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.
In addition, as the dialogs above suggest, the vast majority of users are unable to make intelligent security decisions based on the
information presented. Presenting information that does allow them to make intelligent decisions is much harder than it sounds
because it would require the firewall to not just understand ports, protocols, and the application that is making the request, but
also to understand what it is the request really is trying to do and what that means to the user. This information is very difficult
to obtain programmatically. For instance, the fact that Microsoft Word is attempting to make an outbound connection is not nearly as
interesting as what exactly Word is trying to do with that connection. A plethora of dialogs, particularly ones devoid of any
information that helps an ordinary mortal make a security decision, are simply another fast clicking exercise. We need to reduce the
number of meaningless dialogs, not increase them, and outbound filtering firewalls do not particularly help there. While writing
this article I went and looked at the sales documentation for a major host-based firewall vendor. They tout their firewall's
outbound filtering capacity and advising capability with a screen shot that says "Advice is not yet available for this program.
Choose below or click More Info for assistance." Below are two buttons with the texts "Allow" and "Deny." Well, that clarifies
things tremendously! My mom will surely understand what that means: "Unless you click 'Allow' below you won't get to see the naked
dancing pigs that you just spent 8 minutes downloading." I rest my case.
Fundamentally, it is incumbent on the administrator to configure all outbound filtering because the end user will not be able to,
and once the administrator does that, if there are enough systems using the same protection mechanism, automated malware will just
adapt and exploit the weaknesses mentioned above.
Now, given what I just said about outbound filtering, why is it even included in Windows Vista? Here is why: there is one particular
area where outbound host-based firewall filtering provides real security value, but only in Windows Vista. In that operating system,
services can run with a highly restricted token. In essence, each service has its own security identifier (SID) which is unique to
that service and different even from the SIDs of other services running in the same account. This Service SID can be used to
restrict access to resources, such as network ports. What that means is that even though two services run as NetworkService, they
cannot manage each others processes and the firewall can be configured to allow only one of them to communicate out. If the other
one, the blocked one, is compromised, it cannot hijack the allowed service and use its allowed port to communicate out. This
functionality is another one of the very cool security features added to Windows Vista, and the new Firewall uses it to actually
provide real security value by outbound firewall filtering. In fact, firewall filtering on service SIDs is enabled by default in
Windows Vista. The rules are predefined in the
HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices registry key.
)