Sniffer Proof Your Network - Protecting the Active Directory

Protecting servers is all well and good, but have you thought about how exposed the confidential information traveling across your network is? A search of the Internet returns no less than a dozen free software-based sniffers—tools that, when installed on a computer in your network, can capture the packets traveling across it and open them for reading by anyone. While these tools are a boon to the administrator charged with troubleshooting network problems, in the wrong hands they can mean disaster. Roberta Bragg introduces you to a solution to this problem using IPSec policies.

From the author of

From the author of

So you've hardened your Windows boxes and locked down Exchange. So what?
If I can monitor your network (and if I work at your company, I can quite easily
do so), I can read e-mail as it crosses the wire. Finding that easy and
worthwhile, I might monitor payroll transactions, financial reports, and
whatever else I can capture.

You see, protecting servers is all well and good, and you should definitely
do that. But have you given a thought to how exposed the confidential
information traveling across your network is? Most data is not encrypted by
default, and tools for monitoring the data are readily available. Even when the
ability to encrypt e-mail exists, what guarantees that users will do so? A
search of the Internet returns no less than a dozen free software-based
snifferstools that, when installed on a computer in your network, can
capture the packets traveling across it and open them for reading by any Tom,
Jane or Harry. While these tools are a boon to the administrator charged with
troubleshooting network problems, in the wrong hands they can mean disaster.
Wouldn't it be nice if there was some utility that would sit in the
background and automatically negotiate secure, encrypted sessions whenever it
was necessary? There is!

To accomplish this wizardry in Windows 2000, you write IPSec policies. IPSec,
a standard proposed by the Internet Engineering Task Force (IETF) for secure
communications, is built into the Windows 2000 TCP/IP stack. IPSec policy agents
are installed by default on every machine. This means that you can have
exquisite control over the packets that enter and leave any W2K machine. You can
allow or deny their entry or exit, and you can negotiate secure communications
between any two Windows 2000 computers on your network. Wouldn't it be a
good idea to encrypt communications between Exchange servers? What about
transfers of confidential information from Human Resources? How about protecting
Active Directory replication? You can do all this on a machine-by-machine basis,
or, even more exciting, you can use Group Policy to ensure that multiple systems
on your network follow the same IPSec rules. Note that I'm not suggesting
that you go hog wild and make all systems talk IPSec all the time, but for those
conversations that should be restricted to approved participants, IPSec is the
solution.

To apply IPSec, you must understand it. Here's what you need to
know.

IPSec: The Standard

The IPSec protocol was originally developed to be part of IPv6, the new
version of our current IP protocol. IPv6 expands the Internet addressing scheme
and provides native security capabilities and other features. Several IETF
Requests for Comments (RFCs) detail its specifications (see RFCs 2709, 2410,
2401, 2207 , 2857, 2403, 2402, 2404); you can read them at
http://www.rfc-editor.org/rfcsearch.html.

To successfully implement IPSec, you do not need to be a mathematician or
have a Ph.D. in computer science. However, you do need to understand its basics.
You can't configure IPSec correctly by right by accident. It just
won't work. Worse, you may think you are protecting communications when
you're not, or you may shut down necessary communications between systems.
The first thing to remember is that there are two phases of IPSec and several
steps to each phase. In W2K, you create a policy by making choices that are
utilized in each phase. One of the key elements of your success, then, will be a
thorough understanding of each phase. Figure 1 illustrates the process.

Negotiate encryption and integrity algorithmsW2K can use
either DES, 3DES (if using the high-encryption pack), 40-bit DES, or no
encryption. Integrity algorithms are used to verify that data received is
actually the data sent. Integrity is implemented by preparing a checksum over
the packet contents. The checksum, which is also encrypted and transmitted, is
recalculated at the receiving computer. If both checksums match, the data has
not been changed. W2K uses MD5 or SHA algorithms.

Select the Diffie-Hellman groupThe Diffie-Hellman group
represents the size of the large prime number used in the calculations. The name
comes from the two gentlemen who first proposed this solution to the key-sharing
problem of symmetric keybased encryption algorithms.

Generate a master keyThis is used in Phase II to create the
bulk encryption keys. The IPSec symmetric key algorithms that encrypt and
decrypt the data use the bulk encryption keys. The master key is generated by
both computers and is never transmitted across the network.

Create an IKE security associationA security association
(SA) defines how two computers will securely share information. It consists of
both the defined policy and the keys. The IKE security association is used to
secure Phase II negotiation.

IPSec Phase II

Phase II creates the SAs that are used to secure your data. Two SAs are
required for each conversation: one that originates on computer A and ends on
computer B, and one that travels in the other direction. To create the SAs,
Phase II must negotiate the following:

IPSec protocol. The IPSec standard defines two protocols, Authentication
Header (AH) and Encapsulating Security Protocol (ESP). One or both may be
used.

Integrity algorithm (MD5 or SHA1).

Encryption algorithm (DES, 3DES, 40-bit DES, or none)

Renegotiation

IPSec is very flexible. During communications, both Phase II and Phase I can
be renegotiated. Renegotiation of Phase II generates new bulk encryption keys
and new SAs. Renegotiation of Phase I generates a new master key. In W2K
policies, you can require regeneration of keys based on time or the number of
packets transmitted. For example, you could require a new encryption key every
few minutes or few thousand kilobytes. This limits an attacker's ability to
decrypt packets. If she manages to break or acquire the key, she has only the
information contained in those packets encrypted with that key, not the entire
communication.