今天總算閑了下來，隨手把前幾天VeryCD被劫持的一些分析記錄和解決方法整理出來。相信這份資料對個人站長來說非常有參考價值。
順便推薦一下Caoz寫的一篇文章，希望大家都能了解做網站背后的辛酸：由做站長的艱辛說起
今天總算閑了下來，隨手把前幾天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，我相信一點：在大量數據的攻擊下，設備肯定會失去部分作用。