Security information for routing

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

Security information for routing

Before you enable the routing 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 router, you should also consider security for your remote access solution. For more information, see Security information for remote access.

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 routing 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 within the Microsoft Management Console (MMC). Similarly, you must be a member of the Administrators group to run most of the netsh routing 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, you should 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.

• Which routing components your network requires. You should document how your network is designed, what routing components it requires, and how those components are configured. This information can help you maintain your network and identify potential areas requiring special concern or improvement.

• Whether you can simplify your network topology. Simpler networks are easier to maintain, and they provide fewer attack points. Simplifying your network might include:

  • Minimizing the number of network interfaces. Although most servers running Routing and Remote Access are multihomed computers, you should configure as few network interfaces as possible. If possible, you should not configure the server running Routing and Remote Access with more than one public interface. For more information, see Network interfaces.

  • Minimizing the number of routes. You should use as few demand-dial and static routes as possible. For more information, see Demand-dial routing and Static routing design considerations.

  • Minimizing the number of routing protocols in use. You should track what routing protocols are enabled and how they are configured, and then you should configure and enable as few routing protocols as possible. For example, unless your network requires AppleTalk, you should not enable AppleTalk routing on the server running Routing and Remote Access.

• Which tunneling protocols to use. If you are configuring a router-to-router virtual private network (VPN), you should consider using Layer Two Tunneling Protocol (L2TP) instead of Point-to-Point Tunneling Protocol (PPTP). For more information, see VPN Router-to-Router tunneling protocols and Security information for remote access.

• Whether to use packet filters, firewalls, and other network traffic protection. You should restrict routing network traffic to the minimum level that your network requires. You should also consider using IP filters in your default remote access policy to ensure that inbound network traffic comes from authorized remote access clients.

  • In Routing and Remote Access, you can configure static packet filters on network interfaces and enable Basic Firewall on public interfaces. You can use these security features alone or in conjunction with other software, such as Internet Authentication Service (IAS). For more information, see Basic Firewall, Packet filtering, and Internet Authentication Service.

  • You cannot configure Routing and Remote Access if Internet Connection Firewall (ICF) or Windows Firewall is enabled. Before you configure Routing and Remote Access, you must disable Internet Connection Firewall or Windows Firewall. For more information about Windows Firewall, see Help: Windows Firewall.

• What level of logging to use. You should consider how much information you want to log for each routing protocol. Routing and Remote Access has several logging options. Additionally, you can use features in IAS for more detail and centralized accounting and auditing. For more information, see Logging and Internet Authentication Service.