Defences — Index
Defences
No single mitigation stops every AirSnitch attack. The paper is explicit about this (NDSS’26 §VIII, README §6): you need a combination. This page is a defence-vs-attack matrix and an index into the per-defence pages.
Matrix
✓ = stops the attack. ◐ = partial / configuration-dependent. ✗ = does not stop.
| Defence | Abusing GTK | Gateway Bouncing | Port Stealing | Broadcast Reflection | Machine-on-the-side | Rogue AP | Passpoint flaws | ARP over GTK |
|---|---|---|---|---|---|---|---|---|
| Group key randomization (every handshake + IGTK) | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ |
| VLANs / firewall | ◐ (cross-VLAN only) | ✓ | ✓ | ✓ | ✗ | ✗ | ◐ | ◐ (cross-VLAN only) |
| MAC spoofing prevention | ✗ | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ |
| IP spoofing prevention | ✗ | ◐ (return path) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Filter unicast IP in L2 broadcast | ◐ (IPv4 only) | ✗ | ✗ | ◐ (IPv4 only) | ✗ | ✗ | ◐ | ✗ (ARP, not IP) |
| MACsec | ✓ | ✓ | ✓ | ✓ | ✓ | ◐ | ✓ | ◐ (impact only) |
| Centralised decryption | ◐ | ✓ | ◐ | ✓ | ✗ | ✗ | ◐ | ◐ |
| Move off shared passphrase (PPSK / Enterprise / WPA3-PK) | ✗ | ✗ | ✗ | ✗ | ✓ | ◐ | ✗ | ✗ |
| Reject duplicate MAC across BSSIDs | ✗ | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Dynamic ARP Inspection / bridge-side ARP filter | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ (frame off the bridge) |
Endpoint ARP hardening (arp_accept=0 + populated cache, static entries) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ◐ (only if cache populated) |
| AP Proxy ARP / Hotspot 2.0 DGAF Disable | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ |
| Documentation / warnings | indirect | indirect | indirect | indirect | indirect | indirect | indirect | indirect |
Recommended baseline
(Synthesised from NDSS’26 §VIII-C and README §6.)
If you operate a Wi-Fi network and you actually care about isolation between clients:
- Don’t run WPA2-PSK with shared passphrase if you care about isolation between users. Shared-password isolation is “fundamentally flawed” (NDSS’26 §IV-A header). Move to WPA3-SAE at minimum, ideally Enterprise or PPSK.
- Put guest networks in their own VLAN with firewall rules that prevent guest→main and (if your threat model demands it) guest→guest IP forwarding. (VLANs.)
- Enable per-client randomized GTK if your AP supports it — and test that the randomization extends to the group-key handshake, FT, FILS, and WNM-Sleep, not just the 4-way.
- Enable IGTK randomization if your AP follows Passpoint v3.4 or has a vendor option.
- Enable MAC spoofing prevention — at minimum, refuse a Wi-Fi association with a MAC already used by an internal wired device (gateway, DNS, RADIUS server). Bonus: refuse duplicate MAC across BSSIDs.
- Set the OS sysctl
drop_unicast_in_l2_multicast=1on Linux clients. Doesn’t stop the attack class, but at least IPv4 group-ping injection is blocked. - Document what your client-isolation setting actually does. In a real deployment guide, with concrete answers to: “are guests allowed to talk to each other?”, “are they allowed to talk to the main network?”, “are wired devices isolated?”. See documentation.
When budget allows
- MACsec end-to-end between Wi-Fi clients and the gateway. The only single defence that stops every AirSnitch primary attack. See MACsec.
- Centralised Wi-Fi decryption at a controller, taking the decryption boundary off the AP-local bridge. Cisco enterprise gear can do this; the AirSnitch authors found it makes attacks harder (NDSS’26 §VIII-C).
Per-defence pages
- Group key randomization
- VLANs and firewall
- MAC and IP spoofing prevention
- Filter unicast IP in L2 broadcast
- MACsec
- Centralised Wi-Fi decryption
- Documentation and warnings
- Dynamic ARP Inspection and bridge-side ARP defences — DAI, DHCP-snooping ARP filter, ebtables on
br-lan. Catches wired and bridge-side wireless ARP poisoners; does not stop ARP over GTK. - Endpoint ARP hardening —
arp_accept, static ARP entries, per-host hygiene against ARP spoofing.
See also
- Overview
- Tested devices — which products the AirSnitch team tested and which defences each ships with.