Wi-Fi Design and Deployment

• 1: Wi-Fi Security
• 1.1: Security Modes
• 1.1.1: WPA3-Enterprise
• 1.1.2: WPA3-Personal
• 1.1.3: Enhanced Open
• 1.1.4: Troubleshooting
• 1.2: Security Features
• 1.2.1: Protected Management Frames
• 1.3: Wireless Intrusion Detection & Protection
• 1.3.1: Use Cases
• 1.3.2: RF Scanning Methods
• 1.3.3: Detection
• 1.3.3.1: Infrastructure Event Detection Levels and Signature Descriptions
• 1.3.3.2: Client Event Detection Levels and Signature Descriptions
• 1.3.4: Classification
• 1.3.5: Protection
• 1.3.6: Configuring, Monitoring and Reporting WIDS
• 1.4: Client authentication options and operations
• 1.4.1: RADIUS Accounting

1 - Wi-Fi Security

1.1 - Security Modes

In an increasingly interconnected world, secure and reliable Wi-Fi communication is a must-have. Across home offices to industrial environments to enterprise networks, Wi-Fi has become a crucial part ofmobile connectivity. As the reliance on Wi-Fi networks has grown, so has the security to protect and ensure privacy for sensitive data.

Enhanced Open and Wi-Fi Protected Access version 3 (WPA3) are the current advancements in Wi-Fi security standards from the Wi-Fi Alliance (WFA), designed to address weaknesses of their predecessors WPA2 and Open networks. The security modes sections aim to provide insights into Enhanced Open and WPA3 networks with HPE Aruba Networking deployments, exploring key components, practical implications, and best practices. Deployment considerations and compatibility aspects will be discussed.

Authentication and Key Management (AKM)

The security solutions used in Wi-Fi networks are defined by the IEEE 802.11 standards and Wi-Fi Alliance. Each security protocol has a specific authentication and key management (AKM) suite type (number).

The standard defines AKM suite selectors with a format of OUI:N where N represents the suite type. The standards based AKMs are denoted by an OUI of 00-0F-AC. For example, the suite selector for WPA3-Personal (wpa3-sae-aes) is 00-0F-AC:8. The corresponding pages refer to 00-0F-AC:N as AKM:N.

The Wi-Fi Alliance (WFA) defines security certifications by AKM, cipher suites, and Protected Management Frame (PMF) combinations. The following is used to indicate the different authentication types defined in the standard and their corresponding Wi-Fi Alliance certification program label:

Wi-Fi Alliance Programs

This section details the specifications defined by the Wi-Fi Alliance security certifications. A following section will map them to the security modes implemented by HPE Aruba Networking in AOS.

Enhanced Open

The Wi-Fi Alliance Enhanced Open specification defines the following:

• Enhanced Open based on Opportunistic Wireless Encryption (OWE) defined in RFC 8110 (AKM:18)

WPA3

The Wi-Fi Alliance WPA3 specification defines the following:

• WPA3-Personal (AKM:8, Wi-Fi 7 uses AKM:24)
• WPA3-Personal Transition (AKM:2 + AKM:8)
• WPA3-Enterprise Only (AKM:5)
• WPA3-Enterprise Transition Mode (AKM:1 + AKM:5)
• WPA3-Enterprise 192-bit mode (AKM:12)

Corresponding AOS Security Modes

6 GHz Operation

Wi-Fi 6E is Wi-Fi 6 ‘extended’ to include the 6 GHz band. Extending operation into the 6 GHz band was an opportunity to leave behind some of the legacy requirements which exist for operation in the 2.4 GHz and 5 GHz bands.

The Wi-Fi Alliance (WFA) made the decision to require WPA3 or Enhanced Open as the minimum security modes allowed in the 6 GHz band.

The following legacy security modes not allowed in 6 GHz operation include:

• WPA2-Enterprise or the corresponding transition mode*
• WPA2-Personal or the corresponding transition mode*
• Open, WPA version 1, TKIP, or WEP

Terminology

The following terminology is used throughout the various security mode sections. For additional information, refer to sources mentioned below.

• AKM – Authentication and Key Management
• BSS – Basic Service Set
• CNSA – Commercial National Security Algorithm
• DH – Diffie-Hellman
• Enhanced Open – Wi-Fi Alliance certification based on OWE protocol
• FT - Fast (BSS) Transition for improving handoff between APs
• IEEE – Institute of Electrical and Electronics Engineers
• OWE – Opportunistic Wireless Encryption
• MFP – Management Frame Protection (see PMF)
• MFPC – Management Frame Protection Capable
• MFPR – Management Frame Protection Required
• PMF – Protected Management Frame (see MFP)
• PMK – Pairwise Master Key
• RSNE – Robust Security Network Element
• SAE – Simultaneous Authentication of Equals protocol used by WPA3-Personal
• WFA – Wi-Fi Alliance
• Wi-Fi 6 – Based on IEEE 802.11ax (HE)
• Wi-Fi 6E – Wi-Fi 6 extended to include the 6 GHz band
• Wi-Fi 7 – Based on IEEE 802.11be (EHT)
• WPA2 – Wi-Fi Protected Access version 2
• WPA3 – Wi-Fi Protected Access version 3

Sources and References

• IEEE 802.11-2016
• IEEE 802.11-2020
• RFC 5759 – Suite B Certificate and Certificate Revocation List (CRL) Profile
• RFC 6460 – Suite B Profile for Transport Layer Security (TLS)
• RFC 6379 – Suite B Cryptographic Suites for IPsec
• RFC 7268 – RADIUS Attributes for IEEE 802 Networks
• RFC 8110 – Opportunistic Wireless Encryption
• WPA3 Specification version 3.0
• WPA3 Specification version 3.1
• WPA3 Specification version 3.2

Decoder Ring

1. wpa3-sae-aes with AKM:24 is not yet supported in AOS.
2. wpa2-aes is not typically deployed with PMF due to lack of support by WPA2 clients.
3. wpa2-aes with PMF configuration set as required removes AKM:1 (802.1X with SHA-1) and adds AKM:5 (802.1X with SHA-256) which is effectively WPA3 only. Please review caveats on the WPA3-Enterprise page.
4. Transition mode for WPA3-Enterprise CCM 128 is supported starting in AOS 8.11 and 10.5. Transition mode has no effect on operation in AOS 8.10 and 10.4.
5. WPA3-Enterprise CCM 128 with transition mode enabled adds AKM:5 (802.1X with SHA-256) in the 2.4 GHz and 5 GHz bands starting in AOS 8.11 and 10.5. When transition mode is disabled, AKM:1 (802.1X with SHA-1) is not advertised.
6. There is no compatible FT AKM for CNSA.

See the following subpages to learn more:

1.1.1 - WPA3-Enterprise

HPE Aruba Networking offers three different modes of operation for WPA3-Enterprise: CCM 128, GCM 256, and CNSA.

• CCM 128 offers the widest compatibility, including WPA2-certified clients when deployed in transition mode.
• GCM 256 restricts to WPA3-certified clients that support GCMP-256 ciphers.
• CNSA (192-bit) constrains the available options used with WPA3-Enterprise with the intent to raise the bar of attack sophistication making CNSA suitable for some of the highest levels of data protection.

WPA3-Enterprise CCM 128

WPA3-Enterprise CCM 128 meets the requirements for two modes of operation for WPA3-Enterprise as specified by the Wi-Fi Alliance.

• “WPA3-Enterprise transition mode” which advertises key management for both WPA2-Enterprise and WPA3-Enterprise clients and sets PMF to optional (when operating in the 2.4 GHz and 5 GHz bands).
• “WPA3-Enterprise only mode” which advertises key management for only WPA3-Enterprise configured clients and requires PMF (across all bands of operation). This is the behavior when transition mode configuration is explicitly disabled.

WPA3-Enterprise CCM 128 in transition mode (default behavior) advertises or negotiates the following capabilities in beacons, probe response, or association in the 2.4 GHz and 5 GHz bands of operation:

• AKM suite selectors include 00-0F-AC:1 (802.1X with SHA-1) and 00-0F-AC:5 (802.1X with SHA-256).
• Protected Management Frames are capable and automatically set as optional (MFPR=0 and MFPC=1).
• This mode supports both WPA2-Enterprise only clients to connect with WPA2 (AKM:1) and WPA3-Enterprise capable clients to connect with WPA3 (AKM:5).

WPA3-Enterprise CCM 128 with transition mode disabled (WPA3-Enterprise only mode) advertises or negotiates the following capabilities in beacons, probe response, or association in the 2.4 GHz and 5 GHz bands of operation:

• AKM suite selector as 00-0F-AC:5 (802.1X with SHA-256).
• Protected Management Frames are required and automatically set as mandatory (MFPR=1 and MFPC=1).
• This mode only supports WPA3-Enterprise capable client connection with WPA3 (AKM:5).

When operating in the 6 GHz band, WPA3-Enterprise CCM 128 is automatically set as “WPA3-Enterprise only mode”, and advertises or negotiates the following capabilities in beacons, probe response, or association:

• AKM suite selector as 00-0F-AC:5 (802.1X with SHA-256).
• Protected Management Frames are required and automatically set as mandatory (MFPR=1 and MFPC=1).
• This mode only supports WPA3-Enterprise capable client connection with WPA3 (AKM:5).

WPA3-Enterprise CCM 128 advertises or negotiates the following ciphers in all modes of operation in beacons, probe response, or association:

• Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128).
• Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
• Group management cipher suite selector as 00-0F-AC:6 (BIP-CMAC-128).

AOS 8.11+ and 10.5+

The behavior for WPA3 Enterprise CCM 128 in AOS 8.11 and 10.5 or later is as follows:

• Support for transition mode is introduced for WPA3-Enterprise CCM 128.
• When transition mode is enabled (default), the behavior is as follows:
  • 2.4 GHz and 5 GHz operation:
    • Both 00-0F-AC:1 (802.1X with SHA-1) and 00-0F-AC:5 (802.1X with SHA-256) are advertised in the RSNE.
    • Capable clients can negotiate using WPA2 or WPA3. Client picks which.
    • PMF is optional (MFPR=0 and MFPC=1).
  • 6 GHz operation:
    • 00-0F-AC:5 (802.1X with SHA-256) is advertised in the RSNE.
    • PMF is required (MFPR=1 and MFPC=1).

• When transition mode is disabled, the behavior for WPA3-Enterprise CCM 128 is as follows:
  • 2.4 GHz and 5 GHz operation:
    • 00-0F-AC:5 (802.1X with SHA-256) is advertised in the RSNE.
    • WPA2-Enterprise only clients will not connect. Transition mode disabled forces WPA3 connections.
    • PMF is required (MFPR=1 and MFPC=1).
  • 6 GHz operation:
    • 00-0F-AC:5 (802.1X with SHA-256) is advertised in the RSNE.
    • PMF is required (MFPR=1 and MFPC=1).

AOS 8.10 and 10.4

The behavior for WPA3 Enterprise CCM 128 in AOS 8.10 and 10.4 is as follows:

• Transition mode configuration has no effect on operation.
• 2.4 GHz and 5 GHz operation:
  • 00-0F-AC:1 (802.1X with SHA-1) is advertised in the RSNE.
  • PMF is optional (MFPR=0 and MFPC=1).

• 6 GHz operation:
  • 00-0F-AC:5 (802.1X with SHA-256) is advertised in the RSNE.
  • PMF is required (MFPR=1 and MFPC=1).

Workaround

If there is a requirement to restrict connectivity to “WPA3-Enterprise Only Mode” while using CCMP-128 ciphers on AOS 8.10 or 10.4 deployments, consider the following workaround and caveats:

• The WPA2-Enterpise security mode (wpa2-aes) with PMF configured as mandatory (MFPR=1 and MFPC=1) effectively uses WPA3-Enterprise (AKM:5) for key management instead of WPA2-Enterprise (AKM:1).
• Use cases for this workaround:
  • “WPA3-Enterprise Only Mode” with no support for legacy WPA2-Enterprise clients.
  • AOS 8.10 or 10.4 deployments.
  • 2.4 GHz or 5 GHz operation.
• To deploy this workaround two configurations are required.
  • 1. Security mode set as WPA2-Enterprise (wpa2-aes)
  • 2. PMF set as mandatory (MFPR=1 and MFPC=1)
    • Instant 8 configuration for MFP via CLI (mfp-capable and mfp-required parameters), Central template group, or Central REST API.
    • AOS 8 configuration for MFP via WebUI, CLI, or local REST API.
    • AOS 10 configuration for MFP via Central REST API.
• Caveats:
  • This workaround does not support 6 GHz operation.
  • AOS 8 forwarding mode caveats:
    • PMF operation for Wi-Fi 5 APs requires use of decrypt-tunnel forwarding mode.
    • PMF operation in tunnel forwarding mode is supported starting with Wi-Fi 6 APs.
  • When this workaround is deployed and a capable deployment is being upgraded to an 8.11 release, upgrade to at least 8.11.2.1 or later due to a multicast encryption mismatch bug (AOS-243060) present in earlier 8.11 releases.

Example AOS 8.10 configuration for WPA3 only key management in 2.4 GHz or 5 GHz bands using wpa2-aes + mfp-capable + mfp-required:

wlan ssid-profile "ACME_1X_WPA3"
essid "ACME_1X_WPA3"
opmode wpa2-aes
mfp-capable
mfp-required
!

Example AOS 8.10 verification:

(MCR) [mynode] #show wlan ssid-profile ACME_WPA3_Enterprise
SSID Profile "ACME_1X_WPA3"
---------------------------
Parameter                                               Value
---------                                               -----
SSID enable                                             Enabled
ESSID                                                   ACME_1X_WPA3
Encryption                                              wpa2-aes
Enable Management Frame Protection (for WPA2 opmodes)   Enabled
Require Management Frame Protection (for WPA2 opmodes)  Enabled

When this workaround is configured and supported, the following capabilities are advertised or negotiated in beacons, probe response, or association in the 2.4 GHz or 5 GHz bands:

• AKM suite selector as 00-0F-AC:5 (802.1X with SHA-256).
• Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128).
• Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
• Group management cipher suite selector as 00-0F-AC:6 (BIP-CMAC-128).
• Protected Management Frames are mandatory (MFPR=1 and MFPC=1).

When this workaround is configured and not supported, such as by Wi-Fi 5 APs in tunnel mode on AOS 8, the following capabilities are advertised or negotiated in beacons, probe response, or association in the 2.4 GHz or 5 GHz bands:

• AKM suite selector as 00-0F-AC:1 (802.1X with SHA-1).
• Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128).
• Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
• Protected Management Frames are disabled (MFPR=0 and MFPC=0).

After some period of workaround implementation and a new deployment requirement arises for 6 GHz operation, for example when 6 GHz capable hardware is added, consider the following software upgrade and configuration migration order to maintain consistency in advertised key management:

• First
  • AOS 8: Upgrade to 8.11.2.1 or later.
  • AOS 10: Upgrade to 10.5 or later.
• Second
  • Change the security mode from WPA2-Enterprise (wpa2-aes) to WPA3-Enterprise CCM 128 (wpa3-aes-ccm-128).
  • Disable transition mode to disable support for WPA2 clients using AKM:1. This is neccessay because transition mode configuration for WPA3-Enterprise CCM 128 is supported starting in 8.11 and 10.5 and is enabled by default advertising both AKM:1 and AKM:5.
• Third
  • AOS 8: Configure “Allow 6GHz band” on respective VAP.
  • AOS 10: Enable 6 GHz band in respective WLAN configuration.

Best Practices

WPA3-Enterprise is suitable for use cases where WPA2-Enterprise was used prior because of Protected Management Frames and when AKM:5 (SHA-256) is negotiated the key length is increased. It is encouraged to disable weak EAP methods such as PEAP-MSCHAPv2, CHAPv1, PAP, etc., and consider using a stronger EAP method such as EAP-TLS.

Consider disabling transition mode to limit attack vectors. When PMF is disabled or not used by a client, attackers can spoof management frames from an AP to attack an associated client through Denial of Service (DoS) or attacker-in-the-middle techniques.

Consider deploying WPA3-Enterprise and WPA2-Enterprise on different individual VAPs.

WPA3-Enterprise GCM 256

Introduced in AOS 8.5, WPA3-Enterprise with 256 bits enables GCMP-256 cipher suites without requiring CNSA compatible EAP. This mode is also referred to as WPA3-Enterprise Non-CNSA.

The following is advertised and negotiated in beacons, probe response, and association:

• AKM suite selector as 00-0F-AC:5 (802.1X with SHA-256).
• Pairwise cipher suite selector as 00-0F-AC:9 (GCMP-256).
• Group data cipher suite selector as 00-0F-AC:9 (GCMP-256).
• Group management cipher suite selector as 00-0F-AC:12 (BIP-GMAC-256).
• Protected Management Frames are mandatory (MFPR=1 and MFPC=1).

Best Practices

This security mode is suitable for use-cases where WPA2-Enterprise was used prior because of Protected Management Frames and stronger ciphers than CCM 128.

Use this security mode if the client population is under administrative control and knowledge of client support for GCMP-256 with AKM:5 is known.

Weak EAP methods such as PEAP-MSCHAPv2, CHAPv1, PAP, etc., should be disabled and client connections moved to using a stronger EAP method such as EAP-TLS.

The client population must support the defined security parameters as transition mode is not allowed for WPA3-Enterprise GCM 256.

WPA3-Enterprise CNSA (192-bit)

WPA3-Enterprise CNSA (192-bit) enforces CNSA Suite security standards for enterprise Wi-Fi networks.

The following is advertised and negotiated in beacons, probe response, and association:

• AKM suite selector as 00-0F-AC:12 (802.1X with SHA-384).
• Pairwise cipher suite selector as 00-0F-AC:9 (GCMP-256).
• Group data cipher suite selector as 00-0F-AC:9 (GCMP-256).
• Group management cipher suite selector as 00-0F-AC:12 (BIP-GMAC-256).
• Protected Management Frames are mandatory (MFPR=1 and MFPC=1).

Other notes of importance:

• Requires a CNSA Suite compatible EAP-TLS cipher suite (RFC 6460):
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 using p384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 using p384 and RSA > 3k bits
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 using RSA > 3k bits
• TLS v1.2 or later is required.
• Key length must be greater than 3072 bits. The signing keys have the same key length requirements.
• Certificate chain validation is mandatory.
• EAP termination is not supported. EAP termination is when EAP tunnel termination is moved upstream from the RADIUS server to the controller or AP. WPA3-Enterprise 192-bit (CNSA) expects that a RADIUS server is used, and policy is enforced by the RADIUS server. This means CNSA Suite compatible 802.1X happens between client and RADIUS server based on the authenticator indicating which AKM is negotiated between client and AP.

WPA3-Enterprise CNSA (192-bit) is supported by HPE Aruba Networking ClearPass (CPPM) starting in version 6.8 and supports the following RADIUS attributes from RFC 7268:

• WLAN-Reason-Code (185) 
• WLAN-Pairwise-Cipher (186)
• WLAN-Group-Cipher (187)
• WLAN-AKM-Suite (188)
• WLAN-Group-Mgmt-Cipher (189)

Best Practices

This security mode is suitable for use-cases where WPA2-Enterprise was used prior because of Protected Management Frames, increased key length, stronger ciphers, and requirement of CNSA Suite compatible EAP-TLS methods.

This is primarily focused on customers such as government, finance, and other industries who require a high level of security.

The client population must support the defined security parameters as transition mode is not allowed for WPA3-Enterprise CNSA (192-bit).

1.1.2 - WPA3-Personal

Offline dictionary attacks against WPA2-Personal have been widely known for well over two decades. They were discovered shortly after the inception of WPA2-Personal. Certain venues offer free Wi-Fi networks using a shared and public password. Some incorrectly believe Wi-Fi traffic is secure when WPA2-Personal is used. With PSK, the password directly derives a master key and knowledge of the password enables decryption, replay, and forgery of data frames.

sequenceDiagram
    Note over Client,AP: Discovery
    Note over Client,AP: Open System Authentication
    Note over AP,Client: Association
    Note right of Client:PMK generation:<br>PMK=PBKDF2(HMAC-SHA-1,<br>Password,SSID,4096,256)
    Note over AP,Client: 4-way handshake

Protocol

Originally introduced for mesh security in IEEE 802.11-2016, the Simultaneous Authentication of Equals (SAE) protocol replaces the Pre-Shared Key (PSK) implementation found in WPA2-Personal with a password-based authentication method resistant to dictionary attacks.

Users will find a similar experience with SAE and PSK as they are both password provisioned. However, there are major implementation differences in the security protocol.

For those venues who intend to offer better data protection for their users, SAE offers a more secure password-based option than a shared and public PSK. This is because the master key (PMK) resulting from SAE is not solely based on the password.

With SAE, the password is used in a zero-knowledge proof cryptographic function to derive a unique pairwise master key (PMK) per client. The password is used to index a secret point on an elliptic curve. The point on the curve becomes the generator for use in a cryptographic exchange.

sequenceDiagram
    Note over Client,AP: Discovery
    Client->>+AP:PWE = f(password)<br>m,n ← random<br>N = -n * PWE<br>SAE Authentication Commit
    AP->>+Client:PWE = f(password)<br>i,j ← random<br>J = -j * PWE<br>SAE Authentication Commit
    Client->>+AP:SAE Authentication Confirm<br>S = m * ((i+j) * J)<br>PMK = KDF(S, label)
    AP->>+Client:SAE Authentication Confirm<br>S = i * ((m+n) * N)<br>PMK = KDF(S, label)
    Note over AP,Client: Association
    Note over AP,Client: 4-way handshake

This means the password or password-derived data is never sent over the air. Unlike with WPA2-Personal (PSK), knowledge of the password cannot decrypt SAE encrypted data frames. The PMK is needed to decrypt SAE encrypted data frames and the only parties that know the PMK are the client and AP which performed SAE. This means the SAE protocol is resistant to active, passive, and dictionary attacks.

WPA3-Personal Only Mode

WPA3-Personal advertises or negotiates the following capabilities in beacons, probe response, or association:

• AKM suite selector as 00-0F-AC:8 (SAE).
• Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128).
• Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
• Group management cipher suite selector as 00-0F-AC:6 (BIP-CMAC-128).
• Protected Management Frames are mandatory (MFPR=1 and MFPC=1).

WPA3-Personal Transition Mode

WPA3-Personal may be deployed in transition mode that allows both SAE clients and PSK clients to connect to the same Basic Service Set (BSS), which is a mixed mode of operation. The beacon or probe response contains an AKM list in the RSNE which will contain both PSK (AKM:2) and SAE (AKM:8).

This means the password is shared between WPA2-Personal and WPA3-Personal. The WPA2-Personal network is still vulnerable to all the classic issues. If an attacker gains knowledge of the password by attacking WPA2-Personal, they will get access to the network, but will not be able to decrypt WPA3-Personal sessions. Downgrade attacks from WPA3-Personal to WPA2-Personal are also possible.

Due to the same BSS servicing both WPA2-Personal (PSK) and WPA3-Personal (SAE) clients, Protected Management Frames are optional (MFPR=0 and MFPC=1) for WPA3-Personal Transition networks.

WPA3-Personal in Transition Mode advertises or negotiates the following capabilities in beacons, probe response, or association:

• AKM suite selectors include 00-0F-AC:2 (PSK) and 00-0F-AC:8 (SAE).
• Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128).
• Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
• Group management cipher suite selector as 00-0F-AC:6 (BIP-CMAC-128).
• Protected Management Frames are optional (MFPR=1 and MFPC=0).

Hash-to-Element (H2E)

Hash-to-element (also referred to as hash-to-curve or direct hashing) is a cryptographic method for generation of the password element (PWE) which replaces the weaker and original hunting-and-pecking (also referred to as looping) method for SAE. With hash-to-element, WPA3-Personal is further resistant to side-channel attacks and timing attacks.

SAE H2E capability can be found in beacon and probe response frames in the extended RSN capabilities field of the RSN eXtension element (RSNXE).

Status code 126 found in the authentication frame from the client indicates which method is used.

PWE derivation behavior starting in AOS 8.10 and 10.4:

• Operation in the 2.4 GHz and 5 GHz bands:
  • Hash-to-element (H2E) is preferred but allows hunting-and-pecking if the client does not support H2E.
• Operation in the 6 GHz band:
  • Enforces use of H2E and does not allow hunting-and-pecking.

Support for hash-to-element (H2E) is mandatory for WPA3 certified devices.

Clients have been supporting H2E since 2021:

• Android 12+
• Linux wpa_supplicant v2.10+ (see sae_pwe parameter for configuration)
• macOS Catalina+
• Windows 10 21H2+

Best Practices

For use-cases where WPA2-Personal was used before, WPA3-Personal is a suitable replacement to provide better security, even when a non-complex password is used. WPA3-Personal provides stronger data encryption and protection than WPA2-Personal.

WPA3-Personal is also suitable for use-cases where WPA2-Personal is no longer allowed such as with 6 GHz operation and Wi-Fi 7 connectivity.

1.1.3 - Enhanced Open

Wi-Fi networks with Open security transport and pass data in the clear offering no encryption or protection from passive eavesdroppers.

Enhanced Open provides unauthenticated data encryption and protects data from sniffers.

Protocol

Open security is one of the original IEEE 802.11 access methods for connecting clients to APs. Open uses an authentication architecture called Open System Authentication (OSA). OSA offers no encryption. When utilized independently, OSA permits WLAN access to any client.

sequenceDiagram
    Note over Client,AP: Discovery
    Note over Client,AP: Open System Authentication
    Note over Client,AP: Association

Enhanced Open adds automatic encryption without requiring credentials. Enabling private communication between client and AP. Encryption is provided by Opportunistic Wireless Encryption (OWE) defined in RFC 8110. With OWE, the client and AP performs an unauthenticated Diffie-Hellman key exchange which results in a unique pairwise secret key (PMK). The resulting key is used in a 4-way handshake post association to generate the traffic encryption keys.

sequenceDiagram
    Note over Client,AP: Discovery
    Note over Client,AP: Open System Authentication
    Client->>+AP:Association request with<br>Diffie-Hellman parameter<br>X (public key)
    Note left of AP:PMK generation:<br>y←random<br>Y=y*g<br>S=y*X<br>PMK=KDF(S,label)
    AP->>+Client:Association response with<br>Diffie-Hellman parameter<br>Y (public key)
    Note right of Client:PMK generation:<br>x←random<br>X=x*g<br>S=x*Y<br>PMK=KDF(S,label)
    Note over AP,Client: 4-way handshake

The resulting benefit is a Wi-Fi network more secure than a shared and public PSK (WPA2-Personal) because OWE is not susceptible to a passive attack which results in an attacker being able to eavesdrop, forge, and replay frames on the network. Enhanced Open is also easier to deploy because there is nothing to provision. There is no password.

Enhanced Open Only Mode

Enhanced Open advertises or negotiates the following capabilities in beacons, probe response, or association:

• AKM suite selector as 00-0F-AC:18 (OWE).
• Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128), 00-0F-AC:8 (GCMP-128),00-0F-AC:9 (GCMP-256), or00-0F-AC:1 (CCMP-256) could be negotiated.
• Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
• Group management cipher suite selector as 00-0F-AC:6 (BIP-CMAC-128).
• Protected Management Frames are mandatory (MFPR=1 and MFPC=1).

Enhanced Open Transition Mode

Enhanced Open Transition Mode (OWETM) offers a backwards compatible transition from unencrypted Open Wi-Fi networks. OWETM provides the ability for non-OWE clients (Open) and OWE capable clients to connect to the same Wi-Fi network.

This is accomplished by creating and broadcasting two Basic Service Sets (BSSes) with separate beacons for each. Both BSSes point at the other through the OWE Transition Mode Vendor IE.

• BSS-1 for Open for non-OWE clients with the IE to indicate BSS-2.
• BSS-2 for “hidden” OWE with a zero length SSID (hidden) and the IE to indicate BSS-1.

The beacon and probe response frames of the Open BSS includes an OWE Transition Mode IE to encapsulate the BSSID and SSID of the OWE BSS.

• The Open BSS and associated clients do not benefit from Protected Management Frames or data encryption.

The beacon and probe response frames from the OWE BSS include an OWE Transition Mode IE to encapsulate the BSSID and SSID of the Open BSS.

• The beacon frame from the OWE BSS will be zero length and includes the OWE Authentication and Key Management (AKM) selector (00-0F-AC) of AKM:18 in the RSNE.
• PMF is required (MFPR=1 and MFPC=1) for the OWE BSS.
• The OWE client benefits from both encryption and PMF.

The OWE client discovers the OWE AP by using active or passive scanning.

MAC authentication

When using Enhanced Open and authorizing connecting devices using a MAC authentication method, note that the client association will be rejected if the MAC authentication returns a REJECT message on the authentication attempt. This is a change in behavior when compared against an Open network where the client device would stay associated and be left assigned in the logon user role. The MAC authentication service used by an Enhanced Open network will need to always allow the authentication attempt and return the appropriate user role for the session to continue, whether that be a user role that enforces a captive portal, allows full access to the network, or otherwise configured.

Best Practices

Enhanced Open is suitable for use-cases such as captive portals, coffee shops, cafés, schools, enterprises, public venues like airports, stadiums, etc., anywhere that encryption is needed but identity and authentication is not.

1.1.4 - Troubleshooting

AOS 8

(MD) # show ap association  
(MD) # show ap bss-table  
(MD) # show ap essid  
(MD) # show ap owe-tm-info  
(MD) # show auth-tracebuf mac <client-mac>  
(MD) # show dot1x supplicant-info <client-mac> <bssid>  
(MD) # show dot1x supplicant-info pmkid  
(MD) # show log security  
(MD) # show wlan ssid-profile <profile-name>

AOS 10

(AP) # show ap association  
(AP) # show ap bss-table  
(AP) # show ap debug client-table  
(AP) # show ap debug mgmt-frames mac <client-mac>  
(AP) # show clients debug advanced  
(AP) # show log security  
(AP) # show network  
(AP) # show network <profile-name>

1.2 - Security Features

1.2.1 - Protected Management Frames

The IEEE 802.11w-2009 amendment (now part of IEEE 802.11-2020) introduced Protected Management Frames (PMF) which addresses the protection of robust management frames. Prior to WPA3 and Enhanced Open, most management frames are not encrypted. Since Wi-Fi is a broadcast medium, any device can eavesdrop or participate as a legitimate or rogue client. Securing management frames also is equally important as data frames. Without PMF, all management frames are sent unprotected in the open. PMF protects a set of robust management frames and augments privacy protections already in place for data frames (802.11i). WPA3 and Enhanced Open require use of PMF.

PMF is also referred to as Management Frame Protection (MFP). When discussing whether Protected Management Frames are optional or required, the terms MFPR (required) and MFPC (capable) will be used. Their configuration options are discussed below. Throughout the security mode sections the terms PMF and MFP may be used interchangeably. In the context of HPE Aruba Networking, these terms mean the same thing.

Three possible configurations exist for Protected Management Frames:

Protected Management Frames help secure robust management frames against various attacks. The key security objective is to protect against passive eavesdropping, prevent forgery of unicast and multicast action frames, allow replay detection, and prevent stations from masquerading as another station.

PMF protects against forged disassociation and de-authentication frames post association.

Examples of protected robust action frames include:

• Channel Switch Announcements
• QoS
• ADDBA Negotiation
• Block ACK
• Radio Measurement
• Security Association (QA) Query
• Wireless Network Management

Support for Protected Management Frames is advertised in the RSN Capabilities of the RSNE which can be found in beacons, probe responses, and association responses.

AOS specifics:

• PMF is not user configurable for WPA3 or Enhanced Open security modes. MFPR (Required) and MFPC (Capable) configuration is automatic.

1.3 - Wireless Intrusion Detection & Protection

The HPE Aruba Networking Wireless Intrusion Detection & Protection System (WIDS & WIPS) is a network security feature that monitors wireless networks for unauthorized access points, clients, and abnormal traffic patterns. WIDS & WIPS detects rogue and interfering access points, providing real-time alerts and detailed reports to safeguard the integrity of the wireless network. Attacks are not only detected but also classified, contained, and recorded in a seamless sequence that can automatically handle security events.

When security events are discovered, HPE Aruba Networking Central can alert the security team of possible threats and provides essential information needed to locate and manage those threats.

WIDS & WIPS operates at the radio frequency level, with various deployment modes to suit different environments — Access Point (AP) mode for client service, and Air Monitor (AM) mode with an emphasis on security. While standard AP mode suffices for most security needs, environments demanding higher security may opt for AM mode, especially for wireless containment.

HPE Aruba Networking Central provides an effective defense strategy against rogues and other forms of wireless intrusion:

• Performs multiple types of wireless scans.

• Correlate the results of the various scans to consolidate all available information about identified devices.

• Classifies the discovered devices based on rules that are customized to an organization’s security needs.

• Generates automated alerts and reports for IT containing key known information about unauthorized devices, including the physical location and switch port whenever possible.

• Deploys containment mechanisms to neutralize potential threats.

1.3.1 - Use Cases

The primary use cases that HPE Aruba Networking WIDS aims to solve include:

• Network security threats: WIDS helps organizations mitigate and prevent security threats within their network by addressing the need to identify and respond to various threats, such as rogue devices with unauthorized access, before the network’s integrity can be compromised.

• Device visibility: Many organizations struggle with maintaining visibility into the devices connected to their network. WIDS provides the capability to see all devices in real-time, which is essential for tracking, locating and managing authorized and unauthorized devices.

• Zero trust security: The Zero Trust security model, which assumes that no device should be trusted by default, has gained traction. WIDS aligns with this approach by continuously inspecting and verifying the trustworthiness of devices, even after they gain network access.

• Scalability: As organizations grow, their network security needs to scale accordingly. WIDS is designed to scale with the organization, making it suitable for both small and large enterprises.

• Compliance requirements: Various industries and regulatory bodies have strict compliance and data security requirements. WIDS aids in achieving compliance by ensuring that all wireless devices connecting to the network meet security and policy standards.

  As an example, the PCI Data Security Standard requires that all organizations accepting credit or debit cards for purchases protect their networks from attacks via rogue or unauthorized wireless APs and clients. This applies even if the merchant has not deployed a wireless network for its own use.

  Vertical examples:

  • WIDS helps retailers and other covered organizations comply with these requirements. WIDS Rules also enable companies to set up automated, prioritized alerts that can be emailed to a specified distribution list the instant that rogues are detected.

  • Hospitals use WIDS Rules to protect patient data as well as protect IT and medical systems. They need to know if rogues exist on their network along with critical medical devices use for patient care.

Key features & advantages

The solution improves network security, manages compliance requirements, and reduces the cost of manual security efforts.

Wireless threat protection framework

The threat protection framework defines a continuously repeating process consisting of multiple phases: discover, classify, contain, and alert and audit.

1.3.2 - RF Scanning Methods

Scanning

Radios in an HPE Aruba Networking AP can be configured to scan the wireless network in three different modes: Access Point (AP) mode, Air Monitor (AM) mode, and Spectrum Monitor mode. Each mode is designed to prioritize different tasks.

Access Point mode

Radios in AP mode focus on serving clients and pushing wireless traffic but they also perform IDS detection. Most wireless administrators use this mode in their networks. The information provided by the APs is the basis for detection. IDS detection occurs while the AP is serving clients, ensuring full IDS attack detection within the network. The off-channel scanning will find rogue devices and IDS attacks originating from outside of the network.

AP mode scanning operation

Typically, an AP will perform off channel scanning every 10 seconds for slightly less than 100 milliseconds per channel. This allows the AP to monitor the surroundings without missing beacons and causing connectivity problems for clients. Off-channel scanning has multiple use cases in addition to WIDS/WIPS.

Scanning all regulatory domain channels is recommended. That will include any valid channel in any regulatory domain, not just the regulatory domain of the AP. This is recommended since attackers typically don’t feel the need to follow the law. Detection of a malicious device can be performed on a channel outside the AP’s regulatory domain but the AP cannot perform containment on the channels outside of the assigned regulatory domain. The AP can be restricted to scan just the channels within the assigned regulatory domain but this is not recommended for security conscious customers.

APs use a bucketing based algorithm for channel scanning. When an AP boots up, the channels are classified into two different buckets- regulatory and non-regulatory channels. The regulatory channels are scanned more frequently than the non-regulatory channels. A third bucket of “active” channels is populated as the AP scans and detects channels with wireless traffic. The active bucket is scanned more frequently than the regulatory and non-regulatory channels. This allows the AP to spend the most time on channels where a threat is more likely than on other channels with a lower likelihood of threats.

The APs primarily protect the channel to which they are assigned; APs can additionally be configured to conduct an off-channel scan approximately every 10 seconds for a period of about 100 ms to look for any WIDS events.

Due to the adaptive nature of the scanning algorithm, answering the question of “how much time is required to scan all channels?” is relatively difficult. Typically, all channels will be scanned at least once in less than an hour, with active channels getting scanned much more frequently.

Air Monitor mode

Air Monitors (AMs) are dedicated to wireless security. They do not serve clients and hence do not need to be deployed at the same density as APs. In most cases, a 4:1 or 5:1 ratio of APs to AMs is recommended if containment is needed, but that varies heavily based on AP density, environment, and the types of WIDS/WIPS features enabled.

AM mode scanning operation

AMs use a channel scanning algorithm similar to that of APs but use a fourth bucket of classification for ‘rare’ channels. In raw frequency, that is 2412 through 2484 MHz and 4900 through 5895 MHz in 5 MHz increments. Rare channels include the 4.9 GHz spectrum which is a licensed public safety band in many countries. The 6 GHz band is scanned from 5945 MHz through 7125 MHz, with channel scanning done every 20 MHz using the group scanning technology to be able to catch the maximum channel width supported by the radio.

Due to the analog nature of wireless, we have found that the natural bleed through of RF signals will allow us to find rogues that are configured in between standard channels by scanning every 5 MHz. The channels scanned by an AM are configured in the AM scanning profile which is part of the radio profile.

Scan dwell times are based on the bucketing system. When in AP mode, the off-channel dwell time is quite short to minimize impact for serving client devices and allow for the regular sending of beacons. Since the AM is not serving clients and no beacons are being sent, the AM does not need to be on any particular channel regularly.

Air Monitors (AMs) continuously scan all channels based on an algorithm that divides the RF channels into three buckets (active, regulatory, and rare). The AM will spend ~500 ms on active channels, ~250 ms on regulatory channels, and ~100 ms on rare channels.

The exact channel that is scanned will be chosen randomly. The dwell times listed above are slightly randomized to ensure that a rogue cannot predict exactly when it can and cannot transmit to avoid detection.

AMs scan the active channels more frequently than regulatory channels, which are scanned more frequent than rare channels. The exact time to cycle through all the channels varies due to the algorithm noted above. To scan through all regulatory channels can take approximately 5 minutes. The APs and AMs can demodulate, monitor, and detect IEEE 802.11 standards and protocols.

Channels will be promoted to the active channel list at any time based on the detection of Wi-Fi activity. If no activity is seen for a significant period, the channel will be demoted back to the original bucket.

Spectrum monitor

Wireless networks operate in environments with electrical and radio frequency devices that can interfere with network communications. Microwave ovens, cordless phones, and even adjacent Wi-Fi networks are all potential sources of continuous or intermittent interference. The APs that support the spectrum analysis software module and configured in spectrum monitor (SM) mode are able to examine the radio frequency (RF) environment in which the Wi-Fi network is operating, identify interference, and classify the source of the interference. An analysis of the results can then be used to quickly isolate issues with packet transmission, channel quality, and traffic congestion caused by contention with other devices operating in the same band or channel.

AP radios operating in SM mode will gather spectrum data but do not service clients. Each SM will scan and analyze the spectrum band serviced by the SM’s radio. An AP radio in hybrid AP mode will continue to serve clients as an access point while also analyzing spectrum analysis data for the channel the radio uses to serve clients. The option for recording of the data from both types of spectrum analysis devices is available, which allows for saving of that data for later playback and analysis.

Wired rogue AP detection and correlation

The gateway has a few different methods to assist with determining whether or not an AP discovered on the network is a rogue.

The most basic method is a +/- 1 last octet MAC address check if traffic that has been on the wire and seen wirelessly. If wired traffic is observed with a MAC address that is within 1 digit of the wireless MAC, that device will be tagged as a wired rogue. Example, MAC addresses 64-16-4A-54-E4-72 and 64-16-4A-54-E4-71 would be detected as a rogue device.

There are a few more sophisticated methods as well. The APs and AMs will monitor traffic detected over the air and determine if that traffic originated on the wired network by checking if the wireless traffic matches any of the known wired gateway MAC addresses. The list of known wired gateway MAC addresses is built up by the gateway, APs, and AMs. For this functionality to operate correctly, all client facing VLANs need to be trunked to either the gateway, an AP, or an AM. While traffic needs to be trunked only to one AP or AM for the detection to work, the recommendation is to trunk the VLANs to all of the APs or AMs that are deployed. Wired containment requires this setup and is discussed in the chapter regarding containment.

Central will check the bridge forwarding tables and the ARP tables to gather rogue information from the network. The bridge forwarding table gives the mapping of wired MAC addresses to switch ports. The ARP table gives a mapping of wired MAC addresses and IP addresses. Central will then correlate the list of wired MAC addresses with everything that has been heard over the air. If two MAC addresses are within a configurable offset, they will be considered the same device and linked together.

For best results the recommendation is that only the attack detection that is worth investigating is turned on. Security-minded customers may choose the High option. The High option does not enable every event that can be detected by the HPE Aruba Networking system. For example, NetStumbler detection is not turned on by default. NetStumbler detection means that a client device is running an old scanning system and does not necessarily mean that the network was compromised. Custom settings can be chosen that allow the administrator to enable or disable every attack detection individually if they choose to do so.

1.3.3 - Detection

Infrastructure intrusion detection

Detecting attacks against the infrastructure is critical for avoiding attacks that may lead to a large-scale DoS attack or a security breach. HPE Aruba Networking Central offers a suite of signature selections to help detect 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 HPE Aruba Networking AP or a third-party AP. The WIDS application automatically learns about authorized HPE Aruba Networking APs.

For a full list of AP classifications, refer to the Classification topic.

Client intrusion detection

Generally, clients are more vulnerable to attacks than APs. Clients are more likely to associate with a malicious AP due to the client’s driver behavior or a misconfigured client. Monitoring of authorized clients is important to track their associations and to detect any attacks raised against them.

Client intrusion detection includes, but is not limited to the following:

Detecting attacks against 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 misassociations of authorized clients is very important.

An authorized client is a client authorized to use the WLAN network. For HPE Aruba Networking Wireless Operating System (AOS) , an authorized client is called a valid client. AOS automatically learns a valid client. A client is determined to be valid if associated to an authorized or valid AP using encryption; either Layer 2 or IPsec.

For a full list of client classifications, refer to the Classification topic.

Levels of detection

The detection settings on HPE Aruba Networking Central for both infrastructure and clients can set to the different levels depending on the security requirements of the organization.

• High - Enables all the available detection mechanisms

• Medium - Enables most of the important detection mechanisms

• Low - Enables the most critical detection mechanisms

• Off - Disables all detection mechanisms

• Custom - Allows the selection of desired detection mechanisms

1.3.3.1 - Infrastructure Event Detection Levels and Signature Descriptions

Infrastructure Event Detection Levels

The available detection levels that can be configured for infrastructure events.

Low

• Detect AP Spoofing

• Detect Windows bridge

• IDS signature - de-authentication broadcast

• IDS signature - de-association broadcast

Medium

• Detect ad hoc networks using valid SSID – Valid SSID list is auto configured based on the AP configuration.

• Detect malformed frame large duration

High

• Detect AP impersonation

• Detect ad hoc networks

• Detect valid SSID misuse

• Detect wireless bridge

• Detect 802.11 40 MHz intolerance settings

• Detect active 802.11n greenfield mode

• Detect AP food attack

• Detect client flood attack

• Detect bad WEP

• Detect CTS rate anomaly

• Detect RTS rate anomaly

• Detect invalid address combination

• Detect malformed frame – HT IE

• Detect malformed frame association request

• Detect malformed frame – auth

• Detect overflow IE

• Detect overflow EAPOL key

• Detect beacon wrong channel

• Detect devices with invalid MAC OUI

• Detect ghost tunnel server attack

Infrastructure Events - Names and Descriptions

A listing of the available infrastructure event signatures along with the description from the user guide and engineering.

Detect 802.11n 40 MHz Intolerance Setting

When a client sets the HT capability intolerant bit to indicate that it is unable to participate in a 40 MHz BSS, the AP must use lower data rates with all its clients. Network administrators often want to know if there are devices that are advertising 40 MHz intolerance, as this can impact the performance of the network.

This would be enabled to indicate if any clients have set the intolerance bit when HT40+ ESSIDs are configured or monitored. When clients have the intolerance bit set, it can diminish the channel throughput. This is not a security related issue. Recommend Disable.

Detect Active 802.11n Greenfield Mode

When 802.11 devices use the HT operating mode, they cannot share the same channel as 802.11a/b/g stations. Not only can they not communicate with legacy devices, but the way they use the transmission medium is different, which would cause collisions, errors, and retransmissions.

This can generate verbose alerts if a nearby WLAN is broadcasting in Greenfield mode. Greenfield though is very rare anymore. Recommend Disable.

Detect Ad hoc Networks

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.

This can generate VERY verbose alerts, as things like printers, mobiles with Ad hoc enabled, etc. are enabled. Recommend disable unless there is firm control of the devices within the WLAN coverage area where an Incident Response Team can investigate and remediate alerts, or if the environment is a high-security customer where policy dictates that Ad hoc devices be detected.

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.

While this should be more rare than basic Ad hoc detection, as it would require the Ad hoc network to be configured with a valid ESSID, which while it should be rarer, would indicate malicious intent. Recommend enable for any security conscious customers.

Detect AP Flood Attack

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.

If large reports of client disconnects are a concern, this can be enabled. This can be a high false-positive signature depending on the thresholds configured. False alarms can happen if APs or gateways reboot and the signature re-triggers. It can also trigger a false alert if the AP/AM table is full (254 BSSIDs seen, which can be increased but consumes more AP processing power). Recommend enable for any high security conscious customer.

Detect AP Impersonation

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.

This is a very explicit type of attack where a bad actor is spoofing a valid ESSID/BSSID. If proper security is in place (WPA2 using RADIUS and valid certs with validation enabled, etc.), the risk is minimal. WPA2-PSK should use VERY strong passphrases. Open SSIDs would be vulnerable. Recommend disable unless there are managed WLANs that are ‘Open’, or the customer is a high security conscious customer.

Detect Wireless Hosted Network

If enabled, this feature can detect the presence of a wireless hosted network.

When a wireless hosted network is detected this feature sends a “Wireless Hosted Network” warning level security log message and the wlsxWirelessHostedNetworkDetected SNMP trap. If there are clients associated to the hosted network, this feature will send a “Client Associated To Hosted Network” warning level security log message and the wlsxClientAssociatedToHostedNetworkDete cted SNMP trap.

Detect WIFI-Direct P2P Groups

AOS now supports the detection and containment of devices associated to Wi-Fi Direct groups. Wi-Fi Direct is a form of a Wireless Hosted Network and shares many of the same features and concepts with Wireless Hosted Networks, such as:

• The concepts of a Hosted Network group and group leader.

• The softAP put up as a BSS that clients may associate with.

• The derivation of the BSSID of the softAP, although different devices behave differently.

• The ability for devices to BOTH be connected to WLAN Infrastructure and host a Wireless BSSID simultaneously.

• The ability for a device to allow sharing, or access from one network to the other.

Detect AP Spoofing

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.

Can be used by attackers to force client rekeying, to more quickly determine an encryption key (ala with weak WPA2-PSK). Recommend enable.

Detect Bad WEP

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 and searching for such weak implementations that are still used by many legacy devices.

WEP should no longer be in use anywhere. Recommend disable unless the goal is protection of an antiquated WEP-based WLAN.

Detect Beacon Wrong Channel

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.

Prone to false positives as it can trigger when nearby or monitored WLANs change channels often (which is VERY common), would only be applicable if seen in VERY large quantities, and even then, is likely a false positive. Recommend disable.

Detect Client Flood

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.

Can be enabled but is generally an attack on the WIDS. Similar to AP Flood, and can result in false positives. If enabled, thresholds should be enabled up to 150. Recommend disable unless a high security conscious customer.

Detect RTS Rate Anomaly

The RF medium can be reserved via Virtual Carrier Sensing using a clear to send (CTS) transaction. The transmitter station sends a Ready To Send (RTS) frame to the receiver station. The receiver station responds with a CTS frame. All other stations that receive these 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.

Very common false positive, generally indicative of bad client drivers, and requires the baselining of the known client environment to know what is ’normal’ versus what is ‘abnormal’. Is mostly a DoS-based type of attack to disrupt transmission. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining.

Detect CTS Rate Anomaly

The RF medium can be reserved via Virtual Carrier Sensing using an RTS transaction. The transmitter station sends a RTS frame to the receiver station. The receiver station responds with a CTS frame. All other stations that receive these RTS 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.

Very common false positive, generally indicative of bad client drivers, and requires the baselining of a known client environment to know what is ’normal’ versus what is ‘abnormal’. Is mostly a DoS-based type of attack to disrupt transmission. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining.

Detect Device with a Bad 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.

Very verbose false positives. Triggered by both virtual-MACs as well as the proliferation of new MAC Address OUIs being constantly released. Recommend disable.

Detect Invalid Address Combination

In this attack, an intruder can cause an AP to transmit deauthentication and disassociation frames to all its clients. Triggers that can cause this condition include the use of broadcast or multicast MAC address in the source address field.

This is a DOS-type of attack to the WLAN. Malformed frames can trigger this, bad client drivers, neighboring bad APs, etc. Very high false positive rates, generally NOT a security threat. Recommend disable unless customer is a high security conscious customer where all client devices are managed, tested, and tracked.

Detect Overflow EAPOL Key

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.

Recommend disable unless HPE Aruba Networking WIDS is an overlay. Will likely show false positives for poorly performing clients, or very dense client environments. Only enable if HPE Aruba Networking WLAN is the overlay, and customer is high security conscious.

Detect Overflow IE

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.

Recommend disable unless HPE Aruba Networking WIDS is an overlay. Will likely show false positives for poorly performing clients, or very dense client environments. Only enable if HPE Aruba Networking WLAN is the overlay, and customer is high security conscious.

Detect Malformed Frame Association 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.

Recommend disable unless HPE Aruba Networking WIDS is an overlay. Will likely show false positives for poorly performing clients, or very dense client environments. Only enable if HPE Aruba Networking WLAN is the overlay, and customer is high security conscious.

Detect Malformed Frame Auth

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 an Authentication frame.

Recommend disable unless HPE Aruba Networking WIDS is an overlay. Will likely show false positives for poorly performing clients, or very dense client environments. Only enable if HPE Aruba Networking WLAN is the overlay, and customer is high security conscious.

Detect Malformed Frame-HT IE

The IEEE 802.11n HT (High Throughput) IE is used to convey information about the 802.11n network. An 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.

Recommend disable unless HPE Aruba Networking WIDS is an overlay. Will likely show false positives for poorly performing clients, or very dense client environments. Only enable if HPE Aruba Networking WLAN is the overlay, and customer is high security conscious.

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.

Recommend disable. Will likely show false positives for poorly performing clients, or very dense client environments, as other vendor’s APs often send Large Duration frames. Leads to large duration to an extended hold down timers.

Detect Misconfigured AP

A list of parameters can be configured to define the characteristics of a valid AP. This feature is primarily used when non-HPE Aruba Networking APs are used in the network, since the HPE Aruba Networking gateway cannot configure the thirdparty APs. These parameters include WEP, WPA, OUI of valid MAC addresses, valid channels, and valid SSIDs.

Recommend disable unless there is a 3rd party WLAN being monitored. May often show false positives from poorly performing clients or dense client environments. May catch an AP spoofing in different location. If enabled, it’s only for high security conscious customers with controlled physical environments, and limited neighboring WLANs.

Detect Windows Bridge

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.

Recommend enable for security conscious customers. Should generally be a low false positive alert.

Detect Wireless Bridge

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.

Recommend enable, though non-HPE Aruba Networking wireless bridges must be marked as ‘Valid’. Does not trigger on ArubaOS Mesh but may trigger on other vendor’s mesh solutions.

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.

Recommend enable, may require on-site troubleshooting to narrow own source.

Detect Broadcast Dissociation

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.

Recommend enable, may require on-site troubleshooting to narrow own source.

Detect NetStumbler

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.

Recommend disable, is not a common threat vector anymore.

Detect Valid SSID Misuse

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.

Recommend enable.

Detect Wellenreiter

Wellenreiter is a passive wireless network discovery tool used to compile a list of APs along with their MAC address, SSID, channel, and 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.

Recommend disable, as it’s based on WEP and WEP should NOT be in use anymore.

1.3.3.2 - Client Event Detection Levels and Signature Descriptions

Client Event Detection Levels

The available detection levels that can be configured for client events.

Low

• Detect valid client mis-association

Medium

• Detect Disconnect Station Attack

• Detect Omerta Attack

• Detect FATA-Jack Attack

• Detect Block ACK DoS

• Detect Hotspotter Attack

• Detect unencrypted valid client

• Detect Power Save DoS Attack

High

• Detect EAP rate anomaly

• Detect rate anomaly

• Detect Chop Chop Attack

• Detect TKIP Replay Attack

• IDS signature – Air Jack

• IDS signature – ASLEAP

• Detect ghost tunnel client attack

Client Events - Names and Descriptions

A listing of the available client event signatures along with the description from the user guide and engineering.

Detect Block ACK DoS

The Block ACK mechanism that was introduced in 802.11e, and enhanced in 802.11n D3.0, has a built-in DoS vulnerability. The Block 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.

Very prone to false positives from low SNR clients, as well as other mobile devices with poor client driver behavior. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining.

Detect ChopChop Attack

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.

Recommend disable, as this attack is based on WEP and WEP should NOT be in use anymore.

Detect Disconnect Station Attack

A disconnect attack can be launched in many ways; the result is that the client is effectively and repeatedly disconnected from the AP.

Prone to false positives based on how some clients disassociate/disconnect from Wi-Fi. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining.

Detect EAP Rate Anomaly

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 clients 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.

Prone to false positives in EAP environments. If proper security is in place (WPA2 using RADIUS and valid certs with validation enabled, etc.), the risk is minimal. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining.

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.

Recommend enable unless WIDS is monitoring open/public WLAN networks.

Detect Hotspotter Attack

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 SSIDs, these malicious APs respond and invite the client to connect to them. When the client connects to a malicious AP, several security attacks can be launched on the client. Airsnarf is a popular hacking tool used to launch these attacks.

Recommend disable, especially for dense WLAN environments or when the monitored WLAN is within/surrounded by many neighboring WLANs. Very high false positives, and most threats are covered by other WIDS signatures.

Detect a 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.

High false positives are possible in dense environments or where clients roam rapidly in short periods of time. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining, as clients are very PS-Poll aggressive.

Detect Omerta Attack

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 used under normal circumstances.

While exact device identification is impossible due to the nature of the attack, general localization of the alert is possible. Recommend enable.

Detect Rate Anomalies

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.

Prone to false positives in dense environments, or areas where large numbers of clients and/or APs are located. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining, as clients are very PS-Poll aggressive.

Detect TKIP Replay Attack

TKIP is vulnerable to replay (via WMM/QoS) and plaintext discovery (via ChopChop). This affects all TKIP usage in WPA and WPA2. 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.

Would only be enabled if there is a TKIP-based SSID being monitored. All SSIDs now should be WPA2-based (using AES instead of TKIP). Recommend disable unless customer has a TKIP-based SSID WLAN.

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.

Recommend enable, unless one of the monitored WLANs are open. Should not be enabled where Open SSIDs are being monitored as it will generate a large number of alerts.

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 monitored are:

1. Authorized Client associated to Rogue: A valid client that is associated to a rogue AP.

2. Authorized Client associated to External AP: An external AP, in this context, is any AP that is not valid and not a rogue.

3. 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.

4. Authorized Client in ad hoc connection mode: A valid client that has joined an ad hoc network.

Recommend enable for any high security conscious customers where clients should NOT be connecting to non-HPE Aruba Networking or non-Monitored WLAN SSIDs.

Detect AirJack

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 allowing users to force all users off an AP.

Recommend disable, except maybe for very high security conscious customers.

Detect ASLEAP

ASLEAP is a tool created for Linux systems used to attack Cisco LEAP authentication protocol.

Recommend disable unless the HPE Aruba Networking WIDS is an overlay monitoring a Cisco WLAN that uses LEAP.

Detect Null Probe Response

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. Several popular NIC cards will lock up upon receiving such a probe response.

Recommend disable unless large numbers of disconnects are seen with an unknown cause. Most modern NICs are NOT vulnerable.

1.3.4 - Classification

Upon detection, APs and client devices must be accurately classified to determine whether they are valid, interfering, or rogues.

Terminology

APs and clients that are discovered during scanning of the wireless channels are classified into different groups.

AP definitions

Client definitions

Methods

A discovered device is classified into one of the above definitions by the following methods:

• Internal heuristics

• Device level classification

• Rule-based calssification

• Manual classification

Device level classification

Device classification is a combination of cloud processing and edge processing. By default, HPE Aruba Networking access points can continuously monitor the network and discover rogue access points without intervention from Central. Central classification, when enabled, takes precedence.

Internal heuristics

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.

Match methods

The match methods are:

• Plus One - The MAC address detected correlates with the MAC address of an already detected device, with the last bit of the MAC address being one more than that of the Match MAC.

• Minus One - The MAC address detected correlates with the MAC address of an already detected device, with the last bit of the MAC address being 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.

Match types

Eth-Wired-MAC

The MAC addresses of wired devices learned by an AP on the Ethernet interface.

GW-Wired-MAC

The collection of Gateway MACs of all managed devices.

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.

Classification-off

AP is classified as rogue because classification has been disabled, causing all non-authorized APs to be classified as rogue.

Propagated-Wired-MAC

The MAC addresses of wired devices learned by an AP other than the AP that used the information 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. For HPE Aruba Networking OUIs, if the base BSSID of a beacon matches the base BSSID of a known valid BSSID then the new BSSID is not considered to be valid.

AP-Rule

A user-defined AP classification rule has matched.

System-Wired-MAC

The MAC addresses of wired devices learned on the managed device.

System-Gateway-MAC

The Gateway MAC addresses learned on the managed device.

Rule-based classification

Rules available for classification is dependent on the environment being used and is different for AOS 8 vs AOS 10.

Mobility Conductor (AOS-8)

AP classification rule configuration is only performed on a Mobility Conductor. A rule is identified by the ASCII character string name (32 characters maximum). The AP classification rules have three possible specifications.

SSID of 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 not match all the SSIDs can be specified. The default is to check for a match operation.

SNR of the AP

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 or the number of APs that can see the AP

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.

Central (AOS-10)

WIDS rules in Central work in conjunction with the WIDS Module on the AP. While the APs are not dependent on Central to detect rogue events, Central classifications take precedence over device level classifications.

With WIDS in Central, administrators can create a detailed definition of what constitutes a rogue device, and quickly act on a rogue AP for investigation, restrictive action, or both.

AP classification rule configuration is performed on Central. There are three default rules available to help classify rogue and suspected rogue devices, with the ability to create custom rule sets based on different criteria such as detecting AP count, SSID value, time spent on the network, etc. The Rule Classification Criteria page describes all the available criteria that are configurable in Central.

Manual classification

With this method, the wireless administrator monitors the IDS events and manually re-classifies one or more devices to a particular definition such as Interfering, Suspected Rogue or Rogue.

Classification hierarchy

WIDS uses a hierarchy to classify detected devices:

1. Interfering

2. Suspected Rogue

3. Rogue

4. Neighbor (Known Interfering)

5. Manually Contained (DoS)

6. Valid

In the lifecycle of a monitored AP, the classification can only be promoted (i.e., go higher in the list) and can never be demoted (i.e., reduced to a lower value).

This same behavior also applies to the custom rules. For example, if a neighbor AP is already classified as Rogue, then any subsequent rule match will never demote the classification to Suspected Rogue.

1.3.5 - Protection

WIDS offers a wide selection of protection features to protect the network against the threats detected. Device detection and classification are the first steps in securing the network environment from unauthorized wireless access. Adequate measures that quickly shut down intrusions are critical in protecting sensitive information and network resources.

Intrusion protection features support containment of an AP or a client device. In the case of an AP, all the clients that are connected or attempting to connect to the AP are disconnected. In the case of a client, the client’s association to an AP is targeted.

The following containment mechanisms are supported:

• Wired containment - When enabled, APs generate ARP packets on the wired network to contain wireless attacks.

This feature enables containment from the wired side of the network. The basic wired containment feature isolates layer-3 APs whose wired interface MAC addresses are the same as (or one character off from) their BSSIDs. The enhanced wired containment feature can also identify and contain an AP with a preset wired MAC address that is completely different from the AP’s BSSID. In many non-HPE Aruba Networking APs, the MAC address the AP provides to wireless clients as a gateway MAC is offset by one character from its wired MAC address. This enhanced feature allows AOS to check to see if a suspected Layer-3 rogue AP’s MAC address follows this common pattern.

Recommend enable. Wired rogue detection is based on MAC pattern assumption and is a valid mechanism to protect your wired network from rogues. Both Security and Legal should be consulted and approval given before it is enabled in the network.

• Wireless containment - When enabled, the system attempts to disconnect all clients that are connected or attempting to connect to the identified access point.

Infrastructure intrusion protection options

The following are the protection options that can be enabled in HPE Aruba Networking Central against infrastructure intrusion events.

Protection Against Rogue Containment

By default, rogue APs are not automatically disabled. Rogue containment automatically disables a rogue AP by preventing clients from associating to the AP.

This option is disabled by default, as this has far reaching implications regarding the FCC and possible fines. Both Security and Legal should be consulted and approval given before it is enabled in the network. Tarpitting should be the preferred method of containment.

Protecting SSIDs

Protect SSID enforces that valid/protected SSIDs are used only by valid APs. An offending AP is contained by preventing clients from associating to the AP.

This can be a problem for Govroam and eduroam, as just two examples. This should not be enabled as the behavior has far reaching implications regarding the local regulatory body and possible fines. Both Security and Legal should be consulted and approval given before enabling this functionality.

Protection Against AP Impersonation

Protection from AP impersonation involves containing both the legitimate and impersonating AP so that clients cannot connect to either AP.

Should not be enabled, can be disruptive. If enabled, it should only be done when all AP impersonation alerts have been verified.

Protecting Against Ad Hoc Networks

Protection from an ad hoc network involves containing the ad hoc network so that clients cannot connect to the offending device.

If needed, this feature should be enabled with caution as there could be an impact to WLAN quality as much of the airtime would be spent de-authenticating ad hoc devices.

Legacy options in AOS 8

Protecting 40 MHz 802.11n High Throughput Devices

Protection from AP(s) that support 40 MHz HT involves containing the AP such that clients cannot connect.

Recommend to disable, has HUGE implications. Is a legacy setting and should never be enabled.

Protecting 802.11n High Throughput Devices

Protection from AP(s) that support HT involves containing the AP such that clients cannot connect.

Recommend to disable, has HUGE implications. Is a legacy setting and should never be enabled.

Protection Against Misconfigured APs

Protect Misconfigured AP enforces that valid APs are configured properly. An offending AP is contained by preventing clients from associating to the AP.

Should not be enabled except in high security areas where no other BSSIDs/ESSIDs can be seen (only in isolated WLAN environments where there are no neighboring buildings). Has far-reaching implications where neighboring WLANs could be disrupted. Approved non-HPE Aruba Networking WLANs would need to be marked as Valid.

Protection Against Wireless Hosted Networks

Clients using the Windows wireless hosted network feature can act as an access point to which other wireless clients can connect, effectively becoming a Wi-Fi HotSpot. This creates a security issue for enterprises because unauthorized users can use a hosted network to gain access to the corporate network, and valid users that connect to a hosted network are vulnerable to attacks or security breaches. This feature detects a wireless hosted network, and contains the client hosting this network.

This should be disabled, as this has far reaching implications regarding the FCC and possible fines. Both Security and Legal should be consulted and approval given before this is ever enabled at any customers site.

Protecting Against Suspected Rogue Containment

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 the rogue device.

This should be disabled, as this has far reaching implications regarding the FCC and possible fines. Both Security and Legal should be consulted and approval given before this is ever enabled at any customers site. This is the most dangerous of containment as suspect rogue alerts are only based on confidence levels and can easily be misconfigured.

Client intrusion protection options

The following are the protection options that can be enabled in HPE Aruba Networking Central against client intrusion events.

Protecting Valid Stations

Protecting a valid client involves disconnecting the client if associated to a non-valid AP.

Recommend disable. If looking to enable, Great care should be used here to make sure no valid clients that associate to the monitored WLAN could associate to another non-valid WLAN. If hotspots, restaurants, etc. are nearby, there is a good chance a valid station could go off-site and associate to the non-valid.

Protecting Windows Bridge

Protecting from a Windows Bridge involves containing the client that is forming the bridge so that the client cannot connect to the AP.

Recommend disable, unless Detect Windows Bridges are seen, and investigations show they are not false-positives.

Containment on APs vs. AMs

APs in both Access Point mode and Air Monitor mode detect and mitigate possible security threats in a wireless network.

APs can perform wireless containment, but they will prioritize client traffic over containment. This is a very important distinction and the reason why Air Monitors (AMs) are recommended if wireless containment is enabled. For example, if an AP is serving clients on Channel 36 and there is a rogue on Channel 48 the AP will not change channels to contain the rogue. If the rogue happens to be on channel 36, the AP will perform wireless containment while serving clients.

AMs in contrast will alter their scanning algorithm when containing to make sure they visit the channel where containment is occurring frequently. They will continue to scan for additional threats on other channels.

Both APs and AMs support containment of rogue APs and prevent clients from associating with rogue APs. They tarpit or deauthentication containment frames if any of the following criteria is met:

• When an AP is marked for Denial-of-Service (DoS), a single broadcast deauthentication frame is sent for disassociation and if stations do not honor the broadcast message, two unicast deauthentication frames are sent to disassociate the station from the AP and vice versa.

• To disassociate a valid station from the non-valid AP, a unicast deauthentication frame is sent from the station’s MAC address to the AP and vice versa.

• AP impersonation is active, and it disassociates all stations from the invalid AP by sending unicast deauthentication frames.

1.3.6 - Configuring, Monitoring and Reporting WIDS

Configuring WIDS

Captured below are the typical configuration workflows for WIDS in HPE Aruba Networking Central. For step-by-step instructions, refer to the Central user documentation.

Enabling rule classification

To enable WIDS, navigate to the Configuration option under the Security tab, and enable the toggle to start monitoring for Rogue APs and create classification rules.

Follow the Central user documentation for step-by-step instructions on enabling WIDS rules.

Configuring rules

After enabling WIDS in the UI, the set of three default classification rules will take effect and a maximum of 32 custom rules can be configured. Multiple conditions can be defined in a single rule, and they are all used with an “AND” operand, which means that a rule will only be applied if all the criteria in that rule are matched.

Follow the Central user documentation for step-by-step instructions on creating and configuring custom rules.

Rule ordering matters as rules are evaluated from top to bottom in the custom rule list. Whenever a rule match is found, that rule is executed and no further rule evaluation takes place. Ordering of the rules from lower classifications to higher classifications is important for proper operation. If a neighbor AP gets manually classified by the administrator, then no rules will be evaluated for that AP. If the classification rule selects a non-final state classification (i.e., Interfering or Suspected Rogue), then AP rogue detection algorithms will continue to be applied at the edge where further monitoring of the AP may result in the determination that the AP is in fact a rogue and have the classification updated accordingly.

Monitoring WIDS events

Rogue events

The Rogues tab provides a list of all the APs that have been detectd in the network and their corresponding classifications.

The Central user documentation captures more details on interpreting rogue events and device classifications.

WIDS events

The IDS tab provides a list of potential threats detected by HPE Aruba Networking access points at the infrastructure and client levels.

Central consolidates multiple attacks within a single event to reduce noise. Each displayed event corresponds to a specific MAC address, where multiple events (if generated) are aggregated for each of those MAC addresses.

• Multiple APs reporting the same event

• Several attacks against the same MAC address

Use the Central user documentation for instructions on interpreting each of the different fields in the event view.

Generating WIDS alerts

Wireless administrators can set up alerts for different types of infrastructure and client attacks. For instructions, check out the Central user documentation.

Generating WIDS reports

HPE Aruba Networking Central provides administrators the ability to generate reports for IDS events. For details on creating reports, refer to the Central user documentation.

1.4 - Client authentication options and operations

1.4.1 - RADIUS Accounting

RADIUS accounting is a method of collecting resource consumption data to be forwarded to a RADIUS server. This data can be used for trend analysis, capacity planning, billing, auditing, and cost analysis. The Network Access Server (NAS) is a RADIUS client responsible for passing user accounting information to the RADIUS server. The server receives this request and returns a response to the NAS.

In AOS-8 campus deployments, RADIUS accounting messages are always sent directly from the controller that functions as the NAS. When a client device roams between APs, the controller continues sending interim updates without the need for a stop and a new start message.

In AOS-10 deployments, the accounting behavior differs based on the deployment scenario:

1. Bridge mode - A deployment with only APs.
2. Tunneled and mixed modes - Deployments that involve gateways.

For RADIUS accounting in AOS-10, two key attributes are explored.

1. Acct-Multi-Session-Id: Identifier remains constant across related sessions, such as during client roaming and links multiple events into a single logical session for seamless tracking.
2. Acct-Session-Id: Unique identifier changes with each new session, such as when a client re-authenticates with a different AP, helping to track individual session events.

Bridge mode - no roaming

In bridge mode without client roaming, each access point (AP) handles traffic forwarding directly to the local VLAN where the client resides. The AP acts as the NAS for the client, and is responsible for initiating and managing RADIUS communications.

In this scenario, RADIUS accounting messages are sent by the AP. Since there is no roaming involved, a single Acct-Session-Id is used for the duration of the connection, and no changes to the Acct-Multi-Session-Id is necessary.

Accounting start: When the client connects to the AP, the AP sends a ‘Start’ message to the RADIUS server.

Accounting interim update: If interim updates are enabled, the AP sends an ‘Alive’ update to the RADIUS server.

Accounting stop: When the client disconnects with the AP, a ‘Stop’ message is sent from the AP to the RADIUS server.

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  4 15:15:14.651  rad-acct-start   ->                  1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70/clearpass  -   -   
Nov  4 15:23:32.051  rad-acct-int-update   ->             1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70            -   -       
Nov  4 15:24:06.517  eap-logoff   ->                      1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70            -   -    
Nov  4 15:24:06.517  dot1x-timeout *                      1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70            11  512  station timeout
Nov  4 15:24:06.527  rad-acct-stop   ->                   1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70/clearpass  -   -    
AP-8-635# show clock                  

Current Time     :2024-11-04 15:24:32
AP-8-635#

Tunnel mode - no roaming

In tunnel mode without client roaming, traffic from the client is tunneled from the AP to the gateway. The gateway acts as a RADIUS proxy and forwards authentication and accounting requests for all tunnel-mode clients. To learn more about Tunnel forwarding mode, refer to Tunnel Forwarding.

In this configuration, RADIUS accounting messages originating from the AP is sent to and forwarded by the gateway, ensuring consistent tracking and accounting of client sessions. Since there is no client roaming involved, the accounting behavior is straightforward, with a single Acct-Session-Id and Acct-Multi-Session-Id assigned and maintained for the duration of the client’s session.

Accounting start: When a client associates to an AP, an accounting ‘Start’ request is sent from the AP and forwarded by the gateway to the RADIUS server.

Accounting interim update: If interim updates are enabled, the gateway forwards an ‘Alive’ update to the RADIUS server.

Accounting stop: When the client disconnects from the AP, an accounting ‘Stop’ request is sent from the AP and forwarded by the gateway to the RADIUS server.

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  4 15:38:32.494  rad-acct-start   ->                  26:08:2c:70:91:b9  74:9e:75:41:7c:71/__gw_172.30.32.21  -   - 
Nov  4 15:38:33.605  rad-acct-int-update   ->             26:08:2c:70:91:b9  74:9e:75:41:7c:71                    -   -   
Nov  4 15:41:36.080  eap-logoff   ->                      26:08:2c:70:91:b9  74:9e:75:41:7c:71                    -   -    
Nov  4 15:41:36.081  dot1x-timeout *                      26:08:2c:70:91:b9  74:9e:75:41:7c:71                    11  512  station timeout
Nov  4 15:41:36.093  rad-acct-stop   ->                   26:08:2c:70:91:b9  74:9e:75:41:7c:71/__gw_172.30.32.21  -   -    
AP-8-635# show clock

Current Time     :2024-11-04 15:42:06
AP-8-635#  

Mixed mode - no roaming

In mixed mode with no client roaming, both tunneled and bridged client sessions rely on the gateway as the RADIUS proxy. In this scenario, with no client roaming, Acct-Session-Id and Acct-Multi-Session-Id remain stable, simplifying RADIUS accounting and maintaining a consistent session context throughout the client’s connection. To learn more about mixed mode, refer to Mixed Forwarding.

Bridged client sessions

When the mixed mode WLAN client session is handled as bridged, client traffic is bridged at the AP level, with user VLANs assigned directly on the AP. However, the gateway still forwards all RADIUS communications as the proxy, including accounting messages.

Accounting start: When a client associates to an AP, an accounting start request is sent from the AP and forwarded by the gateway to the RADIUS server.

Accounting interim update: If interim updates are enabled, the gateway forwards an ‘Alive’ update to the RADIUS server.

Accounting stop: When the client disconnects from the AP, an accounting ‘Stop’ request is sent from the AP and forwarded by the gateway to the server.

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  4 16:40:10.729  rad-acct-start   ->                  ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72/__gw_172.30.32.22  -    -  
Nov  4 16:40:10.950  rad-acct-int-update   ->             ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72                    -    -  
Nov  4 16:41:47.646  rad-acct-stop   ->                   ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72/__gw_172.30.32.22  -    -  

Tunneled client sessions

For mixed mode WLAN client sessions handled as tunneled, the gateway acts as the RADIUS proxy, with the gateway’s IP address used as the NAS IP. RADIUS accounting messages for these clients is forwarded by the gateway, centralizing session and accounting management.

Accounting start: When a client associates to an AP, an accounting ‘Start’ request is sent from the AP and forwarded by the gateway to the RADIUS server.

Accounting interim update: If interim updates are enabled, the gateway forwards an ‘Alive’ update to the RADIUS server.

Accounting stop: When the client disconnects with the AP, an accounting ‘Stop’ request is sent from the AP and forwarded by the gateway to the server.

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  4 16:40:10.729  rad-acct-start   ->                  ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72/__gw_172.30.32.22  -    -   
Nov  4 16:40:10.950  rad-acct-int-update   ->             ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72                    -    -  
Nov  4 16:41:47.646  rad-acct-stop   ->                   ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72/__gw_172.30.32.22  -    -  

Bridge mode with roaming

In bridge mode with client roaming, user traffic is locally bridged to the VLAN at each AP. As the client moves between APs, each AP independently acts as the NAS for its connected clients and handles RADIUS communications.

RADIUS Accounting Behavior: When a client roams from one AP to another, the new AP takes over as the NAS, and a new RADIUS accounting start message is generated by this AP. The initial AP sends an accounting stop message to indicate the AP’s end of session management for that client. This ensures accurate tracking and accounting of client sessions across multiple APs.

Typically, each new connection triggers a change to the Acct-Session-Id, while a consistent Acct-Multi-Session-Id can link these related events for session continuity tracking.

Here’s how accounting messages are exchanged during a client roam from one AP to another:

Accounting start with the Initial AP: When the client connects to the initial AP, the AP sends an accounting start message to the RADIUS server. This message includes updated information about the AP the client is connected to.

Similarly, for interim updates:

Accounting stop for Initial AP: After the client has roamed, the AP sends an Accounting stop message for the session associated with the initial AP (AP-8-635). This closes out the session tied to that AP.

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  5 16:52:54.440  rad-acct-start   ->                  1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70/clearpass  -   -    
Nov  5 16:56:13.211  rad-acct-int-update   ->             1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70            -   -    
Nov  5 17:01:13.804  rad-acct-int-update   ->             1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70            -   -    
Nov  5 17:04:30.932  rad-acct-stop   ->                   1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70/clearpass  -   -    
AP-8-635# 

Note the multi Acct-Session-Id: val=26082C7091B9-1730847899 and the Acct-Session-Id : val=749E75417C71-26082C7091B9-672AA529-2D70E

Accounting start from the new AP: Once, the client connects to the new AP, the AP sends an Accounting Start msg for the new session with the new AP (AP-3-635).

Interim updates will proceed from the new AP as usual.

Buffer trace of this process:

AP-6-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  5 17:04:43.601  rad-acct-start   ->                  1a:3a:2c:f7:f5:75  74:9e:75:41:79:70/clearpass          -   -    
Nov  5 17:05:25.700  rad-acct-int-update   ->             1a:3a:2c:f7:f5:75  74:9e:75:41:79:70                    -   -      
AP-6-635# 

Acct-Session-Id and Acct-Multi-Session-Id Behavior: If the roam is a fast roam, the Acct-Multi-Session-Id remains the same, indicating the same client session. However, the Acct-Session-Id changes to reflect the transition to a new AP.

Acct-Multi-Session-Id on the Initial AP : val=1A3A2CF7F575-1730854373
Acct-Multi-Session-Id on the New AP : val=1A3A2CF7F575-1730854373

Acct-Session-Id on the Initial AP : val=749E75417C70-1A3A2CF7F575-672ABDE6-6B51D
Acct-Session-Id on the New AP : val=74975417970-1A3A2CF7F575-672ACOAB-92AFB

Tunnel mode with roaming

In tunnel mode with client roaming, traffic from the client is tunneled from the AP to the gateway. The gateway acts as a RADIUS proxy and forwards authentication and accounting requests for all tunnel-mode clients.

RADIUS Accounting Behavior: When a client roams from one AP to another, the user designated gateway (UDG) forwards a new RADIUS accounting start message reflecting the updated AP information and an accounting stop message for the initial AP.

For fast roaming scenarios, the Acct-Multi-Session-Id remains consistent, linking all related session events to the same logical session, while the Acct-Session-Id changes to reflect the new session context. Here’s the accounting messages being exchanged:

Accounting start with the Initial AP: As the client connects to the initial AP (AP-8-635), the gateway (UDG) forwards an Accounting start message to the RADIUS server. This message includes updated information about the AP the client is connected to.

Similarly, for interim updates:

Accounting stop for initial AP: After the client has roamed, the gateway forwards an Accounting stop message for the session associated with the initial AP (AP-8-635). This closes out the session tied to that AP.

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  5 15:07:21.187  rad-acct-start   ->                  26:08:2c:70:91:b9  74:9e:75:41:7c:71/__gw_172.30.32.21  -    - 
Nov  5 15:11:01.515  rad-acct-int-update   ->             26:08:2c:70:91:b9  74:9e:75:41:7c:71                    -    - 
Nov  5 15:11:09.949  rad-acct-stop   ->                   26:08:2c:70:91:b9  74:9e:75:41:7c:71/__gw_172.30.32.21  -    -   
AP-8-635#  

Note the multi Acct-Session-Id: val=26082C7091B9-1730847899 and the Acct-Session-Id : val=749E75417C71-26082C7091B9-672AA529-2D70E

Accounting start from the new AP: Once the client connects to the new AP, the gateway (UDG) forwards an Accounting Start msg for the new session with the new AP (AP-3-635).

Buffer trace of this process:

AP-3-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
                                                                                                                        
                                                                                                                        
Nov  5 15:11:10.176  station-up *                         26:08:2c:70:91:b9  74:9e:75:41:25:d0                    -  -  wpa2 aes
Nov  5 15:11:10.189  rad-acct-start   ->                  26:08:2c:70:91:b9  74:9e:75:41:25:d0/__gw_172.30.32.21  -  -  
Nov  5 15:11:10.190  rad-acct-int-update   ->             26:08:2c:70:91:b9  74:9e:75:41:25:d0                    -  -  
Nov  5 15:14:35.753  rad-acct-int-update   ->             26:08:2c:70:91:b9  74:9e:75:41:25:d0                    -  -  
AP-3-635#   

Acct-Session-Id and Acct-Multi-Session-Id Behavior: If the roam is a fast roam, the Acct-Multi-Session-Id remains the same, indicating it pertains to the same client session. However, the Acct-Session-Id changes to reflect the transition to a new AP.

Acct-Multi-Session-Id on the Initial AP : val=26082C7091B9-1730847899
Acct-Multi-Session-Id on the New AP : val=26082C7091B9-1730847899

Acct-Session-Id on the Initial AP : val=749E75417C71-26082C7091B9-672AA529-2D70E
Acct-Session-Id on the New AP : val=749E754125D0-26082C7091B9-672AA60E-2DD81

This approach in tunnel mode allows the RADIUS server to track the client’s AP changes while keeping the session continuous through the Acct-Multi-Session-Id.

Mixed mode with roaming

In mixed mode when a client roams, both tunneled and bridged client sessions rely on the gateway as the RADIUS proxy. In this scenario, when a client roams the Acct-Session-Id changes while the Acct-Multi-Session-Id remains the same, simplifying RADIUS accounting and maintaining a consistent Acct-Multi-Session-Id throughout the client’s connection. To learn more about mixed mode, refer to Mixed Forwarding.

Summary

In summary, a consistent Acct-Multi-Session-Id across a client’s session, including during roaming, provides several benefits. The Acct-Multi-Session-Id enables seamless tracking of a user’s activity, ensuring that all session data is unified even if the client moves between APs. This simplifies session management, billing, and accounting, as all activity is associated with one session, reducing administrative complexity. Additionally, security monitoring is enhanced by creating a clear and consistent record of user activity across the network.