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.
When To Use (or Not Use) WF
Enabling Windows Firewall doesn't make sense on every machine, but I think it's a good idea for many. I think that there are factors that people might consider when deciding whether or not to enable WF on a given system:
- Does your network have a hardware firewall already, and is the system inside that firewall's area of protection?
- Are you already using another software firewall on the system?
- Does the system primarily act as a server, or instead as a client?
- Is the system directly connected to the Internet?
Let's consider each in turn.
If the System is Protected with a Hardware Firewall, Use WF Anyway
At first glance, it might seem silly to have two levels of firewalls—a hardware router between the intranet and the Internet, what is sometimes called a perimeter firewall , and a software firewall on every workstation. But it makes good sense because of, again, our friend the buffer-overflowexploiting worm.
Once again, a worm needs two things to attack a system: a bug that's not been patched and access to the port "connected to" that bug. So, returning to the Blaster example, wouldn't a perimeter firewall protect systems inside that perimeter?
The answer is no, probably not. So long as the worm is running around on the Internet then yes, the perimeter firewall protects the systems inside that perimeter, because I don't know of anyone who lets a firewall pass port 135; it's one of the few dozen "what are you, crazy ?" ports—ones that most of us don't expose to the Internet. But suppose there's a leak in that perimeter? When discussing this with clients, I like to ask two questions:
Question 1: "Do you let people take laptops outside of the office? You do? Great. But you don't let people bring them back in, do you?"
What I'm saying here is that if the worm gets past the firewall and is on your intranet, then the perimeter firewall no longer stands between the worm and port 135. (Again, remember that I'm just using 135 as a common example. Other worm exploits have targeted bugs attached to other ports.) In other words, once you're past the front gate, there's no security and, if anything, many people are more lax than usual about security on their intranet because "we have a firewall." This has led to security types observing over the years that many networks have what they call "candy bar" security because it's "hard and crunchy on the outside, but soft and chewy on the inside."
Suppose your employee Felix takes an unpatched company laptop out of the building on the afternoon before Blaster hits. He takes it home and plugs it into his cable modem, which directly connects him to the Internet. Blaster hits and his system is infected. Felix returns to work the next day, plugs into the company intranet, and in no time, the worm has found worm food by the cubic yard in your company's network.
Question 2: "Do you have any wireless networks in your organization…that you know of?"
Anybody with $75 can become the proud owner of a Linksys WRT54G wireless-G router. They're great, I use 'em all the time, albeit with encryption and with a modified administrator password. But not everyone takes those precautions. Think of the convenience, our friend Felix muses, of being able to put my laptop anywhere in my office, or even down the hall, instead of needing these annoying Ethernet cables! So Felix picks up a wireless router in Wal-Mart, brings it into the office, plugs it in to the power and the network jack, runs the wizard that sets that router up, and now he—and your organization's network—are "on the air." And I'll bet that Linksys router's still got the password "admin," the default out of the box. Result? Anyone in the parking lot can get onto the router…and therefore inside your firewall's perimeter. Just think: drive-by worms, just another convenience (sigh) that computers offer.
Until worms become a thing of the past, it's better to think of the perimeter firewall as a good idea but not a complete solution. I mean, there's a reason why NASA has astronauts keep their spacesuits on when their rockets are doing dangerous stuff like taking off or re-entering.
If Already Using a Software Firewall, Don't Use WF Usually
As I mentioned earlier in this chapter, lots of folks offer software firewalls, and several of the big security suites include them, so you might just already have a software firewall on your system. If that's the case, and if you're happy with what that software firewall does, then stay with it, and forgo WF.
Why? Because WF's fairly minimal set of features is probably improved upon in every way by a third-party software firewall. That might, however not be the case entirely, as WF's ability to be administered centrally through group policy might save you a lot of time over some of the thirdparty software firewalls. I suggest that you look at the features of WF and the alternative, and choose one. Running two software firewalls can lead to all kinds of unexpected behaviors, like network lockups or inexplicable inabilities to talk to some server.
Workstations Always Need Firewalls, Servers Almost Always
Part of your decision criteria is whether or not you're considering turning WF on at a system that's primarily a client—that is, a workstation system—or primarily a server—that is, a server system. (And yes, I know, this is a server book, but WF appears on both 2003 Server and XP with SP2, so it's worthwhile taking up a workstation topic briefly.)
I believe that you'd be wise to enable WF (or some other firewall) on all of your XP systems. Recall that the main foundation of WF's firewall functionality is stateful inspection, which says, "I reject incoming packets unless they're server responses to a request from this client." As workstations mostly act as clients in the client-server world, they'll be largely unaffected by enabling the firewall, and of course they'll get some protection from any future worms.
Now, let me be very clear here: there is one very significant and troubling side effect of turning on WF on a workstation: remote control tools stop working. You can't use an MMC to remotely control a firewalled workstation; you can't use Remote Desktop to run a session on it; and the like. This isn't an insoluble problem, but it does mean that you may have to create some exceptions to allow those remote control tools to work, and you'll have to think long and hard about which exceptions to allow, as the ports you'll have to open to enable remote control are often the very same ones that have been the favorites of worms throughout the ages. (We'll take up the question of which ports to open a bit later.)
Servers require the same kind of analysis, and more of it. Inasmuch as servers mainly host the server side of client-server applications, and inasmuch as servers don't start conversations, they respond to them, then servers must open the ports needed to let client requests through. Again, this will require a bit of study before it's safe to enable WF on your servers. But I would argue that enabling WF or some other firewall on each of your 2003 SP1 and R2 servers is overall a good idea.
Won't Enabling the Firewall Kill Domain Membership?
When Microsoft announced that they were going to not only install a new firewall on every XP, 2003, and later system, and that the firewall would be enabled by default on desktop OSes, the whole idea struck me as insane at first. All systems, I wondered? What about domain memberships? Wouldn't a system running on an intranet with domain controllers become unable to "hear" those domain controllers?
No, I eventually realized, firewalls don't get in the way of domain membership because, recall, anything gets through the firewall, as long as the conversation is initiated by the client. So, for example, when an XP box wants to log on, then it does so with the help of a domain controller. The XP box acts as what might be called a "logon client," and the domain controller acts as the "logon server." The XP box started the conversation by saying, "Please log me on," and when the DC responds, that response passes through the firewall. When the XP box requests your roaming profile, the response is unaffected by the firewall because the XP box started the conversation, and when the XP box requests group policy information every hour and a half or so, the response passes through the firewall because of the XP box's having spoken first.
That's not to say that raising a firewall on workstation OSes wouldn't cause a few support headaches. Domain membership isn't affected, but remote control tools stop working in a firewall scenario unless you noodle with the firewall settings, as you'll see later.
If Connected Directly to the Internet, Enable a Firewall
As I travel a lot, and my laptop runs XP (x64 Edition, actually), I end up plugging my system into a lot of different Internet hookups—hotels, conferences, airports, and so on. Who's running those networks? Heck, I have no idea. But I do know that when I connect to one of these public Internet providers, I often end up with a routable IP address. In other words, there's nothing between me and the big, scary old Internet. So turning on WF is a great idea in that case.
Yes, I know, that was a workstation example, and this is a server book. Who directly connects their servers to the Internet? Some people do, and I don't think it's a terrible idea, as long as the system is firewalled. Servers directly on the Internet are often on the Internet because they're offering some specific set of services across the Net, and in most cases that's a pretty small set of services— web, email, and DNS are a common triad. In that case, the prescription for better security is simple. First, turn on WF. Second, collect the ports that people use to communicate with the server (probably TCP ports 80, 443, 25, and 53 and UDP port 53 in this case), and only open those ports. And if you're wondering how you'd know which ports to open, we're going to discuss the Security Configuration Wizard in a few chapters. It will examine the services that you're offering and suggest which ports to open.
By now, I've covered "how it works" and "why and when to use it," and I hope that I've convinced you that WF's got some value.
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