今天總算閑了下來，隨手把前幾天VeryCD被劫持的一些分析記錄和解決方法整理出來。相信這份資料對個人站長來說非常有參考價值。
順便推薦一下Caoz寫的一篇文章，希望大家都能了解做網(wǎng)站背后的辛酸：由做站長的艱辛說起
今天總算閑了下來，隨手把前幾天VeryCD被劫持的一些分析記錄和解決方法整理出來。相信這份資料對個人站長來說非常有參考價值。
順便推薦一下Caoz寫的一篇文章，希望大家都能了解做網(wǎng)站背后的辛酸：由做站長的艱辛說起
====
話說VeryCD等網(wǎng)站被劫持的第二天，劫持還在繼續(xù)。我閑著無聊在QQ群里胡扯，被Dash和xdanger逮到。正好我非常榮幸的是北京網(wǎng)通用戶，這個偉大的任務就只能交給我了。
先用正常方式訪問一下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:~$
可以發(fā)現(xiàn)返回的結果直接被劫持并替換。并不像一般的掛馬等行為是在網(wǎng)頁內(nèi)容的最前或者最后部分插入劫持代碼。
之后直接輸入VeryCD的IP，返回的結果是VeryCD的squid服務器默認頁面，說明IP并沒有成為劫持的判斷標準。應該是VeryCD的域名或者網(wǎng)頁中某個特征導致劫持設備對內(nèi)容進行替換。（此處省略結果）
既然域名是判斷的標準之一，那么就可以嘗試替換HTTP協(xié)議中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為發(fā)送一個主機頭為www.veryc.com的請求到verycd的服務器，可以看到數(shù)據(jù)正常返回，沒有被劫持
2為發(fā)送了一個主機頭為verycd.com的請求到verycd的服務器，可以看到數(shù)據(jù)被劫持了
3為發(fā)送了一個主機頭為www.veryc.com，使用GET方式獲取/verycd.com文件的請求到verycd的服務器，可以看到數(shù)據(jù)正常返回，沒有被劫持
4為發(fā)送一個主機頭為w.verycd.com的請求到verycd的服務器，可以發(fā)現(xiàn)數(shù)據(jù)沒有被劫持
通過上面的結論可以看出，用于劫持的設備只對域名的host部分做判斷。
我們再來一個有趣的測試：如果把host發(fā)送到網(wǎng)通的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"> (略)
可以看到，什么事情都不會發(fā)生。這說明劫持設備應該是在北京網(wǎng)通出口上。
為了證實設備就在北京網(wǎng)通的出口上，我分別用北京不同線路的機器進行了測試，發(fā)現(xiàn)訪問均一切正常。但某小ISP租用了網(wǎng)通的出口，出現(xiàn)了被劫持的情況。
為了再證實我的猜想，我在一臺位于北京某不受影響的ISP的服務器上分別裝了pptpd和rinetd，先測試使用VPN鏈接到此服務器pptpd，所有數(shù)據(jù)包通過此服務器發(fā)送，訪問VeryCD.com，一切正常，數(shù)據(jù)沒有被劫持。
然后再把本機的hosts指向此服務器，通過服務器的rinetd對數(shù)據(jù)包進行轉發(fā)至VeryCD的服務器，發(fā)現(xiàn)數(shù)據(jù)包被劫持。
結論：加密后的數(shù)據(jù)不會被劫持。
我再到外部隨便找了一臺服務器，此服務器跟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
分析到了這一步，事情已經(jīng)非常明朗了：
在北京網(wǎng)通的出口，被人有意或者無意放置了一套類似于GFW的設備用于劫持所有在列表內(nèi)的P2P網(wǎng)站。我個人更加愿意相信這是網(wǎng)通在測試新設備。因為很明顯，劫持后返回的數(shù)據(jù)使用了一個警告（warn）的標題，劫持者對于這些被劫持的網(wǎng)站的流量有一個很清晰的認識，并沒有自己使用服務器來支撐這些流量（根據(jù)我掌握的數(shù)據(jù)，這些網(wǎng)站的流量，就算是靜態(tài)的html文件也需要十幾臺服務器做支撐），而是不帶任何用于分成或者統(tǒng)計的代碼跳轉到百度（百度用于統(tǒng)計和分成的代碼是tn=xxxx）。（被劫持的第三天有部分流量被分到information.com，直接把information.com弄掛了）。
至于百度也是有苦難言。白白來了這么多無效流量，消耗資源不說，還要背上一個罵名。據(jù)我所知，出事后百度也在到處找方式接觸受害網(wǎng)站了解情況。
====
解決方法：
根據(jù)上面的結論，這件事情的解決方法有下面幾種：
1.更換域名，跟劫持者耗。對網(wǎng)站所有者來說低成本，但會造成大量用戶不知道新域名而流失。但可以借助百度貼吧來解決。
2.使用BGP協(xié)議，更改北京網(wǎng)通用戶到網(wǎng)站服務器之間的路由，跳過劫持設備。缺點是成本太高，BGP協(xié)議可以被網(wǎng)通人為忽略。
3.在劫持設備以內(nèi)放置一臺分流服務器，分流服務器使用VPN或者別的加密鏈路鏈接至主服務器進行數(shù)據(jù)交換。這樣用戶使用非加密鏈接鏈接至分流服務器，劫持設備無法進行劫持。
4.網(wǎng)站使用ssl，用戶和網(wǎng)站之間數(shù)據(jù)均經(jīng)過加密，劫持設備無法截取。
====
課外作業(yè)：
既然這套設備類似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
可以看到，這套設備真不咋地，不支持反向過濾。
====
又及：
在測試的過程中，我發(fā)現(xiàn)連續(xù)發(fā)送N個請求出去，總有幾個漏網(wǎng)之魚，能正確返回數(shù)據(jù)。這說明了啥？
1.設備是旁路的，失敗的截取不會影響到正常的數(shù)據(jù)傳輸
2.設備要么是性能有缺陷，要么有防ddos的功能。我更加愿意相信前者。
3.不管設備是性能有缺陷還是能防ddos，我相信一點：在大量數(shù)據(jù)的攻擊下，設備肯定會失去部分作用。