Share via

IPSec Best practices

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Best practices

  • Establish an IPSec deployment plan.

    The deployment plan should address the following considerations: which deployment scenarios (such as server-to-server or remote access) require the use of IPSec, what level of security you require for each scenario, which types of data to secure, which computers to secure, which physical links to secure, who will manage IPSec policies, and how you will provide ongoing support and troubleshooting for end users after IPSec is deployed. The deployment plan should also address broader organizational security issues, such as the vulnerability of the network to specific types of attacks, the use of Active Directory, and how security is applied to Group Policy objects.

    For more information about IPSec security planning, see Establishing an IPSec security plan.

    For more information about Active Directory, see Active Directory Overview.

  • Create and test IPSec policies for each deployment scenario.

    Before deploying IPSec in a production environment, test the IPSec policies in a realistic lab environment. To obtain realistic performance data, run standard workloads on programs. During initial tests, view packet contents with Network Monitor, or use Authentication Header (AH) or Encapsulating Security Payload (ESP) with null encryption to view packet contents for test environments.

  • Do not use preshared keys.

    For enhanced security, the use of preshared key authentication is not recommended because it is a relatively weak authentication method. In addition, preshared keys are stored in plaintext. Preshared key authentication is provided for interoperability purposes and to adhere to IPSec standards. It is recommended that you use preshared keys only for testing and that you use certificates or Kerberos V5 instead in a production environment.

    For more information, see Preshared key authentication.

  • Do not use Diffie-Hellman Group 1 (low).

    For enhanced security, do not use Diffie-Hellman Group 1, which provides 768 bits of keying strength. For maximum security, use Group 2048 (high), which provides 2,048 bits of keying strength. Use Group 2 (medium), which provides 1,024 bits of keying strength when required for interoperability with Windows 2000 and Windows XP. Strong Diffie-Hellman groups combined with longer key lengths increase the computational difficulty of determining a secret key.

    For more information, see Key exchange methods.

    Note

    • Diffie-Hellman Group 2048 is provided only with the Windows Server 2003 family.

  • Use the Triple Data Encryption Standard (3DES) algorithm for stronger encryption.

    For enhanced security, when configuring key exchange security methods for IPSec policies, use 3DES, which is a stronger encryption algorithm than DES.

    For information about how to configure key exchange security methods, see Create key exchange security methods.

    Note

    • Computers running Windows 2000 must have the High Encryption Pack or Service Pack 2 (or later) installed in order to use the 3DES algorithm. If a computer running Windows 2000 receives a 3DES setting, but does not have the High Encryption Pack or Service Pack 2 (or later) installed, the 3DES setting in the security method is set to the weaker DES, to provide some level of confidentiality for communication, rather than blocking all communication. However, you should only use DES as a fallback option if not all computers in your environment support the use of 3DES. Computers running Windows XP or a Windows Server 2003 operating system support 3DES and do not require installation of the High Encryption Pack.

  • Create and assign a persistent IPSec policy for failsafe security.

    To enhance security, create and assign a persistent IPSec policy, so that computers can be secured if a local IPSec policy or an Active Directory-based IPSec policy cannot be applied. When you create and assign a persistent policy, it is applied before a local policy or an Active Directory-based policy, and it remains in effect regardless of whether the local policy or the Active Directory-based policy is applied (for example, an IPSec policy will not be applied if it is corrupted).

    Note

    • You cannot configure this feature in the IP Security Policy Management console. To configure this feature, you must use the Netsh IPSec command-line tool. For more information, see Netsh commands for Internet Protocol security.

  • For computers connected to the Internet, do not send the name of the certification authority (CA) with certificate requests.

    When certificate authentication is used to establish trust between IPSec peers, each IPSec peer sends to the other peer a list of trusted root CAs from which it accepts a certificate for authentication. Each of these CA names is sent as a certificate request payload (CRP), and it must be sent before trust is established. Although transmitting this list aids in connectivity by facilitating the selection of a CA, it can expose sensitive information about the trust relationships of a computer, such as the name of the company that owns the computer and the domain membership of the computer (if an internal public key infrastructure is being used), to an attacker. Therefore, to secure computers that are connected to the Internet, enable the option to exclude the CA name from the certificate request.

  • For computers connected to the Internet, do not use Kerberos as an authentication method.

    When Kerberos V5 authentication is used, during main mode negotiation, each IPSec peer sends its computer identity in unencrypted format to the other peer. The computer identity is unencrypted until encryption of the entire identity payload takes place during the authentication phase of the main mode negotiation. An attacker can send an Internet Key Exchange (IKE) packet that causes the responding IPSec peer to expose its computer identity and domain membership. To secure computers that are connected to the Internet, certificate authentication is recommended.

    For more information, see Authentication methods.

  • For computers that are connected to the Internet, do not allow unsecured communication.

    If you configure a filter action to negotiate IPSec security, ensure that the following options are disabled in order to secure computers that are connected to the Internet:

    • Accept unsecured communication, but always respond using IPSec. This option allows initial incoming unsecured traffic (for example, TCP SYN packets) but requires outgoing traffic to be protected. This option should be disabled to prevent denial-of-service attacks.

    • Allow unsecured communication with non-IPSec-aware computers. This option allows unsecured communications with computers that cannot negotiate the use of IPSec or process IPSec-secured communications, and it is appropriate only in environments where IPSec-secured communication is not necessary.

      For more information, see Filter action.

  • Restrict the use of administrative credentials in your organization.

    Members of the local Administrators group can view and modify the IPSec policy settings on their computers. For this reason, and as a general security best practice, ensure that end-users in your organization use the principle of least privilege.

    For information about general best practices for security, see Best practices for security for security.

  • When applying the same IPSec policy to computers running different versions of the Windows operating system, test the policy thoroughly.

    Several features in the Windows Server 2003 family implementation of IPSec are not provided in Windows 2000 or in Windows XP. These new features include:

    • A stronger Diffie-Hellman group (2,048-bit Diffie-Hellman key exchange).

    • The ability for IPSec policy filters to allow logical addresses for local IP configuration.

    • The removal of default traffic exemptions from IPSec filtering (only Internet Key Exchange traffic is now exempt by default).

    • The ability to exclude the name of the certification authority (CA) from a certificate request.

    To ensure that the same IPSec policy functions as expected on computers running the Windows Server 2003 family and on computers running Windows XPor Windows 2000, test the policy thoroughly on all relevant operating systems before deployment.

    For more information about new features in IPSec, see New features for IPSec.

  • Use the Windows Server 2003 IP Security Policy Management console to manage the IPSec policies that use the new features that are available only in the Windows Server 2003 family implementation of IPSec.

    If you plan to apply IPSec policies that use any of the new features that are available only in the Windows Server 2003 family implementation of IPSec, do not use the Windows XP or the Windows 2000 version of the IP Security Policy Management console to manage these policies. The settings in the earlier versions of the IP Security Policy Management console will override the settings in the Windows Server 2003 family IPSec policy, and the new features will not be functional.

  • Use Terminal Services to remotely manage and monitor IPSec on computers running different versions of the Windows operating system.

    Remote management and monitoring of IPSec is supported only for computers running the same version of the Windows operating system. To remotely manage and monitor IPSec on a computer that is running a different version of Windows than the version of Windows that is running on your computer, use Terminal Services. For example, if your computer is running the Windows Server 2003 family, and you plan to remotely manage and monitor IPSec on computers running Windows 2000 or Windows XP, use Terminal Services to gain remote access to these computers.

    If your computer is running the Windows Server 2003 family, and you plan to manage and monitor IPSec on computers that are also running the Windows Server 2003 family, you can run the IPSec Policy Management console and IP Security Monitor, or you can use the Netsh command-line tool remotely.