Republished with permission from WatchGuard Technologies, Inc.


What Does Windows Firewall Actually Do?

By David M. Piscitello, President, Core Competence

[Editor's Note: Numerous articles have been written on how to operate and configure Windows Firewall, including a painstakingly detailed user guide from Microsoft Corporation. Dave has compiled an impressive number of these useful resources and made them available at At that site, as in the article below, Dave suggests practical deployment guidelines for Small and Medium Businesses, perfect for most LiveSecurity subscribers. -- Scott Pinzon]

It's possible that no software upgrade has ever received as much and as contradictory attention as Windows XP Service Pack 2 (SP2). A major upgrade that includes new features and a radically different (for Microsoft) default security posture, SP2 is a lightning rod for controversy and confusion. In many respects, the hype far outdistances reality. The hype surrounding Windows Firewall is a good example. Depending on whom you believe, Windows Firewall either single-handedly breaks countless business-critical applications, or it doesn't do anything. As usual, the truth lies somewhere in between. Before you decide what role Windows Firewall can play in your network, this article can help you sort the myths from realities; learn what Windows Firewall offers; and consider ways it can help your organization improve client system security.

Myths and mis(sed) configurations

Experts forever criticize Microsoft for choosing ease of use over secure behavior, and have especially criticized how exploitable Windows operating systems are when default configurations are left unmodified. With SP2 installed, XP is no longer the easy pickings Windows operating systems once were. Windows Firewall is on by default, and enabled early in the system startup process, to provide boot time security. Windows Firewall begins immediately after the network (TCP/IP) stack, so it blocks attacks that might succeed before a firewall service begins protecting a system.

Windows Firewall's default security policy blocks all unsolicited incoming traffic. This means that Windows Firewall blocks all packets that it cannot associate with any outgoing connections or requests. This default policy is applied globally, to all network connections. The only allowed incoming connection in the default policy is Windows remote assistance. You can't even ping XP SP2 systems when the default policy is enforced. This strong DENY posture is exactly opposite from Internet Connection Firewall in XP prior to SP2, and accounts for a number of claims that XP SP2 breaks applications. Windows Firewall isn't breaking applications. It's doing exactly what critics have asked Microsoft to do for a while. Ironically, Microsoft is now being criticized for forcing users and administrators to begin with an inbound policy of, allow only what is expressly permitted.I'm sure the irony is lost at Redmond.

With Windows Firewall's default inbound traffic handling policy enabled, all "server services" that users attempt to run are blocked. This policy can reduce or eliminate rogue FTP, Web, P2P, and IM (file transfer) servers. However, commonly used networked services like Microsoft's File and Printer Sharing, and Universal Plug and Play framework, are also blocked by default. This is a sound default behavior for a user visiting a public wireless kiosk or a broadband user connecting from a home LAN, but it may interfere with how users access applications and peripherals on trusted LANs in the workplace. Windows Firewall's default policy may also interfere with how your IT staff manages systems and offers helpdesk support. Also blocked by default: SNMP agents installed on client systems; centralized patch management systems like Shavlik's HFNetChkPro; and Microsoft's own remote desktop connection client.

To handle such situations, you must configure exceptions to Windows Firewall's default incoming traffic policy. An "exception" is an allow inbound traffic rule Windows Firewall will apply to an application, ICMP traffic (e.g., ping), or a TCP/UDP port. Windows Firewall exception rules persist following system shutdown and restart. What if users require different firewall policies depending on the network connection they use (at work, at a WiFi hotspot, at home)? Administrators can accommodate them by applying exceptions to individual network connections. Windows Firewall also provides the ability to limit or scope incoming traffic exceptions to specific IP addresses or IP subnets: you can create sets of exception rules for situations where a single network connection, like a 10/100 Ethernet adapter, is used at home and at the office.

Misconceptions and missed opportunities

Windows Firewall does not interfere with services commonly required for systems to join networks, e.g., DNS, DHCP, and domain controller access. Windows Firewall only handles incoming traffic policy. XP's default outbound traffic policy, allow any outbound traffic, does not change when you install SP2.

Leaving the default configuration of an XP system unprotected from many spyware applications, back channels, and trojans is one of several "missed opportunities" for Microsoft. By comparison, third-party personal firewall software like Zone Alarm, Tiny PFW, and Kerio begin with deny all outbound traffic. Access to IP Security Policies isn't available from Windows Security Center, the control panel Microsoft offers as a way to manage your Windows security settings. To modify outbound traffic handling policy you must configure Internet Protocol security (IPSec) policies, which is a difficult configuration task for non-technical users. By making outbound policy configuration this challenging, Microsoft has all but assured that relatively few users will modify the defaults.

Windows Firewall logging presents another missed opportunity. Windows Firewall can log dropped packets and successful connections, and per packet log information is easy to interpret (see "Interpreting the log file" in Microsoft KBA 875357). But logging has been implemented poorly:

  • It is disabled by default
  • The initial log file size is too small
  • The maximum size is only 32767 KB
  • The log file is neither maintained the same way as other NT event logs (System, Application, Security), nor accessible via Administrative Tools.

Adding insult to injury, the log file is thoughtlessly and irreverently dumped into C:\windows.I It's almost as if poor pfirewall.log has been shunned by its event log peers.

Where should SMBs use WF?

The addition of Windows firewall to the methods of safeguarding Windows XP systems provides administrators with some confusing and interesting possibilities.

The most common source of confusion is whether one should use Windows Firewall, a third-party personal firewall, or both. On the surface, "both" seems appealing because it's philosophically consistent with the strategy of deploying defense in depth. In practice, "both" is proving to be the least attractive: third-party firewall users report conflicts, and configuring a consistent policy across two software firewalls is challenging for non-technical users.

Disable Windows Firewall and use a third-party firewall if you:

  • Have many non-technical users
  • Want to enforce or encourage a strict outbound traffic handling policy
  • Must offer self-administration to your users.

Your users will manage security best with a single, simple user interface.

This doesn't necessarily leave Windows Firewall with no role in your organization. Many organizations do not use (or they disable) personal firewalls on intranet (trusted LAN) connections. This leaves computers vulnerable to worms, blended threats, and other malicious code that distributes itself using anonymous file shares or other LAN applications. As Microsoft explains in its Windows Firewall jargon, unprotected systems can be "infected with a malicious program (such as a virus or worm) that uses unsolicited incoming traffic to spread to other computers." If you're concerned about malware, you could reasonably argue for using Windows Firewalls on non-mobile systems in trusted LANs, both wired and wireless.

Should any organization consider a universal adoption of Windows Firewall and IPsec policies instead of third- party personal firewalls? Some organizations have strong incentives to eliminate self-administration and centrally administer Windows XP systems. For such organizations, administering client firewall policy using Group Policy and directories, for example, may be acceptable and prove less costly than purchasing and administrating third-party software.

Many organizations feel they will be well served if they eliminate self-administration, and will want to eliminate Windows Firewall self-administration as well. For example, administrators can use Windows Firewall Group Policy settings and Active Directory to define a standard inbound traffic handling policy; block users from creating local policy exceptions; and to enable logging on all computers they manage. Administrators can create a standard outbound traffic handling policy using IP Security policy, as well. Define a group policy that accommodates your application mix and remote computer management, and push it to your users when they log on. Even if you aren't using Active Directory, Microsoft explains several alternative methods of deploying a common Windows policy configuration in Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2.


When the smoke clears and the noise of battle subsides, many IT professionals will look back and think, "Why all the fuss over Windows Firewall?" Eventually, whether Windows Firewall is all it could be will become a moot question. Windows Firewall represents an important initial step towards client Operating System default security policies that adhere to the philosophy, that which is not expressly permitted is prohibited. This is a Very Good Thing. Don't dismiss Windows Firewall out of hand. Instead, consider whether you can use it to improve your security baseline in areas where you have not yet implemented personal firewalls.


For specifics on how Windows Firewall interacts with Firebox management software, read "When Firewalls Collide." For even more information, visit Dave's Windows XP Security and Performance Resources.

Copyright© 2004, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.

Copyright © 1996 - 2004 WatchGuard Technologies, Inc. All rights reserved.