Internal Vulnerability Assessment

These risks are usually evaluated from two lenses—internal and external. With an internal scan, the assessment is run based on how the target devices appear from the internal network. This is valuable since the internal network access will be unfiltered (not blocked by firewalls) as long as the scanning appliance has proper access.

Scanning for vulnerabilities from inside offers the entire picture of the device's posture, allowing the organization to fully secure it, including from internal (malicious or unintentional) threats.

External Vulnerability Assessment

For systems and networks that have Internet connectivity, an external assessment is also part of the vulnerability management program. The only difference here is that the scan is initiated externally from the Internet—offering a view of how the system appears to the outside world. The external assessment is critical since the Internet introduces access to millions of potentially malicious users, scripts, and bots.

As it relates to wireless systems, if your infrastructure supports remote sites with APs connected over the Internet, remote workers using remote APs, or remote management access to the controller, then the architecture will have necessitated inbound access from the Internet. In these cases, the external vulnerability scan will help ensure no gaps exist that may increase the risk of a successful Internet-based attack.

A vulnerability management program with ongoing vulnerability assessments is just one piece of an overall strategy for ensuring security of the environment. Outputs from these scans and summary reports may be included as part of the security audit and security assessments discussed in this chapter. However, security audits and assessments are more of a point-in-time static view of the environment, whereas an effective program will including continuous vulnerability scanning.

WIDS vs. WIPS vs. Wired IPS

First, let me go ahead and tackle the WIDS vs. WIPS conversation and get that out of the way. Just like its wired counterparts, wireless IDS is intrusion detection, and wireless IPS is intrusion prevention. Realistically there are very few use cases for a detection-only system. For obvious reasons most organizations are looking for the protection and to stop an attack.

If I left my laptop bag at a table with friends and said, “hey will you watch this for a minute?” and then a stranger came by and tried to steal my bag, my IDS friends would watch my bag get stolen and give me a detailed description of the thief along with the direction he went. My IPS friends would see the heist happening and grab my bag before the crook could abscond with it.

We all want those IPS friends. In wireless there are a few specific cases where we may be limited in the response and actions taken to mitigate certain over-the-air attacks, and I'll cover that shortly (and more than once).

The next explanation is the answer to a commonly asked question of “if we have IPS on the network, why do we need an WIPS?” It's a short and sweet answer. Wired IPS systems only have visibility into and signatures for wired-side attacks. They can't possibly see or parse an RF-based attack over the air. Hence, we require WIPS in addition to any IDS systems on the wired network.

WIPS sensors have visibility of layers 1 and 2 over-the-air, versus a wired IPS device, which will only see and evaluate wired traffic. Depending on the wired sensors, the wired IPS may secure traffic inbound from the Internet and/or internal LAN traffic, as shown in Figure 7.4.

Requirements for WIPS

Because WIPS systems are monitoring for attacks over the air, there are a few specific requirements to consider when planning the architecture. The WIPS system will need to have sensors within the physical airspace of the assets to be protected, or area to be monitored; those sensors will need to have radios in the RF spectrum to be monitored; and the system (which by nature will have distributed sensors) should integrate with a centralized platform to ingest and alert on any incidents.

Integrated vs. Overlay vs. Dedicated

If I were writing this just a few years ago, I would tell you about integrated versus overlay systems. The truth is the industry went from three or four dedicated Wi-Fi WIPS vendors to approximately zero over the course of the past 10 years or so.

There are WIPS features in several of the special-purpose monitoring tools discussed with spectrum analyzers shortly. Those products have predominately been used in federal, military, and logistics operations with specialized needs and aren't mainstream in enterprise environments (yet).

So, instead, we'll talk about the differences between integrated and dedicated WIPS sensors, since the story is the same, but the characters are different.

Pretty much every enterprise Wi-Fi product has some form of integrated WIPS and security monitoring built into the product. If configured to do so, APs that are servicing endpoints can spend part of their time scanning and listening for signs of over-the-air attacks, anomalies, and rogue devices.

The benefit to allowing the APs to pull double-duty is that you've immediately satisfied the three requirements of WIPS—you have radios that support the RF bands of interest, they're physically distributed throughout the environment, and they're attached (or can be) to a central system, whether that's a management product, cloud manager, or controller.

The downside to the double-duty model is that the AP radios have limited time and bandwidth (as in RF bandwidth) to monitor. They can't really fully monitor while they're servicing clients—it's like the falsity of multitasking—they're not doing both at once, they're just switching quickly between tasks. As shown in Figure 7.5, if the radio needs to contain a threat, that radio will cease to serve clients. APs that have an additional dedicated radio can do both simultaneously by using the extra radio for scanning and containment.

If there is an over-the-air threat, the only way to contain or mitigate it is also over the air (well, unless it's a rogue device you can unplug). In addition to the limitations of monitoring (listening), there are even more restrictions when an AP (or any radio) attempts to contain a threat. During the containment, that radio can't perform any other function, including servicing enterprise clients.

If you've seen Ghostbusters, the mental image of the particle thrower's stream while they're trapping ghosts is about as good as any to picture an AP “capturing” a bad actor on the wireless network.

If an AP has a dedicated security radio, it can perform both scanning and mitigation tasks without disrupting the client-serving radios.

The enterprise Wi-Fi products are usually configurable to a degree. The options change with code revisions but usually include the following:

• Set AP radio(s) to scan/monitor in downtime (when not actively servicing clients)
• Set AP radio(s) to scan/monitor a specified subset of channels or frequency (e.g., 2.4 GHz, 5 GHz, or specific channels)
• Set one or more AP radios as dedicated WIPS sensors (these radios will not service clients and this AP acts as an overlay/dedicated sensor)
• Set one or more AP radios as a dedicated spectrum analyzer (these radios will not service clients in this mode)

Granularity and options for WIPS vary by product. Juniper Mist has a limited WIPS configuration in the web UI, focusing on rogue and neighbor APs as well as honeypots, as shown in Figure 7.6. WIPS configurations in Aruba Central offer preset high, medium, low settings or the option to custom configure, shown in Figure 7.7. Alerts for WIPS events can also be configured in a different window.

What a WIPS sensor (or an AP moonlighting as a WIPS sensor) can do is dependent on what mode of operation it's in—integrated/dual function or dedicated.

Attacks WIPS Can Detect and Prevent

Your WIPS mileage will vary depending on the deployment and products in use, but generally even the most basic WIPS will perform the most crucial tasks of identifying rogue devices and a subset of over-the-air attacks.

Attack signatures and methods have been collapsed for readability; Wi-Fi-capable WIPS often include these detection abilities:

• Rogue AP By strict definition, a rogue AP is an unauthorized AP attached to the enterprise network. We'll cover rogue classification more in-depth next.
• Rogue Client A rogue client could mean a couple of things depending on the vendor. Most often a rogue client is a client connected to an unauthorized or rogue AP. In other cases, a rogue (or unauthorized, not valid) client could mean any endpoint that is not associated with the enterprise Wi-Fi infrastructure.
• Misconfigured AP This option is primarily designed for use when there are (for example) two separate enterprise Wi-Fi systems, and you want to instruct one system to check the parameters of the other.

  Think of the prescribed parameters as being part of a secure baseline configuration—specifying the SSIDs to be served along with the corresponding security profile (e.g., WPA3-Enterprise or WPA2-Personal).

  As an example, in a hospital setting, there may be a wireless controller with infrastructure APs, but there may be an overlay network by a third party in one area of the hospital using APs not attached to the controller.

  The alert can also be used to report on misconfigured APs within a local cluster or using a management system with overrides (as in not controller-based).

• Ad-hoc (Non-infrastructure) Wi-Fi Networks Ad-hoc networks occur when devices in the environment self-organize and establish wireless networks between themselves, bypassing the infrastructure Wi-Fi all together. Ad-hoc networks can be 802.11 WLANs, Bluetooth, or other networks.

  Depending on the WIPS sensor capabilities, the system may only be able to see and report on ad-hoc Wi-Fi (blind to Bluetooth and BLE), which is especially dangerous.

  Popular sources of ad-hoc networks in the enterprise include wirelessly enabled printers that advertise their own network, screen casting devices, smartphones in hotspot mode, and devices using services like AirDrop.

  The infrastructure of WIPS sensors can see and monitor the RF, so even if the endpoints aren't talking to the infrastructure APs, their traffic can be heard over-the-air if the ad-hoc network is occurring in range of the APs.

• AP or SSID Impersonation There's a subtle difference between impersonation and spoofing. AP impersonation occurs when an unauthorized AP assumes the identity of a legitimate AP. To do this, the malicious AP would be broadcasting the SSIDs of the infrastructure APs; this is often indication of an evil twin attack.

  Aside from malicious use, it's also possible there is an enterprise-approved AP in the airspace and that AP may need to be manually accepted into the system as authorized. This is common if an organization has two different AP vendors in the same space, or within RF range of one another. For example, a main part of the building may be using a Cisco controller-based network, but in the manufacturing floor they've started migrating to Juniper Mist for the BLE location tracking. These two networks aren't designed for endpoints to roam between them, but they are both advertising the same SSIDs, and the Cisco APs can “hear” the Mist APs, and vice versa.

• AP Spoofing Spoofing has to do with spoofing of a packet source, versus spoofing the identify of an AP. In this form of spoofing, an AP sends packets that look like they're from another AP. Figure 7.8 shows the difference between AP impersonation and AP spoofing.

  

  I've avoided using the words “malicious” and “attack” here because spoofing has been used for many years as a legitimate mitigation technique for securing the enterprise environment.

  In short, spoofing includes a forged frame that looks like it's from one AP but it's really from another. This can absolutely be one step of a malicious attack but it's also how current threat mitigations work (a topic covered shortly), when an infrastructure AP spoofs de-auth or disassociation packets from a rogue AP to keep valid clients from connecting to it.

  After association (the 4-way handshake), endpoints and APs both participating in protected management frames (PMF) are protected from most AP spoofing attacks.

• Client Spoofing Client spoofing behaves the same as AP spoofing, but in this case the packets are falsified to appear to be from a client (versus AP). The same model applies, and this could indicate an attack but could also be the result of a mitigation technique where an infrastructure AP again spoofs de-auth or disassociation packets, but they appear to come from the client to the rogue AP.

  In addition to these two examples of spoofing, there's an assortment of related attacks with broadcast, floods, and fake beacon frames, all with the intent of introducing various denial-of-service (DoS) attacks.

  Endpoints and APs both participating in protected management frames (PMF) are protected from client spoofing attacks.

• Client with Invalid (Fake) MAC Address Every valid MAC address on a network interface indicates the manufacturer with the first 24-bits that define the organizationally unique identifier (OUI). For example, my laptop has an Intel® Wi-Fi NIC and it can be identified by the prefix of 60:F2:62 as registered to Intel Corporation. The OUIs are centrally registered with IEEE and are universally unique worldwide.

  I always assume every network admin has extensive experience in hunting and searching down endpoints based on the OUI, but if not Wireshark's OUI Lookup Tool (https://www.wireshark.org/tools/oui-lookup.html) is very helpful.

  This event triggers when the OUI of an endpoint doesn't have a real (registered) OUI, indicating a fake MAC address. Randomized MAC addresses are not considered fake MAC addresses.

  In recent years the use of MAC randomization has become prevalent in many endpoints including Apple phones and tablets, Android, and Windows devices. The following image demonstrates how to identify a randomized MAC address.

  The format of a random MAC address isn't really quite random; it's a locally administered MAC address as defined by IEEE so they're easily identified (see Figure 7.9)—meaning a WIPS solution should not trigger on IEEE-compliant random MAC addresses. If it is, the product may need to be updated.

  

• Broadcast De-authentication and Disassociation In normal Wi-Fi operations, de-authentication and disassociation frames are sent as unicast between an AP and client. Broadcast frames of these disconnect type frames are always suspicious.

  It's possible some vendors may use a broadcast disconnect message to kick clients off an AP before an upgrade is initiated, but every other operation in 802.11 (e.g., channel change) has a specific type of message and it's not a broadcast disconnect.

  Bulk disconnect messages are disruptive to the environment and indicative of a DoS attack.

  Endpoints and APs both participating in protected management frames (PMF) are protected from spoofing attacks including forged de-auth and disassociation packets.

• Anomalies That Impact Airtime and Quality Such as Those in CTS/RTS With Wi-Fi, airtime is a precious commodity as endpoints and APs take turns transmitting over the air; they do so using request-to-send (RTS) and clear-to-send (CTS) messages, among other collision avoidance coordination.

  There are subsets of DoS attacks that abuse RTS and CTS and in doing so, they hog the airtime, making it impossible for legitimate clients and APs to transmit.

  Vendors have different signatures for these, but in general they're looking for anomalies that indicate abuse (see Figure 7.10).

  

• Malformed Packets and Fuzzing Fuzzing and malformed packets are a set of attacks that can be used as DoS attacks and/or to introduce malicious payloads (as in some fuzzing).

  Fuzzing is especially nasty as data can be injected into legitimate packets (such as beacons), resulting in overflows, crashed drivers or OSs, and ultimately allow for remote code execution.

  Not all vendors offer broad fuzzing signatures but they're useful in WIPS when available. In an ideal world, the endpoints' network interfaces would discard malformed or unrecognized frames instead of trying to process them.

• Client with Interfaces Bridged Chapter 6 included details on why client bridging was undesirable and a security risk. Here, a bridge is defined as an endpoint that's connected two interfaces to pass traffic between them. Figure 7.11 and Figure 7.12 show how an end user can bridge interfaces in Windows.

  Bridging interfaces is supported in just about every system platform with multiple network interfaces. Many WIPS products may only have signatures to detect this on Windows or a subset of OSs.

  

  

  If an endpoint is connected to the secure Wi-Fi (ACME-Secure SSID) and bridges the interface to its wired NIC, the laptop can offer access to the ACME-Secure SSID network to devices over the wired connection.

  Note that this is not the same scenario as simply having a client that's connected both to the enterprise Wi-Fi and wired networks. Bridging can also work the other way, allowing an end user to extend the wired network to other users to connect wirelessly.

  Just to make sure this is crystal clear—with bridged interfaces, the client device is allowing other (likely unmanaged endpoints) to access a network (possibly your secure corporate network) directly through its interfaces without authenticating or authorizing the other endpoints.

• Wireless Bridges In this context, wireless bridges are connections between two or more APs designed to span a distance and bridge (for example) two buildings wirelessly. There are scenarios where an unauthorized wireless bridge may be introduced to the environment. APs acting only as bridges don't service clients, so in these cases the APs would not be classified as rogues, and the alert therefore requires its own classification.
• Various DoS Attempts (Floods, Overflows) As you saw in the preceding examples, there are numerous types of attacks that may result in denial of service; these can happen starting at layer 1 (via RF jamming) up through the stack with the CTS/RTS abuse covered earlier, as well as various overflow, flood, and fuzzing attacks.

  The signatures in various WIPS products are all over the place; in general I place higher value (or more risk) in events triggering the types of DoS attacks that may result in code execution or crashing devices, versus ones that will impact RF. While still an issue, if RF is impacted, the network admin will have several ways to see that in dashboards—and you can bet if they miss that the help desk will be getting calls.

• Client Misassociation It's ideal to ensure enterprise-managed endpoints aren't connected to an AP or other unauthorized device. The client misassociation signatures will identify managed endpoints that have connected to rogue, external/neighbor, or honeypot APs (see Figure 7.13).

  This prevents managed devices from accidentally communicating over non-encrypted networks, using unsecured or unauthorized resources, and mitigates opportunities for man-in-the-middle attacks.

  

• Use of Apple AirDrop Another topic of Chapter 6 covered the security risks associated with zero configuration (zeroconf) networks including overlay protocols such as Bonjour and mDNS. Use of Apple's AirDrop protocol can absolutely introduce risks to the enterprise environment, as you saw in the last chapter. AirDrop facilitates direct file transfers between Apple devices; the discovery and connection is initiated over BLE, and the file transfer occurs over Wi-Fi. In 2021, researchers found vulnerabilities in the exchanges that occur over BLE, demonstrating it reveals the user's phone number and email address. That gap makes it trivial for an attacker to connect to a victim and deliver payloads. Assuming no attack in standard use, the Wi-Fi transfer is encrypted, obscuring any visibility into the payload; meaning the enterprise security tools can't inspect and protect an endpoint from malicious code (whether it was an intentional attack or malware).

  For this reason, there are WIPS signatures designed to identify and alert on these peer-to-peer sharing instances when it occurs within range of the infrastructure APs or WIPS sensors.

• Use of Attack Tools or Methods Most WIPS products will have signatures tuned to pick up on behavior indicative of common attack and cracking tools for Wi-Fi (and sometimes Bluetooth).

  Specific tools you may see signatures for include Fake AP, AirPwn, Airsnarf, Chop, ASLEAP, Karma, cracking tools, Hotspotter, and Wellenreiter. Additionally other fragmentation attacks, DHCP attacks, unauthorized DHCP, and dictionary attacks can usually be detected.

Wireless Rogues and Neighbors

Wi-Fi and WIPS products use their own words for classifying devices they've discovered, and I don't feel they're always quite accurate in terms of determining risk level. Following are widely accepted definitions that more precisely reflect the risk and appropriate level of concern for each.

• Authorized AP Authorized, valid, or approved APs are APs that your WIPS platform has identified as approved enterprise APs. These may be automatically discovered (especially with WIPS integrated into APs) or they may be manually identified and authorized in the system to prevent false positives.
• Rogue AP Rogue APs are unauthorized APs that are connected to the enterprise wired network. Rogue APs introduce an extremely high level of risk to the network, since the unauthorized AP is likely broadcasting unfettered access to a live production wired network without proper security controls.

  Rogues make their way onto the network in several ways. Most often rogues are introduced when employees or students decide the enterprise-provided Wi-Fi is not sufficient and they connect a personally owned AP (usually a consumer-grade wireless router) and configure it for their use.

  As a quick aside, I've mentioned several times throughout the book that a quality RF design for Wi-Fi is crucial to security, and this scenario provides further evidence to that point.

  Rogue APs can be prevented by enforcing edge switch port security, but due to a long list of complications, that is a rare scenario. And, while edge port security is the best way to protect the network from rogue devices, in the absence of that, detecting them over the air is second-best.

• Neighbor or External AP A neighbor or external AP is one that's in a close enough proximity to be heard over the air but is not determined to be connected to the enterprise network. That means an external/neighbor AP isn't a rogue, it's just something nearby, meaning it's not as high of a security risk, but can present complications and should be addressed.

  To address a neighbor/external AP, simply label or flag it in the WIPS system as a known neighbor/external AP. Those likely won't move or change too much. The exception being many vehicles these days include mobile hotspots and those will come and go, creating a volume of alerts.

  Other unexpected external APs may warrant further inspection. Specifically, there are two cases where external APs should be investigated.

  First, if it's a user within your organization with an unapproved AP, even if it's not connected to the enterprise network, it is likely causing interference with the infrastructure Wi-Fi and should be removed. This includes mobile hotspots, MiFi devices, and anything else such as printers or casting devices broadcasting networks.

  Second, an unexpected external AP could be a malicious user with either a hardware AP or a software-generated tool AP that is preparing for a Wi-Fi attack. The hope is that any attack launched would trigger one of the other signatures; this eliminates the need to attempt to monitor all external AP alerts (which is not reasonable in most organizations).

• Honeypot AP Honeypots can be good or bad. Good honeypots are organization-owned and used in many forms for network security; they're designed to lure an attacker to a specific (fake) target. This allows forensics and incident response teams to study the attack methods and it can serve to lure attacks away from real production assets.

  On the other hand, bad honeypots are used by an attacker to lure legitimate users to a malicious asset pretending to be an enterprise resource. In Wi-Fi applications, a malicious honeypot impersonates an enterprise AP and lures unwitting clients to it. By doing so, the malicious AP can attack the endpoint, deliver malicious payloads, or capture credentials, among other things.

  If an organization has more than one Wi-Fi system or vendor in the environment, broadcasting the same networks, it will likely be categorized as a honeypot. This is a similar situation to the organizationally owned external AP described earlier.

Authorized APs are enterprise-managed or known APs in the environment. Rogue APs are unauthorized APs connected to the enterprise network. They may not be intentionally malicious but should be removed for security reasons. Honeypot APs impersonate enterprise APs in an attempt to lure clients to them, and neighbor or external APs are just innocuous APs that can be “heard” nearby. See Figure 7.14.

For detecting threats such as rogue APs, detection isn't always straightforward; it's not a binary rogue/not-rogue determination. Systems will classify APs as rogue but that may actually mean it's a suspected rogue, and for that reason many systems will layer inputs to build a confidence level.

For example, if several infrastructure APs see an external AP (an AP not within the management of the Wi-Fi system reporting it) then it may be a rogue. If the system then adds context based on seeing MAC addresses over-the-air and on the wired network from that AP, there's a much higher chance it's a real rogue.

Methods of rogue detection vary greatly from vendor to vendor; many of the methods are proprietary, and some are even patented. Also, these methods are continually evolving, which is why we're not delving to great depths on the classification methodology.

It is, however, important to understand the methods your WIPS vendor is using and ensure the environment is amicable to those. For example, products that add wired side visibility may need SNMP or other credentials to access switches and routers for polling. If the WIPS product is attempting to correlate broadcast traffic between wired and wireless, the sensor will need to have a presence in each VLAN being monitored, since broadcast traffic (unless specifically configured to do so) will not cross layer 3 boundaries. Keep in mind the VLANs you'll want to monitor aren't limited to the Wi-Fi designated VLANs; if you're looking for rogues, you want to watch all VLANs that have access to the internal assets.

The point is that each vendor will have a few conventional methods, and likely a few special sprinkles on top so do your homework and architect accordingly.

Table 7.1 offers a quick overview of the AP classifications. The suspected rogue category has been added to demonstrate the process most WIPS go through during classification. In these cases, the WIPS system has seen the unknown AP over the air but doesn't have enough data correlation to determine whether it's connected to the wired network.

WIPS Mitigation and Containment

What happens after a WIPS identifies suspicious or malicious behavior? Depending on the product and options selected, the system may be able to perform certain containment and mitigation actions.

The WIPS system (which could be overlaid or integrated into the Wi-Fi APs) can always perform over-the-air mitigation, and some products also include a few wired network mitigations.

For over-the-air mitigation, the process is simple—the WIPS will send spoofed de-authentication or disassociation packets to sever the connection between the targeted AP and client. The range of mechanisms include:

• Spoofed de-authentication packets as the AP (to the client)
• Spoofed disassociation packets as the AP (to the client)
• Spoofed disassociation packets as the client (to the AP)
• Spoofed channel change beacon as the AP (to the client, forcing the client to the wrong channel, effectively to a black hole or tarpit)

Vendors use combinations of these spoofed packets depending on the scenario and desired result. For example, if a client is attaching to a rogue AP and the mechanisms used are spoofed de-auth or disassociation packets, the client can (and will) simply continue reconnecting repeatedly to the rogue AP, and the WIPS would have to constantly work sending packets to sever the connection.

Instead, if the WIPS were to send a channel change packet, directing the client to a fake channel (really just a channel the rogue AP isn't using) then the client will continue carrying on as usual for some period of time instead of repeating the rejoin process.

Combinations of the same packets can be used for varying forms of mitigation and containment. It's possible for a WIPS system to disable a rogue AP or rogue client in any number of ways.

Remember that due to laws of physics, in integrated systems where a Wi-Fi AP is servicing clients and pulling double duty as a WIPS sensor, the AP radios can only do one or the other at any given time. Relying on over-the-air remediation may not be desired, effective, or efficient.

In fact, in the cases of rogue APs, the action that should be taken is to identify the rogue AP, physically locate it (via wired and/or Wi-Fi locationing), and then have it removed from the network.

There should definitely be an organization-wide policy on the use of personal infrastructure devices within the enterprise environment, and that policy should address (and disallow) what would be classified as rogue APs.

Figure 7.15 depicts an over-the-air mitigation. In this example the WIPS is using both a broadcast de-authentication frame (to FF:FF:FF:FF:FF) as well as a unicast frame directed to the client (to 00:00:43:24:A4:C5). Both of the spoofed packets are sent from the WIPS but appear to be from the rogue AP.

The other option for mitigation is over the wired network. Wired mitigation is a feature not often found in the integrated Wi-Fi AP products but is common in overlay systems. The use of wired mitigation for rogue APs is yet another example of why holistic security architecture is so important. Our networked environments are an ecosystem and coordinating controls and mitigations across managed endpoints, the wired network, and Wi-Fi infrastructure offers a level of flexibility and security not attainable with a single security product.

In addition to WIPS, wired mitigation of rogue APs can be achieved with various network access control (NAC) products, which are able to disable edge switch ports via SNMP, CLI, or APIs. Of course, if the enterprise APs are being authenticated to the wired network as covered in Chapter 6, then edge ports using port security or 802.1X would have preemptive control over rogues. They simply wouldn't be allowed to connect and pass traffic through the wired network to start with.

Legal Considerations of Over-the-Air Mitigation

Over-the-air mitigations have legal ramifications every architect and organization should be aware of. The following example includes the Federal Communications Commission (FCC) in the U.S., but my understanding is this same model is true for most countries in Eastern Europe and North America.

Technically, blocking of wireless signals in any way is a violation of Section 333 of the U.S. Communications Act, which states that “No person shall willfully or maliciously interfere with or cause interference to any radio communications of any station licensed or authorized by or under this Act or operated by the United States Government.” That statement encompasses any kind of jamming as well as the mitigation techniques described here with WIPS.

Although that clause has been in the Communications Act for over three decades, it had never been a problem for enterprises using WIPS including mitigation and containment. At least, not until there was an incident. Here's the short version of what happened in 2013 that sent the Wi-Fi industry spinning.

In 2013, Marriott used WIPS (specifically spoofed de-authentication packets) to mitigate (disable) the Wi-Fi hotspots of guests at a convention center in its Nashville, TN Gaylord Resort property. Regardless of the real reason, the perception and complaint by guests was that Marriott was attempting to force conference attendees to use (and pay for) their hotel-managed Wi-Fi at the venue, which was a non-trivial amount. Tsk, tsk. Oh, Marriott.

A complaint was officially made, a lawsuit was filed, and in 2014 the FCC formally fined Marriott $600,000 USD and issued an order summarizing the activities, the fines, and a multi-year probationary period of self-reporting. The front page of the order is shown in Figure 7.16. You can read the file by searching FCC records for file number EB-IHD-13-00011303.

In that order, the FCC cited Marriott as being in violation of Section 333 of the U.S. Communications Act. They underscored the expectation that airspace is not “owned” by any person or organization, meaning companies did not have the right to disrupt anyone else's use of that airspace, even within their own buildings and their own outdoor properties.

As you can probably imagine, the Wi-Fi and WIPS industries reeled after this finding. It's likely one of the main contributing factors to the demise of the overlay WIPS market. If organizations can't legally automate mitigation for security, offering an overlay solution doesn't add much value since the Wi-Fi APs could reasonably perform interim scanning and no enforcement means there's no requirement for multiple dedicated security radios.

However, there are legitimate use cases for wireless mitigation, and I firmly believe at some point the FCC (and possibly other regulatory bodies around the world) will need to reach an agreement with their citizens about what's appropriate. Here's why: Consider a hospital environment. Even now, they're rife with wirelessly connected systems that connect staff to electronic health records (EHR) on mobile carts and tablets, enable critical nurse calling systems, power telehealth, and facilitate lifesaving monitoring and alerting systems. Wirelessly connected devices are increasing, not decreasing, and the criticality of and reliance on these systems is also growing.

So then, in our made-up scenario, what happens in a few years from now when a malicious user walks into a hospital with an RF jammer, disrupting entire systems in the facility, and ultimately launches an attack that results in loss of life? Who's at fault here? Obviously, the attacker is at fault, but I imagine the families of the patients impacted will wonder why the hospital didn't protect itself, protect the patients, and ultimately protect human life—its most precious asset.

This is just my personal opinion, but if, as a society, we're saying we're ready to rely fully on wireless to connect our most critical assets, then we need to agree on ways to protect them accordingly.

De-authenticating users for monetary gain is not acceptable, but you can probably think of a thousand scenarios where mitigation is appropriate.

All of this is to say that organizations will have to make a cautious and informed decision about whether and how to use over-the-air mitigation. Like BYOD policies, this is not a topic to be decided by network or security architects or system administrators. It's a conversation about risk (legal and technical) to be had with the decision-makers (and lawyers).

Spectrum Analyzers and Special-Purpose Monitoring

Related to WIPS and security monitoring, there's a subset of technologies for monitoring layer 1 that deserve special attention before we address WIPS recommendations:

• Spectrum Analyzers
• Special-Purpose Monitoring

You'll find that many WIPS products include spectrum analyzer features, but capabilities are often limited by the type of radios built into the WIPS device.

In contrast, spectrum analyzers and other special-purpose monitoring tools are purpose-built products that can offer full visibility into a breadth of RF spectrum beyond integrated WIPS products.

Spectrum Analyzers

Spectrum analyzers are intuitively named; they use one or more radios to analyze the RF (the spectrum) and offer a visual representation of that data. Spectrum analyzers (or spec-ans for short) are great for looking beyond the data applications of wireless and seeing the entirety of the radio frequencies within a given band. They're often used in enterprises by Wi-Fi professionals to identify sources of non-Wi-Fi interferences (such as microwave ovens, heavy equipment, or other emitters).

Some WIPS systems include a spectrum analysis function, while others only monitor the slices of airspace in use for data transfer. If a WIPS is only concerned with layer 2 (non-RF) based attacks on Wi-Fi, it may scan through the specific Wi-Fi channels (such as 1, 6, and 11 on 2.4 GHz and 36, 40, etc. on 5 GHz) and report on security incidents within those ranges.

Other products may not only scan the known or in-use Wi-Fi channels but also watch the rest of the spectrum for interference and anomalies. Some products can be configured to do both; the extent to which a system can operate as a spectrum analyzer will depend on the radio configuration and is tied heavily to whether the sensor is integrated or overlaid.

A spectrum analyzer operates at layer 1 (RF for Wi-Fi, 802.11 PHY), a protocol analyzer at layer 2 (802.11 MAC), and packet analyzers at layer 3 and above, as shown mapped to the OSI stack in Figure 7.17.

From a security perspective, even without the decoding of 802.11 packets, a spectrum analyzer can provide insight into layer 1 RF-based events that may be impacting the availability of the enterprise's wireless networks.

Although I've mentioned 802.11 a lot here, the beautiful thing about spectrum analysis is it can happen on any radio frequency that the radio(s) supports. As you'll see next, spectrum analyzer hardware can be paired with accessories and software to create a powerful RF monitoring and security tool.

Many of the products in the niche monitoring space are built with software-defined radios (SDRs), which makes them easily reconfigurable to support new use cases and technologies.

As one example, the MetaGeek Wi-Spy hardware dongle radio is a spectrum analyzer. Combined with its Chanalyzer software, the spectrum (RF, layer 1) can be viewed along with the Wi-Fi networks (802.11 MAC, layer 2), as shown in Figure 7.18. Spectrum analyzers capture the RF utilization over a specified spectrum (based on radio capabilities) and display it as values over time using colors similar to a heatmap.

Some of the more common spectrum analysis tools in enterprise use today include:

• Spectrum analyzers built into Wi-Fi and WIPS sensors (many enterprise APs can be converted to operate as spectrum analyzers within their radio space with some limitations)
• NetAlly® AirMagnet® Spectrum XT, supports 802.11 and Bluetooth (www.netally.com)
• MetaGeek Wi-Spy + Chanalyzer, support 802.11 (www.metageek.com/)

The second and third bullets are representative of products that include software and a dongle (usually USB) with a radio. At time of writing most products still only support 2.4 GHz and 5 GHz radios with plans to release 6 GHz shortly. Products described for special-purpose monitoring (next) include products that extend well beyond Wi-Fi and Bluetooth.

NetAlly's AirMagnet Spectrum XT software offers many ways to view and analyze the RF spectrum (see Figure 7.19). Spectrum analysis software such as this one relies on access to a radio with capabilities in the range to be analyzed (see Figure 7.20). The adapter contains the radio required for spectrum analysis and can be used with a laptop or tablet and the Spectrum XT software.

Recommendations for WIPS

Now that we've explored every aspect of WIPS including layer 1, we'll resume the WIPS discussion with recommendations. When it comes to planning WIPS in the security architecture, there are a lot of inputs to factor and additional research is always required. Implementations, depth of visibility with signatures, and options for mitigations vary by vendor. Also, the organization's security requirements and comfort with mitigation plays a major role in planning WIPS workflows.

Many compliance frameworks include requirements for some form of WIPS capabilities in the scoped environment—specifically alerting, not mitigation.

As you learned with the FCC ruling (and similar examples outside the U.S.), organizations may be limited by what they can do in terms of mitigation (legally) and that situation has made it a bit easier to rely on integrated AP WIPS sensors in years past.

Recommendations for WIPS can be summarized as follows:

• All organizations will benefit from visibility of WIPS, and it should be enabled (it's disabled by default in most Wi-Fi products).
• To start, use the visibility and alerting features only, and do not configure mitigation or containment unless authorized by the organization to do so.
• Like any IPS tool, WIPS will require maintenance, especially early in the project for tuning.
• Focus alerting on the most critical events, such as rogue APs to alleviate alert fatigue by removing or tuning down inconsequential or false positive WIPS events.
• Rogue APs should be addressed by physically removing them from the network, and there should be an organizational policy disallowing connection of personal APs to the enterprise network.
• Neighbor or external devices within your buildings but not attached to the network (such as smartphone hotspots, printers, and ad-hoc networks) can cause RF interference and impact availability. Reinforce desired behavior within your organization and ensure the enterprise Wi-Fi quality and coverage is sufficient to eliminate the need for users to supplement.
• Tune the WIPS appropriately for your environment; for example, you don't need to be emailed WEP weak IV alerts if you're not using WEP in the environment, and you may be less concerned about suspected but unconfirmed rogues if your infrastructure is authenticating APs to switch ports or uses NAC. As another example, in universities with a large personal device population, the decision may be made to ignore ad-hoc networks and AirDrop.
• Use mitigation and containment features only when approved formally by the organization and use them only for the most critical security concerns, remembering that integrated AP and WIPS products will be limited in containment capabilities.

There are additional security alerts we're interested in outside of the WIPS-detected events just covered, such as any incidents where admin access to the system is being brute-force attacked. The next major section of this chapter is “Logging, Alerting, and Reporting Best Practices,” where I cover not only more recommendations for WIPS alerting, but also these other security events outside the purview of WIPS.

Security Event Logging

As with many topics in this book, centralized logging is a minimum requirement in most compliance frameworks.

Most enterprise Wi-Fi products support the option to send logs, alerts, or traps of various kinds to a log server. Event logging serves several purposes including:

• Capturing and memorializing significant changes to the infrastructure devices (such as configuration changes, software updates, and reboots)
• Capturing security events for further processing or alerting
• Logging administrative access for audit purposes
• Logging administrative access attempts for security alerting

Exceptions to products that support this type of logging include API-based cloud products with no SNMP or local logging.

Centralized logging is much more efficient than attempting to configure individual alerting on products in the environment. And, as you'll see next, the more capable tools add the benefit of correlation to centralized logging.

If there's no robust logging product currently, and no budget to procure one, there are free tools to serve as a stopgap, but these usually have very limited capabilities. If you do choose a DIY approach just ensure the log server is part of the enterprise infrastructure and provisioned and secured appropriately; meaning, please don't download a free tool and send logs to your laptop.

Security Event Correlation and Analysis

If there is a central security platform, that's usually where the logs will be sent for ingestion. This classification of products goes well beyond logging and includes event correlation, analysis, sometimes parsing, and workflows for incident investigation and response.

Tools that fall within the category of security event correlation and analysis include an alphabet soup of acronyms such as:

• SIEM (security information and event management)
• SOAR (security orchestration, automation, and response)
• XDR (extended detection and response)

By the time you're reading this book, there will likely be more new acronym bullets. I'll spare you the detailed nuances that differentiate these products but will offer a bit of explanation.

Handheld Testers

Handheld testers are wonderful because they're small, portable, and very practical for sending onsite instead of having to dispatch a senior network admin for troubleshooting. By the way, I'm not covering spectrum analyzers here since they've been addressed earlier, but there are some handheld tools and applications that are purpose-built spec-ans.

Handheld tools with testing functions are designed to give technicians an easy way to test and validate Wi-Fi. Some of the checks and functions they perform include:

• Airtime availability and quality
• RF noise levels and RF interferers
• Network and network services availability (e.g., DNS, DHCP)
• Connectivity metrics such as throughput
• Security settings of the SSID
• Detection of possible rogue devices
• Verifying access rights and segmentation
• Path analysis to a specified target (internal or Internet)
• Over-the-air packet capture

Just as with spectrum analysis and WIPS, handheld wireless testing tools must have radios that support the RF spectrum to be analyzed. For Wi-Fi products, that's 2.4 GHz, 5 GHz, and now 6 GHz.

There are many handheld testers and different industries, especially in telecom, have specific brands and tools commonly used. For the rest of us, the products most often used for Wi-Fi testing come from NetAlly (www.netally.com). Earlier in this chapter when we covered WIPS, I provided a brief history of NetAlly. You may recognize some of its tools from being branded Fluke Networks or NetScout. NetAlly is well known and supported in the industry and has a strong community of Wi-Fi professionals.

NetAlly has a suite of wired and wireless testing tools, but the two prominent for wireless purposes are its AirCheck G2 and EtherScope nXG products (see Figure 7.22). In full disclosure, I'm particularly fond of the EtherScope nXG; it carries a hefty price tag but is, as they advertise about, as close as you can get to a “portable network expert.”

Among other things, these handheld testers are great for identifying security misconfigurations that result in access that should be blocked. In the testing sequences, you can configure it to report as pass or fail depending on the result. For example, one test parameter may be to verify a user can access an internal server, and if that's successful it's a “pass” result. A separate test may verify that that user cannot access another network or resource, and if the user is able to access it (via the test) then it can be flagged as a “fail.”

RF Design and Survey Software

There are two sides to the coin of RF planning—there's RF design and survey, which can be two separate vendors, or two products from the same vendor that are integrated.

RF design software estimates coverage and includes output such as predicted coverage heatmaps, while RF survey software takes live measurements with a radio and documents the actual coverage and quality in a space. Design is predictive and survey is actual coverage.

RF Survey Hardware and Software

RF survey tools are a set of hardware (antennas) and software that, used together, take readings from an environment, and visually represent the RF coverage and quality.

The same vendors of RF design software also have survey products that include either handheld tools (such as NetAlly) or antenna kits or purpose-built hardware (such as Ekahau's Sidekick Pro) for this purpose. Software runs on a laptop, tablet, handheld, or smartphone, which is connected to the hardware with the survey radios. Figure 7.23 is a heatmap from a live RF survey. The AP placements represented here are estimated based on location algorithms in the tool. The darkest gray areas designate spaces where the signal quality did not meet specifications.

Network Protocol Analyzers

Network protocol analyzers offer unprecedented insight into the inner works of wireless, starting at layer 2. Again, as with any tool that's helping us over the air, use of a protocol analyzer relies on getting input from something that has radios capable of monitoring the RF in scope.

Depending on platform capabilities, packet captures can be accessed and viewed nearly real-time or offline as a static file.

The most common network protocol analyzer is Wireshark and there are plug-in color filters specifically for different wireless protocols to make life a bit easier (see Figure 7.24). Wireshark is supported by community volunteers and made available as a free download for Windows and Mac.

Cloud-hosted network vendors may also use cloud-hosted solutions for packet analysis, such as CloudShark. In fact, some cloud-hosted management platforms support auto-packet capture and direct integration with a cloud-hosted analysis platform.

Testing and Troubleshooting Applications

Along with the more formal tools and products mentioned thus far, there are scores of other testing and troubleshooting applications, many of which run on Apple iOS and Android smartphones or tablets. They come, they go, and there are too many to cover individually here, but many Wi-Fi and networking blogs and podcasts cover these supplemental tools.

At time of writing, a few popular tools include:

• MetaGeek (www.metageek.com)
• WLAN Pi (www.wlanpi.com)
• EAPTest (app available for Apple iOS)
• Wi-Fi Analyzer and miscellaneous apps available for Android)

Secure Management Access

• Log all successful management access
• Log all failed management access attempts

Always log all management access attempts, both successful and failed. This supports event correlation and enables the system to alert on brute force attacks to the management of the system.

If your platform supports it, log discrete commands issued as well. This is possible with certain TACACS+ deployments and/or with privileged access management (PAM) tools. Both of these topics were covered in more detail in Chapter 6.

Infrastructure Integrity

• Log configuration and software changes
• Log reboots of all infrastructure devices
• Log all physical access
• Log all other configured WIPS events

Log configuration and software changes, which can be used to identify unauthorized configuration changes, and to trigger an event to match a configuration against the approved baseline.

Logging reboots of the infrastructure devices (wired and wireless) helps correlate outages and other user-impacting events.

Physical access to network closets and datacenters should be secured to the degree possible, and for systems that support identity-based access (such as card readers) that access should be logged for event correlation. In some platforms, physical location of users is an input for several triggers, including alerting if a user has physically entered one area of a building but logged in from another.

Also log all available events from the WIPS system, even if you may not be alerting on them all. This, too, helps with event correlation, and something that seemed innocuous may turn out to be activity preceding an attack.

Client Security and Other WIPS

• Log airtime anomalies
• Log any client-related WIPS events
• Log specially authorized endpoint traffic
• Log attempts of clients accessing unauthorized resources

WIPS-generated events related to airtime anomalies (such as CTS/RTS) may be false alarms. These events, when malicious, are specifically indicative of DoS attacks versus delivering payloads or infiltrating systems. For this reason, you may not want to alert on these events, but the data should be available for investigation later.

If your platform supports it, log attempts of endpoints accessing unauthorized resources along with logging access to specially authorized resources between security zones. For example, if traffic from a guest network to an internal network is not allowed, but there's a policy allowing access to specific assets (such as a printer or screen casting device) log the allowed traffic. Logging disallowed and allowed traffic can help during incident response and forensics.

Secure Management Access

• Alert on brute force login attempts
• Alert on anomalous logins

At a minimum, you want to be alerted if the system is experiencing any form of brute force attack, including (and especially) attacks against management logins. If the platform doesn't support this natively, this is one place to get a little digital duct tape and make it happen.

For more mature security programs with anomaly detection engines, it's ideal to also trigger immediate alerts on anomalous logins—for example a login from an IP address or network that deviates from the norm.

Infrastructure Integrity

The following alerts are loosely organized in order of precedence if your workflows and resources can't handle all alerts:

• Alert on rogue or honeypot APs
• Alert on AP or controller offline
• Alert on DoS attacks
• Alert on failed attempts of AP authentication to switch
• Alert on changes of an AP MAC or IP address
• Alert on unauthorized physical access or attempts
• Alert on expired certificates
• Alert on misconfigured AP
• Alert on devices that support UPnP

Many of these alerts will depend on a third-party tool of some sort—logging or SIEM. However, every Wi-Fi platform I know of supports basic alerting for rogue APs and you definitely want to enable that directly or via another tool. Along the same vein as strict rogues, alert on anything in the rogue family such as honeypots and wireless bridges (which may not appear as rogues because they're not beaconing).

I strongly suggest alerting on any infrastructure device that goes offline unexpectedly. There are many organizations and particularly universities that ignore offline APs because of the sheer volume in their network. Even knowing that, in large organizations with tens of thousands of APs, there are easy ways to flag maintenance windows and I advise security-conscious clients to alert on these events. It can be a precursor to something more, and even if it's not a security issue, it will impact users and should be addressed quickly.

If there's a WIPS function, it's good to alert on the DoS suite within WIPS (which will vary from a handful to dozens of signatures). These may require tuning to reduce false positives and they can be omitted in many cases if the tuning is not sufficient. If there's an outage, most environments will hear about it from the user population if nothing else.

The next two alerts speak to the risks of an unauthorized user accessing the network via the edge ports serving APs. If an AP is authenticating to the network, and repeatedly fails, that's a good indication someone has removed the AP and is attempting to connect to the network with its port. Similarly, in the absence of port security, if the AP suddenly has a different MAC address or IP address that also is an indication someone is attempting wired access through the AP's network drop. NAC products do a great job with profiling that adds a layer of protection against MAC spoofing for scenarios just like this. Again, it doesn't matter where the alert comes from—e.g., Wi-Fi product, log server, SIEM, or NAC.

Expired certificates can (and do) wreak havoc. In a perfect world, you'll be tracking infrastructure certificates and reporting on them proactively, but if somehow that got missed, an immediate alert is warranted before an entire subset of the wireless infrastructure is deemed unusable.

Alerts for misconfigured APs can be handled a few ways. The goal is to prevent any enterprise APs from operating in a manner less secure than designed. These alerts may be generated via WIPS (if supported) or can be configured through a SIEM that can compare current and prior configurations and alert on changes or deviations from a baseline.

Lastly, we've talked about the horrors of universal plug and play (UPnP), which reconfigures firewalls to allow unplanned inbound traffic. UPnP devices can be found by monitoring for Simple Service Discovery Protocol (SSDP) traffic. If your Wi-Fi or WIPS monitoring tools don't offer this, it's available in vulnerability assessment tools that offer network monitoring. SSDP is yet another zeroconf protocol designed for residential use.

You should also be alerting on added infrastructure devices—new DHCP servers, new routers, or any new device with OUIs from residential router manufacturers. Find some way to ensure these devices aren't on your network, ever.

Client Security and Other WIPS

• Alert on ad-hoc networks
• Alert on client bridges
• Alert on malformed packets or fuzzing
• Alert on broadcast de-authentication or disassociation
• Alert on use of known attack tools

Alerting on ad-hoc networks is appropriate for security-conscious organizations but isn't for everyone. Universities, retirement homes, certain healthcare facilities, and in general networks with residential areas are likely to see volumes of ad-hoc networks. In addition, printers and screen casting products within enterprise environments may also use ad-hoc networks; these are the types of events you want to alert on and investigate. It may take a bit to get them under control, but in an enterprise, direct Wi-Fi printing should not need to be enabled. The same goes for screen casting tools. Those should be investigated and monitored; it's possible to implement them securely without using ad-hoc networks, and if the decision is made to allow the ad-hoc connections, that should be monitored (perhaps not alerted on though). Also, remember that these extra (non-enterprise networks) use up precious airtime and affect RF quality for all Wi-Fi in the area.

I can't think of a legitimate use case to allow client bridging in an enterprise environment. The risks of this feature were detailed earlier in the chapter and client bridges should be alerted on and remediated immediately. Remediation can entail contacting the user and instructing them to cease; it could be auto-remediation by reconfiguring a managed endpoint, or it could be to denylist the device MAC address(es).

Malformed packets and fuzzing are attacks that may crash drivers, disrupt services, and allow an attacker to deliver a malicious payload to clients. Given the severity of these attacks, immediate alerting is warranted.

There's no valid use of broadcast de-authentication and disassociation frames in normal Wi-Fi operation. If your WIPS system sees this activity, it's worth investigating. It falls just below alerting on fuzzing since these attacks (by themselves) will simply result in DoS.

Lastly, it may be advisable to alert on any WIPS events tied to use of known Wi-Fi attack tools. Again, these may require a bit of tuning and some attack tools may not be effective against your infrastructure so pick and choose accordingly to alleviate alerts that don't apply.

Secure Management Access

• Report on presence of default users or credentials
• Report on use of unencrypted management protocols

Maintenance of wireless security includes continuous reporting of the posture of the systems to ensure integrity is maintained. One such vital report should identify the presence of any default users or credentials, including (and especially) default SNMPv2 community strings (notably, “public” and “private”) along with any default user accounts. Default accounts include management accounts and users such as “admin” or “root” along with vendor-provisioned accounts for help desk or other users.

Along with checking for default users, reports should identify whether unencrypted management protocols are in use—specifically looking for HTTP and Telnet as well as unencrypted file transfer protocols.

Infrastructure Integrity

• Report on configuration changes
• Report on trending adoption of PMF
• Report on new APs or infrastructure devices
• Report on AP groups and configurations
• Report on use of unused/disabled protocols
• Report on expiring certificates

As part of maintaining infrastructure integrity, configuration changes (planned or otherwise) should be reported on at a regular cadence. If configuration changes are reported on and investigated appropriately, many of the following reports won't be needed other than as an occasional audit. As referenced in the intro to this reporting topic, many products include a security audit feature with built-in report templates that cover most if not all of the items here. These reports may be run quarterly (or as needed) to ensure the posture of the infrastructure and any compliance mandates.

For trending analysis and migrations, adoption of protected management frames (PMF, 802.11w) should be tracked. The migration plans must also entail upgrading the endpoints to add this capability.

New infrastructure devices (planned or otherwise) should be reported on, including the presence of new APs. Ideally that report should be reviewed to ensure new APs are in the proper groups; if not, other means of reporting or alerting should be used.

Just as with the audits to ensure unencrypted management protocols are disabled, there should also be reports occasionally to confirm other unused protocols are in fact still disabled. This might include discovery protocols and certain routing protocols as an example.

Expired certificates usually cause quite a mess, and therefore reporting on expiring certificates early (before they're expired) is ideal.

Client Security and Other WIPS

• Report on trending adoption of WPA3
• Report on client misassociations
• Report on use of zeroconf protocols
• Report on use of AirDrop and similar

If your organization is migrating to WPA3, reporting on the adoption of WPA3 is helpful for trending analysis. At some point, decisions will need to be made around when to sunset WPA2-secured networks, or when to reduce the scope of WPA2 networks to the subset of devices unlikely to be upgraded.

If your organization doesn't have a specific plan, start with quarterly reports for migrations and use each report to target populations of endpoints that require driver updates or hardware refreshes to take advantage of the WPA3-secured networks and PMF.

Client misassociation indicates a managed endpoint that's connecting to unmanaged, external, or unknown networks while in the organization. This may be an indication that users are trying to bypass enterprise security or content filtering. Generally, this doesn't require the immediate action of an alert, but should be addressed for security hygiene.

Highly secured networks won't include zero configuration (zeroconf) protocols such as Bonjour and mDNS, and they won't allow ad-hoc and peer file sharing protocols like AirDrop. For those organizations, alerting on these may be in order but at a minimum for any organization it's preferred to at least report on them at some regular interval to understand how prevalent they are in the environment. Even if these protocols are allowed by policy, it would behoove an organization to understand if managed endpoints are participating, and to evaluate the risk regularly.

Things to Remember

We covered these protocols in depth earlier, but I realize Chapter 3, “Understanding Authentication and Authorization,” was five chapters ago. Before you dive into troubleshooting, here are a few reminders about 802.1X, EAP, and RADIUS:

• 802.1X is an IEEE standard for port security on several media types including (but not limited to) 802.11 Wi-Fi.
• Extensible Authentication Protocol (EAP) is a standard for authentication and manages the key exchanges for encryption and is used with 802.1X for secured networks.
• 802.1X secured networks define mutual authentication, which means the server has to authenticate itself to the client (always with a certificate) in addition to the client authentication.
• A minimum configuration for an 802.1X secured wireless network involves the client, SSID, and an AAA server.
• AAA stands for authentication, authorization, and accounting (logging) and is most often a RADIUS server.
• WPA2-Enterprise and WPA3-Enterprise secured SSIDs use 802.1X with EAP.
• The EAP authentication happens between the client and the authentication server.
• Communication between the client and AP uses EAP protocol; the AP repackages them as RADIUS to communicate to the authentication server.

Things to Troubleshoot

There are twelve easy-to-check tasks for troubleshooting 802.1X, EAP, and RADIUS. The diagram enumerates where to check each item—at the RADIUS server, the AP/controller, wired network, or endpoint device.

Many of these requirements and additional details were covered in detailed in Chapter 3. Revisit that content for more detail.

Figure 7.25 is a holistic view of the 12 troubleshooting steps, which are divided into three groups. Some checks can be performed in the Wi-Fi infrastructure, some on the wired network, two on the endpoint, and seven can be checked on the RADIUS server itself. These tasks are listed ordinally, but you may not have admin access to all parts of the infrastructure included in the steps. If you only have access to the Wi-Fi system and the endpoint, then those are the first troubleshooting tasks for you, as indicated in Figure 7.25. The troubleshooting tasks are as follows.

If you're not seeing any activity at or from the RADIUS server, perform these five checks first:

1. Enable RADIUS accounting on the Wi-Fi system.

   Depending on the product, if accounting (logging) is not configured, you'll have nothing to check to investigate failure. Specifically, if you're using Microsoft NPS this is a manual setting within NPS.

2. Verify the Wi-Fi devices are allowed RADIUS clients.

   In the RADIUS server, ensure the Wi-Fi APs, controller, and/or AP network are configured as allowed RADIUS clients. If not, the system will not process requests from them. You should see this in the logs as well.

3. Test network layer 2/3 access between Wi-Fi devices and RADIUS server.

   If the Wi-Fi devices can't communicate with the RADIUS server, requests will not make it to or back from the server. The device(s) to check are the APs or controller acting as the 802.1X Authenticator. That will depend on your architecture and configurations. See Chapter 3 for more.

4. Verify the SSID is configured for 802.1X and the correct RADIUS server and ports.
5. Check and re-enter the RADIUS shared secret between RADIUS server and Wi-Fi devices.

   If logging is enabled, the RADIUS server will alert if there's an incoming request from an unknown RADIUS client.

If authentication requests are getting to the RADIUS server but the authentication is still failing, check these next four items:

6. Check the RADIUS server certificate.

   If the server certificate is not valid (expired), or the endpoint is configured (through group policy) to only allow specific certs, and that's not one, the authentication will fail, usually without a specific error indicating why. The same may happen if the RADIUS server was provisioned with a wildcard certificate.

7. Review the RADIUS server logs for failed reason code.

   Some RADIUS and NAC products will be very clear about the failure with a text explanation. If working with Microsoft NPS or similar, you may need to research the Microsoft reason code (available online).

   For example, NPS reason code 16 indicates authentication failed due to a user credentials mismatch. Reason code 22 means there's an EAP mismatch between the endpoint and the RADIUS server policy. Reason codes 48 and 49 mean the incoming request did not match an NPS network policy or NPS connection request policy, respectively.

8. Verify the configured EAP type of the endpoint matches what's allowed in the RADIUS server.

   The RADIUS policy may allow several EAP methods, such as PEAP with MSCHAPv2 as well as EAP-TLS or EAP-TTLS. The endpoint will probably be configured to use one; just ensure that is allowed in the RADIUS policy.

9. Check the client authentication user format.

   Most systems are pretty forgiving but if the logs indicate the user is unknown check the format, such as [email protected] or domain.com/user. Also ensure the RADIUS server has connectivity to directory services it's relying on to verify the users.

The last group of checks are appropriate if the authentication was successful, but the endpoint still doesn't have network access:

10. Verify the endpoint's DHCP and DNS.

    If the endpoint wasn't able to get an IP address through DHCP, or it obtained an address but has a DNS server that's not reachable, it will not have network access after the authentication. If there's no IP address, retrace the path through VLAN and IP helpers to DHCP server to find the cause.

11. Check for a dynamic VLAN assignment in RADIUS server policy.

    If the RADIUS server is configured to return a dynamic VLAN (or any dynamic authorization such as downloadable ACL) it may not be correct; that network may not be fully configured; or there's a mismatch in the format of the VLAN with how the Wi-Fi expects to see it (e.g., VLAN ID versus name).

12. Check the endpoint's network access to the default gateway.

    If the endpoint has an IP address and reachable DNS server, check its access to the default gateway. If the gateway is not reachable, it's possible the IP address is in the wrong network, or another misconfiguration occurred on the wired side.

MAC Address Formatting

Requirements for setting the MAC address format vary by product. Some just auto-magically work, while others require the delimiters to be specified to match the MAC addresses in the database (wherever that may be). The format specifies whether a MAC address is parsed as “aabbccddeeff” (no delimiter), “aa:bb:cc:dd:ee:ff” (multi colon), or any number of formats. The most common formats are outlined in Table 7.3.

This is one quick and easy thing to check. The logs will show how the MAC address is coming in, and it's a trivial task to look at the database and see how they're represented there. Most vendors will include delimiter instructions, if required, in their configuration guides.

MAC Authentication Bypass AAA Settings

MAB is a fall-through sub-function of an 802.1X AAA configuration on a device (switch, AP, etc.). If MAB is not working properly and other parameters have been checked, it may be the AAA settings are not accurate.

Figure 7.26 highlights the complexity of port-level configurations of 802.1X with MAB on a Cisco switch. I'm using Cisco as an example, but all vendors suffer this challenge due to the nature of 802.1X and the fact that it's a port-level configuration.

Similar settings for an SSID are more streamlined but if you're troubleshooting APs not authenticating to a switch, this serves as a perfect example. This output shows an example of a port-level config for 802.1X with MAB, and includes instructions such as:

1. First, instruct the port to attempt to authenticate the endpoint with 802.1X.
2. Then, if 802.1X times out, attempt to authenticate with MAB:
   • Prefer 802.1X over MAB
   • Periodically reauthenticate
3. If the RADIUS server is unreachable, reinitialize to VLAN XX.
4. Reinitialize the voice VLAN on the port.

In this example, the port configuration is taking advantage of multi-auth to allow multiple endpoints on the port (common with laptops daisy-chained with VoIP phones). With any vendor deployment there may also be temporary code to allow for a phased deployment.

In these cases, it's best to check with your vendor (switch or Wi-Fi) and consult their documentation or validated design guides. 802.1X gets especially persnickety on wired ports and behavior may be unpredictable as vendors (all vendors, not Cisco specifically) include operations that are off-standard. MAB itself is not a standard, nor is it part of the 802.1X specification, meaning each code revision or product may vary slightly in operation here.

Settings on the RADIUS and Directory Servers

Authenticating a device based on its MAC address as a username and password sounds far more straightforward than it is in practice.

By virtue of using a MAC address as both a username and password, a few basic security principles are violated and may require some tweaking. These include:

• Most policies disallow using a password that is equal to or similar to the username
• Most policies require the password to be rotated on a specified schedule (such as every 90-180 days)
• Most password policies require password length and complexity

These may require the directory or group policy to accommodate an exception for these devices.

Also, older products including prior versions of Microsoft IAS RADIUS required setting the account password to allow reversible encryption in order for MAC authentication to work.

Wi-Fi Training and Certification

Certified Wireless Network Professionals (CWNP) is a training and certification organization that's part of Certitrek. CWNP has a suite of programs for vendor-neutral 802.11 WLAN (Wi-Fi) networking including:

• CWNA® - Certified Wireless Network Administrator
• CWSP® - Certified Wireless Security Professional
• CWDP® - Certified Wireless Design Professional
• CWAP® - Certified Wireless Analysis Professional

The CWNA is considered the entry-level certification and is required for recognition of any of the specializations (Design, Security, or Analysis). Although foundational, the CWNA content is by far the most extensive in the CWNP portfolio and is challenging due to the pure breadth of topics covered. Prep materials for CWNA teach all basic concepts of 802.11 including RF theory, modulation and encoding, antennas, network design and architecture, as well as troubleshooting.

The CWSP focuses on Wi-Fi security, but its content differs greatly from this book's. CWSP focuses more on security protocols and less on applied security concepts for architecture. It's a great supplement to this material for the Wi-Fi professional who wants to dig deeper into specific topics.

CWDP is the design course, and covers topics related to proper RF design, planning, and validation of 802.11 networks. You've heard throughout this book that proper RF design is vital to Wi-Fi security and the prep courses for CWDP are focused on that knowledge.

Last but not least, the CWAP (analysis professional) is regarded as the pinnacle of the specializations. It requires a deep understand of 802.11 protocols and packet structure and the courses for CWAP are heavy in packet analysis, frame formats, and troubleshooting.

Information on CWNP, its certification programs, training classes, and exam objectives can be found at www.cwnp.com.

IoT Wireless Training and Certification

At time of writing, the CWNP collection of IoT courses is the most prominent vendor-neutral offering targeted for Wi-Fi pros seeking competency in IoT technologies. There are industry- and product-specific trainings focused on specific technologies that readers are encouraged to research and seek.

CWNP doesn't only focus on Wi-Fi. In recent years, they've released a second track of certifications and training programs dedicated to non-802.11 wireless for IoT:

• CWISA® - Certified Wireless IoT Solutions Administrator
• CWICP - Certified Wireless IoT Connectivity Professional
• CWIIP - Certified Wireless IoT Integration Professional
• CWIDP - Certified Wireless IoT Design Professional

Like the CWNA program for Wi-Fi, the CWISA certification has a similar depth and breadth of content including RF technologies appropriate for Bluetooth and BLE, cellular, Zigbee, and others. Also as with its Wi-Fi counterpart, the CWISA is the foundational certification required to attain the specializations mentioned next.

The CWICP focuses on connectivity of IoT devices and takes a deeper look at the protocols in 802.15.4 networks (Zigbee, ISA, WirelessHART, 6lowPAN, and Thread) as well as long-range connectivity protocols such as Sigfox and LoRaWAN.

CWNP's CWIIP moves up the stack to topics of IoT integration, covering transport protocols like MQTT, CoAP, and AMQP. The integration content also covers use of APIs, programming, libraries, and Python programming fundamentals.

Lastly, in the IoT family, the CWIDP covers IoT design comparable to the CWDP for Wi-Fi design.

Network and Cyber Security Training

Security architecture is holistic, and as such it's a great idea to round out wireless knowledge with other network architecture and network security learning. (ISC)2, CompTIA, and SANS offer training and certification in areas of network and cyber security that include but extend beyond wireless.

• (ISC)2 Systems Security Certified Practitioner (SSCP)
• CompTIA Security+
• SANS various courses

(ISC)2 SSCP is a vendor-neutral certification program designed for a breadth of IT professionals and system admins looking to integrate security with practical knowledge. It covers security operations, identity, authentication, and access controls, risk analysis and security monitoring, incident response, cryptography, PKI, network and domain security, and system security including MDM.

(ISC)2 is unique in that most of its certifications are ANSI accredited, and that it's a not-for-profit membership-based organization. This means the SSCP (and other certifications) meet rigorous international standards for quality and process control of creating and administering certifications. Qualified professionals that pass an (ISC)2 exam become part of the global membership. Information on SSCP can be found at www.isc2.org.

CompTIA Security+ is a vendor-neutral program for cyber security with a strong focus on networking technologies including Wi-Fi and other wireless. Many of the concepts overlap and extend topics of this book including risk and data privacy, identity and authentication, PKI, cryptographic concepts, hardening, types of attacks including Wi-Fi, security assessments and penetration testing, and secure network architectures. At time of writing the Security+ content includes WPA3. You can find the most up-to-date information at www.comptia.org.

SANS offers a breadth of security courses ranging from network security to pen testing, including ethical hacking, monitoring and detection, and specialized courses for automation scripting, cloud security, and forensics. Find their training portfolio at www.sans.org.