Apple想干嘛？

28 Nov 2008 Author: 吴洪声 In: 生活

作为一个标准果粉，我很难明白苹果此举。相信又有一伙FQ要出来骂娘了。

l_b9f6493362128c9bd9a88efbd6747d1c.png

母亲

24 Nov 2008 Author: 吴洪声 In: 影像

DNSPod 开放 API 接口完成

23 Nov 2008 Author: 吴洪声 In: IT

周末又宅了两天在家里，宅出了成绩：完成了DNSPod的几个开放API接口

目前一共有7个公开API和1个私有的API，基本能满足大部分需求。数据返回支持XML和JSON

7个公开的API：

Domain.Create

Domain.List

Domain.Remove

Record.Create

Record.List

Record.Modify

Record.Remove

1个私有的API：

User.Create

现在API已经上线，具体的文档将会整理后发出来DNSPod API 列表。

目前使用API不收费。

2008年年终盘点

23 Nov 2008 Author: 吴洪声 In: 生活

年终盘点是来北京后的好习惯，像我这样浑浑噩噩过日子的人，只有这么一个途径能量化一年下来的所作所为，能看到自己的进步，不足。

2006年的盘点在这里，2007年盘点在这里。我发现自己连制订人生目标都偷懒了，2008年没给自己留下任何明确的目标。这是因为2007年完成了大部分目标所致，以至于自己在08年浪费了大好时光。决定自己09年不能再这样下去了。

先回顾08年所定下的两个目标

1.还清家里的房贷

春节回家的时候完成了。在春节假期开始前的最后一刻把房产证拿到手，过了一个无忧无虑的春节。还清贷款耗时三年，自己实际在新房子里面住的时间不到一年。买房子的时候自己还在读中专做网站，买房子的理由无非是想让父母住的舒服点，顺便在亲戚朋友和同学面前炫耀自己的能力。房子装修好后爱上了祖国的大好河山，开始自己在祖国大陆浪迹的过程，享受着漂泊的生活。每次回家都觉得很陌生，睡觉也不踏实，一度让我产生住回老平房的想法。带着继续在一年四季抽井水洗澡的想法回到老房子后反而无法接受老房子的破旧和霉味。原来我已经迷失在繁华都市的迁徙中。

中专时除了买房，还有一个幼稚的想法：赚钱买车，开回学校参加毕业典礼，让那些笑我的人笑不出来，让前女友后悔不要我。最后结果是毕业后一年自己才弄到属于自己的车，毕业典礼也因为没收到通知而没回去。后来看同学发来的毕业照，前女友也不在。ridiculous。

2.如果各方面的条件合适，购买第二套房。

今年房地产不景气，不敢下手也没法下手。承受不起第二套房贷的高首付和高利率。也因为如此，让我的银行存款能在这个寒冬里有6位数的余额。感谢。

08年其实还做了不少事情，值得记录的

1.若干年前，一个小男孩对他的初恋女友说，08年我一定会去北京找你，陪你一起看奥运。开幕式的转播上，长大后的小男孩迟迟没有按下手机短信的发送键。奥运完了，小男孩对女孩说起当初的约定，女孩一脸茫然。是啊，早该忘了，还惦记着干嘛呢。

2.为了有更加大的发展，离开了自己帮着带大的公司。很高兴自己离开后公司继续发展壮大并且开了分公司。原来自己并不是不可或缺的一个。

3.加入了MySpace China。好歹算是外企。感谢土人大叔提供的机会。但自己做的的确让他失望，非常失望。

4.出了躺国，护照的第一次给了日本，一个做梦也想去的地方。印象中的日本遍地女优和援交，为此还曾经去学过日语。去了才发现遍地女优不假，但都是巨幅的广告。援交也不假，但出口就是东北腔，感情都是中国人那。

5.英语水平有所提高。发现那些大学四级出来的说起英语来还没我初中水平好。应试教育的问题，大家心里都明白。

6.在北大给北大的学生开了一堂讲座。

展望下2009年：

1.DNSPod商业化，推出VIP服务

2.月入3万（在这寒冷的冬天，不敢定太高）

3.自驾游中国

4.在公司里面做一些成功的事情

5.情况合适的话，重新考虑买房

6.

上面的内容写得真不容易，足足写了3天。最近状态不好，老觉得心里有什么卡住。我这人得老年痴呆症是迟早的事情。

网通用户访问VeryCD等P2P网站被劫持的分析和解决方案

8 Nov 2008 Author: 吴洪声 In: IT

今天总算闲了下来，随手把前几天VeryCD被劫持的一些分析记录和解决方法整理出来。相信这份资料对个人站长来说非常有参考价值。

顺便推荐一下Caoz写的一篇文章，希望大家都能了解做网站背后的辛酸：由做站长的艰辛说起

====
话说VeryCD等网站被劫持的第二天，劫持还在继续。我闲着无聊在QQ群里胡扯，被Dash和xdanger逮到。正好我非常荣幸的是北京网通用户，这个伟大的任务就只能交给我了。

先用正常方式访问一下VeryCD，得到下面的结果

Sam@Bogon:~$ curl -v -H www.verycd.com
* About to connect() to x.x.x.x port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to x.x.x.x (x.x.x.x) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.verycd.com
> 
< HTTP/1.1 200 OK
< Content-Type: text/html;charset=gb2312
< Content-Length:182
< 
<html><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"><title>warn</title></head><frameset cols="100"><frame src="http://www.baidu.com"/></frameset></html>
* Connection #0 to host x.x.x.x left intact
* Closing connection #0
Sam@Bogon:~$

可以发现返回的结果直接被劫持并替换。并不像一般的挂马等行为是在网页内容的最前或者最后部分插入劫持代码。

之后直接输入VeryCD的IP，返回的结果是VeryCD的squid服务器默认页面，说明IP并没有成为劫持的判断标准。应该是VeryCD的域名或者网页中某个特征导致劫持设备对内容进行替换。（此处省略结果）

既然域名是判断的标准之一，那么就可以尝试替换HTTP协议中Host的办法来测试

(1)
Sam@Bogon:~$ curl -v -H 'Host: www.veryc.com' www.verycd.com
* About to connect() to www.verycd.com port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to www.verycd.com (x.x.x.x) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.veryc.com
> 
< HTTP/1.1 200 OK
(略)
 
(2)
Sam@Bogon:~$ curl -v -H 'Host: verycd.com' www.verycd.com
* About to connect() to www.verycd.com port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to www.verycd.com (x.x.x.x) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: verycd.com
> 
< HTTP/1.1 200 OK
< Content-Type: text/html;charset=gb2312
< Content-Length:182
< 
<html><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"><title>warn</title></head><frameset cols="100"><frame src="http://www.baidu.com"/></frameset></html>
* Connection #0 to host www.verycd.com left intact
* Closing connection #0
Sam@Bogon:~$ 
 
(3)
Sam@Bogon:~$ curl -v -H 'Host: www.veryc.com' www.verycd.com/verycd.com
* About to connect() to www.verycd.com port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to www.verycd.com (x.x.x.x) port 80 (#0)
> GET /verycd.com HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.veryc.com
> 
< HTTP/1.1 200 OK
(略)
 
(3)
Sam@Bogon:~$ curl -v -H 'Host: w.verycd.com' www.verycd.com
* About to connect() to www.verycd.com port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to www.verycd.com (x.x.x.x) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: w.verycd.com
> 
< HTTP/1.1 200 OK
(略)

例子中，分别用了4种测试方法
1为发送一个主机头为www.veryc.com的请求到verycd的服务器，可以看到数据正常返回，没有被劫持
2为发送了一个主机头为verycd.com的请求到verycd的服务器，可以看到数据被劫持了
3为发送了一个主机头为www.veryc.com，使用GET方式获取/verycd.com文件的请求到verycd的服务器，可以看到数据正常返回，没有被劫持
4为发送一个主机头为w.verycd.com的请求到verycd的服务器，可以发现数据没有被劫持

通过上面的结论可以看出，用于劫持的设备只对域名的host部分做判断。

我们再来一个有趣的测试：如果把host发送到网通的bbn.com.cn去会怎样呢？

Sam@Bogon:~$ curl -v -H "Host: www.vercd.com" www.bbn.com.cn
* About to connect() to www.bbn.com.cn port 80 (#0)
*   Trying 202.106.195.131... connected
* Connected to www.bbn.com.cn (202.106.195.131) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.vercd.com
> 
< HTTP/1.1 200 OK
< Date: Sat, 08 Nov 2008 13:33:06 GMT
< Server: Apache/2.0.59 (Unix) DAV/2
< Last-Modified: Thu, 06 Nov 2008 07:21:36 GMT
< ETag: "73c63-119c6-259cc000"
< Accept-Ranges: bytes
< Content-Length: 72134
< Content-Type: text/html
< Set-Cookie: BIGipServerweb_pool=107325632.20480.0000; path=/
< 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
(略)

可以看到，什么事情都不会发生。这说明劫持设备应该是在北京网通出口上。

为了证实设备就在北京网通的出口上，我分别用北京不同线路的机器进行了测试，发现访问均一切正常。但某小ISP租用了网通的出口，出现了被劫持的情况。
为了再证实我的猜想，我在一台位于北京某不受影响的ISP的服务器上分别装了pptpd和rinetd，先测试使用VPN链接到此服务器pptpd，所有数据包通过此服务器发送，访问VeryCD.com，一切正常，数据没有被劫持。
然后再把本机的hosts指向此服务器，通过服务器的rinetd对数据包进行转发至VeryCD的服务器，发现数据包被劫持。
结论：加密后的数据不会被劫持。

我再到外部随便找了一台服务器，此服务器跟VeryCD无任何关系，也不位于同一物理位置，结果如下

Sam@Bogon:~$ curl -v -H 'Host: www.verycd.com' server.outside
* About to connect() to server.outside port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to server.outside (x.x.x.x) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.verycd.com
> 
< HTTP/1.1 200 OK
< Content-Type: text/html;charset=gb2312
< Content-Length:182
< 
<html><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"><title>warn</title></head><frameset cols="100"><frame src="http://www.baidu.com"/></frameset></html>
* Connection #0 to host server.outside left intact
* Closing connection #0

分析到了这一步，事情已经非常明朗了：
在北京网通的出口，被人有意或者无意放置了一套类似于GFW的设备用于劫持所有在列表内的P2P网站。我个人更加愿意相信这是网通在测试新设备。因为很明显，劫持后返回的数据使用了一个警告（warn）的标题，劫持者对于这些被劫持的网站的流量有一个很清晰的认识，并没有自己使用服务器来支撑这些流量（根据我掌握的数据，这些网站的流量，就算是静态的html文件也需要十几台服务器做支撑），而是不带任何用于分成或者统计的代码跳转到百度（百度用于统计和分成的代码是tn=xxxx）。（被劫持的第三天有部分流量被分到information.com，直接把information.com弄挂了）。
至于百度也是有苦难言。白白来了这么多无效流量，消耗资源不说，还要背上一个骂名。据我所知，出事后百度也在到处找方式接触受害网站了解情况。

====
解决方法：
根据上面的结论，这件事情的解决方法有下面几种：
1.更换域名，跟劫持者耗。对网站所有者来说低成本，但会造成大量用户不知道新域名而流失。但可以借助百度贴吧来解决。
2.使用BGP协议，更改北京网通用户到网站服务器之间的路由，跳过劫持设备。缺点是成本太高，BGP协议可以被网通人为忽略。
3.在劫持设备以内放置一台分流服务器，分流服务器使用VPN或者别的加密链路链接至主服务器进行数据交换。这样用户使用非加密链接链接至分流服务器，劫持设备无法进行劫持。
4.网站使用ssl，用户和网站之间数据均经过加密，劫持设备无法截取。

====
课外作业：
既然这套设备类似GFW，众所周知GFW是双向的，不知道这套设备怎样呢？带着这个疑问，我做了一个课外实验，让外省的朋友使用上面的测试方法访问我的机器

curl -vIH "Host: www.verycd.com" http://124.64.1xx.xx/
* About to connect() to 124.64.1xx.xx port 80 (#0)
*   Trying 124.64.1xx.xx... connected
* Connected to 124.64.1xx.xx (124.64.1xx.xx) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.verycd.com
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Thu, 06 Nov 2008 15:28:27 GMT
Date: Thu, 06 Nov 2008 15:28:27 GMT
< Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.7l
Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.7l
< Last-Modified: Mon, 24 Sep 2007 05:23:06 GMT
Last-Modified: Mon, 24 Sep 2007 05:23:06 GMT
< ETag: "29d84-17ef-43adad0ba6280"
ETag: "29d84-17ef-43adad0ba6280"
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Content-Length: 6127
Content-Length: 6127
< MS-Author-Via: DAV
MS-Author-Via: DAV
< Content-Type: text/html
Content-Type: text/html

可以看到，这套设备真不咋地，不支持反向过滤。

====
又及：
在测试的过程中，我发现连续发送N个请求出去，总有几个漏网之鱼，能正确返回数据。这说明了啥？
1.设备是旁路的，失败的截取不会影响到正常的数据传输
2.设备要么是性能有缺陷，要么有防ddos的功能。我更加愿意相信前者。
3.不管设备是性能有缺陷还是能防ddos，我相信一点：在大量数据的攻击下，设备肯定会失去部分作用。

Pages (47): « First ... « 9 10 11 12 13 14 15 » ... Last »

About this blog

奶罩的个人Blog，记录生活中的点点滴滴。


Sponsors

RSS My Twitter

Categories

Copyright © 2007 - - is proudly powered by WordPress
Dilectio Theme is created by: Design Disease brought to you by Smashingmagazine.com