Chapter 29
The ArubaOS Wireless Intrusion Prevention (WIP) features and configurations are discussed in this chapter. WIP offers a wide selection of intrusion detection and protection features to protect the network against wireless threats. Like most other security-related features of the Aruba network, the WIP configuration is done on the master controller in the network.
To use most of the features described in this chapter, you must install a Wireless Intrusion Protection (RFprotect) license on all controllers in your network. If you install a RFprotect license on a master controller only, an AP or AM terminated on a local controller will not provide the WIP features.
These features do not require an RFprotect license:
-
Rogue AP classification techniques other than AP classification rules
-
Rogue containment
-
Wired containment
-
Wireless containment without Tarpit
For details on commands see the ArubaOS Command Line Interface Reference document.
This chapter contains the following sections:
The WebUI’s reusable, intuitive, user-friendly Wizard provides steps to enable, define, or change:
-
Integrated vs Overlay WLAN/WIP options
-
Rules-based rogue classification
-
Detection features for attacks against infrastructure
-
Detection features for attacks against WLAN clients
-
Protection features for attacks against infrastructure
-
Protection features for WLAN clients
Figure 112 displays the WIP Wizard layout. Highlighting one of the previously configured rules reveals drop down menus for changing values. Note that the reusable wizard includes robust online Help.
Apply the intrusion detection mechanisms for detecting attacks against your infrastructure and clients (see Figure 113). You can either set the detection level to automatically enable the appropriate detection mechanisms or customize the settings for infrastructure and client attacks. Use the slider to select one of the detection levels for the infrastructure and clients:
-
High—Enables all the detection mechanisms applicable to your infrastructure including all the options of low and medium level settings.
-
Medium (Default)—Enables some important detection mechanisms for your infrastructure. This includes all the options of the low level settings.
-
Low—Enables only the most critical detection mechanisms for your infrastructure.
-
Off—Disables all the detection mechanisms.
To enable custom settings, click the Allow custom settings link to manually enable or disable the detection mechanisms for your clients. To revert to the standard settings from the custom settings mode, click the Revert to standard settings link.
Figure 113 WIP Wizard’s Intrusion Detection
Apply the intrusion protection mechanisms for your infrastructure and clients (see Figure 114). You can set the protection level to automatically enable the appropriate protection mechanisms or customize the settings for your infrastructure and clients.
Use the slider to select one of the protection levels for the infrastructure:
-
High—Enables all the protection mechanisms applicable to your infrastructure including all the options of low and medium level settings.
-
Medium—Enables some important protection mechanisms for your infrastructure including all the options of the low level settings.
-
Low—Enables only the most critical protection mechanisms for your infrastructure.
-
Off (Default)—Disables all the protection mechanisms.
To enable custom settings, click the Allow custom settings link. You can manually enable or disable the protection mechanisms for your infrastructure. To revert to the standard settings from custom settings mode, click the Revert to standard settings link.
Use the slider (see Figure 114) to select one of the following preset protection levels for your clients:
-
High—Enables all the protection mechanisms applicable to your clients including all the options of the low level settings.
-
Low—Enables only the most critical protection mechanisms for your clients.
-
Off (Default)—Disables all the protection mechanisms.
To enable custom settings, click the Allow custom settings link to manually enable or disable the protection mechanisms for your clients. To revert to the standard settings from custom settings mode, click the Revert to standard settings link.
Figure 114 WIP Wizard Intrusion Protection
The Security Summary dashboard, in the Monitoring section of the WebUI, allows you to monitor the detection and protection of wireless intrusions in your network.
The dashboard’s two top tables—Discovered APs & Clients and Events—contain data as links. When these links are selected they arrange, filter, and display the appropriate information in the lower table. For example, if you select the number 10 under the Active APs column (highlighted in yellow in Figure 115) then the bottom table will filter and arrange information about the ten classified Rogue APs. Use the scroll bar at the right to view all ten Rogue APs.
|
|
The term events in this document is meant to include security threats, vulnerabilities, attacks (intrusion or Denial of Service) and other similarly related events. |
The Event table contains data links. Selecting these data links will display information, in the bottom table, related to the Event you selected. Again, remember to use the scroll bar at the right to view all the Events.
Figure 115 WIP Monitoring Dashboard
The most important WIP functionality is the ability to classify an AP as a potential security threat. An AP is considered to be a rogue AP if it is both unauthorized and plugged into the wired side of the network. An AP is considered to be an interfering AP if it is seen in the RF environment but is not connected to the wired network.
While the interfering AP can potentially cause RF interference, it is not considered a direct security threat since it is not connected to the wired network. However, an interfering AP may be reclassified as a rogue AP.
APs and clients are discovered during scanning of the wireless medium, and they are classified into various groups. The AP and client classification definitions are in Table 105 and Table 106.
A discovered AP is classified as a rogue or a suspected rogue by the following methods:
-
Internal heuristics
-
AP classification rules
-
Manually by the user
The internal heuristics works by checking if the discovered AP is communicating with a wired device on the customer network. This is done by matching the MAC address of devices that are on the discovered AP’s network with that of the user’s wired network. The MAC of the device on the discovered AP’s network is known as the Match MAC. The ways in which the matching of wired MACs occurs is detailed in the sections Match Methods and Match Types.
The match methods are:
-
Plus One—The match MAC matches a device whose MAC address’ last bit was one more than that of the Match MAC.
-
Minus One—The match MAC matches a device whose MAC address’ last bit was one less than that of the Match MAC.
-
Equal—The match was against the same MAC address.
-
OUI—The match was against the manufacturer’s OUI of the wired device.
The classification details are available in the ‘Discovered AP table’ section of the ‘Security Summary’ page of the WebUI. The information can be obtained by clicking on the details icon for a selected discovered AP. The information is also available in the command show wms rogue-ap.
-
Eth-Wired-MAC—The MAC addresses of wired devices learned by an AP on its Ethernet interface.
-
GW-Wired-MAC—The collection of Gateway MACs of all APs across the master and local controllers.
-
AP-Wired-MAC—The MAC addresses of wired devices learned by monitoring traffic out of other valid and rogue APs.
-
Config-Wired-MAC—The MAC addresses that are configured by the user typically that of well known servers in the network.
-
Manual—User triggered classification.
-
External-Wired-MAC—The MAC address matched a set of known wired devices that are maintained in an external database.
-
Mobility-Manager—The classification was determined by the mobility manager, AMP.
-
Classification-off—AP is classified as rogue because classification has been disabled causing all non-authorized APs to be classified as a rogue.
-
Propagated-Wired-MAC—The MAC addresses of wired devices learned by a different AP than the one that uses it for classifying a rogue.
-
Base-BSSID-Override—The classification was derived from another BSSID which belongs to the same AP that supports multiple BSSIDs on the radio interface.
-
AP-Rule—A user defined AP classification rule has matched.
-
System-Wired-MAC—The MAC addresses of wired devices learned at the controller.
-
System-Gateway-MAC—The Gateway MAC addresses learned at the controller.
Suspected Rogue Confidence Level
A suspected rogue AP is an AP that is potentially a threat to the WLAN infrastructure. A suspected rogue AP has a confidence level associated with it. An AP can be marked as a suspected rogue if it is determined to be a potentially threat on the wired network, or if it matches a user defined classification rule.
The suspected-rogue classification mechanism are:
-
Each mechanism that causes a suspected-rogue classification is assigned a confidence level increment of 20%.
-
AP classification rules have a configured confidence level.
-
When a mechanism matches a previously unmatched mechanism, the confidence level increment associated with that mechanism is added to the current confidence level (the confident level starts at zero).
-
The confidence level is capped at 100%.
-
If your controller reboots, your suspected-rogue APs are not checked against any new rules that were configured after the reboot. Without this restriction, all the mechanisms that classified your APs as suspected-rogue may trigger again causing the confidence level to surpass their cap of 100%. You can explicitly mark an AP as “interfering” to trigger all new rules to match against it.
AP classification rule configuration is performed only on a master controller. If AMP is enabled via the mobility-manager command, then processing of the AP classification rules is disabled on the master controller. A rule is identified by its ASCII character string name (32 characters maximum). The AP classification rules have one of the following specifications:
-
SSID of the AP
-
SNR of the AP
-
Discovered-AP-Count or the number of APs that can see the AP
Each rule can have up to 6 SSID parameters. If one or more SSIDs are specified in a rule, an option of whether to match any of the SSIDs, or to not match all of the SSIDs can be specified. The default is to check for a match operation.
Each rule can have only one specification of the SNR. A minimum and/or maximum can be specified in each rule and the specification is in SNR (db).
Discovered-AP-Count specification
Each rule can have only one specification of the Discovered-AP-Count. Each rule can specify a minimum or maximum of the Discovered-AP-count. The minimum or maximum operation must be specified if the Discovered-AP-count is specified. The default setting is to check for the minimum discovered-AP-count.
A rule must be enabled before it is matched. A maximum of 32 rules can be created with a maximum of 16 rules active simultaneously. If a rule matches, an AP is classified to:
-
Suspected-Rogue—an associated confidence-level is provided (minimum is 5%)
-
Neighbor
The following mechanism is used for rule matching.
-
When all the conditions specified in the rule evaluate to true, the rule matches.
-
If multiple rules match causing the AP to be classified as a Suspected-Rogue, the confidence level of each rule is aggregated to determine the confidence level of the classification.
-
When multiple rules match and any one of those matching rules cause the AP to be classified as a Neighbor, then the AP is classified as Neighbor.
-
APs classified as either Neighbor or Suspected-Rogue will attempted to match any configured AP rule.
-
Once a rule matches an AP, the same rule will not be checked for the AP.
-
When the controller reboots, no attempt to match a previously matched AP is made.
-
If a rule is disabled or modified, all APs that were previously classified based on that rule will continue to be in the newly classified state.
This section covers Infrastructure and Client Intrusion Detections.
Infrastructure Intrusion Detection
Detecting attacks against the infrastructure is critical in avoiding attacks that may lead to a large-scale Denial of Service (DOS) attack or a security breach. This group of features detects attacks against the WLAN infrastructure, which consists of authorized APs, the RF medium, and the wired network. An authorized or valid-AP is defined as an AP that belongs to the WLAN infrastructure. The AP is either an Aruba AP or a third party AP. ArubaOS automatically learns authorized Aruba APs.
Table 107 presents a summary of the Intrusion infrastructure detection features with their related commands, traps, and syslog identification. Feature details follow the table.
Detect 802.11n 40MHz Intolerance Setting
When a client sets the HT capability “intolerant bit” to indicate that it is unable to participate in a 40MHz BSS, the AP must use lower data rates with all of its clients. Network administrators often want to know if there are devices that are advertising 40MHz intolerance, as this can impact the performance of the network.
Detect Active 802.11n Greenfield Mode
When 802.11 devices use the HT operating mode, they can not share the same channel as 802.11a/b/g stations. Not only can they not communicate with legacy devices, the way they use the transmission medium is different, which would cause collisions, errors and retransmissions.
An ad hoc network is a collection of wireless clients that form a network amongst themselves without the use of an AP. As far as network administrators are concerned, ad hoc wireless networks are uncontrolled. If they do not use encryption, they may expose sensitive data to outside eavesdroppers. If a device is connected to a wired network and has bridging enabled, an ad-hoc network may also function like a rogue AP. Additionally, ad-hoc networks can expose client devices to viruses and other security vulnerabilities. For these reasons, many administrators choose to prohibit ad-hoc networks.
Detect Ad hoc Network Using Valid SSID
If an unauthorized ad hoc network is using the same SSID as an authorized network, a valid client may be tricked into connecting to the wrong network. If a client connects to a malicious ad hoc network, security breaches or attacks can occur.
Fake AP is a tool that was originally created to thwart wardrivers by flooding beacon frames containing hundreds of different addresses. This would appear to a wardriver as though there were hundreds of APs in the area, thus concealing the real AP. An attacker can use this tool to flood an enterprise or public hotspots with fake AP beacons to confuse legitimate users and to increase the amount of processing need on client operating systems.
In AP impersonation attacks, the attacker sets up an AP that assumes the BSSID and ESSID of a valid AP. AP impersonation attacks can be done for man-in-the-middle attacks, a rogue AP attempting to bypass detection, or a honeypot attack.
An AP Spoofing attack involves an intruder sending forged frames that are made to look like they are from a legitimate AP. It is trivial for an attacker to do this, since tools are readily available to inject wireless frames with any MAC address that the user desires. Spoofing frames from a legitimate AP is the foundation of many wireless attacks.
This is the detection of WEP initialization vectors that are known to be weak. A primary means of cracking WEP keys is to capture 802.11 frames over an extended period of time and searching for such weak implementations that are still used by many legacy devices.
In this type of attack, an intruder spoofs a beacon packet on a channel that is different from that advertised in the beacon frame of the AP.
There are fake AP tools that can be used to attack wireless intrusion detection itself by generating a large number of fake clients that fill internal tables with fake information. If successful, it overwhelms the wireless intrusion system, resulting in a DoS.
and
The RF medium can be reserved via Virtual Carrier Sensing using an CTS/RTS transaction. The transmitter station sends a Request To Send (RTS) frame to the receiver station. The receiver station responds with a Clear To Send (CTS) frame. All other stations that receive these RTS and/or CTS frames will refrain from transmitting over the wireless medium for an amount of time specified in the duration fields of these frames.
Attackers can exploit the Virtual Carrier Sensing mechanism to launch a DoS attack on the WLAN by transmitting numerous RTS and/or CTS frames. This causes other stations in the WLAN to defer transmission to the wireless medium. The attacker can essentially block the authorized stations in the WLAN with this attack.
Detect Devices with an Invalid MAC OUI
The first three bytes of a MAC address, known as the MAC organizationally unique identifier (OUI), is assigned by the IEEE to known manufacturers. Often clients using a spoofed MAC address do not use a valid OUI and instead use a randomly generated MAC address.
Detect Invalid Address Combination
In this attack, an intruder can cause an AP to transmit deauthentication and disassociation frames to all of its clients. Triggers that can cause this condition include the use of broadcast or multicast MAC address in the source address field.
Some wireless drivers used in access points do not correctly validate the EAPOL key fields. A malicious EAPOL-Key packet with an invalid advertised length can trigger a DoS or possible code execution. This can only be achieved after a successful 802.11 association exchange.
Some wireless drivers used in access points do not correctly parse the vendor-specific IE tags. A malicious association request sent to the AP containing an IE with an inappropriate length (too long) can cause a DoS and potentially lead to code execution. The association request must be sent after a successful 802.11 authentication exchange.
Detect Malformed Frame-Assoc Request
Some wireless drivers used in access points do not correctly parse the SSID information element tag contained in association request frames. A malicious association request with a null SSID (that is, zero length SSID) can trigger a DoS or potential code execution condition on the targeted device.
Malformed 802.11 authentication frames that do not conform to the specification can expose vulnerabilities in some drivers that have not implemented proper error checking. This feature checks for unexpected values in a Authentication frame.
The IEEE 802.11n HT (High Throughput) IE is used to convey information about the 802.11n network. A 802.11 management frame containing a malformed HT IE can crash some client implementations; potentially representing an exploitable condition when transmitted by a malicious attacker.
Detect Malformed Frame-Large Duration
The virtual carrier-sense attack is implemented by modifying the 802.11 MAC layer implementation to allow random duration values to be sent periodically. This attack can be carried out on the ACK, data, RTS, and CTS frame types by using large duration values. This attack can prevent channel access to legitimate users.
A list of parameters can be configured that defines the characteristics of a valid AP. This feature is primarily used when non-Aruba APs are used in the network since the Aruba controller cannot configure the third-party APs. These parameters include WEP, WPA, OUI of valid MAC addresses, valid channels, and valid SSIDs.
A Windows Bridge occurs when a client that is associated to an AP is also connected to the wired network, and has enabled bridging between these two interfaces.
Wireless bridges are normally used to connect multiple buildings together. However, an attacker could place (or have an authorized person place) a wireless bridge inside the network that would extend the corporate network somewhere outside the building. Wireless bridges are somewhat different from rogue APs in that they do not use beacons and have no concept of association. Most networks do not use bridges – in these networks, the presence of a bridge is a signal that a security problem exists.
Detect Broadcast Deauthentication
A deauthentication broadcast attempts to disconnect all stations in range. Rather than sending a spoofed deauth to a specific MAC address, this attack sends the frame to a broadcast address.
Detect Broadcast Disassociation
By sending disassociation frames to the broadcast address (FF:FF:FF:FF:FF:FF), an attacker can disconnect all stations on a network for a widespread DoS.
NetStumbler is a popular wardriving application used to locate 802.11 networks. When used with certain NICs, NetStumbler generates a characteristic frame that can be detected. Version 3.3.0 of NetStumbler changed the characteristic frame slightly.
If an unauthorized AP (neighbor or interfering) is using the same SSID as an authorized network, a valid client may be tricked into connecting to the wrong network. If a client connects to a malicious network, security breaches or attacks can occur.
Wellenreiter is a passive wireless network discovery tool that is used to compile a list of APs along with their MAC address, SSID, channel, security setting in the vicinity. It passively sniffs wireless traffic and with certain version (versions 1.4, 1.5, and 1.6) sends active probes that target known default SSIDs.
Generally, clients are more vulnerable to attacks than APs. Clients are more apt to associate with a malignant AP due to the client’s driver behavior or to a mis-configured client. It is important to monitor authorized clients to track their associations and to track any attacks raised against the client.
Client attack detection is categorized as:
-
Detecting attacks against Aruba APs clients—An attacker can perform an active DOS attack against an associated client, or perform a replay attack to obtain the keys of transmission which could lead to more serious attacks.
-
Monitoring Authorized clients—Since clients are easily tricked into associating with unauthorized APs, tracking all mis-associations of authorized clients is very important.
An authorized client is a client authorized to use the WLAN network. In ArubaOS, an authorized client is called a valid-client. ArubaOS automatically learns a valid client. A client is determined to be valid if it is associated to an authorized or valid AP using encryption; either Layer 2 or IPSEC.
|
|
Detection of attacks is limited to valid clients and clients associated to valid APs. Clients that are associated as guests using unencrypted association are included in the attack detection. However, clients on neighboring (interfering) APs are not tracked for attack detection unless they are specified as valid. |
Table 108 presents a summary of the client intrusion detection features with their related commands, traps, and syslog identification. Details of each feature follow the table.
The Block ACK mechanism that was introduced in 802.11e, and enhanced in 802.11nD3.0, has a built-in DoS vulnerability. The Bock ACK mechanism allows for a sender to use the ADDBA request frame to specify the sequence number window that the receiver should expect. The receiver will only accept frames in this window.
An attacker can spoof the ADDBA request frame causing the receiver to reset its sequence number window and thereby drop frames that do not fall in that range.
ChopChop is a plaintext recovery attack against WEP encrypted networks. It works by forcing the plaintext, one byte at a time, by truncating a captured frame and then trying all 256 possible values for the last byte with a corrected CRC. The correct guess causes the AP to retransmit the frame. When that happens, the frame is truncated again.
Detect Disconnect Station Attack
A disconnect attack can be launched in many ways; the end result is that the client is effectively and repeatedly disconnected from the AP.
To authenticate wireless clients, WLANs may use 802.1x, which is based on a framework called Extensible Authentication Protocol (EAP). After an EAP packet exchange and the user is successfully authenticated, the EAP-Success is sent from the AP to the client. If the user fails to authenticate, an EAP-Failure is sent. In this attack, EAP-Failure or EAP-Success frames are spoofed from the access point to the client to disrupting the authentication state on the client. This confuses the client’s state causing it to drop the AP connection. By continuously sending EAP Success or Failure messages, an attacker can effectively prevent the client from authenticating with the APs in the WLAN.
Detect FATA-Jack Attack Structure
FATA-Jack is an 802.11 client DoS tool that tries to disconnect targeted stations using spoofed authentication frames that contain an invalid authentication algorithm number.
The Hotspotter attack is an evil-twin attack which attempts to lure a client to a malicious AP. Many enterprise employees use their laptop in Wi-Fi area hotspots at airports, cafes, malls etc. They have SSIDs of their hotspot service providers configured on their laptops. The SSIDs used by different hotspot service providers are well known. This enables the attackers to set up APs with hotspot SSIDs in close proximity of the enterprise premises. When the enterprise laptop Client probes for hotspot SSID, these malicious APs respond and invite the client to connect to them. When the client connects to a malicious AP, a number of security attacks can be launched on the client. A popular hacking tool used to launch these attacks is Airsnarf.
Detect Meiners Power Save DoS Attack
To save on power, wireless clients will "sleep" periodically, during which they cannot transmit or receive. A client indicates its intention to sleep by sending frames to the AP with the Power Management bit ON. The AP then begins buffering traffic bound for that client until it indicates that it is awake. An intruder could exploit this mechanism by sending (spoofed) frames to the AP on behalf of the client to trick the AP into believing the client is asleep. This will cause the AP to buffer most, if not all, frames destined for the client.
Omerta is an 802.11 DoS tool that sends disassociation frames to all stations on a channel in response to data frames. The Omerta attack is characterized by disassociation frames with a reason code of 0x01. This reason code is “unspecified” and is not be used under normal circumstances.
Many DoS attacks flood an AP or multiple APs with 802.11 management frames. These can include authenticate/associate frames which are designed to fill up the association table of an AP. Other management frame floods, such as probe request floods, can consume excess processing power on the AP.
TKIP is vulnerable to replay (via WMM/QoS) and plaintext discovery (via ChopChop). This affects all WPA-TKIP usage. By replaying a captured TKIP data frame on other QoS queues, an attacker can manipulate the RC4 data and checksum to derive the plaintext at a rate of one byte per minute.
By targeting an ARP frame and guessing the known payload, an attacker can extract the complete plaintext and MIC checksum. With the extracted MIC checksum, an attacker can reverse the MIC AP to Station key and sign future messages as MIC compliant, opening the door for more advanced attacks.
Detect Unencrypted Valid Clients
An authorized (valid) client that is passing traffic in unencrypted mode is a security risk. An intruder can sniff unencrypted traffic (also known as packet capture) with software tools known as sniffers. These packets are then reassembled to produce the original message.
Detect Valid Client Misassociation
This feature does not detect attacks, but rather it monitors authorized (valid) wireless clients and their association within the network. Valid client misassociation is potentially dangerous to network security. The four types of misassociation that we monitor are:
-
Authorized Client associated to Rogue—A valid client that is associated to a rogue AP
-
Authorized Client associated to External AP—An external AP, in this context, is any AP that is not valid and not a rogue
-
Authorized Client associated to Honeypot AP—A honeypot is an AP that is not valid but is using an SSID that has been designated as valid/protected
-
Authorized Client in ad hoc connection mode—A valid client that has joined an ad hoc network
AirJack is a suite of device drivers for 802.11(a/b/g) raw frame injection and reception. It was intended to be used as a development tool for all 802.11 applications that need to access the raw protocol, however one of the tools included allowed users to force off all users on an AP.
ASLEAP is a tool created for Linux systems which is used to attack Cisco LEAP authentication protocol.
A null probe response attack has the potential to crash or lock up the firmware of many 802.11 NICs. In this attack, a client probe-request frame will be answered by a probe response containing a null SSID. A number of popular NIC cards will lock up upon receiving such a probe response.
Intrusion protection features support containment of an AP or a client. In the case of an AP, we will attempt to disconnect all client that are connected or attempting to connect to the AP. In the case of a client, the client's association to an AP is targeted. The following containment mechanisms are supported:
-
Deauthentication containment: An AP or client is contained by disrupting its association on the wireless interface.
-
Tarpit containment: An AP is contained by luring clients that are attempting to associate with it to a tarpit. The tarpit can be on the same channel as the AP being contained, or on a different channel (see “Tarpit Shielding” ).
-
Wired containment: An AP or client is contained by disrupting its connection on the wired interface.
The WIP feature supports separate enforcement policies that use the underlying containment mechanisms to contain an AP or a client that do not conform to the policy. These policies are discussed in the sections that follow.
Infrastructure Intrusion Protection
Table 109 presents a summary of the infrastructure intrusion protection features with their related commands, traps, and syslog identifications. Details of each feature follow the table.
Protect 40MHz 802.11 High Throughput Devices
Protection from AP(s) that support 40MHz HT involves containing the AP such that clients can not connect.
Protect 802.11n High Throughput Devices
Protection from AP(s) that support HT involves containing the AP such that clients can not connect.
Protection from an Ad hoc Network involves containing the ad hoc network so that clients can not connect to it.
Protection from AP impersonation involves containing both the legitimate and impersonating AP so that clients can not connect to either AP.
Protect Misconfigured AP enforces that valid APs are configured properly. An offending AP is contained by preventing clients from associating to it.
Protect SSID enforces that valid/protected SSIDs are used only by valid APs. An offending AP is contained by preventing clients from associating to it.
By default, rogue APs are not automatically disabled. Rogue containment automatically disables a rogue AP by preventing clients from associating to it.
By default, suspected rogue APs are not automatically contained. In combination with the suspected rogue containment confidence level, suspected rogue containment automatically disables a suspect rogue by preventing clients from associating to it.
Table 110 list the client intrusion protection features with their related commands, traps, and syslog identifications. Details of each feature follow the table.
Protecting a valid client involves disconnecting that client if it is associated to a non-valid AP.
Protecting from a Windows Bridge involves containing the client that is forming the bridge so that it can not connect to the AP.
The WLAN management system (WMS) on the controller monitors wireless traffic to detect any new AP or wireless client station that tries to connect to the network. When an AP or wireless client is detected, it is classified and its classification is used to determine the security policies which should be enforced on the AP or client.
1. Navigate to the Configuration > Advanced Services > Wireless page.
2. Configure the parameters, as described in Table 111. Then click Apply.
Use the following commands to configure WMS via the CLI. The parameters in this command are described in detail in Table 111.
wms general
adhoc-ap-ageout-interval <minutes> | ap-ageout-interval <minutes> | collect-stats {disable|enable} | learn-ap {enable|disable} | learn-system-wired-macs |
persistent-neighbor {enable|disable} | poll-interval <milliseconds> |
poll-retries <number> | propagate-wired-macs {enable|disable} | sta-ageout-interval <minutes> | stat-update {enable|disable}
Configuring Local WMS Settings
You can also use the CLI to define local WMS system settings for the maximum number of APs and client stations.
|
|
Use this command with caution. Increasing the limit will cause an increase in usage in the memory by WMS. In general, each entry will consume about 500 bytes of memory. If the setting is bumped up by 2000, then it will cause an increase in WMS memory usage by 1MB |
(host) (config) #wms-local system max-threshold <max-threshold>
The WMS process interacts with all the air monitor (AM) processes in the network. When WMS receives an event message from an AM, the WMS process will save the event information along with the BSSID of the AP that generated the event in the WMS database. Use the following commands in Enable mode to manage the WMS database.
The wms export-db command exports the specified file as an ASCII text file into the WMS database.
(host) #wms export-db database <file>
The wms import-db command imports the specified file into the WMS database:
(host) #wms import-db database <file>
The wms reint-db command reinitializes the WMS database. Note that this command does not make an automatic backup of the current database.
(host) #wms renit-db
When a client is blacklisted in the Aruba system, the client is not allowed to associate with any AP in the network for a specified amount of time. If a client is connected to the network when it is blacklisted, a deauthentication message is sent to force the client to disconnect. While blacklisted, the client cannot associate with another SSID in the network.
The controller retains the client blacklist in the user database, so the information is not lost if the controller reboots. When you import or export the controller’s user database, the client blacklist will be exported or imported as well.
There are several ways in which a client can be blacklisted in the Aruba system:
-
You can manually blacklist a specific client. See “Manual Blacklisting” for more information.
-
A client fails to successfully authenticate for a configured number of times for a specified authentication method. The client is automatically blacklisted. See “Authentication Failure Blacklisting” for more information.
-
A DoS or man in the middle (MITM) attack has been launched in the network. Detection of these attacks can cause the immediate blacklisting of a client. See “Attack Blacklisting” for more information.
-
An external application or appliance that provides network services, such as virus protection or intrusion detection, can blacklist a client and send the blacklisting information to the controller via an XML API server. When the controller receives the client blacklist request from the server, it blacklists the client, logs an event, and sends an SNMP trap.
|
|
The External Services Interface feature require the Policy Enforcement Firewall Next Generation (PEFNG) license installed in the controller. |
There are several reasons why you may choose to blacklist a client. For example, you can enable different Aruba intrusion detection system (IDS) features that detect suspicious activities, such as MAC address spoofing or DoS attacks. When these activities are detected, an event is logged and an SNMP trap is sent with the client information. To blacklist a client, you need to know its MAC address.
To manually blacklist a client via the WebUI:
1. Navigate to the Monitoring > Controller > Clients page.
2. Select the client to be blacklisted and click the Blacklist button.
To clear the entire client blacklist using the WebUI:
1. Navigate to the Monitoring > Controller > Clients page.
2. Click Remove All from Blacklist.
To manually blacklist a client via the command-line interface, access the CLI in config mode and issue the following command:
stm add-blacklist-client <macaddr>
To clear the entire client blacklist using the command-line interface, access the CLI in config mode and issue the following command:
stm purge-blacklist-client
Authentication Failure Blacklisting
You can configure a maximum authentication failure threshold for each of the following authentication methods:
-
802.1x
-
MAC
-
Captive portal
-
VPN
When a client exceeds the configured threshold for one of the above methods, the client is automatically blacklisted by the controller, an event is logged, and an SNMP trap is sent. By default, the maximum authentication failure threshold is set to 0 for the above authentication methods, which means that there is no limit to the number of times a client can attempt to authenticate.
With 802.1x authentication, you can also configure blacklisting of clients who fail machine authentication.
|
|
When clients are blacklisted because they exceed the authentication failure threshold, they are blacklisted indefinitely by default. You can configure the duration of the blacklisting; see “Blacklist Duration” . |
To set the authentication failure threshold via the WebUI:
1. Navigate to the Configuration > Security > Authentication > Profiles page.
2. In the Profiles list, select the appropriate authentication profile, then select the profile instance.
3. Enter a value in the Max Authentication failures field.
4. Click Apply.
To set the authentication failure threshold via the command-line interface, access the CLI in config mode and issue the following commands:
aaa authentication {captive-portal|dot1x|mac|vpn} <profile>
max-authentication-failures <number>
There are two type of automatic client blacklisting that can be enabled: blacklisting due to spoofed deauthentication, or blacklisting due to other types of DoS attacks.
Automatic blacklisting for DoS attacks other than spoofed deauthentication is enabled by default. You can disable this blacklisting on a per-SSID basis in the virtual AP profile.
Man in the middle (MITM) attacks begin with an intruder impersonating a valid enterprise AP. If an AP needs to reboot, it sends deauthentication packets to connected clients to enable them to disconnect and reassociate with another AP. An intruder or attacker can spoof deauthentication packets, forcing clients to disconnect from the network and reassociate with the attacker’s AP. A valid enterprise client associates to the intruder’s AP, while the intruder then associates to the enterprise AP. Communication between the network and the client flows through the intruder (the man in the middle), thus allowing the intruder the ability to add, delete, or modify data. When this type of attack is identified by the Aruba system, the client can be blacklisted, blocking the MITM attack. Enable this blacklisting ability in the IDS DoS profile (this is disabled by default).
To enable spoofed deauth detection and blacklisting via the WebUI:
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. In the Profiles list, expand the IDS menu, then select IDS profile.
4. Select the IDS DOS profile.
5. Select (check) Spoofed Deauth Blacklist.
6. Click Apply.
To enabled spoofed deauth detection and blacklisting via the command-line interface, access the CLI in config mode, and issue the following commands:
ids dos-profile <profile>
spoofed-deauth-blacklist
You can configure the duration that clients are blacklisted on a per-SSID basis via the virtual AP profile. There are two different blacklist duration settings:
-
For clients that are blacklisted due to authentication failure. By default, this is set to 0 (the client is blacklisted indefinitely).
-
For clients that are blacklisted due to other reasons, including manual blacklisting. By default, this is set to 3600 seconds (one hour). You can set this to 0 to blacklist clients indefinitely.
To configure the blacklist duration via the WebUI:
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. In the Profiles list, select Wireless LAN, then Virtual AP. Select the virtual AP instance.
-
To set a blacklist duration for authentication failure, enter a value for Authentication Failure Blacklist Time.
-
To set a blacklist duration for other reasons, enter a value for Blacklist Time.
4. Click Apply.
To configure the blacklist duration via the command-line interface, access the CLI in config mode and issue the following commands:
wlan virtual-ap <profile>
auth-failure-blacklist-time <seconds>
blacklist-time <seconds>
Removing a Client from Blacklisting
You can manually remove a client from blacklisting using either the WebUI or CLI:
To remove a client from blacklisting via the WebUI:
1. Navigate to the Monitoring > Controller > Blacklist Clients page.
2. Select the client that you want to remove from the blacklist, then click Remove from Blacklist.
To remove a client from blacklisting via the command-line interface, access the CLI in enable mode and issue the following command:
stm remove-blacklist-client <macaddr>
Note:this release has not been updated since the release of the pdf