Welcome back to vSphere 8 in the real world.
Now we're going to discuss securing vCenter Server.
So probably one of the most important things,
one of the most, you know, the first things you're going to do
when you're configuring vCenter
is during the installation process,
even installing vCenter,
is you're going to configure your single sign-on source.
Now, you can let vCenter be its own single sign-on source,
or you can also configure it for,
to use another third-party service,
like, for example, the most common one,
the one you see all the time,
is Active Directory Directory Services.
So Active Directory can also be
the single sign-on source for vCenter.
It's very common, almost every time I think I've seen it,
where they install vCenter
and it has its own single sign-on source,
and then they add Active Directory.
It's an additional single sign-on source later.
So you can use the administrator at vSphere.local,
and I see that almost everywhere.
You don't have to use at vSphere.local,
but it seems like everyone is using
that kind of default one there,
with a, hopefully, very secure password,
especially if you are using the app vSphere.local,
because if I'm someone trying to break into a network,
that would be the very first username I would try,
and try and get passwords in order to access vCenter.
All right, so, and with these other things,
also, of course, you want to have trusted certificates.
You want certificates that you can trust when you sign in
using your secure username and your secure password.
All this communication is encrypted,
and it's encrypted using a certificate that you trust.
You trust the identity of the server,
because the certificate in the address bar is green
and tells you, yep, this is the trusted CA.
This certificate name matches the name of the address bar.
All of that matches up,
so I know I'm signed into the right place,
and then we can have trusted encryption as well,
so we know that our passwords
aren't going to be stolen and things like that.
So, we want our vCenter communication to be encrypted.
Now, DNS can be encrypted.
Not many people use encrypted DNS.
That's something you're starting to barely see now,
but some.
Mail is much more often encrypted
using, like, TLS or something like that,
so if you're going to have vCenter, you know,
sending account messages to a mail server,
you probably want encryption configured with TLS.
You probably don't want to use 480, right?
You want to use, you know, HTTPS, you know, using 443,
so that way you know the encryption of your name
and your password is being sent, okay?
So, some other things to consider about your vCenter server.
So, the underlying physical host.
vCenter is a virtual appliance, and as such, you know,
it's going to be a VM on a physical host.
Now, I don't care what system you have.
If your physical hosts aren't secure,
meaning this room that your servers are in,
that data center your servers are in,
the rack that your servers are in is not secure.
People can walk up to your servers, your physical hosts.
If they can get to your hosts, your switches,
anything like that, then you're owned,
and they're going to, you know, have a much,
much easier time in hacking into your systems.
It's very rare that hackers, other than in the movies,
it's very rare that hackers that, you know,
the bad actors actually physically get access to a server.
They're normally in a different country
on a different continent trying to break into these things,
and that's one of the telltale signs,
is that there's traffic going to an IP address
in a, you know, a geoblock that your country,
that your company doesn't normally do business with.
Geoblocking would help prevent some of that.
It doesn't prevent all of it,
because they oftentimes will use jump boxes
in the United States to get to those machines, right?
So you'll take that with a grain of salt.
But if they can physically get to your hosts,
then they can pretty much own you very quickly.
So the underlying physical security
of the host is super important.
Patches are really important.
It's also very well known that most people
who do get hit with some kind of a cyber incident
got hit with a vulnerability to a machine
that a patch was available for,
that, you know, the vendor released,
that might have released a long time ago,
and it was never installed.
Either it was never installed on your firewall,
it was never installed from your, on Windows,
your ESXi boxes were not patched,
your vCenter server wasn't patched.
Some component of your network was not patched,
and a known vulnerability
that made it very easy for them to get in was used.
So patching is very, very important.
Again, certificates from a strip authority
is obviously going to be super important.
Configuring single sign-on to use, like, for example,
Active Directory Directory Service,
where you have, you know, some kind of MFA configured
for your admin accounts,
where vCenter is going to use, like,
the more advanced security, you know,
settings that you probably have on your domain that, you know,
your, whatever company might audit you
is going to check your Active Directory policies.
What is your lockout policy for user accounts?
How long are they locked out for?
What's your password complexity rules?
Things like that, right?
Some kind of external provider,
are you using some kind of third-party provider
for authentication?
Role-based access.
So you probably don't want to go in
and give a user direct access,
direct privileges to, you know, perform certain tasks,
because then when you need to go in
and let another user do that same thing,
then you have to kind of do a lot of that same work over again,
whereas you created a role and gave privileges to the role
and then put users in that role.
You know, you assign the role to the users.
Then if I need to make another user
able to do the same thing again,
all I got to do is add them to that same role.
Also using the predefined roles,
I know, okay, this is my backup role.
This is my virtual machine role.
So by using these roles and saying,
okay, I want my developers to have the VM role
and only the VM role on this one cluster,
now they can power on and power off
and all those kinds of things, the virtual machines.
If I gave them too many privileges
or if I tried to give them privileges,
like on a one-by-one basis, like, okay, you can power on VMs,
you can power off VMs, you can read VMs,
then it gets really messy,
and you might find yourself giving them access
to more things than you meant to as well.
So use the built-in roles.
Built-in roles make it very quick.
They make it easy.
It makes it very repeatable,
and also it makes it easier to, like,
find where maybe you have a weakness somewhere
or something like that, because these predefined roles
can be updated very easily.
So another component of hardening your vCenter server
is configuring a time server.
So you can either use NTP, the network time protocol,
or PTP, which is the precision time protocol.
So the big difference between the two is
NTP is all software, right?
And it's going to be accurate up to the millisecond,
whereas the precision time protocol
actually has special hardware involved
on the host that's going to be using it
and on the machine it's going to be synchronizing with.
And the specialized hardware can get you down
to, like, the nanosecond or the picosecond maybe even.
So obviously, if you're doing something
that has to be just extraordinarily precise
for some kind of scientific work that may be being done,
maybe something like the New York Stock Exchange
might want some very precise time
for when trades happen and things like that.
Most environments, most scenarios,
NTP, the network time protocol, is going to be perfect.
So you can configure your host to use an NTP server,
and that will get you accurate within milliseconds.
As long as your clocks are fine within five minutes,
usually you're in good shape,
because we're just talking about authentication.
So if a user is going to authenticate into a box,
their clock and where they're authenticating from
into the host they're trying to authenticate to
need to be within a few minutes of each other
for authentication to be successful.
If it's too far out of sync,
then what might be happening is the host is going to assume
someone's captured packets on the network,
and they're trying to retransmit the packets
that you used to authenticate.
They're trying to retransmit those packets
to authenticate again with old packets
from, you know, 15 minutes ago
or yesterday or something like that.
They want those packets to be very current
within the last few minutes.
And so the default is normally five minutes.
The clocks have to be synchronized within five minutes.
That doesn't really give people much of a chance
to retransmit authentication packets
and try and use them again.
All right, also time is really important for your log files.
When you're going through and looking at your log files,
you want to know when did something happen.
Having accurate time will help you know
when that event happened.
So if you're looking at it and your time is off by hours
on the host compared to what it really is,
it's very difficult to narrow down
when something actually occurred.
Also clocks on a computer,
they're actually usually pretty accurate,
but it's possible for various reasons.
They can float, meaning that they can actually slow down
or speed up a little bit,
and so it makes the time less accurate.
And if you're using a time protocol server,
it might start to float a few minutes,
but by the time it gets, you know,
within like even a minute or so off,
it's going to synchronize again and get back.
It doesn't float within, you know, minutes,
within, you know, an hour.
It takes days for it to happen.
But they can move around a little bit.
So a time protocol server just keeps those times in sync
to one, your logs are accurate,
so going back and looking at them has more value
and also makes your authentication more secure as well.
So we discussed configuring time services
and we discussed hardening vCenter server.
Let's go ahead and jump into vCenter
and I'll show you how to do some hardening.
So the most common thing that people are going to do
in their vCenter server is they're going to make sure
their time services are correct.
So we could choose one of our hosts.
We can go to configure.
And we can scroll down.
And we can go to, we have services here.
We can go through and we can make sure
that NTP is running.
So NTP right now is currently stopped, right?
So we might want to go there and configure NTP.
So we don't have to start it right here.
Actually, we can go to the NTP configuration
and we can start it up.
So let's go jump over to that.
Let's go to time configuration
and we can say we want to manually set this up.
Now this is just going to be the default time,
default date, right?
We can also say we want to add a service
and we're going to add a precision time.
I don't have precision time hardware on this system.
So I'm going to say I want to add NTP,
the network time protocol.
So we can say enable monitoring of events,
like starting and stopping.
Now I can say an address.
So I might say pool.ntp.org.
So one thing this does by using this particular address
is it is a pool, right?
There are individual computers at ntp.org I can point to,
but pointing to a pool means I'm pointing
to actually a bunch of different servers
so I'm less likely to have one go down.
Another common thing that people do
is they'll point to a domain controller
in their environment.
The only thing about pointing to a domain controller
in your environment is a lot of times
the domain controllers are VMs
and a lot of people do it,
but there's also some bad practices
about pointing to a VM because VMs,
if the host starts to slide,
the VM's time is synchronized with the host.
I hope that might start to slide.
There's like, it gets to be a vicious circle.
Using a third party exterior one
sometimes is a better situation.
You might though have your host synchronize
with a domain controller, even though it's a VM,
and then that VM synchronizes with a third party
or with a physical machine in your environment
or something like that.
So we can specify this here, right?
So now that I've got this configured,
notice it says it's running, right?
So this guy is actually now in running.
So if I were to go back to my services and look at NTP,
it's running now.
And that's really all you gotta do to configure your time
is just go in, add the service,
you can test it, see if it's up and running or not,
see if it's synchronizing or not with you.
So that is configuring NTP.
The other thing you might wanna look at doing
is configuring single sign-on.
So click our hamburger, administration,
and we have single sign-on here, configuration,
and I can go to my Active Directory directory services.
I can say I wanna join Active Directory.
It's asking for the domain name, organization,
that's optional, username and password
that'll allow me to join Active Directory, right?
And of course, my DNS is gonna have to be able
to connect me to there.
I'll say okay to that, reboot the node,
and then I should join Active Directory
and I should be able to authenticate into my vCenter server
using Active Directory directory services.