Windows Firewall: the best new security feature in Vista?
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.
Comments
Anonymous
January 01, 2003
I was reading a ZDnet article today about the Vista firewall being hobbled because it apparently...Anonymous
January 01, 2003
Thousands of people from around the world have been hard at work to ensure that Windows Vista is the...Anonymous
January 01, 2003
For those of you in enterprises testing Vista, here are a couple resources from today’s blog reader....Anonymous
January 01, 2003
Jesper Johansson  is one of our Security Strategists and like all good evangelist, dishes out his...Anonymous
January 01, 2003
PingBack from http://www.keyongtech.com/3530890-firewall-installationAnonymous
January 01, 2003
Jesper has an interesting blog post discussing what he thinks is the best new security feature in Vista... the Windows Firewall. I am more inclined to say I like UAC better, but thats just me. Anyways, besides the excellent breakdown on the benefits ofAnonymous
January 01, 2003
PingBack from http://www.hilpers.com/58216-passwort-verwaltung/4Anonymous
January 01, 2003
Jesper Johanson (Senior Security Strategist in the Security Technology Unit at Microsoft) hat einen Blog Artikel über die neue Windows Firewall in Vista geschrieben. Alles in allem sind das interessante Features, und es wird klar, dass MicrosoftAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Segurança foi uma área que recebeu atenção especial no desenvolvimento doAnonymous
January 01, 2003
PingBack from http://technet.quebecblogue.com/2009/06/04/re-sygate-firewall-part-2-technology-questions/Anonymous
January 01, 2003
If you want to learn more about Windows Vista security features check out this page. There are a ton of good resources; webcasts, podcasts and videos. http://www.microsoft.com/events/series/technetvista.aspxAnonymous
May 01, 2006
This is the first time I've seen this information. So much focus from the press is on what Microsoft has pulled from the product. This post demonstrates that there is still a lot to the product that we have not seen yet!Anonymous
May 01, 2006
Where are the SIDs of the restricted services in your screen shot? I only see Apps and library names?
Gruss
BerndAnonymous
May 02, 2006
You are exactly right!. I think its a great post. Some of the things I found interesting..
--- Your comment --
In addition, as the dialogs above suggest, the vast majority of users are unable to make intelligent security decisions based on the information presented.
--- end your comment ----
I just don't think we as programmers present users with "information", we present them with 'data' something like "blah blah blah.. is blah blah blah" Think of this like driving a car, you don't need to be a mechanic in that case, versus you need to be pretty sophisticated computer user to use a computer 'securely'. I think we as an industry lack some new thought (of course I can't think anymore like a human after using computers for 10 yrs :) )
Also along the same lines,
--- Your comment ----the fact that Microsoft Word is attempting to make an outbound connection is not nearly
----- End your comment
I think MS as a company needs to get its act straight and stop programs from talking back (unless absolutely absolutely absolutely required). I (being an outsider), don't see any need for this, but I'm sure someone there has a 'realllllllllly (sic) good' reason for enabling this (?). If you look at the trends in the industry, somehow everyone now-a-days is obsessed with collecting 'data'. If there is something you can do to influence this..
--Vasu.Anonymous
May 02, 2006
yea sure and guess which one will be the most hacked and bypassed firewall in existance?Anonymous
May 02, 2006
Bernd, to be honest I have not investigated how the firewall retrieves the service SIDs based on what is in the registry, but I am guessing it calls LookupAccountSid to get them. That is the normal way to do it. Call that API, passing in "NT SERVICEservicename" for the name of the account. You can also get that information after the service is installed by calling QueryServiceConfig2 using the SERVICE_CONFIG_SERVICE_SID_INFO level.Anonymous
May 03, 2006
The comment has been removedAnonymous
May 03, 2006
What's about IPv6?Anonymous
May 04, 2006
I have used run Windows XP as non-admin user since 2003. I try to install applications I don't totally trust as non-admin. I would like a firewall to alert me when those programs are attempting outgoing connections. I would think an outbound firewall would work pretty well for those cases.
In cases where the application has suitable rights to disable the firewall or go around it, the app won't do that unless it is programmed to do so. Like you said, nowadays programs very rarely do that. So having an outbound firewall would buy some security still.
I do agree those dialogs rarely help ordinary users, and avoiding them in the first place is the way to go if possible.
By the way, you seem to imply Windows Vista will encourage users to run as administrators all the time which I find disappointing. I hope that is not really the case.Anonymous
May 06, 2006
The comment has been removedAnonymous
May 20, 2006
The comment has been removedAnonymous
June 15, 2006
The comment has been removedAnonymous
July 16, 2006
I love what Vasu said:
-------
I just don't think we as programmers present users with "information", we present them with 'data' something like "blah blah blah.. is blah blah blah" Think of this like driving a car, you don't need to be a mechanic in that case, versus you need to be pretty sophisticated computer user to use a computer 'securely'. I think we as an industry lack some new thought (of course I can't think anymore like a human after using computers for 10 yrs :) )
---------
I'm a "human" who tries to understand enough about computers to interpret for other humans --- I teach "computer basics" to seniors and job seekers at a community college.
Ordinary people have never really been the target audience for computers --- all the usability has responded to techie type early adopters. It's time for The Computer to mature to the point where there are no longer any intimidating dialog boxes. I don't think we're going that way yet, but it looks like more and more people are recognizing there are "humans" out there. Thanks, Vasu