那天凌晨两点，我的值班微信突然连续响起。运维监控报警显示香港机房局域网多个节点延迟飙升，部分服务器间互相丢包。最初我以为是交换机老化或链路端口故障，但在排查链路健康状态后依然毫无头绪。直到我尝试ping网关地址时发现响应延迟异常，并结合抓包分析才确认，我们遭遇了一次ARP欺骗攻击。局域网被篡改的ARP响应扰乱了正常路由，导致整个网络通信异常。
这是我第一次在香港自营机房中处理ARP攻击问题。过去面对外部DDoS、Web攻击我们有完善的防御机制，但像这种来自内网的ARP欺骗却没有预设防护方案。本文将完整记录我如何通过配置静态ARP表与部署ARP防护工具恢复网络稳定，并彻底封堵类似风险。
一、香港服务器与网络基础环境概况
- 服务器位置： 香港沙田机房（BGP多线）
- 操作系统版本： CentOS 7.9 / Ubuntu 20.04
- 服务器型号： Dell PowerEdge R740
- 网卡型号： Intel X550 10GbE
- 核心业务部署： Web服务节点、数据库后端、Redis缓存等
- 局域网架构： 二层平面架构，交换机无VLAN隔离
- 路由器与网关设备： Cisco ISR 4331
二、问题现象与初步排查
ARP欺骗的影响通常体现在局域网通信异常。以下是当时发现的问题症状：
局部节点到默认网关响应时间 > 500ms，偶尔丢包
Redis主从同步中断
通过ping测试发现多个MAC地址在不同IP中跳变
使用以下命令抓取ARP响应进行分析：
tcpdump -i eth0 arp
结果显示，大量来自非网关设备的ARP Reply 报文，以伪造的MAC地址映射多个关键IP，说明已有ARP欺骗发生。
三、实施方案与技术实现
为稳定局域网环境并阻止ARP欺骗攻击，我采取了两项核心手段：
1. 配置静态ARP表（永久绑定IP-MAC）
在关键服务器上配置静态ARP条目，避免通过ARP动态学习被伪造响应污染。
以CentOS为例，在 /etc/rc.d/rc.local 添加如下配置：
arp -s 192.168.1.1 00:11:22:33:44:55
arp -s 192.168.1.254 00:11:22:aa:bb:cc
注意：静态绑定必须确保设备MAC地址不变，建议集中管理服务器MAC地址清单。
配置永久后执行：
chmod +x /etc/rc.d/rc.local
systemctl enable rc-local
2. 使用ARP防护工具（arptables + arpwatch）
arptables：基于ARP的防火墙规则工具
安装：
yum install arptables
设置只允许合法MAC访问默认网关：
arptables -A INPUT --source-mac ! 00:11:22:aa:bb:cc -j DROP
也可以限制ARP请求或响应来源：
arptables -A INPUT -d 192.168.1.254 --source-mac ! 00:11:22:aa:bb:cc -j DROP
保存规则：
arptables-save > /etc/arptables.rules
开机自启可写入 /etc/rc.local 中加载规则：
arptables-restore < /etc/arptables.rules
arpwatch：ARP活动监控与告警
安装并配置：
yum install arpwatch
systemctl enable arpwatch
systemctl start arpwatch
日志文件位于 /var/log/messages，可集成ELK或Zabbix进行告警输出，发现新MAC异常变化即刻上报。
- 四、补充防御建议与网络结构优化
- 交换机层级优化： 使用支持动态ARP检测（DAI）功能的三层交换机，如H3C S5130
- 局域网划分： 将管理网络与业务网络物理隔离，关键设备使用管理VLAN
- 主动ARP检测脚本： 自研定时脚本，每5分钟检测ARP表变化并对比历史值报警
- 云防火墙配合： 对接高防节点对公网访问过滤伪造ARP源流量
五、恢复效果与数据验证
部署ARP防护方案后，我持续监测了一周，网络稳定性大幅提升。
这次ARP攻击暴露出我们内部局域网结构的设计缺陷，也让我深刻意识到：内网安全同样重要，特别是二层协议攻击往往被忽视。通过静态ARP表与ARP防护工具的组合使用，不仅让网络恢复正常运行，也为之后的网络架构改造提供了明确的方向。
如果你和我一样在香港运营自营服务器，建议尽早规划好ARP安全机制，把风险消灭在萌芽状态。
