All
right, let's take a look at Module 10,
which is going to be dealing with virtualization and cloud computing.
Virtualization is the best thing since sliced bread.
I love my VMware hypervisor, my ability to
set up complete lab environments on a single host.
I just got done building what I'm going to now start calling the twins, but a couple
of Intel Nook Boxes about Yay Big, each running a copy of ESX server, and
I've got 15 machines running on each one, and it's not even breaking a sweat.
Love it.
So virtualization, I refer to software based virtual representation of your IT
infrastructure, which used to be just virtual machines.
Now it's applications, containers, it's networks, it's software defined
networking, it's devices, storage area networks, all emulated in memory.
So the whole concept here is running
multiple individual machines or appliances in a memory space of a single machine.
We'll call that single machine hypervisor environment.
We have a Type 1 and type 2, bare metal, hosted hypervisor.
We'll talk about those a little bit here in a couple of later slides.
Your virtualization framework provides physical resources traditionally
bound to hardware in a multiple individual simulated environments.
All right, so traditional architecture.
Dedicated server, storage, network
hardware, operating system installed, applications run on that.
You may not get optimal use of your resources and processing power.
There may be a lot of unused cycles,
unused resources, and a standard physical deployment.
So to optimize the use of your resources, virtualization is just wonderful.
We can now carve up that memory space and that processor usage and that hard disk
into multiple virtual machines, each acting as a single independent unit.
So they will behave walk, talk, quack, and
so forth, just like a physically air gap machine, but they do share a common memory
space, and that means we are going to be concerned with some unique security issues
that deal with the co usage of resources, covert storage channels, things like that,
crossPM breaches that you wouldn't see in physically air gap machines.
Your virtual architecture, applications,
running on an operating system, all of this multiple OSes run on a single system.
The difference between virtualization,
which I'm probably getting the cart before the horse here, and containerization is
whether or not we have to allocate individual guest operating systems.
So we will come back to that for sure.
Are your virtualization components.
Hypervisor, virtual machine monitor.
You've got your Type 1s or Type 2s.
Your bare metals like an ESX server, or
you're hosted like a BMW workstation running on a Windows OS.
So for example, I am currently running, and this is an example of my setup here.
So right now, I'm running a hosted hypervisor on my local box.
I can actually open virtual machines
locally, or I can connect to my ESX server, which I love this.
I just stood this up recently, haven't used one for years, and holy cow, the
performance of this thing is just fantastic.
Man, I love it.
There's all my current virtual machines installed on this box.
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13.
I think I said 15.
But I got another one I'm setting up with
a bunch of different lab machines for the courses.
My utilization for all of this is pretty minimal.
These guys are all running and it doesn't miss a beat.
Really absolutely love it.
The benefit of a bare metal is less resources used for the
first layer operating system and more allocated to the guest.
And actually just the time slicing in the management just seems to be way better.
So absolutely love it.
But I could definitely open a local host
and be running a hosted hypervisor as well.
All right, so my virtual machine monitor
or hypervisor allows me to manage the virtual environment.
My guest machine or virtual machine are
the individual instances that I create within my virtualization environment.
The virtual machines again behave like their independent physical machines, but
again, they're all running in the same memory space.
So VMS run on top of the hypervisor.
Your host machine or physical machine is
the machine that provides the competing resources to support virtual machines.
A management server, virtualization platform components used to directly
manage virtual machines, which may use a VMware hypervisor, vSphere, that thing.
Then the management console interface used
to access, configure, and manage the virtualization product.
I just can't resist, I got to take a look at one more aspect.
That was two.
Love the web interface as well.
I'm like a kid after Christmas.
This is my management interface, web based.
That could get all crazy with licensing
and vSphere and all that, but this is all free.
Love that.
I built these little nook boxes, and every time I pick it up and show it to
the camera, I end up hitting the power button.
I'm not going to do it again because my virtual is going to drop.
But I've got two small form factor
machines like this running an Intel i7 12 core processor, 6 core multi threaded.
I've got two terabytes of M 3 drive, and
I've got 64 gigs of RAM, and I've got more than I need for sure.
Love it.
All right, so apparently my evaluation license has expired.
They're still running just fine, and I've got all this implemented for free.
The virtual machines, there's the breakdown.
You can do all sorts of resource
allocation, subdivision, really manageable.
I digress.
Virtual virtualization enablers.
Network virtualization, software defined
networking, network function virtualization.
You can emulate all this stuff in memory.
Pretty much everything is going the way of
virtualization because we've got lots of cloud providers, lots of
rack space, everything's happening in the virtual cloud environment anyway.
So it just makes sense that we're going to start virtualizing all this stuff in
memory versus physically allocating systems and devices and so forth.
So you can implement a virtual storage or network.
You can implement virtual appliances.
You can implement different network configurations.
And actually, while we're on that subject,
if I go to my virtual network editor, just on the VMware workstation level,
I can manage multiple networks, attach host to each network.
And then in my ESX server, I can get really crazy with that.
Add multiple networks, virtual switches,
physical NICs, TCP IP stacks, firewall rules, whole nine yards.
That may be going to scratch the surface on this configuration.
Virtual desktop infrastructure.
Imagine you need remote access
and imagine you've got a mobile workforce and imagine that mobile workforce is using
home machines and home tablets and you've got some of this bring your own device
type of thing happening and you've got some security concerns.
I remember back in the day when I
supported end users, dial up connections, VPNs, and so forth at one of the first
training centers I worked at, and we had some concerns on AV.
We had a couple of situations where some
files got infected based on a user's machine.
They didn't have antivirus software installed, etc.
So you have some definite security
concerns on your endpoints that goes without saying.
But a great way to remedy that is to use a virtual desktop infrastructure.
So if I'm using a remote host,
that remote host is accessing corporate data, storing things locally, acts as a
pivot point or traversal point of the network, then I do have a higher exposure
or a risk of compromise than if I was just tremodeling in to a virtual desktop.
So how about this instead?
How about we have a virtual desktop that you remote into, and really all that's
happening remotely is keyboard and video and mouse, and all the processing, data
access and so forth takes place in the target network.
So rather than me implement it locally, I
would just use my hypervisor, connect to this guy.
And actually, I've got this set up for outside access.
I won't really demonstrate that because I want to show you live IP addresses or
anything and invite people to test my security.
But I could just connect to one of my VMS
from a remote location and do all my processing on the remote VMS.
So a full virtual desktop is one thing,
and then you have virtual applications that could be published as well.
But before we go to the virtual mobile discussion or virtual application
discussion, we've got the container concept to introduce.
Okay, container in general is just virtualization, a contained environment.
Virtualization based on an operating system where the OS functionality is
replicated on multiple instances of isolated user space called containers,
software containers, or virtualization engines.
All right, so typically when we think of
containers, we think of things like Docker or Kubernetes.
But the container is really just a contained environment.
And really what it is
is a confinement of memory space that all the processes run in.
Containers as a service includes virtualization of containers and
container management through orchestrators.
Using this service, subscribers can develop rich, scalable containerized
applicationsthrough the cloud or onsite data centers.
A container engine, managed environment
for deploying containerized applications, the orchestration, the process of managing
the life cycles of the containers, and a couple of examples of container
orchestration software, docker sworn, open shift and Kubernetes.
So in virtualization, they're both
more or less containers without using the term, but the virtualization where you
virtualize the OS is a hypervisor, where you virtualize the application and
put it in its own isolated environment that's going to be a container.
So the difference between the two is whether or not the guest OS is required.
So types of containers.
Again, OS containers uses an operating system run multiple services.
Examples, LXC, Open VZ, Linux V server, and so forth.
Application containers run a single
application per containerversus multiple services on a single OS.
Docker, probably one of the most widely recognized, widely used open source
technology for containers, developing, packaging and running applications.
Docker provides a platform as a service functionality through OS level
virtualization and delivers containerized software packages.
Again, I hate to say this out loud, but I haven't really done a lot with containers.
I just haven't really gotten around to it.
As far as container security and cloud
environments and so forth, most definitely, I've never really done a lot
with managing my own local resources using a container engine.
One of these days I'll get around to it, but haven't done much with it.
Microservices versus Docker.
Monolithic applications broken down to cloud hosted subapplications called
microservices that work together, each performing a unique task.
Each microservice packaged in the docker container
along with required libraries, frameworks and configuration files.
Microservices belong to a single
application, can be developed and managed using multiple platforms.
So again, you're encapsulating everything
in a little portable object, monolithic versus micro services.
Kubernetes is one of the other more notable container engines out there.
Also known as K8s, open source, portable,
extensible orchestration platform developed by Google for managing
containerized applications and micro services.
Resolving framework, managing distributed containers.
So it is a Pepsi to docker's Coca Cola, if you want to look at it that way.
And there's lots of examples of Kubernetes tools.
Again, don't really do much with it.
So a lot of this discussion in this module
is going to be purely academic, not a lot of experience, at least, administrative.
I understand the security issues, believe
me, I attack them, but just really haven't configured them.
Our docker security threats.
Escaping is always an issue.
When you escape, you're escaping the confines of the container.
So gaining of root access on the host
server by the user with access to a container.
Whenever anything is encapsulated or confined in software, there's a way out
somehow, just really a matter of finding it.
Software defined or software enforced
security barriers, they're software enforced, they can be hacked.
Physical security barriers get a lot more resilient.
We talked about pros and cons of physical versus virtual.
Cross container attacks, gaining access to a container and
utilizing it to attack other containers on the same host or within the local network.
Now you've got lateral movement between
the containers versus a vertical to the host server.
Enter container attacks, gaining unauthorized access to a single container,
and then docker registry attacks, gaining access to the docker registry.
Now in the lab, you're going to do a lot
with cloud, but not a lot with the container stuff.
So then you have some great labs for you
on AWS and Google Cloud, but not really much for you on the containers.
What is serverless computing?
Serverless computing sounds an awful lot like computers without servers.
Kind of.
Known as serverless architecture or function as a service.
Cloud based application architecture, where your infrastructure and supporting
services are provided by the cloud vendor as they are needed.
So you're really just getting application functionality.
Serverless computing simplifies the process of application deployment,
eliminates the need for managing the server and the hardware by the developers.
So we're going to look at some cloud
models here shortly, and those will also illustrate whether we're administering the
network, the platform, or just the application.
Software is a service, platform is a service, or infrastructure is a service.
Service computing frameworks. Some examples.
Aws Lambda, Cloud Functions, IBM Cloud
Solutions, AWS Fargate, Elibaba Cloud Function Compute.
Our Vue Sprawl Avoidance.
We defined the term Sprawl in our earlier module.
Sprawl is where you have several systems
that are really not fully documented or accounted for, sprawled out through your
network, and as such, they get lost in the cracks.
They may introduce security issues.
They may be pivot points for attackers and that thing.
It occurs because of a lack of proper
policy implementation for the provisioning and de provisioning.
You stand something up, you forget about it, and you just leave it running.
I am guilty of that in my lab environments.
Living VMS idle for long duration when the
administrator overlooks, fails to handle or control all the VMS in the network.
To avoid it, perform an audit, protect
data resources, identify appropriate sites for VMS, clear orphan snapshots, well
named naming conventions, archival, cataloging and inventory.
All right, VMS escape protection.
I remember it vividly back in 2007, 2008, Cloud Burst came out.
And up until that point, we'd have
relatively few hypervisor level vulnerabilities.
And I remember thinking to myself, this Cloud Burst exploit, you could install a
key logger on the host hypervisorfrom a guest virtual machine.
I remember thinking to myself, there goes the neighborhood.
Here's the whole virtual security is going right out the window now.
We're seeing live example of it.
It's just going to get worse from here.
But man, that was 13 years ago and there's
really been relatively few similar types of vulnerabilities.
Now, there's always the possibility of
cross VM breaches through normal communication vectors, right?
Shared folders, things like that, network connections.
But using the hypervisor vulnerability in the hypervisor to breach virtual machines,
that would definitely be a flavor of vulnerability.
So, VM escape protection.
Escape attack attempts can be minimized by
placing VMs that offer web services and other services in independent security
zones with the corresponding physical host.
Now you're talking about physical segregation of what's otherwise virtual.
So again, put them in an isolated subnet, even though they're abstracted on virtual
machines, still put them in an isolated security zone.
All right, protection against VM escape
attacks, update or patch the DM software, install only the required resources,
minimize software installations because each program could have its own exploits.
All right, Docker security tools. Docker bench.
I'm sorry, you are going to be doing a lab on docker bench.
Relatively new course.
I don't have all the labs committed to memory yet.
But docker bench for security is a script that enables host configuration, docker
gaming configuration, configuration files, build files, and container runtime.
It's going to run through a series of scripted checks.