Windows Firewall Basics
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 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