Windows Firewall: Building Security

When it comes to securing systems, most organizations focus their efforts on servers. But many of the recent worms that have brought down entire networks and cost companies millions of dollars have done so simply by targeting the humble workstation. Malicious intruders—be they outsiders or disgruntled employees—who manage to take control of a workstation and impersonate the system's legitimate owner can access confidential information and resources on the local system and on the network. Gone are the days when you could trust your local LAN to be a safe haven. Between worms and malicious insiders, you need to protect all open ports on your workstations against attacks.

Microsoft evidently recognizes this new reality. Thus, as part of its Trustworthy Computing initiative, the company has made security the focus of Windows XP Service Pack 2 (SP2)—the most security-centric service pack since Windows NT 4.0 SP3. Many people in the user community dubbed that service pack "Security Pack 3," and XP SP2 (which as I write this article is scheduled for release late this summer) deserves the same moniker. SP2 is chock-full of new security features to combat worms and malware that can infect networks through unprotected workstations. SP2's most important feature is Windows Firewall, a much enhanced version of Internet Connection Firewall (ICF). The feature's name change reflects the emphasis that Microsoft is placing on using local firewall technology to protect workstations that connect solely to a local intranet as well as those that connect to the Internet. The best way to begin to take advantage of SP2's new firewall feature is to install SP2 on a standalone test server, which I'll show you how to do in this article. After you're familiar with the feature, you can install SP2 and centrally configure Windows Firewall on all the workstations on your network (something I'll show you how to do in a follow-up article).

Getting to Know You
To start learning about Windows Firewall, I suggest you manually install SP2 on an XP test system. Windows Firewall automatically activates after SP2 installation. The firewall accommodates two configuration profiles—domain and standard— on systems that are members of a domain. Windows Firewall uses the domain profile when the workstation is connected to the internal LAN; otherwise, the firewall uses the standard profile. You must use Group Policy to configure this dual capability, and I'll show you how to do so in my next article. For the purposes of this article, however, we'll assume that the test system isn't a member of a domain. Therefore, the system will use only one profile, which will apply when the computer is connected to the internal network as well as when the system is connected to the Internet. We'll take a look at Windows Firewall's nuts and bolts by stepping through the manual, local configuration process, which uses Control Panel to configure Windows Firewall on your standalone test system.

Start It Up
Open the Control Panel Windows Firewall applet. (Note that the dialog boxes in the XP SP2 version that I used when
writing this article still bore the firewall's original name—Internet Connection Firewall. Therefore, the dialog boxes in the final version of SP2 will probably look or be organized differently than in the figures that accompany this article. The sidebar "Windows Firewall Update" discusses some other changes that have taken place.) On the General tab, you'll see options for two operational modes: On and Off. Setting Windows Firewall to Off disables the feature and leaves the workstation (and your network) completely exposed to attack. Selecting On activates Windows Firewall. Windows Firewall is a stateful inspection firewall, meaning that it keeps track of the state of all TCP and UDP conversations and can thus identify incoming packets that aren't part of a valid conversation that the workstation initiated. By default, Windows Firewall drops such packets. However, in some situations you might want to permit incoming connection requests. For example, if the workstation is connected to a LAN, you might want to allow connections to port 3389, which both Remote Assistance and Remote Desktop use. When you enable Windows Firewall, it disables all incoming connections except those that you define on the applet's Exceptions tab.

To enforce a temporary lockdown—when, for example, a new worm is gathering speed on the network and your antivirus vendor hasn't yet released a signature update or you can't push out the necessary security patch in time—you can switch your workstations to Shielded mode until the patch is deployed or your antivirus product is updated. (This type of widespread configuration would take place through Group Policy.) Be aware that during this type of lockdown, services that need to accept incoming connections (e.g., Windows Messenger) will be broken. For information about Shielded mode, see "Windows Firewall Update."

The Exception to the Rule
Exceptions define how Windows Firewall handles unsolicited inbound packets. To configure global exceptions that apply to all network connections, including dialup, LAN, VPN, and WAN connections, go to the Windows Firewall applet's Exceptions tab, which Figure 1 shows. (I'll show you later how to configure exceptions that apply to specific network connections.)

Note that Windows Firewall doesn't enforce any policies on outgoing packets. Ideally, a workstation firewall such as Windows Firewall would also control outbound packets. Without such control, you can't prevent malicious users or programs on the workstation from attacking other computers on the network. In all fairness, however, controlling outbound traffic is much more complex than
controlling inbound traffic because distinguishing between legitimate and malicious outbound connections is difficult. (That's why personal firewall developers such as Internet Security Systems'—ISS's—BlackICE must employ an annoying learning mode.)

Windows Firewall comes with several predefined Programs and Services that you can configure as exceptions, and you can add more. Each exception is based on a specific TCP or UDP port or on an executable name. The classic method of defining firewall rules is by using port numbers, but backdoor and Trojan horse programs have proven that port numbers aren't always a dependable way of judging incoming packets. A backdoor program that successfully installs itself on a computer opens a port and waits for an attacker to connect. Some of these backdoor programs open ports that legitimate programs use; other backdoor programs insert themselves between a legitimate program and its port, inspecting incoming traffic and intercepting incoming requests to the backdoor (these requests masquerade as requests to the legitimate program). To defeat both types of backdoor programs, Windows Firewall also lets you authorize specific programs to open ports. Let's examine two of Windows Firewall's prebuilt exceptions, which demonstrate the port- and program-based approaches.

Ports. To view a port-based exception configuration, select the Remote Assistance and Remote Desktop check box under Programs and Services on the applet's Exceptions tab to open the Exceptions dialog box. As Figure 2 shows, this built-in exception is based on TCP port 3389, which is used by the Remote Desktop Protocol (RDP), through which Remote Assistance and Remote Desktop communicate.

At the bottom of the Exceptions dialog box, you'll find two Scope options: You can open the specified port to All IP addresses (i.e., systems on the local LAN segment and from across the Internet), or you can open the port to Local Subnet Only. The Local Subnet Only option's value is limited to small and midsized businesses that have only one subnet or to organizations that can be sure that the people or programs that need to access the workstation from over the network will be on the same subnet as the workstation. For companies with more than one subnet, the Scope setting is fairly useless. If you use a systems-management program such as Microsoft Systems Management Server (SMS) or if your administrators need network access to workstations on multiple subnets, you have no choice but to set the Scope to All IP addresses. An alternative to using the Scope option is to use XP's built-in IP Security (IPSec) support. You can use IPSec policies to link Allow or Deny rules to multiple IP subnets so that computers outside your overall intranet subnet ranges can't connect to ports that you must open up within Windows Firewall. You can use the same Group Policy Object (GPO) that you use to control Windows Firewall to easily distribute these IPSec policies. (For more information about using such policies within your intranet, see "Resources.")

Programs. Now let's look at a program-based exception. Click Cancel on the Exceptions dialog box to close the box, then select the Windows Messenger check box on the Exceptions tab to open a new Exceptions dialog box. As Figure 3 shows, this exception is tied to a specific program file (%ProgramFiles%Messengermsmsgs.exe) instead of a port number. (Some programs, such as Windows Messenger, don't use predefined port numbers.)

Windows Firewall comes with several prebuilt exception definitions, but only three—Files and Settings Transfer Wizard (%windir%system32usmtmigwiz.exe), NetMeeting (%ProgramFiles%NetMeetingconf.exe), and Windows Messenger (%ProgramFiles%Messengermsmsgs.exe)—are enabled by default. To enable another prebuilt exception, select its check box on the Exceptions tab. To define an exception for another program or port, click Add, then provide the appropriate program or port information.

Keep the Connection
If a computer uses multiple network connections (including dialup and VPN connections), you might need to enable, disable, or tailor Windows Firewall differently for each connection. You can accomplish this task on the Windows Firewall applet's Network Connections tab, which Figure 4 shows. To enable or disable Windows Firewall for a connection, select or clear the check box for that connection on the Network Connections tab. To configure advanced settings for a connection, select the connection's check box and click Settings to open the Advanced Settings dialog box. The Services tab, which Figure 5 shows, lets you open certain services to Internet traffic, as long as you're using Internet Connection Sharing (ICS). Similarly, the Advanced Settings dialog box's ICMP tab, which Figure 6 shows, lets you configure how Windows Firewall will respond to Internet Control Message Protocol (ICMP) messages (e.g., pings) that are received on the specified network connection. (The applet's ICMP tab, which Figure 7 shows, lets you configure global settings that determine how Windows Firewall will respond when the system receives an ICMP message such as a ping. You can enable or disable each type of ICMP request as you see fit.)

You might wonder how network connection-specific port exceptions relate to the global port exceptions that you put into effect when you create a port-based exception. The easiest way to explain is with an example. Suppose you have two NICs: NIC1 and NIC2. You want to open port 3389 on both NICs, but you also want to open port 80 on NIC1 but not on NIC2. You can create an exception that opens port 3389, then use the Network Connections Advanced Settings to add a service that opens port 80 on NIC1.

Keep a Log
The Windows Firewall applet's Log Settings tab, which Figure 8 shows, lets you configure whether and how Windows Firewall logs its activity. (Be aware that Windows Firewall logging is disabled by default.) You can control whether Windows Firewall logs dropped packets or successful incoming and outgoing connections. Thus, the log can reveal every time someone tries and fails to connect to the computer, as well as each successful incoming connection and each time the computer opens an outgoing connection to another system, such as a local file server or a Web server over the Internet. The log records source and destination IP addresses and port numbers as well as lets you know whether the connection was dropped or successful. For example, the log output in Figure 9 shows that Windows Firewall rejected an attempt by a system at IP address 10.42.42.2 to connect to port 80 on the local workstation. The log then shows that the system at IP address 10.42.42.10 successfully connected to the local workstation through Remote Desktop Protocol (port 3389). Finally, the log shows that the local workstation connected to IP address 10.42.42.100 to execute a remote procedure call (RPC) transaction using port 135.

By default, Windows Firewall stores the log as C:windowspfirewall.log and sets a maximum log size of 4MB, but you can change the path and filename (the file must reside on the local system) as well as the maximum log size. When the log reaches the maximum, Windows appends .old to the log filename, then starts a new log under the path name specified on the Log Settings tab. The next time the log fills up, Windows again renames the log file (which then overrides the original, oldest file) and starts a new log.

Extend the Wall
Now that you understand how Windows Firewall works, you can determine how to best configure it for your environment. In my next article, I'll show you how to use Group Policy to automatically deploy SP2 to all your XP workstations and to centrally configure and control Windows Firewall on those machines.