Why You May Actually Need a Firewall

Today, a client sent us this article: Why you don't need a firewall. Now of course, we sell an appliance that includes a firewall, so I admit bias in this matter. On the other hand, my sysadmin side loves the idea of less devices to manage. Sadly, this editorial's justifications lack logic and reason.

The author, Roger A. Grimes, first argues that software is less hackable today than it was in the past, thereby reducing the need for a firewall. This couldn't be further from the truth. Every single security bulletin published by Microsoft in the last year contains one or more remote code execution vulnerabilities. As long as new code is written, new bugs will inadvertently be created. I doubt Mr. Grimes is a proponent of leaving servers unpatched, but if that was his argument, a firewall that blocks access to a server's vulnerable services from outside the network could certainly prevent them from being exploited. Even if you do aggressively patch your servers, each month's security bulletin informs you of the exploits your servers and workstations have been vulnerable to up until the moment they're patched.

Mr. Grimes' next argument is that 'firewalls tend to be horribly managed,' as 'almost no one reads the logs or responds to the events recorded.' This is clearly an administrator problem. Although some devices are easier to use than others, I know of at least one vendor that works hard to make the task of remediating network alerts as simple as possible.

But he continues: "I find so many firewalls with "ANY ANY" rules that defang the protection, it doesn't faze me anymore." This is indeed a useless rule set. The AccessEnfocer blocks all inbound traffic by default, and with three clicks, blocks all outbound traffic as well. This has been our recommended practice since inception of the company, and our customers know we have articles on our Online Portal that explain in simple terms how to lock down a network using a 'default deny' rule without hurting users or blocking critical network traffic.

His next argument against ports 80 and 443 being too open is really just a continuation of the last one. Any decent firewall will help you lock down these ports, and more. Between a web filter that proxies all web traffic, to an intrusion prevention engine that inspects and blocks it, to a content filter that blocks known malware sites as well as certain types of downloads, a UTM device can reduce the attack surface significantly. Of course, no system is perfect, which is why security experts recommend multiple layers of security, and of course, continuous signature/definition updates.

Mr. Grimes' own examples even work against him. "The recent Remote Desktop Protocol exploit is a case in point: Microsoft recommended that affected clients block RDP port 3389 at perimeter firewalls as one of their protective work-arounds. But everyone I know, instead, installed the emergency patch," he writes. However, the flaw was first discovered in May 2011. If administrators had previously blocked port 3389, their servers would never have even been publicly vulnerable.

I once worked for a university IT department that assigned public IP addresses via DHCP to every internal computer. When deploying new machines, we would first bring them online on a dedicated, firewalled network in order for them to receive their patches and security policies. We once accidentally connected a batch of new laptops to our WiFi network by accident. Shortly thereafter, we received a call from the Security Office saying we had a bunch of IP's on our network spewing out spam and malware. The total time that had elapsed between putting these laptops on an un-firewalled network and receiving that call: five minutes.