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.
Check out the second half of this chapter excerpt, Setting up IPsec bypass, from Mark Minasi's book, Mastering Windows Server 2003 Upgrade Edition for SP1 and R2.
I know, this has been a long chapter, but if you're still with me, then I'll let you in on a secret: I saved the best for (almost) last. Quietly embedded in Windows Firewall, which first shipped with XP SP2 in August of 2004, is a pretty neat technology, and one that also offers a look at some of the new version of Windows Server's upcoming surprises.
What IPsec bypass can do for you
The technology that I'm talking about is called IPsec bypass. To understand it, let's review some of the main principles comprising Windows Firewall:
- When you enable WF on a given computer, then by default no outside systems can initiate communications with your computer.
- This makes it secure, but too secure. If it's a server, then servers that you can't approach are kind of useless. A raised firewall without exceptions makes even workstations more trouble, as we, at minimum, want to ping workstations and usually want to do some kind of remote control on them, which requires a small amount of server-like behavior. Trying to connect to a workstation via a remote control tool is essentially an unsolicited conversation, which the firewall would reject.
- In the real world, then, virtually every software firewall needs exceptions. A good firewall lets you be very specific about those exceptions. Having the ability to open just a few ports is better than having to open or close them all. Having the ability to open a given port to a specific set of IP addresses is better than having to open the port to every IP address on the Internet, and WF lets you do that.
That about summarizes what you've seen about WF so far. Given that information, what can you do to really control which systems could access a given server?
@31541 For most of this chapter, I've been suggesting that WF's main value is to slow down a worm set loose inside an organization's intranet, inside the organization's perimeter firewall. But now let's take the question, "What can software firewalls on my servers and workstations do to secure my network?" a bit further.
Around 1999, I was doing some work for a large corporation. They asked if I'd like to see their data center, and so I took the tour of their racks and racks of servers, switches, and the like. Then they took me to a separate room with a smaller group of servers. Waving their hands around this separate-from-most-of-the-data-center room, they said with a smile, "This is our perimeter firewalled area." They explained to me that the growth of wireless networks, the number of people VPNing into the company from unsecured laptops, and the increasing number of outside "partner" firms to whom they were opening their network in a limited way led them to realize that more and more their intranet was looking about as safe as the Internet. As a result, they were experimenting with creating an inner perimeter which would enclose some of their most important servers.
That seemed a trifle paranoid in 1999 but doesn't seem quite so goofy today. For example, I've often been asked by people, "How do I ensure that only the accounting people get to the accounting servers?" Fifteen years ago, my answer would be, "Secure the NTFS, share, and database permissions on the accounting servers to just people in the Accounting group," and that's still not a bad answer. But what if you could say, "To access the accounting server, you've got to be a member of the Accounting group, and you've got to be sitting on a machine that's a member of that Accounting Computers group?"
With IPsec bypass, you can require that a prospective client of a given server must authenticate not only herself, but her computer as well. And sure, there are other ways to do this; Microsoft programmers surely weren't the first to think of this. But now they've made it a free add-on to some software—Server 2003 and XP—that you've already paid for.
How IPsec bypass works, in short
More specifically, here's what IPsec bypass does.
- First, you need an Active Directory. AD is different from earlier Windows domains, you may recall, because AD allows for groups that contain not just user accounts, but machine accounts.
- With IPsec bypass, you first create a group that contains the machines that you want to be the only ones that can communicate with a given server.
- Next, create IPsec policies that connect these acceptable clients to the server. These IPsec policies must either cause IPsec to do digital signing of the communications between the client and server (AH, in IPsec-ese), or that encrypt those communications (ESP, in IPsec-ese). (If you're rusty on IPsec, look back at Chapter 6 of Mastering Windows Server 2003.) While IPsec policies can employ either shared secrets, certificates, or Kerberos to authenticate the client to the server and vice versa, IPsec bypass requires Kerberos authentication.
- With the machine group created and the IPsec policies in place, use the group policy setting Windows Firewall: Allow Authenticated IPsec Bypass, identifying the machine group.
- Finally, enable Windows Firewall on the server, but do not create any exceptions.
Yes, you read that last part right. You're enabling Windows Firewall on a server but not creating any port or program exceptions, which until now has meant that no client can access the server. So how does a client get to the server when the firewall's set to "maximum cranky?" Simple; it just bypasses the firewall. To activate the Windows Firewall: Allow Authenticated IPsec Bypass group policy setting, you must tell Windows Firewall the name of one or more AD groups and/or machine accounts. This tells Windows Firewall, "Hey, listen, WF, I know that up to this point you've been the first player to examine incoming packets, but now that's changed. If there's an incoming packet and you find that it meets two criteria: it is either signed or encrypted by IPsec and it comes from a machine that's on that list that I just gave you, then just let it through—don't worry about it, don't even look at it."
This is what I meant when I said that IPsec bypass lets you set up a server so that it required both the user and the machine to authenticate. The user authentication is old hat; we've been doing it since NT 3.1 with file, directory, and database permissions. But the machine authentication's new. Your client machines must have AD machine accounts, and those accounts must be members of some group, and you configure IPsec bypass on a server to allow any machine using an authenticated IPsec connection and who is a member of that designated group to have access to the server.
TIP: You can, of course, also still create exceptions in WF on the server so that non-IPsec-connection clients can get to particular services, as you've seen in the rest of this 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