13号早上跑到客户那边去，刚刚接上网络没多久，同事就发现公司的Internal服务器打不开了，打开首页只有一个大的IFrame，其它部分全部空白，卡巴弹出木马警报，该Frame指向http://aa.18dd.net下面的一个网址。心中一惊，难道Internal服务器被人攻破了？这台服务器和畅享网的服务器在同一个防火墙的后面，如果它出了问题，畅享网也危险。赶紧打开畅享网一看，似乎一切正常。还在暗自庆幸自己不是网管的时候，恶梦开始了。会员发现在畅享网发表文章的页面上会报病毒，发表文章编辑器打不开。但是这个时候在我的机器上是好的，而公司里面所有的编辑人员都打不开了，提示跟Internal同样的木马。我的瑞星没有警报，页面也能正常打开。跑到服务器上看看，客户端发现有病毒的那个文件并没有被修改，文件里也没有任何恶意的代码。

基于这个状况，开始怀疑是大家在用Internal的时候导致本机中毒，才会造成访问其它页面的时候出现这个问题，但是后来许多会员都开始反应有这个问题，而也有的会员没有问题，从后台来看，仍然有人在发表新文章。上网查了一下这个网址，似乎已经是普遍现象了，原来是最近很流行的ARP欺骗攻击。甚至在某个论坛上，某个网站说的很明白，如果你发现自己的网站被挂了这个木马，而在自己的服务器上又找不到病毒，那就不要瞎忙活了，这个病毒在别人的服务器上，赶紧打电话给机房吧。

多看了几篇ARP欺骗的原理，大致明白了一些，于是致电机房，说机房的某台服务器中了ARP病毒，正在影响我们的服务器，导致我们的页面显示有病毒。但是机房的人不承认，说自己并没有接收其它用户的投诉，也没有看到任何设备发出警报，请我们自己再检查检查。于是又回来开始排查服务器和防火墙的问题。在服务器上安装了ARP专杀，ARP防火墙，无果，即没有查检出病毒，也看不到任何ARP攻击的迹象。半天过去了，事情没有任何改观。IT那边折腾Internal的服务器也没有任何结果。直到下午回到公司，继续折腾，到了4点的时候，把机器重启了一下，发现一切突然正常了，Internal也正常了。又致电机房，对方说他们也没有做什么。因为是没有结果的好转，所以一直提心吊胆。

晚上在家里继续监视服务器，到了晚上9点的时候，病毒代码又一次出现，跟IT赶紧沟通。商量过后决定把Internal的服务器移到防火墙外面，于是打电话让机房的人帮忙弄，结果不知道哪里出了问题，双方沟通了一个小时这台机器接出来硬是连不上网。无奈，一切还原回去。当IT准备把Internal服务器切换到防火墙外面的另一台备用机上时，这才想起来在那台机器上安装一个ARP防火墙。结果装好以后马上就收到了ARP攻击的警告，拦截到了对方服务器的MAC地址。我终于长出一口气，打电话给机房的值班人员，告诉了他们中毒服务器的MAC地址，对方说会进行检查。于是告诉IT第二天早上去机房跟他们一起搞定那台机器，然后就睡觉了。

第二天早上来到公司，发现病毒代码还在，（这个病毒地址会发生变化），现在的病毒代码卡巴仍然会报警，却不影响编辑器窗口的显示了。再打电话去机房，对方居然说他们没有办法根据MAC地址找到机器，让我提供IP。我实在是气不打一处来，ARP欺骗会伪造假的IP地址，只有MAC地址是有效的，机房的交换机难道连查MAC地址的功能都没有，对方又说他没有权限操作机房的交换机，我说那你去找个有权限的人来吧，难道就这样让问题继续下去吗？对方仍然说我们没有接到其它用户的投诉……

再打电话给IT，他们居然没有去机房，还在远程把数据库往那台备用机上转移，似乎已经折腾了一个晚上，我真的是无语了。过了不久，机房来电话，看来是来了一个更高级的技术人员，说他已经知道了问题所在，正在排查，前面的那个人的确没有权限操作交换机。半小时以后，又来电话，说已经找到了那台机器，把它断网了，让我检查一下自己的网站。上网查看，病毒代码已经不存在了，问题解决。这时候，IT的备用机系统刚刚还原好启动起来，域名也被指向了这台机器……我告诉他们，你们现在可以切回来了……

总结：此次的问题机房要负全部责任，从昨天上午告诉他们ARP欺骗攻击到今天解决，已经过了24小时，中间的过程只是一味的搪塞，而不去核实并解决问题。中间走了太多弯路：ARP欺骗是在局域内进行数据包广播，我们自己的防火墙没有防ARP欺骗的功能，同时把这些广播的数据包挡在了外面，导致内部的两台机器上即使装了ARP防火墙也无能为力，看不到防火墙外面的攻击行为。同时，这次的ARP病毒只在htm网页和asp网页里面插入代码，畅享网的aspx页面不受影响。

原文出处：http://www.unfish.net/archives/224-20071114.html