Five Minutes and an Empty Port Part 9: MAC Filtering, USB Device Control, and Wireless IDS

Parts 7 and 8 covered the two strongest controls in this series, Layer 2 hygiene and 802.1X with a real NAC platform behind it. This part closes the defensive arc with three more, each useful, and each worth being honest about the limits of rather than presenting as a complete answer on its own.

MAC OUI and vendor filtering

The first three bytes of every MAC address, the Organizationally Unique Identifier, identify the manufacturer, and a lot of network hardware still ships with a policy option to allow or block traffic based on it. In principle this sounds like it should catch some of what this series has covered: Hak5 devices, ESP32 boards, and Raspberry Pi hardware all have recognizable OUI ranges.

In practice, this control is genuinely weak, and this series has been honest about weaker-than-advertised techniques before, Part 4’s Karma assessment being the clearest example, so it’s worth applying the same standard here. A MAC address, OUI included, is trivially rewritten in software: ip link set eth0 address <any address> on Linux, or a tool like macchanger, changes it in seconds with no special hardware. Every device covered in Parts 2 and 5, including the real Raspberry Pi 4 built in this series, can present whatever OUI its operator chooses. OUI filtering is worth having as one signal among several, particularly for flagging anomalies in a monitoring dashboard, but it should never be the control a network’s actual access decision rests on. That job belongs to 802.1X, covered in Part 8, precisely because it can’t be defeated by a one-line command.

USB device control at the OS level

Part 3’s entire argument rested on one fact: operating systems trust any USB keyboard unconditionally, independent of whatever the network layer is doing. Nothing in Parts 7 or 8 touches that vector at all, since a Bash Bunny in HID mode, a Rubber Ducky, or an O.MG Cable never asks the network for permission to type.

Closing that gap means controlling USB at the endpoint, not the switch port. On Windows, Group Policy can restrict USB storage class devices entirely, and Windows Defender Application Control can go further, allowlisting specific device classes or even specific hardware IDs rather than blocking storage wholesale. On Linux, udev rules can block newly connected HID devices outright, and USBGuard, a purpose-built framework for exactly this problem, allowlists devices by their USB descriptor, vendor ID, product ID, serial number, so a first-time-seen keyboard needs explicit approval before the kernel will accept input from it. macOS handles the equivalent through MDM configuration profiles restricting USB device classes.

None of this is airtight either. A device that spoofs a legitimate keyboard’s vendor and product ID can, in principle, get past an allowlist keyed purely on those values, the same spoofability problem MAC filtering has, just one layer down the stack. The realistic goal is raising the cost of the USB HID vector from “works instantly on any unlocked machine” to “needs the specific device identifiers of something already on the allowlist,” which is a meaningfully higher bar even though it isn’t an absolute one.

Wireless IDS: the one control this series’ own tools can’t talk their way past

Part 4 was explicit that Karma-style association attacks are far less reliable against a modern client than older write-ups suggest, thanks to randomized MAC addresses and the death of directed probe requests. Deauthentication was the one exception: a deauth frame targets a device already associated to a real access point by its real, currently connected MAC address, not a probe an attacker is trying to bait, so MAC randomization does nothing to stop it.

That’s exactly the pattern wireless IDS is built to catch. A WIDS baseline compares every BSSID actually seen on air against a list of authorized access points, flagging anything unrecognized as a potential rogue AP or evil twin. On top of that, volume-based detection watches for an abnormal rate of deauthentication or disassociation frames from a given source, the signature a Flipper Zero or bare ESP32 deauther leaves behind regardless of how carefully the rest of an engagement avoids detection. Cisco’s Catalyst wireless controllers and the 9800 series run this as aWIPS, Fortinet’s FortiAP fleet reports rogue AP and deauth activity back through the Security Fabric this site has covered extensively elsewhere, and Aruba’s equivalent runs through its own Mobility Conductor infrastructure. The specific product names change; the underlying logic, watching for BSSIDs and frame patterns that don’t belong, doesn’t.

Where this leaves the whole series

No single control covered across Parts 7 through 9 closes every vector from Parts 2 through 6 on its own, and that was never really the goal. Port security and DHCP snooping stop the wired dropbox from ever getting a foothold. 802.1X with a real NAC platform behind it answers the identity question MAC-based controls can’t. USB device control closes the HID vector network controls were never going to touch in the first place. Wireless IDS catches the one attack in this whole series that spoofing a MAC address never helped with to begin with. Layered together, each control closes a gap a different one leaves open, which is the entire argument for defense in depth over reaching for a single silver bullet.