Kismet WIDS 部署实战：钓鱼AP与去认证攻击识别

作者

无线入侵检测（WIDS）解决的是加密加固解决不了的问题：WPA3 再强，也挡不住有人在楼下架一台同名钓鱼 AP，或用伪造的去认证帧把整层楼的人踢下线。本文用 Kismet 搭一套可长期运行的无线入侵检测，覆盖监听模式配置、告警规则编写、钓鱼 AP 与去认证洪泛的识别，以及告警落地成可检索日志的完整链路。测试网卡为 Atheros AR9271，系统 Debian 12。

适用场景

  • 办公区、门店、园区周边存在大量同名 SSID，怀疑有钓鱼 AP 诱导员工连接
  • 无线终端频繁掉线，怀疑遭受去认证或去关联洪泛攻击
  • 需要发现未授权的私接 AP 与随身 WiFi，补上资产台账的盲区
  • 需要为无线安全事件留下可追溯的射频侧证据链
  • 合规审计要求提供无线环境监测与告警记录

前置条件

  • Debian 12 或 Kali，内核 6.x，网卡支持监听模式（Atheros AR9271、RTL8812AU 均可）
  • Kismet 2023 及以上版本：apt install kismet
  • 一张不参与业务转发的独立无线网卡，避免监测影响现有 WiFi 连接
  • 合法授权范围：只监测自有场所的射频环境，不对第三方网络做任何注入类测试
  • 磁盘预留 20GB 以上，服务账户对 /var/log/kismet 有写权限

原理说明

WIDS 的检测能力来自 802.11 管理帧的被动监听。Beacon 与 Probe Response 携带 SSID、BSSID、加密套件与厂商信息；Deauthentication 与 Disassociation 是明文管理帧，攻击者伪造源 BSSID 即可把客户端踢下线。监测网卡进入监听模式后能看到同信道上的全部管理帧，无需关联任何 AP，因此不会被发现，也不产生业务流量。

Kismet 用数据源（datasource）抽象网卡，用 alert 机制把「同一 SSID 出现多个 BSSID」「加密方式突然从 WPA3 降为开放」「短时间内大量去认证帧」这类模式转成告警。规则写在 kismet_alerts.conf 中，阈值可调，这一步是把原始射频数据变成可运营信号的关键。

三类高频威胁各有特征。钓鱼 AP：SSID 与自有网络完全一致但 BSSID 与加密套件不同，常见开放认证配合强制门户。去认证洪泛：单位时间内 Deauth 帧数量远超正常漫游水平，且通常来自单一源。私接 AP：射频侧出现未登记 BSSID，其上游出口落在你的网段内。

被动监测的边界也要说清楚：它只提供发现与取证，不具备阻断能力。任何主动发送去认证帧做反制的做法都涉及无线电管理与网络安全法规，合规环境中不应采用，正确路径是把告警接到交换机端口定位与终端侧策略。

监测点覆盖同样影响检出率。射频是衰减很快的介质，一台网卡放在机房机柜里，根本看不到三层办公区的吊顶 AP。规划时按「每层至少一个监测点、位于 AP 覆盖边缘而非正下方」布置，边缘位置的信号差异最明显，最容易识别出功率异常的钓鱼 AP。多监测点还要解决时钟同步，否则同一事件在不同节点的时间戳无法对齐，取证链会断。

操作步骤

第一步：网卡进入监听模式并确定信道策略

ip link set wlan1 down
iw dev wlan1 set type monitor
ip link set wlan1 up
iw dev wlan1 info | grep type

# 双网卡方案：一张跳频，一张锁定业务信道
iw dev wlan2 set channel 6 HT20

锁信道能保证关键 SSID 的帧不丢，代价是看不到其它信道。单网卡场景保留 Kismet 默认跳频即可，双网卡才是生产部署的常态，一张负责全网扫描，一张盯住核心办公信道。

第二步：配置 Kismet 服务与数据源

cat > /etc/kismet/kismet_site.conf <<'EOF'
source=wlan1:name=mon0,channel_hop=true,hop_rate=5
source=wlan2:name=mon1,lock=6
log_types=kismet,pcapng
log_prefix=/var/log/kismet/wids
log_retention=30
server_port=2501
httpd_username=wids_admin
httpd_password=请替换为强口令
EOF

systemctl enable --now kismet
systemctl status kismet --no-pager | head -20

log_types 同时保留 pcapng，出事后可直接用 Wireshark 复核原始帧；log_retention 控制留存天数，无线日志增长很快，按天分卷并按需归档。

第三步：编写钓鱼 AP 与去认证告警规则

cat > /etc/kismet/kismet_alerts.conf <<'EOF'
# 同一 SSID 出现多个 BSSID：疑似钓鱼 AP
alert:SSIDMULTIBSSID,ssidmultibssid,300,{ssid="%s",bssid="%s"},5/min

# 短时间内大量去认证帧：疑似去认证洪泛
alert:DEAUTHFLOOD,deauthtype,300,{source="%s"},20/min

# 未登记 BSSID 出现：私接 AP
alert:ROGUEAP,dot11ssid,120,{ssid="%s",bssid="%s"},1/min
EOF

systemctl restart kismet

阈值不是固定值，办公区正常漫游本身就会产生去认证帧。建议先以观察模式跑 72 小时，把告警基线摸清后再收紧到 20/min 一类的可用阈值，否则第一天就会被误报淹没。

第四步：把告警接入集中日志

cat > /usr/local/bin/wids_tail.sh <<'EOF'
#!/bin/bash
tail -F /var/log/kismet/Kismet-*.alert 2>/dev/null | while read -r line; do
  ts=$(date '+%Y-%m-%d %H:%M:%S')
  echo "$ts $line" >> /var/log/wids-alert.log
  echo "$ts $line" | logger -t wids -p auth.warning
done
EOF
chmod +x /usr/local/bin/wids_tail.sh

cat > /etc/systemd/system/wids-tail.service <<'EOF'
[Unit]
Description=WIDS alert tailer
After=kismet.service

[Service]
ExecStart=/usr/local/bin/wids_tail.sh
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl enable --now wids-tail

接进 syslog 之后，rsyslog 或 Wazuh 都能直接做集中收敛与阈值升级，射频告警就并入了已有的运营流程，而不是躺在某台机器的本地目录里没人看。

第五步：建立自有 BSSID 白名单基线

# 导出已观测到的 BSSID，人工确认为自有资产后固化为基线
grep -ho 'bssid=[0-9a-fA-F:]*' /var/log/kismet/Kismet-*.kismet \
  | sort -u > /etc/kismet/known_bssid.txt
wc -l /etc/kismet/known_bssid.txt

# 告警过滤：命中基线的 BSSID 不再上报
grep -v -F -f /etc/kismet/known_bssid.txt /var/log/wids-alert.log > /var/log/wids-alert-new.log

先跑一周把自有 AP、访客网络、周边固定邻区的 BSSID 全部登记成基线，之后新增的 BSSID 才有研判价值。没有基线的 WIDS 只会报警，不会分辨。

配置验证

# 1. 数据源是否被正确识别
kismet_client -c localhost:2501 --list-datasources

# 2. 管理帧是否真的被采集
tcpdump -i wlan1 -e -c 20 'type mgt subtype deauth'

# 3. 告警是否产生并可检索
ls -lh /var/log/kismet/ | tail -5
grep -c "DEAUTHFLOOD" /var/log/wids-alert.log
journalctl -t wids --since "1 hour ago" | tail

验证要覆盖一次受控触发的全链路：在授权范围内用测试设备产生少量去认证帧，确认 pcapng 有记录、alert 文件有事件、集中日志有落地。三者缺一，说明链路某一段断了。

常见问题

Q1：网卡能进监听模式，但 Kismet 看不到任何 SSID？

先确认芯片是否被驱动真正支持监听，iw phy 输出里必须存在 monitor 接口类型；再检查 NetworkManager 是否在后台把网卡拉回托管状态，用 nmcli device set wlan1 managed no 解除。部分 USB 网卡在 5GHz 监听需要额外固件，缺固件时只会显示 2.4GHz 网络。

Q2：告警量大到无法处理，怎么降噪？

三条路径并用：把 SSIDMULTIBSSID 阈值从 5/min 提到 30/min 以上，过滤邻区同名；用 known_bssid 基线把已知 AP 排除；对 DEAUTHFLOOD 增加源 MAC 白名单，正常漫游集中在少数几个 AP。降噪目标是让每天需要人工复核的告警控制在十条以内。

Q3：WIDS 能直接阻断攻击吗？

被动监测本身不阻断。要阻断需具备主动注入能力，例如向攻击源发送去认证帧做反制，但这在国内受无线电管理与网络安全法规约束，合规环境不建议采用。正确做法是把告警接到交换机端口定位：发现钓鱼 AP 后通过物业或执法渠道处置，同时对内部终端下发禁止连接开放 SSID 的策略。

总结

WIDS 的价值不是抓包，而是把射频侧看不见的风险变成可复核的时间线。落地顺序建议是：网卡与数据源稳定 → 白名单基线跑一周 → 告警阈值按基线收紧 → 告警接入集中日志。四步做完，钓鱼 AP、去认证洪泛、私接 AP 三类问题都能从「用户反馈掉线」变成「几点几分、哪个 BSSID、持续多久」的确定性结论，无线侧的安全运营才真正开始。