Wireless LAN Security Best Practices

Author: Herbert Haas
Address:
herbert AT perihel DOT at
http://www.perihel.at/dcom
Revision: 0.1
Date: 2008-06-17
Copyright: Copyright (c) 2008 Herbert Haas.

Abstract

This document summarizes important facts about WLAN Security. It is not a WLAN tutorial. Note that some Cisco-related explanations or recommendations are provided as is, without any warranty - please consult www.cisco.com for more detailed information. The reader should already be familiar with WLAN fundamentals (see e. g. my WLAN lecture notes). If you find any mistakes please send me an E-Mail, thanks!

Contents

1   Motivation

Even relatively recent (german) studies show that more than 50% of all WLAN networks rely on WEP encryption, while approximately 17% are protected by WPA or WPA2. Roughly 22% are unprotected at all.

It is important to explain to decision makers that WEP encryption is not 'good enough'. WEP can be cracked within minutes (or even less) and the needed cracker tools can be operated by anybody. That is, using WEP is practically only slightly better than avoiding security measures at all!

1.1   802.11 Standard Authentication

The original 1997 version of the IEEE 802.11 standard mandates either open system or shared key authentication before sending any association request. Even when you plan 802.1x authentication you must choose one of them.

Note:

  • Shared key authentication is extremely insecure and useless. Only use it if you want to make the attacker happy.
  • Always prefer Open System Authentication. Together with WPA2.

1.2   Encryption Summary

  • WEP is always insecure. With aircrack-ptw you can crack WEP within a few minutes (possibly less than two).
  • Dynamic WEP i. e. 802.1x-based user-specific WEP keys are also very insecure. Because the keys are not changed unless the user dissassociates.
  • TKIP and MIC are secure enough for most cases. As of today no successful attacks are known.
  • AES-CCM is the best we have.

Remember:

  • WPA = 802.1x + TKIP + MIC + Key Management
  • WPA2 = 802.1x + AES-CCM + Key Management

Although it is possible to support WPA, WPA2, TKIP, MIC, and AES-CCMP, in combination, it is recommended to configure different SSIDs, one for WPA (with TKIP and MIC), the other for WPA2 (with AES-CCM). This is because some clients have difficulties if one SSID supports all combinations. Especially try to avoid non-standard combinations such as AES-CCM with WPA (v1) or TKIP with WPA2 (although most clients have no problems with that - try it).

Avoid WPA-PSK or WPA2-PSK! These don't use 802.1x or key management and are vulnerable to offline dictionary attacks. If you must use them, then use keys longer than 20 characters, prefer good 64 byte keys.

1.3   Wireless Equivalent Privacy

'WEPplus' = WEP with avoidance of weak IVs

2   802.11i and WPA2

WPA2 supports FIPS 140-2 compliant security, basically AES in counter mode. (An early draft included AES-OCB instead but it was dropped due to patent issues.) A 48 bit IV protects against replay attacks.

Authentication and Integrity is maintained using an 8 byte CBC-MAC with a 48 bit nonce. Besides the data also the source and destination MAC addresses in the header are protected by the CBC-MAC. (These fields are called Additional Authentication Data (AAD).

The CBC-MAC, the nonce, and additional 2 byte IEEE 802.11 overhead make the CCMP packet 16 octets larger than an unencrypted IEEE 802.11 packet.

The AP advertises cipher suites both in beacons and probe responses.

2.1   Proactive Key Caching (PKC)

PKC allows a client to store PMKs to reuse them when later associated to the same AP or LAP. In order to support PKC the clients calculates and sends PMKIDs, i. e. a hash of the PMK, a string, the station MAC and the AP MAC. This 'PMK SA Identifier' is sent in an association request. The PMKID uniquely identifies the PMK on the WLC and therefore the 802.1x authentication can be by-passed. The client can send more than one key name in the association request. If the access point or WLC sends a success in the association response, then the client and access point proceed directly to the 4-way handshake.

Note:

  • PKC is automatically enabled on a Cisco WLC when WPA2 is enabled for a WLAN.
  • PKC does not work with Aironet Desktop Utility (ADU) as client supplicant.

2.2   Preauthentication

While PKC reduces the reauthentication time on APs or WLCs where the client has been authenticated once, preauthentication reduces roaming delays because it allows clients to authenticate to other APs or WLCs without association. Note that the preauthentication process is realized through the current AP or WLC to which the client is currently associated! Using preauthentication the client can establish PMKs with all APs or WLCs. The PTK handshake is only performed when the client actively associates to a new AP or WLC. In this case the association request again carries a PMK SA Identifier as explained in the PKC section above.

2.3   Differences between 802.11i and WPA2

WPA2 compliant products are always backwards compatible with WPA. If all devices run AES-CCMP then 802.11i is used. If some run TKIP then WPA2 devices are needed which run a mixture of 802.11i and WPA.

2.4   Migration Mode

Aironet APs support a 'Migration Mode' to support both legacy WEP-only clients and new WPA clients. This mode can be enabled by selecting a cipher suite (>encryption manager) which supports both methods such as

  • TKIP+WEP128
  • TKIP+WEP40

Besides WPA clients, static and dynamic WEP clients (802.1x) are supported.

Additionally configure

  • Appropriate static WEP keys in slot 2 or 3
  • Key management 'WPA optional'

3   Management Frame Protection (MFP)

4   Wired Guest Access

Configuration steps:

  1. Interface configuration: check Guest LAN checkbox.

  2. WLANs > New

    • Set type to Guest LAN (instead of WLAN)
    • Configure an arbitrary SSID
    • Choose the VLAN interface configured above as Ingress Interface. This is the interface the client comes in (i. e. the access switch is located)
    • Choose another VLAN interface as Egress Interface. Client data is forwarded through this interface when the client is successfully authenticated. For example choose the same guest-VLAN as used with wireless guest WLAN.
  3. Create a local guest user and from the drop down menu check either the SSID configured in step 2 or choose Any WLAN (so this user can also use the normal wireless guest WLAN.

4.1   Note

  • The access switch must have a direct layer-2 connectivity to the WLC (no routing!)
  • The DHCP server defined on the egress interface is used for the client.
  • The default authentication method under the WLAN settings is Web-Auth (obviously).

5   Other interesting controller features

5.1   Trusted AP Policies

Validate SSID
If a rogue (known internal!) uses one of our own SSIDs then generate alert!

5.2   Rogue Detection

Either via RLDP and/or using Rogue Detection APs which scan for rogue clients also. Using RLDP, the WLC commands the nearest own (joined) LAP to act like a client, associate to the Rogue AP and obtain an IP address. Then this AP (the pseudo-client) sends a ping-like packet to the WLC's management interface. If this ping arrives we know that the rogue is attached to our LAN.

5.3   WLC/ACS Radius

  • AES key wrap, (defined in draft-zorn-radius-keywrap-13) describes more secure methods for RADIUS to communicate keying material. On the WLC enable AES key wrap for a more secure RADIUS connection.

5.4   AP Authentication Policy

  • Similar MFP, also uses Timestamp
  • But the RF Group name is used as key (protects RF group)
  • Only applied to RRM frames between APs

5.5   AP Policies

When using a Self Signed Certificate (SSC) the SHA-1 fingerprint must be configured on the WLC under Security > AP Policies. Here the AP's MAC address is tied to its certificate fingerprint. The fingerprint can be obtained from the CSV file which is created by the upgrade tool. Alternatively (if the fingerprint is unknown) you can observe what the AP is sending to the WLC:

wlc> debug pm pki enable

Verifcation commands:

wlc> show auth-list
wlc> show ap summary

You can configure controllers to use RADIUS servers to authorize access points using MICs. The controller uses an access point’s MAC address as both the username and password when sending the information to a RADIUS server. For example, if the MAC address of the access point is 000b85229a70, both the username and password used by the controller to authorize the access point are 000b85229a70. Do not use the same AAA server for client authentication.

5.6   Peer to Peer Blocking (aka PSPF)

The Peer-to-Peer Blocking feature blocks communication between each two clients on the same WLC (option drop). If you want to extend blocking over your whole WLAN then choose forward upstream and let the central switch decide (configure Private VLANs there: let the client VLANs be isolated and the upstream port promiscuous).

When PSPF is enabled on the standalone AP then on the switch “protected port” should be enabled to prevent clients from seeing each other data.

5.7   IPS

WLC 4.0 allows the integration of an LWAPP-based WLAN system with the Cisco IDS/IPS product line running software 5.0 or later. The goal is to allow the Cisco IDS/IPS system to instruct the WLCs to block certain clients from access to wireless networks when an attack is detected anywhere from Layer 3 through Layer 7 that involves the client in consideration.

  • Up to five IDS Sensors can be configured on a WLC.
  • Each configured IDS Sensor is identified by its IP address or qualified network name and authorization credentials.
  • Each IDS Sensor can be configured on a controller with a unique query rate in seconds.

A shun request from an IDS Sensor is distributed throughout the entire mobility group of the controller that retrieves the request from the IDS Sensor.

IPS 4100
4100 IPS 5.0 contains over 1000 built-in default signatures. Supports about 2000 attack signatures

5.8   Access Lists

On the WLC ACLs behave differently than on a Cisco Router:

  • There is only a single ACL per interface (NOT two, i. e. per direction)
  • And each ACL entry (ACE) can either check the inbound (upstream) or outbound (downstream) direction
  • Hence, for every permit access rule you must also consider and permit the return traffic

ACLs can be applied:

  • On a WLAN (i. e. SSID)
  • On a VLAN interface
  • On the CPU (recommended against DoS; e. g. malicious HTTPS request through a VLAN interface against the CPU)

You can configure up to 64 ACLs with 64 entries each.

6   ACS Issues

6.1   Connectivity

When either the IP address of the WLAN Controller s incorrect on the AAA Server or the Shared Secret on the controller is different than on the AAA server the error “Unknown Network Access Server” is shown in the ACS log file.

6.2   Radius Attributes for VLAN Assignment

The RADIUS user attributes used for the VLAN ID assignment are:

  • IETF 64 (Tunnel Type) - Set this to VLAN.
  • IETF 65 (Tunnel Medium Type) - Set this to 802.
  • IETF 81 (Tunnel Private Group ID) - Set this to the VLAN ID.
VLAN-Tag
This attribute indicates the group ID for a particular tunneled session, and is also known as the Tunnel-Private-Group-ID attribute, type - 81
Interface-Name
This attribute indicates the VLAN Interface a client is to be associated to. Type 26 = Vendor Specific

6.3   Scalability

ACS 4.0 supports from 10,000 to 300,000 internal users per server

7   Security Site Survey

8   Config summary: ACS

9   Config summary: WLC

9.1   Which EAP method?

There are lots of EAP methods today. Some of them are regarded secure or rather insecure, depending on the circumstances.

However, nobody gets fired when implementing the following EAP methods:

  • EAP-TLS (complicated and slow)
  • PEAP (Supported by any Windows)
  • EAP-FAST (RFC by Cisco, many features and fast)
  • EAP-TTLS (rarely used)

On the other hand you should NOT use:

  • LEAP (efficient dictionary attacks possible)
  • EAP-MD5 (same as above plus unidirectional authentication only)

9.2   OTP and Smartcards

On the WLC the default timeout for the EAP identity request is only 1 second. Most users are not able to enter a one-time password or passphrase in that time (but you might give them a try).

Therefore extend that timeout:

(wlc) > config advanced eap identity-request-timeout 30

(Also on autonomous APs the timeout is 30 seconds by default.)

9.3   Client Exclusion Policies

On the WLC configure the maximum number of authentication attempts and how long an excluded client must wait until he/she may reauthenticate.

9.4   Windows clients

  • If you use the native Windows supplicant: Use at least Windows XP SP2 (and the latest hotfixes). There are still some bugs in there.

9.5   Rogue AP detection

  • Use AP authentication. When enabled all RRM frames (sent by the APs to each other) are protected by a cryptographically protected checksum. The RF-Group is used as shared secret (so keep it secret!) and additionally a time stamp is included. Therefore configure a NTP server.
  • Consider MFP version 1 (infrastructure). It might be possible that some clients have problems with that (although they should not) in which case disable it again. MFPv1 is used to authenticate management traffic but only the only the neighboring APs will check the authentication code (i. e. the clients should ignore this information). MFPv1 helps the AP to detect rogue AP attacks much quicker.
  • Enable RLDP - this allows the WLC to discover whether the rogue AP is connected to the same LAN

9.6   Wireless Protection Policies

These are some additional optional security settings on the WLC:

  • Validate SSIDs - If a rogue SSIDs matches one of the controllers SSIDs an alarm is sent.

9.7   Radius Server

The default RADIUS timeout is 2 seconds. This might be too short in case

  • The RADIUS server forwards the request to an external server
  • EAP-TLS is used

Therefore increase this value to e. g. 5 seconds.

Check this with:

(wlc) > show radius summary

(wlc) > config radius auth retransmit-timeout 1 5  ### first value is server index

9.8   NTP

You should provide a NTP server to synchronize the controllers.

Especially you really need NTP when:

  • You use MFP or RRM-based AP authentication
  • SNMPv3
  • Location-based services

9.9   IDS and IPS

Also use external IDS sensors.

Note that external IDS sensors:

  • Only check IP packets (not WLAN frames).
  • Can apply thousands of signatures
  • Can basically detect and stop all "normal" attacks, not specifically WLAN related

Configuration:

  1. Tell the WLC which IDS/IPS system it should connect to. Provide login credentials.
  2. Configur a query interval (e. g. 10 seconds, default is 60 seconds).
  3. Check the state checkbox and provide the 40-byte fingerprint (format: deadbeef01234... no colons!)
  4. The WLC wil register with that IDS/IPS via port 443 and query it for shunned clients.

Up to five sensors can be configured.

Same on the console:

> config wps cids-sensor add <index> <ip_address> <username> <password>
> config wps cids-sensor interval <index> <interval>
> config wps cids-sensor fingerprint <index> sha1 <fingerprint>
> config wps cids-sensor enable <index>

> show wps cids-sensor summary

The default block time is 30 minutes.