Most personall firewall application fail in a very basic (and essential) aspect of their operation: giving the user a clear and concise way of identifying the software that is trying to access the network.

Even though this is widely known and has been discussed to death, it never really struck me until I installed the ADSL modem I recently got for free, courtesy of my telephonephone line operator.
The windows 2000 version of the modem driver starts up and greets me with this nice dialog box as soon as I log in into my computer:

Allowing “rundll32.exe” to always connect to the web is to be considered a safe practice or not?

How many users, when pestered with this annoying dialog popping up every day, are savvy enough not to dismiss it once and forever?

Please note that the standard version of the dialog message gives even less details about the outgoing connection than the screenshot pasted here, and only identifies the offending executable by filename: no path information, no version information, no nothing.

How many will take the time to properly configure the firewall to only let the offending driver connect to the local subnet?

Now, this is arguably a bad design decision on the part of the writers of the modem driver, but there is a much simpler and cleaner way for wannabe virus writers to bypass any security measure that personal firewalls provide blocking outgoing connections: simply use the web browser to connect to the web. Both IE and firefox are powerful enough to provide support for a variety of web protocols, as well as easy scripting interfaces, and one of those two has been durely flagged as “connect to the net without asking consent”, most likely both.

Everyday is a great day to learn something new…

Sometimes ago I had the incredible luck of supervising the installation of an “application-layer-firewall”.

It is, for those of you who never heard about it, a black-box device, usually using internally lots of open source software but nevertheless sold for big buck$, built to protect web server from being hacked. It achieves this goal by filtering all incoming HTTP requests (possibly outgoing responses, too), and blocking those that look suspicious enough / violate a defined set of rules.
Many of these devices offer a lot of extra functionality, such as providing HTTPS termination for those webservers that do not support it natively, rewriting of incoming requests etc… All in all, very useful boxes.

It is the very principle upon which they are built that left me baffled the first day we tried to configure ours, and it still has me unconvinced, namely that sloppy coding on part of the programmer can be overcome by adding an extra layer of black-box filtering that works without any knowledge of the functions implemented on the webserver.

I have been told umpteen times that the http firewalls follow the 80%/20% rule, warding off common attack vectors such as buffer overflows and escape sequences in urls, and this is useful enough by itself to justify their cost.

But in the modern-day internet, phising, xss and sql-injections attacks are more and more common, and while nobody is interested in defacing your site anymore, a lot of crackers are eager to get to your database where customer credentials are kept. And while http firewalls excel at the former, they are very poor at the latter.

(more…)