14.2 Controlling Access

     

The best way to make remote access more secure is to strictly control who is allowed to access your network remotely, either via virtual private networks (VPNs) or dial-up connections. Instead of allowing all company users to dial in, restrict the service to employees who actually need it. If an employee is going on a business trip, enable dial-up access for his account; when he returns from the trip, remove his dial-up authorization. While the cost of managing this user may be relatively high, the practice of carefully limiting remote access usually provides greatly enhanced security.

Windows Server 2003 uses remote access policies to determine who is and who is not allowed to access a remote access server. Windows Server 2003 can use Remote Authentication for Dial-in User Services (RADIUS) to provide centralized remote access policies for a group of remote access servers and to allow Windows Server 2003's remote access policies to manage non-Windows dial-up gateways.

14.2.1 Remote Access Policies

Windows Server 2003 uses remote access policies to determine whether it will accept incoming remote access connections. Remote access policies can apply to a number of different connection types, including VPN, dial-up, and wireless. Windows Server 2003 provides the Routing and Remote Access Microsoft Management Console (MMC) snap-in, shown in Figure 14-1, which allows you to manage remote access policies and all configuration for Routing and Remote Access (also known as remote access services, or RAS).

Figure 14-1. Managing remote access policies with the Routing and Remote Access snap-in

When a user attempts to connect to Routing and Remote Access, the service evaluates the remote access policies in the order that they're listed in the snap-in. Each policy specifies conditions, such as user groups, connection types, time of day, and so forth, which the server attempts to match to the requested connection. If the server finds a policy with conditions that match the requested connection, it uses the policy's Allow or Disallow state to permit or deny the connection. If the server is unable to match a policy to the conditions of the connection, the connection is denied .

For example, suppose you create a policy that applies to dial-up connections made between the hours of 6 p.m. and 6 a.m. and mark that policy to allow connections. Any authenticated user attempting to dial in to the server during those hours will be permitted. You can also have policies check for group membership or examine the user's Active Directory account to see if dial-up permissions have been granted to the account.

14.2.1.1 Written remote access security policies

The technology-based solution to remote access policy is described in detail throughout this chapter. However, these policies must be examined and documented before they can be implemented with the steps I provide. This documentation is in the form of a written remote access policy.

Chapter 15 provides guidelines and processes for creating written security policy for your organization. A number of considerations for these policies are specific to remote access, including:

Login hours

Do you want to allow your users to connect via remote access at all hours? If policy requires users to work from the office during normal working hours, RAS can be disabled during those hours. This blocks attackers during a significant portion of the day as well as conserves resources on the remote access servers. Bandwidth consumption is also minimized during the important working hours if VPN support is disabled at that time.

Restricted use of remote access

Do all employees need the ability to dial in? Most corporations require written authorization from management to enable a user to connect via remote access. Restricting use of remote access improves security by minimizing the number of authorized RAS credentials. This restriction also makes the best use of limited resources by stopping unauthorized users from consuming corporate bandwidth.

Temporary remote access

If a user needs temporary remote access (for example, a normally office bound employee makes an extended business trip), ensure the authorization is revoked after an approved time period. This should be considered part of the authorization process.

Minimum security for connection

If your users frequently access sensitive data across RAS, you should ensure the connection is as secure as possible. This includes encrypting network traffic between the client and RAS server.

Security for remote computer

Internet viruses and worms often make successful attacks against unprotected home computers. If those computers are then allowed to connect to your corporate network, the viruses and worms can quickly spread to internal computers. This effectively bypasses normal firewalls and other protection devices, as the RAS connection is trusted. Many corporations now require that all computers connecting via RAS run current antivirus and firewall software. This is not a foolproof solution, but it does reduce the likelihood that a home or mobile user will infect the corporate network.

An emerging RAS technology group called Network Quarantine generically allows administrators to isolate computers connecting via RAS (and often via LAN) and perform some security checks before exposing those computers to the rest of the network. At the time of this writing, Microsoft does not yet have a quarantine product and has not officially announced a date for its availability.

Allowing users to connect via RAS increases the need for defense- in-depth protection of your network resources. Because viruses and worms can lay dormant on remote computers for extended periods before attacking resources, a user could easily transport malicious code into the network. If there is insufficient protection within the network (e.g., each server running virus-scanning software, layers of firewalls, etc.), this malicious code could run amok.

14.2.2 RADIUS and IAS

Normally, remote access policies apply only to the Windows Server 2003 system on which they are configured. If you have multiple servers acting as remote access gateways, or if you have non-Windows remote access gateways, remote access policy management can become cumbersome. Fortunately, Windows Server 2003 provides a solution.

Rather than using its own remote access policies, Windows Server 2003 can be configured to use a centralized RADIUS server. RADIUS is an industry-standard protocol that remote access gateways use to communicate with a central authorization server on your network. The central server uses its own configuration to instruct the gateways to accept or decline incoming connections. Figure 14-2 shows the properties of Routing and Remote Access configured to use a RADIUS server rather than the server's own remote access policies. This was accessed by right-clicking on the server name (in this case, IRIDIS5A) in the Routing and Remote Access MMC snap-in and then clicking Properties.

Figure 14-2. Configuring Routing and Remote Access to use a RADIUS server for authentication

Windows Server 2003 also includes its own RADIUS-compatible server, called Internet Authentication Service (IAS). IAS is designed to run on Windows Server 2003 and use that server's local remote access policies to authenticate users for other RADIUS-compatible remote access gateways. Since most remote access gateways are RADIUS-compatible (including those produced by Shiva, Cisco, Nortel, and others), you can use IAS to enforce Windows Server 2003 remote access policies on those other gateways.

You can also use IAS to centralize policy management if you use only Windows Server 2003 and Routing and Remote Access to provide remote access services to your users. Simply install IAS on one remote access server and configure remote access policies on that server. Configure the other remote access servers to use RADIUS for authentication, and configure their RADIUS settings to use the server on which IAS is installed.

Using IAS and RADIUS to centralize remote access authentication management provides more consistent and reliable security than configuring individual policies on a number of remote access gateway servers or devices.

Authentication and Accounting

Most RADIUS servers, including IAS, can provide accounting functionality in addition to their authorization capabilities. Accounting creates detailed log files of remote user access, including logon times and session information. Many organizations use these logs to charge each company department for their remote access usage or to plan for remote access capacity. You can also audit these logs on a periodic basis to check for unauthorized access attempts, overlong sessions from users who normally aren't online for very long, and so forth.

In an especially large remote access environment, the tasks of authorization and accounting might be more than one RADIUS server can handle. Accounting in particular can be very resource intensive , since every remote access connection constantly generates a stream of status messages. For this reason, most RADIUS clients ”including Routing and Remote Access ”can be configured to use one RADIUS server for authorization and another for accounting, effectively dividing the load and creating a more scalable solution.