This section provides overviews of advanced security features that can be used with Windows Server 2003 and Windows XP VPN connections.
Symmetric, or private-key, encryption (also known as conventional encryption) is based on a secret key that is shared by both communicating parties. The sending party uses the secret key as part of the mathematical operation to encrypt (or encipher) plain text to cipher text. The receiving party uses the same secret key to decrypt (or decipher) the cipher text to plain text. Examples of symmetric encryption schemes are the RSA RC4 algorithm, which provides the basis for MPPE, and DES, which is used for IPSec encryption.
Asymmetric, or public-key, encryption uses two different keys for each user: one is a private key known only to this one user; the other is a corresponding public key, which is accessible to anyone. The private and public keys are mathematically related by the encryption algorithm. One key is used for encryption and the other for decryption, depending on the nature of the communication service being implemented.
In addition, public-key encryption technologies allow digital signatures to be placed on messages. A digital signature uses the sender’s private key to encrypt some portion of the message. When the message is received, the receiver uses the sender’s public key to decipher the digital signature to verify the sender’s identity.
With symmetric encryption, both sender and receiver have a shared secret key. The distribution of the secret key must occur (with adequate protection) prior to any encrypted communication. However, with asymmetric encryption, the sender uses a private key to encrypt or digitally sign messages, while the receiver uses a public key to decipher these messages. The public key can be freely distributed to anyone who needs to receive the encrypted or digitally signed messages. The sender needs to carefully protect the private key only.
To secure the integrity of the public key, the public key is published with a certificate. A certificate (or public key certificate) is a data structure that is digitally signed by a certification authority (CA)—an authority that users of the certificate can trust. The certificate contains a series of values, such as the certificate name and usage, information identifying the owner of the public key, the public key itself, an expiration date, and the name of the certificate authority. The CA uses its private key to sign the certificate. If the receiver knows the public key of the certificate authority, the receiver can verify that the certificate is indeed from the trusted CA and, therefore, contains reliable information and a valid public key. Certificates can be distributed electronically (through Web access or e-mail), on smart cards, or on floppy disks.
In summary, public key certificates provide a convenient, reliable method for verifying the identity of a sender. IPSec can optionally use this method for peer-level authentication. Remote access servers can use public key certificates for user authentication.
EAP-TLS is an IETF standard (RFC 2716) for a strong authentication method based on public-key certificates. With EAP-TLS, a client presents a user certificate to the dial-in server, and the server presents a server certificate to the client. The first provides strong user authentication to the server; the second provides assurance that the user has reached the server that he or she expected. Both systems rely on a chain of trusted authorities to verify the validity of the offered certificate.
The user’s certificate could be stored on the VPN client computer or in an external smart card. In either case, the certificate cannot be accessed without some form of user identification (PIN number or name-and-password exchange) between the user and the client computer. This approach meets the two factor authentication mentioned earlier—the something-you-know-plus-something-you-have criteria recommended by most security experts.
EAP-TLS is supported in Windows Server 2003 and Windows XP. Like MS-CHAP and MS-CHAP v2, EAP-TLS returns an encryption key to enable subsequent data encryption by MPPE.
Network Access Quarantine Control, a new feature in the Windows Server 2003 family, delays normal remote access to a private network until the configuration of the remote access computer has been examined and validated by an administrator- provided script. When a remote access computer initiates a connection to a remote access server, the user is authenticated and the remote access computer is assigned an IP address. However, the connection is placed in quarantine mode, with which network access is limited. The administrator-provided script is run on the remote access computer. When the script completes successfully, it runs a notifier component that notifies the remote access server that the remote access computer complies with current network policies. The remote access server removes quarantine mode, and the remote access computer is granted normal remote access.
Figure 3-1: Quaratine Control Operations
Network Access Quarantine Control is a combination of the following:
A remote access server running Windows Server 2003 and a quarantine notification listener service
A RADIUS server running Windows Server 2003 and Internet Authentication Service (IAS), configured with a quarantine remote access policy that specifies quarantine settings
A Connection Manager profile created with the Windows Server 2003 Connection Manager Administration Kit that contains a network policy compliance script and a notifier component
A remote access client that is running Windows Server 2003, Windows XP, Windows 2000, Windows Millennium Edition, or Windows 98 Second Edition
For more information about Network Access Quarantine Control, see Chapter 5.
The remote access account lockout feature is used to specify how many times a remote access authentication fails against a valid user account before the user is denied remote access. Remote access account lockout is especially important for remote access VPN connections over the Internet. Malicious users on the Internet can attempt to access an organization intranet by sending credentials (valid user name, guessed password) during the VPN connection authentication process. During a dictionary attack, the malicious user sends hundreds or thousands of credentials by using a list of passwords based on common words or phrases. With remote access account lockout enabled, a dictionary attack is thwarted after a specified number of failed attempts.
The remote access account lockout feature 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 might have their accounts locked out.
If you enable the remote access account lockout feature, a malicious user can deliberately force an account to be locked out by attempting multiple authentications with the user account until the account is locked out, thereby preventing the authentic user from being able to log on.
Changing settings in the registry on the computer that provides the authentication configures the remote access account lockout feature. If the remote access server is configured for Windows authentication, modify the registry on the remote access server computer. If the remote access server is configured for RADIUS authentication and Internet Authentication Service (IAS) is being used, modify the registry on the IAS server computer. For more information, see the topic titled “Remote access account lockout” in Windows Server 2003 Help and Support Center.
The remote access account lockout feature is not related to the Account Locked Out setting on the Account tab on the properties of a user account or to the administration of account lockout policies using Group Policy.
As described earlier, just because the user has access to the network via VPN, that does not mean that the user should have access to every resource on the network while accessing from an unsecured location. Remote access policies that define authorization and connection constraints can be used to specify a set of IP packet filters that are applied per user or group to remote access connections. When the connection is accepted, the packet filters define the types of IP traffic that are allowed from and to the VPN client.
This feature can be used for extranet connections. An extranet is a portion of your organization network that is accessible to users outside the organization, such as business partners and vendors. By using remote access policy profile packet filtering, you can create a remote access policy that specifies that members of the Partners group can only access the Web servers at specific IP addresses or on a specific subnet.
This feature can also be used to prevent VPN remote access clients from sending packets that they did not originate. When the remote access client computer makes the VPN connection, by default it creates a default route so that all traffic that matches the default route is sent over the VPN connection. If other computers are forwarding traffic to the remote access VPN client, treating the remote access client computer as a router, then that traffic will also be forwarded across the VPN connection. This is a security problem because the VPN server has not authenticated the computer that is forwarding traffic to the remote access VPN client. The computer forwarding traffic to the remote access VPN client computer has the same network access as the authenticated remote access VPN client computer.
To prevent the VPN server from receiving traffic across the VPN connection for computers other than authenticated remote access VPN client computers, configure remote access policy packet filters on the remote access policy that is used for your VPN connections. The default remote access policy for Windows Server 2003 named Connections To Microsoft Routing And Remote Access Server already has the correct input packet filters for this configuration.
Although this is the default setting for the VPN server to apply filters for all individual remote users, this can make the IP filter list quite huge in a large- scale environment, thus potentially causing a performance hit. If you are seeing performance degrade when going into the thousands of users per gateway, make sure to use Quarantine to check to make sure the client’s routing bits are disabled, thus blocking the client from acting as a router, and then disable the individual IP filters and see if this improves performance.