Protect Confidential Information Using IPSec and Group Policy

At one time or another, everyone has had to limit read access to a file server directory, a Microsoft Exchange Server folder, or a SQL Server table. Chances are that the information you want to protect is confidential. But how do you protect this information? Access control permissions are great, as long as the data remains on the server. However, as soon as a legitimate user accesses the information from his or her workstation, the data might become visible to anyone using a network sniffer. To protect your classified information as it traverses your Windows 2000 network, you can use Group Policy to implement a limited rollout of IP Security (IPSec). And to put your mind at ease, you can use a network sniffer yourself to prove that you've properly secured the information—an important step considering that your network servers are hosting information worth protecting.

I hear you saying, "Aren't sniffers limited to network experts with special hardware?" Actually, using a sniffer to scan the data on your network is easier than you might think. Several easy-to-use sniffer programs are available that require little, if any, networking knowledge. For example, I recently used a popular packet analyzer called PacketBoy from NDG Software to capture traffic on my network. To test the software, I opened a file called confidential.txt with Notepad, as Figure 1 shows. Compare the contents of the file in Notepad with the packet highlighted in PacketBoy, as Figure 2 shows. As you can see, confidential.txt transmitted in clear text, and it didn’t require a lot of effort to capture its contents. You can easily capture database and email traffic as well because most applications (e.g., POP3) send information, including account passwords, in clear text. Remember, though, that an attacker needs to have access to a computer that connects to a segment of the LAN carrying the desired traffic.

For instance, if a rogue employee installs a sniffer on his or her workstation, the employee can probably see all the traffic going to and from other nearby workstations on the same LAN segment. This traffic is visible because hubs retransmit each packet they receive on one port to all other ports. This data transmission continues until the packet reaches a router, where it stops unless the packet is destined for another segment. The rogue employee probably can't eavesdrop on traffic traveling to and from a workstation in another building because that traffic is on a different segment. However, more companies are migrating to switched-to-desktop networks in which a workstation sees only packets destined for that machine. Switching has been touted as a defense against sniffing, but new sniffers are appearing that use Address Resolution Protocol (ARP) redirects. With ARP redirects, you trick a computer into thinking you are the local router. Thus, the computer sends all packets to you first. After capturing the information, you then forward the traffic to its proper destination.

The only sure protection against sniffing is encryption—this is where IPSec comes in. IPSec provides authentication and encryption at the IP transport layer, which means you can protect data without modifying any applications. For an introduction to IPSec, see Tao Zhou's "IP Security in Windows 2000." IPSec is an Internet protocol, so Microsoft can’t take credit for designing it. However, the company can take credit for how easy IPSec is to implement in a Win2K network by defining a few simple rules. IPSec is a complicated implementation of several protocols that determine which encryption and hashing algorithms to use and how to exchange keys. Group Policy and Win2K's pre-built IPSec policy objects mask this complexity and make it easy for you to centrally deploy IPSec policy throughout your network using the organizational units (OUs) in Active Directory (AD).

In this scenario, you don’t want to secure every packet in the network. You simply want to secure the traffic to and from your servers that host classified information. The first task is to enable IPSec on all workstations and then configure the appropriate servers to require IPSec-protected communications. Finally, you can sniff some traffic to make sure you are protected.

To configure IPSec, you must use Group Policy Objects (GPOs) in AD. Although each system has a local GPO, I don’t recommend that you use it to configure computers in a domain because any other applicable GPO in AD will overwrite the local GPO settings. In addition, you are defeating the primary purpose of Group Policy, which lets you manage many systems at once from AD.

To configure IPSec, begin by opening AD Users and Computers, open the Properties dialog box for the domain, click the Group Policy tab, and edit Default Domain Policy. Maneuver to Computer ConfigurationWindows SettingsSecurity SettingsIP Security Policies on Active Directory, as Figure 3 shows. You will see three pre-built policies. You can handle most internal network implementations of IPSec using these pre-built policies instead of creating custom ones. By default, none of these policies are assigned. As a result, every Win2K system includes IPSec functionality, but it remains inactive until you flag a policy as assigned. If you assign the Client (Respond Only) policy to a computer, it communicates without IPSec unless it contacts a server that requires IPSec. For this example, you will want to activate Client (Respond Only) as the default policy for all computers in the domain by flagging it as assigned here in the Default Domain Policy GPO. Right-click the policy and click Assign.

At this point, none of your systems will use IPSec because none of them actively request IPSec. Consequently, your next step is to assign a different IPSec policy (i.e., one of the other two IPSec policies) to the servers that host classified information. Both of Win2K's pre-built IPSec policies for servers—Server (Request Security) and Server (Require Security)—negotiate the highest level of security that the client supports starting with triple Data Encryption Standard (DES) and falling back to DES, if necessary. These policies use Kerberos to authenticate the client and server to each other, which works fine if both computers are in the same forest of domains because all domains in a forest automatically have two-way Kerberos trusts. To communicate securely via IPSec with systems outside your forest, you must create custom policies that use certificates or shared keys for authentication. If you use Server (Request Security), the server always requests IPSec from clients that connect to it, but it falls back to unprotected TCP/IP if the client doesn’t support IPSec or isn’t configured to use it. For this example, you can assume that the only clients accessing your classified servers are Win2K workstations from within the domain that you have configured to support IPSec when requested. To ensure that communication with these servers is always secure, use the Secure Server (Require Security) policy, which won't allow connections with nonIPSec-enabled clients.

But where do you assign this policy? You can’t assign it in Default Domain Policy because that would require IPSec for all communications in the domain, which involves additional planning. You can’t assign the policy in each server’s local GPO because the Client (Respond Only) policy that you assigned at the domain level will override this new policy. So, you will want to assign the Secure Server (Require Security) policy using an OU or GPO permissions.

To implement the first option, create an OU called Servers-Classification Secret. Next, move all servers with classified data into that OU. To move a computer object, go to Active Directory Users and Computers, right-click the object, select Move, and select the desired OU. Then, create a new GPO linked to that OU and flag the Secure Server (Require Security) policy as assigned in that GPO. Now, Win2K will assign the Client (Respond Only) policy to all systems except the servers in the Servers-Classification Secret OU. Remember, when two GPOs have conflicting policies, any GPOs you define at a lower-level OU override GPOs at a higher level. In this case, the IPSec policy assignment in the Servers-Classification Secret OU overrides the policy you assigned in the Default Domain Policy GPO linked at the root of the domain.

Now that you've deployed your IPSec policy, you can test it by running a sniffer. After I set up my lab systems, as I described above, I started the sniffer again. I logged on to a workstation and opened the confidential.txt file on the server as before. As Figure 4 shows, the results were very different this time. The sniffer captured the packets, but it could only decode them as far as the IP header and identify them as Encapsulated Security Payload (ESP) packets (ESP is IPSec's encrypted mode). If you look inside the data portion of the packet, all you see is scrambled data.

Protecting sensitive information isn't difficult, even when it traverses the network, thanks to the integration between Group Policy and IPSec. However, creating a separate OU for the classified servers might not be an optimal solution for your domain. Next time, I'll show you why this separate OU might be a problem and how to use GPO permissions as an alternative.