Windows Firewall Basics
By Mark Minasi
Mark Minasi is a best-selling author, commentator and all-around alpha geek. He is best known for his books in the Mastering Windows series. The following excerpt is from chapter eight of Minasi's newest book, Mastering Windows Server 2003 Upgrade Edition for SP1 and R2, entitled "Windows Firewall Basics." Read the entire chapter here.
Writing that batch file might be impressive, but, again, it'd be a lot of work. Fortunately, you needn't do that, because of the things that WF does. Put briefly, here's an overview of what kind of firewall services it offers and what else might be appealing about it.
- Basically, WF is a stateful packet filter; by default, all packets trying to enter a system with WF enabled will be discarded unless those packets are responses to queries from that system. Unsolicited packets never get past the TCP/IP stack.
- WF lets you create exceptions for particular ports from particular ranges of IP addresses; for example, it's possible to say, "Accept unsolicited packets on port 25, but only from the range of addresses from 192.168.0.1 through 192.168.0.254." When paired with IPsec on Server 2003 and R2, WF can do some impressive things via something called IPsec bypass
- Windows lets its firewall behave in two different ways ("profiles"): one where the system is inside the corporate firewall, and another when outside the firewall. (Clearly having two different behaviors for WF is of more interest to XP users—XP SP2 introduced WF—than to server users, as most of us don't carry our servers outside the building.)
- WF may not be the most full-featured of firewalls, but it may have the most broad-spectrum means of control of almost any Windows feature. First, you can control it from a fairly comprehensive command-line interface via the netsh command. Second, WF has near-complete group policy setting-based control. Finally, it's got a GUI.
- Unlike its predecessor ICF, Windows Firewall starts up before the TCP/IP stack does. ICF had the troublesome aspect that it started after the TCP/IP stack did, leaving the stack unprotected for a few seconds on bootup.
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