Personal Firewalls Mostly Useless, Says Mail & Guardian

hweimer writes "More and more security researchs come to the conclusion that personal firewalls are ineffective in controlling outbound traffic. An article in the Mail & Guardian online mentions a test that 'showed that the software often causes more problems than it solves. Not one of the six firewall programs the magazine tested, regardless of whether commercial or freeware, could prevent all attempts from the test programs at establishing outgoing connections between the PC and the internet.' Simple PoCs are available, too."

Comments

Told you so

[growse]

Well, that's what happens when you try and introduce a complex topic like network security into the consumer market, and subsequently fail at that task. They (the software manufacturers) fail not only in raising a suitable amount of awareness (if every single computer on the planet was behind a firewall, how many worms/malware would this stop?), but they also fail to do the job properly (not blocking outbound traffic) for those who do install their software.

Annoyance

[damaki]

Personal firewalls do not block outbound connection because it is a pain in the ass to decide what can pass or not. I mean, did you ever try some windows firewall that allows that? You get hundred of warnings from obscure services trying to send unknown data to somewhere you do not want to know. Users are clueless about it, they will just check the box that say "shut up and hack by box" if it prevents further messages from appearing.

Question

[geeber]

So if I have a hardware firewall in my router is a software firewall useful as a last ditch defense? Or is it nothing more than an annoyance and resource hog?

Re:Question

[SCHecklerX]

Software firewalls 'solve' the same problem as antivirus software. They attempt to disallow stupid users from doing stupid things. For the most part, if people don't install unknown/untrusted software on their PCs, and use safer alternatives for online stuff (gaim, firefox, sylpheed vs. aol's own messenger, MSIE, Outlook) along with practicing safe online computing in general, personal firewalls add the same value as antivirus software. None.

For a skilled user (which these aren't marketed to anyway), there is value in anlyzing what your software is trying to open outbound connections to, if you tell your PFW to alert you. In the hands of a skilled user, this is good information and the PFW is a good tool to analyze what software you may want to ditch or restrict. Again, this isn't the demographic most PFW vendors market to. You can't use a tool like this without a basic knowledge of how TCP/IP works. Then again, maybe that should be required knowledge for any user who connects their computer to the Internet. We need licenses to show we are competent enough to drive cars, and this is the "Information Superhighway" after all.

[OT] Re:Link to "printable" version of stories!

[Ma�djeurtam]

If slashdot, digg and friends were to link to printable versions, how long would it take for those sites either to remove the print version or to put their ads there?

Biggest problem with personal firewalls

[totallygeek]

Okay, we are talking about Windows users: they will simply click 'Yes' to anything that pops up on the screen.

Trivial to Bypass

[ThinkFr33ly]

I always get a kick out of people who set their firewall to prompt on every attempt to access the net, especially when they're running as admin on their boxes.

Even without the user running as admin, it's fairly easy to create a program to bypass outgoing firewalls. Basically the trick is it piggypack your communications over an existing application that's trusted.

Nearly everybody is going to trust IE (or Firefox, or whatever browser) to access the network. All you have to do is figure out a way to use that program to do your communications for you.

I once wrote a proof of concept app (in VB no less!) that used IE to do exactly this. I setup a simple piece of server software that accepted requests via HTTP GETs and returned the response as base64 encoded text in an HTML body. When my app needed to access remote data I just used IE to request that data from the server and then base64 decoded it. I could have also done something like have the server software act as a proxy so I could request any remote data I wanted, even if it wasn't hosted by my server. It was trivial.

The best part was that *every* major outgoing firewall failed to detect this attempt, despite that fact they claim to be able to tell when one application is using another to piggyback communications. Perhaps it was the way the COM interface worked, I'm not sure... but it never failed and never prompted me to allow it to happen.

ISP's hate firewalls

[phorm]

I love how, whenever I go to my grandparents to fix their computer (after they've dealt with their ISP's tech support) the ethernet cable is always running straight to the PC and bypassing the router. It's hard enough to get average Joe to understand the usefulness of a hardware routing/firewall device, but when the ISP is actively having them bypass it I can see a software firewall being somewhat useful at times.

Re:misleading headline

[dgatwood]

It also makes dynamic loading and unloading of device drivers impossible, which is why it doesn't make any sense for desktop system. Security can only be achieved through properly granting permission, not through outright avoiding granting permission. A scheme that is too restrictive will simply get turned off or worked around by the end users, and thus is not particularly useful, and indeed may actually be harmful to security because of developers making security assumptions that are no longer valid in such a situation.

Want to really improve security? Create multiple separate privilege sets in the kernel instead of a single "root". Make different executables setuid to a user with privilege sets that allow certain operations. Your kernel extension loader has sufficient privileges to load a kernel extension, but still can't write directly to kernel memory or listen on low numbered ports or access raw devices or bypass filesystem permissions. Your software that requires the ability to listen on low numbered ports doesn't get permission to bypass filesystem permissions or load kernel extensions. And so on.

Don't get me wrong, it's perfectly okay to have a "root" user, but no executable should ever be setuid root in such a scheme, and that root user should only be used for very limited administrative tasks.