Windows XP SP2: Centralized Deployment and Defense

In the Group Policy console, maneuver to the GPO's Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall object. This object contains two subfolders: one for the firewall's domain profile and one for the standard profile. Windows Firewall automatically determines whether a system is connected to the LAN and if so, applies the settings defined under the domain profile. Otherwise, Windows Firewall applies the settings defined under the standard profile. (For more information about the determination process, see the Windows Firewall­related articles listed in "Resources.") Having two profiles lets you configure Windows Firewall with stricter policies for users who work outside your more trusted internal network. You get this dual-profile functionality, however, only when the XP workstation is part of an AD domain, and you can configure the profiles only through Group Policy. I'm going to show you how to configure the domain profile; keep in mind that the standard profile contains the same settings. Many of these settings correspond with the manual settings I describe in "Windows Firewall: Building Security," so see that article for more details about what the settings do.

Select the Domain Profile folder, double-click the Operational Mode setting object in the right-hand pane, and open the setting's Properties dialog box. You can configure the policy setting to be Not Configured, Enabled, or Disabled. Select Enabled; doing so then lets you configure Windows Firewall's operational mode as Off or Enabled (as I explain in "Windows Firewall: Building Security"). Click OK to close the setting. If you select Not Configured or Disabled (rather than Enabled), Windows will let end users use local settings to configure Windows Firewall. Beware that this is true for all the settings I describe here: disabling or not configuring a setting gives users the ability to change the setting locally—so long as the next setting I describe, Allow User Preference/Group Policy Settings Merge, is Enabled or Not Configured.

Open the Allow User Preference/Group Policy Settings Merge setting's Properties. If you leave this policy as Not Configured, Windows will ignore any settings that users make to Windows Firewall. If you select Disabled, Windows will disable Windows Firewall settings altogether for end users. If you select Enabled, Windows will merge any preferences that end users set with the settings you configure through Group Policy. Thus, enabling Allow User Preference/Group Policy Settings Merge can let users use the Control Panel Windows Firewall applet to configure unapproved firewall exceptions through open ports or allowed programs—a bad idea. Select Disabled to prevent users from having manual access to Windows Firewall settings and potentially opening security vulnerabilities on their workstations (and your network).

Open the Properties for the Define Allowed Programs setting, which defines the programs that Windows Firewall will let access your XP SP2 systems. Select Enabled, then click Show to see a list of allowed programs. To add a program to this list, you must enter a path and several other values in the form executablepath:scope:enabled/disabled:friendly name, where scope can be LocalSubnet or can be the wildcard symbol (*) to specify all IP addresses. For instance, the entry that Figure 2 shows defines Windows Messenger as an allowed program for traffic from all IP addresses. Add or remove programs as necessary, then click OK to close the Show Contents dialog box and click OK to close the Define Allowed Programs Properties dialog box.

Open the Properties for the Define Custom Open Ports setting. Select Enabled to define authorized ports for incoming connections. To authorize a port, you must enter it in a format similar to the one you use to allow programs. For ports, the format is port number:TCP/UDP:scope:enabled/disabled:friendly name, where scope can be either LocalSubnet or the wildcard symbol (*). For example, 80:TCP:LocalSubnet:enabled:HTTP lets computers on the local network connect to Microsoft IIS on the local workstation.

You might wonder, "What's the purpose of specifying disabled in the defined programs or specifying ports in the Define Allowed Programs and Define Custom Open Ports settings?" Microsoft documentation states that any enabled rule for a given port or program will override any disabled rule for the same port or program. However, Windows Firewall closes all ports by default, so disabled rules seem to have no value as far as locking down a system. You can, though, use disabled rules to prepopulate the Control Panel Windows Firewall applet's Programs and Services list with unselected exceptions. Doing so would make it easy to temporarily enable certain programs or ports—for example, if several management consultants working on a project at a client location needed to use peer-to-peer sharing to share files with one another.

The Allow Dynamically Assigned Ports for RPC and DCOM setting lets you control whether other people on the intranet or Internet can access the workstation via Remote Procedure Call (RPC) or Distributed COM (DCOM). This type of traffic includes WMI, remote access to most of the resources in the MMC Computer Management snap-in, and a host of other processes. RPC and DCOM are especially problematic for firewalls because they both use dynamically assigned ports. Consequently, Windows Firewall by default blocks access to incoming RPC or DCOM requests, with the exception of requests to executables that are listed as allowed programs.

The Allow Dynamically Assigned Ports for RPC and DCOM setting lets you control how programs that aren't defined as exceptions accept incoming RPC and DCOM connections. If you select Enabled, you must then configure RPC port visibility to None, Entire Network, or Local Subnet. When you select None, Windows Firewall will allow incoming requests only to programs listed as exceptions. When you select Entire Network or Local Subnet, Windows Firewall will accept incoming RPC and DCOM requests from the entire network or the local subnet, respectively.