The following table lists the policy settings that are relevant to the NPS role service. Use these policy settings to enforce the appropriate security configuration in your solution. Configure the policy settings in the following table as a remote access policy on the server computers that run the NPS role service.
Table 10.3 NPS Role Service Remote Access Policy
Policy object
|
Description
|
Ignore-User-Dialin-Properties
|
Ignore any of the dial-in related properties of a user or group account.
|
More Information
The following resources on Microsoft.com can provide you with additional best practice information about how to harden server computers that run the NPS role service role:
Extensible Authentication Protocol.
IPsec overview.
Network Policy Server.
Network Policy Server Infrastructure.
Protected Extensible Authentication Protocol (PEAP).
"RADIUS Extensions": RFC 2869.
Server and Domain Isolation.
Shared secrets.
Routing and Remote Access Role Service
With Routing and Remote Access, you can deploy VPN and dial-up remote access services and multiprotocol LAN-to-LAN, LAN-to-WAN, VPN, and network address translation (NAT) routing services. The Routing and Remote Access role service comprises the following subelement role services:
Each subelement role service is discussed in its own respective section.
For more information about the Routing and Remote Access role service, see:
Routing and Remote Access.
Routing and Remote Access Blog.
Remote Access Service Role Service
The Remote Access Service role service is a subelement of the Routing and Remote Access role service. The Remote Access Service role service is responsible for providing dial-up and VPN remote access services. Although many of the recommendations presented here are applicable to dial-up remote access services, this guide focuses on hardening server computers that provide VPN remote access services.
Server computers that run this role service are used as NAS devices (RADIUS clients) and should be configured to use the authentication and auditing services provided by NPS. For more information about hardening server computers running the NPS role service, see the "NPS Role Service" section earlier in this chapter.
For more information about the Remote Access Service role service, see:
Routing and Remote Access.
Routing and Remote Access Blog.
Attack Surface
The Remote Access Service role service is susceptible to security attacks that are typical of edge-of-network services, but specifically to any VPN services, such as VPN fingerprinting, user name guessing, offline password cracking, man-in-the-middle attacks, and so on. To identify the attack surface for this role service, you need to identify the following factors:
Installed files. The files are installed as part of the Remote Access Service role service.
Running services. The services that run as part of the Remote Access Service role service.
Note You can use the RootkitRevealer and Sigcheck utilities that are part of Windows Sysinternals to verify the integrity of the installed files and the files that the services run.
Firewall rules. The Windows Firewall rules that the Remote Access Service role service uses.
Note Some of the Windows Firewall rules that the Remote Access Service role service uses are disabled until you run the Configure and Enable Routing and Remote Access wizard. For more information about how to run this wizard, see "Install and Enable the Routing and Remote Access Service" in the Windows Server 2008 Help and Support
Role dependencies. The dependencies for the Remote Access Service role service.
The details of the attack surface for the Remote Access Service role service are included in the Windows Server 2008 Attack Surface Reference workbook that accompanies this Solution Accelerator. To view the attack surface for this role service, on the NPAS tab of the workbook, view the sections that correspond to each of the items in the previous list.
Security Measures
This section describes the security measures that you can incorporate into your Remote Access Service role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Remote Access Service role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included.
Configuration Checklist
The following table lists the recommended security configuration tasks for hardening servers that perform the Remote Access Service role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.
Table 10.4 Configuration Checklist
|
Configuration tasks
|
|
Protect computers that run the Remote Access Service.
|
|
Configure the firewall rules on intermediary firewalls.
|
|
Make computers that run the Remote Access Service members of an extranet forest.
|
|
Use IPsec to secure communication between the Remote Access Service and NPS.
|
|
Protect RADIUS shared secrets.
|
|
Require multifactor authentication for remote users.
|
|
Limit users who can remotely access your intranet.
|
|
Use the PEAP or EAP-TLS authentication protocol to authenticate remote access users and client computers.
|
|
Secure remote access client communication.
|
|
Use NPS to provide centralized user authentication.
|
Protect Computers That Run the Remote Access Service
The server computer that runs the Remote Access Service role service needs to communicate with remote access client computers through the Internet. Typically, the computers that run the Remote Access Service role service are immediately behind the outward-facing firewalls that provide Internet ingress and egress.
The computers that run the Remote Access Service role service communicate with the computers that run the NPS role service. Because the NPS server communicates directly with AD DS, place the server computers that run the NPS role service in protected networks, such as your intranet, a secured extranet, or a secured perimeter network.
Configure the Firewall Rules on Intermediary Firewalls
The computers that run the Remote Access Service role service are typically placed in your extranet or perimeter network. The computers that run the NPS role service are typically placed in protected networks with one or more firewalls between the computers that run the Remote Access Service and NPS role services.
Configure the firewall rules on the intermediary firewalls to allow the appropriate kind of traffic. For more information about the types of traffic to allow, see the sections "Restrict Traffic Based on the Services Offered" and "Prohibit Legacy RADIUS Requests" earlier in this chapter.
The computers that run the Remote Access Service role service are typically placed in environments that are less secure than the one in which the computer that runs the NPS role service resides, such as a perimeter network or extranet. Many extranets have an AD DS forest (an extranet forest) that manages the credentials used by services that run on computers in the extranet.
Deploy the computers that run the Remote Access Service role service as members of the extranet forest. The extranet forest typically has a one-way trust with the AD DS forest in your intranet.
Use IPsec to Secure Communication Between the Remote Access Service and NPS
The computers that run the Remote Access Service role service are typically placed in environments that are less secure than the one in which the computer that runs the NPS role service resides. To prevent potential viewing of the communication between the computers that run Routing and Remote Access and NPS, secure communication by using IPsec. For more information about securing communication between Routing and Remote Access and NPS, see the sections "Use IPsec to Secure Communication Between NPS and RADIUS Clients" earlier in this chapter.
Protect RADIUS Shared Secrets
RADIUS shared secrets are used to verify that RADIUS messages, with the exception of the Access-Request message, are sent by a RADIUS-enabled device that is configured with the same shared secret. The Remote Access Service role service acts as a NAS device (RADIUS client) that communicates with NPS (RADIUS server). For more information about protecting RADIUS shared secrets, see the section "Protect RADIUS Shared Secrets" earlier in this chapter.
Require Multifactor Authentication for Remote Users
Human authentication factors typically belong to one of the following classifications:
The user knows specific information, such as a password, pass phrase, or personal identification number (PIN).
The user has a specific device, such as a smart card, security token, software token, phone, or cell phone.
The user provides a human attribute through an action, such as a fingerprint or retinal pattern, DNA sequence, signature or voice recognition, unique bio-electric signals, or another biometric identifier.
Organizations often use a combination of these methods. An example of such a combination is a debit card and a PIN, which is known as two-factor authentication. You can use multifactor authentication to enhance security in your organization, as compared to only requiring users to provide a password. Multifactor authentication typically includes a physical device, such as a smart card reader, USB security token, or fingerprint reader. Selecting physical devices for multifactor authentication is based on requirements that are not related to security.
For example, your organization could require smart cards for users that include picture identification, because you can print a picture and a name on the smart card. However, a smart card requires a reader, which might introduce additional costs. A USB token can include flash memory for storing documents and files, and users can plug a USB token into existing USB ports on their computers.
Microsoft recommends using two-factor or greater authentication for accounts that have remote access privileges.
Limit Users Who Can Remotely Access Your Intranet
In most remote access scenarios, only a subset of users require remote access. Limit the number of users who can remotely access your intranet based on their individual business needs. As an extra level of precaution, consider the following options:
Establish a stringent approval process that requires evaluation of each user request for remote access. For example, require management approval for remote access requests.
Automatically disable remote access after a period of time. This approach forces re-evaluation of the business requirements for each user's remote access privileges.
Use the PEAP or EAP-TLS Authentication Protocol to Authenticate Remote Access Users and Client Computers
Windows-based operating systems, including Windows Server 2008, support a variety of authentication protocols. The strongest of the supported authentication protocols are Protected Extensible Authentication Protocol (PEAP) and Extensible Authentication Protocol – Transport Level Security (EAP-TLS).
EAP-TLS is an EAP type of protocol that is used for smart card or certificate-based authentication. EAP-TLS message exchanges provide mutual authentication, integrity-protected cipher suite negotiation, and private key exchange and determination between the access client and the authenticating server. You can use EAP-TLS to authenticate users or computers.
PEAP does not specify an authentication method, but it does provide additional security for other EAP authentication protocols that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for 802.11 wireless client computers, but it is not supported for VPNs or other remote access clients.
You can use PEAP with the following protocols:
EAP-MS-CHAPv2 (PEAP-EAP-MS-CHAPv2), which is easier to deploy than EAP-TLS because user authentication is accomplished with password-based credentials (user name and password) instead of certificates or smart cards—only the IAS Server or RADIUS server is required to have a certificate.
EAP-TLS (PEAP-EAP-TLS), which uses certificates for server authentication and either certificates or smart cards for user and client computer authentication. Public Key certificates provide a much stronger authentication method than those that use password-based credentials. To use PEAP-EAP-TLS, you must deploy a public key infrastructure (PKI).
Microsoft recommends using EAP-TLS or PEAP-EAP-TLS to provide the highest possible security for authentication. For more information about the PEAP authentication protocol, see Protected Extensible Authentication Protocol (PEAP). For more information about EAP-TLS, see Extensible Authentication Protocol.
Secure Remote Access Client Communication
Remote access clients typically connect to computers that run the Remote Access Service role service over the Internet. You need to protect this communication by securing the traffic between the computers that run the Remote Access Service role service and the remote access clients. You can secure this traffic by using either of the following methods:
IPsec. Use the AH and ESP protocols to help secure traffic. For more information, see the IPsec overview page on TechNet.
Secure Sockets Tunneling Protocol (SSTP). SSTP is a new form of VPN tunnel with features that allow traffic to pass through firewalls that block PPTP and L2TP/IPsec traffic. SSTP provides a mechanism to encapsulate PPP traffic over the SSL channel of the HTTPS protocol. The use of PPP allows support for strong authentication methods such as EAP-TLS. The use of HTTPS means traffic will flow through TCP port 443, a port commonly used for Web access. Secure Sockets Layer (SSL) provides transport-level security with enhanced key negotiation, encryption, and integrity checking. For more information, see Step-by-Step Guide: Deploying SSTP Remote Access on the Windows Server 2008 Step-by-Step Guides page of the Microsoft Download Center.
Use NPS to Provide Centralized User Authentication
The Remote Access Service role service can authenticate user accounts that are stored in the following locations:
The Local SAM database on the computer that runs the Remote Access Service role service. This method is not recommended because the local SAM database can be subject to attack if the server is compromised.
An AD DS domain of which the computer that runs the Remote Access Service role service is a member. This method is not recommended because if the server is compromised, the attacker could gain access to the accounts in the domain.
An AD DS domain that is connected through a computer that runs the NPS role service. This method is recommended because there is an extra layer of abstraction between the computer that runs the Remote Access Service role service and the AD DS domain. Authentication of credentials in the AD DS domain can only be performed by the computer that runs the NPS role service. If the computer that runs the Remote Access Service role service is compromised, very little secure information is accessible.
|
