Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Securing Wireless Access Using IAS

Access to your network via 802.11 wireless access points (APs) should be considered as a form of remote access. Unlike wired LANs and WANs, the wireless network boundary can easily and unintentionally extend beyond your organization's perimeters and, by default, is also available to anyone visiting your organization that has a wireless access card and appropriate computing device. Laptop computers and PDAs now come with wireless network cards, and for those that do not have a card, many inexpensive cards are available.

By default, little to no security is imposed on wireless network APs; thus, wireless networks can pose serious threats to the security of wired networks. There are security features provided with most APs, including authentication and encryption; however, in many cases, there are ways around these features, and in most cases, they are not configured at all. There are three possible ways to improve wireless security.

Native 802.11 Security Features

The first step to securing wireless is to understand the features offered by existing wireless APs and use them. The features usually available are as follows:

Encryption
Wireless Equivalent Privacy (WEP) is the encryption process provided for 802.11 networks. The implementation of WEP in most APs is flawed, and tools exist that can discover encryption keys and thus read messages if the tools are allowed to capture enough packets. Still, for most implementations, the benefits of using encryption are like the benefits of locking one's house or car. Tools exist that can get past the locks, but most people do not have nor have a desire to use the tools, and a lock, or in this case encryption, does what it is supposed to do. In addition to its vulnerability to sophisticated technical attacks, WEP does not provide key management. In order to change keys, which could lessen the threat of successful attack, the AP and all clients must be reconfigured. This is not easily done in a network of any size.

What's All the Fuss?

WEP can be cracked, or so they say. Researchers at Berkeley first documented possible attacks on WEP, and their research has been supported by others. Tools exist today, such as AirSnort, that can be used to crack WEP. A large number of packets must be captured, which might take longer than the intruder cares to wait. However, in a busy network, 15 minutes might be all that is required. Still, not every network is monitored all the time, and more recent WAPs include WEP algorithms that appear resistant to these types of attacks.

Authentication
Authentication is either Open System, in which no authentication is required, or Shared Key authentication, in which the client must manually enter the key used by the AP. There is no key management for the shared key. The same key is used by every client. In addition, it may be more secure to use Open System. In many wireless implementations, the shared key for authentication is the same as the encryption key. Shared key authentication uses a challenge and response mechanism that may be susceptible to attack. If the authentication key is obtained, it can be used to decrypt encrypted wireless messages.

MAC address filtering
The Media Access Control (MAC) address of the network card is stored on the AP, and only those computers whose MAC address is present can connect. Because MAC addresses can be spoofed, this security is not foolproof. However, it does add some protection from the casual interloper.

No SSID broadcast
The SSID is the network name for the wireless network. It is broadcast by default, and many devices are programmed to automatically connect to available SSIDs. Turning off the broadcast discourages casual access once again, but the SSID is part of wireless communications that is not encrypted, and thus a sniffer can determine the SSID. In addition, the SSID is entered in clear text in the wireless network configuration of the clients, so the SSID can be easily discovered by visiting with authorized users or possibly by looking over their shoulders.

Secure AP use of SNMP
Many wireless APs automatically configure the Simple Network Management Protocol (SNMP) to provide remote administration of the AP. However, few provide any security. Common default community names such as public and comcomcom are implemented. Community names are used by SNMP to provide access to administrator. They can be used to find information about the AP and modify its configuration. If SNMP must be used for administration, modify the community names. Take the time to verify that the SNMP agent has been patched to correct the flaw exploitable by the PROTOs tool developed by the University of Oulu. If SNMP is not needed, turn it off.

Secure administration tools
Many APs have web-based administration tools that can be accessed over the wireless network. Change the password for these tools to a long, strong password before the AP is placed on the network.

WiFi Protected Access (WPA)

WPA is an interim standard that follows the proposed 802.11i wireless standard. 802.11i uses the Temporal Key Integrity (TKI) algorithm. TKIP rekeys (changes) the key used for every frame. WPA specifies synchronization of keys between client and server. If a RADIUS server is available, the standard supports the use of EAP for authentication; otherwise, a shared key can be used. A technique called Michael provides integrity. An 8-byte Message Integrity Code (MIC) is included with the data, and the Integrity check value used by 802.11. Some network APs are now available that use WPA, and some current 802.11 APs and wireless network cards may be upgradeable. An upgrade for Windows XP Professional implements the WPA architecture.

Using a VPN

Typical 802.11 wireless networks can be provided additional security by requiring a VPN connection to the network where wireless APs are used. When VPN connections are required, Windows accounts can be used for authentication, and the encryption can be provided by the VPN. Figure 14-38 illustrates this arrangement. The wireless AP is connected to the external interface of the VPN server, and the internal network is connected to the internal interface of the VPN server. To connect to the internal network, the wireless client must authenticate to the VPN server and make a VPN connection.

Figure 14-38. VPN protection can be added between the wireless network and the internal network.

Using 802.1x

802.1x is a new standard for 802.11 network authentication. This standard requires wireless APs and wireless network cards that meet the standard and a RADIUS server. A Windows Server 2003 IAS server can be used as that RADIUS server. Figure 14-39 illustrates the network topology. Clients request a connection to the wireless access point, which in turn acts as a RADIUS client. The RADIUS server uses Active Directory or its own account database for authentication and Remote Access Policies to determine if the access is authorized. This solution can also solve the key management problem; encryption keys can be automatically issued to authorized clients and changed frequently without manual intervention. In addition, clients can be required to have computer certificates. When clients must use certificates to authenticate to the IAS server, many unauthorized attempts at connection can be rejected.

Figure 14-39. VPN protection can be added between the wireless network and the internal network.

[View full size image]

NOTE: Downlevel Systems

An upgrade for Windows 2000 is available to allow a Windows 2000 IAS server to be used as the RADIUS server for 802.1x authentication. An 802.1x client is available for Windows 2000. Additional clients are available to Microsoft customers with a support agreement for Windows 98, Windows Millennium Edition, and Windows NT 4.0.

Security Improvements with 802.1x and WPA

There are two major security improvements: improved authentication methods and dynamic key assignment.

Instead of relying on simple AP identification, 802.1x provides a choice of authentication methods:

Protected Extensible Authentication Protocol (PEAP) EAP-MSCHAPv2
Passwords are protected by Transport Layer Security. The IAS server must have a certificate, but client computers do not. Users can use their Windows account passwords.

EAP-TLS
Certificate-based mutual authentication. Both client computers and IAS must have certificates.

EAP-MD5
No certificates at all are required. Authentication is not mutual. This choice is not considered secure because the user provides an account and password using the MS-CHAP protocol. Unlike the PEAP EAP-MSCHAPv2, EAP-MD5 is susceptible to dictionary attacks.

Unlike earlier wireless standards that provide no key management and rely on WEP, WPA (and some implementations of 802.1x, such as Microsoft's) provides key management and encryption. Dynamic key assignment or rekeying is used to distribute keys to the client automatically and to change the keys frequently when certificates are used for authentication (when EAP-TLS is used). 802.1x can be implemented with either WPA or 128-bit WEP. When Windows XP clients are used with IAS, key assignment is performed during certificate authentication and is protected. Keys can be refreshed periodically by forcing Windows XP to re-authenticate to the server every 10 minutes.

Implementing 802.1x Security Using IAS

To configure IAS to support 802.1x authentication for wireless APs, follow these instructions:

Configure the AP as a RADIUS client by using the instructions given previously for configuring an RRAS server as a RADIUS client in the IAS interface.

Configure the wireless AP according to the manufacturer's instructions.

Create a Remote Access Policy for wireless clients.

Create a Connection Request Policy. Remote Access Policies are created to define and constrain user connections. A Connection Request Policy is used to constrain RADIUS clients. They can be used to restrict a RADIUS client to dates, times, and so forth.

Configure wireless clients via Group Policy.

Create a Remote Access Policy for Wireless Clients

Use the Remote Access Policy Wizard to create a policy for wireless clients. The following custom configuration should be made:

To identify incoming requests from wireless clients, use the Condition NAS-Port Type and select Wireless - Other or Wireless-IEEE 802.11 policy, as shown in Figure 14-40.

Figure 14-40. Use the Wireless - Other or Wireless-IEEE 802.11 NAS port type in the Remote Access Policy.

Configure other parameters as required. For example, restrict wireless access to certain groups of users, for certain times of day, and so forth.

Set the profile attribute Ignore Users-Dial-in to true to ensure that settings such as Callback are not sent to wireless APs.

Set the Advanced profile attribute Terminate Action to RADIUS-Request, as shown in Figure 14-41, to ensure that when XP clients re-authenticate, wireless APs don't disconnect them.

Figure 14-41. Set Terminate Action to RADIUS-Request.

Configure 802.1x Authentication for Clients Using Group Policy

Windows XP clients can be individually configured to use 802.1x; however, you can do so more efficiently and consistently by using Group Policy. To do so, follow these steps:

Select the Computer Configuration, Windows Settings, Security Settings, Wireless Network (IEEE 802.11) Policies, as shown in Figure 14-42, and double-click the policy that you want to configure. If the policy does not exist, create one by right-clicking the Wireless Network Policies and selecting Create New Policy.

Figure 14-42. Find the wireless policy in Group Policy.

[View full size image]

On the General tab, as shown in Figure 14-43, use the Network to access drop-down box to select Access point (infrastructure) networks only.

Figure 14-43. Select infrastructure networks.

On the General tab, select the Use Windows to configure wireless network settings for to set a preference for Windows configuration over a third-party wireless client loaded on the client computer.

Do not select Automatically connect to non-preferred networks. (It is cleared by default.) Checking this box allows clients to automatically attempt to connect to any wireless network. This is not a good policy for environments where rogue wireless networks may exist. Connecting to them may subject the client computer to attack.

On the Preferred Networks tab, click the Add button to configure the organization's AP information including, SSID and WEP, as shown in Figure 14-44, Repeat for each AP.

Figure 14-44. Add wireless network information on the Network Properties tab.

For each network, use the Network Properties tab to configure the SSID.

Do not select Shared Mode for network authentication. Open mode is required to allow 802.1x authentication.

Enable WEP and select The key is provided automatically to allow dynamic key exchange.

Select the IEEE 802.1x tab, as shown in Figure 14-45, to configure 802.1x-specific properties. Enable network access control using IEEE 802.1x is enabled by default.

Figure 14-45. Configure 802.1x authentication.

10.

In the EAPOL-Start message, specify any parameters for transmitting EAP over LAN (EAPOL) start messages. These must match the configuration at the AP. Choices are transmit, Do Not Transmit, and TRansmit per IEEE 802.11x. Specify the parameters (seconds).

11.

Select the EAP types to be used with the wireless network. This will match that selected in IAS.

12.

If Smart Card or other certificate is selected, click Settings… and

Select Use My Smart Card if smart cards are to be used or

select Use a Certificate On This Computer if a certificate in the certificate store on the computer should be used for authentication.

Verify that the server certificate is valid by selecting the Validate Server Certificate box, then click Connect to These Servers and specify the server or servers that client computers should automatically connect to. Specify the trusted root certification authorities.

To allow users to use a different name than the user name associated with their smart card or certificate (in case this name is not the same as their domain user name for the domain in which they wish to log on), select the Use A Different User Name for the Connection box.

13.

If PEAP is selected in the EAP type, then

Select the Validate Server Certificate check box to validate that the server certificate is still valid. Click the Connect to These Servers check box and specify the server or servers that clients should automatically connect to. Specify the trusted root certification authority.

Use the Select Authentication Method area to select the authentication method that clients can use within PEAP.

If Secured Password (EAP-MSCHAPv2) is selected, in its properties, specify if the user name, password, and domain that users normally use should be used.

If Smart Card or other certificate is selected, configure as specified in step 6.

If Fast Reconnect is desired, check the Enable Fast Reconnect check box.

PEAP Fast Reconnect allows roaming users to maintain connectivity when traveling between APs on the same network if each AP is configured as a RADIUS client of the same IAS server.

Both wireless client and RADIUS server must be configured for fast reconnect.

14.

If client computers should attempt to authenticate when user information or computer information is not available, select Authenticate as Guest When User or Computer Information Is Unavailable.

15.

If client computers should attempt to authenticate when users are not logged on, check the Authenticate as Computer When Computer Information is Available. In Computer Authentication, click an option to specify how. The options are as follows:

User Authentication
Computer credentials are used and will continue to be used even when the user logs on. If a different AP is accessed, and the user is logged on, his credentials will be used.

With User Re-Authentication (Recommended)
Computer credentials are used when the user is not logged on, and user credentials are used when the user logs on. When the user logs off, the computer credentials are used again.

Computer only
Authentication always uses the computer credentials, never the users.

Allowing computer authentication using any of these methods is useful in order to maintain client connections when users are logged off. On the other hand, it might allow an attack to go unnoticed, as computers may connect to the network when users are not logged on, and in the first and latter case, it may allow unauthorized users to obtain wireless access.

How Does 802.1x Authentication Work?

802.1x authentication specifies the following physical infrastructure:

A supplicant
This is the wireless client.

A wireless AP with two ports
One port is the uncontrolled port and any client can connect and begin to negotiate a connection with the uncontrolled port. The controlled port grants access to authenticated and authorized clients to the network.

A RADIUS server or authenticator
This serves as the control agent.

An authenticating server
This validates client credentials.

Figure 14-46 illustrates this arrangement; in the figure, a client has requested access but has not been authenticated, so the controlled port is not available to it.

Figure 14-46. 802.1x requires access to the controlled port be authenticated and authorized.

[View full size image]

As implemented using IAS, access is negotiated in the following manner:

The supplicant, the wireless client, requests a connection.

The AP requests identity information.

The supplicant returns the information.

The AP creates a RADIUS access request message that includes the supplicant's credentials and sends it to the authenticator. (In our case, the IAS server.)

IAS checks its Connection Requests Policies to see whether the AP is approved and whether the request meets any constraints.

If the AP is approved and constraints are met, IAS checks its Remote Access Policies to see whether the client is authorized.

If the client is authorized, the credentials from the access request message are forwarded to the domain controller (the authenticating server) for validation.

If the client is authenticated, confirmation is returned to IAS.

IAS checks its Remote Access Policies for any constraints that must be applied to the connection.

Notice of accepted authentication and authorization is returned to the AP in a RADIUS accept message.

The AP generates the WEP keys and passes them to the client.

The client is allowed access to the network through the controlled port.

Securing Wireless Clients

Securing wireless clients is another important aspect of wireless security. Compromised clients pose a threat to servers and other clients. Mobile wireless clients are often exposed to viruses, Trojan horses, and other attacks when they connect to public networks.

Client security should be maintained by hardening clients, including the use of personal firewalls, anti-virus software, and by only connecting to protected wireless networks. When 802.1x authentication is not in place, clients should be configured to use a VPN for access to the network.

Best Practices for Wireless Access

Use Group Policy to set Client Settings.

Use 802.1x.

Use SSL, SSH, or another secured connection when remotely managing APs to prevent capture of configuration data.

Manage APs from the wired network.

Use IAS Remote Access Policies to control client authorization, encryption, IP packet filters, and static routes.

Use IAS Connection Policies to validate APs and restrict their access.

Use PEAP-EAP MS-CHAPv2 when computers are not domain members and when certificate infrastructure is not in place.

Do not use PEAP-MD5. The password is not protected against dictionary attacks.

Best Practices for IAS and RRAS Security

If you must use passwords, use strong passwords. Strong passwords are those that are 8 or more characters long and are composed of uppercase and lowercase characters, numbers, and special characters. Strong passwords make password-cracking attacks more difficult.

If possible, require smart cards for remote authentication.

Where MS-CHAP will be allowed for authentication, require MS-CHAPv2 authentication. MS-CHAPv2 updates are available for most Windows versions that are not able to use MS-CHAPv2 by default.

Disallow the use of MS-CHAP. If you cannot, change the value of the Allow LM Authentication to 0 at the following location. This prevents the use of LM authentication that is allowed by default when MS-CHAP is used. Be sure to configure clients by adding, if necessary, the AD client and configuring the clients to use NTLMv2 for authentication:


HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccessPolicy

Configure the highest level of encryption and authentication that clients can use.

When RADIUS is selected as an authentication and/or accounting method, use a long shared secret (22 characters or more) composed of a random sequence of letters, numbers, and punctuation and change it often. This helps protect the password from dictionary and brute-force password attacks.

The shared secret is also used to provide message integrity.

Use the Message Authenticator attribute to protect RADIUS from spoofed IP addresses. The IP address of the RADIUS client is configured in the IAS properties and is used to determine whether or not to consider a connection request. Because IP addresses can be spoofed, the Message Authenticator attribute can be used to provide further protection. It is an MD5 hash of the entire RADIUS message that uses the shared secret as a key. If the feature is used, RADIUS messages can be verified as coming from a client or server with knowledge of the shared secret. Messages that do not pass this test are dropped. If the Message Authenticator attribute is required and not used, the message will also be dropped.

Use a different shared secret for each RADIUS client and RADIUS server pair, and for each RADIUS proxy and RADIUS server pair, unless you specify RADIUS clients by IP address range, in which case you must use the same shared secret for each RADIUS client in that group.

Use IPSec to secure the entire RADIUS message by creating a policy for use by communication between the RRAS and IAS servers. This is especially important where the threat environment may be high.

Enforce strong password policies on the network if smart cards cannot be used.

Be cautious if you decide to use account lockout policy for remote access. If a dictionary or brute-force attack is run against accounts, it can lock out both the attacker and the legitimate user. (Note that account lockout for remote access has nothing to do with the account lockout policy configured in Group Policy.)

If you locate the logs to a different place from the default location, configure the ACLs on the log files to allow only the local system account and the Administrators group access.

If you redirect logging to SQL server, ensure control of who can access database. Secure the SQL server and the connection and transport of log data.

Configure auditing to track who accesses the log files.

Do not move log files to a server on which access controls cannot be set on the files.

Establish encrypted communication between the RRAS or IAS server and the SQL server if log files are published to the SQL server. The log data is sent in plain text and should be encrypted to protect it. See the SQL server documentation for help in configuring the encrypted communication.

Use terminal services to administer RRAS and IAS remotely. Communications are 128-bit encrypted.