JavaEye无法访问与ARP攻击

很多JavaEye用户可能都发现了JavaEye网站出现了间歇性无法访问，或者页面出现乱码的问题，还有用户报告所谓的JavaEye网站被挂木马的报告，我们感觉非常有必要向用户及时解释事情的真相和来龙去脉。

要搞清楚这究竟是怎么回事，我们先要了解什么叫做“ARP欺骗”.
ARP是路由器维护的一个服务器网卡IP地址和网卡Mac地址的对照表，根据这个ARP对照表，路由器才能决定将外网请求过来的数据发给网段内的哪台服务器。但是ARP往往并不是路由器静态写死的（如果静态写死，那路由器管理员会累死），而是由服务器自己不停的把自己的ARP数据发送给路由器，通知路由器更新ARP对照表。因此ARP对照表的正确与否往往取决于服务器的自觉性。

说到这里大家就可以明白了，ARP机制有非常大的漏洞！如果有台叫做Fake的服务器心怀不轨，他想攻击JavaEye服务器，他就可以疯狂的向路由器发送更新ARP的通知，不停的告诉路由器，我才是JavaEye，我才是JavaEye，由于他发送欺骗性ARP数据包频率非常高，在路由器刷新 ARP对照表的瞬间，他抢在JavaEye服务器之前通知了路由器，那么他就得逞了。

从这个时候开始，凡是用户访问JavaEye的请求，路由器都会错误的发给fake服务器，而fake服务器会把请求路由给真正的JavaEye服务器，然后再添加上早已准备好的木马js，于是用户的浏览器接收到的网页就被挂马了！

这仅仅是一个最简单的ARP欺骗，实际的ARP攻击手段多种多样，但是最基本的解决ARP攻击的手段需要路由器具有足够好的安全性，正确的识别和拒绝异常的ARP数据欺骗包。但遗憾的是中国的IDC机房的网络安全性，中国IDC网管的技术水平都是惨不忍睹的！截止目前，中国IDC机房的网管们对付 ARP欺骗的唯一手段还仅仅只是在出现问题的时候，一个IP一个IP的拔网线的方式去排查fake服务器。

然而这还不是最糟糕的情况，最糟糕的情况是这个网段并不是属于某个服务器托管商的，而是分配给好几个不同的托管商。这些托管商都没有权限去登录整个网段的路由器。于是在v01托管商机柜里面的JavaEye服务器被fake服务器冒名顶替之后，v01托管商根本找不出来fake究竟在哪里，因为他没有权限去拔别人机柜的网线寻找fake服务器，他只能判断出来fake不在自己的机柜之内，要求别的托管商去自查。

这里就引出了第二个问题？为什么cracker对JavaEye的服务器这么敢兴趣？因为JavaEye服务器流量大用户多，可以最大化达到它控制木马的目的。

试想你是一个卑鄙龌龊的人，你想控制尽可能多的桌面电脑，盗QIE他们的帐号、密码和其他有价值的数据，那么你必须想办法给他们的桌面安装木马。要做到这一点，你就必须挑选一个访问量庞大用户多的网站挂马，这样用户访问这个网站的时候就会被下木马，否则你等于白费功夫。所以当JavaEye服务器所在的网段地址之内出现了某台存在安全缺陷的Windows服务器，这台Windows服务器就成了cracker的肉鸡了。

当然cracker并不是和JavaEye有宿怨，但是当它一旦控制了一台肉鸡，它想最大化的发挥肉鸡的作用，就肯定要逐个调查该网段的每台服务器，看看究竟哪台服务器流量大，那台流量最大的服务器就是它理想的冒名顶替的对象了。

这就是JavaEye服务器目前面临的问题！

首先这个问题并不是JavaEye服务器本身的问题，而是服务器所在的网段的网关被ARP攻击欺骗了，因此JavaEye服务器本身无论做什么工作都不解决问题。（当然JavaEye如果自己发起ARP攻击是可以自卫的，但是也有很大的风险被弱智的管理员发现以后拔掉网线，所以这种以 cracker对cracker的手段不解决根本的问题）

其次这个问题的解决依赖于路由器的安全性和网管们的技术素养，不过可叹的是，中国网络技术水平之低劣是令人发指的！以我这种对网络技术外行的人都可以去指点他们怎么做，你就不要对他们能够解决问题报任何希望。

更令人可耻的是他们的职业道德水平问题，当晚上再次出现ARP攻击的时候，该托管商技术人员说下班了已经回家，明天上班以后再给你解决！

经过和服务器托管商的多次协商，我们将采取如下解决方案：JavaEye网站的服务器，切换到另外一个比较安全的网段之内，避开这个已经被ARP攻击控制的网关。

由于切换服务器IP导致的DNS域名失效，特别是由于NS记录需要修改和刷新，JavaEye网站将无法访问，NS记录的刷新需要至少1小时时间，因此DNS的完全刷新大概需要1-2小时时间。

文章url：http://javapub.iteye.com/admin/blogs/733495