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 snifferstools 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.
Figure 1 IPSec policy phases.
IPSec Phase I
The first phase performs multiple setup tasks, including these:
Mutual authenticationEach computer must positively identify itself to the other. Windows 2000 provides a choice of Kerberos, certificates, or shared-key authentication methods.
Negotiate encryption and integrity algorithmsW2K 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 groupThe 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 keybased encryption algorithms.
Generate a master keyThis 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 associationA 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)
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.