Dela via


Security issues for VPN

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

Security information for VPN

It is important to follow best practices for security when using VPN servers on your network. For more information, see Best practices for security.

If your VPN servers are configured as Remote Authentication Dial-In User Service (RADIUS) clients, see Security information for IAS.

The following are known security issues for VPN connections:

  • Many authentication methods are too weak to provide adequate security for most organizations.

    Many organizations use authentication methods that expose their network to a variety of security attacks. The most secure method of authentication is Extensible Authentication Protocol-Transport Level Security (EAP-TLS) when used in conjunction with smart cards. However, EAP-TLS and smart cards require a public key infrastructure (PKI), which can be complicated to deploy.

Recommendations:

  • When you use password-based authentication, enforce strong password policies on your network to make dictionary attacks more difficult. For more information, see Strong passwords.

  • Make sure that Password Authentication Protocol (PAP), Shiva Password Authentication Protocol (SPAP), and Challenge Handshake Authentication Protocol (CHAP) are disabled. PAP, SPAP, and CHAP are disabled by default on the profile of a remote access policy.

  • Disable Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). MS-CHAP is enabled by default on the profile of a remote access policy. Before you disable MS-CHAP, ensure that all of the clients of your access server are capable of using MS-CHAP version 2 (MS-CHAP v2). If your server is not running Microsoft® Windows Server 2003 , you will need the latest service packs and dial-up networking updates in order to support MS-CHAP v2.

  • If you do not disable MS-CHAP, disable LAN Manager authentication for MS-CHAP. LAN Manager authentication for MS-CHAP is enabled by default on clients running earlier versions of Windows.

  • To disable LAN Manager authentication, set the registry value Allow LM Authentication to 0 at the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Note

  • You can change an entry in the registry using Registry Editor. For more information, see Registry Editor and Change a value.

  • Make sure that MS-CHAP v2 is enabled. MS-CHAP v2 is enabled by default on the profile of a remote access policy.

  • For wireless clients running Windows XP, enable Protected Extensible Authentication Protocol (PEAP) with Extensible Authentication Protocol (EAP)-MS-CHAP v2. PEAP with EAP-MS-CHAP v2 provides mutual authentication: the IAS server is authenticated with a certificate, while user authentication is accomplished with password-based credentials. For more information, see New features for IAS. For an example of a remote access policy that uses PEAP, see Wireless access with secure password authentication.

  • Enable EAP-TLS. EAP-TLS is disabled by default on the profile of a remote access policy. When you use the EAP-TLS authentication protocol, you must install a computer certificate on the IAS server. For client and user authentication, you can install a certificate on the client computer, or you can use smart cards. Before you deploy certificates, you must design the certificate with the correct requirements. For more information, see Network access authentication and certificates and Computer certificates for certificate-based authentication.

  • Remote access account lockout can deny network access to authorized users.

    When remote access account lockout is enabled, if a malicious user attempts a dictionary attack with the logon name of an authorized user, both the malicious user and the authorized user are locked out of the account until the account lockout threshold is reached.

Recommendations:

  • Be cautious when defining account lockout policy. For more information, see Password Best practices.

  • When the lockout count for a user account is reset to 0, due to either a successful authentication or an automatic reset, the registry subkey for the user account is deleted. To manually unlock a user account (before the account lockout threshold is automatically reset), delete the following registry subkey that corresponds to the account name of the user:

    **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\**DomainName:UserName

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Notes

  • You can change an entry in the registry using Registry Editor. For more information, see Registry Editor and Change a value.

  • Remote access account lockout is not related to the Account locked out setting on the Account tab on the properties of a user account.

    Remote access account lockout does not distinguish between malicious users who attempt to access your intranet and authentic users who attempt remote access but have forgotten their current passwords. Users who have forgotten their current password typically try the passwords that they remember and, depending on the number of attempts and the MaxDenials setting, might be locked out of their accounts.

  • The default domain functional level setting (Windows 2000 mixed) can create security holes.

    You should use only servers that are running Windows 2000 or Windows Server 2003 , if possible. Using servers running Routing and Remote Access in conjunction with servers that are running Windows NT®  4.0 and either Remote Access Service (RAS) or Routing and Remote Access Service (RRAS) decreases your network security. For more information, see Domain and forest functionality and Member server in a domain.

Additional recommendations:

  • Allow the VPN server or a DHCP server to assign IP address leases to VPN clients.

    Do not allow VPN clients to specify their own IP address. The method by which the VPN server assigns addresses to remote access clients (either using addresses that the VPN server obtains from a DHCP server or using addresses from a specified range of addresses that you configure) is set when you run the Routing and Remote Access Server Setup Wizard. For more information, see L2TP-based remote access VPN deployment and DHCP.

  • Always use Layer Two Tunneling Protocol/Internet Protocol security (L2TP/IPSec) connections for the strongest encryption.

    Use smart cards for the most secure authentication and certificates when smart cards are not practical.

  • Use certificates for Internet Key Exchange (IKE) negotiations.

    Do not use preshared keys, as they are susceptible to dictionary attacks.

For more information about security considerations and best practices, see: