Securing Remote Access Servers

To implement security for remote access servers, you must consider the configuration of servers running RRAS, servers running IAS, and servers running ISA Server. The combination of these servers and services provides the required security for remote access dial-up and VPN connection. Specifically, when designing security for remote access servers, consider taking the following measures:

Implement RADIUS authentication and accounting.
Secure RADIUS authentication traffic between the remote access server and the RADIUS server.
Configure a remote access policy.
If using L2TP/IPSec, deploy required certificates.
Restrict which servers can start or stop RRAS.
Implement remote access account lockout.

Implementing RADIUS Authentication and Accounting

RADIUS authentication and accounting allow for centralized authentication, authorization, and accounting for remote access connectivity. Rather than authentication and authorization being performed at individual remote access servers, connection request messages are sent to the RADIUS server, which is a server running IAS in a Windows 2000 network.

The RADIUS packets are sent to specific ports on the IAS server. Authentication packets are sent to User Datagram Protocol (UDP) port 1812, and the accounting packets are sent to UDP port 1813. The format of the RADIUS packets allows for NAT traversal. This permits you to place the IAS server on the private network behind firewalls, rather than in your network s perimeter network (also known as DMZ, demilitarized zone, or screened subnet). Therefore, the IAS server can connect directly to a domain controller to validate a user s provided credentials and access the user s account properties.

The IAS server then validates the authentication attempt against Active Directory. If the credentials sent to the RADIUS server match the credentials in Active Directory, the authentication succeeds and the RADIUS server tells the remote access server to authenticate the user.

In addition to providing centralized authentication and accounting, IAS provides centralized remote access policy for remote access connection authorization. Rather than having to configure a remote access policy at each remote access server, the remote access policy is configured at the IAS server. The RADIUS clients implicitly trust the answer they receive from the IAS server when a RADIUS connection request response is received. By implementing the remote access policy at a single location, you ensure that the same conditions and policy configuration are applied to each remote access client, no matter which remote access server sends the connection request.

Securing RADIUS Authentication Traffic Between the Remote Access Server and the RADIUS Server

Technicians have raised concerns that RADIUS traffic between the remote access server and the RADIUS server is susceptible to inspection and brute force attacks. To protect against these attacks, you can implement an IPSec policy that requires ESP encryption of RADIUS traffic. This ensures that RADIUS traffic is protected against inspection and brute force attacks. You must ensure that the remote access server and the IAS server are not separated by a NAT device to ensure that IPSec traffic can be transmitted between the two servers.

Configuring a Remote Access Policy

To authorize remote access connections, you must define remote access policy. The remote access policy must be defined at each remote access server (when using Windows authentication) or at the configured IAS server (when using RADIUS authentication). The remote access policy must enforce the company s security policy for remote access connections. Remote connections are secured by configuring conditions and profiles for each remote access policy.

Remote Access Policy Conditions

All remote access connections are evaluated against conditions defined for each remote access policy. If a remote access connection matches these conditions, the connection attempt is either allowed or denied based on the first matching remote access policy (its remote access permissions and profile settings) and the dial-in properties of the user s account.

You can use the following condition attributes to identify a remote access connection attempt:

Called-Station-ID
The phone number dialed by the remote access client. This condition allows you to apply different remote access policies depending on the phone number the remote client uses.
Calling-Station-ID
The phone number from which the call originates. This condition allows you to apply remote access policies depending on which phone number originates the connection.
Client-Friendly-Name
The name of the RADIUS client that forwards the authentication request. This condition allows you to apply differing remote access policies based on the RADIUS client that forwards the request. This condition can be implemented only in a remote access policy defined at an IAS server.
Client-IP-Address
The IP address of the RADIUS client that sent the authentication request. This condition is used to identify RADIUS clients for VPN authentication requests. This condition can be implemented only in a remote access policy defined at an IAS server.
Client-Vendor
Identifies the manufacturer of the RADIUS client that forwards the authentication request. This condition allows you to apply manufacturer-specific remote access policies. This condition can be implemented only in a remote access policy defined at an IAS server.
Day And Time Restrictions
Allows you to restrict connections to specific days of the week or times of day. For example, you can prevent remote connections from being made outside office hours.
Framed Protocol
Allows you to define which remote access protocols are allowed for connections. For example, you can restrict connections to only Point-to-Point Protocol (PPP) connections, while preventing Serial Line Internet Protocol (SLIP) connections that transmit all data in plaintext.

Although a Windows 2000 server running RRAS cannot accept SLIP connections, an IAS server can authenticate dial-in requests to a non-Microsoft remote access server.
NAS-Identifier
Allows you to identify the RADIUS client that forwards the request by comparing the string sent by the RADIUS client to a string defined in the remote access policy.
NAS-IP-Address
Allows you to identify the RADIUS client by its IP address. This is useful if you want to apply different remote access policies to a specific VPN server, based on its IP address.
NAS-Port-Type
Allows you to identify the medium used by the remote access client. You can indicate dial-up, ISDN, or VPN connections. For wireless communications, you can choose 802.11b connections.
Service-Type
Allows you to identify the service requested by the client. For remote access clients, the type of service typically is Framed.
Tunnel-Type
Allows you to restrict which protocol a client uses for a VPN connection. You can specify PPTP or L2TP, subject to the existing network infrastructure.
Windows-Groups
Allows you to restrict access by Windows 2000 group membership. You can select only Windows 2000 universal groups or global groups.

Remote Access Policy Profiles

Remote access policy allows you to apply additional security that extends beyond condition matching. Once a remote connection attempt matches the conditions of a defined remote access policy, the remote access policy profile is applied to the connection. The remote access policy profile defines what security settings must be implemented by the remote access connections. These profile settings include the following:

Dial-In Constraints
Include how long a connection can remain idle before it is disconnected, the maximum time for session lengths, the day and time limitations, the dial-in number constraints, and the dial-in media constraints. Typically, the dial-in constraints ensure that remote access sessions are terminated if left idle for long periods of time and that they take place only during specific times of the day or week.
IP Constraints
Allow you to define packet filters that restrict access to the network for the remote access client. These packet filters can limit which protocols can be used by remote access clients.
Multilink
Define whether multilink sessions are allowed and where a client can make multiple remote access connections to the remote access server, thus effectively increasing available bandwidth.
Authentication
Allow you to define which protocols are allowed for a remote access connection. If the remote client is not configured to use the required authentication protocol(s), the connection attempt is terminated.
Encryption
Allow you to define what type of encryption must be applied to the remote access session. You can choose to require no encryption, basic encryption (56-bit keys for DES and 40-bit keys for MPPE), strong encryption (56-bit keys for DES or MPPE), or the strongest encryption (3DES or 128-bit MPPE).
Advanced
Allow you to define advanced RADIUS attributes that are used when remote access connections are using RADIUS authentication.

Deploying Required Certificates for L2TP/IPSec

If you are implementing L2TP/IPSec for VPN connections to the corporate network, you must deploy the necessary certificates to your network s computers and users. Computer certificates are required for IPSec authentication, and User certificates are required for EAP-TLS authentication.

IPSec Certificate Deployment

Computer certificates are required for the authentication of the remote client computer with the remote access server. Computer certificates authenticate the IPSec main mode SA established between the VPN client and the VPN server. The certificate used by the VPN client must chain to a Certification Authority (CA) located in the trusted root store of the VPN server. The certificate used by the VPN server must chain to a CA located in the trusted root store of the VPN client. Although it is possible for the VPN client and server to use certificates from different chains, it is easiest to issue certificates to both the client and the server from CAs in the same chain.

To deploy certificates automatically, you can implement a Windows 2000 enterprise CA that publishes the IPSec or Computer certificate template (for client computers or domain controllers). If an enterprise CA is deployed, you can automatically send the computer certificates to the remote access client computers by using the Automatic Certificate Request Settings Group Policy setting. This setting automatically deploys the defined computer-based certificates to the computer accounts against which the Group Policy object (GPO) is applied.

If you must deploy certificates to nondomain members, you must publish the IPSec (Offline Request) certificate template at the enterprise CA. This template allows nondomain members to enroll the certificate template by using Web-based certificate enrollment. The nondomain members must provide credentials that are assigned the Read and Enroll permissions for the IPSec (Offline Request) certificate template.

Alternatively, if the user is a local administrator, the IPSec certificate can be deployed by using the Certificates Microsoft Management Console (MMC) focused on the local machine or by using the Certificate Web-based enrollment pages.

Although it is possible to use shared secrets for L2TP/IPSec computer authentication, it is not recommended because doing so weakens remote access computer security. Always use certificate-based authentication for L2TP/IPSec computer authentication. Kerberos authentication for L2TP/IPSec computer authentication is not possible.

User Authentication Certificates

If your remote access solution uses EAP-TLS authentication, regardless of whether you are using dial-up connections, PPTP connections, or L2TP/IPSec connections, you must deploy user authentication certificates to the remote access user and server authentication certificates to either the remote access server or the IAS server. If you are using Windows authentication, the server authentication certificate (either a Computer certificate or a Domain Controller certificate) must be installed on the remote access server. If you are using RADIUS authentication, the server authentication certificate must be installed on the IAS server. These two certificate deployment scenarios are shown in Figure 19-1.

figure 19-1 the deployment of user authentication certificates, which varies depending on whether you implement radius authentication

Figure 19-1. The deployment of user authentication certificates, which varies depending on whether you implement RADIUS authentication

The remote access client will require either a Smart Card Logon certificate, which is recommended, or a User certificate that is stored in the user s certificate store. This proves the user s identify for the remote access connection.

Restricting Which Servers Can Run RRAS

To prevent unauthorized connections to the network, not only must you implement remote access policy to define the allowed remote access connections, you also must prevent users from running unauthorized remote access servers. You can accomplish this by ensuring that all servers and computers in the domain are members of the local domain or forest you are running in your company. If the computers are members of the domain, you can utilize Group Policy to ensure that only authorized remote access servers can start RRAS. The start state of any Windows 2000 service is defined in the following Group Policy location: Computer Configuration\Windows Settings\Security Settings\System Services. For each service listed in the details pane, you can define the default start state of the service as well as permissions defining which users or security groups can start, pause, or stop the service.

To ensure that only approved remote access servers can start RRAS, verify that all approved remote access servers are placed in a common OU or OU structure in which a GPO is linked. The GPO should set RRAS as an automatic startup mode and allow only Administrators or the System account to change the startup mode for the service.

For all other computers, configure the default domain policy to disable RRAS. To prevent RRAS from ever being started, do not assign any security groups other than the System account and local Administrators group the permission to start, stop, or pause the service.

Implementing Remote Access Account Lockout

To prevent online dictionary attacks against a user s password, you can enable remote access account lockout, which denies remote access to user accounts but does not lock out user accounts for local network activities. If attackers attempt an online dictionary attack, the account is blocked from further remote access attempts when the remote access account lockout threshold is reached.

You activate remote access account lockout by enabling two registry entries at the server that performs remote access authentication. If using Windows authentication, the registry settings are defined at each remote access server. If using RADIUS authentication, the registry settings must be defined at the IAS server.

These are the registry settings that enable remote access account lockout:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \RemoteAccess\Parameters\AccountLockout\MaxDenials
Must be set to the required maximum attempts before remote access is prevented. If the counter exceeds the configured value, remote access is prevented for the account, until the reset time. A successful authentication resets a failed attempt s counter for each account.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \RemoteAccess\Parameters\AccountLockout\ResetTime
Defines the interval, in minutes, when the failed attempts counter is reset to 0. The default for this value is 2880 minutes (48 hours).