WEBVTT

00:00:00.000 --> 00:00:04.000
Welcome back to vSphere 8 in the real world and now we're going to discuss securing VMs.

00:00:06.480 --> 00:00:10.080
So some of the things you're going to talk about when you talk about securing VMs are going to be

00:00:10.080 --> 00:00:14.080
things we've already talked about before and some of the things are going to be things that

00:00:14.080 --> 00:00:19.760
you would normally just do if you had physical servers like physical Windows servers for example

00:00:19.760 --> 00:00:23.360
and there are maybe a few things a couple things that you might do that would be a little bit

00:00:23.360 --> 00:00:27.760
unique for a virtual environment but for the most part one of the first things you're you know one

00:00:27.760 --> 00:00:32.959
of the first rules that you're going to adhere to when you're securing a virtual machine are the

00:00:32.959 --> 00:00:38.400
same things that you did to secure your ESXi hosts and the same things that you did to secure vCenter.

00:00:38.400 --> 00:00:41.840
So for example you know if your host you want to make sure your hosts are patched you want to make

00:00:41.840 --> 00:00:46.160
sure vCenter is patched you want to make sure that you have you know signed certificates from

00:00:46.160 --> 00:00:52.160
a trusted root CA you want to make sure that you know that you physically have secured your house

00:00:52.160 --> 00:00:56.959
all those rules that we talked about for securing your host and securing vCenter are going to be

00:00:56.959 --> 00:01:02.000
true for securing your VMs because if they can compromise your host or they can compromise vCenter

00:01:02.000 --> 00:01:08.000
to get to your host and they can get to your VMs they can compromise your VMs to them. So you want

00:01:08.000 --> 00:01:12.720
to make sure that you've secured your vSphere environment both your vCenter host vCenter server

00:01:12.720 --> 00:01:18.720
and your ESXi hosts. You want to ensure you've physically secured those boxes as well so they're

00:01:18.720 --> 00:01:25.440
going to be in a secure data center locked doors behind you know gates you know that kind of thing

00:01:25.440 --> 00:01:30.080
that they're in racks the racks are going to be locked there are racks that have a bunch of

00:01:30.080 --> 00:01:33.279
different sensors on them so you know of course things like if it's getting too hot the sensor

00:01:33.279 --> 00:01:36.879
is going to go off and let you know and things like that but also if the door of the racks opened

00:01:36.879 --> 00:01:41.839
right so there's all the kinds of things like that can you know create alerts and let you know so if

00:01:41.839 --> 00:01:46.000
someone into your data center someone should be alerted if someone opened the gate into your data

00:01:46.000 --> 00:01:50.639
center you should be alerted if someone opened the door to the rack then you should be alerted right

00:01:50.639 --> 00:01:55.120
so there's a bunch of things that you can be notified to help you secure the physical servers

00:01:55.120 --> 00:02:00.239
themselves and then for your guest os so now we're actually talking about specifically the VMs

00:02:00.879 --> 00:02:05.360
so for your guest os all the same things you would want to do if you had a physical

00:02:05.360 --> 00:02:10.800
server a physical windows server for example make sure your anti-virus is up to date any

00:02:10.800 --> 00:02:16.399
anti-malware tools that you're using are up to date make sure that the guest os so if you're

00:02:16.399 --> 00:02:22.559
running windows server 2016 or you know 2022 whatever make sure that your windows servers are

00:02:22.559 --> 00:02:27.839
patched and patched up you know completely and currently of course you know most people are

00:02:27.839 --> 00:02:31.759
going to want to test their patches and things like that in the lab and then deploy into production

00:02:31.759 --> 00:02:36.880
but make sure this happens quickly so you are current all those kinds of patches once microsoft

00:02:36.880 --> 00:02:41.440
has released a patch for something they often are going to say this is what we patched here's the

00:02:41.440 --> 00:02:46.080
vulnerability here's the information about it so now it's known out into the world so if there's a

00:02:46.080 --> 00:02:51.119
patch out there you need to install it and get those machines patched if a windows machine is

00:02:51.119 --> 00:02:55.679
going to be vulnerable a physical window machine can be vulnerable to something on your net over

00:02:55.679 --> 00:03:02.320
a network that vm is also potentially vulnerable the exact same thing so make sure your guest os

00:03:02.320 --> 00:03:06.800
is a patch and make sure all your hardening is done you know hardening guidelines are things like

00:03:08.000 --> 00:03:12.559
don't run services you don't need if you're not going to be sharing files and printers don't run

00:03:12.559 --> 00:03:16.880
the file you know sharing services on there don't run services you don't need

00:03:17.759 --> 00:03:22.160
that just you know opens you up to more vulnerabilities don't have devices that you

00:03:22.160 --> 00:03:27.199
don't need don't have open network ports on your on your storage don't have open you know storage

00:03:27.199 --> 00:03:31.520
controller ports on your on your devices you know things like that on your physical boxes on your

00:03:31.520 --> 00:03:35.440
vms don't have devices you don't need don't have things like floppy drives don't have things

00:03:35.440 --> 00:03:41.279
like um uh you know serial ports that you don't need and things like that right so don't have as

00:03:41.279 --> 00:03:48.000
few devices on your vms as necessary meaning only the ones you need okay minimize the vm console

00:03:48.000 --> 00:03:53.919
use so don't use that vm console more than you have to communication between it and the client

00:03:53.919 --> 00:03:58.720
should be encrypted but it also you know again the more use of things like that you're better

00:03:58.720 --> 00:04:02.960
off using some kind of you know other more secure encrypted access like maybe you have

00:04:02.960 --> 00:04:12.000
some kind of monitoring agent forward and things like that so unnecessary remove unused services

00:04:12.000 --> 00:04:16.239
for example like i mentioned before if you don't need file services don't don't enable them if you

00:04:16.239 --> 00:04:21.200
don't need services for unix don't install them because they're cool you like you know having

00:04:21.200 --> 00:04:27.600
the ability to run linux commands or units commands on a windows server right don't install services

00:04:27.600 --> 00:04:32.239
and features that you're not going to use strip it down to the absolute minimum

00:04:33.119 --> 00:04:37.679
uh any unused physical devices on the physical machine on the virtual machine same thing remove

00:04:37.679 --> 00:04:44.079
those devices and use a function so again don't add a bunch of displays to a virtual machine if

00:04:44.079 --> 00:04:48.559
you don't need a windows server pies that need to have two and three uh displays on the virtual

00:04:48.559 --> 00:04:54.000
machine configured you know things like that so secure that with a minimal uh functionality that's

00:04:54.000 --> 00:04:59.679
needed to run it now i'm not saying strip it to where it cripples the machine like well i can you

00:04:59.679 --> 00:05:03.359
know take this and that out it's going it's going to hamper the performance it's going to hamper

00:05:03.359 --> 00:05:09.119
the functionality but i can't take it off leave what you need for functionality leave what you

00:05:09.119 --> 00:05:13.200
need for performance leave the memory you need there for the performance the cpus and all the

00:05:13.200 --> 00:05:18.160
devices that are needed for performance and functionality but just if things aren't needed

00:05:18.160 --> 00:05:22.880
don't add additional devices that aren't needed don't add more network cards than what are going

00:05:22.880 --> 00:05:28.160
to be needed things like that so don't run anything that aren't necessary securing your

00:05:28.160 --> 00:05:34.959
virtual virtual machines also means network security so isolate the network so it's very

00:05:34.959 --> 00:05:40.399
common in an enterprise environment and it's very easy to do not to you know too expensive too

00:05:40.399 --> 00:05:46.399
complicated even you know smaller less than an enterprise environment to have a separate vlan

00:05:46.399 --> 00:05:50.799
for servers and a separate vlan for your workstations and a separate vlan for your

00:05:50.799 --> 00:05:56.239
phones and a separate vlan for security devices even a small you know network would have that

00:05:56.880 --> 00:06:03.920
often in enterprises what we might see is we might see domain controllers are on one vlan and a

00:06:03.920 --> 00:06:08.239
separate vlan for you know an application the application might have several parts and we're

00:06:08.239 --> 00:06:13.760
going to put that application onto a separate vlan now if i want to get really um you know

00:06:13.760 --> 00:06:18.720
very fine tuned in my security i might have a vlan for my sql servers and i might have another vlan

00:06:18.720 --> 00:06:24.160
for you know a back-end application and i only allow the back-end application to talk to the

00:06:24.160 --> 00:06:30.000
sql server network over you know the ports that are used by sql specifically so there's going to

00:06:30.000 --> 00:06:33.600
be a small number of ports that sql is going to need you know for communication with with the

00:06:33.600 --> 00:06:39.040
back-end device that back-end device might then communicate with a web application you know front

00:06:39.040 --> 00:06:43.600
end and maybe only allow communication between those on the just the ports that are needed that

00:06:43.600 --> 00:06:48.239
kind of thing so i can segment that down really really fine in a big enterprise that's more common

00:06:48.320 --> 00:06:54.880
to see in a smaller environment where maybe only have um five or six hosts maybe only have like 100

00:06:54.880 --> 00:07:01.279
or so vms that's less likely seen but it's always a good practice so if you're able to segment your

00:07:01.279 --> 00:07:05.600
environment like that and able to configure the firewall if you have the knowledge the expertise

00:07:05.600 --> 00:07:12.959
to do that kind of stuff then it's advisable isolate network traffic on your hosts it's also

00:07:12.959 --> 00:07:18.000
a really good idea to isolate traffic you want a network for your vmotion traffic you want a

00:07:18.000 --> 00:07:23.359
network for your management you want another network for your storage right all on different

00:07:23.359 --> 00:07:27.679
vlans and you don't want routing between them because they don't need to talk to each other

00:07:27.679 --> 00:07:32.000
so you would you know configure a firewall policy that does not allow any communication between

00:07:32.000 --> 00:07:35.839
the storage network and your management or your vmotion network in your management things like

00:07:35.839 --> 00:07:42.640
that same thing would be true for your applications so you know in an esx host maybe you have three or

00:07:42.640 --> 00:07:47.119
four or five different vlans configured um don't want to get too carried away and you know with

00:07:47.119 --> 00:07:51.440
things that aren't necessary but maybe you have your print servers on a different vlan from your

00:07:51.440 --> 00:07:56.079
file servers or from your domain controllers things like that all right so close the firewall

00:07:56.079 --> 00:08:00.559
ports that aren't needed so it doesn't do you a lot of good to create these separate vlans and

00:08:00.559 --> 00:08:06.000
then to allow just routing from the layer three switch so everything can talk to everything on

00:08:06.000 --> 00:08:10.640
all the different ports so if someone discovers oh you know i'm on this vlan but i see another

00:08:10.640 --> 00:08:16.079
ip subnet exists let me scan that one too because there's no firewall blocking any of that

00:08:16.079 --> 00:08:21.040
so it's a good idea to route your traffic in your firewall and then we'll only allow what's through

00:08:21.040 --> 00:08:28.880
what's absolutely needed okay um and that's your network security policies so um firewalls are one

00:08:28.880 --> 00:08:33.440
example of network security policies there also are you know seams they're going to monitor your

00:08:33.440 --> 00:08:38.960
network traffic you can do a sampling of traffic going to these devices and they can then uh if

00:08:38.960 --> 00:08:43.359
they see suspicious behavior they can send out alerts maybe they can run a script that's going

00:08:43.359 --> 00:08:47.359
to shut down an interface on something to stop running from happening if a certain type of alerts

00:08:47.359 --> 00:08:52.080
triggered things like that so any kind of network security policy you would have in your physical

00:08:52.080 --> 00:08:57.760
environment you want to be applicable to your virtual environment uh vm specific network traffic

00:08:57.760 --> 00:09:05.919
so again a subnet for vms and maybe a subnet per type of vm maybe again domain controllers are in

00:09:05.919 --> 00:09:12.239
one and file and print servers are on a different one things like that okay all of that segmentation

00:09:12.239 --> 00:09:18.880
can happen through the use of vlans and your firewall now if you bought your firewall with

00:09:18.880 --> 00:09:22.960
the intention of we're really going to monitor the user's connections out to the internet

00:09:24.239 --> 00:09:30.799
and you size it as such and then all of a sudden you decide to start throwing other vlans on it so

00:09:30.799 --> 00:09:36.239
the routing is happening on that firewall device and all of a sudden we're seeing like you know

00:09:36.239 --> 00:09:40.080
servers talking to servers and clients talking to servers and a bunch additional traffic you

00:09:40.080 --> 00:09:45.039
might overwhelm your firewall so make sure that before you move that kind of stuff to the firewall

00:09:45.039 --> 00:09:50.159
that your firewall is sized appropriately and then if you know when you're buying a new firewall

00:09:50.159 --> 00:09:53.520
if you're thinking about doing that make sure you purchase firewall that will handle that kind of

00:09:53.520 --> 00:10:02.239
traffic all right so connecting to storage so this is kind of similar but a little bit different

00:10:02.880 --> 00:10:08.320
isolate network traffic so really for your storage there shouldn't be routing between

00:10:08.320 --> 00:10:13.039
really anything else and your storage most of the time storage is going to be very specific

00:10:13.039 --> 00:10:18.559
to a physical location i have this cluster of hosts maybe i have like two or three or four

00:10:18.559 --> 00:10:24.640
clusters maybe i have you know clusters um you know cluster of six over here and a cluster of 12

00:10:24.640 --> 00:10:30.320
over here a third cluster of you know five or twenty or something like that and they all use

00:10:30.320 --> 00:10:35.919
the same storage array that you've purchased you know and maybe it's some huge array with

00:10:35.919 --> 00:10:40.400
multiple controllers and it's able to handle the load from all these different hosts that you have

00:10:40.400 --> 00:10:45.679
you know put in front of it there's not really a lot of reason to route any of that traffic the

00:10:45.679 --> 00:10:50.719
only time that you might see traffic going across the land to a wide area network is if we're

00:10:50.719 --> 00:10:56.719
replicating from one storage array to another storage array like a dr site or something like

00:10:56.719 --> 00:11:03.119
that but for the most part 90 of our storage traffic is going to be local on this one land

00:11:03.679 --> 00:11:09.119
and nothing else should be on that storage network if you're using fiber channel then just by the

00:11:09.119 --> 00:11:13.440
nature of what fiber channel is that's isolated right that's just all that's going to be unique

00:11:13.440 --> 00:11:19.840
and specific to just the spider channel hbas and the controller on the storage array if we're using

00:11:19.840 --> 00:11:25.520
iSCSI and that's going through our traditional layer 3 switch it's not uncommon at all to see

00:11:25.520 --> 00:11:30.960
people purchase switches that are dedicated just for storage there are higher end switches they're

00:11:30.960 --> 00:11:37.760
very very fast of course you enable jumbo frames already on there and you know we might have a

00:11:37.760 --> 00:11:44.320
bunch of 100 gig connections or a bunch of 50 gig connections from our hosts to this um this

00:11:44.320 --> 00:11:48.479
storage switch that we're calling the storage switch because we've dedicated storage and then

00:11:48.479 --> 00:11:54.000
to our storage array well that's the only thing on there we've isolated it but sometimes we'll see

00:11:54.000 --> 00:12:01.599
where you know people have connected to a switch and new to switch has you know several open qsfp

00:12:01.599 --> 00:12:06.080
ports and so we're going to connect our hosts because we have a smaller number of hosts and

00:12:06.080 --> 00:12:12.960
our storage array to that switch and other ports on that switch are being used for um the servers

00:12:12.960 --> 00:12:17.520
like the esx host themselves that's where the vm traffic goes to and that's where the management

00:12:17.520 --> 00:12:22.080
traffic goes to maybe we have some 10 gig interfaces on that for the vm traffic or for the

00:12:22.080 --> 00:12:27.039
management traffic for free motion traffic things like that um vlan that all off separately and

00:12:27.039 --> 00:12:31.760
we're not going to route between it the vlan that's for my storage probably doesn't even need an ip

00:12:31.760 --> 00:12:35.840
address at all because we're not going to route in or out of it and since we're going to be routing

00:12:35.840 --> 00:12:41.359
in and out of it we don't need to worry about having a a gateway on there or an address on

00:12:41.359 --> 00:12:47.679
there for to route out through okay so isolate the traffic if you do have a gateway on there if you

00:12:47.679 --> 00:12:52.719
can get in and out of it for some reason use a firewall to secure it block it don't let you know

00:12:52.719 --> 00:12:57.359
any traffic in or out of it it's not necessary and really nothing should be necessary so we shouldn't

00:12:57.359 --> 00:13:00.719
need a firewall because we shouldn't have an ip address going to it most of the time

00:13:01.359 --> 00:13:06.719
uh strong network security um vm specific traffic well you know for our storage network there should

00:13:06.719 --> 00:13:13.119
be no vms on there only storage um and it should be on a dedicated vlan just for my storage only

00:13:13.679 --> 00:13:18.479
so uh it's very similar in rules only much simpler because there shouldn't be anything

00:13:18.479 --> 00:13:26.479
going in and out there so in conclusion securing our vms is very similar to securing our esxi

00:13:26.479 --> 00:13:30.479
and our vcenter because we have to follow the same practices for that it's also very similar

00:13:30.479 --> 00:13:34.880
to securing a physical server we want to secure its network we want to put it on a separate

00:13:34.880 --> 00:13:39.119
segment we want to make sure it's patching up to date we want to make sure that you know our

00:13:39.119 --> 00:13:44.880
antivirus and our anti-malware tools are all up to date all that kind of stuff we want to have as

00:13:44.880 --> 00:13:50.960
few devices on that virtual machine as necessary we want to run as few services on that vm as

00:13:50.960 --> 00:13:56.320
necessary all these same things are true when you're securing a physical environment so securing

00:13:56.320 --> 00:14:00.880
a virtual machine and securing a physical machine are also very similar