Hello and welcome. My name is Tyler McMinn with Aruba, a Hewlett Packard Enterprise company. This is the network security basics course, Part 1, video Number 10. In this video, we're going to continue on with our discussion into securing protocols. What protocols are we going to use? These are protocols we use all the time. But what's the secure version of them? Or what's our best practice when we're utilizing these protocols? Let's get started. All right, so using secure protocols. We're going to take a look at a list of protocols that might allow us to, for example, get command line access or do file transfer over serial, or doing web access or Simple Network Management Protocol. If you look at this table, what it shows is the protocols themselves like command line could be done through Telnet or Secure Shell SSH. The security of Telnet is generally insecure. It's not that you can't put a password on SSH. The problem is that the password is in the clear. It's security is just not very good security, is the white picket fence of security in front of your house. SSH, on the other hand, is cryptographically secure. In fact, there's some steps that we can take in the the full 4-day class where we go through, and we actually install certificate authority certs or generates certs, and then distribute those in a secure manner to your management team. Some best practices that can be used rather than just using SSH and checking the hash every time you get connected. What is enabled by default in the original Aruba operating system, and what is enabled by default in the new CX operating system, and a little checkbox is show you which. The older operating system, one thing you might notice is that everything is enabled, secure, insecure by default, with the exception being your web access, which you can enable if you want to and SNMP Version 3, which you can enable as well. It's just not enabled by default. The Arouba OS seems like the better buy because you have support for all of these older algorithms. The CX, which does not support Telnet at all, you cannot enable it, nor can you enable HTTP or TFTP. These are not options that are available and CX if you wanted to use them. You might think, well jeez, I'm really missing out. Well, it's for your own benefit. It's like if we were able to make a car that wouldn't start unless you buckled your seat belt as the driver or something like that. Although that might be a little bit annoying. In this case though it's actually a good thing. There's really no compelling reason to utilize these protocols in today's networks to access that switch itself. It's not that you couldn't take your laptop and be able to go through the switch and get to a web server that runs HTTP, you certainly can. The CX switch will allow you to access HTTP. It's just as an administrator, I wouldn't be able to connect to my switch using HTTP to manage it, wouldn't be an option. I'd have to use certificate based, TLS based encrypted HTTPS connection. I would have to, same thing with command line, I'd have to use SSH. Or secure file transfer protocol, which is transferring files over SSH in a manner that someone who's sniffing that traffic, or is doing a man in the middle would either not be able to do a man in the middle or wouldn't be able to discern the traffic, even if they were able to tap the line somehow. The same thing with simple network management protocol. There's an older standard. We don't really use it as much in lieu of REST API calls and scripting in modern networks. But there are still a lot of examples out there of networks that use pulling through devices like air wave with Aruba, or you might be familiar with something like solar winds or the old HPE IMC product. These are tools or servers that query your network devices, your printers, your servers, your routers or switches, whatever, that's used this old protocol from the early 2000s in order to have the device report back as to its status. In fact, you could actually send commands to configure the device. You could shut ports down, you could reboot devices with SNMP. The problem with SNMP is that the first versions of it were extremely insecure. No real password other than community strengths, which aren't really even passwords. There is a version three that's available. It's been available since 2005. You obviously would support it with any modern device that's still around and kicking. That's the lesson here, is Step 1 of hardening any communication or any type of device is always go with the secure version, even if it's a little more of a hassle to set up and get configured. Disable any of these older versions whenever possible. Take the steps to remove these from your normal workflow because those are vectors of attack that hackers look for. Disable SNMP Version 1, Version 2, the vulnerabilities are they used plain text passwords, they're susceptible to eavesdropping. Basically, it just exposes your network as useful as it is to air wave, to be able to monitor the status of all your switches and all your connections and all your devices. It's also just as usable for the hacker to make that a target of reconnaissance, so remove that, use Version 3,and by using Version 3, all of this information would be encrypted and your authentication would be validated using strong hashing algorithms. With Version 3, you go in and create an SNMP Version 3 user. This is on the newest CX switch. Match the username. The authentication protocol uses a strong hash called secure hashing algorithm or SHA. We use a good strong password as well as full encryption, which you can use an older cipher standard called DES,D-E-S. But it's weak, very weak, in fact, compared to the modern standard, Advanced Encryption Standard, which is AES, that would be your encryption password. You have to two types of security here. You have the authentication which validates identity that your server is able to talk to that networking device, like airwaves is able to talk to your CX switch. You also have encryption between your switch and the airwaves server so that if the line is tapped, which is certainly a possibility, the hacker wouldn't be able to inject their own commands because they couldn't authenticate, and they wouldn't be able to read the information being passed back and forth because it's kept in this encrypted AES container. Set the global security level and then enable SNMP on a management VRF. This is probably a good place to stop for this video. We talked about securing our network protocols as well as locking down SNMP and what the steps are involved to do that. In the next video, we'll continue on, and we will discuss physical security and a few other little best practices when it comes to locking your network, including authenticating your network time protocol. Again, I appreciate your time. I will see you guys in the next one.
