Rocky Heckman (MVP - Security) posted a summary of a recent conversation on our local MVP discussion list. I agree with the thrust of Rocky's post. I'm just going to address a few additional points that were raised during the discussion.

a) Outbound filtering is good because bad guys don't try to bypass it.
True, they (the bad guys) don't at the moment. But this because there is so much low hanging fruit around at the moment. Why try to bypass outbound filtering when there are plenty of hosts that don't have this? When/if outbound filtering becomes popular, the bad guys will find ways around it. As long as there is money to be made in running spam-bots (or stealing information), the bad guys will do whatever minimum amount of work is required to make their money.

b) But if we educate users, they'll know how to stop the bad traffic going out
Maybe. Rocky mentioned some ways that bad traffic can hide itself. Most software firewalls will generate an MD5 checksum of each executable, so you can't just call your program iexplore.exe. But here's a few other ideas: register yourself as a service and run inside svchost.exe along with 20-30 other services. How is the user supposed to tell whether the traffic svchost.exe is sending out is good or bad traffic? They can't.

Another mechanism is simply to inject your malicious code into an existing running process like iexplore.exe. The user needs to allow iexplore.exe (or firefox.exe) access to remote ports 80/443, so these processes are generally free to send data to anywhere.

c) But my firewall alerts me when it's not working properly and/or you can't stop my firewall without supplying a password. Won't that stop the bad stuff?
As long as the user is in ultimate control of the PC, then the bad code can do whatever the user can do. Which includes stopping services, agreeing to any dialogue prompts, changing the system binaries, hooking the interrupt dispatch table (IDT) and system tables, and so on (well, under 64bit Windows, the last two are no longer available to unsigned code).

d) So, is egress filtering useless then?
Not entirely. The question is: does it provide more value than it costs to maintain? At the moment, for a reasonably tech-savvy user, the value is probably greater than the cost.

However it is important to understand that running a software firewall on a compromised host is, ultimately, a losing proposition.

I realise there is no such thing as "proof by analogy", but here's an analogy anyway. Suppose your Cisco PIX was compromised. Do you think anyone would say "Our PIX still has outbound rules enabled. We'll be OK"? No way! Every Cisco admin would say "Our Cisco PIX is compromised, and we can no longer rely on it to provide firewall capability" Why is running a software firewall on a compromised Windows host any different? In my opinion, it's not. For the time being, as part of a defense-in-depth strategy, it provides some value. But down the track, that value will continue to erode.

e) So what's the answer?
There is no single answer, otherwise we would have solved the whole security problem long ago! You've probably heard the phrase "security is a process, not a product". If you remain vigilent, practice safe-computing and follow best practise, you (most likely) won't get compromised in the first place. Using a firewall is part of that process, but it isn't the panacea that a lot of people make it out to be.

One of the fundamental equations in the whole security arena is working out (a) the cost of a compromise and (b) the risk of that compromise happening. You multiply the two together to get some risk-weighted cost. If the cost of implementing a mitigation is less than the risk-weighted cost of a compromise, you implement the mitigation. If you're implement a software firewall, there's a cost involved in maintaining it (e.g. in agreeing to all the prompts that it throws up, and in making sure that it's still working and hasn't been subverted). Now compare that to the risks that it mitigates (possibly preventing other machines on your network being infected, or running up a large ISP bill if your ISP charges for uploads). Is it worth implementing? Only you can decide.