Apply the VPN concept to defend mission-critical resources
As you make your network more porous to support connections to your business partners and customers, you must shore up defenses around the crucial resources on your internal network. Sometimes you can implement internal firewalls to separate your network into zones and accomplish this goal. But what if the traffic or computers that you need to protect don't correspond to convenient physical LAN segments? In such cases, you can take a cue from the Internet and apply the VPN concept to your internal network, using IP Security (IPSec) and Group Policy to shield your mission-critical Windows 2000 servers from attackers who manage to penetrate your perimeter defenses.
The IPSec Advantage
You can use IPSec to secure all IP traffic on your network. The protocol provides authentication, integrity checking, and optional encryption at the packet level—and does so in a way that's transparent to your applications. IPSec authentication is stronger than source—IP address filtering, which is subject to spoofing and is difficult to maintain.
IPSec uses Kerberos, preshared keys, or certificates for its initial authentication. You can assign (i.e., activate) only one IPSec policy at a time on a Win2K computer, but that policy can contain multiple IPSec rules so that the computer treats different kinds of traffic in different ways. An IPSec rule specifies a filter list, action, and authentication method. The filter list catches appropriate packets (according to source IP address, destination IP address, and ports), then subjects those packets to a specified action—Permit, Block, or Negotiate security. The Permit action causes the system to process the packet traffic as if you hadn't implemented IPSec. Block causes the system to drop packets. Negotiate security causes the system to secure traffic using the Authentication Header (AH) or Encapsulating Security Payload (ESP) mode, depending on how you've configured the action. If the system receives a packet that isn't secured by AH or ESP, it sends a message to the originating computer, inviting it to retry the exchange by using IPSec. If the originating computer doesn't respond (because it isn't enabled for or doesn't support IPSec), the receiving computer either acquiesces and drops back to unsecure traffic or rejects communications (depending on the action's configuration). AH mode guarantees both computers that the traffic is authentic, meaning that the computer that claims to have transmitted the traffic truly did so. AH mode also uses integrity checking to make sure the packet wasn't modified in transit. AH is sufficient when you don't care about confidentiality but simply want to limit which computers can communicate with a system and make sure that traffic hasn't been modified in transit. ESP, which is a superset of AH, provides encryption in addition to authentication and integrity checking so that only the receiving system can read the data in the packet. (For more basic information about IPSec, see John Howie, "Securing Wireless Networks," January 2002, InstantDoc ID 23374.)
When you receive an IPSec-secured packet, you know that it came from an authorized computer and hasn't been forged or modified in transit. An IPSec-configured computer that drops unauthenticated packets before they reach your applications can foil attackers: Intruders can't attack an application if they can't communicate with it. With some creative thinking, you can find ways to use IPSec and Group Policy to specify which computers in your domain can communicate with one another, thereby adding security and preventing attacks on mission-critical applications such as SAP, Oracle, PeopleSoft, Microsoft Exchange Server, and Microsoft SQL Server.
A Fine Example
Suppose you want to protect an important Win2K system that runs SQL Server. You want to implement security above and beyond what conventional Win2K and SQL Server options can provide. Out of a network of 5000 user workstations, only 100 workstations need to communicate with the SQL Server system, over port 1433. However, these 100 computers are scattered throughout your network, so restricting traffic to the server according to source IP address is impractical (not to mention unsecure). However, you can use IPSec authentication to limit, in two steps, the computers that can communicate with the SQL Server machine through port 1433.
First, you need to create an IPSec policy on the SQL Server machine to require ESP mode for any traffic on the port. (In this example, I suggest that you use ESP mode to encrypt confidential data traveling between the clients and server.) Then, you need to enable IPSec on the 100 authorized client computers.
Configuring the Server
Open the Microsoft Management Console (MMC) Local Security Policy snap-in on the SQL Server system, and select IP Security Policies on Local Machine in the left-hand pane. Right-click a blank area in the right-hand (aka details) pane, then select Create IP Security Policy from the context menu to launch the IP Security Policy Wizard. Click Next, enter a name such as Secure SQL Server, then click Next again. Clear the Activate the default response rule check box, click Next, then click Finish. (The default response rule causes Win2K to acquiesce to any IPSec request from computers that the system contacts. You want to stay in control of IPSec negotiation in this example, so you need to deactivate the rule.)
The Secure SQL Server Properties dialog box opens automatically. On the Rules tab, click Add to launch the Security Rule Wizard. Click Next until you reach the Authentication Method screen. Keep in mind that you're configuring computer-to-computer authentication, not user authentication. When all the computers involved are part of an Active Directory (AD) forest, Kerberos is the easiest authentication method to use because each computer already has a Kerberos-enabled AD computer account. Kerberos isn't as secure as the other options (i.e., certificates and preshared keys), but it's much less work. Therefore, let's start by examining how to use Kerberos authentication. Select the Windows 2000 default (Kerberos V5 protocol) option.
Previous
Register
