I’ve found what I consider a vulnerability with the default setup of Destination NAT as documented by Ubiquity. A lot of people just follow the setup guides without really thinking about how it works. There are several YouTube videos that seem to follow this setup guide and if you follow it exactly how it’s written you open up your Firewall to whatever port you are trying to open externally. Here’s the link to the document:
And here’s a link to a video I did that shows how the vulnerability works:
This is not a plug for my YouTube channel but I can see if someone might think it is.
Ok so in the instructions you need to configure one firewall rule and two Destination NAT rules. It is the Firewall rule that I am most concerned about. Let’s say that I substitute TCP port 443 with say TCP/UDP port 3389 (RDP). In the instructions it states that I should create a new rule in the WAN_IN ruleset and that the rule should allow whatever port I want to open as the Destination Port, set the basic setting to accept, set the protocol (in this case TCP and UDP), and then nothing else. Without any further restrictions you’ve just allowed any computer that can point it’s Gateway address to your WAN IP address access to any system on the Internal network or networks over the port that was opened. Of course in my example I was using RDP so only Windows systems are affected but you may not want just anyone snooping around your Exchange server. Of course to make this work you are going to need to know the Internal IP addresses and when you make the connection, you are going to use the Internal IP of the device behind the Firewall. But I’m guessing the Internal subnet wouldn’t be too hard to guess. So if I were going to create this Firewall Rule I would probably limit the connections to just the Internal IP addresses or address group that allow for that service to be connected from the outside. I’m sure some of the more experienced users are probably like “No Duh!” but there’s probably thousands of other users that just follow what’s written and when it works don’t think twice about it.
Interesting no current clients with the Edge Router but have access to same and will take a look. Docs have been known to be wrong so I’ll pass this along to others I work with.
As the video shows it’s a pretty easy thing to test for. In my current position we have all of our workstations using public IP addresses (protected up stream) and all of our servers behind Enterprise level Firewalls. We’d probably lose our accreditation if we had a hole like this open. It’s not that the documentation is wrong, it just that they are selling a “Firewall” router but they are not taking the time or effort to expand on their setup instructions. In the world of senior level IT support, you must learn what it takes to limit access to all your supported systems. The hard part is still allowing for business processes to continue to work for users and systems.
Back when I was more hands on I would always set do the initial config and take the time to review docs with client admins to avoid such things and many a time called in to fix problems arising from same. There are many novice admins who do not have the in depth knowledge to avoid these kind of traps. Incomplete docs are the same as wrong docs.
Hopefully posts such as yours will be seen by those who need to see such the most. Passed the info along to folks I have working relationships with. Little omissions could bring down the house.
Ubiquiti response to the issue with the docs is to be applauded. They are definitely on my good to go list. Tom’s videos on Ubiquiti’s products convinced me to take a critical look at the full line. In the past used the Edge Router and has been solid. An important metric in product choice is responsiveness to issues big or small. That is something missing in all the marketing hype.
