Planning Security for Data Transmission


Plan security for data transmission.

  • Secure data transmission between client computers to meet security requirements.

  • Secure data transmission by using IPSec.

IP Security (IPSec) is a framework of open standards for ensuring private, secure communications over IP networks. This protocol is rapidly becoming the underlying framework for secure communications using VPNs and will likely replace Point-to-Point Tunneling Protocol (PPTP) as Microsoft's VPN protocol of choice. IPSec takes advantage of many of the most popular encryption protocols in use today. For more information on encryption protocols, see Chapter 4. IPSec is based on an end-to-end security model, which means that the only computers that must know about IPSec are the sending and receiving computers. The packets travel the network without being affected by any of the intervening network devices. Each IPSec device handles its own security and functions with the assumption that the transport medium is not secure. The Internet is an excellent example of a transport medium that is not secure.

The Microsoft Windows Server 2003 implementation of IPSec is based on standards developed by the Internet Engineering Task Force (IETF) IPSec working group . However, it is important to note that Microsoft uses two implementations of IPSec: the IETF version, also known as Pure IPSec Tunnel mode, or just tunnel mode; and the Microsoft variant on IPSec, which Microsoft calls L2TP/IPSec mode, or transport mode. An IPSec VPN configured to use transport mode secures an existing IP packet from source to destination, using the encryption and authentication methods discussed later in this section. Tunnel mode puts an existing IP packet inside a new IP packet that is sent to a tunnel endpoint in the IPSec format. Both transport and tunnel mode can be encapsulated in Encapsulating Security Protocol (ESP) or Authentication Header (AH) headers. The original IETF Request for Comments (RFC 2401, http://www.ietf.org/rfc/rfc2401.txt) IPSec tunnel protocol specifications did not include mechanisms suitable for remote access VPN clients , instead focusing on site-to-site VPN implementations. For that reason, Microsoft's implementation of tunnel mode relies on the use of the L2TP protocol developed jointly with Cisco to provide this additional packet format. (An introduction to the components of IPSec comes later in this chapter.) It is worth noting that a new RFC (RFC 3193, http://www.ietf.org/rfc/rfc3193.txt) introduced in late 2001 discusses using L2TP with IPSec.

EXAM TIP

Protecting VPN connections By default, client remote access VPN connections are protected using an automatically generated IPSec policy that uses IPSec transport mode (not tunnel mode) when the L2TP tunnel type is selected. You will probably see this configuration in almost every production implementation of a Windows Server 2003 IPSec implementation. To enable this configuration, configure the Routing and Remote Access Service for L2TP VPN connectivity, as described in Chapter 4.

Understand IPSec The exam includes questions and scenarios on IPSec. Although you don't need to memorize the minutiae surrounding the encryption protocols used by IPSec, you should be familiar with what the components of IPSec are, how to implement an IPSec tunnel, and especially how to work with IPSec policies.


The following new features are supported in the Windows Server 2003 IPSec implementation:

  • IPSec in Windows Server 2003 now supports User Datagram Protocol (UDP) encapsulation of IPSec packets to allow Internet Key Exchange (IKE) and Encapsulating Security Protocol (ESP) traffic to pass through a Network Address Translation (NAT) devicesomething not previously possible in Windows 2000. It is now possible for Windows 2000 and Windows XP clients to establish IPSec connections with a Windows Server 2003 server that is located behind one or more NAT devices.

  • The IP Security Monitor is now implemented as an MMC snap-in instead of a standalone executable as in Windows 2000. Also, you can now monitor information about local and remote computers as well as several other enhancements.

  • IPSec now supports the use of a 2048-bit Diffie-Hellman key exchange. As a result, the secret key resulting from the Diffie-Hellman exchange has greater strength. This results in a longer key length, which increases the difficulty an attacker faces when trying to determine a secret key.

  • You can administer and control IPSec from the command line with new extensions to the netsh command. Using the netsh ipsec context, you can configure static or dynamic IPSec main mode settings, quick mode settings, rules, and configuration parameters. The netsh ipsec context replaces the Ipsecpol.exe tool that was provided with the Windows 2000 Server Resource Kit.

  • IPSec now provides stateful filtering of network traffic during computer startup. Any outbound traffic initiated by the computer upon startup is permitted, as is any inbound reply traffic. Dynamic Host Configuration Protocol (DHCP) is exempt from this new protection provided by IPSec and is thus allowed during startup. You can also specify other types of traffic you want to exempt. Computer startup security can be configured only by using the netsh command with the ipsec context.

  • Windows Server 2003 Enterprise Edition and Windows Server 2003 Datacenter Server Edition provide improved support for integration of IPSec with network load balancing. This allows a group of NLB servers to better provide highly available IPSec-based VPN services to clients. NLB can now accurately track IPSec-secured sessions, and the IPSec Internet Key Exchange (IKE) protocol can now detect when an IPSec-secured session is being established with a cluster server and quickly recover from a failover.

  • IPSec provides an extension to the Resultant Set of Policy (RSoP) snap-in (another new addition to Windows Server 2003) that can be used to view IPSec policy assignments of computers or other Active Directory objects.

The following are the standard features of the Windows Server 2003 IPSec implementation:

  • IPSec in Windows Server 2003 is policy based. It cannot be configured without an IPSec policy being in place, allowing an administrator to more easily apply settings to groups of objects such as computers or users.

  • IPSec on Windows Server 2003 can use Kerberos v5, a digital certificate, or a shared secret (string) for user authentication.

  • IPSec mutually authenticates computers prior to any data being exchanged.

  • IPSec establishes a security association (SA) between the two host computers involved in the data transfer. An SA is the collection of a policy and keys, which define the rules for security settings.

  • IPSec encrypts data using Data Encryption Standard (DES) or Triple DES (3DES).

  • IPSec uses the MD5 or SHA1 algorithm for data hashing.

  • IPSec is invisible to users. IPSec operates at the network level of the Open System Interface (OSI) model; therefore, users and applications do not directly interact with the protocol. After an IPSec tunnel has been created, users can connect to applications and services as if they were on the local network and not on the other side of a public network.

IPSec operates at the network layer; therefore, it is invisible to applications and computers. An understanding of the following features, however, will help you troubleshoot problems that may arise in connectivity:

  • IPSec policies are part of Group Policy, both locally and within Active Directory. This built-in feature allows changes and management to be centralized. Settings for IPSec are enforced on the computer as the policy is enforced.

  • The Internet Security Key Association Key Management Protocol (ISAKMP) monitors the negotiations between the hosts and provides the keys to use with security algorithms.

  • The installed IPSec driver secures traffic between the two hosts.

Understanding the Architecture and Components of IPSec

Plan for network protocol security.

  • Specify the required ports and protocols for specified services.

Let's look at the underlying architecture and components of the IPSec protocol. IPSec provides data and identity protection services for each IP packet by adding a security protocol header to each IP packet. This header is made up of several components, each with its own function.

Authentication Header (AH)

The IPSec Authentication Header (AH) provides three services as part of the IPSec protocol. First (as its name might suggest), AH authenticates the entire packet. Second, it ensures data integrity. Third, it prevents any replaying of the packet by a third party who might be trying to penetrate the IPSec tunnel. One service AH doesn't provide is payload encryption. AH protects your data from modification, but an attacker who is snooping the network would still be able to read the data. To prevent the modification of the data, AH uses two hashing algorithms to "sign" the packet for integrity:

  • The Message Digest 5 (MD5) algorithm applies the hashing function to the data in four passes .

  • The Secure Hash Algorithm (SHA1) is closely modeled after MD5. SHA uses 79 32-bit constants during the computation of the hash value, which results in a 160-bit key. Because SHA has a longer key length, it is considered more secure than MD5.

AH uses an IP protocol decimal ID of 51 to identify itself in the IP header. The AH header contains the following fields:

  • Next Header This field identifies the next header that uses the IP protocol ID.

  • Length This field indicates the length of the AH header.

  • Security Parameters Index (SPI) Used in combination with the destination address and the security protocol (AH or ESP), the SPI is used by the receiver to identify the cryptographic keys and procedures to be used to decode the packet.

  • Sequence Number This field provides the anti-replay functionality of AH. The sequence number is an incrementally increasing number (starting from 0) that is never allowed to cycle and that indicates the packet number. The machine receiving the packet checks this field to verify that the packet has not been received already. If a packet with this number has already been received, the packet is rejected.

  • Authentication Data This field contains the Integrity Check Value (ICV) used to verify the integrity of the message. (This is the hash value mentioned previously.) The receiver calculates the hash value and checks it against the ICV to verify packet integrity.

An IP Packet that has AH applied in transfer mode is modified with the AH header between the IP header and the TCP header, as shown in Figure 7.16.

Figure 7.16. An IP packet with the AH header inserted in transfer mode.

AH can be used alone or in combination with the ESP protocol, which is discussed next.

Encapsulating Security Protocol (ESP)

Encapsulating Security Protocol (ESP) provides confidentiality in addition to authentication, integrity, and anti-replay. This portion of the IPSec protocol encrypts the data contents of the packet. The format of the ESP varies, depending on the type and mode of encryption being utilized. ESP can be used alone, in combination with AH, or using Microsoft's implementation, nested within the L2TP.

ESP appears in the IP header with an IP protocol decimal ID of 50. The ESP header contains the following fields:

  • SPI The receiver uses the SPI, in combination with the destination address and the security protocol (AH or ESP), to identify the cryptographic keys and procedures to be used to decode the packet.

  • Sequence Number This field provides the anti-replay functionality of ESP. The sequence number is an incrementally increasing number (starting from 0) that is never allowed to cycle and indicates the packet number. The machine receiving the packet checks this field to verify that the packet has not been received already. If a packet with this number has already been received, the packet is rejected.

NOTE

Replaying: Why Is It Bad ? You may have noticed that replaying has been included several times as part of the discussion of IPSec. Replaying is a somewhat obscure method for obtaining access to a system. A replay attack occurs when packets are intercepted by an unauthorized party, stored, and later retransmitted in an effort to trick one or both sides of the transmission into thinking that it is a valid communication. A replay attack becomes an issue because TCP/IP protocols such as Network File System (NFS) have no mechanisms to determine whether a packet is being replayedeven after several hours. Fortunately, the anti-replay mechanisms in IPSec make a replay attack a virtual impossibility .


The ESP trailer contains the following fields:

  • Padding Specifies 0 to 255 bytes used for 32-bit alignment and with the block size of the block cipher.

  • Padding Length Indicates the length of the Padding field in bytes.

  • Next Header Identifies the makeup of the payload, such as TCP or UDP.

The ESP Authentication Trailer contains one field: Authentication Data. This field contains the Integrity Check Value (ICV) and a media access control (MAC) used to verify the sender's identity and ensure message integrity.

ESP is inserted after the IP header and before an upper layer protocol, such as TCP, UDP, or ICMP, or before any other IPSec headers (such as AH) that have already been inserted. Everything following ESP (the upper layer protocol, the data, and the ESP trailer) is encrypted, as shown in Figure 7.17. The IP header is not signed and, therefore, not necessarily protected from modification unless tunneling mode is active, as shown in Figure 7.18.

Figure 7.17. An IP packet with the ESP header inserted in transfer mode.

Figure 7.18. An IP packet with the ESP header inserted in tunnel mode; the original IP header is now encrypted.

The final piece of the IPSec protocol is the authentication and key exchange mechanism. Authentication and key exchange are accomplished using a pair of protocols.

Internet Security Key Association Key Management Protocol (ISAKMP/Oakley)

ISAKMP/Oakley (also known as ISAKMP/IKE, for Internet Key Exchange) provides the mechanism that allows disparate VPN servers to share encryption key information and make the IPSec protocol practical in today's environment. Before secured data can be exchanged between VPN servers, a contract between the two computers must be established. In this contract, called SA, both computers agree on how to exchange and protect information. In other words, the two servers (or the server and client computer) need to agree on how to encrypt and decrypt the data to be sent.

To enable this process, the IPSec protocol uses a standard process to build this contract between the two computers. This process combines the ISAKMP and Oakley key generation protocols. ISAKMP provides the centralized security association management, whereas Oakley actually generates and manages the encryption keys used to secure the information.

IKE actually performs a two-phase operation to establish the secure communication channel. In each phase, confidentiality and authentication are ensured by the use of encryption and authentication algorithms that are agreed upon by the computers negotiating. In the first phase (also known as main mode), the two computers establish a secure, authenticated channel called the Phase I (Main Mode) SA. The IKE provides identity protection during this phase. In the first phase (also known as quick mode), the two computers establish the rules for communication called the Phase II (Quick Mode) SA. During the second phase, a new shared key is created for use. After the Phase II SA is in place, IPSec secured communications can occur.

The final piece of this puzzle that needs to be covered is Microsoft's IPSec/L2TP implementation, which adds an additional tunneling protocol to the IPSec implementation.

L2TP and IPSec

The major difference between the ESP tunnel and L2TP is that the L2TP tunnel performs at Layer 2 of the OSI Model, the data link layer. This way, L2TP can tunnel additional protocols, such as IPX or NetBEUI. IPSec's ESP tunneling protocol tunnels only the TCP/IP protocol, based on the standard. When L2TP and IPSec are used in combination to provide a secured tunnel, the original packet header is used to carry the packet's source and final destination, whereas the tunnel packet's IP header might contain the address of an IPSec gateway. The L2TP header carries the information needed to route the packet over the network. The Point-to-Point Protocol (PPP) header within the encapsulated packet identifies the protocol of the original packet. In other words, when using L2TP to transfer data, IPSec is used to secure the tunnel. L2TP encapsulates the packet in a PPP frame. The PPP frame is then added to a UDP-type frame assigned to port 1701. UDP, which is part of the TCP/IP suite, qualifies for IPSec to secure the contents; thus, the contents of L2TP are secure, regardless of the originating protocol and/or data type.

One additional benefit of the L2TP method is that you have a choice of additional encryption algorithms for securing the data.

Now that you have a basic introduction to the benefits and background of the IPSec protocol, you are ready to look at working with IPSec.

Configuring and Implementing IPSec

Configure network protocol security.

  • Configure protocol security in a heterogeneous client computer environment.

  • Configure protocol security by using IPSec policies.

Before enabling IPSec on your local computer or domain, you should configure IPSec through policies. An IPSec policy is a set of rules that define how and when communication is secured between two endpoints. This is done through the configuration of various rules. Each rule contains a collection of actions and filters that begin when they encounter endpoints that match.

Policies allow you to quickly and easily configure IPSec based on the settings required within your organization. Windows Server 2003 comes with the following three preconfigured IPSec policies that may or may not meet your needs:

  • Client (Respond Only) This policy requires IPSec-provided security only when another computer requests it. This policy allows the computer to attempt unsecured communications first and switch to IPSec-secured communications if requested. 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 that is being secured. This policy, which can be used on workstations and servers alike, provides the minimum amount of IPSec security.

  • Server (Request Security) This policy requests security from the other computer and allows unsecured communication with non IPSec-aware computers. The computer accepts inbound unsecured traffic but always attempts to secure further communications by requesting IPSec security from the sending computer. If the other computer is not IPSec-enabled, the entire communication is allowed to be unsecured. This policy, which can be used on workstations and servers alike, provides a medium level of IPSec security.

  • Secure Server (Require Security) This policy is implemented on computers that require highly secure communications, such as servers transmitting sensitive data. The filters in this policy require all outbound communication to be secured, allowing only the initial inbound communication request to be unsecured. This policy has a rule to require security for all IP traffic, a rule to permit ICMP traffic, and the default response rule to respond to requests for security from other computers. This policy, typically used only on servers, provides the highest level of IPSec security on a network. This policy can also be used on workstation computers if you want.

    Non IPSec-enabled computers cannot establish any communications with computers using this policy.

You can opt to either use one of the preconfigured policies that comes with Windows Server 2003 or create your own policy. You can also modify the preconfigured policies to suit your needs if you want. Before we can go any further into our discussion about IPSec, we first need to create the tools that allow us to manage IPSec on a local computer. Step by Step 7.4 helps you to create your own IPSec management console.

STEP BY STEP

7.4 Creating the IPSec Management Console

  1. Open a blank MMC by clicking Start, Run. Then type MMC to open a blank MMC, as shown in Figure 7.19.

    Figure 7.19. The MMC provides a powerful, flexible framework from which to manage Windows Server 2003.

  2. In your new console, click the File menu and select Add/Remove Snap-in. The Add/Remove Snap-in dialog box opens, as shown in Figure 7.20.

    Figure 7.20. You can add snap-ins to your console to customize its management features.

  3. Click the Add button to open the Add Standalone Snap-in dialog box, as shown in Figure 7.21.

    Figure 7.21. Windows Server 2003 comes with several dozen snap-ins you can choose from.

  4. Scroll down the list, select IP Security Monitor, and click the Add button.

  5. Select IP Security Policy Management and click the Add button. You are prompted to choose the scope that the snap-in will manage, as shown in Figure 7.22.

    Figure 7.22. Many MMC snap-ins can be targeted at several different levels of management.

  6. For this example, choose Local Computer from the Select Computer or Domain page. Notice that you have the option to select the Active Directory domain that this computer is part of, another Active Directory domain, or another computer. Click Finish to complete the addition of the IP Security Policy Management snap-in to your console.

  7. Click Close on the Add Standalone Snap-in dialog box.

  8. Click OK on the Add/Remove Snap-in dialog box. Your completed IPSec management console is shown in Figure 7.23.

    Figure 7.23. Your completed IPSec management console contains the tools you need to manage and monitor IP Security.

  9. Save your newly created console by clicking File, Save. Enter a suitable name, such as Local IPSec Management Console , and click Save. By default, the console is saved in the Administrative Tools folder of the currently logged-in user.


Armed with your newly created IPSec management console, you can now get down to work configuring and managing IPSec. At this point, you may want to do one of two things: implement a preconfigured IPSec policy or create one of your own. We explore the latter in the next Step by Step. You can accomplish the former by right-clicking the desired policy in the right pane of the console window and selecting Assign from the context menu, as shown in Figure 7.24. Note that you can have only one IPSec policy assigned at a time.

Figure 7.24. Assigning an IPSec policy to the local computer is a quick task.

You can verify that the policy is now assigned to the computer by examining the Active Policy node of the IP Security Monitor, as shown in Figure 7.25.

Figure 7.25. The IP Security Monitor can be used to display many bits of useful information about IPSec.

We examine the use of the IP Security Monitor console later in this chapter. For now, we need to look at the process to create a custom IPSec policy.

Creating Customized IPSec Policies

Plan for network protocol security.

  • Plan an IPSec policy for secure network communications.

Configure security for data transmission.

  • Configure IPSec policy settings.

After you've decided to use IPSec on your network, you may realize that the preconfigured IPSec policies do not provide exactly the solution you are looking for. You can opt to either customize an existing policy or create a new one from scratch. I prefer to create policies from scratch to ensure that I have complete control over every piece of the puzzle, and that's exactly what IPSec can turn out to be if not treated with caution and respectone large puzzle that you are left to piece together.

Before we start to actually create our own IPSec policy, let's take a few moments to examine the parts that make up an IPSec policy by dissecting the Secure Server (Require Security) policy. From within your IPSec management console, double-click this policy to open its Properties dialog box, as shown in Figure 7.26. It has two tabs: Rules and General.

Figure 7.26. Examining the properties of a preconfigured IPSec policy can help us to learn what makes up such a policy.

Let's look at the Rules tab first. The IP Security Rules window lists all the IP Security Rules that are active for that policy. Selecting a rule and clicking the Edit button opens the Edit Rule Properties dialog box, as shown in Figure 7.27. Its five tabs contain the configuration settings for this particular rule.

Figure 7.27. The IP Filter List tab of the Edit Rule Properties dialog box.

The IP Filter List tab shows all IP filters configured for the selected rule. An IP filter contains source and destination IP addresses that apply to this rule. These IP addresses can be those of an individual computer or that of a network subnet. If this tab identifies a network communication that has a participant listed in an IP filter, a particular filter action that is specific for that connection is applied. Selecting the All IP Traffic filter for editing opens the dialog box shown in Figure 7.28. From here, you can specify many items, including the source and destination IP addresses that this filter applies to.

Figure 7.28. You can edit the filter properties to specify the source and destination computers that they apply to.

The Filter Actions tab of the Edit Rule Properties dialog box, shown in Figure 7.29, contains actions that specify the type of security and methods by which security is established.

Figure 7.29. The Filter Actions tab defines the types of security and methods by which security is established.

Filter actions (see Figure 7.30) define the type of security and methods by which security is established. The default methods are Permit, Block, and Negotiate Security. The Permit option passes the traffic without the requirement for security. This action is appropriate if you never want to secure traffic to which a rule applies. The Block action silently blocks all traffic from computers specified in the IP filter list. The Negotiate Security action specifies that the computer is to use a list of security methods to negotiate the appropriate security for the communication.

Figure 7.30. You can specify exactly what the computer will do when a filter action is processed .

If the Negotiate Security action is selected, both computers must make an agreement on the security parameters to be used, meaning that they both must support at least one common set of security parameters from those in the list. The list entries are processed in order of preference from top to bottom. The first security method shared by both computers is used.

From the Authentication Methods tab, shown in Figure 7.31, you can configure what method will be used to authenticate both sides of the communication. You can choose from Kerberos (the default setting), a digital certificate, or a shared secret (string) that will be used to protect the key exchange process. You can configure more than one method and also choose the order of precedence for your configured methods. Using the shared secret is not recommended because this static entry can be compromised.

Figure 7.31. You can specify Kerberos, digital certificate, or shared secret as the authentication methods.

From the Tunnel Setting tab, shown in Figure 7.32, you can either have the rule apply to a tunnel by specifying an endpoint or not have it apply to a tunnel (transport mode).

Figure 7.32. The Tunnel Setting tab allows you to configure a tunnel endpoint if required.

The Connection Type tab, shown in Figure 7.33, determines for which types of connections the rule will be applied: LAN, Remote Access, or All Network Connections.

Figure 7.33. The Connection Type tab allows you to specify which connections are affected by the policy.

You can create two basic types of IPSec policies: those that specify a tunnel and those that do not specify a tunnel. Tunneling is commonly used in the creation of a VPN and is called tunnel mode. Not using a tunnel, called transport mode, is commonly used between subnets or computers on an intranet. Step by Step 7.5 shows how to create a new IPSec policy that operates in transport mode between two subnets (192.160.11.0 and 192.168.12.0) in the same intranet of the company Area 51 Partners. These two subnets represent the Accounting and Payroll departments, respectively, and they need to pass only secured traffic between their subnets.

STEP BY STEP

7.5 Creating a Custom Transfer Mode IPSec Policy

  1. Open the IPSec management console that you created in Step by Step 7.4.

  2. Right-click IP Security Policies and select Create IP Security Policy from the context menu.

  3. Dismiss the opening page of the IP Security Policy Wizard by clicking Next.

  4. On the IP Security Policy Name dialog box, enter a descriptive name for the new policy. For this example, use Accounting to Payroll Security Policy , as shown in Figure 7.34. Click Next after entering the required information.

    Figure 7.34. You should enter a policy name and description that will make sense later.

  5. On the Requests for Secure Communication dialog box, shown in Figure 7.35, deselect Activate the Default Response Rule option. You will configure this policy entirely by yourself. Click Next to continue.

    Figure 7.35. Removing the opportunity for unsecured communications to occur with the new rule.

  6. You are now at the end of the wizard portion of the creation process. Ensure that the Edit Properties option is selected, as shown in Figure 7.36, and click Finish to begin editing the policy's properties.

    Figure 7.36. The completion of the wizard is not the completion of the policy creation process.

  7. The Accounting to Payroll Security Policy Properties dialog box opens, as shown in Figure 7.37.

    Figure 7.37. Your new IPSec policy requires some configuration to complete.

  8. On the Rules tab, ensure that the Use Add Wizard option is selected; then click the Add button to start the Security Rule Wizard to create a new filter list and action.

  9. Click Next to dismiss the opening page of the Security Rule Wizard.

  10. On the Tunnel Endpoint dialog box, shown in Figure 7.38, select This Rule Does Not Specify a Tunnel (recall that this IPSec policy is being created to secure communications between two subnets on the same intranet). Click Next to continue.

    Figure 7.38. You can create a rule for either transport mode or tunnel mode.

  11. On the Network Type dialog box, shown in Figure 7.39, select the network connections to which this rule applies. For this example, select All Network Connections and click Next to continue.

    Figure 7.39. Selecting All Network Connections ensures that all communications by the server are secured using the new policy.

  12. The IP Filter List dialog box, shown in Figure 7.40, shows that no IP filters are configured for this rule. Click the Add button to create a filter that meets your requirements.

    Figure 7.40. You must configure an IP filter for this rule to work properly.

  13. From the IP Filter List dialog box, shown in Figure 7.41, you need to configure the IP filter properties for this rule. Enter a descriptive name such as Accounting to Payroll security in the name box and a description if you like. Ensure that the Use Add Wizard option is selected and click the Add button.

    Figure 7.41. The process to configure an IP filter begins with the IP Filter List dialog box.

  14. The IP Filter Wizard opens to start the process of configuring the IP filter. Click Next to dismiss the opening page of the wizard.

  15. On the IP Filter Description and Mirrored Property dialog box, shown in Figure 7.42, enter a description of the filter. Ensure that the Mirrored option is selected. This option allows the rule to automatically match packets with the exact opposite source and destination addresses to ensure that machines from the destination subnet are also included in the incoming filter. Click Next to continue.

    Figure 7.42. Allowing the IP filter to be mirrored saves you work.

  16. On the IP Traffic Source dialog box, select the A Specific IP Subnet option and configure the IP Address and Subnet mask as required. Recall that we are creating a policy between the 192.168.11.0 and 192.168.12.0 subnets. Enter 192.168.11.0 and the subnet mask of 255.255.255.0 , as shown in Figure 7.43, and click Next to continue.

    Figure 7.43. Be sure to specify the correct source address and subnet mask.

  17. On the IP Traffic Destination dialog box, select the A Specific IP Subnet option and configure the IP Address and Subnet mask as required. Enter 192.168.12.0 and the subnet mask of 255.255.255.0 , as shown in Figure 7.44, and click Next to continue.

    Figure 7.44. Be sure to specify the correct destination address and subnet mask also.

  18. On the IP Protocol Type dialog box, shown in Figure 7.45, you can configure which IP protocol types you want to be included in the filter. We want the filter to apply to all types, so leave the default selection of Any and click Next to continue.

    Figure 7.45. You can configure the filter to be very specific about what types of protocols it applies to.

  19. The Completing the IP Filter Wizard dialog box opens, as shown in Figure 7.46. Deselect the Edit Properties option and click Finish.

    Figure 7.46. The IP filter has been created, but much work still remains.

  20. Back at the IP Filter List dialog box, you can see your newly created IP filter. Click OK to close the filter and complete the creation process. If you click Cancel, your newly created filter will be lost, so be careful.

  21. Select the Accounting to Payroll Security filter from the list on the IP Filter List dialog box, as shown in Figure 7.47, and click Next to continue with the Security Rule Wizard.

    Figure 7.47. You need to select the filter for use after creating it.

  22. On the Filter Action dialog box, shown in Figure 7.48, select a filter action. Ensure that the Use Add Wizard option is selected and click Add to start the Filter Action Wizard.

    Figure 7.48. You now need to configure the action that the filter will take.

  23. The Filter Action Wizard starts. Dismiss its opening dialog box by clicking Next.

  24. On the Filter Action Name dialog box, enter a descriptive name and description for the filter. Click Next to continue.

  25. On the Filter Action General Options dialog box, shown in Figure 7.49, select Negotiate Security and click Next to continue.

    Figure 7.49. Instructing the filter action to negotiate security between communication computers.

  26. On the Communicating with Computers That Do Not Support IPSec dialog box, shown in Figure 7.50, you are asked whether you want to allow unsecured communications. In this case, such communications are not allowed because all communications must be secured. Ensure that the Do Not Communicate with Computers That Do Not Support IPSec option is selected and click Next to continue.

    Figure 7.50. Ensure that you do not allow unsecured communications to occur.

  27. On the IP Traffic Security dialog box, shown in Figure 7.51, select Custom to specify what security methods are to be used. Click Settings to edit the security settings.

    Figure 7.51. You can specify custom settings or use the standard settings provided.

  28. The Custom Security Method Settings dialog box, shown in Figure 7.52, opens. From here, you can specify the settings you want. Ensure that both the AH and ESP check boxes are selected. Configure the desired integrity and encryption algorithms. Do not configure settings for the session key at this time. Click OK to accept your settings.

    Figure 7.52. You can specify the encryption and integrity algorithms to be used in your filter action.

  29. Back at the IP Traffic Security dialog box, click Next to continue.

  30. On the Completing the IP Security Filter Action Wizard dialog box, shown in Figure 7.53, ensure the Edit Properties option is selected and click Finish.

    Figure 7.53. The Filter Addition Wizard is completed, but the filter still requires a bit more configuration.

  31. Back at the filter action Properties dialog box, shown in Figure 7.54, ensure the Use Session Key Perfect Forward Secrecy (PFS) option is selected and click OK. Selecting session key PFS ensures that the master key keying material cannot be used to generate more than one session key, which adds both security and overhead to the connection. Do not click Cancel unless you want to scrap your newly configured filter action. Click OK.

    Figure 7.54. Selecting to use perfect forward secrecy to increase the security of the session key.

  32. Back at the Filter Action dialog box, shown in Figure 7.55, select the newly created filter and click Next to continue.

    Figure 7.55. The filter action is configured, so it's time to move on.

  33. On the Authentication Method dialog box, shown in Figure 7.56, select the primary authentication method this rule will use. The default selection of Kerberos v5 should be used in most cases. You can add additional authentication methods after the rule has been configured. Click Next to continue.

    Figure 7.56. Specify the preferred authentication method; Kerberos v5 is preferred.

  34. From the Completing the Security Rule Wizard dialog box, ensure that the Edit Properties option is deselected and click Finish to complete the rule creation process.

  35. Finally, you are back to the policy Properties dialog box, as shown in Figure 7.57. You still have some additional configuration that you can complete, however.

    Figure 7.57. The new security rule is displayed in the policy's properties.

  36. On the General tab, you can configure the interval at which the computer will check for updates and changes to the security policy, as shown in Figure 7.58. The default setting of 180 minutes is usually acceptable.

    Figure 7.58. Configuring the policy update interval.

  37. You can modify the settings used for the IKE process by clicking the Settings button at the bottom of the General tab.

  38. On the Key Exchange Settings dialog box, shown in Figure 7.59, you can configure for Master key perfect forward secrecy, which improves security of the keying process. Additionally, you can change the defaults provided for key generation.

    Figure 7.59. You can configure advanced IKE properties from the Key Exchange Settings dialog box.

  39. If you want to configure the methods used to protect the identities, click the Methods button. The Key Exchange Security Methods dialog box opens, as shown in Figure 7.60. Note that by default the new 2048-bit Diffie-Hellman key exchange method is not used. You can select it by adding or editing a security method, as shown in Figure 7.61.

    Figure 7.60. Customizing the key exchange security methods can increase security.

    Figure 7.61. Using the new 2048-bit Diffie-Hellman key exchange method.

  40. Click OK as required to return to the policy Properties dialog box. Your new IPSec policy is now configured and ready to use. Assign it as previously discussed at the end of the "Configuring and Implementing IPSec" section of this chapter.


IPSec can be deployed at any level within your organization. Thus far, we have examined it only from the point of view of a local computer. You can just as easily apply it via Group Policy using the Active Directory Users and Computers console, as shown in Figure 7.62.

Figure 7.62. You can easily apply IPSec at the domain or OU level using Group Policy.

With the task of implementing IPSec out of the way, you are now left to monitor and troubleshoot it, as we examine in the next section.

Monitoring and Troubleshooting IPSec

Troubleshoot security for data transmission. Tools might include the IP Security Monitor MMC snap-in and the Resultant Set of Policy (RSoP) MMC snap-in.

With all the work behind you in configuring and deploying IPSec, you now must manage and monitor its use on your network. Fortunately, we have already seen a small bit of the monitoring tool of choice: the IP Security Monitor snap-in. Recall in Step by Step 7.4 that we constructed an IPSec management console, which contained the IP Security Monitor snap-in.

The IP Security Monitor MMC Snap-in

The IP Security Monitor snap-in is divided into three major areas: the Active Policy node, Main Mode node, and Quick Mode node. We saw the Active Policy node previously in Figure 7.25. Table 7.4 explains each of the items in the Active Policy node of the IP Security Monitor.

Table 7.4. Active Policy Node Items

Item

Description

Policy Name

Provides the name of the active IPSec policy.

Description

Provides the description of the active IPSec policy.

Policy Last Modified

Provides the date and the time that the active IPSec policy was modified.

Policy Store

Provides the storage location for the active IPSec policy. For a local policy, it reads Local Store , and for a domain policy, it reads Domain Store .

Policy Path

Applies only to domain policies and provides the LDAP path to the active IPSec policy.

Organizational Unit

Applies only to domain policies and lists the organizational unit to which the Group Policy object is applied.

Group Policy Object Name

Applies only to domain policies and lists the Group Policy object to which the active IPSec policy is applied.

The Main Mode node, shown in Figure 7.63, provides information about the Phase I security associations (SAs) as detailed in Table 7.5.

Figure 7.63. The Main Mode node displays information about the Phase I SAs.

Table 7.5. Main Mode (IKE) Statistics

Main Mode Statistic

Description

Active Acquire

Displays a request by the IPSec to have IKE perform a task. This number includes all outstanding and queued requests and is typically a value of 1. Under heavy loading, this number increases.

Active Receive

Displays the number of IKE messages that have been received and are queued for processing.

Acquire Failures

Displays the number of times that an acquire has failed.

Receive Failures

Displays the number of times that errors have occurred in receiving IKE messages.

Send Failures

Displays the number of times that errors have occurred in sending IKE messages.

Acquire Heap Size

Displays the number of entries in the acquire heap, which stores active acquires. This number increases with heavy loading and should decrease as the heap is cleared.

Receive Heap Size

Displays the number of entries in the IKE receive buffers for incoming IKE messages.

Authentication Failures

Displays the total number of identity authentication failures that have occurred during Main Mode negotiation. This is a useful indicator to determine whether the authentication methods do not match between two computers attempting communications.

Negotiation Failures

Displays the total number of negotiation failures that occurred during Main Mode or Quick Mode negotiation. This is a useful statistic to determine whether security and/or authentication methods do not match between two computers attempting communications.

Invalid Cookies Received

A value contained in a received IKE message that IKE uses to find the state of an active Main Mode. If a cookie in a received IKE message cannot be matched with an active Main Mode, it is invalid.

Total Acquire

Displays the total number of requests submitted by IKE to the IPSec driver to establish an SA for securing traffic.

Total Get SPI

Displays the total number of requests submitted by IKE to the IPSec driver to obtain a unique Security Parameters Index.

Key Additions

Displays the number of outbound Quick Mode SAs that IKE adds to the IPSec driver.

Key Updates

Displays the number of inbound Quick Mode SAs that IKE adds to the IPSec driver.

Get SPI Failures

Displays the number of requests submitted by IKE to the IPSec driver to obtain a unique SPI that have failed.

Key Addition Failures

Displays the number of outbound Quick Mode SA addition requests submitted by IKE to the IPSec driver that have failed.

Key Update Failures

Displays the number of inbound Quick Mode SA addition requests submitted by IKE to the IPSec driver that have failed.

ISADB List Size

Displays the number of Main Mode state entries, including negotiated Main Modes, Main Modes in progress, and Main Modes that have failed and have not yet been deleted.

Connection List Size

Displays the number of Quick Mode state entries. This number indicates the load placed on the computer.

IKE Main Mode

Displays the total number of successful SAs created during Main Mode negotiations.

IKE Quick Mode

Displays the total number of successful SAs created during Quick Mode negotiations. Typically, multiple Quick Mode SAs are created for each Main Mode SA; thus, this value may not necessarily match that of the Main Mode.

Soft Associations

Displays the total number of negotiations that resulted in the use of unsecured traffic (also known as soft SAs). Typically, this is an indication of SAs formed with computers that do not support IPSec or were not able to negotiate a successful IPSec connection. This can be an indication of mismatched security and authentication settings.

Invalid Packets Received

Displays the number of received IKE messages that were invalid. Most commonly, invalid IKE messages are a result of retransmitted IKE messages or an unmatched shared key between the communicating computers.

The Quick Mode node, shown in Figure 7.64, provides information about the Phase II SAs as detailed in Table 7.6.

Figure 7.64. The Quick Mode node displays information about the Phase II SAs.

Table 7.6. Quick Mode (IPSec) Statistics

Quick Mode Statistic

Description

Active Security Associations

Displays the number of active IPSec SAs.

Offloaded Security Associations

Displays the number of active IPSec SAs that have been offloaded to hardware.

Pending Key Operations

Displays the number of IPSec key operations that are in progress.

Key Additions

Displays the total number of successful IPSec SA negotiations.

Key Deletions

Displays the number of key deletions for IPSec SAs.

Re-Keys

Displays the number of rekey operations for IPSec SAs.

Active Tunnels

Displays the number of active IPSec tunnels.

Bad SPI Packets

Displays the total number of packets for which the Security Parameters Index was incorrect. SPIs are used to match inbound packets with an SA. If the SPI is incorrect, the inbound SA may have expired . If rekeying intervals are set very short, this number is likely to increase very rapidly. Under normal conditions, a bad SPI packet does not mean that IP Security is failing because SAs expire normally.

Packets Not Decrypted

Displays the total number of packets that were not decrypted successfully. This may indicate that a packet has arrived for which the SA has previously expired. When the SA expires , the session key used to decrypt packets is removed. By itself, this does not indicate that IP Security is failing.

Packets Not Authenticated

Displays the total number of packets for which data could not be verified , meaning that the integrity hash verification failed. Most commonly, this is the result of an expired SA.

Packets With Replay Detection

Displays the total number of packets that contained a valid Sequence Number field.

Confidential Bytes Sent

Displays the total number of bytes sent using the ESP protocol.

Confidential Bytes Received

Displays the total number of bytes received using the ESP protocol.

Authenticated Bytes Sent

Displays the total number of bytes sent using the AH protocol.

Authenticated Bytes Received

Displays the total number of bytes received using the AH protocol.

Transport Bytes Sent

Displays the total number of bytes sent using IPSec transport mode.

Transport Bytes Received

Displays the total number of bytes received using IPSec transport mode.

Bytes Sent in Tunnels

Displays the total number of bytes sent using IPSec tunnel mode.

Bytes Received in Tunnels

Displays the total number of bytes received using IPSec tunnel mode.

Offloaded Bytes Sent

Displays the total number of bytes sent using hardware offload.

Offloaded Bytes Received

Displays the total number of bytes received using hardware offload.

As far as configuring the IP Security Monitor, it hasn't changed much since Windows 2000. You can open the IP Security Monitor properties for any server listed in the IP Security Monitor node by right-clicking it and selecting Properties. The server Properties dialog box opens, as shown in Figure 7.65. You have the option to change the refresh interval for the IP Security Monitor statistics that are displayed and also whether you want to enable DNS name resolution; this comes into play when you are examining the SAs that are formed.

Figure 7.65. You don't have to configure very much for the IP Security Monitor's properties.

The Resultant Set of Policy (RSoP) MMC Snap-in

The Resultant Set of Policy (RSoP) snap-in can be added to a blank or custom MMC to provide a means for you to create queries that poll Group Policy at all levels and then report the results of the query. RSoP gathers this information from the Common Information Management Object Model (CIMOM) database ( otherwise known as CIM-compliant object repository) through Windows Management Instrumentation (WMI).

Often when policies are applied on multiple levels, results can conflict. Using the RSoP snap-in can easily help you to determine where the problem lies and the precedence (processing order) of the policies involved. RSoP can be used in one of two modes:

  • Planning Mode Allows you to simulate the effect of policy settings that you want to apply to a computer and user

  • Logging Mode Allows you to determine the existing policy settings for a computer and user who is currently logged on

RSoP can be added to an MMC using the same basic process as discussed in Step by Step 7.4. After you have created the custom MMC, right-click the Resultant Set of Policy object and select Generate RSoP Data to start the Resultant Set of Policy Wizard. Run the query in logging mode by following the wizard through the required steps. When you are done running the query, you can examine the results, specifically for the IPSec policies, as shown in Figure 7.66.

Figure 7.66. You can use RSoP to determine what policies are applied to users and computers.

General IPSec Troubleshooting

If you have problems with IPSec, you should first verify that any routers or firewalls you may be passing through are configured to support IPSec traffic. You need to allow the following traffic:

  • Protocol ID 50 and 51 or ESP and AH traffic

  • UDP port 500 for IPSec negotiation traffic

Following are some other basic troubleshooting tips:

  • You are not able to establish any communications with a computer . In this case, you should first verify that basic network connectivity exists between the computers in question. Ensure also that all required network services, such as DHCP and DNS, are operating properly for both computers.

  • You are not able to establish any communications with a computer . This may also be the result of a computer that has been removed from the domain, which causes IPSec communications to fail.

  • Communications are occurring, but not as expected . Ensure that you have the correct (and compatible) IPSec policies assigned on both computers.

  • No hard associations are being formed . If soft associations are currently in place, a hard association is not formed. You need to completely stop all communications between the computers for about 510 minutes to allow the soft associations to time out. The easiest way to do this is to disable the network connection. After you have allowed the soft association to time out, you can check to see that a hard association has been formed. If a hard association still has not been formed, you need to examine your IPSec policy to verify that unsecured communications are not allowed.

  • IPSec communications are failing after configuring a digital certificate for authentication . You must make sure that the required digital certificate is installed on the computers attempting to communicate using that IPSec policy. This can also be the result of specifying an incorrect Certificate Authority (CA).

  • Some computers can create IPSec connections and some cannot . This situation is most likely caused by not having the same IPSec policy applied to all your computers. If you are intentionally using different policies, ensure that they share at least one common authentication and security method.



MCSE Windows Server 2003 Network Infrastructure (Exam 70-293)
MCSE 70-293 Exam Prep: Planning and Maintaining a Microsoft Windows Server 2003 Network Infrastructure (2nd Edition)
ISBN: 0789736500
EAN: 2147483647
Year: 2003
Pages: 151
Authors: Will Schmied

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