Wireless Intrusion Detection and Continuous Monitoring

WIDS/WIPS Architecture: Seeing the Air

Effective wireless monitoring is a physical problem first and a software problem second. A single sensor in the ceiling of a warehouse will miss directional attacks aimed at the loading dock, and a laptop running Kismet in promiscuous mode is not a substitute for distributed sensor placement. The architecture that works combines three layers: edge sensors for raw capture, local aggregators for deduplication and preliminary analysis, and a centralized correlation engine where temporal and spatial patterns become visible.

For sensor placement, think in terms of cell overlap rather than coverage. Each sensor should see 60–70% of its neighbors' range to enable triangulation and to eliminate single-point blind spots. In multi-floor buildings, vertical separation matters: 2.4 GHz penetrates concrete better than 5 GHz, so your 5 GHz sensor grid needs tighter spacing. Directional Yagi or panel antennas on select sensors can watch perimeter parking lots and outbuildings where attack staging occurs.

Centralized correlation is where stateless alerts become useful intelligence. A deauthentication frame on one sensor is noise; the same source MAC deauthenticating clients across three sensors in 90 seconds is an attack. Kismet's alert REST API and live packet export feed this pipeline, but the correlation logic is yours to build.

Kismet Drone Deployment and Real-Time Alerting

Kismet operates optimally in stationary, not mobile, deployments. Its passive collection mode detects hidden networks and non-beaconing infrastructure through data traffic analysis alone, but this requires sustained presence. The drone model separates capture from processing: lightweight sensors run kismet_cap_linux_wifi or equivalent remote capture binaries, streaming 802.11 frames to a central Kismet server over TCP.

Lab deployment — sensor node:

# On Raspberry Pi 4 or similar edge sensor with supported monitor-mode card
sudo apt install kismet-capture-linux-wifi

# Start remote capture pointing to central server at 192.0.2.10:3501
sudo kismet_cap_linux_wifi \
    --connect 192.0.2.10:3501 \
    --source wlan1:wlan1 \
    --env-monitor

What it does: Runs only the capture component, streaming parsed 802.11 metadata rather than raw pcap to reduce backhaul bandwidth. When to use it: Resource-constrained edge locations where full Kismet server operation is impractical. Risks: TCP backhaul over WiFi creates a meta-monitoring problem—use wired Ethernet for drone uplink where possible. Expected output: Central server logs remote source connection; frames appear tagged with source UUID.

Central server — alert threshold configuration:

Kismet defines two alert categories: stateless/stateful fingerprint-based alerts for known-hostile behaviors (wireless driver attacks, malformed frame sequences), and trend-based monitors for time-anomalous patterns like flooding and denial-of-service. Tune trend monitors in kismet.conf or via the web UI:

# Example alert tuning section
alert=DEAUTHFLOOD,20/sec,10/sec,300
alert=BCASTFLOOD,50/sec,30/sec,300
alert=BSSTIMECOUNT,5/min,3/min,600

The three numeric fields are: rate threshold, burst threshold, and minimum silence period (seconds) before re-alerting. These are site-specific; a conference venue with 5,000 clients will need radically different baselines than a manufacturing floor with fifty fixed IoT stations.

Signature-Based Detection: Rogue APs and Evil Twins

Rogue AP detection splits into two problems with different difficulty levels. Layer-2 rogue APs—unauthorized devices on your wired infrastructure or open APs bridged to your SSID—are relatively detectable through existing solutions. Kismet flags unconfigured BSSIDs, unexpected WPA2 Enterprise RADIUS fingerprints, or beacon intervals deviating from your deployed template. Layer-3 rogue APs protected by WEP or comparable security measures are significantly more challenging; the encryption boundary hides the BSSID-to-infrastructure mapping that simple beacon analysis relies on.

For evil twin detection, analyze beacon metadata beyond the SSID string:

Field	Normal Baseline	Evil Twin Indicator
BSSID	OUI matches vendor procurement records	Randomized or unregistered OUI
Channel	Assigned from planned spectrum	Unexpected channel (e.g., your channel 36 twin on channel 165)
Beacon interval	100 TUs (102.4 ms) typical	Deviations suggest manual configuration
RSN capabilities	Matches deployment standard	Bitmask differences in MFP, group cipher
Supported rates	Vendor-specific	Legacy 802.11b rates only (inexpensive hardware giveaway)

Kismet syslog normalization for SIEM ingestion:

Kismet supports syslog output for integration with SIEM platforms. Configure in kismet_logging.conf:

log_types=pcapng,kismet,alert
enable_syslog=true
syslog_facility=local4
syslog_host=192.0.2.50:514

Sample syslog format output:

<164>May 15 14:32:11 kismet-server kismet: ALERT ADVERSIONROGUE BSSID[aa:bb:cc:dd:ee:ff] SSID[CorpWiFi-Fake] frequency[5180] reason[Unconfigured BSSID with matching SSID to authorized network]

Parse at the SIEM with a simple grok pattern:

%{SYSLOGPRI:priority}%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host} kismet: ALERT %{WORD:alert_type} BSSID\[%{MAC:mac}\] SSID\[%{DATA:ssid}\] frequency\[%{NUMBER:freq}\] reason\[%{GREEDYDATA:reason}\]

What it does: Pushes structured alerts to your log aggregator in real time. When to use it: When Kibana, Graylog, or Splunk is your single pane of glass; eliminates API polling latency. Risks: UDP syslog can drop under flood conditions; consider TCP syslog or local rsyslog buffering. Expected output: Alerts appear as parsed fields in your SIEM, enabling dashboard correlation with wired-side events.

Behavioral Anomaly Detection

Client association patterns reveal compromise that signature detection misses. Track these metrics per client MAC over sliding windows:

Association roam velocity (AP changes per minute)
Probe request SSID entropy (sudden broad probing suggests reconnaissance)
Time-of-day deviation from historical baseline
Geolocation consistency (if your sensors have GPS or fixed position tags)

A client that historically associated with the third-floor engineering AP and now probes aggressively across all floors at 03:00 merits investigation regardless of whether its credentials are valid.

For geolocation, Kismet can record GPS coordinates per packet if the sensor has a fix. Correlate with inconsistency: a MAC seen simultaneously from sensors 500 meters apart is either spoofed or under active attack.

802.11 Frame Metadata for Forensic Timeline Reconstruction

Kismet's pcapng logs include per-frame Radiotap headers with signal strength, noise, channel, and rate. For forensic reconstruction after an incident:

# Extract all frames from suspected rogue AP within incident window
tshark -r incident.pcapng -Y "wlan.bssid == aa:bb:cc:dd:ee:ff" \
    -T fields -e frame.time_epoch -e radiotap.dbm_antsignal \
    -e wlan.fc.type_subtype -e wlan.seq

# Output sample (truncated):
# 1715784723.123456    -42    0x08    1234   # Beacon
# 1715784723.234567    -39    0x20    2847   # Data
# 1715784725.345678    -67    0x0c    2848   # Deauthentication (sudden signal drop)

The signal drop from -39 dBm to -67 dBm on the deauth frame suggests the attacker moved between capture and attack execution, or switched to lower transmit power—physical layer evidence you cannot derive from wired logs alone.

Integration with SIEM and Zeek/Spicy Pipeline

For environments already running Zeek (formerly Bro), the Spicy plugin enables custom 802.11 or IP-over-wireless protocol analyzers. The Zeek/Spicy integration exposes Spicy parsers to Zeek's processing pipeline, allowing you to write decoders for Kismet-exported metadata or raw Radiotap structures. This is development work, not configuration—expect to write Spicy grammar for your specific frame types of interest.

DPDK-accelerated capture, as documented in Suricata, provides libraries for high-throughput packet processing. While Suricata's DPDK documentation focuses on wired capture hardware optimization, the same principles apply to wireless monitoring at scale: kernel bypass, dedicated CPU cores, and hugepage memory allocation. For 802.11 specifically, this requires a DPDK-enabled wireless driver, which is less common than its wired equivalent; check current driver support for your NIC.

Physical Layer Evasion and Monitoring Compensation

Attackers evade WIDS through directional antennas, power control, and brief transmission windows. A high-gain panel antenna aimed at a specific client from a parking lot may not illuminate your ceiling-mounted sensor at all. Compensate with:

Technique	Monitoring Countermeasure
Directional transmission	Perimeter sensors with directional antennas pointed outward; sector coverage rather than omnidirectional
Power control (near-far problem)	Multiple low-height sensors in suspected attack corridors; signal strength triangulation
Short-duration attack (hit-and-run)	Continuous 24-hour pcapng ring buffer on all sensors; post-hoc retrieval, not real-time detection alone
Non-standard channels or 802.11ax 6 GHz	Sensor cards with full spectrum coverage; regulatory domain unlock where legal

The non-obvious truth: a WIDS that alerts only in real time fails against a patient attacker. The ring buffer is your insurance policy. Allocate storage for 72 hours of full pcapng at minimum; disk is cheaper than an undetected breach.

Common Mistakes in Wireless Monitoring

Mistake	Why it bites you
Using managed-mode client NICs for "monitoring"	You see only beacons and your own traffic; miss hidden networks and direct client-to-client attacks entirely
Alerting on every unexpected BSSID	Alert fatigue hides the real rogue AP; baseline your environment, then alert on deviations from that baseline
No GPS or position tagging on sensors	Cannot correlate signal strength with physical location; spatial analysis becomes impossible
Ignoring 2.4 GHz "legacy" band	Attackers target crowded 2.4 GHz for evil twins exactly because defenders have moved focus to 5/6 GHz
Relying solely on commercial WIPS without pcapng	Vendor black-box detection misses novel attacks; you need raw frames for custom analysis

Checklist: Production Monitoring Deployment

[ ] All sensors run confirmed monitor-mode capable cards with tested raw 802.11 capture
[ ] Sensor grid provides overlapping coverage with 60%+ mutual visibility
[ ] Central Kismet server has storage for 72-hour rolling pcapng per sensor
[ ] Alert thresholds calibrated against 7-day baseline of normal traffic
[ ] Syslog or REST API integration tested to SIEM with verified field parsing
[ ] Perimeter sensors include directional antennas for outward monitoring
[ ] Drone-to-central communication runs over out-of-band wired network
[ ] Incident response playbook includes frame metadata extraction procedures

⚠️ Authorized, defensive use only. Directional antenna placement, power analysis, and deauth detection techniques described here are intended for authorized network defense and lab validation of your own infrastructure. Wireless monitoring of networks you do not administer may violate local regulations; verify legal authority before sensor activation.