作者:wiLdGoose
发布时间:May 15, 2008
分类:生活 Lifestyle
大约几个星期前,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 上某编辑说的一句话:“众多电信运营商的沉默客户们,请擦亮您的双眼,维护您的合法权益”。
作者:wiLdGoose
发布时间:April 26, 2008
分类:生活 Lifestyle
三明治和三文治都是英文单词 sandwich 的音译,属于著名而流行的典型西方快餐的一种。其历史悠久,发展至今,已经有火腿奶酪三明治、金枪鱼三明治等品种。关于 sandwich 这个名字的来历,可以参见这里和这里。
其实,一直对西方快餐文化嗤之以鼻,又以以肯德基、麦当劳为代表的垃圾食品为甚。就算是去了他们的餐厅,大都只要一杯百事可乐,实在饿得慌而又无法脱身去其他地方的时候才会多叫一个不甜不辣的汉堡。
曾有一次在从杭州飞往深圳的国航航班上领用早餐,分为中式与西式两种。中式早餐是一些糕点和饮料,而西式早餐就是火腿煎鸡蛋。对于火腿鸡蛋三明治的做法,我的理解是,用火腿煎了鸡蛋,夹在几片土司面包中就行了。火腿煎鸡蛋也可以称为鸡蛋煎火腿,其实谁煎谁都不重要,重要的是有没有土司面包。
那次之后,火腿煎鸡蛋给我留下了较为深刻的印象。回到杭州之后就想设法重现这道菜,苦于一直忙着忙着,居然渐渐淡忘了。前段时间突然想起,于是打算自己做一份火腿煎鸡蛋。
从超市买到袋装火腿肉,装盘待切:

阅读剩余部分...
作者:wiLdGoose
发布时间:February 9, 2008
分类:技术 Technology
春节是一个容易让大部分国人变得懒惰的节日。每天好吃好喝之后就犯困,要么睡大觉,要么 KTV、泡吧……总之就是应了一句话:“饱暖思淫欲”。在这样一个节日里,我也明显感受到了生活的无趣。我不是工作狂,但我一直坚信工作、生活密不可分,缺一不可。这几天彻底闲下来,直接导致我的反应能力下降;随之而来的是慵懒,懒得出门、懒得走路、懒得打电话拜年,甚至懒得吃饭、懒得睡觉。
为了避免大脑生锈,这里顺便分析一下“懒得出门”这样的短语,用 lucky 的话说就是“咬文嚼字”。“懒得出门”这个短语最容易产生歧义的地方就是这个“得”字,因为“得”有很多种意思。《南史·陶潜传》中有云“开郑有得,便欣然忘食。”这里的“得”作名词,有“收获、心得”之意。而《史记·项羽本纪》中“君为我呼入,吾得兄事之。”这里的“得”是副词,有“必须、应该”的意思。在某些语境中,“得”还通假“德”;如《荀子》中所述“尚得推贤不失序。”此外,“得”还可以作动词,解释成“得到、获得”。而这里的“得”用在形容词“懒”的后面,连接表示程度或结果的补语“出门”,基本上算一个连接助词。“懒得出门”与“红的发紫”表意不同,前者表示懒惰到不想出门,而不是懒惰到我出门了;后者表示很红,以致于快发紫了。
我终于意识到,在我写下如此知音的标题后,眼看前面又说了这么多废话,几乎快赶上标题党了。马上开始正文。
由于一直懒得出门,所以对于电信的催缴话费的电话通知也置若罔闻。今天白天在睡梦中被这样一个电话活生生吵醒,非常郁闷:眼看青蛙已经变成了王子,正要去吻沉睡的公主,就突然没了下文。不知道公主是苏醒了过来,还是突然变成了青蛙。为了避免以后再发生此类事情,我给 10 的 4 次方去了电话,咨询能否网上支付固话账单。对方的回复是这样的:“尊敬的中国电信用户,您咨询的缴费方式目前暂未开通。您可以选择去您当地就近的营业厅办理缴费或其他业务。给您带来不便,我们深表歉意。中国电信感谢您的理解、关心与支持,祝您新春愉快、万事如意。您若还有其他疑问,欢迎您随时致电中国电信客服一万号,我们将随时恭候您的垂询。再见。”我总结了一下,两个字:不行。
随后我在搜索引擎的结果中找到一个“中国电信网上客服中心”,然后又看到各地的分站。为了确认他的权威性,我找到这个域名的 whois 记录。不出意外的话,这是官方的“网上客服中心”了,不知道电信为何没有人去宣传,甚至有工作人员对此一无所知。
我根据页面上的提示,用电话号码注册了一个帐号,登录后开始寻找为固话交费的地方。在“自助服务”下面,我找到了“话费查询”,然后终于看到“缴费”字眼了:

点击“缴费”按钮居然来到另外一个 URL:http://www.114mall.cn/ctpay/。这让我感觉到一点发现新大陆似的好奇。初步测试了一下,这个地址不能直接访问,否则会提示“参数错误”。由于 URL 后面很干净,看样子数据是 POST 过去的。如果提交的数据正确,这时页面上会显示待缴电话账户的欠费情况。我把欠款结清之后再次看到这个页面,发现是这样的:

我回到“自助服务”,发现左侧栏目中有一项“充值缴费”,试着点击了一下:

填上自家电话号码,提交:

我想了一想,如果填写的是别人的电话号码呢?我试了一下,结果非常骇人:


看来中国电信的业务透明度实在已经达到了一个非常的境界,连自家公司的电话费用都可以查到,而且户主姓名也很精确:

对于小灵通也基本一样,但查询不到号码的户主姓名:

我隐约觉得,这个功能一定是中国电信所有业务中最好、最强大的一个业务。他似乎不仅能查全国(因为查询地区可以切换)的电信固定电话与小灵通账单,还能查到固话号码所对应的户主。简直就是免费的 114,堪比您的私家侦探。且该业务目前处于免费试用期,欢迎广大新老朋友试用:)
YY 广告了一把。
事后我发现在那个叫做“百事通商城”的网站上注册一个帐号,同样也能查询到上述信息:

登录后点击左侧“固话缴费”按钮可以查询到“各种”固话账单,点击“小灵通充值”按钮可以查询到“各种”小灵通余额或欠费信息:

固定电话查询:

小灵通查询:

于是,从现在开始起,我从心底里真心佩服中国电信;无论是他那优质的服务,还是他那无畏的胆量。根据我的主观分析,固话账单也好、小灵通余额也好,都是客户的隐私信息。每一个电信业务,都意味着中国电信以甲方身份与客户签有协约。所谓“言者无意、听者有心”,泄露客户资料对中电信这样的国家级企业来说一定无所谓;但对于最终用户来说,可能有时候就会造成很大的影响。而这一切祸水的来源,都是这个 114mall.cn 的网站。在好奇心的驱使下,我查看了这个域名的 whois 信息,结果又惊讶了一回……
作者:wiLdGoose
发布时间:February 1, 2008
分类:技术 Technology
又是一个不眠之夜,写点东西好了。
上个月托管在某电信机房的服务器遭受了 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 欺骗。有空研究一下。
作者:wiLdGoose
发布时间:January 24, 2008
分类:技术 Technology
一直以来,我以为 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 http://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 服务器)。
- 1
- 2
- »