Internet Protocol Security (IPSec)

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 Policies

To add, edit, or remove IPSec policies, perform the following steps:

  1. Start the IP Security Policy Management snap-in by clicking Start, Run, and entering MMC or by entering MMC at the command line.

  2. After the console is open, choose File, Add/Remove Snap-in from the menu.

  3. Click the Add button, choose the IP Security Policy Management snap-in from the Add Standalone Snap-in dialog box, and then click Add. The following three options for IPSec policies are then displayed (see Figure 6.1):

    • Local Computer Use this option to manage the local system only.

    • Active Directory Domain of Which This Computer Is a Member Use this option to manage IPSec policies for any domain members .

    • Another Active Directory Domain Use this option to manage IPSec policies for another domain.

    Figure 6.1. You must select how to apply the IPSec policy.

    graphics/06fig01.gif

    If you need to manage another local policy on a remote computer, you can select the Another Computer option. After making your selection, click the Finish button.

  4. Click the Close button in the Add Standalone Snap-in dialog box. Then click OK in the Add/Remove Snap-in dialog box.

  5. After creating this setup, you can add a new policy by going to the console tree and clicking IP Security Policies on < SYSTEMNAME >. Then choose Action, Create IP Security Policy from the menu, and follow the instructions in the IP Security Policy Wizard until the Properties dialog box for your new policy opens.

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.

graphics/06fig02.gif

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.

A Word on Filters

The Negotiate Security filter action contains one or more security methods that are used in a specific order of preference during IKE negotiations. In security setups that include firewalls, proxy servers, or certain routers, you might have to enable the following settings so that IPSec traffic is not rejected:

For input filters:

  • IP Protocol ID of 51 (0x33) for inbound IPSec Authentication Header traffic

  • IP Protocol ID of 50 (0x32) for inbound IPSec ESP traffic

  • UDP port 500 (0x1F4) for inbound Internet Security Association and Key Management Protocol (ISAKMP)/Oakley negotiation traffic

For output filters:

  • IP Protocol ID of 51 (0x33) for outbound IPSec Authentication Header traffic

  • IP Protocol ID of 50 (0x32) for outbound IPSec ESP traffic

  • UDP port 500 (0x1F4) for outbound ISAKMP/Oakley negotiation traffic


The following three default policies are defined:

  • Client (Respond Only) This policy allows individual systems to secure their own communications at the request of the other system for secured communications. This policy contains the default response rule, which creates dynamic IPSec filters for inbound and outbound traffic based on the requested protocol and port traffic for the communication being secured.

  • Server (Request Security) This policy is configured so that systems can request secure IP communications whenever possible but allow unsecured IP communication if nonIPSec-aware computers or systems not configured via a Client (Respond Only) policy attempt a communications channel.

  • Secure Server (Require Security) This policy is used for systems that require secure communications. The filters for this policy require all communication from the given system to be secured, with the exception of the initial inbound communication request. When nonIPSec-aware computers or systems not configured via a Client (Respond Only) policy attempt a communications channel with this system, they are denied access because only secure communications channels are allowed to systems running this configuration.

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 Authentication

IPSec 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:

  1. Double-click the policy you want to modify in a saved or newly created IP Security Policies MMC and double-click the rule you want to modify.

  2. In the Authentication Methods tab, click Add to add a method (if one is not already defined), or choose an existing method and then click the Edit button. Then select the authentication method you want to add or modify.

  3. For authentication services in a Windows 2000 or Windows Server 2003 Active Directory domain or a trusted Active Directory domain, select the Active Directory Default (Kerberos V5 Protocol) option. To enable a public key certificate for authentication services, use the Use a Certificate from This Certification Authority option. If you decide to define a preshared key, select the Use This String (Preshared Key) option.

  4. To delete methods you do not want to use, simply highlight them and click the Remove button. You can also rearrange the preference order of an authentication method by highlighting it and clicking the up or down arrows.

graphics/note_icon.gif

IPSec polices are configured through a system's local policy or via Active Directory. IPSec policies that are configured and assigned via OUs take precedence over domain-level policies for computers that have accounts in that OU. An OU inherits the policies of its parent OU by default, unless inheritance is blocked or a policy is explicitly assigned to the child OU.

To specify IPSec connection types, go to the Connection Type tab and choose All Network Connections to set the connection type for all available network connections, Local Area Network (LAN) to set the connection type for all available LAN connections, or Remote Access to apply the rule to any available VPN or dial-up connections.


Implementing IPSec Rules

An 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.

graphics/06fig03.gif

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):

  • To secure packets from all IP addresses on the computer for which you are configuring this filter, select My IP Address.

  • To secure packets from any computer, select Any IP Address.

  • To secure packets from a DNS name specified in the hostname, select A Specific DNS Name.

  • To secure packets from an IP address that you specify in the IP Address field, select the A Specific IP Address option.

  • To secure packets from an IP subnet specified in the IP Address field and the subnet mask you specify in the Subnet Mask field, select the A Specific IP Subnet option.

Figure 6.4. You can manage filters by IP address via the IP Filter Properties dialog box.

graphics/06fig04.gif

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.

graphics/note_icon.gif

To automatically create two filters based on configured filter settings going to and from the specific destination address, select the Mirrored check box. If the settings were created for a single filter configuration (to or from, but not both), clear the Mirrored check box.


graphics/tip_icon.gif

When you create a filter for an IPSec tunnel, clear the Mirrored check box because you need to create two separate filter lists. The first list handles outbound traffic, and the other describes inbound traffic. You also need to create two rules that use the inbound and outbound filter lists in your policy.




MCSE 70-293 Exam Cram. Planning and Maintaining a Windows Server 2003 Network Infrastructure
MCSE 70-293 Exam Cram: Planning and Maintaining a Windows Server 2003 Network Infrastructure (2nd Edition)
ISBN: 0789736195
EAN: 2147483647
Year: 2004
Pages: 123

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net