Table 3-1 802.11 Standards

Figure 3-1 illustrates the 802.11 MAC frame format, including the control frame information.

Figure 3-1 802.11 Frame Format

There are three types of frames defined in the standard:

Control frame: This type of frame sets up data exchanges and facilitates the data frames.

Management frame: This type of frame facilitates WLAN connectivity, authentication, and status.

Data frame: This type of frame handles station data between the transmitter and receiver.

Figure 3-2 Station and WAP Connection Process

The following steps are involved in the association and authentication process:

Step 1. Beacon frames are transmitted periodically to announce the presence of a WLAN and contain all information about one or more Service Set Identifiers (SSIDs), data rates, channels, security ciphers, key management, and so on.

Step 2. The STA sends a probe request.

Step 3. The AP sends a probe response to the STA.

Step 4. The STA sends an authentication request frame to the AP. (Note that this assumes Open Authentication.)

Step 5. The AP send an authentication response frame to the STA.

Step 6. The STA sends an association request to the AP with security.

Step 7. The AP send an association response frame to the STA.

WLAN management for centrally creating SSIDs and associated settings

Radio resource management (RRM), which includes the following:

Transmit power control (TPC), which sets the transmit power of each AP to maximize the coverage and minimize co-channel interference

Dynamic channel assignment (DCA), which evaluates and dynamically manages channel assignments

Coverage hole detection (CHD), which detects coverage holes and mitigates them

Mobility management for managing roaming between APs and controllers

Access point configuration

Security settings and wireless intrusion prevention system (wIPS) capabilities

Network-wide quality of service (QoS) for voice and video

Operations and troubleshooting

RFC 4564 defines the objectives for the CAPWAP protocol.

RFC 5418 covers threat analysis for IEEE 802.11 deployments.

RFC 5415 defines the CAPWAP protocol specifications.

CAPWAP carries control and data traffic between the AP and the WLC. The control plane is Datagram Transport Layer Security (DTLS)–encrypted and uses UDP port 5246. The data plane is optionally DTLS encrypted and uses UDP port 5247. The CAPWAP state machine, which is used for managing the connection between AP and controller, is shown in Figure 3-3.

Figure 3-3 CAPWAP State Machine

After an AP gets an IP address using DHCP or uses a previously assigned static IP address, the AP uses one of the following methods to connect to a WLC.

Layer 3 CAPWAP discovery: This feature can be enabled on different subnets from the access point and uses either broadcast IPv4 or IPv6 addresses and UDP packets. Any WLC that is Layer 2 adjacent to the AP will respond to the request.

CAPWAP multicast discovery: Broadcast does not exist in IPv6 addresses. An access point sends a CAPWAP discovery message to all of the controller’s multicast addresses (FF01::18C). The controller receives the IPv6 discovery request from the AP only if it is in the same Layer 2 segment and sends back the IPv6 discovery response.

Locally stored controller IPv4 or IPv6 address discovery: If the access point was previously associated to a controller, the IPv4 or IPv6 addresses of the primary, secondary, and tertiary controllers are stored in the access point’s nonvolatile memory. This process of storing controller IPv4 or IPv6 addresses on an access point for later deployment is called priming the access point.

DHCP server discovery using option 43: DHCP option 43 provides controller IPv4 addresses to the access points. Cisco switches support a DHCP server option that is typically used for this capability.

DHCP server discovery using option 52: DHCP option 52 allows an AP to discover the IPv6 address of the controller to which it connects. As part of the DHCPv6 messages, the DHCP server provides the controller’s management with an IPv6 address.

DNS discovery: The AP can discover controllers through your DNS server. You must configure your DNS server to return controller IPv4 and IPv6 addresses in response to CISCO-LWAPP-CONTROLLER.localdomain or CISCO-CAPWAP-CONTROLLER.localdomain, where localdomain is the access point domain name.

It is recommended for predictability and stability that you manually insert the primary, secondary, and tertiary controllers into Wireless > Access Points > All APs > Details for AP Name > High Availability, as shown in Figure 3-4. This is recommended regardless of the discovery method the AP uses.

Figure 3-4 Manual WLC Definition

You may also define backup WLCs for all APs by going to Wireless > Access Points > Global Configuration, as shown in Figure 3-5. You can configure primary and secondary backup controllers for all access points (which are used if primary, secondary, or tertiary controllers are not responsive) in this order: primary, secondary, tertiary, primary backup, and secondary backup.

Figure 3-5 WLC Primary and Secondary Definitions for all APs

Local: This is the default (unless you are running a flex controller) and most commonly deployed mode. The AP uses its CAPWAP tunnel for data forwarding and management (authentication, roaming, and so on). All client traffic is centrally switched by the controller, meaning the controller forwards the traffic from its data interfaces. Lightweight Access Points (LAPs) are sometimes referred to as “dumb” APs, primarily due to the fact that they do very little thinking on their own when in local mode.

FlexConnect: This mode is typical for branch and remote office deployments. It allows for central (at the WLC) or local (at the AP) switched traffic. More details can be found in the next session, “FlexConnect Access Points.”

Bridge: This mode is for using the AP to connect to a root AP.

SE-Connect: This mode allows you to connect to a spectrum expert, and it allows the access point to perform spectrum intelligence.

Monitor: This mode is the monitor-only mode.

Sniffer: The access point starts sniffing the air on a given channel. It captures and forwards all the packets from the clients on that channel to a remote machine that runs Airopeek or Wireshark (packet analyzers for IEEE 802.11 wireless LANs). It includes information on the time stamp, signal strength, packet size, and so on.

Rogue Detector: This mode monitors the rogue APs on the wire. It does not transmit or receive frames over the air or contain rogue APs.

Access points also have an option to configure the AP submode:

wIPS: The AP is in local, FlexConnect, or monitor mode, and the wIPS submode is configured on the access point.

None: The AP is in local or FlexConnect mode, and the wIPS submode is not configured on the AP.

Locally switched WLANs map wireless user traffic to VLANs to an adjacent switch by using 802.1Q trunking. If desired, one or more WLANs can be mapped to the same local 802.1Q VLAN. All AP control/management-related traffic is sent to the centralized WLC separately using CAPWAP.

Central switched WLANs use CAPWAP to tunnel both the wireless user traffic and all control traffic to the centralized WLC, where the user traffic is mapped to a dynamic interface/VLAN on the WLC. This is the normal CAPWAP mode of operation.

On FlexConnect access points, two types of WLANs can be configured:

Connected mode: The WLC is reachable. In this mode, the FlexConnect AP has CAPWAP connectivity with its WLC.

Standalone mode: The WLC is unreachable. The FlexConnect AP has lost or failed to establish CAPWAP connectivity with its WLC.

You can have one WLAN that is centrally switched (for example, for a guest) and still have a locally switched WLAN (for example, for an employee). When the FlexConnect AP goes into standalone mode, the locally switched WLAN still functions, and the centrally switched WLAN fails.

FlexConnect groups allow you to group together APs in a branch or remote office that share common configuration items, such as the following:

Local/backup RADIUS servers’ IP/keys

Local user and EAP authentication

Image upgrade

ACL mappings, including AAA VLAN-ACL mappings and WLAN-ACL mappings

Central DHCP settings

WLAN-VLAN mappings, which allows override of the WLAN VLAN/interface for the group

WLAN-AVC mappings

Figure 3-6 illustrates some of the options configurable for FlexConnect groups.

Figure 3-6 FlexConnect Groups

FlexConnect ACLs allow for filtering of traffic on FlexConnect APs and groups. The same configuration options exist for FlexConnect ACLs as for regular ACLs.

Figure 3-7 Guest Anchor Controller

When building a connection from a foreign controller to an anchor controller, IP port 97 for EoIP packets and UDP port 16666 for mobility control and new mobility data must be opened bidirectionally on any firewalls or packet filtering devices.

To create a guest anchor controller, perform the following steps:

Step 1. Go to Controller > General > Default Mobility Domain Name and RF Group Name and ensure that the anchor and foreign WLC are in different mobility groups (see Figure 3-8).

Figure 3-8 Mobility Group Configuration

Step 2. Go to Controller > Mobility Management > Mobility Groups > New and add the anchor controller to the foreign controller and add the foreign controller to the anchor controller mobility group members (see Figures 3-9 and 3-10).

Figure 3-9 Adding a Mobility Group Member

Figure 3-10 Configuring a Mobility Group Member

Step 3. Go to Controller > Interfaces > New and add a VLAN on the anchor controller for guest users.

Step 4. Go to WLANs > Mobility Anchors > New and configure the WLAN on the anchor WLC’s mobility anchor to be local. Figures 3-11 and 3-12 show where to add the local mapping on the anchor WLC.

Figure 3-11 Configuring a Mobility Anchor on the WLAN

Figure 3-12 Mobility Anchor Create on the Anchor Controller

Step 5. Add the anchor controller’s IP to the foreign controllers as shown in Figure 3-13.

Figure 3-13 Mobility Anchor Created on the Foreign Controller

One guest anchor controller can terminate up to 71 EoIP tunnels from internal WLAN controllers. This capacity is the same across models of the Cisco WLC except the 2504. The 2504 controller can terminate up to 15 EoIP tunnels. More than one guest anchor controller can be configured if additional tunnels are required. EoIP tunnels are counted per WLAN controller, independently of the number of tunneled WLANs or SSIDs in each EoIP.

WEP was found to be insecure because of its relatively short IVs and static keys. The RC4 encryption algorithm has nothing to do with the major flaws. By having a 24-bit IV, WEP eventually uses the same IV for different data packets. For a large busy network, this reoccurrence of IVs can happen very quickly, resulting in the transmission of frames having keystreams that are too similar. If a malicious person collects enough frames based on the same IV, the individual can determine the keystream or the shared secret key. This, of course, leads to the hacker decrypting any of the 802.11 frames.

Key mixing function: TKIP combines the secret root key with the IV before passing it on to RC4.

Sequence counter: TKIP uses this counter to protect against replay attacks, in which valid data transmission is repeated maliciously.

Message integrity check (MIC): A 64-bit MIC is able to protect both the data payload and the header of the packet.

Even with the additional levels of security it provides over WEP, WPA is considered obsolete and superseded by WPA2.

WPA2 offers a higher level of security than WPA because AES offers stronger encryption than RC4, and CCMP is superior to TKIP. WPA2 creates fresh session keys on every association. The encryption keys that are used for each client on the network are unique and specific to that client. Ultimately, every packet that is sent over the air is encrypted with a unique key. Cisco recommends that customers transition to WPA2 as soon as possible.

Enterprise authentication, or 802.1X, is the de facto standard for almost all businesses and organizations. 802.1X allows for individual user visibility (for example, John Smith is connected to AP2 on the Employee SSID) and mutual authentication through authentication type, such as Extensible Authentication Protocol Transport Layer Security (EAP-TLS). RADIUS is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) and is responsible for determining whether a user or device is authorized to connect to the WLAN. Authentication and validation of the RADIUS server is helpful in preventing attacks such as evil twin attacks. In this type of attack, a rogue Wi-Fi access point that appears to be legitimate because it mirrors the enterprise SSID is set up to sniff wireless traffic or steal credentials.

The WLC allows you to configure either PSK or 802.1X for each WLAN or SSID, as shown in Figure 3-14.

Figure 3-14 Configuring PSK Versus 802.1X

802.11r is the IEEE standard for fast roaming. FT introduced a new concept of roaming where the handshake with the new AP is done even before the client roams to the target AP. The initial handshake allows the client and APs to do Pairwise Transient Key (PTK) calculation in advance, thus reducing roaming time. The pre-created PTK keys are applied to the client and AP when the client does the re-association request/response exchange with the new target AP. 802.11r provides two ways of roaming:

Over-the-air: With this type of roaming, the client communicates directly with the target AP using IEEE 802.11 authentication with the FT authentication algorithm.

Over-the-DS (distribution system): With this type of roaming, the client communicates with the target AP through the current AP. The communication between the client and the target AP is carried in FT action frames between the client and the current AP and is then sent through the controller.

Roaming is configured per WLAN in the Fast Transition section, as shown in Figure 3-15.

Figure 3-15 Roaming Configuration with Fast Transition

You also need to use FT 802.1X or FT PSK in the Authentication Key Management section for the Layer 2 security in order for FT to work correctly.

To create a new WLAN go to WLANs > Create New > Go. Then, as shown in Figure 3-16, select the type (typically WLAN), create a profile name, add an SSID name, and select the ID.

Figure 3-16 New SSID

After clicking Apply to create the new WLAN, the next step is to choose an interface to put the clients on after connection is made to the WLAN. Figure 3-17 illustrates selecting the employee interface.

Figure 3-17 Selecting an Interface for a WLAN

When Security is selected, the default settings already have WPA2 with AES for encryption and 802.1X for AKM. These are the recommended options for Layer 2 security. The next step is to reference the correct RADIUS servers on the AAA Servers page, which is shown in Figure 3-18.

Figure 3-18 Select RADIUS Authentication and Accounting Servers

The advanced options of the WLAN offer a lot of individual configuration items. Following is a list of the most import ones for securing a WLAN:

Allow AAA Override: Allows the VLAN, QoS, and ACLs to be assigned by the RADIUS server and override the settings on the WLAN. The recommendation is for this setting to be enabled for deployments that integrate with ISE.

Override Interface ACL: This option allows you to override the interface ACL and apply an ACL that is specific to the WLAN. Normally, this feature is not used.

URL ACL: This option allows you to apply a URL ACL to the WLAN. This allows organizations to develop a blacklist of URLs for the WLAN and apply it before reaching the network.

P2P Blocking Action: Selecting Drop causes the Cisco WLC to discard the P2P packets. This is very useful where you want to isolate all traffic between users on the WLAN. Selecting Forward-UpStream causes the packets to be forwarded on the upstream VLAN. The device above the Cisco WLC decides what action to take regarding the packet. If you have a router with ACLs or a firewall, the external device now can control what types of traffic can be forwarded between clients. For example, you might want to allow Jabber messages and voice but not MS-RPC traffic between wireless users.

Client Exclusion: This option allows you to enable or disable the timeout for disabled client machines. Client machines are disabled by their MAC address. This option is normally enabled. For more information, review the “Client Exclusion” section, later in this chapter.

DHCP Addr. Assignment: This option requires all WLAN clients to obtain IP addresses from the DHCP server. This prevents clients from assigning their own static IP addresses.

MFP Client Protection: The default, Optional, is normally left selected because MFP on the client requires Cisco Compatible Extensions (CCX) to be supported on the client. For more information, review the “Management Frame Protection” section, later in this chapter.

NAC State: ISE NAC is the recommended setting for deployments with ISE.

RADIUS Client Profiling: This allows the WLC to send up RADIUS accounting information about the client for ISE to profile the connected clients. If you are using ISE, this is normally enabled.

Local Client Profiling: This allows the WLC to learn what type of device is connecting to the WLAN. Normally, you should enable both DHCP and HTTP profiling, regardless of whether or not RADIUS profiling is enabled.

FlexConnect: If you are doing a FlexConnect deployment, you need to review and configure this set of options, which includes everything from local switching and authentication to DHCP processing.

Figure 3-19 illustrates some of these advanced settings.

Figure 3-19 Advanced WLAN Settings

How does any organization deal with the rogue AP threat? By detecting, classifying, and mitigating rogue APs.

Off-channel scanning: This operation, performed by local mode and FlexConnect (in connected mode) APs, uses a time-slicing technique that allows client service and channel scanning using the same radio. By going off channel for a period of 50 milliseconds every 16 seconds, the AP, by default, spends only a small percentage of its time not serving clients.

Monitor mode scanning: This operation, which is performed by monitor mode and adaptive wIPS monitor mode APs, uses 100% of the radio’s time for scanning all channels in each respective frequency band. This allows for greater speed of detection and enables more time to be spent on each individual channel. Monitor mode APs are also far superior at detecting rogue clients as they have a more comprehensive view of the activity occurring in each channel.

Any AP not broadcasting the same RF group name or part of the same mobility group is considered a rogue.

Another way to detect rogue APs is to use Rogue Location Discovery Protocol (RLDP). Rogue detectors are used to identify whether a rogue device is connected to the wired network. An AP connects to a rogue AP as a client and sends a packet to the controller’s IP address. This works only with open rogue access points. Figure 3-20 shows the options for selecting which APs can use RLDP.

Figure 3-20 RLDP Access Point Selection

An organization can make an AP operate as a rogue detector full time by selecting Rogue Detector as the AP mode and placing it on a trunk port so that it can hear all wired-side connected VLANs. It proceeds to find the clients on the wired subnet on all the VLANs. The rogue detector AP listens for Address Resolution Protocol (ARP) packets in order to determine the Layer 2 addresses of identified rogue clients or rogue APs sent by the controller. If a Layer 2 address that matches is found, the controller generates an alarm that identifies the rogue AP or client as a threat.

To create a rogue rule, go to Security > Wireless Protection Policies > Rogue Policies > Rogue Rules > Add Rule. For example, Figures 3-21 and 3-22 illustrate the creation of a rogue rule for a friendly classification for a coffee shop SSID and RSSI minimum of –80 dBm.

Figure 3-21 Adding a New Rogue Rule

Figure 3-22 Friendly Rogue Rule with SSID and RSSI Criteria

Another popular rule looks for rogue APs that are impersonating your SSID. Figure 3-23 shows a rule that matches a managed SSID (that is, an SSID that is added to the controller) and has a minimum RSSI of –70 dBm.

Figure 3-23 Malicious Rogue Rule with Managed SSID and RSSI Criteria

You can manually classify SSIDs as friendly by adding the MAC address of the AP to Security > Wireless Protection Policies > Rogue Policies > Friendly Rogue.

By default, all access points are unclassified unless you create rules, manually set the MAC address to friendly, or manually classify them under Monitor > Rogues > Unclassified Rogue APs. Figure 3-24 shows how an unclassified AP can be manually classified as friendly or malicious.

Figure 3-24 Manually Classify a Rogue AP

When configuring containment (in Security > Wireless Protection Policies > Rogue Policies > General), you must set a rogue detection security level to support containment:

Low: Basic rogue detection for small-scale deployments. Auto containment is not supported for this security level.

High: Basic rogue detection and auto containment for medium-scale or less-critical deployments. RLDP is disabled for this security level.

Critical: Basic rogue detection, auto containment, and RLDP for highly critical deployments.

Custom: Customized rogue policy parameters.

The Auto Contain section of the Rogue Policies page gives options on the types of events/rogues that warrant auto containment. The Auto Containment Level setting allows an administrator to configure how many APs will be used for auto containment; if Auto is selected, the ASA dynamically determines the appropriate number of APs to use. Rogue on Wire, Using Our SSID, Valid Client on Rogue AP, and AdHoc Rogue AP are all configurable items for enabling auto containment. Figure 3-25 illustrates a sample configuration that uses monitor mode APs to provide auto containment of some of the event types.

Figure 3-25 General Rogue Policy and Containment Configuration

If a malicious SSID or criterion is known in advance, a rule can be specified to match and contain it, as illustrated in Figure 3-26.

Figure 3-26 Malicious Rogue Rule with SSID Criteria

Also, you can manually contain an AP the same way you would manually classify rogue APs.

The list of default signatures is illustrated in Figure 3-27 and can be found by going to Security > Wireless Protection Policies > Standard Signatures.

Figure 3-27 Wireless IDS Signatures

When the ID of a signature is clicked, the details of the signature, including frequency and data pattern to match, are shown. Figure 3-28 shows the NetStumbler generic signature as an example.

Figure 3-28 NetStumbler Generic Signature Detail

Custom signatures are displayed in the Custom Signatures window. You can configure custom IDS signatures or bit-pattern matching rules to identify various types of attacks in incoming 802.11 packets by uploading them to the controller. You do this at Commands > Download File by selecting Signature File and specifying the transfer method and filename. Example 3-1 shows an example of a signature in text format that could be uploaded as a custom signature.

Name = "NetStumbler generic", Ver = 0, Preced= 16, FrmType = data, Pattern =
0:0x0108:0x03FF, Pattern = 27:0x00601d:0xFFFFFF, Pattern = 30:0x0001:0xFFFF, Freq  = 1, Quiet = 600, Action = report, Desc="NetStumbler"

To see if an IDS signature is alerting, you can go to Security > Wireless Protection Policies > Signature Events Summary, as shown in Figure 3-29.

Figure 3-29 Signature Events Summary

Figure 3-30 Adaptive Wireless Intrusion Prevention System

The following important protocols are needed for the adaptive wIPS architecture to function:

Network Mobility Services Protocol (NMSP): This protocol is used for communication between WLCs and the MSE. In the case of a wIPS deployment, this protocol provides a pathway for alarm information to be aggregated from controllers to the MSE and for wIPS configuration information to be pushed to the controller. This protocol is encrypted.

Simple Object Access Protocol (SOAP/XML): This protocol provides a method of communication between the MSE and PI. This protocol is used to distribute configuration parameters to the wIPS service running on the MSE.

Simple Network Management Protocol (SNMP): This protocol is used to forward wIPS alarm information from the MSE to the PI. It is also utilized to communicate rogue access point information from a WLC to the PI.

In order to configure adaptive wIPS, a profile must be configured on PI and pushed to the controllers and MSE. Figure 3-31 shows the details of a wIPS profile on PI.

Figure 3-31 Prime Infrastructure wIPS Profile Configuration

An adaptive wIPS solution has several enhancements over the WLC’s wIDS solution. First, it provides additional threat identification and protection:

Customizable severities: Severity of alarms is set based on the security threat level and operation impact on a wireless production network. For example, most DoS attacks may have an operational impact on the wireless infrastructure. Thus, their severity is set to Critical by default.

Capture attack forensics: A toggle-based packet capture facility provides the ability to log and retrieve a set of wireless frames. This feature is enabled on a per-attack basis from within the wIPS profile configuration of PI.

Location integration: With MSE location, administrators can easily find an attacker on the floorplan.

Consolidation of alerts: PI can provide a unified view of security alerts from multiple controllers and MSE.

Access points are responsible for detecting threats with signatures. The following options exist to provide wIPS capabilities for enterprise deployments:

Enhanced local mode (ELM): This mode allows local or FlexConnect APs to run an AP submode of a wIPS and operates effectively for on-channel (the channel the AP is currently servicing clients on) attacks, without any compromise to performance in terms of data, voice, and video clients and services. ELM does scan for off-channel (other channels the AP is not servicing clients on) attacks, but it is considered best effort.

Dedicated monitor mode APs: This allows for 100% channel scanning but requires an organization to deploy an overlay network to passively listen for threats.

Wireless Security and Spectrum Intelligence (WSSI) module: For organizations running 3600/3700 series APs, instead of deploying extra APs and creating an overlay network, the WSSI module allows you to install a module into the local/FlexConnect AP, whose sole responsibility is to scan all channels for threats and spectrum intelligence.

2800/3800 series access points: These newer APs contain a flexible radio architecture. In a sense, the AP is a tri-band radio as it contains a dedicated 5 GHz radio to serve clients and another flexible radio (known as an XOR radio) that can be assigned the wIPS function within the network.

Non-Wi-Fi transmitter or RF jammer detection and location

Non-Wi-Fi bridge detection and location

Non-Wi-Fi access point detection and location

Layer 1 DoS attack location and detection (Bluetooth, microwave, and so on)

Excessive 802.11 association failures: Clients are excluded on the sixth 802.11 association attempt after five consecutive failures.

Excessive 802.11 authentication failures: Clients are excluded on the sixth 802.11 authentication attempt after five consecutive failures.

Excessive 802.11X authentication failures: Clients are excluded on the fourth 802.1X authentication attempt after three consecutive failures.

IP theft or reuse: Clients are excluded if the IP address is already assigned to another device.

Excessive web authentication failures: Clients are excluded on the fourth web authentication attempt after three consecutive failures.

Client exclusion can be configured at Security > Wireless Protection Policies > Client Exclusion Policies (see Figure 3-32).

Figure 3-32 Client Exclusion Policies

After the default 60 seconds, clients are able to try to connect again. If the timer is severely increased or a timeout setting of 0 is used, indicating that administrative control is required to reenable the client, then sometimes the users will call the helpdesk to be manually removed from the excluded list. To remove the client from the exclusion list manually, go to Monitor > Clients and click the blue drop-down for the client and then click Remove.

MFP provides security for the otherwise unprotected and unencrypted 802.11 management messages passed between access points and clients.

The MIC component of MFP ensures that a frame has not been tampered with, and the digital signature component ensures that the MIC could have only been produced by a valid member of the WLAN domain.

Infrastructure MFP is configured under AP Authentication Policy, found at Security > Wireless Protection Policies > AP Authentication (see Figure 3-33).

Figure 3-33 AP Authentication Policy

When you enable the AP authentication feature, the access points sending RRM neighbor packets with different RF network names are reported as rogues.

When you enable infrastructure MFP, it is enabled globally for the Cisco WLC. You can enable or disable infrastructure MFP validation for a particular access point or protection for a particular WLAN if MFP is enabled globally for the Cisco WLC.

Client MFP encrypts management frames that are sent between APs and CCXv5 clients so that both the AP and the client can take preventive action by dropping spoofed class 3 management frames (that is, management frames passed between an AP and a client that is authenticated and associated). Client MFP leverages the security mechanism defined by IEEE 802.11i to protect the following types of class 3 unicast management frames: disassociation frames, deauthentication frames, and QoS WMM actions.

Client MFP supplements infrastructure MFP rather than replacing it because infrastructure MFP continues to detect and report invalid unicast frames sent to clients that are not client-MFP capable as well as invalid class 1 and class 2 management frames. Infrastructure MFP is applied only to management frames that are not protected by client MFP. If you require a non-CCXv5 client to associate a WLAN, client MFP should be configured as disabled or optional.

By default, client MFP is optional for a WLAN, but you can set it to Disabled or Required in the WLAN configuration, found at WLAN > SSID Name Edit > Advanced (see Figure 3-34).

Figure 3-34 Client MFP Configuration

The 802.11w protocol applies only to a set of robust management frames that are protected by the PMF service. These include disassociation, deauthentication, and robust action frames. Client protection is achieved by the AP through the addition of cryptographic protection for deauthentication and disassociation frames, thus preventing spoofing of a client in an attack.

PMF configuration is done at WLAN > SSID Name > Edit > Security > Layer 2:

Step 1. Enable PMF by changing PMF from Disabled to Optional or Required (see Figure 3-35).

Step 2. Change the Authentication Key Management setting from PSK or 802.1X to PMF PSK or PMF 802.1X (see Figure 3-36).

Figure 3-35 Enable PMF on the WLAN

Figure 3-36 Enable PMF on Authentication Key Management

Figure 3-37 Management Authentication Priority

Authentication and authorization services are tied to each other. For example, if authentication is performed using RADIUS or a local database, then authorization is not performed with TACACS+. Rather, authorization would use the permissions associated for the user in the local or RADIUS database, such as read-only or read/write, whereas when authentication is performed with TACACS+, authorization is tied to TACACS+.

To add a new RADIUS authentication server, go to Security > AAA > RADIUS > Authentication > New and add the IP address and shared secret and ensure that Management is checked. If the server will be used only for management authentication, ensure that the Network User check box is not selected.

To add a new TACACS+ authentication server, go to Security > AAA > TACACS > Authentication > New and add the IP address and shared secret. Figure 3-38 illustrates a new TACACS+ authentication server being added in a WLC.

Figure 3-38 New TACACS+ Authentication Server

Authorization that is specific to TACACS+ deployment is task-based rather than per- command-based. The tasks are mapped to various tabs that correspond to the seven menu bar items that are currently on the web GUI:

Monitor

WLANs

Controller

Wireless

Security

Management

Command

This mapping is based on the fact that most customers use the web interface rather than the CLI to configure a controller. An additional role for lobby admin management is available for those who need to have lobby admin privileges only. In order for basic management authentication via TACACS+ to succeed, you must configure authentication and authorization servers on the WLC. Accounting configuration is optional. Figure 3-39 illustrates adding a new TACACS+ authorization server in the WLC. The IP address and shared secret must match the authentication server information.

Figure 3-39 New TACACS+ Authorization Server

Accounting occurs whenever a particular user-initiated action is performed successfully. The attributes changed are logged in the TACACS+ accounting server, along with the user ID, the remote host where the user is logged in, date and time, authorization level, and what action was performed and the values provided.

To add a new RADIUS accounting server, go to Security > AAA > RADIUS > Accounting > New and add the IP address and shared secret (the same as the authentication shared secret); also, if the server will only be used for management authentication, ensure that the Network User check box is not selected.

To add a new TACACS+ accounting server, go to Security > AAA > TACACS > Accounting > New and add the IP address and shared secret. Figure 3-40 illustrates adding a new TACACS accounting server in the WLC.

Figure 3-40 New TACACS+ Accounting Server

Figure 3-41 shows how HTTP can and should be disabled on the Management > HTTP-HTTPS page.

Figure 3-41 HTTP-HTTPS Configuration

Telnet is another protocol that is risky to use for management access. Figure 3-42 shows how Telnet can and should be disabled on the Management > Telnet-SSH page.

Figure 3-42 Telnet-SSH Configuration

The management over wireless feature allows you to monitor and configure local controllers using a wireless client. In most cases, wireless users should not be allowed to log in to the WLC. To disable management over wireless, go to Management > Management Via Wireless page and uncheck the box, as shown in Figure 3-43.

Figure 3-43 Management Via Wireless

The safest way to create a CPU ACL is to explicitly deny traffic and/or networks that are not supposed to communicate with the WLC and explicitly allow all other traffic. The following is a logical example (not a real configuration example):

Click here to view code image

deny tcp [CLIENT NETWORKS] [WLC mgmt IP] eq 443
deny tcp [CLIENT NETWORKS] [WLC mgmt IP] eq 22
permit ip any any

To apply the created ACL for IPv4 or IPv6, go to Security > Access Control Lists > CPU Access Control Lists, select Enable CUP ACL, and select the ACL to apply. Figure 3-44 illustrates setting an IPv4 ACL.

Figure 3-44 CPU ACL

By going to Wireless > Access Points > Global Configuration, you can configure the following to help secure the APs (see Figure 3-45):

Login credentials: You can set the username and password to log in directly to an AP through Telnet or SSH.

802.1X supplicant credentials: You can set the username and password the AP will use to perform EAP-FAST 802.1X login on the wired interface.

Global Telnet SSH: You can turn on/off Telnet and SSH login directly to the AP.

Figure 3-45 Access Point Global Configuration

The WLC can also use SGT Exchange Protocol (SXP) to propagate the security group tags (SGTs) assigned to users across network devices that do not have hardware support for Cisco TrustSec. The SXP sends SGT information to the TrustSec-enabled devices or ISE so devices have the appropriate IP-to-SGT mappings. The WLC can send mappings for IPv4 and IPv6 clients. From WLC release 8.3, the SXP on the Cisco WLC is supported for both centrally and locally switched networks. Also, IP-to-SGT mapping can be done on the WLANs for clients that are not authenticated by Cisco ISE. The Cisco WLC is always in SXP Speaker mode, meaning it sends the mappings. SXP can be configured under Security > TrustSec > SXP Config. For locally switched WLANs in local or FlexConnect mode APs, SXP can be configured by going to Wireless > Access Points > All APs > Trusted Security.

WLC release 8.2 introduced the enhanced NetFlow records exporter. NetFlow v9 sends 17 different data records, as defined in RFC 3954, to external third-party NetFlow collectors such as Stealthwatch.

To configure NetFlow, go to Wireless > NetFlow and create an exporter and a monitor. Then under WLAN > Edit > QoS, select the NetFlow monitor.

Figure 3-46 illustrates how the WLC can send NetFlow to Stealthwatch and Stealthwatch can use ISE to quarantine wireless users.

Figure 3-46 Integration with ISE and Stealthwatch

Local policies: Allows administrators to customize Umbrella policies based on user roles. In essence, a user is assigned a role via RADIUS authentication from ISE, and a local policy configuration can map that role to an Umbrella profile on the WLC. This allows administrators to customize policies for different user roles in their organization; for example, employees, contractors, and guests can all have different policies.

Per WLAN/AP group: Administrators can statically map an entire WLAN or AP group to an Umbrella profile.

Along with the profile mappings, there are three Umbrella modes that can be used, depending on the deployment:

Force mode: This mode, enabled by default, is enforced per WLAN and forces all DNS traffic to query Umbrella.

Ignore mode: WLC honors the DNS server used by the client; it could be an Umbrella server or an enterprise/external DNS server.

Copy mode: All Internet-bound DNS traffic is forwarded to an Umbrella cloud without any policy options (no blocking/redirection).

For detailed information on Umbrella, see Chapter 9.