Get the lowdown on XP SP2's successor to ICF
In the wake of last year's Blaster worms, Microsoft decided to delay Windows XP Service Pack 2 (SP2) until the company could incorporate more security into the service pack. One step the company decided to take in SP2 is to automatically turn on XP's Windows Firewall (formerly Internet Connection Firewall—ICF) for all NICs.
This is a drastic step, and one that can make XP work differently from the way you expect it to, whether in a corporate domain or a home workgroup. By "work differently," I mean cause things that used to work to stop working. Administrators whose hands are already full will greet this news with a rueful sigh and might simply turn off Windows Firewall—certainly that was my first inclination. After thinking about it, though, I decided to leave Windows Firewall on. However, I discovered that I needed to relax its constraints a bit because Windows Firewall's default setting disables all remote control and remote support tools.
Whether you decide to disable Windows Firewall or modify its settings, you'll probably want to implement your decision over dozens, hundreds, or thousands of systems as easily as possible. In this article, I show you how to turn Windows Firewall on and off and configure the firewall's domain and mobile profiles. In a future article, I'll handle the finer settings.
How Windows Firewall Works
First, what exactly does Windows Firewall do? It examines and potentially blocks only incoming traffic—it doesn't affect outgoing traffic. By default, Windows Firewall rejects all incoming traffic unless that traffic is in response to a previous outgoing request.
For example, if I open Microsoft Internet Explorer (IE) from my XP box and type
in the Address bar, IE causes the system to send a request to CNN for its home page. Windows Firewall doesn't block the outgoing traffic, but it does note where that traffic is going. A few moments later, CNN's Web server tries to send IE the data that it requested. Windows Firewall sees the incoming traffic, determines that it's from www.cnn.com—a site to which my system had sent a request—and lets the traffic pass. Basically, Windows Firewall ensures that you can communicate with the rest of the Internet and with your intranet as long as your system initiates the conversation.
In contrast, suppose an outside system—perhaps one that's infected with the Blaster worm—tries to strike up a conversation with my XP system. The external system attempts to send a packet to port 135 on my system, trying to infect my system with Blaster. Because Windows Firewall doesn't interpret this communication as a response to a conversation that my system initiated, the firewall discards the packet. In a sense, Windows Firewall says to the network, "Speak to me only when I speak first."
What would happen if you enabled Windows Firewall on a system inside your intranet—an intranet connected to a domain? You might at first think that rejecting all communications except for those initiated by a client would somehow inhibit a workstation's usual participation in a domain—certainly that was my initial, hasty conclusion. After some thought, however, I realized that all domain communication is initiated by a client: The client asks to log on, the client asks for Group Policy refreshes, the client asks for roaming profiles, and so on. To test this theory, in September 2003, I enabled Windows Firewall on several XP workstations in my Active Directory (AD)-based domain. Since then, I haven't experienced any loss in domain function. However, as I mentioned earlier, my remote administration tools don't work unless I disable or modify Windows Firewall.
Your network might experience problems mine didn't. For example, I know someone who, after enabling the pre-SP2 firewall, lost the ability to browse Network Neighborhood and map to shares. Realize that every network segment needs a browse master—a machine that creates a census of servers on its segment. Any server can act as a browse master, and in most networks every workstation is a server. On a segment that doesn't have an actual server, such as a file server or print server, some workstation takes up the job of browse master. But in a segment that's populated only by workstations that have a personal firewall installed, no system would step forward to assume the role of browse master and Network Neighborhood browsing would fail. You'd also see that behavior on a segment populated only by SP2-equipped XP systems unless you modified the firewall on at least one system on the segment to open the port and allow that system to function as a file and print server.
Let's start looking at the most fundamental aspect of Windows Firewall control: turning it off and on. You can disable and enable Windows Firewall under SP2 in three ways: through the GUI, from the command line, and through Group Policy.
Using the GUI
The XP GUI has changed a bit since its pre-SP2 days, at least insofar as Windows Firewall is concerned. Depending on how your GUI is set up, when you click Start, Control Panel, you should see a category named either Network Connections or Network and Internet Connections. If you see the Network Connections category, you might see in the left pane a Network Tasks section that contains a Configure Internet Connection Firewall link. If so, click that link. If you see instead a Local Area Connection link (referring to a wired Ethernet adapter) or a Wireless Network Connection link, right-click that link, choose Properties, click the Advanced tab, then click Settings. If you have a Network and Internet Connections category instead of a Network Connections category in Control Panel, click that category, then, under Pick a task in the left pane, click Configure your firewall.
Regardless of which route you take, you should see an Internet Connection Firewall Properties page. (The final SP2 code might call the page Windows Firewall Properties.) The page has tabs named General, Exceptions, Network Connections, Log Settings, and ICMP. The General tab offers three radio buttons: On (recommended), On with no exceptions, and Off. Click Off, click OK, then close Control Panel, and Windows Firewall will be disabled.
Using the Command Line
You might prefer to disable Windows Firewall from the command line if you're a command-line junkie like me or if you want to change Windows Firewall settings en masse and can't use Group Policy, perhaps because you don't yet use AD. With SP2, the already powerful Netsh command gains a new set of options for controlling Windows Firewall. You can shut off Windows Firewall altogether by opening a command prompt and typing
This command turns off the firewall on any and all NICs on your system.
But suppose you don't want to turn off Windows Firewall on all your NICs. For example, suppose you like the idea of enabling the firewall on your wireless NIC and want to disable it only on your Ethernet card. You can use the Netsh Set Opmode command with the interface=name parameter. If your system's wireless card is named wireless network connection and its Ethernet card is called local area connection, you can use the following commands to turn Windows Firewall on for the wireless card and turn it off for the Ethernet card:
set opmode mode=enable
netsh firewall ipv4 set opmode
Veteran Netsh users will note that unlike other Netsh parameters, the interface=name parameter requires you to fully name the interface. If the interface=name parameter worked like other Netsh parameters, interface=w would be sufficient to differentiate the wireless network connection interface from the local area connection interface. But at least in the SP2 beta that I worked from while I was writing this article, you must type the complete interface name.
Using Group Policy
In addition to the GUI and the command-line interface, XP SP2 lets you disable Windows Firewall from Group Policy Editor (GPE) as either a local or a domain policy. You've always been able to turn off the firewall from a Group Policy Object (GPO), but the ability was very limited—turning off the firewall was about all you could do. SP2 provides an entirely new category (i.e., folder) of GPOs to control Windows Firewall.
In GPE, navigate to Computer Configuration, Administrative Templates, Network, Network Connections, Internet Connection Firewall, as Figure 1 shows. Inside the Internet Connection Firewall folder are two more folders: Domain Profile and Mobile Profile. This notion of Windows Firewall's two profiles is important, so let's sidetrack and consider it.
Two Windows Firewall profiles. Microsoft recognized that many people wouldn't want to enable Windows Firewall on systems inside the network but that they might want to enable Windows Firewall when those systems were outside the network. Consequently, Microsoft made the firewall smart enough to determine whether the machine is logged on to a domain. When it is, Windows Firewall follows the instructions in the Domain Profile folder. But when the machine isn't logged on to a domain (note that Windows Firewall determines whether the machine, not the user, is logged on to a domain), Windows Firewall looks to the Mobile Profile folder for its marching orders.
As I mentioned, SP2 Group Policy represents these two sets of policy settings as folders, or categories in Group Policy-speak. Each folder contains the same nine policy settings, one of which is called Operational Mode. You can disable Windows Firewall through the Operational Mode setting. To turn off Windows Firewall, change the setting to Disabled and apply the policy.
Operational Mode has two other possible states: Enabled and Shielded. The Enabled state turns on the firewall and lets you open any ports that you need to. If you might want to turn on Windows Firewall when your machine isn't attached to your domain, set the Domain Profile folder's Operational Mode to Disabled and set the Mobile Profile folder's Operational Mode to Enabled.
The Shielded state turns on the firewall and ignores requests to open incoming ports. The idea behind this setting is that if a worm were attacking your network, you could enable Shielded mode, shutting out all unsolicited incoming data and rendering the worm incapable of infecting your systems.
A GPE note. If you're creating a domain-based GPO to control Windows Firewall, you'll need to do a little preparation. Because the Windows Firewall policy settings are all new, your Windows Server 2003- or Windows 2000-based domain controller's (DC's) copies of GPE (gpedit.msc,) almost certainly won't display the Windows Firewall policy settings. (I say "almost certainly" because a Windows 2003 system that's running Windows 2003 SP1—which is supposed to ship some time this year—would have the settings. That service pack will modify Windows 2003's firewall in the same way that XP SP2 modifies XP's firewall.)
To create a domain-based GPO that includes the new Windows Firewall settings, load the Windows 2003 administration tools onto an XP box that has SP2 installed. Open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in (for a site policy, open the MMC Active Directory Sites and Services snap-in) at that XP system. You can then create or edit a GPO that includes the new policy settings.
Configuring mobile and domain profiles from the command line. Domain-based Windows Firewall policies are great, but users who aren't yet running AD are likely to turn to batch files for help. The mobile and domain profiles make Windows Firewall more attractive, but can you control them from the command line? The answer is yes—you can even set up mobile and domain profiles from the command line.
To control Windows Firewall's behavior in a particular profile, just add the profile= parameter to the Netsh Set Opmode command, followed by the keyword current, all, corporate, or other. The current keyword tells the system to make the change to the active profile. The all keyword means make this change to both profiles. Less obvious are the corporate keyword, which changes the domain profile, and the other keyword, which changes the mobile profile. (I sometimes get the idea that lots of people at Microsoft are working on Windows Firewall and that they don't all talk to one another.)
Suppose I want to use the command line to set up a system that turns off Windows Firewall while the system is connected to a domain and turns on the firewall otherwise. The following two commands accomplish that task:
netsh firewall ipv4 set opmode
Armed with these basics, you can get started using Windows Firewall's power. But let me stress two things. First, I don't recommend turning off the firewall in mobile mode. Second, I think that enabling the firewall isn't a bad idea even inside a domain.
We've just scratched the surface of Windows Firewall's abilities, and they really are worth understanding better. In an upcoming article, I'll dig deeper.