長城寬帶惡意流量劫持證據(jù)分析及防范

長城寬帶使用下三濫手段劫持可執(zhí)行文件下載地址，然后引導(dǎo)到其他站點，這個操作用心不良啊，這可以夾帶惡意文件啊。    

看看這個220.112.194.135這個ip地址歸屬，http://www.ip.cn/index.php?ip=220.112.194.135

如果上面大圖看不清，請繼續(xù)閱讀下面關(guān)于http://www.bing.com/test.zip 的例子        

后續(xù)，后面投訴到長寬的客服，聯(lián)系了多人處理了一下（僅僅把我反饋的www.7-zip.org 處理了下，怎么處理的呢，就是加了下緩存），忽悠吧，后面接著投訴。

證據(jù)：

yoke@yoke:/etc$ curl -v http://www.7-zip.org/a/7z1604.exe
*   Trying 178.62.49.34...
* Connected to www.7-zip.org (178.62.49.34) port 80 (#0)
> GET /a/7z1604.exe HTTP/1.1
> Host: www.7-zip.org
> User-Agent: curl/7.50.1
> Accept: */*
>  < HTTP/1.1 302 Found
< Connection: close
< Location: http://211.162.127.22/files/61760000031424D9/www.7-zip.org/a/7z1604.exe
<  * Closing connection 0

好吧，似乎location的地址不一樣了，這個7-zip 的是可以下載了，但是劫持還在，為什么說是劫持呢？下面證據(jù)可以看下，我偽造一個不存在的地址(正常情況應(yīng)該是返回404 不存在，如果你是用緩存或者代理服務(wù)器，那也是應(yīng)該返回404的）， curl –v  http://www.bing.com/test.zip

[yoke@host:/]#curl -v http://www.bing.com/test.zip

 > GET /test.zip HTTP/1.1 

  > User-Agent: curl/7.38.0 

 > Host: www.bing.com 

 > Accept: */* 

> 
< HTTP/1.1 302 Found 
< Content-Length: 0 

< Cache-Control: no-cache 

< Connection: close 
< Location: http://211.162.74.233:9011/www.bing.com/c3pr90ntc0td/test.zip

而如果用瀏覽器訪問則顯示：

使用wireshark 抓包的情況：

1. 488 編號的包，是我發(fā)送http://www.bing.com/test.zip 的請求包

2. 489 返回了302 Found，給的包內(nèi)容是location:http://211.162.74.233:9011/www.bing.com/c3pr90ntc0td/test.zip

3. 490由于發(fā)現(xiàn)302，我方回包給bing FIN，ACK關(guān)閉連接。

4. 497對方對FIN，ACK 的包進(jìn)行響應(yīng)，發(fā)回ACK。

5. 498 我方ACK對方的ACK。

6. 500 這個包很特別，是晚到的真的bing的返回包，但是由于前面的原因（3-5步驟里），這個包認(rèn)為是重傳的包，已經(jīng)被應(yīng)用忽略了，雖然協(xié)議顯示tcp,實際這個包并沒有解碼http,解碼http后的信息是下面

  HTTP/1.1 301 Moved Permanently 
    Location: http://cn.bing.com/test.zip
    Server: Microsoft-IIS/8.5 

    X-MSEdge-Ref: Ref A: 5BD13BD03E4A4A62AAB34684A24288F0 Ref B: BJ1SCHEDGE0116 Ref C: Fri Mar 10 23:27:26 2017 PST 

    Date: Sat, 11 Mar 2017 07:27:26 GMT 

    Content-Length: 0

結(jié)論：

1. 長城寬帶的劫持是http的劫持，而且是針對特定Url模式的，比如后綴是zip,rar,exe,apk，mp3等，有些國內(nèi)的大站用的似乎是緩存或代理，而不是劫持。

2. 劫持后看location的地址，應(yīng)該是nginx 的反向代理加了緩存，只不過似乎劫持和反向代理沒有配合好，也或者是反向代理技術(shù)比較爛，站點本來該緩存在ngnix 上的，但是nginx沒有緩存（也沒有做反向配置），所以丟到http://220.112.194.135:9011/www.jsfund.cn/c3pr90ntc0td/cert.zip 類似這樣的地址，不會有內(nèi)容返回）。

3. 測試自己是否被劫持很簡單，不用抓包了，只需使用curl -v http://www.bing.com/test.zip (這是個偽造的地址，如果你發(fā)現(xiàn)響應(yīng)的是302，而不是404或者301，都是劫持，劫持一般通過重寫location 也或者返回一段js讓你跳轉(zhuǎn)） ，我的dns解析沒有問題，雖然也可能存在DNS劫持（DNS默認(rèn)是UDP協(xié)議，也可走TCP，但是如果不加密都是可以劫持的）這里是http劫持（你是否注意到我抓包的界面的dns解析的ip 是正確的，因為我直接查的國外的dns）,那么ip沒有問題，而且我的包也是發(fā)往正確的ip的，只是響應(yīng)內(nèi)容被替換了。

防范手法：

OK，既然知道了整個過程和劫持的手段，遇到這種情況我們只能認(rèn)宰了么？有沒有更好的辦法可以處理劫持。上面抓包的解釋充分說明，長寬的http劫持只是在目標(biāo)網(wǎng)站返回前，丟你一個假的302的包，它也懶得去丟個rst 給目標(biāo)網(wǎng)站，所以目標(biāo)網(wǎng)站仍然發(fā)包給你，不過你會忽略掉而已了。

那么我們只需要識別出這個假的302的包然后丟棄就可以了嘛，那么什么工具可以做這個，顯然是防火墻的功能，而且是能寫包匹配規(guī)則和對包能操作的工具，linux上的iptables 正好做這個事情，IPtables含有一個string module 可以匹配包中的字符串，由于長寬丟回的302包中都有這個:9011/ 的關(guān)鍵字，而且這個302 Found用的很是典型，所以我用多個過濾條件進(jìn)行過濾。  

iptables -N check_for_9011
  iptables -I INPUT -p tcp -m tcp --sport 80 --tcp-flags FIN,SYN,RST,PSH,ACK,URG PSH,ACK -m string --string  "302 Found" --algo bm --from 45 --to 80 -j check_for_9011

  iptables -I check_for_9011 -m string --string ":9011/" --algo bm --from 70 –to 180  -j DROP

以上iptables 規(guī)則檢查源端口為80，且tcp-flags 為PSH,ACK的包，如果返回包中包含：”302 Found”,然后丟給check_for_9011 chain ,這個chain 會有另外一個規(guī)則額外處理，會匹配是否含有":9011/"的字樣，如果發(fā)現(xiàn)丟棄該包。

注意：上面我使用了iptables 的string 擴(kuò)展和tcp擴(kuò)展，我使用tcp-flags 來匹配PSH,ACK標(biāo)志位的包，string 擴(kuò)展從包的第45字節(jié)到80 字節(jié)之間進(jìn)行尋找”302 Found” ,如果找到跳到check_for_9011 用戶表，然后check_for_9011表中有規(guī)則匹配是否含有“：9011/” ,我用了offset from70到180來防止過多匹配。這個offset 你可以使用wireshark來輔助，比如上面wireshark 截圖中的最下面的左邊為十六進(jìn)制，右邊為ASCII解碼的界面里，最左邊有個0010，0020，0030這些行，每行16個字節(jié)，這樣你可以計算大概的offset了（TCP頭的大概差不多40個字節(jié)左右）。

注意iptables 的規(guī)則從上自下執(zhí)行，如果前面有規(guī)則，比如對包狀態(tài)ctstate RELATED,ESTABLISHED的數(shù)據(jù)包放行的規(guī)則存在的話，你需要調(diào)整上面的iptables 為靠上（我上面的Iptables 命令用了-I，會把規(guī)則插入到最前面）

加了iptables 后的效果：

yoke@yoke:/etc/iptables$ curl -v http://www.bing.com/test.zip
*   Trying 202.89.233.104...
* Connected to www.bing.com (202.89.233.104) port 80 (#0)
> GET /test.zip HTTP/1.1
> Host: www.bing.com
> User-Agent: curl/7.50.1
> Accept: */*
>  < HTTP/1.1 301 Moved Permanently
< Location: http://cn.bing.com/test.zip
< Server: Microsoft-IIS/8.5
< X-MSEdge-Ref: Ref A: 6150F693AAC74237AE03DBDAE30A17B6 Ref B: BJ1EDGE0216 Ref C: Tue Mar  7 06:47:07 2017 PST
< Date: Tue, 07 Mar 2017 14:47:06 GMT
< Content-Length: 0
<  * Connection #0 to host www.bing.com left intact

這樣才是正常不被劫持的狀態(tài)，如果劫持存在，就返回302了。

寬帶路由器上攔截的方法：

如果你的路由器使用openwrt 等linux系統(tǒng)，上面iptables 規(guī)則應(yīng)用到路由器上非常簡單。只需要把命令改為下面（和上面規(guī)則相比，寬帶路由上只把INPUT表換成了FORWARD表）

下面命令輸入到openwrt --->網(wǎng)絡(luò)設(shè)置—>防火墻—>自定義規(guī)則中，然后重啟防火墻。

iptables -N check_for_9011 
iptables -I FORWARD -p tcp -m tcp --sport 80 --tcp-flags FIN,SYN,RST,PSH,ACK,URG PSH,ACK -m string --string  "302 Found" --algo bm --from 45 --to 80 -j check_for_9011 
iptables -I check_for_9011 -m string --string ":9011/" --algo bm --from 70 –to 180  -j DROP

如果你喜歡命令行，請ssh 你的寬帶路由（假設(shè)是openwrt系統(tǒng)），請修改/etc/firewall.user 增加上面內(nèi)容，這樣路由重啟后依然會應(yīng)用這些策略。

那么規(guī)則放了，如何看規(guī)則有沒有生效呢？

1. 客戶端使用curl 或者瀏覽器訪問，測試目前url

2. 防火墻上使用iptables –L INPUT –xv && iptables –L FORWARD –xv && iptables –L check_for_9011 –xv 看狀態(tài)

3. 如果openwrt 網(wǎng)頁版，可用狀態(tài)—>防火墻里面來看，比如下圖: