Welcome To BlogerDesign

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.

Figure 1 IPSec policy phases.

IPSec Phase I

The first phase performs multiple setup tasks, including these:

• Mutual authentication—Each 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 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.

IPSec Policies in Windows 2000

IPSec is implemented in Windows 2000 through the use of built-in IPSec drivers in the IP stack, customizable policies, and a policy agent that filters all IP packets against the policy. To take control of the where, when, and how, you define the particulars of negotiation. A wizard walks you through choosing the options defined previously. Once implemented, the IPSec policy is triggered either when packets that match those identified in your filters are required to be transmitted or received, or when the policy requires negotiation of authentication, integrity and encryption with another system. Figure 2 shows the internals of one of default polices that can be used to help you understand IPSec in W2K. You may customize them or develop your own.

Figure 2 Properties of the default Windows 2000 IPSec policy.

Three types of W2K IPSec policies exist:

• Blocking—Prevents packets that meet the criteria of protocol, port, source, or destination from leaving or entering the computer

• Allow—Allows packets that meet the criteria of protocol, port, source, or destination to leave or enter the computer

• Negotiate—Negotiates secure communication between two computers

Both blocking and allow IPSec policies can be applied to single computers. The policies either enable or disable communication facilities. For example, you may want to prevent Windows 2000 Professional systems from responding to HTTP requests. Although no Web services are installed on Professional by default, someone might do so. If your corporate policy forbids such action, it's still pretty tough to prevent all users from doing so. An IPSec blocking policy can prevent the server from answering requests on port 80. (No Code Red worm would infect such a system, even if Joe user installs IIS.)

Negotiate policies, on the other hand, require matching policies to exist on two machines. They are used to secure communications between the machines.

Using Group Policy to Apply IPSec Throughout an Active Directory Domain

Creating IPSec policies computer by computer is a tedious and dangerous task. That's because asdasthere are many steps to follow. In addition, if you make a mistake and policies that should be used between cooperating computers do not match, they will not work. If multiple computers in an Active Directory environment must participate in IPSec-negotiated sessions, the easiest way to ensure consistent application is through Group Policy. Figure 3 indicates the area of a Group Policy where IPSec policies reside. In this figure, a policy for negotiating Exchange server administrative functions has been activated.

Figure 3 The Exchange Server Admin IPSec Policy is created in the Exchange Server OU Group Policy.

IPSec policies are created within the IPSec container of a Group Policy. The Group Policy is linked to the OU that contains the servers that should use it. Let's imagine, for example, that you want to encrypt administrative sessions between the Exchange administrator's computer and all Exchange servers. If all Exchange servers and the administrators computer are placed in the same OU, the IPSec policy written in a Group Policy linked to that OU will be applied consistently to all computers. Likewise, you might establish policies for communications between all computers in the Accounting department and the Accounting database server, or between top executives.