Windows XP Service Pack 2 (SP2), with its Windows Firewall component, promises to be a white knight for those of you who want to defend your XP client systems (and the rest of your networks) against malicious invaders. The thought of deploying the service pack and configuring the firewall on all your clients, however, might make you want to throw yourself in the moat. But hold on: XP SP2 takes advantage of Group Policy to let you centrally deploy the service pack and configure Windows Firewall. (Be aware that the final version of SP2 is likely to have changed somewhat from the prerelease version I used when writing this article, so some details might be different than those I describe here.)
Deploy...
All service packs for Windows 2000 and later include a Windows Installer (.msi) file that lets you automatically push out the packs to appropriate computers simply by using Group Policy's Software Installation feature. The first step in getting XP SP2 ready for autodeployment is to create a shared folder (appropriately named, for example, xpsp2) from which the computers can access the .msi file and two other SP2-related files. Give the Administrators group Full Control permissions on the folder and give the Domain Computers group Read access. Next, download xpsp2.exe from Microsoft (or find it on the XP SP2 CD-ROM) and run the executable with the /x switch to extract the service pack to the shared folder.
After the extraction is completed, you're ready to set up a Group Policy Object (GPO) that will install SP2 to all your XP computers. But how do you limit the GPO to XP computers and prevent it from trying to install SP2 on your Windows Server 2003 or Windows 2000 systems? You can't use a Windows Management Instrumentation (WMI) filter to limit the GPO's scope because Win2K computers don't recognize WMI filters attached to a GPO (and consequently apply the GPO as though no filter were present). You can use organizational units (OUs) to limit the GPO's scope, but to do so you need an OU that contains all your XP workstations and no other systems. If your OU structure doesn't permit that type of setup, you'll need to create an Active Directory (AD) group—called, for instance, XP Workstations—and make all your XP computers members of that group.
Create a new GPO at the domain root and give the GPO a name such as XP Workstation Computer Configuration. Open the GPO's Properties dialog box and select the Security tab. Delete the Everyone entry from the GPO's ACL and add an entry for the XP Workstations group, then grant that group Read and Apply Group Policy permissions. Now, even though the GPO is linked to the domain root, only computers that are members of XP Workstations will be able to apply the GPO and thus install SP2.
To configure the XP Workstation Computer Configuration GPO to install SP2, you need to edit the GPO. (If you need information about the process of editing GPOs, see "Resources.") In Group Policy Object Editor, right-click the Computer Configuration\Software Settings\Software Installation object and select New, Package from the context menu. In the Open dialog box that appears, enter the Universal Naming Convention (UNC) path to your shared installation folder in the File name text box, then append \i386\update\update.msi to that path and click Open. You'll be prompted to select a deployment method; select Assigned and click OK. The right-hand pane of Group Policy Object Editor will now display the Windows XP Service Pack 2 (1033) object, as Figure 1 shows.
Your XP systems won't install SP2 yet, however. XP's default startup behavior lets users log on even before full network access is available, and this behavior prevents Group Policy from automatically processing Software Installation policies that you add to a GPO. Microsoft documentation states that the installation will occur on each XP system the next time the system logs on to the network, but in my experience, Software Installation policies that you configure under a GPO's Computer Configuration node fail to execute unless you enable the Always wait for the network at computer startup and logon policy under the GPO's Computer Configuration\Administrative Templates\System\Logon object. You need to enable that policy for the GPO. After you do so, your XP systems will install SP2 the next time they reboot.
Note that users won't be able to log on until the SP2 installation completes, which can take 20 minutes. Therefore, I recommend that you alert users in advance of rolling out SP2. You might even want to encourage users to restart their computers before they leave for the day so that SP2 completes installation before they get to work the next morning. By the way, don't worry that users dialing in to your network or VPN will experience slow performance while Windows tries to download the SP2 installation files over a slow connection. By default, Windows automatically recognizes slow connections and postpones the application of certain areas of Group Policy—including Software Installation. You can use the policies under the GPO's Computer Configuration\Administrative Templates\System\Group Policy object to control this behavior.
...and Defend
After you've installed SP2 on all your XP computers and gotten to know the service pack's new Windows Firewall feature by working with it on a standalone test server (as I describe in "Windows Firewall: Building Security," July 2004, InstantDoc ID 42930), you can centrally manage the configuration of Windows Firewall on your XP SP2 systems. To do so, open the Microsoft Management Console (MMC) Group Policy snap-in on one of your XP SP2 systems so that you can edit the Group Policy settings under the XP Workstation Computer Configuration GPO's Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall object. (You'll need to have installed adminpak.msi on that system to edit the GPO; see the sidebar "Editing a GPO from a Windows XP System" for details.) If you don't see this folder when you first open the Group Policy console, don't worry—it simply means that the GPO hasn't yet been updated with the new Windows Firewall settings. Windows will automatically update the GPO and make the settings available when you begin to edit the GPO.
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 Firewallrelated 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.
To determine which settings you need to enable on your XP workstations requires thorough research and testing. I suggest you start out by disabling RPC and DCOM access on a test network, then fully testing all system management functions (e.g., Microsoft Systems Management Server—SMS) and remote support functions (e.g., Computer Management console functions, WMI scripts) that you use to administer workstations from over the network. If you can't connect to a feature, determine the name of the corresponding server program and enable that program for incoming RPC requests.
The Allow File and Printer Sharing setting is a shortcut policy that enables all the ports necessary for file sharing—specifically, UDP ports 137, 138, and 139 and TCP ports 139 and 445. If you enable this policy, you must set visibility to Local subnet only or Global visibility.
The Allow ICMP Settings policy lets you control how Windows Firewall handles Internet Control Message Protocol (ICMP) messages. If you enable the policy, you must enable specific permitted ICMP message types.
The Allow Remote Assistance Support setting is another shortcut policy that controls whether Windows Firewall will permit unsolicited Remote Assistance requests. (Enabling TCP port 135 for the entire network and adding helpsvc.exe to the allowed programs list accomplishes the same goal as enabling this setting.)
The Allow Universal Plug and Play setting is a shortcut policy that controls whether Windows Firewall will let Universal Plug and Play (UPnP) work on your XP SP2 systems. If you enable the setting, Windows Firewall opens TCP ports 1900 and 2869 and UDP port 2869 for the entire network.
Safe Haven
I'm excited about XP SP2's new security features—especially Windows Firewall. Carefully determine which ports and programs can accept incoming connections when workstations are connected to the internal network, and use the LocalSubnet scope whenever possible. (The only major complaint I have with Windows Firewall is that it doesn't have an option similar to the LocalSubnet scope to let you define multiple subnets so that large companies can configure the firewall to differentiate between internal and external connection attempts.) When you configure the standard profile, make sure to differentiate between the ports and services that should be open when your workstations connect to the intranet as opposed to when the computers connect to some other network. And when you roll out SP2 via Group Policy, make sure you coordinate the rollout with users so that you don't create problems for them when they reboot and launch the SP2 installation process.
After you've rolled out SP2 to all the workstations and given them a chance to reboot, I suggest you use Microsoft Baseline Security Analyzer (MBSA) to find computers that for whatever reason are missing SP2. You can also use a port scanner against a sampling of systems to confirm that your Group Policy settings are performing as expected. And as always, carefully perform impact analysis and testing before rolling out SP2. Doing so will let you successfully build up the fortress around your workstations.
| Resources |
|
WINDOWS & .NET MAGAZINE RESOURCES You can obtain the following articles from Windows & .NET Magazine's Web site at http://www.winnetmag.com. JAN DE CLERCQ NT Gatekeeper, "NT Gatekeeper: RPC and Firewall Configuration," September 2001, InstantDoc ID 21956 KATHY IVENS Windows Admin 101,"Taking Control of Group Policy," April 2004, InstantDoc ID 41985 MARK MINASI "Windows Firewall Update," July 2004, InstantDoc ID 42931 Inside Out, "Meet Windows Firewall," May 2004, InstantDoc ID 42293 KEN PFEIL Discoveries, "Multiple Vulnerabilities in Microsoft Windows RPC/DCOM," April 2004 Web exclusive, InstantDoc ID 42423 RANDY FRANKLIN SMITH "Windows Firewall: Building Security," July 2004, InstantDoc ID 42930 "Don't Shoot Yourself in the Foot with Group Policy Security Settings, Part 1," July 2001 Web exclusive, InstantDoc ID 21656 |
