今天刚到办公室就有楼上多个科室的人过来反映网络上不去，问了几个人，也证实了Ping服务器失败。看来跟我机子上的问题一样。奇怪的是我的机子已经绑定了服务器的IP和MAC地址，居然也是Ping不通。到服务器上一查，Arp映射表里很多IP地址和MAC地址的对应是错误的，其中也包括我的机子。显然又是某台机器染毒导致的arp攻击，把机子的mac地址做一下双向绑定应该可以解决这个问题。
Arp -s我的机子后我可以正常上网了，但是其它人的机子怎么办，总不能把所有机子地址都逐条都绑定进去(谁来干这个？)，更不能在网内留下这个隐患。所有的网卡都错误映射至地址B，这是昨天那位同事的网卡物理地址。查找了些相关资料，出现IP/MAC映射错误一般是接收到了未经请求的ARP响应包，刷新了自己的ARP缓存。当然这些响应包是被伪造的。用Windump查看arp协议相关的数据包，发现不停的有Arp reply出现，IP各不相同，MAC地址则都是错误的地址B。这中间有两个问题，一是在正常情况下，Arp缓存会有一定老化时间，不会如此频繁的发出请求的。第二，Arp响应非常多，然而Arp请求却寥寥无已。Arp请求也是在网内广播的，两种包的数量正常性况下不可能相差这么悬殊。在服务器上用Arp -d删除缓存后，会发现很快的列表再次被错误的IP/MAC映射填充，由此看来，某台机子有木马程序不停的向网内机子发送伪造的ARP请求是确定的了。但是如何查出这台机子的IP地址呢？ARP响应中并没有提供源地址，即使有也可能是被伪造的。一时间没有什么办法。
幸好没那么不走运。虽然不能肯定MAC映射到B就一定能证明是B机子发送的虚假响应包，然而如果要排除的话，当然要从B机子先开始。于是打电话让这位同事拔掉网线，立刻看到在我这边Windump窗口不断刷出的Arp响应包马上消失了。然后又在服务器上用Arp -d清除Arp缓存，然后再刷新，发现慢慢刷出来的地址表都映射到了各自IP的真实MAC地址。刷新多次后没有变化，看来是服务器没有再收到虚假Arp响应的缘故。现在基本可以肯定是同事B的机子上的木马作的怪。最后在他的办公室里确定了这一点。B旁边一台机子上ping服务器正常。然后插上B的网线，Ping的响应立刻超时了。铁证如山啊。
事后的心得：
Windows收到Arp响应后立刻刷新自己的Arp映射表，并不判断自己是否发出了Arp请求，也无从判定响应包的真实性。据说Linux内核2.4以上的能够对自己是否发出了请求进行判断，也许会安全一些。用静态绑定Arp表的方法可以解决问题，但在一个较大的局域网内工作量显然是不小，而且也没有解决木马问题。Windows用Arp -s绑定，但2000以前的一些版本即使用了-S参数仍会在收到响应包后刷新。我的机子和服务器都是2003，静态绑定是有效的。Linux下编辑某文件可以静态绑定Arp表，这比Windows更为方便，因为是可以持久保存在机子上的。还学到个Windows任务管理器的命令行版本:tasklist，杀进程用Taskkill。以前可从未注意过。当时发现问题后在B机子上查看了一下进程，一眼瞅到个大大的SVOHOST.EXE，不用说就是个木马或病毒。没再仔细看下去，究竟是这东西惹的祸还是另有罪魁让同事B搞定吧。
Linux下静态绑定Arp表的方法：
建立/etc/ethers文件，其中包含正确的IP/MAC对应关系，格式如下： 192.168.2.32 08:00:4E:B0:24:47
然后在/etc/rc.d/rc.local最后添加arp -f 生效即可
原创文章，作者：苏葳，如需转载，请注明出处：https://www.swmemo.com/167.html
