News

Review: Windows XP's Built-in Firewall

• By Stephen Swoyer
• 09/24/2001

While Windows XP’s ICF could be a more than adequate solution for many SOHO implementations – and although it might conceivably pass muster as a combined firewall/router solution for some remote office environments – it understandably lacks the security and configurability of a dedicated stand-alone firewall solution.

As its name suggests, ICF is actually an enhancement to the Internet Connection Sharing (ICS) technology which first appeared in Windows 98 and in Windows 2000. ICS offers base-level Network Address Translation (NAT) routing and is something of a poor cousin to the beefier and more robust NAT implementation that Microsoft ships with Windows 2000 Server and Advanced Server.

In Windows XP, ICF is closely tied to ICS: Set a user’s PC up for ICS routing, and ICF will automatically be applied. It’s also possible, however, to configure an end user’s PC to support ICF in the absence of ICS.

ICF is a stateful firewall, but, unlike its more full-featured standalone brethren (e.g., firewall products from Checkpoint Software and from Symantec), it inspects inbound traffic at the packet level but does not filter outgoing packets. Instead, ICF maintains a table of outgoing information requests. When incoming packets arrive, ICF queries its table to make sure that they were requested in the first place.

If the packet traffic has been legitimately initiated by a local application, by the operating system, or by applications or operating systems on an ICS private network, ICF lets it pass. If it hasn’t, it unceremoniously drops it. Helpfully, ICF writes suspicious events of this kind to a log file.

ICF is simple to install, and can easily be invoked by means of Windows XP’s “Network Setup Wizard,” a dialogue box-based graphical tool that walks an end user through the process of connecting her PC to the Internet and – if she so desires – of allowing other PCs to connect to the Internet through her system (by means of ICS). In some cases –- if a user is setting up her PC as a standalone system or as an ICS gateway –- the Network Setup Wizard automatically initiates the installation and configuration of ICF. If a user’s PC is attached to a private internetwork and connects to the internet through a separate gateway, however, the Network Setup Wizard will not support ICF.

Experienced users can also manually configure and enable ICF by opening up a network adapter’s “Properties” menu and by selecting the “Advanced” tab.

ICF performed very well in our tests. We used the popular Unix nmap tool to run a series of common scans against our Windows XP test client. When we ran an nmap TCP connect scan (nmap –sT) against a Windows 2000 Advanced Server test system that was directly connected to the Internet and which was running RRAS and NAT, nmap returned a wealth of information about the system in question, identifying all of its open ports and mapping them to the services that they were hosting. Ditto for an nmap TCP SYN scan (nmap –sS) -– a probe that can trick a system into divulging on which ports it’s listening for TCP traffic –- which not only returned a list of open ports and of relevant services, but also responded with TCP Sequence Prediction and with TCP/IP Fingerprint information, as well.

When pitted against Windows XP with ICF enabled, nmap fared considerably worse, however. In response to our TCP connect scan (nmap –sT), for example, ICF returned … nothing. Nmap even went so far as to suggest that there was no host at the address specified. Ditto for our nmap TCP SYN scan (nmap –sS). We’re by no means nmap gurus – and we’ve been told that nmap in the right hands is an intelligence-gathering tool par excellence -– but we couldn’t get it to return anything when arrayed against Windows XP and ICF. As far as a potential malicious hacker, or ne’er-do-well script kiddie, for that matter, is concerned, a Windows XP system with ICF enabled doesn’t even exist on the public Internet.

Clearly, then, Windows XP’s ICF leverages the old firewall trick of not letting others do unto it unless it’s already first done unto others: If an XP client doesn’t initiate traffic with another system, it simply won’t respond to or otherwise acknowledge the requests of the system in question. This goes for anything from ping requests to SMB traffic.

This approach is not without drawbacks of its own. Application compatibility – especially with regard to network-bound services such as e-mail and FTP, but with respect to peer-to-peer and other collaborative applications – could be problematic. And NetBIOS file-sharing capabilities can also be constrained. For this reason, Microsoft says that ICF should never be enabled on client systems which connect to a private internetwork.

In order to enable support in ICF for e-mail, FTP and for other network-bound services, a user must manually access the “Advanced” tab of the ICF-enabled adapter’s “Properties” menu. Once there, she’ll next click on the “Settings” button and then navigate to the “Services” tab in the menu which next appears. Finally, she’ll have to choose each of the services (e-mail, FTP & etc.) for which she wants to enable support.

This is all well and good for services which leverage standard protocols and for which ICF provides canned support. But what about an e-mail application such as Microsoft Outlook, which communicates with an Exchange Server by means of RPC? After all, ICF won’t let unsolicited RPC traffic pass through the firewall, which means that – at worst – a user won’t receive the near-instant notification of new mail that she’s accustomed to. She’ll have to manually query the Exchange server for new mail.

ICF represents a surprisingly good base-level firewall effort from Microsoft. Although it lacks the features and configurability of its more seasoned standalone brethren, it also lacks their larger price tags, as well.