Why you don't need a firewall

Once, firewalls were useful for certain types of attacks. Now they're more trouble than they're worth -- and create a false sense of security into the bargain

Firewalls need to go away. I'm just saying what we all already know. Firewalls have always been problematic, and today there is almost no reason to have one.

Computer firewalls have been with us since the 1980s. Even early on it was pretty clear that they didn't really work; if they did, we would have defeated malicious hackers and malware a long time ago. But at least back in the day there was a decent reason to need them.

[ The Web browser is your portal to the world -- as well as the conduit that lets in many security threats. InfoWorld's expert contributors show you how to secure your Web browsers in this "Web Browser Security Deep Dive" PDF guide. | Keep up with key security issues with the Security Central newsletter. ]

A vestigial defense
For nearly three decades, remote buffer overflows were the most dreaded tool in the hacker's arsenal. Simply find an open listening port running a vulnerable service, pile in executable code, and -- voila! -- your buffer overflow exploit gained you complete system access.

That's hardly ever true anymore. The number of truly remote buffer overflows -- the ones you can point at a listening service and pull the trigger, such as SQL Slammer or MS-Blaster -- are dwindling and nearly gone. Ask Microsoft: Since the release of Microsoft Windows Server 2003 in April of that year, Microsoft Windows has had only a handful of truly remote buffer overflows. This is out of literally thousands of different versions of Microsoft services over nine years. (Note: Most of today's so-called remote buffer overflows require local human interaction to be successful, which does not qualify it as a remote exploit in my book.)

It's simply harder to pull of any buffer overflow today, much less a remote buffer overflow. Microsoft and other vendors have significantly improved the quality of the code and provided excellent proactive memory protections, including DEP (data execution prevention), ASLR (address space layout randomization), canary stack values, and chip-level NX/XD hardware protections. Even if you pull off a buffer overflow against a service, fewer of them are running as local system or root.

Worse than a boat anchor
Firewalls tend to be horribly managed. Almost no one reads the logs or responds to the events recorded. Who can blame us? The average firewall produces thousands of warning messages every hour. Who can find the valuable, actionable information in all that noise? Not me -- nor any firewall administrator I've ever met.

Worse, when I review firewalls, almost all of them seem to have horrible rule sets. I find so many firewalls with "ANY ANY" rules that defang the protection, it doesn't faze me anymore. Again, I'm not sure I can always blame the poor, misguided souls that have created those rules. Firewalls seem to interrupt many legitimate operations, and I know the frustration that led to those rules.

I've been there: "Just open the firewall up and let's see if that's causing the problem. Oh, that worked. OK, we'll get that app running, then come back and fix the firewall later." I'd be lying if I said this didn't happen once or twice in my career when I was a network administrator. These days, I have a hard time doing security reviews, patching, or other legitimate network management due to firewall problems.

1 2 Page 1
Page 1 of 2
FREE Download: Get the Spring 2019 digital issue of CSO magazine today!