Keep Your WIDS About You
Introduction
Are you alerted when or if a rogue AP broadcasts your companies SSID? Are you alerted when or if large volumes of de-authentication packets are sent to your wireless clients? These are some questions I've been asking recently as I've researched WIDS and how Fortinet can help. This isn't really a support request for the forum; it's more of an information sharing post for those interested.
Generally, most wireless deployments I see using Wireless Intrusion Detection Systems (WIDS) or Wireless intrusion Prevention System (WIPS) are using default vendor setting rather than fine tuning the settings to suite your business needs or align with your company cyber security policies. In some cases, WIDS may be disabled all together due to concern of resource usage on the AP hardware itself or limiting the available radios of the AP by using radios as dedicated monitors. Most of what can be found via a quick google search regarding wireless security is more centered around user awareness of watching out for certain network types or using a VPN while connected to hotspots for example. This is great advice for users with corporate devices that are out and about but what about intrusion prevention on the on-premises corporate network that you manage? It's always good for any corporation to provide users with handy tips on security and for the user to apply logic to decisions around their corporate assets and access to the wireless network, but how can the infrastructure help? What can be done with the wireless infrastructure regarding security outside of ensuring the best Cipher suite (Like CCMP) and Authentication Key Management (AKM) suite (Like 802.1X) is used? How can we detect rogue access points and report or act?
This is where Wireless Intrusion Detection or Prevention Systems can come into play. This post aims to keep the basic principals in mind regarding WIDS/WIPS and how attackers can use tools to mimic and attempt man-in-the-middle (MITM) attacks and how to configure WIDS on a Fortinet Firewall managing Fortinet wireless access points.
WIDS, why use it?
A Wireless Intrusion Detection System (WIDS) is a feature either bundled with a vendor product (Integrated WIDS) or a separate dedicated solution (Overlay WIDS) to monitor and detect rogue access points and wireless attacks. As the wireless medium is becoming increasingly used, it remains very important for monitoring and reporting of potential threats of such a large attack surface. The main difference between a WIDS and a WIPS is that a WIDS will detect and report on threats (or potential threats) and WIPS has additional mitigation features built-in where an action or policy can be applied to mitigate the threat. A WIPS usually will mitigate threat by the using de-authentication packets to clients associated to an identified rogue AP for example. Although the mitigation of threats can be useful, it is also a much more extreme approach and could have legal consequences in depending on where you are in the world. In the case of this post, I am focusing more on WIDS as it provides monitoring and detection of wireless threats which can then be investigated and acted upon in a more passive approach rather than the potential of impacting a false positive without human intervention. An example of false positive is a neighbouring network innocently broadcasting the same Service Set Identifier (SSID) or network name as your corporate network, and then your WIPS solution may then start sending de-authentication packets to clients which could interrupt that companies wireless access creating what would look like a denial of Service (DoS) attack on that companies WIDS/WIPS. Although there can be slightly different view of what a rogue AP is, I am using the CWNP definition - A rogue AP can be defined as any AP operating in your owned space that has not been authorised by you.
Common attacks on wireless include the installation of a rogue access point (AP) which could be authorised or unauthorised. An example that comes to mind is a previous team I was in was responsible for monitoring and managing the network at a large hospital. A doctor who wanted to connect personal devices to the wireless brought in his own wireless AP from home. Although this would have been rightfully detected as rogue although this doctor didn’t mean to cause any issues or trigger an investigation. Moreover, the AP this doctor brought in was actual more than an AP it was a SOHO wireless router which also started handing out IP addressing which cause a lot of issues. This event also highlights how important the use of wired port-based security is using 802.1X on the wired network. Another attack using a rogue AP could be by an attacker broadcasting your companies SSID to act as an 'evil twin' to try and encourage your companies’ wireless clients to connect. Once connected, the attacker could then attempt other attacks on the clients locally.
Another common attack is sending de-authentication frames to clients to either stop them connecting or force a reconnection so the 4-way handshake can be captured. Capturing the 4-way handshake can then be used to attempt to discover the passphrase to a wireless network using pre-shared key (PSK) as the authentication type. By capturing the 4-way handshake used by clients on a WPA2-PSK network for example, an attacker can use an offline dictionary attack using the Aircrack-NG suite bundled by default with Kali Linux but can be installed on pretty much any other Linux distro.
Fortinet WIDS
Fortinet solutions always keep security at the forefront of their products. The latest wireless security standards and settings are supported which include intrusion detection and prevention systems configuration options to include in your network.
Fortinet offers several types of wireless management which include:
- FortiGate Firewall (A common choice as no extra licensing is required and integrated configuration through a single pane of glass)
- FortiLAN Cloud - Cloud management for standalone FortiAPs
- FortiManager - Central management of wireless networks through AP manager (Can be on-premises or cloud)
- FortiSASE - Supports management and integration of FortiAP as an edge device
This post is concentrating on the WIDS configuration available using a FortiGate (Or FortiWifi in my case) as the wireless controller. Fortinet uses FortiAP Profiles for common configuration options for different FortiAP models as different models support different features. WIDS can be configured in different ways within a FortiAP Profile. An example of capabilities is the Wi-Fi 7 AP FAP231K allows a WIDS profile per radio and each radio can be either in Access Point Mode or Dedicated Monitor mode. The Wi-Fi 7 AP FAP441K has a fourth radio which can only be either disabled or set as a Dedicated Monitor with a WIDS profile attached. The other three radios on the AP441K can't be set in Dedicated Monitor Mode allowing the AP to provide constant service of clients in the 2.4,5, and 6GHz bands while also providing dedicated monitor radio.
It's important to note that like other vendors, when a FortiAP is in Access Point mode and has a WIDS profile enabled, the FortiAP will briefly switch to monitoring mode to scan the environments every 300 seconds. Each second a different channel will be monitored for up to 20ms until all channels have been scanned. Depending on your usage needed, it may be better to enable a radio as a dedicated monitor or procure an AP like the FAP441K with a dedicated fourth monitoring radio for busier environments where WIDS is required. The Wi-Fi 7 AP FAP231K mentioned above has three radios (2.4, 5, and 6GHz) but if your environment didn’t need the 6GHz radio for example then that radio could be set to dedicated monitor as an alternative cost effective option. Having a dedicated monitoring radio offers better detection and faster alerting because the dedicated radio will not be in a dual role between monitoring to service clients like in Access Point Mode.
WIDS profiles can be configured from the FortiGate GUI via WiFi & Switch Controller > WIDS Profiles. The following intrusion detection options can be configured from the GUI:
- Asleap Attack—ASLEAP is a tool used to perform attacks against LEAP authentication.
- Association Frame Flooding—A Denial of Service attack using a large number of association requests. The default detection threshold is 30 requests in 10 seconds.
- Authentication Frame Flooding—A Denial of Service attack using a large number of association requests. The default detection threshold is 30 requests in 10 seconds.
- Broadcasting De-authentication—This is a type of Denial of Service attack. A flood of spoofed de-authentication frames forces wireless clients to de-authenticate, then re-authenticate with their AP.
- EAPOL Packet Flooding—Extensible Authentication Protocol over LAN (EAPOL) packets are used in WPA and WPA2 authentication. Flooding the AP with these packets can be a denial of service attack. Several types of EAPOL packets are detected: EAPOL-FAIL, EAPOL-LOGOFF, EAPOL-START, EAPOL-SUCC.
- Invalid MAC OUI—Some attackers use randomly-generated MAC addresses. The first three bytes of the MAC address are the Organizationally Unique Identifier (OUI), administered by IEEE. Invalid OUIs are logged.
- Long Duration Attack—To share radio bandwidth, WiFi devices reserve channels for brief periods of time. Excessively long reservation periods can be used as a denial of service attack. You can set a threshold between 1000 and 32 767 microseconds. The default is 8200.
- Null SSID Probe Response—When a wireless client sends out a probe request, the attacker sends a response with a null SSID. This causes many wireless cards and devices to stop responding.
- Spoofed De-authentication—Spoofed de-authentication frames are a denial of service attack. They cause all clients to disconnect from the AP.
- Weak WEP IV Detection—A primary means of cracking WEP keys is by capturing 802.11 frames over an extended period of time and searching for patterns of WEP initialization vectors (IVs) that are known to be weak. WIDS detects known weak WEP IVs in on-air traffic.
- Wireless Bridge—WiFi frames with both the fromDS and ToDS fields set indicate a wireless bridge. This will also detect a wireless bridge that you intentionally configured in your network.
The above is referenced directly from - Wireless Intrusion Detection System | 7.0.1 | Fortinet Document Library.
Another great resource to review the available features of a FortiAP is to the Fortinet Wireless Product Matrix found here - https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/Fortinet_Wireless_Product_Matrix.pdf
WIDS Lab
Overview
In this post I wanted to do a quick lab to show WIDS in operation. In the following section I will configure WIDS on my FortiWifi Firewall with inbuilt radio which is also managing my FortiAP 231G (Wi-Fi 6E AP). I will use the default WIDS profile enabled and then introduce an additional feature to show what detection looks like and how it can be used. The goal of the lab is to trigger a WIDS event for a duplicate or fake AP broadcasting my test SSID.
This lab assumes some knowledge with Fortinet wireless as some configuration is already added.
Equipment
In this lab I am going to use:
- FortiWifi 40f Firewall - Used as the wireless controller. This also has an inbuilt wireless AP but is set to dedicated monitor to allow WIDS.
- FortiAP 231G (Powered via PoE switch)
- WiFi Pineapple Mark VII by Hak5 - Used to create an evil twin to trigger a WIDS event
Wi-Fi Pineapple
The WiFI pineapple is a wireless penetration testing tool created and sold by Hak5. It is primary used for simulating MITM attacks but due to it being a Linux based platform there is a large community who have written lots of different optional modules that can also be installed to perform other testing. Optional modules like Nmap for port scanning connected clients and Evil Portal used to mimic legitimate captive portals are examples. Although the WiFi Pineapple can be seen as a 'hacking device', I only as a tool to audit and test wireless security in a lab setting as do other wireless professionals.
The WiFi Pineapple has three inbuilt 2.4Ghz radios with different tasks:
- A management radio. Optionally used over the tethered ethernet via the USC-C cable.
- The PineAP radio. Used to impersonate APs and recon among other things.
- An uplink radio. This radio is used to connect to a legitimate SSID so connected clients can be provided internet and appear less obvious they are connected to a different AP.
An optional 5Ghz adapter can be connected to the USB port of the WIFI Pineapple.
For this lab specifically I will be using the WiFi Pineapple to create a fake SSID the same as the SSID configured on my FortiWifi firewall to try and trigger a Fortinet WIDS alert. Any AP could also be used for this Fake AP test, but I think it's important to also be aware of the kinds of tools out there on the market.
Deployment
For this lab I have already setup an SSID called FortiTest using WPA2-PSK in the default tunnel mode on the firewall under WiFi & Switch Controller.
My FortiAP 231G is connected using the FAP231G-default FortAP Profile added by default when commissioning the 231G for the first time.
Within the profile for the 231G series WIDS can be enabled for one or more radios as below. Please note that WIDS is disabled by default and must be enabled via the slider button.
For this lab I am using the default WIDS profile. This profile can be found under WiFi & Switch Controller > WIDS Profiles. When creating a WIDS profile several GUI options are available as below:
I am going to use the default WIDS profile with all the GUI options enabled to show what it looks like via CLI but I will only be focusing on one setting for this post. The configuration can also be viewed via the CLI:
FortiWiFi (root) # show wireless-controller wids-profile default
config wireless-controller wids-profile
edit "default"
set comment "Default WIDS profile."
set sensor-mode both
set ap-scan enable
set ap-bgscan-intv 1
set ap-bgscan-duration 20
set ap-bgscan-idle 1
set ap-scan-passive enable
set wireless-bridge enable
set deauth-broadcast enable
set null-ssid-probe-resp enable
set long-duration-attack enable
set invalid-mac-oui enable
set weak-wep-iv enable
set auth-frame-flood enable
set assoc-frame-flood enable
set spoofed-deauth enable
set asleap-attack enable
set eapol-start-flood enable
set eapol-logoff-flood enable
set eapol-succ-flood enable
set eapol-fail-flood enable
set eapol-pre-succ-flood enable
set eapol-pre-fail-flood enable
next
end
The WIDS feature I want to enable specifically is AP impersonation feature which triggers when the same SSID is used by a rogue AP, this is done by adding it to the WIDS profile via CLI:
config wireless-controller wids
edit default
set ap-impersonation
Now the setting is added to the default WIDS profile.
FortiWifi (root) # show wireless-controller wids-profile default
config wireless-controller wids-profile
edit "default"
set comment "Default WIDS profile."
set sensor-mode both
set ap-scan enable
set ap-bgscan-intv 1
set ap-bgscan-duration 20
set ap-bgscan-idle 1
set ap-scan-passive enable
set wireless-bridge enable
set deauth-broadcast enable
set null-ssid-probe-resp enable
set long-duration-attack enable
set invalid-mac-oui enable
set weak-wep-iv enable
set auth-frame-flood enable
set assoc-frame-flood enable
set spoofed-deauth enable
set asleap-attack enable
set eapol-start-flood enable
set eapol-logoff-flood enable
set eapol-succ-flood enable
set eapol-fail-flood enable
set eapol-pre-succ-flood enable
set eapol-pre-fail-flood enable
set ap-impersonation enable
next
end
There are more advanced WIDS features available via the CLI. Details on the above features and more can be found on the Fortinet website - https://docs.fortinet.com/document/fortiap/7.6.5/fortiwifi-and-fortiap-configuration-guide/961129/wireless-intrusion-detection-system.
Now that the AP impersonation feature is enabled, I will configure the WiFI Pineapple to broadcast the same SSID. This is using the PineAP Evil WPA which allows me to set the SSID name, the BSSID, Passphrase, and Encryption type. I configured the SSID the same as my FortiTest SSID and used a BSSID which appears as a HPE Aruba AP. Any BSSID could be used including the exact same one used by my legitimate FortiAP but in this case I used a HPE BSSID to differentiate from the Fortinet one. I set the passphrase to something generic as this is only for testing.
Now that that SSID is being broadcast, we can navigate back to the FortiWifi to view the rogue devices and more important whether the 'Evil Twin' has been picked up by the WIDS.
I navigated to Dashboard > WiFi > Rogue APs:
As you can see the rogue AP has been noticed and has the status of Onsite Fake AP which was picked up by the FortiWifi firewalls inbuilt wireless radio currently set as a dedicated monitor with the defautl WIDS profile attached. The FortiWifi 40f has an inbuilt radio that can be set to either 2.4 or 5GHz and can be set in Access Point or Dedicated Monitor like other Fortinet APs. In my case I have the FortiWifi radio set as a dedicated monitor and my 231G is set to service clients broadcasting the FortiTest SSID. Interestingly the inbuilt 40F radio does not allow WIDS to be enabled while in Access Point mode likely to save resources on the unit as it's targeted to smaller branch office deployments.
Navigating to Log & Report > System Events > WiFi Events drop down in top right, and I can see more specific detail about this rogue AP classified as fake-ap-on-air.
These logs can be sent to your FortiAnalyzer, FortiSIEM or any log collector to trigger alerts. An engineer could then investigate the detail and remediate where necessary. There are also inbuilt options in the FortiGate (or FortiWifi) called Automations under the Security Fabric menu. Using an automation the administrator can configure triggers and actions which could be a more passive action like send an email or monitoring trap, or something more active like run CLI commands or other automation sequences to run a desired action.
Conclusions
Although in this lab we only mimicked an AP which by itself might not be cause for concern, the WiFi Pineapple could then be used to attempt to de-authenticate users to force a reauthentication allowing the capture of a 4-way handshake (which could also be picked up by WIDS with - set deauth-broadcast enable). Capturing the 4-way handshake from a PSK network can then be used in an offline attack. The attacker could use the Aircrack-NG suite along with a wordlist (sometimes called a rainbow table) filled with a vast number of different password combinations to attempt to discover the passphrase used. This process is outside of the scope of this post but there are many blogs on how this can be easily accomplished with a Linux PC with the AirCrack-NG suite installed and why it is important to keep in mind. If the passphrase is discovered, then that clients wireless packets could be decrypted and eavesdropped on or the attacker could simply use it to connect to your network to carry out reconnaissance or attacks. With a tool like the WiFi Pineapple the discovered passphrase could be configured for the same SSID and clients could then be targeted with another de-authentication attack and they may connect to the WiFI Pineapple becoming a MITM where further reconnaissance or attacks could happen on the client.
As you could see from the WIDS feature list on the FortiWiFi or other FortiGate firefalls acting as a wireless controller there are a lot of options to use to protect your wireless network outside of just AP impersonation including the detection of clients being sent de-authentication frames that did not originate from the AP. This could indicate an attacker attempting a DoS attack or trying the trigger the client to reauthenticate to capture the 4-way handshake as mentioned above.
Security is multi-facetted. Considering the latest security methods and client capabilities is important. If protecting a corporate network, then using mutual authentication through 802.1X is essential in protecting your clients and network. WPA3-Enterprise using EAP-TLS offers a very high degree of security for your clients and network. WPA3 adds Protected Management Frame (PMF) as mandatory which removes the risk of clients being de-authenticated (but WIDS would still be able to alert you if it was attempted). Of course, not all clients are compatible with some standards and features so many environments may still need to use older security methods. If your environment does need WPA2-PSK but you also had WPA3 capable devices for example, you could setup a separate WPA2 SSID for legacy clients. Using the FortiGate firewall, you could segment those clients off onto a separate VLAN and zone so those clients could be treated with a different security posture allowing the more capable WPA3 clients the best security possible on the separate SSID. Pre-Shared Key (PSK) is not recommended in a corporate or enterprise environment because it’s less manageable and more importantly less secure. WPA3-Personal using SAE is preferred over WPA2-Personal using PSK for its added SAE handshake and features but is still targeted for the small office/home environment. In corporate or enterprise environments, using 802.1X through WPA3-Enterprise for wireless clients with mutual authentication like EAP-TLS partnered with WIPS/WIDS watching the air offers your clients and network the best wireless security.
If you've managed to read to the end, I hope this post invokes thoughts of your current or future wireless deployments to carefully consider security and monitoring outside of just authenticating clients. Security and features are always changing so periodic reviews and audits of your environment are always recommended. Investing in wireless survey tools also allows you to physically investigate the areas identified by WIDS making it easier to locate and further investigate rogue devices.
Thank you for reading.
References
Want to learn more about WIDS and Fortinet Wireless? Please see the references below:
- Fortinet Document Library - Wireless Intrusion Detection System | 7.0.1 | Fortinet Document Library
- Fortinet Training Institute Course - Secure Wireless LAN Administrator - Secure Wireless LAN Administrator | Training Institute