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