ARP风暴需通过流量密度、行为模式和缓存一致性交叉验证；用tcpdump粗筛30秒ARP总量＞50且源IP/MAC集中，再查时间戳间隔是否毫秒级密集刷屏。
ARP风暴攻击不是“抓到一个包就能定性”的问题，而是要通过流量密度、行为模式和缓存一致性三方面交叉验证——单纯看包数量容易误判，比如DHCP重绑定或大规模主机上线也会触发短暂ARP激增。
怎么用 tcpdump 快速识别异常ARP密度
重点不是“抓全”，是“抓准节奏”：正常网络中ARP请求是零星、有响应间隔的；泛洪则表现为毫秒级密集刷屏，且源MAC固定或频繁切换。
- 先粗筛30秒内ARP总量：
sudo tcpdump -i eth0 -c 30 arp，若 >50 包（尤其集中在同一源 IP/MAC），需警惕 - 观察时间戳间隔：
sudo tcpdump -i eth0 -n -q arp | head -20，注意输出里每行开头的时间差——连续多条间隔 - 过滤只看 ARP 请求（opcode 1）：
sudo tcpdump -i eth0 -e -n -vv arp and 'arp[6:2] == 1'，-e 显示 MAC 层，-vv 输出操作码，避免把响应包误当请求
如何定位伪造请求或冒充网关的源设备
ARP风暴常伴随欺骗行为，比如对非本网段IP发请求，或非网关设备反复宣称自己是网关。这类包在Wireshark里一眼可见，但命令行更高效。
- 查目标是否异常：
sudo tcpdump -i eth0 -n arp | grep "who-has" | head -10，看目标 IP 是否大量出现 8.8.8.8、100.x.x.x 等非本子网地址 - 抓冒充网关的响应（以 192.168.1.1 为例）：
sudo tcpdump -i eth0 -e -n arp and 'arp[6:2] == 2' and 'arp[24:4] == 0xc0a80101'，如果响应源 MAC 不是已知网关 MAC，就是伪造 - 检查广播请求是否来自可疑 MAC：
sudo tcpdump -i eth0 -e -n arp and dst host ff:ff:ff:ff:ff:ff | head -10，结合arp -n对比网关 MAC 是否一致
为什么不能只靠 arp -a 或清空缓存来排查
arp -a 只显示当前缓存状态，而风暴期间缓存可能被快速覆盖或卡在 FAILED / STALE 状态，掩盖真实攻击源；盲目执行 arp -d * 会引发新一轮ARP请求洪流，反而加剧拥塞。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 应改用更底层的
ip neigh查看真实状态：ip neigh show nud failed,nud stale，失败条目多说明存在持续无法解析的 IP，可能是攻击者伪造的目标 - 若发现同一 IP 对应多个不同 MAC：
ip neigh show | grep "192.168.1.1"，说明缓存已被污染，此时应配合抓包确认哪个 MAC 是伪造的 - 清理必须精准：
sudo ip neigh del 192.168.1.1 dev eth0比清空全部安全；sudo ip neigh flush nud failed只清失效项，不影响正常通信
怎么确认是不是真有设备在发包，而不是内核或驱动故障
有些网卡驱动 bug 或 NIC 固件异常会导致内核不断重发ARP请求（比如 link flap 后未正确收敛），看起来像风暴，但实际没有外部攻击源。
- 先排除物理层：
ethtool eth0看 link 状态是否稳定，dmesg | grep -i "eth0\|arp"查内核是否有相关报错 - 对比交换机侧 MAC 表：
show mac address-table interface GigabitEthernet0/1（Cisco）或display mac-address dynamic（华为），看风暴源 MAC 是否真实绑定到某个端口 - 临时断开该端口，再运行
sudo tcpdump -i eth0 arp -c 20—— 如果包数骤降，基本锁定物理设备；如果仍高频出现，可能是本机网卡或内核问题
真正难处理的不是识别风暴，而是区分它是恶意泛洪、配置错误（如双网关ARP通告）、还是硬件异常。建议抓包时同步记录 ip neigh show 和 cat /proc/net/arp 输出，三者时间戳对齐后比对，才能避开“看到包就删MAC”的惯性操作。
