NPS is the Microsoft implementation of a RADIUS server and proxy. You can use NPS to centrally manage network access through a variety of network access servers, including wireless access points, VPN servers, dial-up servers, and 802.1X authenticating switches. In addition, you can use NPS to deploy secure password authentication by using any RFC3748-compliant Extensible Authentication Protocol (EAP) method, such as Protected Extensible Authentication Protocol (PEAP)-MS-CHAP v2 or Lightweight Extensible Authentication Protocol (LEAP). NPS also contains key components for deploying NAP on your network.
For more information about the NPS role service, see the Network Policy Server page on Microsoft® TechNet.
Attack Surface
The NPS role service is susceptible to the same security attacks as any RADIUS server and proxy. To identify the attack surface for this role service, you need to identify the following factors:
Installed files. The files that are installed as part of the NPS role service.
Running services. The services that run as part of the NPS 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 NPS role service uses.
Role dependencies. The dependencies for the NPS role service.
The details of the attack surface for the NPS 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 NPS role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the NPS 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 performing the NPS 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.1 Configuration Checklist
|
Configuration tasks
|
|
Restrict traffic based on the services offered.
|
|
Prohibit Legacy RADIUS requests.
|
|
Explicitly specify RADIUS clients.
|
|
Protect computers that run NPS.
|
|
Configure firewall rules on intervening firewalls.
|
|
Use IPsec to secure communication between NPS and RADIUS clients.
|
|
Enable the Message-Authenticator attribute when not using EAP authentication.
|
|
Protect RADIUS shared secrets.
|
|
Use the PEAP or EAP-TLS authentication protocol to authenticate client computers and users.
|
Restrict Traffic Based On the Services Offered
You can configure the NPS role service to respond to only RADIUS authentication requests, only RADIUS accounting requests, or both by changing the Windows Firewall rules in the following ways:
On computers that respond to only authentication requests, prohibit the UDP ports that respond to accounting requests (UDP ports 1812 and 1645).
On computers that respond to only accounting requests, prohibit the UDP ports that respond to authentication requests (UDP ports 1813 and 1646).
Prohibiting unused traffic reduces the attack surface of the computer that runs the NPS role service. For more information about configuring Windows Firewall rules, see "Firewall Rules" in the Windows Server 2008 Help and Support.
Prohibit Legacy RADIUS Requests
The RADIUS protocol standard supports two sets of UDP ports, one pair for the current RADIUS standard (UDP ports 1812 and 1813) and a pair for legacy support (UDP ports 1645 and 1646). When all the NAS devices in your organization support the current RADIUS standard, prohibit the legacy UDP ports by changing the Windows Firewall rules to block inbound traffic to UDP ports 1645 and 1646. For more information about configuring Windows Firewall rules, see "Firewall Rules" in the Windows Server 2008 Help and Support.
Explicitly Specify RADIUS Clients
You can configure NPS to communicate with all RADIUS clients (for example NASs) in your intranet, which is also known as wildcard access. However, this configuration includes all RADIUS clients, including potential rogue RADIUS clients.
To prevent potential rogue RADIUS clients from communicating with NPS, explicitly specify the RADIUS clients to use in your remote access solution. For more information about explicitly specifying a RADIUS client, see "Add a New RADIUS Client" in the Windows Server 2008 Help and Support.
Protect Computers That Run NPS
The server computer that runs the NPS role service needs to communicate with the Active Directory® Domain Services (AD DS) domain controllers to authenticate remote user credentials. 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. For more information about communication between NPS and domain controllers, see Network Policy Server Infrastructure on TechNet.
Configure Firewall Rules on Intervening Firewalls
RADIUS clients are typically placed in an extranet or perimeter network (also known as DMZ, demilitarized zone, and screened subnet). The computers that run the NPS role service are typically placed in protected networks with one or more firewalls between the RADIUS client and NPS.
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 preceding sections on "Restrict Traffic Based on the Services Offered" and "Prohibit Legacy RADIUS Requests."
Use IPsec to Secure Communication Between NPS and RADIUS Clients
RADIUS clients 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 NPS and RADIUS clients, secure communication by using IPsec, which includes the following protocols:
Authentication Header (AH). This protocol provides integrity, authentication, and nonrepudiation if the appropriate choice of cryptographic algorithms is made.
Encapsulating Security Payload (ESP). This protocol provides confidentiality, along with optional authentication and integrity protection that Microsoft strongly recommends.
You can use either of these protocols to secure communication between the NPS and RADIUS clients by using IPsec. However, using both protocols ensures the highest level of protection from IPsec. Microsoft recommends using other IPsec authentication methods instead of preshared keys, such as Kerberos version 5 protocol or public key certificate authentication methods. For more information, see the IPsec overview page on TechNet.
Enable the Message-Authenticator Attribute When Not Using EAP Authentication
When you configure a RADIUS client in NPS, you configure the IP address of the client. If an incoming RADIUS Access-Request message does not originate from at least one of the IP addresses of configured clients, NPS discards the message to protect the NPS server. However, attackers can spoof source IP addresses.
Important Client computers, such as wireless laptop computers and other computers that run client operating systems, are not RADIUS clients. RADIUS clients are network access servers, such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers. This is because they use the RADIUS protocol to communicate with RADIUS servers, such as Network Policy Server (NPS) servers.
To provide protection from spoofed Access-Request messages and RADIUS message tampering, you can additionally protect each RADIUS message with the RADIUS Message Authenticator attribute, which is described in RFC 2869, "RADIUS Extensions." Enabling the Message Authenticator attribute provides additional security when PAP, CHAP, MS-CHAP, and MS-CHAP v2 are used for authentication. EAP uses the Message Authenticator attribute by default. Therefore, when you use EAP as an authentication method, you do not have to enable the Message Authenticator attribute.
For information about how to configure the Message Authenticator attribute for the RADIUS clients of an NPS server, see "Using the Message Authenticator Attribute" in the Windows Server 2008 Help and Support. For information about how to configure the Message Authenticator attribute for the Routing and Remote Access service, see "RADIUS Clients" in the Windows Server 2008 Help and Support.
Protect RADIUS Shared Secrets
Shared secrets are used to verify RADIUS messages. With the exception of the Access-Request message, they are sent by a RADIUS-enabled device that is configured with the same shared secret. Shared secrets also verify that the RADIUS message has not been modified in transit to ensure message integrity. The shared secret is also used to encrypt some RADIUS attributes, such as User-Password and Tunnel-Password. To provide verification for Access-Request messages, you can enable the RADIUS Message Authenticator attribute for both the RADIUS client configured on the NPS server and the access server.
Observe the following guidelines and best practices when creating and using a shared secret:
You must use the same case-sensitive shared secret on both RADIUS devices.
Use a different shared secret for each RADIUS server-RADIUS client pair.
To ensure a random shared secret, generate a random sequence at least 22 characters long.
You can use any standard alphanumeric and special characters.
You can use a shared secret of up to 128 characters in length. To protect your Microsoft Internet Security and Acceleration (IAS) Server and your RADIUS clients from brute force attacks, use long shared secrets of more than 22 characters.
Make the shared secret a random sequence of letters, numbers, and punctuation marks and change it often to protect your IAS Server and your RADIUS clients from dictionary attacks. Shared secrets should contain characters from each of the groups listed in the following table:
Table 10.2 Shared Secret Characters
Group
|
Examples
|
Letters (uppercase and lowercase)
|
A, B, C and a, b, c
|
Numerals
|
0, 1, 2, 3
|
Symbols (all characters not defined as letters or numerals)
|
Exclamation point (!), asterisk (*), colon (:)
|
The stronger your shared secret, the more secure the attributes are for such things as passwords and encryption keys that use it. An example of a strong shared secret is 8d#>9fq4bV)H7%a3-zE13sW.
For more information about creating strong shared secrets, see the Shared secrets page on TechNet.
Use the PEAP or EAP-TLS Authentication Protocol to Authenticate Client Computers and Users
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). Both of these authentication protocols provide the security framework for mutual authentication between NPS and client computers.
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 the Protected Extensible Authentication Protocol (PEAP) page on the MSDN® Web site. For more information about EAP-TLS, see the Extensible Authentication Protocol page on TechNet.
|
