Windows Firewall Basics

A good, but not great, list of abilities. Still, a great improvement over the ICF firewall originally shipped with XP and 2003.

The Specific WF "Firewall Rules"

Still wondering if WF is worth looking at? Then let's get very specific about what it blocks and what it can't block, why Microsoft took the time to create this newer WF, and whether or not you should consider enabling it on your 2003 or R2 system (it's disabled by default) or whether to disable it on your XP boxes (it's enabled by default). First, let's more exactly answer the question, "How does WF decide whether to block or pass information?" With just a few rules.

WF Must Be Enabled to Do Anything

First, of course, it's got to be enabled before it'll monitor packets. It is, again, off by default on Server 2003 SP1 and R2 and on by default on XP SP2.

WF Never Blocks Outgoing Traffic

If your computer wants to send out an IP packet of any kind to any system on the Internet, then WF couldn't give a hoot. Now, this turned out to be a fairly controversial issue at Microsoft, and an early version of WF in XP SP2 could block outgoing traffic. The idea was that if the buffer overflow worm du jour entered your system via port 515 (I'm making that up) and, after infecting your system, it tried to communicate with other systems on port 515, then it might be nice to be able to write a group policy that would block any outgoing messages destined for port 515, caging the worm until all of the infected systems could be found and disinfected. It didn't seem like a bad idea at the time, but some folks had an argument against it, and so WF will always pass outgoing packets. (And, in an interesting Part 2 to the story, Vista's version of WF will supposedly allow you to block outgoing packets. We'll see.)

WF Blocks All Incoming Packets Except Ones that Are Responses to Requests, or if the Packet Is Destined for a Port that You Have Made an Exception For

For example, suppose you're sitting at a Server 2003 SP1 system with WF enabled. You start up IE to visit Microsoft Update. WF does not block the outgoing initial request to Microsoft Update, as I've already said. But it also remembers that there's an outstanding HTTP request to Microsoft Update.

Eventually Microsoft Update's web server sends a packet back to your 2003 SP1 system. WF is by nature suspicious of any incoming packet and so examines this one with the full intention of just dropping it on the floor. But then it consults its state table, which reminds it that this packet is from Microsoft Update, and we're expecting a response from Microsoft Update, so it passes.

Alternatively, suppose that Server 2003 system that I just said you accessed Microsoft Update from also runs server software of some kind; suppose it's running some SMTP/POP3 software and so acts as an Internet email server. SMTP uses TCP port 25 and POP3 uses TCP port 110. Thus, if this server is your firm's email server, then whenever anyone outside of your organization tries to send you some email, they (well, their email server, actually) will do that by sending a request to your 2003 server on its port 25. If the firewall's up, then what happens? Well, a request from some outsider that your 2003 server receive some email looks to WF like an unsolicited communication. Now, recall my note from a few pages back: clients solicit, servers respond . Put that together with what you've seen about WF's packet filtering rules, and I hope you'll see that turning on WF on a server of any kind presents a big potential problem:

NOTE: Because the requests that get client-server computing going are by their nature unsolicited, installing a stateful firewall on a server will make that server useless…unless you get the firewall to relax a bit.

By "relax a bit," I mean that a purely stateful firewall wouldn't work on a server; instead, stateful firewalls must also let you make what Microsoft calls exceptions . There are two kinds of exceptions: port exceptions and program exceptions . A port exception is just WF's way of acting like an old-style port-filtering router. Using the command line, GUI, or group policy, you'll see a bit later that you can say, "Hey, WF, let in any traffic on port 25, whether it's solicited or not." A program exception, in contrast, is where you say to WF, "Hey, whatever ports XYZ program needs you to open for unsolicited communications, just open." Once you open port 25 on the 2003 server, the mail can arrive.

So you've seen how WF would allow a response to pass because of WF's state table, and how it might allow a piece of Internet email to pass because of an exception. Now let's consider a situation where you wouldn't want WF passing a packet. Suppose there were some buffer-overflow-exploiting worm floating around, knocking on port 515 of every system that it meets to see if that system has the imaginary "port 515 vulnerability" that I supposed earlier. In this case, WF would see the incoming packet, examine its state table, and say, "Hey, we didn't initiate a conversation with that system; discard the packet," and the packet never gets to port 515 on our Server 2003 system.

Those three cases are, in a nutshell, examples of what WF does most of the time: pass all outgoing traffic, pass incoming responses, pass incoming exceptions, and reject all other incoming traffic.

The preceding excerpt is from Chapter 8 of Mark Minasi's book, "Mastering Windows Server 2003 Upgrade Edition for SP1 and R2". Visit amazon.com to purchase the book or click here to read the entire chapter.

Mark Minasi is a best-selling author, commentator and all-around alpha geek. Mark is best known for his books in the Mastering Windows series. What separates him from others is that he knows how to explain technical things to normal humans, and make them laugh while doing it. Mark's firm, MR&D, is based in Pungo, a town in Virginia's Tidewater area that is distinguished by having one -- and only one -- traffic light. Copyright 2005 TechTarget

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Microsoft Windows security tools Troubleshooting Microsoft WSUS connectivity issues Windows security tools for the busy desktop administrator Four Internet Explorer 8 group policy security settings Microsoft Stirling security console delayed for more integration Why should Windows shops use Microsoft Baseline Security Analyzer? Using Sysinternals tools in security management scenarios Sysinternals tools: A must-have for every Windows security toolbox Windows security tools roundup Top Windows client security tools for end users Tools for virus removal and detection

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary