实战教程：用Shell脚本监控内网ARP洪泛，并设置飞书/邮件自动告警(shell脚本登陆ftp)

老哥们，有没有碰到过这种怪事：
一大早到公司，发现内网慢得跟乌龟爬一样，连网关都 ping 不通了。第一反应肯定是查监控、看出口带宽，结果呢？一切正常，屁事没有。折腾了半天，最后才发现是内网里某个角落出了问题——有人在搞 ARP 洪泛攻击。

这玩意儿最坑的地方就在于，它属于那种“局部骚乱”，很多高大上的监控系统根本不把它当回事儿。在它们眼里，这都不算“异常流量”。尤其是在一些私有云或者KVM、ESXi这种虚拟化环境里，ARP 风暴简直就是潜伏在暗处的“网络杀手”。

那问题就来了，咱能不能用最简单、最接地气的方法，把这种 ARP 异常揪出来，然后第一时间收到通知？

必须能啊！今天我就带大伙儿用运维老鸟最爱的组合拳——Shell 脚本 + 飞书/邮件通知，搭一个轻量又好使的内网 ARP 洪泛监控。

为什么 ARP 洪泛这么隐蔽，却又这么致命？

动手之前，咱得先弄明白这玩意儿到底是咋回事，知己知彼嘛。

ARP 是什么？

说白了，ARP（Address Resolution Protocol）就是局域网里的“通讯录”。

• 你想找 IP 是 192.168.1.10 的哥们儿聊天。
• 你就在局域网里吼一嗓子（发个ARP请求）：“谁是 192.168.1.10？报上你的 MAC 地址！”
• 那位哥们儿听到了，就回你一句：“我就是，我的 MAC 地址是 XX:XX:XX:XX:XX:XX。”
• 然后你俩才能正式开始传数据。

ARP 洪泛怎么发生的？

正常情况下，ARP 请求是按需发生的，但“洪泛”就不一样了。通常是下面几种情况：

• 设备中毒或被黑：某个倒霉蛋设备被控制了，开始疯狂地在局域网里发 ARP 广播。
• 交换机抽风：硬件出 bug，自己在那儿搞 ARP 回环，把网络搞得一团糟。
• 虚拟化环境配置错误：我之前就踩过坑，KVM 里的 bridge 接口配错了，直接导致虚拟机之间 ARP 包满天飞。
• 最常见的“乌龙”：某个设备（比如新接入的电脑或打印机）的 DHCP 客户端有问题，不停地申请 IP 又拿不到，就在那儿循环发 ARP 广播。

这种 ARP 风暴的特点就是：

• 频率贼高，一秒钟几十上百个包，直接把交换机 CPU 干满。
• 监控装死，因为从表面看，网络是通的，没有明显的错误，但就是卡成狗。

所以，指望现成的工具是靠不住的，咱得自己动手，丰衣足食。

实现目标：三件事搞定

咱们的目标很简单，就三步，不整那些花里胡哨的：

1. 抓包：实时盯着网卡，数一数每秒有多少个 ARP 包。
2. 判断：定个规矩，比如每秒超过 100 个就算异常，触发告警。
3. 通知：马上通过飞书机器人或者邮件把消息发出来，让我们知道出事了。

第一步：监听 ARP 包的数量变化

要抓 ARP 包，`tcpdump` 这把瑞士军刀再合适不过了。直接上命令：

bash
tcpdump -i eth0 arp

但这玩意儿会一直刷屏，总不能让我 24 小时盯着吧？所以，得写个脚本来自动化这个过程。

示例代码：

bash
#!/bin/bash

# --- 配置区 ---
THRESHOLD=100  # 告警阈值，每秒ARP包超过这个数就报警，可以根据自己网络情况调整
INTERFACE="eth0" # 监听的网卡，记得改成你自己的，比如 ens33 之类的
LOG_FILE="/tmp/arp_monitor.log" # 日志文件，方便排查
SLEEP_INTERVAL=1 # 检查间隔，1秒一次

while true; do
    # 在1秒内抓取arp包并统计行数，这就是每秒的包数量
    COUNT=$(timeout $SLEEP_INTERVAL tcpdump -n -i $INTERFACE arp 2>/dev/null | wc -l)

    # 随手记个日志，好习惯
    echo "$(date): ARP count = $COUNT" >> $LOG_FILE

    # 如果包数量超过了阈值
    if [ $COUNT -gt $THRESHOLD ]; then
        echo "【警告】ARP包数量异常！当前: $COUNT, 阈值: $THRESHOLD"
        # 调用咱们的飞书通知脚本
        bash /opt/notify_feishu.sh "ARP洪泛预警：$COUNT 包/秒 @$(date '+%F %T')"
    fi
done

把这段代码保存成一个脚本，比如 `arp_monitor.sh`，然后 `nohup ./arp_monitor.sh &` 扔到后台运行，它就开始默默守护你的网络了。

第二步：配置飞书告警脚本

现在告警都流行用飞书、钉钉这类工具，比邮件快多了。飞书的机器人 Webhook 用起来特别简单。

获取飞书机器人 Webhook：

1. 随便找个飞书群，点右上角的设置。
2. 找到“群机器人”，点“添加机器人”。
3. 选择“自定义机器人”，随便起个名，然后你就能拿到一个 Webhook 链接了，复制它。

示例告警脚本 /opt/notify_feishu.sh：

bash
#!/bin/bash

# 告警消息从第一个参数$1传入
ALERT_MSG="$1"
# 把下面这串URL换成你自己的机器人Webhook
WEBHOOK_URL="https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxx"

# 用curl发个POST请求就完事了
curl -X POST -H "Content-Type: application/json" \
-d "{
    \"msg_type\": \"text\",
    \"content\": {
        \"text\": \"$ALERT_MSG\"
    }
}" $WEBHOOK_URL

别忘了给这个脚本加个执行权限：

bash
chmod +x /opt/notify_feishu.sh

这样一来，只要 ARP 数量超标，你的飞书群里就会立刻收到这样的消息：

css复制编辑ARP洪泛预警：183 条/秒 @2025-07-03 10:58:33

是不是比看一堆花里胡哨的监控图表来得直接多了？

第三步：配置邮件告警（可选）

如果你是邮件党，那也简单。先装个 `mailutils`：

bash
# Debian/Ubuntu
apt install -y mailutils

然后在主脚本里把飞书那行换成这个：

bash
echo "$ALERT_MSG" | mail -s "【紧急】ARP 洪泛预警" your@email.com

当然，你也可以两个都要，在脚本里都写上，双重保险。

🧪 验证：如何模拟一次 ARP 洪泛？

想看看脚本好不好使？可以在一台测试机上用 `arping` 来手动制造一场“人工风暴”：

bash
# 对着网关疯狂发arping
while true; do
    arping -c 1 -I eth0 192.168.1.1
done

**郑重警告：千万别在生产环境手贱！** 否则，你可能真的要被运维主管“请去喝茶”了。

🚨 告警防抖机制与日志轮转

说实话，如果网络真出问题，每秒都发一条告警，你的飞书能被刷到爆。所以，加个简单的“防抖”机制很有必要，比如一分钟内只告警一次。

在主脚本的告警判断那里，可以改成这样：

bash
LAST_ALERT_FILE="/tmp/last_alert_time"
NOW=$(date +%s)
# 读取上次告警时间，如果文件不存在就当是0
LAST=$(cat $LAST_ALERT_FILE 2>/dev/null || echo 0)

# 如果距离上次告警超过60秒
if (( NOW - LAST > 60 )); then
    # 调用告警脚本
    bash /opt/notify_feishu.sh "ARP洪泛预警：$COUNT 包/秒"
    # 更新告警时间
    echo $NOW > $LAST_ALERT_FILE
fi

另外，那个日志文件会一直变大，最好用 `logrotate` 配置一下，让它定期切割归档，免得把磁盘撑爆了。

📊 进阶玩法：可视化 + Grafana Dashboard？

如果你觉得纯文本告警不够酷炫，想搞个监控大盘装一下，那也可以。

• 把脚本统计的 `COUNT` 值，输出成 Prometheus 能识别的 metrics 格式。
• 用 Node Exporter 的 Textfile Collector 功能来采集这个自定义指标。
• 最后在 Grafana 里画个图，展示 ARP 包数量的实时趋势。

这么一套下来，你就能拥有：实时图表 + 飞书秒级告警 + 日志回溯，排查问题时逼格直接拉满。

🧠 为什么要自己写脚本，而不用现成的监控平台？

肯定有人会问：Zabbix、Prometheus 这些大家伙不香吗？为啥要返璞归真写脚本？

原因很简单：

• **术业有专攻**：大多数监控平台默认不关心 ARP 这种底层广播包。
• **部署灵活**：部署 Zabbix Agent 或者 Exporter 都是个事儿，而一个 Shell 脚本，5 分钟就能在任何一台 Linux 服务器上跑起来。
• **轻量高效**：为了抓个 ARP 包就上全家桶，有点杀鸡用牛刀了。一台闲置的 VPS，一段小脚本，就能搞定一个大问题，这才是性价比。

这就像一把“游击神器”，专门用来对付正规军（大型监控平台）的视野盲区。

结尾提一句（不是套路）

我一直觉得，一个好的运维或站长，手里既要有屠龙刀（大型平台），也得常备一把瑞士军刀（小脚本）。

ARP 洪泛这种问题，平时不起眼，一出事就要命。通过这种“小成本、高回报”的实战，我们就能轻松做到防患于未然。这比问题发生后，在老板的催促下焦头烂额地排查要从容得多。

下次再有人喊“网卡了！”，你就可以淡定地看一眼飞书，然后告诉他：“别慌，问题不大，我已经知道是谁在捣乱了。”