Windows Firewall Configuration Strategies

Windows Server 2003 Service Pack 1 (SP1) and Windows XP SP2 include the host-based Windows Firewall, which provides significant improvements over its predecessor, Internet Connection Firewall (ICF). Unlike ICF, which shipped with Windows 2003 and XP, Windows Firewall is suitable for enterprise-wide deployments because it lets you configure and administer firewall policies from one central location, has multiple configuration interfaces, and includes many new features that enhance firewall security. I'll help you get started using Windows Firewall by giving you tips on planning for, configuring, and employing it in an enterprise environment.

Getting Ready
An important thing to remember about Windows Firewall is its default settings. On XP SP2, Windows Firewall is enabled by default, whereas on Windows 2003 SP1 it's disabled by default unless you apply SP1 to a system that has ICF turned on, in which case your firewall settings are preserved. (For slipstream editions, where SP1 has been added to the installation media, Windows Firewall is always enabled during the Security Out-of-Box Experience when the installation process connects to Windows Update to obtain the latest updates.) Thus, if you deploy XP SP2 without first considering Windows Firewall configuration, you might discover that, by accepting the default settings, you've inadvertently blocked the ability to use your administration tools to remotely manage desktops. If you aren't ready to use Windows Firewall, or if you use a third-party host-based firewall, you can safely disable Windows Firewall and deploy SP2 without it.

If your organization uses Active Directory (AD) for user authentication and your desktops are members of a domain that has computer accounts, the simplest way to configure Windows Firewall is by using Group Policy Objects (GPOs). When you apply XP SP2 to your desktops, they'll take on the firewall settings when they're rebooted and again whenever policy is refreshed. If you use a third-party directory product or have unmanaged desktops that aren't in an AD domain, you can use batch or command scripts instead of GPOs to configure Windows Firewall. You can also configure the firewall when performing unattended or interactive installations of XP SP2. The Web-exclusive sidebar, "Windows Firewall Configuration Methods," http://www.windowsitpro.com/windowssecurity, InstantDoc ID 47179, provides more detailed information about using these techniques to configure Windows Firewall.

Windows Firewall Configuration
When you're ready to configure Windows Firewall, you'll find it helpful to understand the following essential facts about how it works:

Before you configure Windows Firewall, you should inventory the applications on your workstations and servers that might establish listening endpoints, the ports that each application and OS use, and the source of traffic to each host that will use Windows Firewall. For mobile systems such as laptops, the inventory should consider the different nature of network traffic when the system is connected to a corporate network with DCs and on which the Windows Firewall Domain profile is active versus when the system is connected to a public network and the Standard profile is active. You should always configure the Standard profile and configure it to permit only essential incoming traffic, if any, through the firewall to minimize the security exposure to your connected mobile system.

Windows Firewall defines four built-in administrative services, which represent common exceptions required in any firewall policy: File and Print, Remote Administration, Remote Desktop, and Universal Plug and Play (UpnP). Remote Administration is the ability to manage the system using common administrative interfaces and subsystems such as Windows Management Instrumentation (WMI) and remote procedure calls (RPCs). Remote Desktop lets you connect to your machine from another system via RDP and is also used when requesting Remote Assistance. Administrators routinely use Remote Desktop to connect to remote servers to manage them. The UpnP protocol lets devices discover and dynamically configure each other in response to running applications and services, to ensure that the devices work. A common example of UpnP is when you launch MSN Messenger and XP works with a UPnP-capable home broadband router to ensure that audio and video connections are allowed through the router's built-in firewall.

When you configure the Windows Firewall Domain and Standard profiles, I recommend that you define exceptions by application. An application exception lets the application establish any listening endpoints it chooses and accept traffic on them. There are two good reasons for defining exceptions by application: First, it's easier to define and approve applications than it is individual ports used by applications, especially since many applications don't fully document the ports that they use or use dynamic ports. Second, many applications, including malware, use the same ports as approved applications; by defining applications instead of ports, you deny nonapproved applications the opportunity to establish listening endpoints. I also recommend that wherever possible you permit no exceptions for the Standard profile and deny all incoming connections. Web Table 1, InstantDoc ID 47178, lists the ports and transport protocols on Windows 2003 and XP that standard Windows and common applications and services use and for which you might need to create exceptions.

Windows Firewall for Servers
Although Microsoft makes no specific recommendations for configuring Windows Firewall for servers, and the firewall is disabled by default unless you install Windows Server 2003 SP1 on a system with ICF enabled, you can leverage the firewall to improve security on a Windows 2003 server. Before using the firewall on a server, you should consider the fact that servers, by their nature, host applications and services that applications and services on other servers, desktops, and laptops want to connect to. If you choose to enable Windows Firewall on a server, you should give some thought to how you'll configure it.

For some servers, Windows Firewall will be easy to configure. For example, an unmanaged standalone Web server in a demilitarized zone (DMZ) will be required to accept only incoming connections on port 80/TCP (HTTP) or 443/TCP (HTTP Secure--HTTPS) if a certificate is installed and Secure Sockets Layer (SSL) is enabled.

When you have dual-homed or multihomed servers (servers that have two or more interfaces) where one interface is connected to the Internet and others are connected to private networks, you can enable Windows Firewall, then disable it on all but the interface connected to the Internet and configure it to permit only the required incoming connections on the Internet interface.

On simple file and print servers on your intranet that are members of a domain, you can enable Windows Firewall and use the built-in File and Printer Sharing service option to let users connect to those servers. You can also use Windows Firewall to secure a server on which services listen on well-known ports, such as a Microsoft SQL Server 2000 database server, after you've configured the firewall to permit traffic on the required ports.

You might prefer to use Security Configuration Wizard (SCW) to configure Windows Firewall in your server environment. SCW, which shipped with Windows 2003 SP1 as an optional component, lets you reduce your server's attack surface by selecting a server role or roles. SCW contains role information for DCs and other infrastructure servers; it disables unnecessary services and configures Windows Firewall to restrict incoming traffic.

There are some servers on which you shouldn't deploy Windows Firewall. These include AD DCs and certain application servers that listen on a wide range of ports or use dynamic ports, such as Exchange Server 2003 servers. (In the latter case, you might be able to deploy Windows Firewall if the servers and clients that connect to the Exchange servers are members of a domain, you configure the firewall to permit authenticated IPsec to bypass Windows Firewall--which I discuss later, and you configure the clients to use IPsec.)

On many servers, such as those that run a myriad applications and services, you'll need to configure Windows Firewall selectively. That is, you'll need to identify which ports the applications and services listen on, discount the unnecessary ports, and configure Windows Firewall for the necessary ones. You can use the Netstat command (netstat.exe), which Microsoft has enhanced in the latest service packs, to determine which ports are open and which applications and services are listening on them. By entering

netstat -a -b

at a command line, you can display all open TCP ports (regardless of state) and UDP ports on the system, the process identifier (PID) for each active connection, and the name of the application or service, as the sample output in Figure 1, page 8, shows. As I mentioned earlier, you can configure Windows Firewall to permit incoming traffic to named applications, regardless of the ports they listen on. The only drawback to using Netstat is that it provides only a snapshot of a running system at a point in time. It won't help you identify applications or services and their ports if those applications aren't running when the snapshot is taken. To build an accurate picture of usage, you could take several snapshots at different times.

An easier alternative to using Netstat is to use the Port Reporter tool, which you can obtain via http://support.microsoft.com/?kbid=837243. The tool installs as a service and logs network activity, including details about running applications and services and even the user account an application or service ran under. You can use a companion tool, Port Reporter Parser (http://www.support.microsoft.com/?kbid=884289), to mine data in the logs that Port Reporter generates. When configured correctly and run over a period of time, Port Reporter can help you identify which applications open ports on your server and which you need to configure in Windows Firewall either by application or by individual port. How long you should run Port Reporter depends on your applications and usage patterns. A word of caution: Port Reporter might slightly affect your system's performance and can produce voluminous data in its log files. Make sure you configure the tool to log to a fast disk that has plenty of free space.

As a best practice, I recommend that you enable Windows Firewall's logging after you've configured it on your servers. You can configure logging of successful and unsuccessful connections. If you have problems running certain applications after you've configured and enabled Windows Firewall, you can use the log information to determine what additional ports you need to open. You configure logging by opening Control Panel, launching the Windows Firewall applet, clicking the applet's Advanced tab, and clicking the Settings button in the Security Logging section, which displays the Log Settings dialog box that Figure 2 shows. Make sure you configure Windows Firewall to log to a fast disk with ample free space and that you set the log's maximum size high enough to capture the information you need over an extended period of time. When you're sure that you've configured Windows Firewall correctly, you can turn off logging.

You can also configure Windows Firewall so that it lets authenticated IPsec traffic from trusted hosts bypass the firewall. This feature allows you to lock down servers and workstations so that they permit only necessary client traffic to pass through while granting unrestricted access to administration workstations and servers. For more information about authenticated IPsec bypass, see the Web-exclusive sidebar "Using Authenticated IPsec to Bypass Windows Firewall," InstantDoc ID 47180.

Ready to Go
When you're ready to deploy Windows Firewall, I recommend that you do so first to a pilot group of users in your organization. If you experience difficulties with the pilot deployment, enable logging for the firewall; the logs contain information that could help you determine what's causing the problems. After you've worked out the kinks and deployed Windows Firewall successfully, you'll undoubtedly find it to be an invaluable part of your organization's security strategy.