Many home networks lack visibility into local wireless activity. Deauthentication attacks — which force devices to disconnect so their reassociation can be captured — often go unnoticed by consumer routers. Because Wazuh was already deployed as the homelab SIEM, the objective for this project was practical: forward meaningful WiFi IDS alerts into the existing security pipeline so that detection becomes part of an operational workflow rather than an overlooked dashboard.
The setup
A small single-board computer on the network was repurposed as a monitoring node running Kismet with a dedicated WiFi adapter in monitor mode. The node's role is purely detection: it listens for management frames and raises alerts when conditions match configured thresholds. Using a low-cost device keeps the monitoring footprint lightweight and easy to recover or replace.
Kismet alerts and DEAUTHFLOOD
Kismet includes an alert type for elevated rates of deauthentication frames (DEAUTHFLOOD). The alerting is rate-based per source to avoid firing on normal roaming or transient noise; the threshold is configurable so it can be matched against the expected behaviour of a given environment.
Forwarding alerts into Wazuh
Kismet exposes recent alerts through its web endpoint. A lightweight poller watches the alerts feed, deduplicates by alert timestamp, and forwards each new alert into the local syslog. The Wazuh agent collects syslog entries and the SIEM is therefore able to ingest, correlate, and act on wireless events alongside the rest of the environment.
Wazuh decoding and rules
To make Kismet alerts meaningful in Wazuh, a small custom decoder and rule were added to the local ruleset. The decoder matches the forwarded syslog tag and extracts the alert type and text; the rule fires on the DEAUTHFLOOD alert type and assigns an appropriate severity and description. This lets the SIEM treat those events like any other security telemetry and enables downstream actions such as notifications or ticketing.
Tuning and operational considerations
Wireless environments are noisy and what looks like an attack in one home may be normal behaviour in another. The DEAUTHFLOOD rate threshold should be verified against day-to-day baseline traffic and adjusted to avoid false positives. Additionally, deduplication in the poller and sensible rule levels in Wazuh help prevent alert storms. For production use, run the poller as a managed service and keep credentials in environment variables or a secrets store rather than hard-coding them.
Notifications and response
Alerts were routed through the existing mail relay so significant events produce an email notification. This ensures a human on-call or an incident response process sees the event rather than it remaining in an unattended dashboard. The mail path is intentionally simple so notification can reach responders quickly; more advanced integrations (webhooks, alert managers, or ticketing systems) are straightforward next steps.
Improvements and next steps
Polling the alerts feed is simple and reliable, but moving to an event-driven approach (for example, a persistent websocket subscription where supported) would reduce detection-to-notification latency and lower load. Longer term, correlating wireless alerts with other signals in the SIEM (DHCP logs, client posture, or network flows) can help place a deauth flood in context and reduce false positives.