标签 arp 下的文章

大约几个星期前，lucky 因对原来主机提供商的服务质量不满，又将他和他夫人的博客重新搬回了我这里。不久后的一天深夜他打来电话，问我服务器是不是又受到 ARP 欺骗攻击了，每次打开他的主页都会跳出一个 0 * 0 大小的窗口。我赶紧排查了一下，发现服务器和机房都没有问题。

正在左思右想的时候，我回忆起之前我也曾遇见这样的现象，但并不是每打开一个网站就会跳出，其频率大约在一周一次。由于家里的线路是小区 LAN，属于 PPPoE 虚拟拨号的一种，电信分配的是动态 IP。如果长时间连接不断开，电信会每周一次主动断开网络连接，并再次连上，迫使客户端重新申请新的动态 IP。我似乎感觉自己有了头绪，于是马上登录路由器，手动重启路由器并重新获取新的 IP，然后再随便打开一个网址，现象重现了。

这个 0 * 0 大小的窗口，其实际 URL 是：

http://ad.thinkmedia.cn/htracker/pid=1060/media=dx.cn/place=qt/size=320x300 我试着打开 http://ad.thinkmedia.cn，看到页面代码如下：

<html>
<!--
<meta http-equiv="refresh" content="0; URL=http://www.jnjinteractive.com/kr/privacy/privacy.html">
-->
124.42.35.52 - imp1
</html> 于是又访问了一下：

http://www.jnjinteractive.com/cn/index.html 这是一家传媒公司，其业务介绍上居然堂而皇之的写着广告推送业务。看看他们的联系方式：

http://www.jnjinteractive.com/cn/contact/contact.html 这家公司貌似在韩国注册，而这个站点就是他们国内的公司：

http://www.thinkmedia.cn 通过 whois 查询看看两个域名的注册人：

http://whois.hichina.com/cgi-bin/whois?domain=thinkmedia.cn thinkmedia.cn 的注册人是北京思维美迪亚广告有限公司。

再看 jnjinteractive.com：

http://whois.hichina.com/cgi-bin/whois?domain=jnjinteractive.com 到这里，应该算真相大白了。这只是电信勾结广告商、传媒公司中众多赤裸裸的强奸案例中的一个罢了，我们无从知晓这其中的商业玄机，只是不愿被不明不白的强奸。更何况，这种强奸还披着合法的、合理的外衣。

最后，我想起 CB 上某编辑说的一句话：“众多电信运营商的沉默客户们，请擦亮您的双眼，维护您的合法权益”。

又是一个不眠之夜，写点东西好了。

上个月托管在某电信机房的服务器遭受了 ARP 欺骗，虽然不是我的服务器中毒，但还是受到了一定程度的影响。事后我认识到双向绑定的重要性，于是和机房联系做了双绑。

对于双向绑定，我的理解是在下级客户端与上级网关上分别知道自己与对方的 IP 及其 MAC 地址，并且这是一个静态的关系。ARP 协议中，默认的关系是 dynamic，而且这与使用 DHCP 与否没有关系。我们来做个实验：

C:\>arp -a
Interface: 192.168.0.201 --- 0x10003
  Internet Address      Physical Address      Type
  192.168.0.1           00-14-78-99-3d-a9     dynamic
  192.168.0.50          00-0b-2f-10-12-ab     dynamic
C:\>arp -d
C:\>arp -s 192.168.0.1 00-14-78-99-3d-a9
C:\>arp -a
Interface: 192.168.0.201 --- 0x10003
  Internet Address      Physical Address      Type
  192.168.0.1           00-14-78-99-3d-a9     static
  192.168.0.50          00-0b-2f-10-12-ab     dynamic 这个例子已经说明了问题。绑定后的状态一直都是 static，直到系统下次重启。

如果服务器处于双线机房，或者由于其他原因，具有一个以上的 IP 地址，其操作方式雷同。我的服务器上有两个 IP 地址，arp -a 后的结果是这样的：

C:\>arp -a
Interface: 60.12.104.24 --- 0x10003
  Internet Address      Physical Address      Type
  60.12.104.1           00-11-bb-3e-62-3f     dynamic
  122.225.96.1          00-11-bb-3e-62-3f     dynamic 我设计了以下的脚本。将它放入计划任务，并设置为每次系统启动时启动该脚本，配合机房在网关设备上对该服务器 IP 与其 MAC 地址的绑定，就可以使 Windows 操作系统的服务器具备防止 ARP 欺骗的能力：

@echo off
arp -d
arp -s 122.225.96.1 00-11-bb-3e-62-3f
arp -s 60.12.104.1 00-11-bb-3e-62-3f
exit 对于类 Unix 操作系统的操作也基本相似。首先通过 arp -a 获取当前信息：

#arp -a
? (60.12.104.1) at 00:11:bb:3e:62:3f on em0 [ethernet]
? (60.12.104.31) at 00:0e:0c:3c:7d:ba on em0 permanent [ethernet]
? (122.225.96.1) at 00:11:bb:3e:62:3f on em0 [ethernet]
nstech (122.225.96.31) at 00:0e:0c:3c:7d:ba on em0 permanent [ethernet] 然后执行单向绑定，注意类 Unix 系统下对 MAC 地址的书写方式：

#arp -s 122.225.96.1 00:11:bb:3e:62:3f
#arp -s 60.12.104.1 00:11:bb:3e:62:3f 服务器上操作完成后，要求机房在网关设备上对该服务器 IP 与其 MAC 地址的绑定，就实现了传说中的双向绑定。

如果服务器当前正在遭受 ARP 欺骗攻击，在机房没有对中毒服务器实施断网处理前，我们只能每隔一段时间就执行一下上面的操作。为了方便起见，我们可以这样做：

#vi /etc/ipmac 将需要做绑定的网关 IP 与其 MAC 地址写入这个文件。每行一个，中间用空格隔开：

122.225.96.1 00:11:bb:3e:62:3f
60.12.104.1 00:11:bb:3e:62:3f 然后：

#crontab -e 添加一行：

*/1 * * * * /usr/sbin/arp -f /etc/ipmac 这里的“*/1”代表每隔 1 分钟执行一次，可以根据实际情况调整。和平时期，我一般设置为 10 分钟执行一次：

* */6 * * * /usr/sbin/arp -f /etc/ipmac 战争时期就设置为 5 秒执行一次：

*/12 * * * * /usr/sbin/arp -f /etc/ipmac 对于 Windows 操作系统，只要重新设置一下计划任务的属性，让它每隔一段时间执行一下脚本就可以了。

咳咳，综上所述，这个解决方案是一个临时性解决方案，比较适用于非战时的防御。如果真的遭遇 ARP 欺骗攻击，第一件事还是通过 arp -a 找到源头，然后将信息报告给机房，让机房尽快将中毒的机器断网才是上策。

听说 FreeBSD 系统下面有一个软件叫做“ipguard”，可以有效防御 ARP 欺骗。有空研究一下。

一直以来，我以为 ARP 欺骗仅仅只会发生在公司单位、网吧等局域网环境比较复杂的地方。也曾耳闻到某些 IDC 机房也出过这样的事情，但总觉得这事情应该离我很遥远。没想到昨天晚上，一个地级市的电信机房也发生了这样的事情。我有幸亲临了整个事件的始终，中途除了机房的技术人员，还有二位仁兄被迫中止睡眠，起身与我一共奋战。一位是 feelinglucky 同学，另一位是我公司的小刘同学，在此向你们二位表示深切的慰问与诚挚的感谢。

昨天晚上 12 点 30 分（也就是今天零点三十分）左右，我打算进入博客后台取点资料，在登录页面上发现了惊奇的一幕：

刷新了一次之后还是这样，突然有一种不详的预感。然后，事实证明这种预感是准确的。我查看页面源代码，发现了更惊奇的一幕：

很明显，页面被挂马了。但又觉得这代码有点不对劲，于是冒着风险用 IE 访问了一下：

现在，发生了什么事情已经非常确定了。从最后一张图上看，应该是 ARP 欺骗挂马的结果；但也有可能是我的博客程序或者是服务器被挂马了。我一边打机房电话，告诉值班人员发生的事情；一边用 FTP 把博客所在目录的文件拖了下来。经过对博客程序的模板、程序代码的检查，发现并没有隐藏框架的代码存在。

下一步，检查服务器日志。把服务器上的 Apache 日志看了又看，没发现异常。根据 lucky 的建议，kill 掉了一些进程，问题依旧。lucky 又建议我测试一下本机访问本机会怎么样，于是：

#vi /etc/apache/httpd.conf 增加：

Listen 127.0.0.1:80 然后：

#/etc/rc.httpd restart
#vi /etc/hosts 增加：

127.0.0.1    www.xuchao.org 然后：

#cd /root
#wget https://www.xuchao.org/xxx/
#cat index.htm 在这里，我并没有发现有隐藏框架的代码存在。于是我更加坚定了刚才的判断，马上再次致电机房，告诉对方我刚才的测试过程，并指出问题极有可能出在机房里。值班的技术人员迷迷糊糊的从美梦中醒来，然后答应帮我检查。由于已经是后半夜了，他说最迟到上午 8 点就可以搞定。

等待、等待……在漫长的等待过程中，我重新查阅了一些几年没看的有关 ARP 欺骗的资料。唉，早知道就做双向绑定了。失误啊、失误。又看了一下 dmesg 日志：

#cat /var/log/dmesg.today 呵呵，全都是这样的内容：

arp: 122.225.96.1 moved from 00:19:b9:f1:14:1c to 00:11:bb:3e:62:3f on em0
arp: 122.225.96.1 moved from 00:11:bb:3e:62:3f to 00:19:b9:f1:14:1c on em0
arp: 122.225.96.1 moved from 00:19:b9:f1:14:1c to 00:11:bb:3e:62:3f on em0
arp: 122.225.96.1 moved from 00:11:bb:3e:62:3f to 00:19:b9:f1:14:1c on em0 从我一直 ping 服务器的情况看，机房的人重启了 3 次交换机，然后那段该死的隐藏框架代码已经不存在了。几分钟后机房给我打来电话，说问题已经解决。我问他原因，他说我的服务器所在机柜有一台服务器中毒，广播 ARP 欺骗包数据，没有防御能力的机器都倒下了。

由于连续 3 次断网，我们的服务器上服务端已经与数据库失去连接了（又是没有走内网通讯的恶果）。重启服务器，开启游戏服务端。早上 6 点，一切恢复正常。

明天整理一下思路，给出一份防御 ARP 欺骗的方案（针对 FreeBSD 服务器与 Windows 服务器）。