Using IPSec


IPSec is a terrific adjunct to other kinds of security measures. It doesn t protect stored data, but it does an excellent job of protecting data in transit, provided that you deploy it properly. Microsoft has a wealth of documentation covering the proper way to deploy IPSec on Windows 2000 and Windows Server 2003 networks, so I confine my comments here to a general discussion of using IPSec with Exchange. For a more general reference, see the TCP/IP Core Networking Guide in the Windows 2000 Server Resource Kit , available online at http://www.microsoft.com/windows2000/techinfo/reskit/en-us/ or in print from Microsoft Press.

In Chapter 2, Security Protocols and Algorithms, I laid out the basics of IPSec, including mention of the key security protocols that make up the IPSec suite. There are a couple of additional details that are useful at this point, beginning with what actually happens when two nodes establish an IPSec connection. Connection isn t the proper term ; IPSec architects refer to this connection as a security association (SA). The SA provides a secure communications channel between two specified hosts , using a specified port and protocol, in one direction. Of course, you have to have some way to set up the SA, which requires that each end have some way to encrypt data to be sent to the other end. That s why one of the important parts of the IPSec suite is the Internet Key Exchange (IKE) capability. IKE is a part of the IPSec suite; its function is to allow any two IPSec-capable computers to securely agree on a shared encryption key. IKE actually implements portions of two related protocols: the Internet Security Association Key Management Protocol (ISAKMP; see RFC 2409) and the OAKLEY protocol for key determination (see RFC 2412).

SA setup actually takes place in two phases: in the first phase (also known as main mode ) the two ends authenticate one another s identities and generate a Main Mode SA. Think of the Main Mode SA as a master SA: all other communications between the two machines will happen after ISAKMP negotiations take place. These negotiations are carried over the Main Mode SA. The Main Mode key can be derived using three mechanisms:

  • Kerberos This is the default IPSec authenticator in Windows IPSec. The Kerberos authentication package uses the machine account generated for each computer in an Active Directory domain. The primary benefit of this approach is that as long as the machine accounts stay in synchronization across the domain, IPSec works with no fiddling. However, you can only use Kerberos authentication with machines in the same Active Directory forest.

  • X.509 certificates Because each certificate is associated with a public/private key pair, it s natural to leverage them as an authenticator for IPSec. The catch is that you have to issue certificates to each machine that you want to access your network, and you must ensure that all CAs from which those certificates are issued chain to a common (and trusted) root CA.

start sidebar
CRL Checking for IPSec

By default, IPSec doesn t check to see whether certificates presented by remote machines are on any known certificate revocation lists (CRLs). To enable it, you have to set HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Oakley\StrongCrlCheck to 1. There are actually two possible values for this key:

  • 1 means that the certificate validation should fail if the CRL explicitly indicates that the certificate has been revoked . This is the standard type of CRL checking. If the CRL cannot be retrieved from the network (either locally or from the CRL distribution point) or if the CRL doesn t contain an entry for the certificate, the certificate is assumed to be valid.

  • 2 means that certification validation should fail on any CRL-related error. This is the strongest type of certificate validation. The CRL distribution point must be reachable on the network, the publisher of the CRL must have issued the certificate, and the certificate must not be revoked.

    After making this change, you ll need to stop and then restart the IPSec Policy Agent service. This setting applies to Windows 2000 and Windows Server 2003; you might consider applying it through Group Policy if you have a widely distributed set of servers.

end sidebar
 
  • Preshared keys The name should tip you off; this key-sharing mechanism requires you to distribute a predefined key to each device that might want to speak IPSec to you. As you can imagine, this quickly becomes a hassle for large numbers of devices, and having the key floating around greatly increases the risk that an unauthorized user will get hold of it. However, preshared keys are still in common use for one situation: quick deployment of IPSec to secure traffic from mobile users back to their home networks.

    Caution  

    Preshared keys are dangerous for another reason: the keys themselves are stored in clear text in the registry (look in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy ). Microsoft recommends against deploying preshared keys for production use, and this is a key reason why.

Once these negotiations are complete, IKE mode 2 (also known as quick mode ) kicks in. Quick Mode SAs default to a lifetime of five minutes or 100 MB of traffic; that means that on an IPSec-protected connection, the session key used to protect the actual traffic is only used for five minutes or 100 MB, whichever comes first. (However, the predefined IPSec filters included in the standard policies have a lifetime of 15 minutes.) The master SA key, however, is good for a default lifetime of eight hours. Quick Mode SAs protect traffic on a specific source/destination/protocol/port combination, so there can be several of them for each Main Mode SA between a pair of machines.

Tip  

If you want to see the active Main Mode SAs on your servers, you ll have to use the netdiag command: netdiag.exe /test:ipsec /v will do the trick.

Understanding the Windows IPSec Implementation

You can think of a Windows IPSec policy as a small database made up of records. Each record represents an IPSec rule. Each rule, in turn , contains several fields: a filter list, a filter action, an authentication mechanism, a tunnel setting, and a connection type.

The filter list field in the rule is actually a foreign key that points to the filter in another, separate database ”a database of filters. This means that when you create a filter list, you re not actually creating the filter inside your rule, or IPSec policy; you re actually creating it in the filters database and referencing the new record in your rule. This indirection allows you to create a filter list in one policy and use it in another. Likewise, filter actions can be shared between policies as well ”a very powerful capability. The authentication mechanism, tunnel setting, and connection type components of the rule are created inside the rule itself, and can t be referenced in other rules.

Now it s time to translate that abstract knowledge into a more concrete understanding of how Windows implements IPSec and what you can do with it. There are several important IPSec pieces scattered around various parts of the Windows 2000 family:

  • The IPSec driver (Ipsec.sys) is a low-level network driver that implements the code that actually encrypts, decrypts, signs, and verifies packets. The driver is ultimately responsible for applying the rules you define to decide which packets, on which ports, can pass and which ones should be blocked.

  • The IKE component actually handles IKE negotiations for phase 1 and phase 2. You can audit success or failure of these negotiations in the system event log.

  • The IPSec policy agent is responsible for downloading IPSec policies from the domain controller (or the registry, for machines that aren t in a domain) and applying them. The fastest way to force an update to an existing set of policies is to manually stop and restart the policy agent service.

An IPSec policy is what its name indicates: a statement about what, when, and how you want IPSec applied to a particular set of communications. There are three predefined policies in Windows 2000; these are normally applied to Exchange servers, file and print servers, Web servers, and workstations.

Tip  

In the wonderful world of IPSec, client just means a machine that s requesting a connection to another machine ”the client might be an Exchange server, a domain controller, a workstation, or a PocketPC. The same is true for server. Don t let the fact that you apply a policy named client to your Exchange server throw you off track.

  • The Client (Respond Only) policy specifies that the target machine can respond to IPSec SA negotiation requests , but it shouldn t initiate them on its own.

  • The Server (Request Security) policy instructs the server to request an IPSec negotiation when connecting to another machine. However, if this negotiation fails for some reason, the connection can proceed without IPSec, leaving all traffic on that connection unprotected .

  • The Secure Server (Require Security) policy forces the server to require the use of IPSec. At the start of a connection, a machine with this policy assigned requests an IPSec SA. If negotiation fails, the Secure Server machine drops the connection. This enforces the security settings you specify in the policy, but it can severely limit which machines the policy target can talk to ”often the entire intention !

To see how effective these basic policies can be, it s instructive to note what happened at the recent OpenHack competition sponsored by eWeek Magazine . Microsoft took the somewhat unusual tack of setting up the Secure Server (Require Security) policy on all ports except port 80, because the contest revolved around offering Web services. Guess what? No one managed to hack the Windows box. Of course, you have to be careful, lest you assign the wrong policy and prevent legitimate traffic from reaching your machine.

Fortunately, Windows allows you to easily build and deploy custom IPSec policies. Whether you create your own policy or use one of the canned ones, when you assign an IPSec policy you re actually specifying a number of things:

  • The policy itself contains information that applies to all rules in the policy. For example, each policy has a name, along with a set of key exchange settings and permitted algorithms for phase 1 negotiations. There s also a default response rule that tells the policy what to do with packets that don t match any of the policy-specific rules.

  • A set of IPSec security rules. Each policy contains at least one rule. Rules specify the types of traffic to be protected ( expressed by source or destination IP address or port number) and what authentication settings are to be used.

Each rule, in turn, contains an IPSec filter list and a filter action. The filter action specifies what should be done to packets that match the filter list; you can choose to block or accept unsecured packets, or to request IPSec but fall back to unsecured communications if IPSec isn t available. The filter list itself contains a list of specifications that allow the IPSec driver to determine which packets should match. For example, you could create a filter list like the one shown in Figure 11-9; this list would protect traffic from any port on a local machine to port 80 on any foreign machine.

click to expand
Figure 11-9: A simple filter list: protect all traffic to port 80 on other machines.

Finally, each rule specifies a set of authentication mechanisms that can be used. These work in conjunction with the filter action, which actually specifies the type of authentication or encryption you want to use.

This nesting can be confusing, especially because when you re creating a new rule the rule wizard starts still other wizards to help you create the rule and all its components. Figure 11-10 shows how the IPSec policy, rules, and filter components are related to one another.

click to expand
Figure 11-10: Policies, rules, and filters nest together.
start sidebar
Careful with Those Exemptions

None of the IPSec policies protects every last bit of traffic. There are some traffic types that cannot be protected, and some that aren t protected by default. First, the Windows IPSec implementation doesn t cover broadcast or multicast traffic; this is due to the design of the IPSec stack and has not changed in Windows 2000 (although Microsoft Windows XP does allow you to turn this exemption off).

In addition, the default settings don t protect IKE, Resource Reservation Protocol (RSVP), or Kerberos traffic. Let s deal with those in reverse order:

  • Kerberos already implements its own security mechanisms, so it doesn t need IPSec protection. Accordingly, in transport mode Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) port 88 aren t protected (although they are in tunnel mode, because it s used to build LAN-to-LAN virtual private networks [VPNs] where domain controllers need to talk to each other).

  • The RSVP protocol (protocol ID 46) has to be able to pass unencrypted traffic to all network devices that might have a quality of service (QoS) impact, including computers, routers, and packet-shaping devices.

  • IKE traffic has to pass in the clear so that the source and destination systems can agree on a key; IKE traffic uses UDP port 500.

    On Windows Server 2003, the exemptions for everything except IKE are disabled; you can force Windows 2000 to turn off these default exemptions by setting (or adding) the NoDefaultExempt value in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\ key to 1. Be careful when you do this, though; you might encounter unexpected Kerberos failures when you suddenly prevent plaintext Kerberos traffic from passing. See Microsoft Knowledge Base articles 254728 and 254949.

end sidebar
 

Creating IPSec Policies

There are several ways to create IPSec policies:

  • You can create policies for a single machine using the Local Security Policy object on a single machine s Group Policy editor.

  • On Windows XP, you can create static or dynamic policies from the command line with the ipseccmd tool; on Windows 2000 (Professional and the Server family), you use Ipsecpol.exe.

  • Windows Server 2003 adds the much more flexible netsh ipsec command, which allows you to configure a number of properties (like CRL checking behavior) that aren t visible from the normal user interface. I m not going to cover it here, but see the Windows Server 2003 product documentation for more information on how to use it, and see the companion Web site to this book ( http://www.e2ksecurity.com ) for some sample netsh scripts for using IPSec with Exchange Server 2003.

For most Exchange sites, the best alternative will be to create and manage IPSec policies with the Group Policy editor, because if you followed the recommendations in Chapter 6, Windows Server Security Basics, your front-end and back-end servers are in their own separate OUs. Using Group Policy for network security might seem a bit odd, but it makes more sense when you consider that IPSec policies are just another Active Directory item that can be applied to sites, domains, or OUs (as well as individual machines, although Active Directory “specified policies override locally built ones). To start managing policies, first you ll need to find where they reside:

  1. Open the Microsoft Management Console (MMC; Mmc.exe) and use the Add/Remove Snap-In command on the File menu (or just press Ctrl+M).

  2. In the Add/Remove Snap-In dialog box, click Add. In the Add Standalone Snap-In dialog box, select the Group Policy editor, and click Add. When the Select Group Policy Object dialog box opens, click the Browse button to select the target of your IPSec policies, and click OK once you ve identified the target. (If you took my suggestion from Chapter 6 and put your Exchange servers into their own OU or domain, that s a natural target!) Click Finish, then click Close and OK in the other dialog boxes you ve opened.

  3. Expand your policy object. IPSec policies for Group Policy Objects are stored in the Computer Configuration container; look under Windows Settings Security Settings IP Security Policies On Active Directory.

Once you have the snap-in open, you ll notice that the predefined policies I mentioned earlier are listed in the right-hand pane. The Policy Assigned column shows whether the specified policy is in effect for the target site, domain, or OU; by default, no policy is in effect. Assign the Server (Request Security) policy to your domain, then wait a few minutes and try pinging from one machine to another. You won t notice any immediate difference, unless you use the Ipsecmon.exe utility to watch the SAs currently in use on your machine, but IPSec is still working to secure your traffic.

To create a new policy, first identify what you want to protect. This identification breaks down into a few simple questions:

  1. What source or destination addresses does the protected traffic use? Do you want to protect LAN traffic only, Internet traffic only, or all traffic?

  2. What source or destination ports does the protected traffic use?

  3. What authentication and security mechanisms do you want to use on this traffic? In what order should they be tried?

  4. What do you want to do with communication requests that don t meet your IPSec requirements: should they be allowed or blocked?

Once you have answers for these four questions in mind, you re ready to begin. The most useful example of IPSec use with Exchange is protecting front-end-to-back-end traffic, which is why it s covered in Chapter 14. Using IPSec to protect IMAP and POP traffic is a close second, though, because those protocols can transmit authentication information in the clear (see Chapter 15 to learn how to keep them from doing so). That makes the answers to these questions fairly simple: you want to protect traffic from any Internet Protocol (IP) address on your LAN to ports 110 or 143 on your Exchange servers. You don t need to protect ports 993 or 995, used for SSL-protected POP or IMAP, because SSL is already protecting these exchanges. You can t effectively use IPSec to protect these protocols from the Internet unless you use certificate-based authentication ”preshared keys are too dangerous, and Kerberos requires both sides of the connection to be members of domains that trust each other. You want to use the best possible security and authentication algorithms, and you want to allow unsecured traffic, but only as a fallback if IPSec negotiation fails.

The actual process for creating your new policy is fairly straightforward, even though it involves more wizards than a Harry Potter novel . Begin by right-clicking the IP Security Policies node in the Group Policy editor snap-in and selecting the Create IP Security Policy command. That launches the IP Security Policy Wizard. The basic process to follow is to create a policy, then to create a rule within that policy, filling out the rule s filter list and filter action along the way.

  1. Click Next to skip the Welcome page, if necessary. On the IP Security Policy Name page, give your policy a name; this name is used for display in the IPSec tools, so choose one that will remind you of what the policy is for. Click Next .

  2. The second wizard page asks you to decide whether you want to activate the default response rule. This rule governs what happens to traffic requests when there s no corresponding rule. For example, if your IMAP rule were the only one defined in a policy that was applied to all computers in a domain, the default response rule would specify what should happen to non-IMAP traffic for all of those machines. Until you re more comfortable with IPSec, you ll want to leave the default response rule alone. Once you ve decided whether to select the Activate Default Response Rule check box, click Next.

  3. If you choose to enable the default response rule, you ll have an opportunity to choose which authentication method can be used with that rule; you get to choose among Kerberos, digital certificates, and preshared-key authenticators. Figure 11-11 shows this wizard page; pay attention, because you ll be seeing it again. Click Next to continue.

    click to expand
    Figure 11-11: The Authentication Method page lets you choose among the IPSec authenticators that Windows supports.

  4. When you reach the last page of the IP Security Policy Wizard, you might notice the Edit Properties check box. It s selected by default, which is good, as it opens the properties for your new policy; this saves you from having to do it yourself.

The Properties dialog box for your new policy looks a little sparse at first, because the only thing visible is the default response rule. To secure IMAP traffic, you need to create a new rule (and its associated filter list and action). Accordingly, you ll need to do the following:

  1. Make sure the Use Add Wizard check box is selected, then click Add. That launches the Security Rule Wizard. Skip the Welcome page by clicking Next.

  2. On the Tunnel Endpoint page, you can create rules for IPSec s tunnel or transport modes (see Chapter 2 for an explanation of the difference between these modes). This filter should use transport mode, which means the second wizard page is irrelevant ”it asks you to specify an endpoint address for a tunnel-mode rule. Click Next.

  3. Select the type of network you re securing; you can apply your new rule to LAN traffic, remote access traffic (for example, traffic that originates from the Internet), or all traffic. For this example, let s say that you re trying to secure traffic across your wide area network (WAN); select the All Network Connections option and click Next.

  4. Next up is the Authentication Methods page first shown in Figure 11-11. You can use this page to select the authentication you want to apply ”remember, in the policy-creation wizard, you re setting authentication policy for the default response rule, and here you re setting it for the newly created rule. Click Next.

  5. The IP Filter List page appears. There are already two default filter lists; in fact, any filter list you ve previously defined appears here, making it easy to reuse them. The default All ICMP Traffic and All IP Traffic filters are very useful for securing all traffic, but in our case all we want to do is secure IMAP, so we ll need a new filter list. Accordingly, click Add on this page. The IP Filter List dialog box opens, but it s blank. Name your new filter list, then click Add (after, of course, ensuring that the Use Add Wizard check box is selected). That launches the IP Filter Wizard.

    • If necessary, skip the Welcome page by clicking Next. The IP Traffic Source page in the IP Filter Wizard allows you to specify the source address on which you want to filter. This filter should apply to any IP address that s trying to contact your IMAP server, so use the Source Address drop-down list to select Any IP Address. (You can also set filters by specified DNS names , a single IP address, or an IP subnet.) Pick the source set of addresses, then click Next.

    • The IP Traffic Destination wizard page allows you to pick the destination address (with the same possibilities as the source address). Because this rule is supposed to filter traffic from anywhere to a single destination, change the Destination Address drop-down list to A Specific IP Address, then type in the IP address of your Exchange server and click Next.

    • IPSec filter lists can apply to individual ports or to entire protocols. (In this case, protocol means a network-layer protocol like IP or Internet Control Message Protocol [ICMP], not an application protocol like IMAP.) By selecting the protocol you want from the IP Protocol Type page, you can select whether you want to protect a specific protocol or all protocols. For our purposes, it s sufficient to choose TCP before clicking Next. Note that you can only select individual ports for the filter list if you choose TCP or UDP as the protocol type.

    • The IP Protocol Port page (see Figure 11-12) opens if you choose TCP or UDP as the filter protocol. It allows you to choose the source and destination ports that you want to filter. Remember that for TCP and UDP, the source port number might vary, but filtering on the destination port allows us to catch all traffic bound for a particular service. Accordingly, leave the From Any Port option selected, then select To This Port and type 143 in the associated text field, then click Next.

      click to expand
      Figure 11-12: Choose the source and destination ports you want to apply.

      At this point, your filter is just about ready to use. The final page of the IP Filter Wizard includes the now-familiar Edit Properties check box, but this time it s cleared. Go ahead and click Finish to create the filter; you ll return to the IP Filter List dialog from step 5. Click OK to close the dialog box, then you can pick up with the process of creating the rule.

    1. On the IP Filter List page of the Security Rule Wizard, make sure that your new rule is selected, as shown in Figure 11-13, and click Next.

      click to expand
      Figure 11-13: Select the newly created filter list to make it part of the rule you re creating.

    2. Now that you ve specified which packets should be filtered, it s time to specify what action you want to take. The Filter Action page gives you three preset filter actions: Permit, Request Security (Optional), and Require Security. If your goal is to require the use of IPSec for IMAP traffic, then selecting Require Security would do the trick. However, you can build your own, more sophisticated, custom actions by clicking Add. Let s look at the process for adding custom actions and security negotiations. First, verify that the Use Add Wizard check box is selected, and click Add.

      • Skip the Welcome page if necessary by clicking Next. On the Filter Action Name page, name the filter, and optionally give it a description.

      • The Filter Action General Options page is next, with three options: Permit, Block, or Negotiate Security. If you wanted to create a rule that would block any traffic matching your filter list (for example, traffic from the Internet to port 135), selecting Block would do the trick. Instead, let s examine the options for negotiating security: select the Negotiate Security option and click Next.

      • When you create a custom action, you can choose whether the action is permissive or restrictive. A permissive action allows the communication to fall back to unsecured mode if the IPSec negotiation fails; a restrictive action drops the connection if an IPSec SA with the requested parameters can t be established. For maximum security, you ll want to create restrictive actions, which you do by selecting the Do Not Communicate With Computers That Do Not Support IPSec option on the wizard page (see Figure 11-14) before clicking Next. In some situations (like when you still have to let people reach your server across your LAN or WAN), you might want to allow unsecured communications; just be aware that when you do so, IPSec isn t guaranteed to be in effect for those communications.

        click to expand
        Figure 11-14: Actions can allow or deny non-IPSec traffic that matches the filter rule.

      • The IP Traffic Security page lets you choose what types of security protection will be used. The High option specifies that both Encapsulating Security Payload (ESP) and Authentication Header (AH) will be used. The Medium option specifies AH alone. The Custom protection level allows you to use the Custom Security Method Settings dialog box, shown in Figure 11-15. By default, a new action uses Message Digest 5 (MD5) and Data Encryption Standard (DES) for AH and ESP security; I recommend tweaking your actions to require SHA-1 and 3DES instead. The Custom Security Method Settings dialog box also allows you to change the interval at which a new Quick Mode IKE exchange takes place. After returning to the IP Traffic Security page, select the desired security level and click Next. Click Finish to complete the Filter Action Wizard.

        click to expand
        Figure 11-15: You can select a custom set of algorithms and Quick Mode IKE settings for each rule.

    3. After returning to the Security Rule Wizard, select your new filter action, and click Next. Click Finish to complete the Security Rule Wizard.

      Note  

      If you want your policy to support multiple authentication methods, open the policy s Properties dialog box and click the Authentication tab. You can add any combination of authentication methods, and you can adjust their order to specify which one should be used first.

The New Filter Action Properties dialog box, shown in Figure 11-16, bundles all of the filter action settings into one place. Rather than use the wizard, which is easy but inefficient, I usually recommend that administrators use the Properties dialog box directly ”it allows you to quickly set the filter action, specify exactly which security methods you want applied, and control whether IPSec is mandatory or optional for packets that match the filter list. As you can see in Figure 11-16, it s possible to set multiple security methods and put them in order of preference; the figure shows AH- SHA1 and ESP-3DES first, followed by ESP-DES, and then AH-MD5. The effect of this action would be to attempt to use ESP and AH together, followed by ESP only, falling back to AH alone only if neither of the ESP negotiations succeeded.

click to expand
Figure 11-16: All of the filter action settings are located in the New Filter Action Properties dialog box.



Secure Messaging with Microsoft Exchange Server 2003
Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)
ISBN: 0735619905
EAN: 2147483647
Year: 2004
Pages: 189

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