| Downloads |
|---|
| 97679.zip |
Executive Summary:
| You can prevent Windows Vista from creating default rules in the new Windows Firewall: Simply create your own secure rules before running the application. Our VBScript scripts help you add rules and enable and disable the firewall. Enabling and disabling the firewall are particularly helpful when you're deploying a new application. Another useful feature of the new Windows Firewall is the MMC Windows Firewall with Advanced Security snap-in, which provides a convenient interface for examining firewall rules. Learn how to launch the snap-in, as well as how to produce a filtered view. |
Windows Vista includes a completely redesigned software firewall, Windows Firewall with Advanced Security, which is notable for its improved manageability—first, because of its powerful scripting interface, and second, because of its new UI, the Microsoft Management Console (MMC) Windows Firewall with Advanced Security snap-in. I'll discuss the scripting interface and examine three sample scripts you can download to help you better manage this new firewall. Then I'll walk you through the Windows Firewall with Advanced Security snap-in to show you how you can examine and manipulate firewall rules in a variety of ways.
A Quick Primer on the Windows Firewall API
Windows Firewall is based on a new low-level network-filtering API called the Windows Filtering Platform. Although the Windows Filtering Platform API isn't the topic of this article, I mention it here because it lets ISVs use the same facilities offered by the OS as those used by internal security features (such as the built-in firewall), which is good news for the IT security community. As a result, we should see some compelling third-party network security products become available for Vista and Windows Server 2008. (To learn more about the Windows Filtering Platform, go to http://www.microsoft.com/whdc/device/network/WFP.mspx. You can find information about Windows Firewall at http://technet.microsoft.com/en-us/network/bb545423.aspx.)
Default Firewall Rules and Deployment Challenges
System administrators are frequently called upon to support legacy applications in a changing environment. The deployment of an OS update is one of the better-known, and perhaps toughest, examples of this challenge. The challenge exists for client as well as server updates.
Vista is a great example of a deployment challenge, as it includes some features that, while compelling, are known to introduce application compatibility risk. However, the built-in firewall feature need not be a source of headaches. In fact, given that the firewall allows all outbound traffic by default, it's unlikely to be a source of compatibility trouble in most scenarios. Still, there are server and peer-to-peer applications that, to function correctly, need to listen on a network port for inbound traffic.
Suppose you're faced with deployment of such an application on Vista or Server 2008. You might have already noticed that, when the application is run for the first time, Windows automatically launches a security dialog box offering to create default firewall rules. (In fact, default rules will be created regardless of which option you select in that dialog box. Selecting Keep blocking or pressing ESC results in default Block rules; selecting Unblock results in default Allow rules.)
What you might not be aware of is that the default Unblock/Allow rules aren't very secure. The good news is that it's easy to prevent the OS from creating default firewall rules: Simply create your own secure rules before running the application. For example, Microsoft provides a sample server application called stcpserver.exe (short for "Secure TCP Server") in its Windows software development kit (SDK). The purpose of stcpserver is simply to open and listen on a socket bound to a preconfigured network port (the default is port 27015). Figure 1 shows the default rules that result from running stcpserver for the first time on a Vista workstation and then clicking the Unblock button in the Windows Security dialog box.
For complete functionality, stcpserver requires only inbound TCP traffic to be allowed on a specific port. But, as Figure 1 shows, the default rules allow UDP and TCP traffic, and they let the application receive traffic on any port—which is overly permissive. The default rules need to be carefully reviewed, and usually replaced, in order to prevent a misbehaving application, or unexpected network traffic, from compromising the host.
Creating Your Own Secure Firewall Rules
In fact, the network traffic requirements of stcpserver can be met via a single firewall rule. Furthermore, you can use VBScript to automate the creation of such a rule, as Listing 1 shows. The most interesting portion of the script in Listing 1 is where the various properties of the new firewall rule are set. Let's discuss each of those properties in turn, since they’re likely to be application-specific.
The first value set is the firewall rule Name property. The value used corresponds to the name of the application binary without its extension. The Name property is set to “stcpserver” in this example, as we want to preempt creation of the default rule for stcpserver. It’s important to note that you must use the correct application name or Windows will still attempt to create a default rule set when running the application for the first time.
The second property set by the sample script is ApplicationName, which should correspond to the target program's full application path, including the binary name with its extension. This property serves an interesting purpose from a security perspective, as it prevents an application with the same name but in a different location from listening on the specified port.
The third property is RemoteAddress, set in Listing 1 to LocalSubnet. Use of this value implies to the underlying firewall rules engine that only traffic originating on the same subnet as the host will be allowed (assuming the other rule properties are satisfied as well). This property allows a variety of useful values, including specific addresses and ranges; see the Microsoft article "RemoteAddresses Property of the INetFwRule Interface" at http://msdn2.microsoft.com/en-us/library/aa365366.aspx for more information.
The fourth property is Protocol. The value 6 is used in this example, corresponding to TCP. The most common alternative, UDP, corresponds to value 17.
The fifth property is LocalPorts, set in Listing 1 to a specific port, 27015. Like the RemoteAddress property above, the LocalPorts property accepts other values that have special meaning. For example, it’s possible to target remote procedure call (RPC) ports, which are dynamically allocated. For more information, see the Microsoft article "LocalPorts Property of the INetFwRule Interface" at http://msdn2.microsoft.com/en-us/library/aa365362.aspx.
The sixth property, Grouping, is set in this example primarily to demonstrate another manageability feature of the firewall API. Unlike the previous properties, group name (if any) has no effect on the security posture of the firewall rule. Instead, it lets you manage one or more rules, either via script or via the firewall's MMC snap-in, as a group. Suppose an application requires both TCP and UDP traffic via a given port. To enable this application with a strict rule set, two rules would be required—one with Protocol set to 6 (TCP) and one with Protocol set to 17 (UDP). By setting the same group value to both rules, which the script in Listing 2 shows, they can be enabled and disabled more easily together.
One more comment regarding the Grouping property bears mentioning. The sample script uses a special syntax, known as an indirect string, as the group value:
"@firewallapi.dll,-23255"
Under the covers, the result of the value used in this example is that the string with identifier 23255 is retrieved from the resource section of firewallapi.dll. The firewall then uses that string as the group name for the rule. Why is this syntax useful? It lets ISVs configure localizable rule group names for a given application. That is, after the application DLL strings are translated to another language (e.g., from English to Japanese), the rule group names will show as translated too.
The string retrieved from firewallapi.dll in this example is None, which simply happens to be a convenient default. If you have the support of a line-of-business development team, and you wish to make more extensive use of the Grouping property, consider requesting the creation of a resource DLL containing the rule group name strings you require. Otherwise, you can continue to use the default, or you can simply remove the line of script that sets this property, which results in a blank group name in the firewall's MMC snap-in.
Returning to the task at hand, after the rule for the stcpserver example has been created, you can examine the result in the firewall's MMC snap-in. Figure 2 shows the inbound rule for stcpserver. To summarize the combined effect of the rule properties set by the sample script, the firewall allows the program binary located at %ProgramFiles%\Secure TCP Server\stcpserver.exe (and only that particular binary) to receive traffic that meets the following criteria: TCP, sent to local port 27015, originating from any address on the local subnet. Traffic not meeting any or all of those criteria will be filtered (i.e., not received by) the application.
Now that you know how to create secure rules, you’ll also want to be able to control the overall state of the firewall. That’s the topic of the next section.
Enabling and Disabling Windows Firewall
Any user with local administrator privilege can disable Windows Firewall, which is enabled by default. For shops wanting to run a third-party firewall, it’s probably most desirable to disable the built-in firewall via Group Policy. However, this disabling operation can be scripted as well. The script option is convenient for ensuring that the firewall is enabled, too, for example on a server hosting a network application such as stcpserver, discussed above.
Listing 3 shows a simple script that toggles the firewall each time it runs, turning it on, then off. The purpose of the script is simply to show how to explicitly enable or disable the firewall. The appropriate snippet should be excerpted and used based on operational requirements. To learn more about how to use VBScript to interact with Windows Firewall with Advanced Security, see the Microsoft article "Using Windows Firewall with Advanced Security" at http://msdn2.microsoft.com/en-us/library/aa366418.aspx.
Viewing Firewall Rules
The Windows Firewall with Advanced Security snap-in provides a convenient interface for examining firewall rules. The following steps describe how to launch the firewall's MMC snap-in, as well as how to produce the filtered view shown in Figure 2.
- Select Start and type wf.msc in the Start Search field.
- Click wf.msc when it appears in the filtered list, or press Enter.
- In the left pane of the firewall's MMC window, select Inbound Rules; you should then see the inbound firewall rules displayed in the center pane.
- To filter out all of the rules other than the one created by the script in this example, in the right pane, select Filter by Group, Filter by None (yes, that’s a confusing group name, but recall that it’s the default and is used by the sample script).
- You should now see the stcpserver rule displayed in the center pane. To remove the group name filter from the current view, select Clear All Filters from the right pane. Otherwise, proceed to the next steps to further customize the rules display.
- Figure 2 shows a custom set of rule properties (in other words, columns). To reproduce this set, select View, Add/Remove Columns. A different set of displayed columns, and the order in which they’re shown, can be selected in the dialog box that appears.
- Finally, Figure 2 also shows the MMC snap-in without its left pane. You can toggle this view mode by clicking the button with tool tip Show/Hide Action Pane, located near the top of the MMC snap-in.
Don't Rely on the Defaults
As you can see in the example above, you can easily handle network application compatibility with the new Windows Firewall by using a combination of scripting and the MMC snap-in. In fact, intentional and informed management of firewall rules is a must, because the defaults might not be as secure as you’d like.
