ITsecurity
twitter facebook rss

Warning – Broken Firewall Ahead

Posted by on August 8, 2015.

I’ve spent the past couple of days trying to make a Billion router (specifically a model 7800DX) act in a vaguely secure manner.  This has proved way more difficult than it should be, and I think it has some worrying implications for anyone who uses this hardware in the expectation that it’s protecting their network.  So whether you’re a Billion customer, or you simply fancy a laugh at other people’s incompetence, you may wish to read on.  It gets a bit technical, but I make no apologies.

Imagine, if you will, that you invested in the aforementioned Billion 7800DX in order to provide internet access and firewall security for your small or branch office.  You have a number of machines on your local LAN, all of which are allocated non-routable IP addresses of the for 192.168.1.x.  Some of those machines get their IP address via DHCP, and some are hard-coded because you need to know that they won’t change.  But everything’s on that 192.168.1 subnet.

And then you decide that you want to use one of those machines as a web or file server.  Possibly for development purposes, or possibly not.  Either way, you decide that you want other people to be able to access that server from outside your LAN (perhaps someone from head office, maybe, or a bunch of customers).  So you buy yourself a spare public IP address and you set up something called One To One NAT on the router, so that traffic destined for the external address gets routed to the server on its 192.168.1 address.  You now have a server which, in addition to being accessible internally in the branch office via its non-routable address, is also available externally too.

Except it’s not, of course, because you need to open a firewall hole for it.  So you log into the Billion router, open a port on the incoming side of the firewall for the external address, and all is well.  Everything works just fine.  Your new web server, or whatever, is open for business.  Your firewall skills are clearly A-rated and you think no more about it.

Correct?  Sort of.

Yes, your server on the 192.168.1 address is accessible from external addresses.  But it’s nothing to do with the Billion firewall.  That rule you specified is actually having no effect whatsoever.  All traffic destined for the external IP address is being forwarded to the server.  Everything is open by default.  Delete the firewall rule you created, and nothing changes.  Your server is still fully open to the world.

I’m currently evaluating Nessus Cloud (http://www.tenable.com/products/nessus/nessus-cloud), a subscription-based hosted version of one of the best-known vulnerability scanners.  Imagine my surprise when I pointed it at the server, fully expecting it to be completely stealthy, and instead being told that Nessus could see a web and ftp server.

Thankfully I always use strong passwords on all my test machines, even if they’re not going to be made available outside of my firewall.  You should too, and this tale is a good reason why.

So if you have a server on a Billion 7800DX via One to One NAT, and you want to use the Billion’s firewall to protect it, can you do so?  You can, but it’s so convoluted and counter-intuitive that you simply won’t believe the steps involved.  Firstly, you have to configure it via the outgoing side of the firewall rather than the incoming one.  Secondly, it takes 2 rules for each port that you need to block.  And bearing in mind that the outgoing firewall forwards all traffic by default, and only allows a total of 32 rules, this means that you can’t block more than a total of 16 ports across all your servers.

You have been warned.  Billion developers, you’re grounded.  Go to your room and don’t come out till you’ve fixed it.  Or at the very least, let your customers know that their network isn’t as safe as they probably think it is.

 


Share This:
Facebooktwittergoogle_plusredditpinterestlinkedinmail

Leave a Reply

Your email address will not be published. Required fields are marked *

Submitted in: Robert Schifreen |