It is interesting how some of the best security features in Windows receive either no attention, or get criticized for the strangest reasons. Case in point: Windows Firewall is one of the best firewalls out there, and yet much of the talk about it are complaints that outbound filtering is disabled by default. I believe there are a lot of incorrect assumptions and outright myths about outbound filtering, but more about those further down. Let’s look at the positive side first.
I really like Windows Firewall in Windows XP Service Pack 2 (SP2). It is lightweight, centrally manageable, does the job well, is unintrusive, 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.
In Windows Vista, the firewall is getting even better. There are several new features, the most obvious being that finally the firewall is combined with IPsec. This makes a lot of sense. IPsec and the firewall fundamentally do closely related things. By combining them enterprises can administer the two using the same group policy interface and design policies that use the two in conjunction. In other words, enterprises that are implementing Server and Domain Isolation or Network Access Protection (NAP) will have more flexibility and a better interface for configuring it. Here is what the interface looks like in the recent builds:
The interface is specifically designed to make configuring Server and Domain Isolation and NAP easier. As I have said before, Server and Domain Isolation today, and NAP in the future, are two of the most promising security technologies we have. Integrating them into the firewall in this way is going to be tremendously powerful.
Another really great feature in the new firewall is that it can set rules based on three different types of networks. In Windows XP SP2 the concept of a domain and a standard profile were introduced. When a domain controller was reachable the system used the domain profile and when the domain controllers were not reachable the system used the standard profile. However, the administrator really had no ability to configure which of these were used on a particular network – all that could be configured was the ports and applications that were allowed on each. With Windows Vista there are three profiles: domain, private, and public. The domain profile works the same as it did in Windows XP, except that the detection logic has been much improved, resulting in a more reliable transition and fewer systems that think they should be using the standard profile when they are actually on the domain. The private profile is essentially new, and solves an important problem. Many of us have home networks, and we may want to be able to connect to a computer over particular protocols, such as SMB (Windows file sharing) on such networks, while blocking those protocols on public networks. However, there is no domain controller on those networks, so the domain profile cannot be used. In Windows XP our only option was to open those ports in the Standard profile. In Windows Vista we will be able to open them in the private profile, which does not expose them when we are at Starbucks, or the airport, because those networks would be public. When you connect the system to a new network it will ask you whether that network is public or private and configures the system appropriately and it remembers this each time you connect to that network. You can also configure domain isolation rules based on the network type, as shown in this screenshot:
Building a firewall rule is also much simpler in Windows Vista. The new rules wizard, shown below, allow you to define all the usual types of rules, and also contains pre-defined rules for particular services.
There is also a “custom” rule (obscured by the dropdown above) which gives you all the flexibility you can expect from a firewall. Of course, you can very easily configure exactly how the rule behaves. For instance, if you want a rule that only allows IPsec encrypted traffic, which you could do in Windows XP, but through several steps, you simply select the right radio button on the appropriate wizard page:
Here you can configure that only authenticated connections can use this port or program. It really can’t get much easier than that to configure Server and Domain Isolation.
There is much, much more in the firewall and in a simple blog post I just cannot describe it all. One very nifty feature is the ability to export and import rules. For example, consultants can build standard rule sets to provide particular types of functionality and then simply deploy those at multiple customer sites. I can see an entire consulting practice and partner ecosystem growing up around firewall rules.
Given all this, it is really unfortunate that all some people seem to be able to say is that, while the Windows Vista firewall “finally” provides outbound filtering, it is disabled by default (which is actually incorrect, see below for more details). This is then usually coupled with denigrating statements about how the Windows XP firewall does not provide outbound filtering and how this means nobody should use it.
Not only is the outbound filtering scenario that provides significant security value actually turned on by default in Windows Vista, but these claims also completely fail to account for a very simple engineering issue: 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, like this one, 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. What the user actually processes is a dialog that looks more like this:
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 of 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 NetworkService, 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. Aah, 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.
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. Below you see a screen shot of that key:
Without the ability to keep a compromised process from hijacking another process outbound host-based firewall filtering provides no protection from a compromised host. Because of the fact that Service SIDs were added in Windows Vista the firewall can actually provide meaningful protection with outbound filtering, but because Windows XP inherently lacks this ability having outbound filtering on Windows XP is meaningless from a security perspective.
This, of course, unless the objective is simply policy enforcement, in other words, attempts to stop non-malicious processes from accidentally communicating out. Some of that you can do with IPsec today, with no additional functionality needed on Windows XP. The new Firewall in Windows Vista will provide more complete desktop policy enforcement power to network administrators. This will allow them to write whatever filters they need to enforce their organizational policies, and, contrary to many Windows XP deployments, have better confidence that users will have a much harder time overriding them, since far fewer users need to run as administrators.