Firewall Stupidity

A company or ISP is worried about crackers. So it installs a firewall which blocks all ports except the ones for services it wants people to use, such as 80 (HTTP) and 443 (HTTPS). It then institutes a complicated policy and procedure for getting new ports opened, complete with risk assessments.

What’s wrong with this picture? Isn’t this just good security practice?

Well, users don’t want to just use HTTP, and application developers want people to be able to download and install their applications. So along comes HTTP tunnelling. Everything gets wrapped in HTTP and a bunch of hacks to make connections appear persistent, and passes over port 80 – or encased in SSL and passed over port 443, where firewalls can’t see what’s going on.

Of course, HTTP is a stateless, transaction-oriented protocol, and not designed for this sort of use. As some outrageous hacks have proved, you can tunnel practically anything over anything else, but the performance always degrades.

So, the entire point of ports is circumvented, and we end up with applications which perform worse on the client and take more resources on the server, and security which is no better. Everyone loses – network admins, users and application developers.

So what’s the conclusion? Default-deny firewall configurations are not actually more secure, because their end effect is to cause users and applications to bypass the system. And, particularly with tunnelling via SSL, there’s nothing an admin can do about it, assuming they want HTTPS to keep working.

9 thoughts on “Firewall Stupidity

  1. tunnelling via SSL, there’s nothing an admin can do about it, assuming they want HTTPS to keep working.
    At my current workplace SSL is denied on most websites except a few chosen one.
    I agree with you port 80 is becoming a junkyard.

  2. I dont get this. An ISP shouldnt block ports. We only use firewalls on specific PCs. My PC at home drops all, except for port 22 and 80.
    We have some firewall scripts that will only allow connections to port 22 from certain ips. I dont understand how anyone would build a tunnel over those ports when the pc doesnt even route traffic.

  3. A-GREED! I just found this out first hand, having arrived at uni last month. Thanks for the link though, I could never find a tunneller that worked. We’ll try this one ^_^

  4. Re: Adrian. It’s not all that difficult. You just write a small script or program that performs the functionality for you, encodes the data in a form that can be sent out over port 80, opens up a connction, and sends out the data. Some programs even do it natively. AIM is one such program. Would you believe that I once had it working over port 21 because that was the one unblocked port that would work?

    A much more useful exercise, at least in big bulk cases like AIM is to block specific sites over all ports on your firewall. No matter what port you’re using, you’re not connecting to login.oscar.aol.com if it’s blocked. It’s a bit impartical sometimes I suppose to make these rules useful, but there are ways to protect ports beyond just blocking them.

  5. Sorry, I still done get it. If I have a web server, wont I block all ports except port 80 and 443? How could people build a tunnel over a PC that will jst host web sites and not route traffic?

  6. Firewall policies need to make good sense. If you set an overly restrictive policy and make it hard to get exceptions for real needs then you’re going to have people using all sorts of tricks to evade the policy. A good policy takes into account the needs of the user community. A perfect firewall policy blocks all illegitimate traffic while allowing all legitimate activities. Failing to allow legitimate traffic is as much an error as failing to block hacker attacks.

    I think it is possible to become so focused on security that the usablity issue is ignored. The security people sometimes need to reminded that firewall or no firewall people still need to get their work done.

  7. maca: this isn’t about user firewalls. User firewalls are fine, as users have control over their configuration. It’s about corporate and ISP firewalls.

    adrian: same as above. This isn’t about firewalls at the service provider’s end either; they are obviously going to open the ports they need.

    The broken situation is:

    • User has web browser and clicks on a link to a RealPlayer stream
    • Target server is perfectly able to send stream
    • RealPlayer port (and loads of others) are blocked by user’s ISP
    • User can’t see stream
    • Real invent HTTP-tunnelled version of their protocol to get around this problem
    • Repeat for lots of other apps
    • Firewall becomes useless

    Gerv