RSS Feed (xml)

Powered By

Skin Design:

Powered by Blogger

Monday, March 17, 2008

XP Firewall

Myth - "The Windows XP Firewall is not good enough because it lacks outbound filtering."

Reality - "I believe there are a lot of incorrect assumptions and outright myths about outbound filtering. I really like the Firewall in Windows XP Service Pack 2 (SP2). It is lightweight, centrally manageable, does the job well, is unobtrusive, and does something very critical: it protects the system at boot. That last one is crucial; we have seen many systems in the past get infected during boot even with a firewall turned on. Any outbound host-based firewall filtering in Windows XP is really just meaningless as a security feature in my opinion. True, it stops some malware, today, but only because current malware has not been written to circumvent it. There simply are not enough environments that implement outbound rules for the mass market malware authors to need to worry about it. In an interactive attack the attacker can circumvent outbound filters at will. To see how, consider this. Circumventing outbound host-based firewall filters can be accomplished in several ways, depending on the scenario of the actual attack. First, the vast majority of Windows XP users run as administrators, and any malware running as an administrator can disable the firewall entirely. Of course, even if the outbound filter requires interaction from the user to open a port, the malware can cause the user to be presented with a sufficiently enticing and comprehensible dialog, that explains that without clicking "Yes" they will not ever get to see the "dancing pigs". See, the problem is that when the user is running as an administrator, or the evil code runs as an administrator, there is a very good chance that either the user or the code will simply disable the protection. Of course, the user does not really see that dialog, because it is utterly meaningless to users. That is problem number one with outbound filtering. Given the choice between security and sufficiently enticing rewards, like "dancing pigs", the "dancing pigs" will win every time. If the malware can either directly or indirectly turn off the protection, it will do so. The second problem is that even if the user, for some inexplicable reason clicked "No. Bug me again" or if the evil code is running in using a low-privileged account, such as Network Service, the malware can easily step right around the firewall other ways. As long as the account the code is running as can open outbound connections on any port the evil code can simply use that port. Ah, but outbound Firewalls can limit outbound traffic on a particular port to specific process. Not a problem, we just piggy back on an existing process that is allowed. Only if the recipient of the traffic filters based on both source and destination port, and extremely few services do that, is this technique for bypassing the firewall meaningful. The key problem is that most people think outbound host-based firewall filtering will keep a compromised asset from attacking other assets. This is impossible. Putting protective measures on a compromised asset and asking it not to compromise any other assets simply does not work. Protection belongs on the asset you are trying to protect, not the one you are trying to protect against! Asking the bad guys not to steal stuff after they have already broken into your house is unlikely to be nearly as effective as keeping them from breaking into the house in the first place

No comments: