Policy

The WIPS Policy Screen is used to configure policies for rogue AP and wireless attacks on the network. You can configure one overall policy for the Stellar wireless network. When an attack is detected based on the policy, the detected device is banned from the network and is displayed on the Intrusive AP or Wireless Attacks Screens for review. After creating a policy as described below, click on the Apply button to activate the policy for the wireless network.

Creating Rogue AP Policies

A rogue AP is an unauthorized AP connected to the wired side of the network, that is considered a security threat to the wireless network. An interfering AP is an AP seen in the wireless environment but not connected to the wired network, which is not considered a direct security threat. However, some interfering APs may have an impact on network quality and can interfere with valid client access to the network. Complete the fields below to configure rules to classify interfering APs as rogue APs.

Recognition Policy

• Signal Strength Threshold - If enabled, an interfering AP with greater RSSI than the setting value will be classified as rogue (Range = 50 - 95 dBm). By default, the RSSI matching rule is disabled.
• Detect Valid SSID - If enabled, a foreign AP broadcasting the same SSID with valid Stellar network SSIDs will be classified as rogue. By default, the Detected Valid SSID rule is enabled.
• Detect Rogue SSID Keyword - If enabled, an interfering AP broadcasting and SSID that matches the characteristic specified by the user will be classified as rogue. The matching condition can be equal to or contain the configured keyword.  
• Rogue OUI - If enabled, interfering APs matching this MAC OUI will be classified as rogue.

Friendly AP

• Friendly MAC - An AP classified as interfering or rogue can be trusted to be a "Friendly" AP by entering the MAC OUI or MAC address of the AP - essentially creating a Vendor "Allowlist". These interfering APs will never be classified as rogue.

Note: The default MAC OUIs (34:e7:0b, dc:08:56, and 88:3c:93) are required for Stellar APs. Also note that you can have a maximum of 32 Friendly MAC OUIs/MAC addresses, including the three default Stellar AP MAC OUIs.

Containment Policy

• Rogue AP Containment - If enabled, the rogue AP containment function reduces the impact of the rogue AP on valid clients.

Creating Wireless Attack Policies

A rogue AP is not the only threat to the wireless network, other wireless attacks can be detected and mitigated for both APs and Clients. To create Wireless Attack Policies, you must enable Wireless Detection. When configuring a policy, each detection policy can be set to one of the following levels. When a level is selected, all detection policies included in that level are displayed and selected.

• High - Enables all applicable detection mechanisms, including all the options of low and medium level settings.
• Medium - Enables important detection mechanisms. This includes all the options of the low-level settings.
• Low (Default) - Enables only the most critical detection mechanisms.
• Custom - Enables only the selected detection mechanisms. When this level is selected, all detection mechanisms are displayed. Select the ones you want to include in the policy.

The sections below describe each of the Wireless Attack Policies.

AP Attack Detection Policy

An AP Attack Detection Policy detects multiple attacks originating from foreign APs. The following detection methods are available depending on the level selected.

• Detect AP Spoofing - An AP Spoofing attack involves an intruder sending forged frames that are made to look like they are from a valid AP.
• Detect Broadcast De-authentication - A de-authentication broadcast attempts to disconnect all clients in range. Rather than sending a spoofed de-authentication frame to a specific MAC address, this attack sends the frame to a broadcast address.
• Detect Broadcast Disassociation - By sending disassociation frames to the broadcast address (FF:FF:FF:FF:FF:FF), an intruder can disconnect all stations on a network for a widespread DoS.
• Detect Adhoc Networks 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.
• Detect Long SSID - Detects long SSIDs with more than 32 characters in the name.
• Detect AP Impersonation - In AP impersonation attacks, an AP assumes the BSSID and ESSID of a valid AP. AP impersonation attacks can be done for person-in-the-middle attacks, a rogue AP attempting to bypass detection, or a Honeypot attack.
• Detect Adhoc Networks - An ad hoc network is a collection of wireless clients that form a network among themselves without the use of an AP. If the ad hoc network does not use encryption, it 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.
• Detect Wireless Bridge - Wireless bridges are normally used to connect multiple buildings together. However, an intruder could place (or have an authorized person place) a wireless bridge inside the network that would extend the corporate network somewhere outside the building. Wireless bridges are somewhat different from rogue APs in that they do not use beacons and have no concept of association. Most networks do not use bridges. In these networks, the presence of a bridge is a signal that a security problem exists.
• Detect 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. Many popular NIC cards will lock up upon receiving such a probe response.
• Detect Invalid Address Combination - In this attack, an intruder can cause an AP to transmit de-authentication and disassociation frames to its clients. Triggers that can cause this condition include the use of broadcast or multicast MAC address in the source address field.
• Detect Reason Code Invalid of De-authentication - De-authentication packets with invalid reason code will be classified as an attack.
• Detect Reason Code Invalid of Disassociation - Disassociation packets with invalid reason code will be classified as an attack.

Client Attack Detection Policy

A Client Attack Detection Policy detects attacks originating from wireless clients. The following detection methods are available depending on the level selected.

• Detect Valid Station Misassociation - This feature does not detect attacks, but rather monitors valid wireless clients and their association within the network. Valid client mis-association is potentially dangerous to network security. The four types of mis-association monitored are:
• Valid Client Associated to a Rogue - A valid client that is associated to a rogue AP
• Valid Client Associated to an Interfering AP - A valid client that is associated to an interfering AP
• Valid Client Associated to a Honeypot AP - A honeypot is an AP that is not valid but is using an SSID that has been designated as valid
• Valid Client in Ad Hoc Connection Mode - A valid client that has joined an ad hoc network
• Detect Omerta Attack - Omerta is an 802.11 DoS tool that sends disassociation frames to all clients on a channel in response to data frames. The Omerta attack is characterized by disassociation frames with a reason code of 0x01. This reason code is “unspecified” and is not be used under normal circumstances.
• Detect Unencrypted Valid Client - A valid client that is passing traffic in unencrypted mode is a security risk. An intruder can sniff unencrypted traffic (also known as packet capture) with software tools known as sniffers. These packets are then reassembled to produce the original message.
• Detect 802.11 40MHZ Intolerance Setting - When a client sets the HT capability “intolerant bit” to indicate that it is unable to participate in a 40MHz BSS, the AP must use lower data rates with all of its clients. Network administrators often want to know if there are devices that are advertising 40MHz intolerance, as this can impact the performance of the network.
• Detect Active 802.11n Greenfield Mode - When 802.11 devices use the HT operating mode, they can’t share the same channel as 802.11a/b/g clients. Not only can they not communicate with legacy devices, the way they use the transmission medium is different, which would cause collisions, errors and retransmissions.
• Detect DHCP Client ID - A client which sends a DHCP DISCOVER packet containing a Client-ID tag (Tag 61) which doesn't match the source MAC of the packet may be doing a DHCP denial-of-service to exhaust the DHCP pool.
• Detect DHCP Conflict - Clients which receive a DHCP address and continue to use a different IP address may indicate a mis-configured or spoofed client.
• Detect DHCP Name Change - The DHCP configuration protocol allows clients to optionally put the hostname in the DHCP Discover packet.  This value should only change if the client has changed drastically (such as a dual-boot system).  Changing values can often indicate a client spoofing/MAC cloning attack.
• Detect Too Many Auth Failure Client - Client which attempts to connect to Stellar AP but fails to pass the authentication for too many times, indicating an attack client.
• Detect Malformed Frame-Assoc Request - Some wireless drivers used in access points do not correctly parse the SSID information element tag contained in association request frames. A malicious association request with a null SSID can trigger a DoS or potential code execution condition on the targeted device.
• Detect Long SSID At Client - Detect long SSID in the wireless environment based on packets sent by clients.
• Detect Reason Code Invalid of De-authentication - Detect invalid De-authentication Reason Code.
• Detect Reason Code Invalid of Disassociation - Detect invalid Disassociation Reason Code.

Client Blocklist Policy

There are two sources for the Client Blocklist: created manually by user or added dynamically by system. If the Dynamic Client Blocklist is enabled, intruders discovered by WIPS are dynamically added into the Client Blocklist and prevented from associating with the network. The following detected items are added to the Client Blocklist by system: List of Client Attack Detection, ad hoc clients, Clients associated to rogue AP.

• Aging Time - Aging time for the Client Blocklist. Once expired, a client will be removed from the Blocklist and allowed to be associated to the valid network until it is detected as a threat again. (Range = 1 hour to 365 days, Default = 1 Day).
• Max Auth Failure Times - Authentication failure times threshold. When a client fails to pass the authentication in the associated phase for too many times in a brief period, it will be classified as an attack and added into the Client Blocklist. (Range = 3 - 10 times per 5 - 3600 seconds, Default = 10 times per 60 seconds.