Almost any data transmitted on a network is vulnerable to some level of compromise. As most communications between systems are not secured, be it on a private network or across an open network such as the Internet, eavesdropping on the session and compromise of unencrypted data are possible. IPSec provides a security mechanism for ensuring the availability, integrity, and confidentiality of data. IPSec can be deployed between two specific systems in an enterprise by using IPSec in Transport mode (the default mode). In Transport mode, IPSec encrypts only the IP payload, such as the Transmission Control Protocol (TCP) segments, a User Datagram Protocol (UDP) message, or the Internet Control Message Protocol (ICMP) message between two systems, when a security association has been established. All other communications to any other system in that environment might not require this secure level of communication and would not necessarily be set up to create a secure connection. IPSec in Tunnel mode is often deployed in settings with two endpoints, such as a Routing and Remote Access Service (RRAS) server acting as a connection point from one site to another RRAS server at another site. The security association in this configuration is between both RRAS servers, which allows IPSec to encrypt the IP header and the payload. This encryption provides protection for all IP traffic leaving all systems on one site and traveling to systems on the other site. Regardless of the destination and recipient systems from either site, all traffic flow within that tunnel is encrypted. In Windows Server 2003, Group Policies enable domain administrators to configure IPSec policies in a forest to be allocated at the site, domain, or Organizational Unit (OU) level as needed. IPSec Encapsulating Security Payload (ESP) can pass through Network Address Translation (NAT) devices that allow UDP traffic. This is done through the Internet Key Exchange (IKE) protocol, which automatically detects the presence of NAT devices and uses UDPESP encapsulation to allow IPSec traffic to pass through the NAT. The use of NAT devices and UDPESP encapsulation allows businesses that want to use Layer Two Tunneling Protocol (L2TP)/IPSec in virtual private networks (VPNs) over untrusted networks, such as the Internet, to keep their clients behind NAT devices to establish secure connections back to the corporate network using IPSec-ESP Transport mode. The use of NAT devices and UDPESP encapsulation also makes it possible to set up and configure RRAS servers using IPSec in Tunnel mode when one of the two servers is behind a NAT device. Implementing IPSec PoliciesTo add, edit, or remove IPSec policies, perform the following steps:
You can create or modify any rules for the policy in the Rules tab. To add a rule, use the Create IP Security Rule Wizard or add the rule manually. To use the wizard, you must confirm that the Use Add Wizard check box is selected on the policy you want to modify, click Add, and then follow the instructions after the wizard starts. To add a rule manually, confirm that the Use Add Wizard check box is not selected, click Add, and then define settings in the IP Filter List, Filter Action, Authentication Methods , Tunnel Setting, and Connection Type tabs as needed. To edit a rule, select the rule you want to edit, click the Edit button, and then modify the rule properties as needed (see Figure 6.2). To activate a rule, go to the Rules tab and select the check box next to the rule you want to activate. To deactivate a rule, simply clear the check box. To remove a rule, select the rule and then click Remove. To remove a policy that is no longer needed, highlight the policy and click Delete. Figure 6.2. You can manage IP filter rules through the IP Security policy's rule properties.
To manage Active Directorybased IPSec policies, use an account that is a member of the Domain Administrators group or be assigned delegate authority for the domain. To manage local or remote IPSec policies for a system, use an account that is a member of the local Administrators group on that system.
The following three default policies are defined:
To assign an IPSec policy, open Active Directory Users and Computers. Right-click the Active Directory object (domain or OU) where you need to assign the policy, and choose Properties. In the Properties dialog box, select the Group Policy tab. Then click Edit to open an existing Group Policy object that you want to edit, or click New to create a new one. IPSec AuthenticationIPSec uses three primary authentication methods: Kerberos V5, Certificates, and preshared secret keys, sometimes referred to as a preshared secret . The default authentication method in a domain is Kerberos V5, which verifies, by way of mutual authentication, the identity of the user and network services. It performs this verification by issuing tickets containing encrypted passwords to users during domain logon and system access. This password is used to confirm users' identities so that they can access requested network services seamlessly through pass-through authentication. The Key Distribution Center (KDC) runs on each domain controller in your Active Directory domain and stores all client passwords and other account information. A user who logs on to a client system is authenticated to the KDC, which issues a special ticket-granting ticket (TGT) to the client. The client system uses the TGT to access the ticket-granting service (TGS), which in turn issues a service ticket to the client. The client then presents the service ticket to requested network services. The service ticket uses mutual authentication to prove the user's identity to the service and the service's identity to the user. Kerberos V5 services are found on domain controllers and allow each domain controller in the domain to act as a KDC. The Kerberos client is installed on each system and uses Domain Name System (DNS) lookup to locate the nearest available domain controllerreferred to as the preferred KDC for that particular logon session. If the preferred KDC isn't available, the system locates another KDC via DNS lookup to provide the needed authentication. Public key certificates can be used for IPSec via public key infrastructure when clients are in use that are not members of the same domain or when systems in use are running other operating systems that do not support Kerberos authentication, such as non-Microsoft operating systems and legacy Windows systems (Windows 95, for example). Computers running Windows 2000, Windows XP, or the Windows Server 2003 family support X.509 Version 3 certificates, including computer certificates generated by commercial Certificate Authorities (CAs), which are often needed for public key certificate deployments. IPSec can also use preshared keys for authentication when two systems attempting a security association use a shared secret key for authentication against an IPSec policy. In this scenario, information is encrypted before transmission on the sending system by using a session key during the initial security negotiation. The session key is created by using a Diffie-Hellman calculation and the preshared secret key. Information is decrypted on the recipient system with the same preshared key. One IPSec peer authenticates the other peer's packet by decryption and verification of the hash inside the packet. (The hash inside the packet is a hash of the preshared key.) If authentication fails, the security association is not established, and communication between the systems is not allowed. To define one of these three IPSec authentication methods, perform the following steps:
Implementing IPSec RulesAn IPSec policy consists of one or more rules that determine IPSec behavior and are configured on the Rules tab in the Properties dialog box of an IPSec policy. A filter list is configured on the IP Filter List tab in the Properties dialog box of an IPSec rule within an IPSec policy (refer back to Figure 6.2). This list contains one or more predefined packet filters describing the types of network traffic to be configured against a filter action for this rule. To add, edit, or remove IP filter lists, select the policy you want to modify in a saved or newly created IP Security Policies MMC. Then double-click the rule containing the IP filter list you want to modify and go to the IP Filter List tab. To add a new IP filter list, click the Add button. To modify an existing IP filter list, select the filter list you want to modify and then click the Edit button. To remove an IP filter list, highlight the filter list you want to remove and click the Remove button. To configure a filter action, you use the Filter Action tab in the Properties dialog box of an IPSec rule within an IPSec policy (see Figure 6.3). You can set the type of action required (Permit, Block, or Negotiate Security) for packets that match the filter list. Figure 6.3. You can configure IP filter actions through the Filter Action tab in the IP Security policy's rule properties.
To add, edit, or remove IPSec filters, start the IP Security Policy Management snap-in by clicking Start, Run and entering MMC or typing MMC at the command line. Next, double-click the policy you want to modify and select the rule containing the IP filter list you want to modify. In the IP Filter List tab, select the IP filter list containing the IPSec filter you want to modify and click the Add button to add a filter or the Edit button to make changes to an existing filter. To remove an existing filter, highlight it and then click the Remove button. Some of the available options in the IP Filter Properties dialog box are described in the following list (see Figure 6.4):
Figure 6.4. You can manage filters by IP address via the IP Filter Properties dialog box.
There are other options to secure packets from dynamically enabled network services, such as dynamic default gateway configurations, DNS, WINS, and DHCP. To configure these settings successfully, you must make the changes for both source and destination addresses.
|