Welcome back to vSphere 8 in the real world, and now we're going to discuss hypervisor security.
So some ESXi hypervisor security, some things to consider.
First of all would be shell or SSH access.
So shell access would mean we are at a console and we can go to a shell command and issue commands,
or we can also SSH into our ESXi host and we can run commands in an SSH console.
So through either one, we can use our ESXi commands and we can issue commands to configure virtual machines,
to configure networking, to configure storage.
We can do monitoring from a shell as far as we can monitor resource utilization.
Just about everything that you would need to configure on an ESXi host or in a vSphere environment,
you can do from some kind of command.
It might be through SSH.
You can also use PowerShell.
There's what they call PowerCLI.
And so VMware's PowerCLI is a plug-in for PowerShell that allows you to use the PowerShell tool to connect to an ESXi host
or to connect to vCenter.
And once you connect to vCenter, you can use these PowerCLI commands,
which look just like and they are basically in PowerShell for configuring your vSphere environment.
And that allows you to obviously to do things like configure scripts and things to either deploy virtual machines
or reconfigure hosts and things like that.
So one of the nice things about doing like with the PowerCLI is it makes it really easy to import CSV files,
and so we might want to deploy 100 VMs.
And all the unique answers for those 100 VMs are in a CSV file or maybe a couple different CSV files, things like that.
So we can configure either our shell or SSH.
We might want to disable those so when we don't need them, they're not open and not vulnerable to the network.
We don't want some bad actor to get into our network and then start trying to SSH into our ESXi host or into our vCenter server
and change things, compromise things, and start encrypting things, things like that.
So we can enable it when we want it, and we can disable it when we don't.
And we can also set a timeout value.
So we can say, okay, we're going to enable it, but we also want it to automatically disable after an hour or something like that.
So if we forget to go back in there and disable it when we're done, which does happen, it will automatically disable itself.
You can also say timeouts for like lack of activity.
So you can also disable the DCUI, and that is basically the console of that server where you might see a monitor with a keyboard
if you're connected physically to that, your DCUI.
We can also configure that with a timeout.
So with so much inactivity, it's going to go away.
And you can also disable it.
So your shell, your SSH access, your SSH daemon service, and your DCUI can all be locked down
so they're not vulnerable to hackers on your network.
So if somebody were to compromise your environment, you have some kind of a cyber incident,
those are not avenues they can try to take advantage of to get access to your systems.
Also, this is true for pretty much every single thing on your network, whether it be Windows servers, Active Directory,
your firewall switches, your VMware environment.
You want to set the least amount of privilege that is necessary to do a task.
If you've got a user that their only job is to go in there and view and monitor things
and they're not allowed to make changes, don't make them a full domain admin.
Don't make them a full administrator in your vSphere environment.
Don't give them root-level privileges.
Create a user account.
They can only read the things they need to read.
If a user is going to manage storage, give them storage access, give them backup access.
Don't, again, make them full-blown admins.
Of course, the users that are going to be full-blown admins that need access to everything,
those are the only ones that should be full-blown admins, full-on root-level privileges.
So use the principle of least privilege.
Only let people do the things that they need to do.
People sometimes, I hate to say, get lazy, but that's kind of what it is.
And, like, I don't want to create this custom group and add this.
I'm like, oh, if I need to do that too, okay, let me go add that.
And it's just easier to give them, you know, admin access.
Go ahead and, yeah, you can do everything.
And you can do it everywhere.
There might be users who need to be full-blown admins with access to everything in a cluster,
but not access to another cluster.
Maybe not levels, you know, to go in there and manage licenses and things like that within vCenter.
They just need to have full access to the host.
So, for example, a good example of this is sometimes, and not everywhere,
but some environments I've been in where the developers have full admin access to their cluster.
They have full admin access to their ESXi host.
They have full access to their VMs.
They can go in there and they can configure the networking and things like that.
That's a little bit scary, but I've seen that.
You might want to give the, you know, developers full-blown access to the VMs.
They can go in there and they can create the VMs.
They can delete VMs.
They can start VMs, stop VMs, all that kind of stuff, but not to the hosts.
They don't need to access port groups.
You don't want them assigning a VLAN onto something that it shouldn't be assigned to,
or, you know, you don't want them, you know, making changes to the network cards on the hosts
and, you know, bringing the hosts down for some reason, things like that.
Again, it's their cluster.
So if they assign the wrong VLAN tag someplace
and it happens to make the VMs not be able to communicate anymore, it affects their cluster.
That's kind of up to you and up to your environment.
But, again, least privilege.
If they don't need to modify the host and all they need to be able to do is start
and stop VMs, create new VMs, delete VMs, things like that,
upgrade their VMware tools on VMs, then just give them that privilege.
Don't give them all the other things they don't need access to.
So principle of least privilege.
That's a really good practice.
It's a good thing to keep in mind in all your areas of IT.
Automate host management for consistency.
So one nice thing you can do is you can use auto-deploy.
Don't see that used a lot, personally.
I don't.
You do see it in some places, but it's not used a lot.
And what auto-deploy basically means is your hosts pixie-boop
and they get an ESXi image pushed out to them,
and then a host profile is applied to the host,
and the host is configured that way.
And when it shuts down, it loses everything.
It's just nothing on there.
If you were to unplug the network card and turn it back on again,
it wouldn't get anything.
There would be no OS on there.
So every time it deployed, it pulls the OS from the network.
You can use auto-deploy also to actually install it on the hard drive,
but the real reason to use auto-deploy is I want a new image basically
every time.
So what you can do, what happens, though,
let's say ESXi host number 5 just catches fire and blows up.
I can go in there and change the reservation from the ACP for its MAC
address to another MAC address on another host,
and that will get that machine's auto-deploy image.
So as long as my hardware is identical, same CPU,
model and same hard drives and network cards and everything's the same,
then when it comes up, it will just come right up.
It will say, okay, this is now host 5,
and it will get host 5's profile.
So the ESXi host isn't really any longer married to that hardware.
It's married to where auto-deploy points to for that host, right,
just by using its MAC address.
Okay, so in host profiles, I can use auto-deploy.
So I can install ESXi on the host, just the good old-fashioned way,
boot up to a USB drive, install ESXi,
join the vCenter, and then I'm going to apply a host profile to that host.
And it will get all the settings and all this configuration,
all the storage, its networking, everything will come in that host profile.
And the nice thing about that is I can have, you know,
a base image host profile, and then just what's unique for my host.
So my host name will be unique, and my, you know,
IP address will be unique, certain things will be unique.
But for the most part, all my hosts are exactly the same,
pulling from the same host profile,
with just uniqueness for each individual host on the network.
So if I want to add another datastore, I can add it to the host profile,
and then all the VMs that share that host profile with their unique settings
will get that same datastore when they reboot.
Okay, so there's some advantages of host profiles,
and you do see those used more.
I'm not saying they're always used, but you see those used more often.
And the nice thing about that is, again, a consistent environment.
You can push some advanced security settings.
You can push things in there like, you know,
disabling certain services like SSH.
You can, you know, specify time servers.
You can specify, you know, NTP.
You can configure a lot of your security settings
in that host profile as well.
And now I know all my hosts have the same security settings across the board.
If there's something later on that we're like, oh,
we need to change this and add this new security, you know,
configuration to all of our hosts, if you have, you know,
dozens and dozens of hosts or more,
we don't have to go to every host and make this change.
We can update the host profile, and then we can reboot the host
and push it out, and they all get that new security setting.
And remember, I don't have to shut down my environment to reboot a host.
I can just evacuate the VMs off of it using vMotion
and then reboot the host on there.
And, of course, limit the number of firewall ports that are open.
So one nice thing that ESXi does is when you go and you start the SSH service,
it will also open the firewall port, so SSH will be allowed in and out.
And when you shut down the SSH service, it will close the firewall port.
So you can, you know, go in and configure a firewall to only open
and close with services that you have started, you know,
and stop those firewall ports from being open when you stop those services.
So keep your firewall settings nice and tight.
Only allow through things that you're actually using.
Don't enable firewall ports on services that you don't need
or are not necessary for your environment.
So lockdown mode.
Lockdown mode is a way of going in and configuring, basically,
what we were kind of talking about before.
We can stop SSH.
We can stop the shell.
We can stop the DCUI.
If we enable lockdown mode, that's going to automatically stop our shell and SSH, right?
And if I do strict, it also stops the DCUI, stops that console access.
If I do normal, then my DCUI might be enabled,
and I can specify which accounts are allowed to sign on to it.
So we have two different versions of our lockdown mode that we can use for
locking down and securing a ESXi host.
And this will be kind of automating, pushing to a policy, you know,
stopping all these things on our hosts.
So here we're just seeing, so, you know, with different modes of lockdown mode,
you know, what is going to run, what's not going to run.
If I don't have lockdown mode configured at all, what services are running,
what APIs are available, things like that.
Then if we look in the middle, we see we have a normal lockdown mode,
what's going to be available, what's not available,
and then we have strict lockdown mode.
So, for example, the vSphere Web API.
All users can use it if we're not in lockdown mode.
If we are in lockdown mode, then the VPX user is going to be able to use it,
and we can have exceptions, right?
And if we have strict, then it's just going to be the VPX user for vCenter,
and everything else is going to be locked down a lot tighter, okay?
So you can kind of look through here, and you can kind of see, you know,
when is the DCUI going to be allowed, you know,
allowing users to connect to it.
When in normal, pretty much everyone can get to it.
If I do a normal lockdown mode, then, again,
I have to specify what users can access it, and if I put it in strict,
no one can access the DCUI.
So this is kind of a nice little chart that kind of breaks down for you,
you know, if you're in normal mode without lockdown,
normal lockdown, or strict lockdown.
So some other considerations.
VIB package integrity.
So you can specify that you want ESXi to only install signed VIBs.
You can say only install VIBs that have been signed by VMware that we know
to be, you know, tested, certified.
They're on the hardware compatibility list.
It might be from a third party, but VMware has signed them,
so we know VMware has tested them to work, you know, with this version of ESXi.
If you don't want that, then you can install third-party VIBs or other VIBs,
but there's no telling how trusted or safe that is.
There's really not a good reason in most environments unless maybe it's a lab
environment or something like that where you might be using less expensive
hardware, less reliable hardware.
I'm not too worried about it.
This is my lab environment, and so I'm going to allow unsigned VIBs.
In production, though, you should have all your hardware on the HCL
and only have signed VIBs, and your VIBs are basically the packages that are
going to have, you know, services, drivers, libraries,
things like that from VMware.
Certificate management, are you going to use a third-party
or enterprise certificate of authority?
By default with VMware, your ESXi and your vCenter,
you're using the self-signed certificates that those computers
generate themselves.
If you want to have a better security environment with a trusted certificate,
so when I go to a certain address, let's say it's my vCenter address,
that address bar at the top should be green,
and that means that the certificate, you know,
that for the host I connected to matches the name in the address bar,
so everything's good.
If it's red, then that could mean that the certificate isn't a trusted CA,
the certificate might be expired, the name on the certificate doesn't match
the name in the address bar.
A lot of things can happen.
It could be someone pretending to be my vCenter environment to try
and capture my credentials when I try to log in or something like that.
The screen that I'm looking at looks like vCenter,
but really it's a fake page someone created trying to capture my credentials.
So someone's already compromised my network.
If it's a nice green bar, then that certificate should be trusted.
It's from a CA that we trust, things like that.
You can also allow or configure smart card authentication.
So if, you know, you're using, for example, a single sign-on environment
where, you know, the smart cards are using your single sign-on,
you can configure vCenter to also use single sign-on.
And, of course, lockout.
By default, five attempts to log in unsuccessfully,
it locks your account out for 15 minutes.
You can go into the command line and you can change those.
You can change the number of failed attempts.
You can also change the timeout value.
You can also do, for example, active directory integration,
so some kind of single sign-on.
The very common one that you see everywhere is active directory integration.
And now the lockout policy is going to be controlled by that environment.
So if in active directory you say we only allow three failed attempts
and it locks out for 30 minutes,
then that's how long that account is locked out for
if a user tries to log into vCenter using an AD account unsuccessfully.
So in conclusion, we discussed lockdown mode and security concerns.
Let's go ahead and jump into our demo environment,
and I'll show you how to configure some of these things.
So here in vCenter, we can go to our host,
and there's different ways we can configure
a bunch of these different things we just discussed.
So a lot of these things are going to be configured
by going to the host and going to configure.
And we can scroll down here.
And notice here I have firewall
and what services are enabled or disabled.
So here, for example, we have SSH on here, defined.
DHCP is on here.
The vSphere web client access is configured on here.
So different things like that are all configured on here for the firewall.
We can also go in and edit some of these options,
and we can manage some of these different firewall configurations.
Now, if we go to services, for example, here I see on this host
I have SSH and SSH is running, right?
If I go to this other host and under services,
I can see SSH is stopped, and I can go in, select it.
I can start it.
I can also go in and look at its startup policy.
I can say start and stop manually,
which for something like SSH,
that's probably the option you're going to choose.
I can say start and stop with the host.
So something like web access, so for managing the host,
you probably want that to start and stop with the host, right?
And we can also specify start and stop with port usage, okay,
and that would be related to how the machine is being accessed.
So the common ones, though, are either manual or with the host.
Another thing that we can look at is our advanced system settings.
So under here, you can see there are a lot of options in here, okay,
and there's actually pages and pages and pages of things here.
So one thing we can look at is we can look at shell access.
So I might go to here and go to filter,
and I want to look for user variable bars, okay.
So here I can see my DCUI timeout.
I can specify how long I can be idle on a system before this DCUI is
going to kick in, right?
We can also look for, in this environment, shell access.
Whoops.
Shell.
Do we want to allow shell access by default, right?
Let's see.
Shell size for our buffers.
I don't want shell size on there.
We can also go in if we want to disable or disable.
Oh, and SSH.
Whoops.
That keeps going away on me.
SSH.
So here I can specify how many sessions, right?
Now, this is going to be non-root users.
Root users, the root user won't be included in this.
Fifty is a lot, a lot, right?
So I might want to go in and change that number down to, like,
five or four, you know, one, something like that, right?
That session limit might be excessive for what we're looking for.
So we can go in there and we can kind of make this SSH access a
little more secure.
So besides configuring timeout values for things like, you know,
console, DCUI, or SSH, or the shell, from advanced settings,
I can also go to the DCUI.
Now, because these are virtual machines,
I can actually just go to my DCUI from here.
I've already logged in, and I can go down to troubleshooting options.
And here I can modify the timeouts for the shell or SSH, right?
I can set them to, by them being to zero,
because there is no timeout set.
I can also go to the DCUI idle timeout.
So if I'm not using this for, you know, a certain length of time,
how long until I'm timed out.
By default, it looks like it's set to ten minutes.
If I set it to zero, there is no timeout.
And I can also increase that to be a higher value.
So if I back out of here, just in my configuration,
my troubleshooting options is where I can go to configure those tools
there.
Now, also, some other options we might want to look at configuring besides
timeouts is we might want to look at our sign-on, right?
So I can go to my hamburger here.
I can go down to administration.
And here I have, you know,
configurations for creating users and groups for single sign-on.
So I can go to configuration.
And if I have an active directory domain, I can go to here.
I can say I want to join an active directory domain.
Now, this one here, the connection to it has failed.
That's why you're seeing that right there.
I think that domain controller is not currently running.
That's why you're seeing that.
If it was, and the connection had succeeded,
I would have leave domain, right?
Also, like I said, I can join.
And so this will allow me to use my active directory accounts when I go to
sign into vCenter.
And by using my single sign-on through active directory,
through my active directory directory services,
then all the security policies I have enabled over there will work here,
like my password complexity rules,
my number of logged on attempts before I'm locked out,
and how long I'm locked out for, things like that.
Also, if someone were to call and say, hey,
I'm trying to log into vCenter and my account got locked out,
I tried it too many times, then I can go to active directory to unlock it.
Or if my company has a self-service portal for doing things like unlocking
your own user accounts, they can go to there.
So, again,
all these things that you've invested in in your organization to help your
organization run better,
vCenter can kind of take advantage of that by using your active directory
integration.
So that's just kind of some of the summary of things like the locked out.
Oh, I think there's one more I forgot to mention.
So let's go back to our inventory here, our host, under configuration here,
security profile.
I don't think I mentioned this one, our lockdown mode.
We can go to edit over here and we can say if we're not using lockdown mode,
so this is like our normal, you know, not lockdown mode.
We have, if we are using lockdown mode,
then we have normal lockdown mode, right,
and we have all the restrictions that we saw in that graph,
and then we have strict lockdown mode.
So with strict lockdown mode, even like the DCUI is locked out,
and with normal,
my admin or my root users can still log into the DCUI with normal lockdown
mode, but with both of these, I don't have SSH access,
I don't have shell access,
so I've really reduced the footprint for the vulnerability for these hosts.
All right,
and that's just a quick overview of how to secure a ESXi host.