Hello and welcome back. My name is Tyler McMann with Aruba, a Hewlett Packard Enterprise Company, and this is the network security basics course. Part 2, the third video in our series, where we're going to be looking at locking down services on our wireless devices. Let's jump on in. Locking down services, best practice if FIPS compliance is required. I mentioned FIPS in the last video, where it stands for Federal Information Protection Service, often where your devices are manufactured in a trade agreement act, country, like the United States or Singapore. If compliance for FIPS is required, meaning that you work for a federal organization or the military, you want to make sure you're using the correct hardware, and with FIPS, there's also some software benefits as well. But regardless, you can still take these steps as best practice to lock down administrative access like logging to the console port that we talked about as well. In addition to that, we can also lock down services. We talked about SNMP Version 1 and 2 in the switching section in Part 1. Version 3, those concepts still apply here when it comes to our wireless, setup authenticated network time protocol. Network Time Protocol synchronizes the clocks between all of your devices, which a savvy hacker might decide to break the time in your environment in order to block any valid authentication, given that your servers might think that they're suffering a replay attack or your certificates themselves may expire, even though they aren't. Then use Control Path Defense. Now, because of the tunneling that we do and that was talking about in the last video. Your access points or tunneling their control plane traffic, they're separately tunneling there data traffic, control-plane goes across an IPSec tunnel, and the data from your actual wireless users goes across what we call a Generic Routing Encapsulation tunnel, where we don't add any encryption, we just leave it encrypted from the wireless user who's using WPA3 or WPA2 encryption, we just leave it encrypted. Then implement recommended global firewall settings. The firewalling is another nice feature. We didn't really go over firewalls in the switching network because the CX switch and the ArubaOS switches are standard layer 3 switches. They support full ACLs and that's great. But what they lack is a full deep-packet inspection, layer 7, application-based firewall that you actually do get when you're using mobility controllers. Rather than going out and buying a third-party firewall from Palo Alto or Cisco, or whatever else. In Aruba, all of our controllers, all of them. From the 7,005 all the way up to the 7280s, they all support a full deep-packet inspection firewall. So let's take advantage of it. Then lastly for that control plane traffic, let's make sure that we are securing it in that IPSec tunnel. Good news about CPSec is that it's certificate-based, it's already up and running, you don't have to do anything except, leave it running, don't disable it for some odd reason. Let's take a look at securing ArubaOS device-to-device communication, and that's just reiterating what I had already talked about. Why do we use control-plane security? Well, you've got your access point here, you've got your controller here, and each of your access points will establish their control-plane securely in order to pass their programming traffic across, what we call PAPI traffic. It just stands for Programmable Application Programming Interface or PAPI. The regular data traffic is going to cross over a separate GRE tunnels debate on the number of SSIDs and the number of radios. But regardless, all that's fine. You could have thousands and thousands of these GRE tunnels that controllers are designed to handle that traffic. With irregular wireless traffic over the GRE, we're not encrypting the GRE. That remains just a regular Generic Routing Encapsulation tunnel. It's literally just traffic over IP. It's easy. With CPSec, we're using IPSec tunneling separate. So that would be established when the API-first associated and was provisioned. Then once it starts advertising these SSIDs, the actual traffic gets converted from the wireless of your mobile device, to the GRE tunnel to reach the mobility controller. Then it just jumps out as regular traffic onto your network as you would expect regular Ethernet traffic. To protect the data from our users, the question is, are we encrypting the data in the first place? If your user is already enforcing WPA2 or WPA3 encryption, then rather than decrypting at the access point, what we do instead is we just keep it encrypted as it goes across this GRE tunnel and reaches the controller, and then the controller is the one that removes the encryption. From end-to-end, any would-be hacker that was snooping are traffic here, and was capturing it on the wireless or even worse, if the eavesdropper was grabbing our traffic on the wired side. In both cases, the payload from the user, they're web searching or their emails or whatever they're sending is going to remain encrypted with whatever encryption you are using here. Typically, we recommend hardware-based encryption, AES with 120 bit or more during CPSec, whatever you like. Without CPSec, there is a bit of a problem here. This is everything I described. But up here I just noticed that said without, so if you went and manually disabled CPSec, which is what you would have to do to turn it off, and I guess you could. Then your control time traffic would be in the clear without any encryption, because it's source from the API. There's no AES or anything like that, it would just be sent and any eavesdropper that's listening, if they were able to grab the wire between these two guys, would be able to see all of the stats, all the configuration, capture keys as they're being passed, not really a great idea. By default, we make sure we leave it encrypted, and as such, any eavesdropper that grabs those payloads would not be able to decrypt the traffic in any mathematically fathomable amount of time. The data remains encrypted regardless, if the user encrypts their traffic, it stays encrypted across the GRE. That's regardless of whether you've encrypted the control plane or not, two separate traffic types, control planes from the API, the data is from the actual user themselves. One quick question before we close out on this one. What do you do if you have a wireless use like I guessed where there is no encryption, it's just open? You could choose to double encrypt just for that SSID, for that wireless network you say, "Oh, well, we're going to double encrypt just for whatever reason." But 99 times out of 100, you'll just continue to forward it encrypted. The point at which it's easiest for someone to capture these frames is if they're in the same proximity as the wireless radio, then those frames are just being broadcasted out. Any would-be hacker could easily physically get a hold of those frames as they're being passed back and forth between the access point and your client, regardless whether they do it there or whether the eavesdropper is able to tap a physical wire, which would take a lot more work. But let's say they do it there, in both cases is the same payload, and in both cases, it's not encrypted. Unless you're doubling crypto on the API, the traffic from your users, if you didn't bother to encrypt it when I was on the wireless, the thought process with Aruba is why bother to encrypt it here? I mean, we give you the option, but generally, you wouldn't worry about it. With important traffic, you are traffic your house with a pre-shared key or corporate traffic, where we're using session-based keys. In both cases, the encryption occurs at the user, and it stays encrypted until it arrives on the other side. We'll pause there, and in the next video, we're going do then lab activity, where we're going to cover how we harden ArubaOS mobility controller. Again, not the switch but the actual wireless controller. See some of these steps in action. Hopefully, you guys have picked up a few tidbits in this video. I'll see you guys in the next one.
