Compartir a través de

Security information for remote access

  • Artículo

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

Security information for remote access

Before you enable the remote access functions of Routing and Remote Access, you should carefully review your network infrastructure so that you can configure Routing and Remote Access to best meet your needs for security and functionality. Security for Routing and Remote Access can be considered in three parts: securing the server running Routing and Remote Access, securing the network traffic between the server and its clients, and using secure authentication methods.

Unless your server running Routing and Remote Access is functioning only as a remote access server, you should also consider security for your routing implementation. For more information, see Security information for routing.

In addition to understanding the security implications of enabling Routing and Remote Access on your network, you should also practice general server security, as described in Security. For example, you should use only servers that are running Microsoft® Windows® 2000 or a member of the Microsoft Windows Server 2003 family, if possible. You will decrease your network security if you use servers that are running Routing and Remote Access on the same network as servers that are running Microsoft Windows NT 4.0 and either Remote Access Service (RAS) or Routing and Remote Access Service (RRAS). For more information, see Domain and forest functionality and Member server in a domain.

Before you configure and enable the remote access features of Routing and Remote Access, you should consider the following:

  • Who can enable, configure, and disable Routing and Remote Access. You must be a member of the Administrators group to use the Routing and Remote Access snap-in, either on its own or as part of the Microsoft Management Console (MMC). Similarly, you must be a member of the Administrators group to run most of the netsh ras commands from the command line. You should restrict the membership of the Administrators group to the minimum number of users necessary to administer the server. For more information, see Default local groups and Default groups.

  • How to open Routing and Remote Access. As a security best practice, consider using the runas command to open Routing and Remote Access rather than logging on with administrative credentials. For more information about why you might not want to log on with administrative credentials, see Why you should not run your computer as an administrator. To open Routing and Remote Access when you are not logged on as a member of the Administrators group, type the following at the command prompt:

    runas /user:[Domain/]UserName**"mmc %windir%\system32\rrasmgmt.msc"**

    The user name that you provide must correspond to the Administrator account or an account that is a member of the Administrators group, and you must provide the password for the account when prompted. For more information, see Runas.

  • What client operating systems to support for remote access. You should consider requiring your remote users to run particular operating systems (such as Microsoft Windows XP, Windows 2000, and members of the Windows Server 2003 family). There are two reasons to consider requiring your users to run particular operating systems. First, not all operating systems have equal levels of security in their file systems and in their user accounting. Second, not all remote access features are available on all operating systems. For more information, see Dial-up networking clients and Virtual private networking clients. Based on what client operating systems you support, you should also consider:

    • What authentication methods to support. You should consider requiring your remote users to be authenticated with more secure authentication protocols, such as Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) or Extensible Authentication Protocol (EAP), rather than allowing your remote users to use protocols such as Password Authentication Protocol (PAP), Shiva Password Authentication Protocol (SPAP), and Challenge Handshake Authentication Protocol (CHAP). For more information, see Remote Access Authentication Methods.

    • What level of data encryption to support. You should consider requiring your remote users to encrypt data with the highest level of data encryption possible. Windows XP and the Windows Server 2003 family support 128-bit encryption keys. For more information, see Remote Access Data encryption.

  • Whether to require strong passwords. You should consider requiring your remote users to provide passwords that contain a certain number of characters and that contain a combination of uppercase letters, lowercase letters, numerals, and special characters. One of the worst vulnerabilities for a remote access solution is the use of weak or easily guessable passwords by remote users. For more information, see Strong passwords and Passwords must meet complexity requirements.

  • Whether to provide users with a managed client. You should consider increasing the security of your remote access solution by using the Connection Manager Administration Kit (CMAK) wizard to create a customized connection for your users. By customizing the connection, you can control how your users connect to your network, and you can also simplify troubleshooting. For more information, see Connection Manager Administration Kit.

  • How to document your remote access solution. You should consider documenting your remote access needs and how your network is configured to meet them. This can help you maintain your network and identify potential areas for concern or improvement. For more information, see Dial-up remote access design considerations and Remote access VPN design considerations.

  • Whether to use Windows Authentication or RADIUS. If you have more than one server running Routing and Remote Access, you should consider using Remote Authentication Dial-In User Service (RADIUS) instead of Windows Authentication. By using RADIUS, you can centralize authentication, authorization, and auditing of remote access connections, and you can more easily manage your remote access policies. If you use RADIUS, you should consider encrypting your RADIUS traffic with Internet Protocol security (IPSec). For more information, see Remote Access Authentication, Using RADIUS, and Internet Authentication Service.

  • Whether to restrict remote access. You should consider restricting remote access to your network to certain users, user groups, times, or client configurations by configuring remote access policies. You can implement remote access policies that restrict remote access to only those users or groups who require it and who meet the security standard for your network. For more information, see Remote Access Policies.