Remote Access Security

Remote Access Security Overview

To protect your corporate data from attacks from intruders and from being accessed by unauthorized users, you need to plan for and implement remote access security. You should authenticate remote access clients attempting to establish a remote connection with the remote access server. To secure connections to the corporate network, you can configure properties that either allow remote access or deny remote access. You can also specify authorization using the source number or destination phone number as the basis.

There are a number of strategies that you can use to secure remote access connections:

Control access through the Dial-in Properties of an individual user account. This is the account that remote access clients utilize to connect to the network.
Create and configure remote access policies.
Create and configure remote access profiles.
Configure remote access authentication and encryption.
You can use Remote Authentication Dial-In User Service (RADIUS) to provide authentication, authorization, and accounting for your remote access implementation.
Configure advanced security features such as smart cards, callback security.
Raise the domain functional level to provide additional security features for your remote access implementation.

Planning Remote Access Security

You should include planning of remote access security when planning your over-all remote access solution. A few issues that need to be clarified are listed below:

Not all users in an organization require remote access. You should therefore identify those users that need remote access and configure only these users to have remote access. Authentication can be used to restrict remote access to only those users that are specified for remote access. You can use remote access policies to define the requirements (conditions) that users must match to obtain remote access.
In addition, not all users need to access the entire network. You should restrict access to the remote access server for those users that only need to access the remote access server to complete their tasks.
Because all users do not need to have access to all resources, you can use permissions to allow different users, different levels of remote access.
Users can also be restricted to specific applications only. You do this by configuring packet filters to allow traffic that uses specific protocols and port numbers only.

For dial-in access, you would want to control which users are able to remotely access the network:

You can allow or disallow remote access for individual users. You can configure individual user access through the Properties dialog box of a specific user, on the Dial-in tab. The Active Directory Users and Computers management console is the tool used to access the Properties dialog box of a specific user account.
You can allow or disallow remote access by configuring remote access policies. This method allows you to specify remote access rights based on various criteria, such as users, group, and time of day. The settings specified on the Properties dialog box of a specific user, on the Dial-in tab dictates whether a user is affected by remote access policies. The different settings on the Dial-in tab of the Properties dialog box of a particular user are:
- Allow Access; the user is allowed to remotely access the network. The remote access policies are not included in the decision.
- Deny Access: the user is denied permission to remotely access the network.
- Control Access Through Remote Access Policy; the remote access policies dictate whether or not the user is allowed remote access.
Remote access policies can also be used to further restrict remote connections after they have been authorized by the Routing and Remote Access Service (RRAS), based on the following:
- Idle timeout time setting
- Maximum session time setting
- IP packet filters
- Encryption strength
- IP addresses for PPP connections and static routes

When planning a VPN remote access strategy, the security specific requirements that you need to clarify are discussed next. The placement of the VPN servers could dictate that you implement additional security measures.

If you place VPN server on the private internal network, the firewall has to allow traffic to the VPN server.
If you place the VPN server on the perimeter network, you need to do the following:
- On the VPN server, configure inbound and outbound filters that allow VPN traffic to and from the Internet interface of the VPN server.
- On the firewall, configure it to allow traffic from the VPN server.

You would also need to determine which VPN protocols to utilize. You can support the use of one or both of the VPN protocols:

Point-to-Point Tunneling Protocol (PPTP)
Layer Two Transport Protocol (L2TP).

The factors to consider when deciding on which VPN protocol to use are:

The requirements of the remote access clients:

Windows 95, Windows 98, Windows ME, Windows NT 4.0, Windows 2000, Windows XP and Windows Server 2003 support PPTP
Only Windows 2000, Windows XP and Windows Server 2003 support L2TP.

Public Key Infrastructure (PKI) requirements: A Public Key Infrastructure (PKI) is needed for the mutual authentication of the VPN server and the client. Certificates need to be installed on the VPN server and VPN clients. In addition to this, user authentication needs protocols such as Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) and Extensible Authentication Protocol Transport Layer Security (EAP-TLS).

IPSec requirement: L2TP can be used with IPSec to provide encryption. If you need authentication for the VPN server and the client, then you need to be able to support L2TP. Only L2TP over IPSec can provide data integrity.

The following section examines the differences between the VPN protocols, and when each protocol should be implemented:

PPTP should be implemented when the following statements are true:
- You need to support legacy Windows clients.
- Client-to-gateway connectivity or network-to-network connectivity is a requirement.
- The VPN must move over a firewall or perimeter server that performs NAT. The only VPN protocol that can pass through NAT is PPTP.
L2TP should be implemented when the following statements are true:
- All client computers have installed computer certificates.
- Client-to-gateway connectivity or network-to-network connectivity is a requirement.
- You want to use an IPSec tunnel.
- The server is not located behind a firewall or a perimeter server that performs NAT.
IPSec tunnel mode should be implemented when the following statements are true:
- Certificate based authentication is being used.
- Certificates are issued by a trusted Certificate Authority.
- Network-to-network connectivity is a requirement.
- Machine authentication is required for the tunnel endpoints.

For VPN remote access, the different levels of encryption that you can configure are:

No encryption: This option allows unencrypted VPN connections.
Basic encryption: This option is also not frequently used because the weaker 40-bit key is used for encryption.
Strong encryption: A 56-bit key is used for encryption.
Strongest encryption: A 128-bit key is used for encryption.

When planning a wireless remote access strategy, the security specific requirements that need to be considered are summarized below:

Remote access policies that allow wireless users to connect to the network have to be configured.
For Wireless Access Points (WAP) to use IAS authentication, the following additional configurations are necessary:
- Each WAP must be added as a RADIUS client in the IAS MMC snap-in.
- On the WAP, you have to enable RADIUS authentication and define the primary and backup IAS servers.
Because security is a high priority for wireless networks, WAPs and adapters that support the elements listed next should be used:
- Firmware updates
- WEP using 128-bit encryption
- Disabling of SSID broadcasts
- MAC filtering to restrict wireless access based on MAC addresses.
Determine the following important factors.
- Whether the Wi-Fi Protected Access (WPA) protocol or the Wired Equivalent Privacy (WEP) protocol will be used.
- For the WEP protocol, determine whether 64-bit or 128-bit encryption will be used.
- Whether 802.1X authentication will be used.
- Whether wireless clients will use IPSec.
- Whether MAC address filtering will be used.
- Whether Group Policy will be used to configure wireless client security.

Securing Remote Access through the Dial-in Properties of a User Account

The different options that you can configure on the Dial-In tab of a specific user account in the Active Directory Users And Computers management console are:

In the Remote Access Permission (Dial-in Or VPN) area, you can select one of the following options:
- Allow Access: The Allow Access option allows remote access for the specific user account. The Allow Access option overrides any settings specified through remote access policies.
- Deny Access: The Deny Access option prevents remote access for the specific user account.
- Control Access Through Remote Access Policy: When you select the Control Access Through Remote Access Policy option, whether or not the user is allowed remote access is determine by remote access policies applied to the connection.
You can enable the Verify Caller ID checkbox to specify the phone number of the user that should be verified before the remote access connection can be established. A connection will only be established if the number that the user is calling from corresponds with the number configured here.
The Callback Options area of the Dial-in tab is where you specify the following:
- No callback.
- Set by caller
- Always callback to a specific callback number.

Callback Security is a feature that you can use for dial-in connections. When enabled, and a remote access client establishes a connection through Callback, the call is disconnected and the client is called back. You can enable either of the following methods of the Callback Security feature.

You can allow the user to define the callback number.
An administrator can specify the callback number.

A few guidelines for setting Dial-in Properties of a user account are summarized below:

If you want to prevent the user from remotely accessing the network, set the remote access permission for the specific user account to the Deny Access option.
If you want to restrict your remote access clients to only certain network segments, configure static routes for the remote access client which specifies those network segments that they can access.
If you want to allow or deny remote access based on policies, select the Control Access Through Remote Access Policy option for the particular user account.
If you want to assign a particular IP addresses for each remote access connection attempt made by a particular user, specify the IP address in the Assign A Static IP Address field.
If you want dial-up connections to use a particular phone number, set the value of the Verify Caller ID field to the specific phone number.

Authentication Methods for Remote Access

There are a number of authentication methods supported by Routing and Remote Access Service (RRAS).

You configure the authentication protocols through the Routing and Remote Access Service (RRAS)

Click Start, Click Start, Administrative Tools, and then click Routing and Remote Access to open the Routing and Remote Access console.
In the console tree, select the server, and then click the Action menu to select the Properties command.
Switch to the Security tab.
Click the Authentication Methods button.
The Authentication Methods dialog box opens.

The different authentication methods on the Authentication Methods dialog box are:

Extensible Authentication Protocol (EAP): EAP is used for network and dialup authentication. It allows the Routing and Remote Access Service to use authentication protocols provided by Windows 2000 and Windows Server 2003 together with third-party authentication protocols and mechanisms such as smart cards .EAP offers mutual authentication, and provides for the negotiation of encryption methods. To secure the authentication process, the EAP authentication method utilizes Transport Layer Security (TLS). If you want to use the EAP authentication method, select the Extensible Authentication Protocol (EAP) checkbox, and then click the EAP Methods button to open the EAP Methods dialog box:
- Extensible Authentication Protocol-Message Digest 5 Challenge Handshake Authentication Protocol (EAP-MD5 CHAP)
- Extensible Authentication Protocol-Transport Level Security (EAP-TLS)
- Protected EAP (PEAP)
- EAP-RADIUS
Microsoft Encrypted Authentication Version 2 (MS-CHAPv2): MS-CHAPv2 provides mutual authentication and is used for network and dialup authentication. MS-CHAPv2 enables mutual authentication through the use of encrypted passwords. This is one of the more secure authentication methods to use to control remote access connections.
Microsoft Encrypted Authentication (MS-CHAP): MS-CHAP is the initial version of the Challenge Handshake Authentication Protocol (CHAP) protocol. With MS-CHAP, one-way authentication is utilized. Only one encryption key is used for sent messages and received messages. This makes MS-CHAP a weaker authentication method than MS-CHAPv2 – MS-CHAPv2 provides mutual authentication.
Encrypted Authentication (CHAP): CHAP is a challenge-response authentication protocol used for PPP connections. This authentication method utilizes the users' passwords for authentication. To use this authentication method, you have to use group policy and enable the Store Passwords Using Reversible Encryption password policy and then reset all users password so that it can be interpreted by CHAP.
Shiva Password Authentication Protocol (SPAP): SPAP uses a non-complicated password authentication protocol that offers no real authentication. SPAP is considered an insecure authentication protocol.
Unencrypted Password (PAP): PAP uses plain text passwords and no encryption. PAP is only provided as an authentication method for those clients that do not support any of the previously mentioned, more secure authentication methods.
Allow Remote Systems To Connect Without Authentication: This option allows remote access clients to connect to the remote access servers with no authentication.

From the above mentioned authentication methods, the following password based authentication methods are considered weak authentication method for securing remote access. It is recommended that you disable these authentication methods:

Password Authentication Protocol (PAP)
Shiva Password Authentication Protocol (SPAP)
Challenge Handshake Authentication Protocol (CHAP):
Microsoft Challenge Handshake Authentication Protocol Version 1 (MS-CHAPv1)

How to disable password based authentication methods

Click Start, Administrative Tools, and then click Routing and Remote Access to open the Routing and Remote Access console.
In the console tree, select the server, and then click the Action menu to select the Properties command.
Switch to the Security tab.
Click the Authentication Methods button.
The Authentication Methods dialog box opens.
Disable the checkbox for Microsoft Encrypted Authentication (MS-CHAP).
Disable the checkbox for Encrypted Authentication (CHAP).
Disable the checkbox for Shiva Password Authentication Protocol (SPAP)
Disable the checkbox for Unencrypted Password (PAP).
Click OK.

A few guidelines and recommendations for selecting authentication methods for your remote access solution are listed below:

SPAP should be used when Shiva Remote Access servers are being used for Network Access Servers (NASs). You cannot use SPAP if you require strong encryption methods for remote access connections. Both SPAP and PAP offer low levels of security.
PAP should only be used when none of the other authentication methods are supported by your remote access clients.
CHAP: CHAP provides a medium level of security for remote access connections. CHAP should be used when your remote access clients use Microsoft operating systems (OSs) and other OSs. Remember that CHAP requires passwords to be stored in reversible encrypted format on domain controllers.
MS-CHAP: MS-CHAP should be used when the following statements are true:
- Your remote access clients use Microsoft operating systems (OSs).
- You do want to store passwords in reversible encrypted format on domain controllers.
- Data needs to be encrypted between the remote access client and the Network Access Server (NAS).
MS-CHAPv2: MS-CHAPv2 provides a high level of protection for remote access connections, and should be used when the following statements are true:
- Mutual authentication is required for the remote access client and the Network Access Server (NAS).
- Data needs to be encrypted between the remote access client and the Network Access Server (NAS).
- Windows 95 clients and Windows 98 clients are only being utilized for VPN authentication.
- Windows NT 4.0 clients and Windows 2000 clients are utilized for dial-up authentication and VPN authentication.
EAP-TLS: EAP-TLS also provides a high level of protection for remote access connections, and should be used when the following statements are true:
- Mutual authentication is required for the remote access client and the Network Access Server (NAS).
- Data needs to be encrypted between the remote access client and the Network Access Server (NAS).
- Operating systems that support third-party authentication mechanisms, such as smart cards, are being used.

Using Remote Access Policies to Secure Remote Access

Remote access policies can be created to control whether or not the user is allowed to connect to the remote access server. Remote access policies contain conditions which you specify through the Routing and Remote Access management console. These conditions determine which users are allowed to connect to the remote access server.

Remote access policies can be used to:

Specify which authentication protocol clients must utilize.
Specify which encryption methods clients must utilize.
Restrict user access, based on the following:
- User
- Group membership
- Time of day
The Grant or Deny setting of a specific policy determines whether the user is allowed or denied access.

When a user attempts to establish a connection, the remote access policies are evaluated to determine whether the user is permitted to access the remote access server. The user is only allowed access once all the conditions in the remote access policy allow access. When more than one remote access policy is configured, you can define the order in which they are to be applied. You do this by specifying the order number or priority of each remote access policy.

A few conditions that remote access policies can compel clients to meet are listed below:

Authentication type; indicates which authentication protocols clients must utilize.
Framed protocol; indicates the data-link layer protocol which clients have to utilize.
Day and time restrictions; indicates which day of the week and the time of the day that the user can connect.
Tunnel type; for VPN clients, it defines the data-link layer protocol that these clients must utilize.
Windows groups; indicates which groups users have to be a member of if they want to connect to the remote access server.

The different attribute types that can be evaluated in a remote access policy are:

Authentication Type; the authentication type, for instance PAP or CHAP.
Called Station ID; the network access server's (NAS) phone number.
Calling Station ID; the phone number used by the caller.
Client-Friendly Name; the name of the RADIUS client requiring authentication.
Client IP Address; the IP address of the RADIUS client.
Client Vendor; the network access server's (NAS) vendor.
Day and Time Restrictions; specifies when a connection can be established.
Framed Protocol; IAS uses this to determine the frame type of the incoming packets.
MS RAS Vendor; the RADIUS client machine's vendor.
NAS Identifier; the network access server's (NAS) name.
NAS IP Address; IP address of the NAS.
NAS Port Type; the media used by the client.
Service Type; the type of service requested.
Tunnel Type; the type of tunnel (PPTP, L2TP) that should be used.
Windows Groups; the groups to which are allowed access to the remote access server.

You can also use remote access policies configure further restrictions once the connection attempt is authorized by the RRAS. Connections can be restricted through remote access policies, based on the following elements:

Idle timeout time
Maximum session time
Encryption strength
IP packet filters
Advanced restrictions – IP addresses for PPP connections

How the Routing and Remote Access Service (RRAS) applies remote access polices when multiple policies are configured
You can define the order in which remote access policies should be applied to connections through the Routing and Remote Access management console. You simply have to select the remote access policy in the details pane and click the Action menu and then click either the Move Up command or the Move Down command.

The order that the Routing and Remote Access Service (RRAS) applies remote access policies is illustrated below:

The Routing and Remote Access Service (RRAS) evaluates the connection attempt to the very first remote access policy. The connection is rejected if there are no configured remote access policies in the list.
If the connection does not meet each condition specified in the initial remote access policy, then the Routing and Remote Access Service (RRAS) proceeds to check the connection against the second remote access policy specified in the list.
If the connection does not meet all of the conditions of any of the remote access policies, the attempted connection is rejected.
If the Ignore-User-Dialin-Properties attribute has a value of False, the Routing and Remote Access Service (RRAS) proceeds to check what the remote access permission setting for the specific user account is.
1. If the Deny Access option is configured for the user account, the attempted connection is rejected.
2. If the Allow Access option is configured, the user account and profile properties are applied to the connection. If the user account and profile properties match the connection attempt, the connection is allowed. If it does not match, RRAS rejects the attempted connection.
3. If the Control Access Through Remote Access Policy option is configured, the remote access permission setting of the policy is checked. If Allow Access is specified, RRAS checks whether the user account and profile properties match the connection attempt. If so the connection is allowed. If not, the connection is rejected.
If the Ignore-User-Dialin-Properties attribute has a value of True, the Routing and Remote Access Service (RRAS) proceeds to check what the remote access permission setting of the policy indicates:
1. If the Allow Access is specified, RRAS checks whether the user account and profile properties match the connection attempt. If so the connection is allowed. If not, the connection is rejected.
2. If Deny Access is specified, the attempted connection is rejected.

A few recommendations for implementing remote access policies are discussed next:

Because all conditions in a remote access policy have to be matched for a remote access connection attempt to be allowed, it is wise to not configure a large number of conditions for each remote access policy.
Ensure that the correct condition is applied to each remote access policy. You should not include a remote access policy condition that cannot be matched or met.
Specify the correct order in which the Routing and Remote Access Service (RRAS) must process the remote access policies. Remote access policies that have more precise exact conditions should be applied to connections before remote access policies that include more general conditions are applied.
Remember that if no remote access policies are defined in the list, then all remote access attempts will simply be denied. A remote access policy that allows remote access connections 24 hours a day is enabled by default.

Using Policy Profiles for Remote Access Connections

Remote access profiles are an important component of remote access policies. Remote access profiles determines what happens after the connection is authorized by RRAS. Each remote access profile contains a set of properties, which are applied to connections that match the conditions specified in the remote access policy.
You can create a remote access profile for a remote access policy either when you create the actual remote access policy, or at some later date. You create a profile by accessing the Properties dialog box of the specific remote access policy, and then clicking the Edit Profile button. The profile Properties dialog box contains the following six tabs: Dial-In Constraints tab, IP tab, Multilink tab, Authentication tab, Encryption tab and Advanced tab.

A remote access profile is made up of the following sets of properties, which can be configured through the profile's Properties dialog box:

Dial-in constraints: Dial-in constraints are used to specify the following:
- The number of minutes that the server can stay idle, prior to it disconnecting.
- The maximum time that a connection is connected.
- The time when connections are allowed.
- Specify, based on media type, which connections should be rejected.
Authentication properties: Authentication properties allow you to set the following:
- Specify which authentication methods are allowed for connections.
- Specify whether users are allowed to modify expired passwords through MS-CHAP and MS-CHAP v2.
Encryption properties: Encryption properties allow you to set the following:
- Specify which encryption strength should be used: Basic Encryption, Strong Encryption or Strongest Encryption.
IP properties: The IP properties allow you to configure the following:
- Specify that the remote access client requests an IP address.
- Specify that the remote access server provide an IP address.
- Specify that static IP addresses be used.
- Specify that the remote access server determines how IP addresses are assigned.
Multilink properties: Multilink properties allow you to configure the following:
- Enable multilink.
- Set the number of ports a multilink connection is allowed to utilize.
Advanced properties: Advanced properties allow you to set the following:
- Specify the RADIUS attributes that are returned by the IAS server to the RADIUS client.

A few guidelines for implementing remote access profiles are summarized below:

If you want to restrict remote access connections to a certain phone number only, then you have to configure dial-in constraints to restrict connections to this phone number.
If you want to ensure that idle remote access connections are not utilizing your available remote access ports, then you have to configure dial-in constraints to disconnect idle connections once a predefined time elapses.
If you want clients to use a particular authentication protocol, configure a remote access profile to only accept connections that are using this specific authentication protocol. Remember that if you do this, then all connections which are not utilizing the specified authentication protocol will be rejected.
If you want clients to only use a specific encryption strength, then configure a remote access profile to allow only this specific encryption strength.
If you want to restrict remote access connections to only certain protocols, configure IP packet filters to only allow these protocols.
If you want to restrict remote access connections to only a specific computer(s), configure IP packet filters that restrict access to only these specific IP addresses.