Hello and welcome back. My name is Tyler McMinn, and this is the Aruba Networks Security Basics Course. Where we're going to continue our discussion talking about physical security and other measures that we can take after we talked last video about securing some of our networking protocols, so let's jump on in. [MUSIC] Ensure physical security and others, this is something people tend to forget, but it's a good idea to lock the door that your switches are in. I mean, I know this sounds pretty obvious, but locking the closets is a good idea and changing the keys and the passwords to those closets. If you have an employee who gets fired, rotate the keys, get a pin pad or something like that and make sure those are being rotated on a monthly basis regardless. Possibly two factor authentication with biometrics and any ports on a switch or any radios that aren't being used should be disabled. Those are just vectors of attack away a hacker will sniff around to try and get access. On some of our older Aruba switches like the 2930s, they have these reset and clear buttons. And what the clear button would do with a paper clip, you just hold it down, is it wipes the password on that switch. Doesn't erase the config, doesn't bring the switch down, it just erases the passwords. So now a hacker who has physical access to your switch can plug into the management port, plug into the console port, plug into a regular interface and attempt to SSH or command line their way into your switch there and now it's completely open. So if you disable these clear and reset buttons, if a hacker does get physical access to your switch, they're blocked out. They're locked out from wiping the device or resetting it with the reset button or clearing out the passwords with a clear button. Authenticate network time protocol, this is another good step for hardening your switch that you might not think of but hackers have thought of it. And what this network time protocol does is it essentially syncs the clocks on your switches and on your devices to a centralized network time server. A server in your environment that usually over the network has a atomic clock or some other clock out there on the web that they synchronize the correct time to down to the nanosecond in some cases. And the reason why this is important is all of our authentication, especially certificates are based on time. And if you're too far from the clock of the server, there's a certain amount of time slippage that we can allow, might be 5 minutes might be 15 minutes. The server won't allow you to log in for fear that you might be suffering a replay attack or something like that. Certificates expire, so if you have your clock way off like it's 1999 or something, you won't be able to log in at all. So why would a hacker attempt to spoof or to break this network time protocol or inject bad times? Well, it be a great way to do a denial in service if you want to bring down a network and block everybody from being able to log in, you don't have to guess their passwords. All you do is just mess up the time in all their core devices, and now no one can authenticate to the network, we should do something about that. Well, here's what you can do, set your network time protocol to use a password and authenticate only against these trusted servers. So then, if somebody tries to maliciously put a second time into your network here, that's going to be dropped and only the trusted server would be allowed, which is basically what they're showing here. So with authentication, only valid time is accepted. And you can verify this against the trusted server using the authenticated password or a hash of the authenticated password. A hash basically takes the shared secret password and hashes it with an algorithm to produce this hash value. Only someone who knows the password would be able to spit out that exact hash, and therefore the would be hacker wouldn't be able to inject something without that password without that hash proving they knew the secret. Additional hardening steps, set non-zero idle time out. Idle time out is something you can do on your switch that says, if I'm working on my switch typing commands, I'm working and I get up and I leave. How long until the switch kicks me out? Five minutes, ten minutes, usually ten minutes by default but you can change that to whatever number you want. Then some other steps, you could say when somebody logs into the switch, they should see a message that pops up. Like, hey, the device you have access belongs to whatever only authorized user allowed to access this device. Your previous successful login was on etc., from the console. So this is ways that you can upon logging in and validating who the IT person is given a little heads up message about what's going on. Alerts you to any issues, informs you about login attempts. The legitimate IT person might know, whoa, I wasn't I didn't log in on that date and time, now that might be an alert that someone had spoofed there login. And then set lockouts protect from dictionary attacks, this means that if I log in and I fail three times or four times, or whatever lock out number is, it's going to drop my connection and lock me out for an hour or a day. Generally, you want to lock someone out for failing to log in correctly, you want to lock them out for a long enough amount of time that they can't just sit there and guess passwords, but not so long, you want to make it reasonable. So it's not like a week because then people are going to have to file tickets to get all this reset. So if it's ten minutes, that's enough time for me to go get a cup of coffee, come back and try again without having to file a ticket. But if it's ten hours, well, I'm going to file a ticket and someone else is going to have to deal with it. So I think that's a good place to stop, when we come back, we're going to in the next video look at DCP Snooping and our protection, and this is going to get a little more technical. Kind of like the art poisoning that we talked about before, but a really cool way to protect defend against. I told you that we would actually show you how to defend against it, now that time has come. So in this video we were looking at securing our network protocols with secure options. So SNP version 3 versus version 1 and 2. We looked at physical security and some basics there to protect your network as well as network time protocol and some additional hardening steps that you can take with these switches. In the next video, we'll pick it up and do some DCP snooping. So thank you very much for your time, I'll see you guys in the next video.
