Welcome back to vSphere 8 in the real world and now we're going to discuss securing VMs.
So some of the things you're going to talk about when you talk about securing VMs are going to be
things we've already talked about before and some of the things are going to be things that
you would normally just do if you had physical servers like physical Windows servers for example
and there are maybe a few things a couple things that you might do that would be a little bit
unique for a virtual environment but for the most part one of the first things you're you know one
of the first rules that you're going to adhere to when you're securing a virtual machine are the
same things that you did to secure your ESXi hosts and the same things that you did to secure vCenter.
So for example you know if your host you want to make sure your hosts are patched you want to make
sure vCenter is patched you want to make sure that you have you know signed certificates from
a trusted root CA you want to make sure that you know that you physically have secured your house
all those rules that we talked about for securing your host and securing vCenter are going to be
true for securing your VMs because if they can compromise your host or they can compromise vCenter
to get to your host and they can get to your VMs they can compromise your VMs to them. So you want
to make sure that you've secured your vSphere environment both your vCenter host vCenter server
and your ESXi hosts. You want to ensure you've physically secured those boxes as well so they're
going to be in a secure data center locked doors behind you know gates you know that kind of thing
that they're in racks the racks are going to be locked there are racks that have a bunch of
different sensors on them so you know of course things like if it's getting too hot the sensor
is going to go off and let you know and things like that but also if the door of the racks opened
right so there's all the kinds of things like that can you know create alerts and let you know so if
someone into your data center someone should be alerted if someone opened the gate into your data
center you should be alerted if someone opened the door to the rack then you should be alerted right
so there's a bunch of things that you can be notified to help you secure the physical servers
themselves and then for your guest os so now we're actually talking about specifically the VMs
so for your guest os all the same things you would want to do if you had a physical
server a physical windows server for example make sure your anti-virus is up to date any
anti-malware tools that you're using are up to date make sure that the guest os so if you're
running windows server 2016 or you know 2022 whatever make sure that your windows servers are
patched and patched up you know completely and currently of course you know most people are
going to want to test their patches and things like that in the lab and then deploy into production
but make sure this happens quickly so you are current all those kinds of patches once microsoft
has released a patch for something they often are going to say this is what we patched here's the
vulnerability here's the information about it so now it's known out into the world so if there's a
patch out there you need to install it and get those machines patched if a windows machine is
going to be vulnerable a physical window machine can be vulnerable to something on your net over
a network that vm is also potentially vulnerable the exact same thing so make sure your guest os
is a patch and make sure all your hardening is done you know hardening guidelines are things like
don't run services you don't need if you're not going to be sharing files and printers don't run
the file you know sharing services on there don't run services you don't need
that just you know opens you up to more vulnerabilities don't have devices that you
don't need don't have open network ports on your on your storage don't have open you know storage
controller ports on your on your devices you know things like that on your physical boxes on your
vms don't have devices you don't need don't have things like floppy drives don't have things
like um uh you know serial ports that you don't need and things like that right so don't have as
few devices on your vms as necessary meaning only the ones you need okay minimize the vm console
use so don't use that vm console more than you have to communication between it and the client
should be encrypted but it also you know again the more use of things like that you're better
off using some kind of you know other more secure encrypted access like maybe you have
some kind of monitoring agent forward and things like that so unnecessary remove unused services
for example like i mentioned before if you don't need file services don't don't enable them if you
don't need services for unix don't install them because they're cool you like you know having
the ability to run linux commands or units commands on a windows server right don't install services
and features that you're not going to use strip it down to the absolute minimum
uh any unused physical devices on the physical machine on the virtual machine same thing remove
those devices and use a function so again don't add a bunch of displays to a virtual machine if
you don't need a windows server pies that need to have two and three uh displays on the virtual
machine configured you know things like that so secure that with a minimal uh functionality that's
needed to run it now i'm not saying strip it to where it cripples the machine like well i can you
know take this and that out it's going it's going to hamper the performance it's going to hamper
the functionality but i can't take it off leave what you need for functionality leave what you
need for performance leave the memory you need there for the performance the cpus and all the
devices that are needed for performance and functionality but just if things aren't needed
don't add additional devices that aren't needed don't add more network cards than what are going
to be needed things like that so don't run anything that aren't necessary securing your
virtual virtual machines also means network security so isolate the network so it's very
common in an enterprise environment and it's very easy to do not to you know too expensive too
complicated even you know smaller less than an enterprise environment to have a separate vlan
for servers and a separate vlan for your workstations and a separate vlan for your
phones and a separate vlan for security devices even a small you know network would have that
often in enterprises what we might see is we might see domain controllers are on one vlan and a
separate vlan for you know an application the application might have several parts and we're
going to put that application onto a separate vlan now if i want to get really um you know
very fine tuned in my security i might have a vlan for my sql servers and i might have another vlan
for you know a back-end application and i only allow the back-end application to talk to the
sql server network over you know the ports that are used by sql specifically so there's going to
be a small number of ports that sql is going to need you know for communication with with the
back-end device that back-end device might then communicate with a web application you know front
end and maybe only allow communication between those on the just the ports that are needed that
kind of thing so i can segment that down really really fine in a big enterprise that's more common
to see in a smaller environment where maybe only have um five or six hosts maybe only have like 100
or so vms that's less likely seen but it's always a good practice so if you're able to segment your
environment like that and able to configure the firewall if you have the knowledge the expertise
to do that kind of stuff then it's advisable isolate network traffic on your hosts it's also
a really good idea to isolate traffic you want a network for your vmotion traffic you want a
network for your management you want another network for your storage right all on different
vlans and you don't want routing between them because they don't need to talk to each other
so you would you know configure a firewall policy that does not allow any communication between
the storage network and your management or your vmotion network in your management things like
that same thing would be true for your applications so you know in an esx host maybe you have three or
four or five different vlans configured um don't want to get too carried away and you know with
things that aren't necessary but maybe you have your print servers on a different vlan from your
file servers or from your domain controllers things like that all right so close the firewall
ports that aren't needed so it doesn't do you a lot of good to create these separate vlans and
then to allow just routing from the layer three switch so everything can talk to everything on
all the different ports so if someone discovers oh you know i'm on this vlan but i see another
ip subnet exists let me scan that one too because there's no firewall blocking any of that
so it's a good idea to route your traffic in your firewall and then we'll only allow what's through
what's absolutely needed okay um and that's your network security policies so um firewalls are one
example of network security policies there also are you know seams they're going to monitor your
network traffic you can do a sampling of traffic going to these devices and they can then uh if
they see suspicious behavior they can send out alerts maybe they can run a script that's going
to shut down an interface on something to stop running from happening if a certain type of alerts
triggered things like that so any kind of network security policy you would have in your physical
environment you want to be applicable to your virtual environment uh vm specific network traffic
so again a subnet for vms and maybe a subnet per type of vm maybe again domain controllers are in
one and file and print servers are on a different one things like that okay all of that segmentation
can happen through the use of vlans and your firewall now if you bought your firewall with
the intention of we're really going to monitor the user's connections out to the internet
and you size it as such and then all of a sudden you decide to start throwing other vlans on it so
the routing is happening on that firewall device and all of a sudden we're seeing like you know
servers talking to servers and clients talking to servers and a bunch additional traffic you
might overwhelm your firewall so make sure that before you move that kind of stuff to the firewall
that your firewall is sized appropriately and then if you know when you're buying a new firewall
if you're thinking about doing that make sure you purchase firewall that will handle that kind of
traffic all right so connecting to storage so this is kind of similar but a little bit different
isolate network traffic so really for your storage there shouldn't be routing between
really anything else and your storage most of the time storage is going to be very specific
to a physical location i have this cluster of hosts maybe i have like two or three or four
clusters maybe i have you know clusters um you know cluster of six over here and a cluster of 12
over here a third cluster of you know five or twenty or something like that and they all use
the same storage array that you've purchased you know and maybe it's some huge array with
multiple controllers and it's able to handle the load from all these different hosts that you have
you know put in front of it there's not really a lot of reason to route any of that traffic the
only time that you might see traffic going across the land to a wide area network is if we're
replicating from one storage array to another storage array like a dr site or something like
that but for the most part 90 of our storage traffic is going to be local on this one land
and nothing else should be on that storage network if you're using fiber channel then just by the
nature of what fiber channel is that's isolated right that's just all that's going to be unique
and specific to just the spider channel hbas and the controller on the storage array if we're using
iSCSI and that's going through our traditional layer 3 switch it's not uncommon at all to see
people purchase switches that are dedicated just for storage there are higher end switches they're
very very fast of course you enable jumbo frames already on there and you know we might have a
bunch of 100 gig connections or a bunch of 50 gig connections from our hosts to this um this
storage switch that we're calling the storage switch because we've dedicated storage and then
to our storage array well that's the only thing on there we've isolated it but sometimes we'll see
where you know people have connected to a switch and new to switch has you know several open qsfp
ports and so we're going to connect our hosts because we have a smaller number of hosts and
our storage array to that switch and other ports on that switch are being used for um the servers
like the esx host themselves that's where the vm traffic goes to and that's where the management
traffic goes to maybe we have some 10 gig interfaces on that for the vm traffic or for the
management traffic for free motion traffic things like that um vlan that all off separately and
we're not going to route between it the vlan that's for my storage probably doesn't even need an ip
address at all because we're not going to route in or out of it and since we're going to be routing
in and out of it we don't need to worry about having a a gateway on there or an address on
there for to route out through okay so isolate the traffic if you do have a gateway on there if you
can get in and out of it for some reason use a firewall to secure it block it don't let you know
any traffic in or out of it it's not necessary and really nothing should be necessary so we shouldn't
need a firewall because we shouldn't have an ip address going to it most of the time
uh strong network security um vm specific traffic well you know for our storage network there should
be no vms on there only storage um and it should be on a dedicated vlan just for my storage only
so uh it's very similar in rules only much simpler because there shouldn't be anything
going in and out there so in conclusion securing our vms is very similar to securing our esxi
and our vcenter because we have to follow the same practices for that it's also very similar
to securing a physical server we want to secure its network we want to put it on a separate
segment we want to make sure it's patching up to date we want to make sure that you know our
antivirus and our anti-malware tools are all up to date all that kind of stuff we want to have as
few devices on that virtual machine as necessary we want to run as few services on that vm as
necessary all these same things are true when you're securing a physical environment so securing
a virtual machine and securing a physical machine are also very similar