A while ago I wrote an article in my blog about the Windows Vista firewall. That post simply pointed out some of the nice features but did not offer up much in the way of deployment advice.
In this article, I go into more detail on some of the features in the Windows Vista® firewall that are specifically designed to ease enterprise management. And I will also be giving advice on how you can use them to make your job simpler and ensure your users are more secure.
With the recent release of SP1 for Windows Vista, you might expect enterprise deployment of Windows Vista to pick up. (It's common for enterprises to wait for the first service pack to be released before migrating to a new OS.) If you're one of the IT pros who are now looking a bit more seriously at Windows Vista for your enterprise environment, you should take a close look at the firewall. Once you realize what the Windows Vista firewall can do, you may want to renegotiate the agreement you have for that third-party security suite to remove the firewall from the package.
Windows Firewalls Then and Now
The firewall in the original release of Windows® XP left a lot to be desired. While it adequately matched the security functionality in commercial host-based firewalls at the time, it didn't add anything new or innovative.
The replacement that came in Windows XP SP2 was completely modified. It was specifically designed to ease enterprise manageability. The Windows XP SP2 firewall is very appealing in that it is lightweight, centrally manageable, effective, and unintrusive. But perhaps most important, it does something very critical: The Windows XP SP2 firewall protects the system at boot.
This last point is crucial. I have seen many systems in the past get infected during boot even with a firewall turned on. In fact, during the height of the Blaster epidemic, attack rates ran as high as one in four minutes. In other words, if you left an unprotected computer on the Internet it could have gotten infected, on average, in four minutes. And if you were relying on a firewall that did not protect the system at boot, 1 system out of 12 would have been infected at reboot. These figures were what drove Microsoft to ensure that the Windows XP SP2 firewall protected the system at boot.
In Windows Vista, the firewall received another complete makeover. The most obvious change, from a management perspective, is that the management interfaces of Internet Protocol Security (IPsec) and the firewall have merged. This is a very logical change. IPsec and the firewall are both designed to block things that are not allowed. The difference is that in the firewall, the parameters that define what is allowed are not very granular, while blocking or allowing large swaths of the address space in IPsec is cumbersome.
With the two features located in a single management interface, admins can make use of both technologies seamlessly, with less worry about whether something requires an IPsec rule or should instead have a firewall filter. In essence, you have a single view of the network attack surface of the system and this helps to minimize the risk of mistakes.
SP1 for Windows Vista adds some reliability enhancements to the firewall features. It also adds new algorithms, notably the Suite B algorithms, for use in IPsec. This is a set of encryption-related algorithms, comprising the Advanced Encryption System (AES), Elliptic Curve Cryptography (ECC), and Secure Hash Algorithm (SHA) 256 and 384.
Most importantly, however, Service Pack 1 adds support for Network Access Protection (NAP). NAP is a policy enforcement tool that ensures that managed and non-compromised clients are up-to-date with the latest security policies, updates, and anti-malware definitions before they are permitted to connect to the network. NAP cannot stop malicious hosts from connecting to the network, but it does ensure that all managed hosts are fully compliant so long as they are not actively compromised.
The Windows Vista firewall, called the Windows Firewall with Advanced Security, is also included in Windows Server® 2008. All the features are also manageable remotely and can be configured across a network using Group Policy.
Rule Types and Scenarios
The combination of firewall and IPsec functionality in the management interface means there are now two different types of rules: directional rules and connection rules. The directional rules are standard firewall rules that define which traffic to allow in the appropriate direction. The connection rules define the protection parameters for connections between computers. To draw an analogy, the directional rules are a bit like the firewall rules you know in previous firewalls while the connection rules are more like the IPsec rules used in conjunction with the firewall in Windows XP SP2.
By combining the firewall and IPsec into the same interface, several very interesting scenarios are enabled. For example, isolating systems from each other on the network is one of the most valuable security concepts available today. Microsoft calls this "Server and Domain Isolation."
Server and Domain Isolation uses both IPsec and firewall functionality. Recognizing this, the new firewall management interface includes specific functionality for isolation rules. These are appropriate if, say, you want to restrict the connection based on attributes of the source or destination systems, such as domain membership.
As you can see in Figure 1, the New Connection Security Rule Wizard starts out by asking what type of rule you want to create. If you select Isolation, the wizard preconfigures certain settings that are appropriate for an isolation rule.
Figure 1 Using the New Connection Security Rule Wizard to create an isolation rule (Click the image for a larger view)
You may also notice in Figure 1 that the isolation rule mentions health status. The rules used for Server and Domain Isolation are actually the same rules you use for NAP.
You can't enforce authentication for some types of traffic. For instance, you probably do not want to require authentication for DNS resolution. For the endpoints of that type of traffic, you need an authentication exemption rule. An authentication exemption rule is exactly what it sounds like—it exempts the traffic from IPsec requirements.
A server-to-server rule is a bit misnamed. While more commonly used with servers, it can also be used with clients. A server-to-server rule simply configures a connection to require authentication. This is different from an isolation rule in that not only does an isolation rule require authentication, it also requires fulfillment of some additional criteria, such as domain membership or health state.
A tunnel rule essentially defines a site-to-site Virtual Private Network (VPN) and the tunnel between the gateways. Tunnel rules are rarely used with Windows Vista, as it is unlikely that you will use Windows Vista in a gateway capacity. You can create fully custom rules. This lets you customize every parameter of the rule.
Rule Ordering
The rule ordering is a bit complicated at first glance. The key to understanding rule ordering is to first forget about ordering. It is not so much about ordering as it is about a matching selection. Consider inbound traffic as an example. Inbound traffic that does not match any rule that allows it is blocked by default. You may consider that as an ordering that says "Allow rules are considered first," but that assumption would be incorrect. If a specific packet is matched by both an allow rule and a block rule, the block rule will win. That means that the matching, in simple terms, is:
- Block rules. If a packet or connection matches one of these, it is discarded.
- Allow rules. If a packet or connection matches one of these, it is allowed.
- Default directional profile behavior. If no block or allow rules match, the traffic will be treated according to the behavior specified as the default for traffic in that direction in that profile. In the inbound direction in all profiles, that means blocking the traffic in a default configuration. In the outbound direction, by default, it means allowing the traffic in the default configuration.
The matching process is moderated by authenticated bypass (IPsec) rules. Using that type of rule, all authenticated traffic that matches the other parameters of the rule is permitted, regardless of whether it matches any other rules or not. Authenticated bypass rules are directional rules that have the Override block rules option selected, as shown in Figure 2. Those are considered first, so as to allow authenticated traffic to always reach the system. This is key to allowing you to easily allow traffic from authenticated hosts but block traffic from everyone else. You can consider that rule as 0 in the ordering. Thus, the complete rule order list looks like this:
Figure 2 Checking the Override block rules option to configure an authenticated bypass rule (Click the image for a larger view)
0. Authenticated bypass rules
1. Block rules
2. Allow rules
3. Default directional profile behavior
It does not really matter if there are multiple rules within each class that match the traffic pattern. As soon as any rule matches the traffic, rule processing stops.
Public, Private, and on the Domain
The new firewall has three profiles: public, private, and domain. The Windows XP SP2 firewall, on the other hand, had two network profiles: standard and domain. The domain profile is automatically invoked when the computer can find the domain controller. In Windows XP, the standard profile was used otherwise. This provided powerful functionality for a security admin who could lock the computer down completely when it was roaming and still allow all the remote management functionality that's necessary when on the organization's network. But this approach presented certain problems for some users—in particular, those with personal networks at home. Because the standard profile was always used if the system was unable to reach the domain controller, the system was locked down from the user's home.
The new private profile included in Windows Vista helps to resolve this issue. Now when you connect the system to a new network, it will ask whether that network is public (this is simply the new name for the former standard profile) or private and configure the system appropriately. The system remembers this each time it connects to that particular network, based on network parameters presented to it by the infrastructure servers on the network. This is not foolproof by any means, but it helps in that it allows more networks to be better locked down.
The detection logic for whether the system is on the domain has also been improved. The result is a faster, more reliable transition and fewer systems that think they should be using the public or private profiles when they are actually on the domain.
You can tie your rules to a particular type of network, preventing the system from volunteering too much information and trying to connect to systems on untrusted networks. This is one area where the integration of the firewall and IPsec starts to pay off.
Using these new rules, you can provide some restrictions that were not previously possible. For instance, for many years attackers have attempted luring attacks to get users to make Server Message Block (SMB)—for Windows networking—connections to untrusted hosts, thereby forcing an authentication sequence giving them a challenge-response pair that can be used to crack passwords. Older versions of this attack were also used to downgrade to clear text authentication or to reflect the user's challenge-response pair back to the originating computer. The former technique was broken years ago. The latter technique was mitigated with Windows XP SP2—but keep in mind that volunteering challenge-response pairs is nevertheless unwise.
To prevent this, you could use another new function in the Windows Vista firewall—outbound filtering. An administrator could decide, for instance, to block all outbound SMB connections (those terminating at ports TCP 135, 139, 445, and UDP 137, 138, 445) in the public profile. This would make it more difficult for a system to be used in a luring attack to gain challenge-response pairs, or prevent it from accessing untrusted Windows File Shares on the Internet.
Again, this is certainly not foolproof. For example, if the system has already been compromised, this rule would not stop the system from communicating out as the attacker could simply disable the rule. However, it can be very useful as a measure to protect well-behaving but potentially exposed systems.
It is important to mention in this context that, just like in Windows XP SP2, only one profile can be active at a time on Windows Vista and Windows Server 2008. If there are two network interfaces live in the system and one of them is on the domain while the other is on a public network, the public firewall profile will be applied to both. The most restrictive profile will always be used. As you might guess, the public profile is more restrictive than the private profile, and the private profile is more restrictive than the domain profile. So beware that the outbound SMB blocking rule can break much traffic over VPN connections.
To enable traffic over a VPN connection when the computer is on a public or private network, you create directional rules that apply only to VPN interfaces. For this to work, the VPN interfaces must be recognized as such by Windows. If you do not use the Microsoft® Routing and Remotes Access Services VPN server, test this functionality before deploying it widely. It is primarily a problem with inbound traffic to the client and any custom outbound rules you create.
Building Firewall Rules
Building a firewall rule is much easier in the new firewall. The New Rule Wizard, shown in Figure 3, allows you to define all the usual types of rules. And it includes predefined rules for particular services.
Figure 3 Predefined rules in the New Rule Wizard (Click the image for a larger view)
The predefined rules are particularly important. Server isolation is essentially about restricting services such that they are only available to those systems that need to use them. On server products, the Windows Security Configuration Wizard (SCW) can be used to make this easier, although still not quite pain free. (I discussed the SCW in the March 2008 issue of TechNet Magazine.)
But the client versions of Windows have not had similar functionality until now. When you use the predefined rule type, much of the hard work is done for you—the task of determining which endpoints a service uses. The firewall is not only application-aware in that it knows which program the "iSCSI Service" represents; it also contains predefined rules that describe certain functionality. This allows you to focus on which computers need to be covered in a rule. That is still a difficult and time-consuming task, but at least one that is unique to your environment.
There is also a custom rule (obscured by the dropdown in Figure 3) that gives you all the flexibility you can expect from an authenticating firewall. For instance, if you want a rule that only allows IPsec encrypted traffic, you would select the option to only allow secure connections on the Action page of the wizard shown in Figure 2.
When you select this, you also have the option to turn on encryption. If you leave this option blank, the traffic will use ESP-NULL (encapsulated security payload with a NULL key). This is the recommended way to use IPsec for authentication. It allows most network management tools to keep working because the traffic is traversing the network in the clear, and if you ever want encryption, you can simply check the box.
In many situations, encryption of network traffic is not nearly as important as not accepting any traffic from malicious hosts. Encrypting traffic on the network blocks a bad guy who has gained access to the network itself from seeing what is in the packet. Requiring authentication may prevent you from sending the packet in the first place and from getting attacked. Granted, there are many situations where network-level encryption is important, but there are also many other situations where you only need authentication.
Building Domain Isolation Rules
In most environments, you want a limited number of computers to be able to send traffic to a workstation. At the very least, all workstations should be configured with domain isolation rules. This was complicated in Windows XP, but it's easy in Windows Vista.
First, open the management tool of your choice and select the Connection Security Rules node. Then right-click on the node and select New Rule and you get the dialog shown in Figure 1. Select Isolation rule and click Next. You now have to select whether you want enforcement of the rule or not. In most cases on workstations, you will want to require authentication for inbound traffic. This prevents any computer that is not domain joined from sending traffic to the workstation. However, in order to request services from infrastructure services, the system must permit some outbound traffic to pass in the clear. The best option, therefore, is to require authentication for inbound connections and request authentication for outbound connections.
Next, pick the authentication method. The default selection is called, well, Default—not a particularly helpful title. You can configure the default authentication method on a per-computer basis in the IPsec properties (accessed by right-clicking on the Windows Firewall With Advanced Security node and selecting properties). The default authentication method is always Kerberos because this is the simplest and most secure. However, for clarity's sake, I recommend that you actually select it when you build your rules. Normally, you want to only authenticate the computer, not the user as well. If you require both, you may be unable to accept certain kinds of management traffic, such as anonymously transmitted SNMP traffic.
After you've selected the authentication method, all you need to do is select which profiles you want this rule to be available in. Because it is a rule that applies to domain joined computers, which can present a Kerberos ticket, it makes no sense to open this particular hole in either the Private or Public profiles. Save the rule, and you are done.
Basic isolation rules are not complicated any longer. However, to take advantage of the power of IPsec for isolation, you need to implement server isolation, even on your workstations. Doing so, you can restrict your workstations from listening to other clients. Instead, they will only respond to the appropriate management stations. Imagine how much less the impact of various malware breakouts would have been had client systems refused to listen to other clients.
Scripting the Firewall
The new firewall comes with a substantial API that allows you to script both deployment and assessment. Ideally, you should use Group Policy for deployment, but since Group Policy is not always available, it is important to have a proper API-set to configure the firewall. The APIs are grouped under the INetFWPolicy2 set of APIs. The Software Development Kit and the MSDN® Library contain more complete details on how to use them, but a few examples help illustrate the point.
One common sample is the need to determine whether a group of rules is turned on. Say, for instance, an application or administrator needs to determine whether file and printer sharing is allowed from a system. This can be accomplished through INetFWPolicy2::IsRuleGroupCurrentlyEnabled. Figure 4 provides a VBScript sample that demonstrates this function.
Figure 4 Using INetFWPolicy2::IsRuleGroupCurrentlyEnabled ' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")
' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules
'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes
'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if
Now, if file and printer sharing is off and you need to turn it on, you first need to ensure that this can be done and will not be over-ridden by Group Policy. This is done with the INetFWPolicy2::LocalPolicyModifyState API. A skeleton, which can be filled in with actual code, is shown here:
Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2
Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
Case NET_FW_MODIFY_STATE_OK
Case NET_FW_MODIFY_STATE_GP_OVERRIDE
Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select
Command-Line and Interface Types
No firewall would be complete without a proper command-line for management. There is a sub-context under netsh, called advfirewall. The advfirewall context gives you command line access to everything you can do in the graphical UI. For example, if you want to implement the outbound block on port 445, you can run the following command from an elevated command prompt:
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
You need to then run the same command, replacing TCP with UDP to complete the block. At that point, you have completed implementation of the rule.
One cool feature in the firewall is the ability to configure rules based on the network interface type. Recall that some rules may impact VPN connections. As long as Windows recognizes the interface as a VPN interface, you can use this type of rule to exempt traffic over that interface:
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
You can do this in the GUI as well, but not until after you create the rule. You then have to right-click on the rule, select Properties, and click on the Advanced tab. There you find an Interface types section where you can select the right interface types.
Outbound Filtering
The lack of outbound filtering in the Windows XP SP2 firewall was held out as the primary proof that the built-in firewall was inadequate for security. There must be thousands of articles written about how insecure the Windows XP SP2 firewall is due to its lack of outbound filtering. This is in spite of the fact that no firewall on Windows XP could securely provide outbound filtering.
The fundamental functionality that transforms outbound filtering into a useful security feature from a mere speed bump—or policy enforcement tool, as I used it earlier—simply does not exist in Windows XP. It does exist, however, in Windows Vista. It is only logical, therefore, that the new firewall makes use of this feature. By default, most inbound traffic is blocked and most outbound traffic is allowed.
By default, outbound filtering in the new Windows Vista firewall blocks only unnecessary traffic from services. This is actually all that can be done to provide protection against a compromise on the host that provides the outbound filters, and doing this on Windows XP would have been meaningless.
Services in Windows Vista can run with a highly restricted token. In essence, each service has its own security identifier (SID), which is unique to that service. This Service SID can be used to restrict access to resources, such as network ports. This is the same functionality we saw earlier when we looked at restricting traffic to users. This means that even though two services may run as NetworkService, they cannot manage each other's processes and the firewall can be configured to allow only one of them to communicate out. If the one that is blocked is compromised, it cannot hijack the allowed service and use its allowed port to communicate out because the port is restricted by Service SID.
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 the new firewall. However, there is no GUI to configure it. The rules are predefined in the HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices registry key. You should be very careful, however, with modifying that key manually, as this is unsupported.
How Much Security Can Outbound Filtering Provide?
A matter of significant misunderstanding in the security community is how much security value is actually offered by outbound filtering. I have mentioned two scenarios so far that provide security through outbound filtering, but both rely on new functionality in Windows Vista that was not previously available. In spite of this, there is a general perception that outbound filtering is generally good and should be a key factor in firewall purchasing decisions.
Ironically, in many organizations, outbound filtering capabilities drove the purchase decision, and then outbound filtering wasn't used once the firewall was implemented. This is misguided and leads to a waste of money and effort from the Information Security group. It seems to be driven more by a desire to feel good about doing something security-related than by actual analysis of a real threat. Far too often, the desire for this type of "security theater" drives decisions that should instead be driven by facts.
There is a very simple fact about outbound filtering that its proponents fail to take into account. The usual argument from the host-based firewall vendors is that if a system is compromised, whether by a worm or by an interactive malicious user, outbound filtering will stop the worm from infecting other systems or will stop the attacker from communicating out. This is not true.
What is true is that, all else being equal, outbound filtering would have stopped some historical malware. However, if Windows XP had come with outbound filtering, the worms we have seen so far would more than likely have been written to turn it off or else to circumvent it.
On Windows XP (and earlier versions of Windows), any worm running as a service (and all the common worms that come up in conversation did run as a service), could have done this. The only reason they did not is that there were virtually no environments using outbound filtering and therefore it was unnecessary to disable it. 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.
Circumventing outbound host-based firewall filters can be accomplished in several ways, depending on the scenario of the actual attack. The simplest way to go about it is to "ask" an over-privileged user to do it for you. Too many environments still run their users as administrators. Those users have the right to circumvent security policies at will. All the attacker needs to do is present the user with a choice between some intangible and non-immediate security benefit and something the user values more—the proverbial naked dancing pigs.
In many cases, the user has been so inundated with these types of dialogs that they quickly click without actually comprehending what is happening. This is problem number one with outbound filtering. Given the choice between security and sufficiently enticing rewards, like naked dancing pigs, the naked dancing pigs will win every time because the vast majority of dialogs asking users to make security decisions are devoid of any information that would enable them to actually make such a decision.
Presenting dialogs, asking for security decisions, with sufficient information to base that decision on is much harder than it sounds because it would require the security product, such as the firewall, not just to 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.
We need to reduce the number of meaningless dialogs, not increase them, and outbound filtering firewalls do not help with this. To get a feel for the state of the art in providing users with valuable information, I went and looked at the sales documentation for a major host-based firewall vendor. The glossies tout the firewall's outbound filtering capacity and advising capability. The advising capability detects what the user is trying to do and gives appropriate advice. Or so the theory goes. The text in the brochure was accompanied by a screenshot that says: "Advice is not yet available for this program. Choose below or click More Info for assistance." It seems that even in the marketing material, vendors can't produce informative dialogs.
Since users do not possess sufficient information to make the right security decisions, it would then be incumbent on the administrator to configure all outbound filtering because the end user is not able to. This increases the administration burden of the administrator infinitely.
Even if the user does click "No. Bug me again later" when asked by the firewall, the malware can usually step right around the firewall. As long as the user whom the malicious code is executing as can open outbound connections on some port, the evil code can simply use that port. Thus, any process can piggyback on an existing process. That is allowed on down-level operating systems. Starting with Windows Vista, the processes can be suitably restricted, which is why services, which are the ones that are restricted by default, are blocked using the outbound filters by default.
Unfortunately, most people think outbound host-based firewall filtering will keep a compromised asset from attacking other assets. That is not possible. 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 as effective as keeping them from breaking into the house in the first place.
Nessun commento:
Posta un commento