8.3 WLAN Risk Management


8.3 WLAN Risk Management

In this section, we look at what risks are faced by security managers when implementing WLANs, especially when connecting WLANs to LANs. The best weapon to combat these weaknesses is knowledge because administrators who are aware of the risk can defend against it more effectively. Administrators who procrastinate or choose not to continually review their security profiles only increase the risk that a breach in the defenses will occur. Now, let's look at what it takes to secure the WLAN.

8.3.1 Necessary Steps to Securing the WLAN Configuration

According to NIST SP800-48 [11] (draft), network administrators need to configure APs in accordance with established security policies and requirements. Properly configuring administrative passwords, encryption settings, reset function, automatic network connection function, Ethernet Medium Access Control (MAC) Access Control Lists (ACLs), shared keys, and Simple Network Management Protocol (SNMP) agents helps eliminate many of the vulnerabilities inherent in a vendor's software default configuration. What follows are some other NIST-recommended steps administrators should take to ensure WLAN security:

  • Updating default passwords. Each WLAN device comes with its own default settings, some of which inherently contain security vulnerabilities. The administrator password is a prime example. On some APs, the factory default configuration does not require a password (i.e., the password field is blank). Unauthorized users can easily gain access to the device if there is no password protection. Administrators should change default settings to reflect the organization's security policy, which should include the requirement for strong (i.e., an alphanumeric and special character string at least eight characters in length) administrative passwords. If the security requirement is sufficiently high, an organization should consider using an automated password generator. An alternative to password authentication is two-factor authentication. One form of two-factor authentication uses a symmetric key algorithm to generate a new code every minute. This code is a one-time use code that is paired with the user 's personal identification number (PIN) for authentication. Another example of two-factor authentication is pairing the user's SmartCard with the user's PIN. This type of authentication requires a hardware device reader for the SmartCard or an authentication server for the PIN. Several commercial products provide this capability. However, use of an automated password generator or two-factor authentication mechanism may not be worth the investment, depending on the organization's security requirements, number of users, and budget constraints.

  • Establishing proper encryption settings. Encryption settings should be set for the strongest encryption available in the product, depending on the security requirements of the organization. Typically, APs have only a few encryption settings available: none, 40-bit shared key, and 128-bit shared key (128-bit being the strongest). Encryption such as that used in WEP, simple stream cipher generation, and XOR processing does not pose an additional burden on the computer processors performing the function. Consequently, organizations do not need to worry about computer processor power when planning to use encryption with the longer keys; however, it should be noted that some attacks against WEP yield poor results regardless of the key size .

  • Controlling the reset function. The reset function poses a particular problem because it allows an individual to negate any security settings administrators have configured in the AP. It does this by returning the AP to its default factory settings. The default settings generally do not require an administrative password and may disable encryption. An individual can reset the configuration to the default settings by simply inserting a pointed object such as a pen into the reset hole and pressing. If a malicious user gains physical access to the device, that individual can exploit the reset feature and cancel out any security settings on the device. The reset function, if configured to erase basic operational information such as an IP address or keys, can further result in a network denial-of-service (DoS), because APs may not operate without these settings. Having physical access controls in place to prevent unauthorized users from resetting APs can mitigate the threats. Organizations can detect threats by performing regular security audits .

  • Using MAC ACL functionality. A MAC address is a hardware address that uniquely identifies each computer (or attached device) on a network. Networks use the MAC address to help regulate communications between different computer NICs on the same network subnet. Many 802.11 product vendors provide capabilities for restricting access to the WLAN based on MAC ACLs that are stored and distributed across many APs. The MAC ACL grants or denies access to a computer using a list of permissions designated by MAC address; however, the Ethernet MAC ACL does not represent a strong defense mechanism by itself. Because MAC addresses are transmitted in the clear from a wireless NIC to an AP, the MAC can be easily captured. Malicious users can spoof a MAC address by changing the actual MAC address on their computer to a MAC address that has access to the wireless network. This countermeasure may provide some level of security; however, users should exercise caution. This may be effective against casual eavesdropping, but will not be effective against determined adversaries. Users may want to consider this as part of an over-all Defense-in-Depth strategy ”adding levels of security to reduce the likelihood of problems ”but users should weigh the administrative burden of enabling the MAC ACL ( assuming they are using MAC ACLs) against the true security provided. In a medium to large network, the burden of establishing and maintaining MAC ACLs may exceed the value of the security countermeasure.

  • Changing the SSID. The SSID of the AP should be changed from the factory default. Although an equipped adversary can capture this identity parameter over the wireless interface, it should be changed to prevent unsophisticated adversary attempts to connect to the wireless network.

  • Changing default cryptographic keys. The manufacturer may provide one or more keys to enable shared key authentication between the device trying to gain access to the network and the AP. Using a default shared key setting is a security vulnerability because many vendors use identical shared keys in their factory settings. A malicious user may know the default shared key and use it to gain access to the network. Changing the default shared key setting to another key will mitigate the risk. For example, the shared key could be changed to "954617" instead of using a factory default shared key of "111111." No matter what their security level, organizations should change the shared key from the default setting because it is easily exploited. In general, organizations should opt for strong encryption (e.g.,128-bit), regardless of their security levels, whenever it is available. If it is not available or feasible , organizations should, assuming they have already performed a risk analysis, use 40-bit encryption. Finally, a generally accepted principle for proper key management is to change cryptographic keys often.

  • Changing the default SNMP parameter. Some wireless APs use SNMP agents, which allow network management software tools to monitor the status of wireless APs and clients . The default SNMP community string that SNMP agents commonly use is the word "public" with assigned "read" or "read and write" privileges. Using this well-known default string leaves devices vulnerable to attack. If an unauthorized user were to gain access and had read/write privileges, that user could write data to the AP, resulting in a data integrity breach. Organizations that require SNMP should change the default community string, as often as needed, to a strong community string. Privileges should be set to "read only" if that is the only access a user requires. If SNMP is not required on the network, the organization should disable SNMP altogether.

  • Changing the default channel. One other consideration that is not directly exploitable is the default channel. Vendors commonly use default channels in their APs. If two or more APs are located near each other, but are on different networks, a DoS can result from radio interference between the two APs. Organizations that incur radio interference need to determine if any nearby APs are using the same channel or a channel within five channels of their own, and then choose a channel that is in a different range.

  • Using DHCP. Automatic network connections involve the use of a Dynamic Host Control Protocol (DHCP) server. The DHCP server automatically assigns IP addresses to devices that associate with an AP when traversing a subnet. For example, a DHCP server is used to manage a range of TCP/IP addresses for client laptops or workstations. After the range of IP addresses is established, the DHCP server dynamically assigns addresses to workstations as needed. The server assigns the device a dynamic IP address as long as the encryption settings are compatible with the WLAN. The threat with DHCP is that a malicious user could easily gain unauthorized access on the network through use of a laptop with a wireless NIC. Because a DHCP server will not necessarily know which wireless devices have access, the server will automatically assign the laptop a valid IP address. Risk mitigation involves disabling DHCP and using static IP addresses on the wireless network, if feasible. This alternative, like the MAC ACL countermeasure, may only be practical for relatively small networks, given the administrative overhead involved with assigning static IP addresses and the possible shortage of addresses. Statically assigning IP addresses would also negate some of the key advantages of wireless networks, such as roaming or establishing ad hoc networks. Another possible solution is to implement a DHCP server inside of the wired network's firewall that grants access to a wireless network located outside of the wired network's firewall. Still another solution is to use APs with integrated firewalls. This last solution will add an additional layer of protection to the entire network. All users should evaluate the need for DHCP considering the size of their network.




Wireless Operational Security
Wireless Operational Security
ISBN: 1555583172
EAN: 2147483647
Year: 2004
Pages: 153

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net