New Features
The firewall in Windows Vista is a completely different beast. It is actually just one possible implementation on top of a comprehensive, extensible filtering platform; an implementation that happens to have a lot of useful features. This is an important distinction as much of the work really went into the underlying platform not the firewall itself. To understand just how fundamental these changes are, we will look at the new features, starting with the Windows Filtering Platform (WFP) that underlies the firewall itself.
Windows Filtering Platform
WFP is the underlying filtering platform used by the firewall. To understand how it works, we show a block diagram in Figure 1.
As Figure 1 shows WFP has both kernel mode and user mode components, and permits easy filtering at both layers. Previously, firewalls would have to perform some odd hooking tricks to see traffic before it got too far up the stack. The actual user interfaces (UI) for the new Windows Firewall are on top of the picture, in user mode. (Note that the picture refers to it as "Windows Personal Firewall UI." That was the old name used during development. It is now called simply "Windows Firewall UI.") Underneath that we see the base filtering engine. The filtering engine stores its configuration data in registry. The figure also shows several user mode filters. Those are used to filter application traffic, such as RPC.
We also see a filter engine in the kernel. Both native features and third-party tools can register callout functions with the filter engine. These will be called when certain events occur, at which point they can inspect the traffic and decide to take action on it. The action they take can block, or conditionally block (as long as no other filter specifies to definitely allow), or allow, or even modify the traffic. For instance, as the picture shows, a third-party antivirus product could create a kernel mode filter callout that inspects inbound traffic for viruses, before the application that requested the data even sees it. This incredibly powerful functionality is what the Windows Firewall is using. The hope is that third parties will extend it further with new types of filters.
The filtering engine, as indicated previously, works at many different layers. For instance, a particular filter could ask for packets only at the network layer, or only at the transport layer, or only UDP packets. A filter could also ask for only the first packet in a connection, or for all packets at the application layer, using the new Application Layer Enforcement (ALE) filters mentioned previously. This enables Windows Vista, and by extension, Windows Longhorn Server, to very easily be extended with application layer firewall functionality. It is not at all inconceivable that third-parties could write stateful inspection filters for HTTP packets for Windows Vista, for instance. The new filtering architecture is extensible enough to support many new and interesting features and it only makes sense to provide these types of well-defined hooks to perform filtering.
IPv6
Note that Figure 1 includes IPv6 in the stack. The WFP includes filtering for IPv6 and consequently the Windows Firewall protects the IPv6 stack as well. This is critically important as IPv6 is enabled by default in Windows Vista. Regardless of which firewall product you use on Windows Vista, you need to ensure that it can handle IPv6 traffic as well.
Integration with IPsec
Another epiphany that must have occurred during the development of Windows Vista was when someone looked at IPsec and Firewall and thought "Hey, these really do the same thing."
This is really simple, actually. A firewall defines over which ports traffic can pass into and out of a network or a computer. IPsec defines under which conditions that traffic may pass. It is a really natural extension of a firewall to use IPsec to further control traffic.
In Windows XP SP2, the firewall supported an "authenticated IPsec bypass" filter. The filter took a Security Descriptor Definition Language string that defined which group of computers were exempted from the firewall restrictions, all of them, and were instead subjected only to IPsec restrictions. You then had to build the IPsec rules to implement exactly the policy you wanted, which turns out to be non-trivial.
In Windows Vista, instead, IPsec filters can be configured directly in the firewall UI. When you build a firewall rule you can specify whether to require the traffic to be authenticated or authenticated and encrypted, as seen in Figure 2. Note, however, that you must still build a corresponding IPsec rule to specify how exactly the encryption and authentication happens. The IPsec filter is not created automatically when you create the firewall rule.
This integration with IPsec is quite logical and reasonably done. If you have ever struggled with IPsec in earlier versions of Windows, you will find this an immense improvement. Still, we wish there was an integrated way to build both the connection and the security rules. We will come back to the topic of IPsec integration later in the chapter.
Stealth
The Windows Firewall has a stealth feature that is on any time the firewall is active. The stealth feature is used to combat a method attackers often use to portscan (see sidebar) through firewalls. If a TCP port on a host is listening and a remote computer tries to connect to it, the connection will result in a standard TCP handshake, and the portscanner will report an open port. However, if the host is not listening on the port, the host returns a TCP RST (reset) message to the host that tried to connect to it. If a firewall in front of the host is configured to let a port through, but the host behind the firewall is not listening on it, the resulting reset tells an attacker that the firewall is configured to allow a particular port through.
The Windows Firewall in Windows Vista includes a stealth feature that blocks these RST messages outbound. If a message is sent to a UDP port or a non-TCP/UDP socket that is not listening, an analogous "nobody home" message is generated, and the firewall blocks these as well. This means that if the Windows firewall is allowing some traffic through and an attacker tries to portscan through the firewall, even if the firewall is configured to allow traffic to a port that does not have a service listening, the attacker will not see any indication of this.
Boot Time Filtering
One of the greatest shortcomings of ICF, and of virtually every third-party host-based firewall at the time and to this day, is the failure to protect the system at boot. One of the authors (Jesper) will never forget the moment, during the height of the Blaster worm outbreak in 2003, when some executives at Microsoft, extremely frustrated for understandable reasons, exclaimed that they could not understand how computers, unpatched as they were, which were demonstrably running with ICF enabled, could get infected. Jesper explained that it had to do with the lack of boot time filters. During the height of the Blaster worm outbreak in 2003, infection rates were running as high as one every four minutes. A computer at the time took about a minute or so to boot. The network interfaces went live early in the process, whereas the firewall, being a fairly high-level process, went live much later. The interval between when the network interfaces went live and when the firewall came up might be up to 20 seconds, or even more in some cases. With very simple math, we realize that a computer would get infected around one reboot in 12. Put another way, if you rebooted 12 computers, all running ICF, statistically one would get infected.
To address this issue, boot time filters were added in Windows XP SP2. In Windows Vista, the boot time filters were implemented in WFP. When the computer boots, the following happens:
-
Machine boots, with no networking active.
-
The networking stack starts up and starts the WFP driver.
-
The network goes live and the WFP boot-time filters are in effect.
-
The base filtering engine (BFE) service starts and replaces the boot-time filters with persistent filters, stored in the BFE rule store.
-
The Windows Firewall service starts and reads the current policy settings, determines the current profile, and allows additional traffic.
The boot-time filters and the persistent filters are identical. The main reason two sets of filters are used so that BFE can retrieve its filters from only one place. They both:
-
Block all unsolicited inbound traffic.
-
Allow inbound traffic from any loopback address.
-
Allow inbound ICMPv6 neighbor discovery. Neighbor discovery is used to map IPv6 addresses to medium access control (MAC) or Ethernet addresses, and hence performs the same function as the Address Resolution Protocol (ARP) in IPv4.
When Windows Firewall goes live, in Step 5, it applies additional filters which allow additional traffic, based on the current profile. The persistent filters, however, are still there while the firewall is enabled. Only if the firewall is disabled do the persistent filters disappear. This means that if, for any reason, the firewall service dies, the persistent filters are still there and block all inbound traffic. In other words, Windows Firewall is designed to fail closed! There are very few other software firewalls that actually have the ability to fail closed.
Strict Source Mapping
In UDP, and portless protocols, there are no session semantics, and hence it is difficult to prevent a third party from taking part in a session.
For instance, if host A sends a UDP request to host B, host A will accept responses from any host that can respond on the requested port and protocol within a certain time limit (typically 60 seconds). This is called "loose source mapping" (LSM).
In Windows Vista, Windows Firewall uses strict source mapping. That means that it maintains a table of UDP and portless requests, and in order for a response to be allowed through it must match not only the protocol and port (for UDP) but also the IP address used in the original request. This is what is known as Strict Source Mapping (SSM). It is an attempt to bring session semantics to protocols that inherently have none.
The Domain Name System (DNS) protocol, and certain other protocols as well, requires an exception to the SSM rule. With DNS it is possible that the request was forwarded to a different server and the response will go from that server directly to the client. In this case, the reply is not coming from the host the requestor originally sent the request to, and if SSM is used, the response would be dropped by Windows Firewall. To prevent this, DNS has a special exemption to permit LSM in the default firewall ruleset. However, this opens the computer up to an obvious attack whereby an attacker would listen to DNS requests and respond with malicious data before the legitimate DNS server gets a chance to. To stop that attack the DNS client in Windows Vista is configured only to accept DNS responses from servers in its DNS server list. In other words, it will accept DNS responses from any server in its DNS server list, regardless of which one it sent the query to.
Service Hardening and the Firewall
With Windows Service Hardening, it is now possible to restrict ports based on services. For instance, a firewall policy might restrict the RPC endpoint mapper to only listen on port TCP 135, and not allow it to connect out on any other port.
Such a policy was impossible to enforce on Windows XP, with the built-in firewall and with any third-party firewalls. Even if a firewall were to attempt to detect which process was accessing the port, this was trivial to circumvent. The process would simply find another process that was allowed to do what the malicious process wanted to, and which was running in the same service context. It would then hook the service with a debug API, inject whatever code it wanted into it, and the other service would then do the malicious process' bidding. In Windows XP, any process can debug any other process running in the same user context. That meant that keeping a compromised service running with a system account isolated was impossible. With 69 services running as LocalSystem by default, it was trivial to find some process that could do what you wanted. Of course, if a process is running as LocalSystem, it is omnipotent on the computer, under Windows XP.
In Windows Vista, this is no longer the case because of Service Hardening. With Service Hardening, the ACL on a process can include the Service SID and the RESTRICTED SID. As long as the process token of the malicious service, which presumably is one that has been hacked, is a restricted token using the service SID as the restricting SID, it will not be able to debug the victim process unless its restricting SIDs grant it permission on the victim process. In other words, taking over another process to do the evil bidding of a compromised process just got a lot more complicated. This means that ports can meaningfully be restricted to specific processes, as long as those processes are pre-configured with the right ACLs.
IPv6
Windows Firewall supports something that is currently, unfortunately, unique among host-based firewalls: IPv6. As you probably know, IPv6 is the long-awaited replacement for the current IPv4, which is the network protocol underlying the entire Internet today. IPv6 is not only supported in Windows Vista, it is installed, and even turned on, by default.
IPv6 changes significantly how we think about networking, but as far as firewalls are concerned, the first thing that changes is that you have to consider what happens when IPv6 is encapsulated in IPv4. The Windows Firewall is designed to handle that, as well as putting restrictions on native IPv6 traffic.
Outbound Filtering
More than any other feature, the lack of outbound filtering in the Windows XP SP2 firewall was held out as proof positive of why it was inadequate for security. The number of articles written about how insecure it is to use the Windows XP SP2 firewall because of its lack of outbound filtering must number in the thousands. This is in spite of the fact that no firewall on Windows XP could securely provide outbound filtering. The fundamental functionality that turns outbound filtering from a mere speed bump into a useful security feature-Service Hardening-simply does not exist in Windows XP. It does exist in Windows Vista.
Without service hardening, outbound filtering is useful only as a friendly suggestion that the end user might want to avoid certain destructive behavior. Any program executing on the computer can send outbound traffic on any port to any host. Service hardening changes that, and enables the Windows Vista firewall to provide meaningful outbound filtering. By default, most inbound traffic is blocked, and most outbound traffic is allowed, but many services have outbound traffic restricted by default.
Outbound filtering in Windows Vista is designed for two purposes:
-
Filtering of outbound connections for services.
-
Pin-point filtering of specific types of traffic by administrators, such as blocking outbound SMB traffic in the public profile, as we discuss later.
These are the two types of outbound filtering that actually provide useful security value, although a user running as an administrator, or code running on that user's behalf, can easily undo either or both of them. In making this design decision, Microsoft has taken the quite reasonable, and possibly even admirable, approach not to take the same path that virtually every other firewall vendor has taken.
How Much Security Can Outbound Filtering Provide?
Windows Vista blocks unnecessary/undesirable traffic originating from many services by default. Many articles in the popular press have already decried the fact that outbound filtering is off by default in Windows Vista. Those articles are, as you might expect, wrong. Not only is outbound filtering on by default, but there are 82 default filters that prevent 34 services from communicating out other than on a very narrow set of defined ports.
There is no GUI to configure the default filters. The filters are not actually even visible in the GUI. Currently, the main management interface is the COM scripting tools. For read-only purposes the default filters are listed in the registry, at HKLM\System\CurrentControlSet\Services\SharedAccess\ Parameters\FirewallPolicy\RestrictedServices\static\system.
Please note, however, that this registry location should be considered undocumented and can change. You should not edit the filters directly in the registry. Use the COM scripting interfaces, if you believe you need to modify them.
A matter of significant misunderstanding in the security community is how much security value can be had by outbound host-based firewall filtering. We have mentioned two scenarios so far that provide security through outbound filtering, but both rely on new functionality in Windows Vista that has not been previously available. In spite of this, there is a general perception that outbound filtering is general goodness, and should be used by everyone, even on operating systems prior to Windows Vista. It is also believed that it should drive firewall purchasing decisions. This is misguided and leads to a waste of money and effort from the security team.
These arguments are fueled by the fact that many firewall vendors have chosen to attempt to mislead customers by greatly hyping and overstating the value of outbound firewall filtering. No firewall can discern program intent. Also, a firewall cannot conclusively retrieve the name of the host the connection is going to. Therefore, when a firewall prompts a user to accept or deny a connection, the prompt typically looks like this:
Program foo attempted to connect to port 48734 on 2001:0:4136:e388
:244c:96e:3f57:7cb3. Do you wish to allow this?
The user has very little chance of making an intelligent decision based on that information. The Windows Vista Firewall does not present any popup dialogs for blocked outbound filters. The two usage scenarios Microsoft focused on do not require user consent; nor is it even desirable. Unfortunately, Microsoft is apparently not as coordinated as one might hope, nor as well informed in all the different groups. Contrary to the quite reasonable design implemented by the Windows Vista team, the Live OneCare team has taken the exact same approach as all the other firewall vendors. They built a firewall that asks the user to make important security decisions at runtime, typically based on data that does not provide sufficient information to enable the user to make an intelligent decision.
There is a very simple fact about generalized outbound filtering that its proponents fail to take into account. Their argument usually goes that if a system is compromised, whether by a worm or by an interactive attacker, outbound filtering will stop the worm from infecting other systems, or stop the attacker from communicating out. This is simply not true. What is true is that outbound filtering, all else being equal, would have stopped some historical malware. However, if Windows XP had come with outbound filtering, the worms we have seen so far would have simply been written to turn it off. On Windows XP and below, any worm that runs as a privileged service, which all the worms that come up in conversation did, could have done so. The only reason they did not is that there were simply not enough environments that used outbound filtering.
Outbound filters also do not help in an interactive attack, where the attacker can react on the fly to how the system is configured. In an interactive attack, the attacker can circumvent outbound filters at will. If the attacker has the ability to run arbitrary code, this is easy, but if necessary, the attacker can also lure the user into circumventing the filters by presenting a sufficiently enticing dialog box.
Figure 3 shows the dialog box a user would get when an application attempts to establish an outbound connection. It is an undoctored screenshot of what happened with a very popular personal firewall product when we tried to make an outbound connection using the very popular tool netcat. Of course, the statement that "nc.exe is attempting to connect to a DNS server" is based entirely on the connecting port number. The prompt would be the same if I had a different service listening on port 53 UDP.
Look closely at the dialog box in Figure 3. Not only would the vast majority of users have no idea how to respond to this prompt, the default action is to "Always allow connections from this program on all ports." If the user were to simply click OK, as just about anyone would (because a connection to a DNS server is generally benign), the firewall would create a rule that allows this program to always connect out. In this case, the user would not ever see the next dialog box, shown in Figure 4.
The dialog box in Figure 4 is the one that actually tells the user, or rather, the small percentage who know how to decipher it, what is actually happening. By attempting a largely benign connection initially, the user would be tricked into the default action of always allowing the program. After that formality is over the program can proceed and take the actually malicious action. A truly malicious program could obviously take advantage of that. Furthermore, what exactly is it that the firewall considers malicious about connecting to port 80? The program may be retrieving a cool game, checking the local time, or uploading a list of all your credit card and bank account numbers. As mentioned earlier, no firewall can discern program intent.
The dialog box in Figure 3, and even the one in Figure 4, is emblematic of a much bigger problem: the computer industry has done an extremely poor job of giving users information they can use to make intelligent security decisions. Imagine that your users can't think of anything more important than seeing naked dancing pigs. Consequently, they spent all morning searching BitTorrent, The Pirate Bay, and Morpheus for various (malicious) programs that show naked dancing pigs. Given the choice of naked dancing pigs, and some obtuse, incomprehensible dialog box espousing an unstated security benefit that the user is not given any information to understand, the user will with near 100 percent probability select the certain benefit of the naked dancing pigs. Particularly because if the user has used the computer for any more than about 37 seconds with the outbound firewall turned on, the user will have been so inundated with these dialog boxes that they have become nothing more than a fast-clicking exercise standing in the way of the proverbial "naked dancing pigs." This is the number one problem with outbound filtering.
Presenting dialog boxes asking for security decisions with sufficient information to base that decision on 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 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, but you do not know that upon connection establishment.
We need to reduce the number of meaningless dialog boxes, not increase them, and outbound filtering firewalls do not particularly help there. While writing this chapter, we went and looked at the sales documentation for a major host-based firewall vendor. They tout their firewall's outbound filtering capacity and the new advising capability, purported to give information to the user to make intelligent security decisions. In the product glossy, there is even a screenshot that proudly proclaims, "Advice is not yet available for this program. Choose below or click More Info for assistance." Below that are two buttons with the texts "Allow" and "Deny." It seems that even in the marketing material, the vendors cannot produce informative dialog boxes.
The fact that users do not possess sufficient information to make the right security decisions means that it is incumbent on the administrator to configure all outbound filtering because the end user will not be able to. This increases the administration burden of the administrator infinitely. It is virtually impossible to develop a reasonable set of outbound restrictions unless we have multiple firewall profiles, and are willing to make very broad generalizations that may impact functionality for many users.
The second problem with outbound filtering is that even if the user, for some inexplicable reason selected the "No. Bug me again" option in the dialog box (also known as "Block this program"), the malware can attempt to step right around the firewall. In Windows XP, where every process running in a particular user context had full access to all other processes running as the same user, this is trivial. As long as that user can open outbound connections on any port the evil code can simply use that port. Even if the firewall limits connections to a certain process, the kernel functionality to truly enforce this does not exist on Windows XP, only on Windows Vista. This allows any process to piggy back on an existing process that is allowed. Of course, in Windows Vista, the processes can be suitably restricted, which is why services are blocked using the outbound filters by default.
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 anything 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.
This, of course, holds unless the objective is simply policy enforcement, meaning attempts to stop non-malicious processes from accidentally communicating out. That is basically what we will do later when we show you how to block SMB outbound in the public profile. However, unless you have access to multiple profiles doing those types of things becomes impossible. It is only meaningful to block outbound SMB when the computer is off the organizational network. If you do so when it is inside the organizational network the computer becomes only marginally useful. Besides, if you can make general blocks across profiles you do not need an outbound filtering firewall. That functionality is available in Windows XP through IPsec.
|
