UniFi Management VLAN & Network Security

Tom here from Lawrence Systems, and should you be putting your UniFi network devices on a management VLAN separate from VLAN 1? There will be plenty of discussion undoubtedly in the comments below about people say this is an imperative and it must be done according to the well, overlords at Cisco who said this is the way to do it, who came up with some of these practices and they are some good practices. We'll get into the details of it shortly, but they say this because back in the earlier days you had a management VLAN, they were things going around in Telnet and plain text and easily snippable. That's less the case now. Matter of fact, Ubiquiti was designed much after Telnet and a much different architecture, meaning they had the foresight to understand that these were going to be controlled with the controller system often hosted remotely, externally from the location of the device, as in transported across the internet. That means that the negotiation and the management traffic that goes back and forth is completely encrypted and therefore if it's going over the internet, it can also go on VLAN 1. But there's still some good reasons you may want to change it or may want to leave it the same. We're going to talk about the pros and cons of some of the security implementations of where you put it and what the threat surface looks like based on that and basically show you how to do it because it's relatively easy to do, provided you have things set up properly. Before we dive into the details of this video, let's first... Are you an individual or company looking for support on a network engineering, storage, or virtualization project? Is your company or internal IT team looking for someone to proactively monitor your system security or offer strategic guidance to keep your IT systems operating smoothly? Not only would we love to help consult on your project, we also offer fully managed or co-managed IT service plans for businesses in need of IT administration or IT teams in need of additional support. With our expert install team, we can also assist you with all of your structured cabling and Wi-Fi planning projects. If any of this piques your interest, fill out our Hire Us form at www.LawrenceSystems.com so we can start crafting a solution that works for you. If you're not interested in hiring us, but you're looking for other ways you want to support this channel, there's affiliate links down below to get your deals and discounts on products and services we talk about on this channel. And now back to our content. Now the first thing I want to do is talk about how this network is set up for the demo here. We have a remotely hosted UniFi app controller. It's hosted in the cloud and if you do that, no problem. This will still work. If it's hosted locally, this will still work. The prerequisite is simply that whatever network it's on or whatever network you want to be the management VLAN, both of those networks need to have access to the controller. The inform ERL has to work on either one of those, the native network or the management VLAN. Our two networks are 172.16.16.0.0.24 and 192.168.1.0.0.24. Both of these have access to this remotely hosted UniFi instance and we are just using the port settings of all when we're feeding the UniFi access point. The reason for that is because we need the UniFi access point to provide an SSID with this network and an SSID in this network over here, the tagged 10 network. Now, one of the things that is kind of confusing for some people is doesn't the device, the access point here we're going to be demoing with, need to be in this 192.168.0.0.0.0 network to provide an SSID for that network and actually the answer to that is no. It does not need to have an IP address in that network and the same goes for this. It is currently in the 172.16.16.0.0 network but also doesn't need to have an IP address in order to provide the VLAN native network. So the SSID will work either way. We're only changing the part where this IP address gets assigned to the device for control of the device. So let's go over to our UniFi controller and show you how you switch that which is really easy. Here's our U6LR currently at that address 16.16.16.2 settings. Scroll down here, go to services, change it from LTS Tom to NSW.net, which happens to be that VLAN. We're going to click apply changes. It's going to re-provision that and then it's provisioning already. Well, wait a second, it'll get a new IP address. All right, it has been re-provisioned and something I want to point out is that the uptime is still 27 days. It doesn't actually reboot it but there is a temporary connectivity loss while you re-provision it and connect it to the new management VLAN that you set. That's all you have to do to move it to a management VLAN. Now, let's come back over to our diagram and talk a little bit of theory and the threats we're trying to mitigate against. And the first threat is, well, we'll use this little bad actor and what if the bad actor was able to hijack the stream, hijack the DNS and point us somewhere else? Well, as of right now in August of 2022, that's not an issue because there is no known vulnerabilities between the UniFi controller and the encrypted traffic that goes between each of the devices. A threat actor could disrupt it, they could denial of service, they could hijack the DNS and point it somewhere else. That would cause us to lose visibility, that would cause the devices to not be managed anymore temporarily while that was going on. But not being managed and not talking to the controller doesn't stop them from working, they will keep continuing to work in the last known state. So you would not be able to switch any ports, you wouldn't be able to change the SSID but they will just keep working as they do. This is why when there's controller updates, restarting the controller or updating the software on the controller doesn't cause any disruption to the devices that are working. Now, if the controller is internal, the threat actor then has to move inside the network to do that same level of disruption. But once again, it doesn't allow them anything in terms of being able to modify their devices in a nefarious way. Next problem. And this is where the bigger issue is. And it's too many people put everything on VLAN 1 native. There's a reason I refer to my VLAN 10 as NSFW. It's where the laptops and the computers that play games are. That is where the potentials for problem are. And you don't want those on native VLAN because if you put those devices on native VLAN and then created a special VLAN for like the UniFi, well, anyone who has access to VLAN 1 and that port was set to all as in carrying the other VLAN traffic, there is the potential for someone then to inject packets or do something within that VLAN because the all setting that is on these, for example, for the threat actor gets between the PF sense and the UniFi switch that we have. Well, that would allow them to see all the traffic that's going through and unencapsulate because you remember VLANs are shared because they are sharing VLAN 1 and every subsequent VLAN underneath them. They encapsulate physically on that wire all of the traffic that's on there. So if you're trying to hide it from a visibility standpoint, yeah, that would still be there. Now, visibility is not really an issue because the encryption, there's not any way to unravel the encryption that is known right now, but it's still one of those things to think about. So in summary, it's not a bad idea to put things on a management VLAN, but it's not really all that necessary. It's not where your biggest security risks are. The bigger security risk is someone having access to VLAN 1 and potentially all the encapsulated VLANs within that VLAN. So the native one is perfectly fine to leave it on there. The devices themselves, the UniFi switches, UniFi access points, if someone were to get on that network, what are the things they can directly attack the devices? Well, you don't have to turn on SSH. That's an option. It's off by default. You don't have to turn on SNMP monitoring. That's off by default, but it's a feature you can turn on and they would have things to poke at. So if there was a flaw in SSH and you have it enabled and someone's on native VLAN with the devices, that's a potential attack surface. And if there was a flaw in the SNMP, the same thing, they would be able to attack those ports on there. So this is good reasons just not to let anything be on VLAN 1, maybe other than your UniFi devices. The last thing is port 8080 is open on these devices, but I don't know any known vulnerabilities in that either for them to poke at it or any of the services listening that have a potential exploit. But of course, you know, anytime something can get to something, the potential therefore in the future, if someone finds a way in is there. So just keeping everything off of VLAN 1 and keeping maybe only your UniFi or hardware devices like your PFSense on VLAN 1, make VLAN 1 the management and put everything subsequently might make a lot more sense for your design and architecture. Leave your comments down below. Tell me why I'm right, why I'm wrong. It's always fun to have a healthy discussion about security. And it is a far cry from the years ago when everything really had to be on management because the control plane between the different devices was all, you know, telnet and things like that. I've also got that David Bombal video link down below talking about how VLAN hopping works and how you can dive into Cisco and inject packets. And, you know, that is a security concern. Obviously, you have to really protect the ports to make sure they're all set up. And now that Cisco video is really good on how he does it. Cisco handles things different than UniFi. So just some food for thought and further reading and stuff to think about. Thanks. And thank you for making it all the way to the end of this video. If you've enjoyed the content, please give us a thumbs up. If you would like to see more content from this channel, hit the subscribe button and the bell icon. If you'd like to hire us for a project, head over to LawrenceSystems.com and click the Hire Us button right at the top. To help this channel out in other ways, there's a join button here for YouTube and a Patreon page where your support is greatly appreciated. For deals, discounts, and offers, check out our affiliate links in the description of all of our videos, including a link to our shirt store where we have a wide variety of shirts that we sell and designs come out, well, randomly. So check back frequently. And finally, our forums. Forums.LawrenceSystems.com is where you can have a more in-depth discussion about this video and other tech topics covered on this channel. Thanks again for watching and look forward to hearing from you.