Countdown to XP SP2: Dealing with ICF

In preparation for the release of Windows XP Service Pack 2 (SP2), I want to pass along some of the insights I've gained about the upcoming service pack and some of its pros and cons. In the previous installment of this Web-exclusive VIP column, "Countdown to XP SP2: Forced Protection," (April 2004, InstantDoc ID 42496), I discussed my initial concerns with what will probably be SP2's most significant feature: the automatic enabling of XP’s Internet Connection Firewall (ICF)—which, as it turns out, will be known as Windows Firewall. When I first began exploring this feature, I worried that it would wreak havoc on corporate networks and home offices alike. As it turns out, I was wrong ... or at least I overestimated the potential problems.

Initially, I worried that an XP SP2 system on which Windows Firewall was enabled wouldn't be able to participate as a domain member because ICF passes only those communications initiated by the XP machine. If an XP client asks a Web server for information, when the Web server tries to deliver the data to the XP client, ICF says “Hmm ... incoming data ... are we being hacked? No, this data is just the answer to a question that my system asked. Go on through.” But ICF won't pass communications that weren't initiated by the XP system. For example, you won't get a response when you ping an XP system that has ICF enabled. ICF discards the ping request that your system sent to the XP system because the XP system didn't initiate the conversation.

So how does this behavior affect XP SP2 systems that function as domain clients? Well, because domain clients initiate conversations with servers, Windows Firewall should pretty much stay out of the way. The client initiates authentication requests, so server responses will pass Windows Firewall scrutiny. Roaming profiles are nothing more than a fancy name for client-initiated NET USE commands and file-copying operations. And although Group Policy seems like a central Active Directory- (AD-) oriented tool, policy implementation is in fact client-driven rather than server-driven and therefore Windows Firewall–proof. For use on simple domain clients, then, SP2 probably won't pose the troubles I'd worried about.

So after some thought, I realized that the bottom line is that turning on Windows Firewall will probably result in a net positive, even for systems inside an intranet—if you've planned ahead. The fact remains that all your XP clients' server functions will become useless unless you tweak SP2's default Windows Firewall implementation. “Server functions?” some of you might be thinking. “Who uses a workstation for server functions?” The vast majority of us do. Here are a few examples of server software you might want to run on your XP systems and how you'll need to tweak Windows Firewall to let these tools work.

Remote Desktop and Remote Assistance. Remote Desktop and Remote Assistance are two Terminal Services-related tools that work by installing a bit of server software on your XP workstation. Remote Desktop Client is a simple piece of client software that you run on another system, then use to control your XP workstation remotely. The system running Remote Desktop Client tries to start a conversation with the XP workstation on port 3389. To allow these conversations, you’ll have to open that port on the target system.

The Manage Computer console. The highly useful Microsoft Management Console (MMC) Manage Computer snap-in lets you control your local system as well as any other system for which you have an administrative-level account. When you direct Manage Computer to control a remote XP system, the snap-in attempts to contact a bit of server software, called Microsoft Remote Procedure Call (RPC), on the target system. You'll need to open port 135 on the target system or Windows Firewall will foil any remote-connection attempts.

File sharing. Many administrators perform at least some remote administration by connecting to “administrative” file shares such as C$ and D$. In such cases, the system that's being remotely administered acts like a low-power file server. To make these connections, you'll need to open port 139 or port 445.

Ping. As I’ve already mentioned, turning on Windows Firewall will by default cause XP SP2 systems to ignore ping requests. I find Ping to be a useful tool and my job would be more difficult if my workstations all stopped responding to pings. Configuring Windows Firewall to respond to pings requires some extra configuration. (I can't recommend that you open particular ports because, strictly speaking, Ping doesn’t use ports.) For more information tweaking Windows Firewall, see the Windows & .NET Magazine article "Meet Windows Firewall" (May 2004, InstantDoc ID 42293).

Network Neighborhood. Although most of you probably aren't worried about using XP SP2 on a home network, I don’t want to neglect that possibility. XP systems on which Windows Firewall is enabled and that run in a small network without a WINS server can't resolve names of other systems, even when those other systems are on the same network segment as the XP machine. This problem will cause some headaches for small home networks when, all of a sudden, XP SP2 systems can’t find networked printers and file shares. The workaround is to open up file sharing, but that probably isn't such a good idea considering that access to file-sharing ports was what let W32.Blaster in. Perhaps it’s time to dust off LMHOSTS files again? Yuck.

As for that new set of Group Policy settings for Windows Firewall control that I mentioned in my previous article: It looks as though these settings will make opening ports from a central location—AD—relatively simple, but you’ll have to create the necessary Group Policy Objects (GPOs) before you deploy SP2 to avoid an upheaval. Get a jump on that task by reading the Microsoft white paper "Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2."