| 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!
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!
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:
Remember:
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.
'WEPplus' = WEP with avoidance of weak IVs
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.
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:
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.
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.
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'
MFP Version 1 is called Infrastructure MFP, in which APs validate management packets emitted by other APs. Only infrastructur devices use MFP version 1. Clients simply cannot interpret the new MFP IE and ignore it. Actually a MIC IE is inserted at the end of each management frame. Other APs validate such frames or generate an IDS event.
IE contains:
- Timestamp (therefore use NTP on all WLCs - the time window is 2 seconds only!)
- Sequence number
- MIC
Two configuration options:
- Protection: Add MIC
- Validation: Check MIC and generate alert
MFP Version 2 is called Client MFP and is supported since WLC version 4.1. Requires CCXv5 compatible clients and WPA2 for key management. Management frames are encrypted like data frames via TKIP or AES.
Configuration steps:
Interface configuration: check Guest LAN checkbox.
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.
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.
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.
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.
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.
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.
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.
On the WLC ACLs behave differently than on a Cisco Router:
ACLs can be applied:
You can configure up to 64 ACLs with 64 entries each.
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.
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.
ACS 4.0 supports from 10,000 to 300,000 internal users per server
Under Network Settings enter the Management Interface of the WLC as AAA Client. Select RADIUS Airespace as protocol.
Import a certificate or create a self-signed certificate (> System Settings > Import ACS Certificate) You need this certificate for PEAP and the (optional) EAP-FAST authenticated automatic PAC provisioning.
It is recommended (but not required) to install the corresponding Root-Certificate on the WLAN client so that the client can verify the signature of the ACS certificate
Under System Settings > Global Authentication Setup enable PEAP and/or EAP-FAST. Disable LEAP, EAP-MD5.
Click on the EAP-FAST configuration page:
- Leave the TTL values - they are ok.
- Enter an Issuer-ID - this is mandatory! You can choose any name for your ACS but it should be reasonable and unique in your network (ideally unique among all networks the client might visit!)
- Allow authenticated automatic PAC provisioning but you should NOT require the client to have a certificate
- Optionally allow anonymous provisioning also but be aware that MITM attacks might be possible -- however this is unlikely as phase zero only used once (or a few times) per client. Therefore avoid this option if possible.
Under Security configure the IP and shared secret of the ACS. Leave the port 1812 for authentication. Consider to use the ACS also for accounting - this supports troubleshooting and forensic analysis.
Configure a VLAN interface for the secure users.
Under WLAN add a new WLAN:
- Enable it and select the VLAN Interface
- Disable 2.4 GHz or 5 GHz if you don't need it
- Select WPA2, 802.1x, AES as layer 2 security method
- Select the authentication server (and also the accounting server)
- By default the SSID is broadcasted. Don't change this.
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:
On the other hand you should NOT use:
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.)
On the WLC configure the maximum number of authentication attempts and how long an excluded client must wait until he/she may reauthenticate.
These are some additional optional security settings on the WLC:
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
You should provide a NTP server to synchronize the controllers.
Especially you really need NTP when:
Also use external IDS sensors.
Note that external IDS sensors:
Configuration:
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.