您好,登錄后才能下訂單哦!
長城寬帶使用下三濫手段劫持可執行文件下載地址,然后引導到其他站點,這個操作用心不良啊,這可以夾帶惡意文件啊。
看看這個220.112.194.135這個ip地址歸屬,http://www.ip.cn/index.php?ip=220.112.194.135
如果上面大圖看不清,請繼續閱讀下面關于http://www.bing.com/test.zip 的例子
后續,后面投訴到長寬的客服,聯系了多人處理了一下(僅僅把我反饋的www.7-zip.org 處理了下,怎么處理的呢,就是加了下緩存),忽悠吧,后面接著投訴。
證據:
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 的是可以下載了,但是劫持還在,為什么說是劫持呢?下面證據可以看下,我偽造一個不存在的地址(正常情況應該是返回404 不存在,如果你是用緩存或者代理服務器,那也是應該返回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 抓包的情況:
488 編號的包,是我發送http://www.bing.com/test.zip 的請求包
489 返回了302 Found,給的包內容是location:http://211.162.74.233:9011/www.bing.com/c3pr90ntc0td/test.zip
490由于發現302,我方回包給bing FIN,ACK關閉連接。
497對方對FIN,ACK 的包進行響應,發回ACK。
498 我方ACK對方的ACK。
500 這個包很特別,是晚到的真的bing的返回包,但是由于前面的原因(3-5步驟里),這個包認為是重傳的包,已經被應用忽略了,雖然協議顯示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
結論:
長城寬帶的劫持是http的劫持,而且是針對特定Url模式的,比如后綴是zip,rar,exe,apk,mp3等,有些國內的大站用的似乎是緩存或代理,而不是劫持。
劫持后看location的地址,應該是nginx 的反向代理加了緩存,只不過似乎劫持和反向代理沒有配合好,也或者是反向代理技術比較爛,站點本來該緩存在ngnix 上的,但是nginx沒有緩存(也沒有做反向配置),所以丟到http://220.112.194.135:9011/www.jsfund.cn/c3pr90ntc0td/cert.zip 類似這樣的地址,不會有內容返回)。
測試自己是否被劫持很簡單,不用抓包了,只需使用curl -v http://www.bing.com/test.zip (這是個偽造的地址,如果你發現響應的是302,而不是404或者301,都是劫持,劫持一般通過重寫location 也或者返回一段js讓你跳轉) ,我的dns解析沒有問題,雖然也可能存在DNS劫持(DNS默認是UDP協議,也可走TCP,但是如果不加密都是可以劫持的)這里是http劫持(你是否注意到我抓包的界面的dns解析的ip 是正確的,因為我直接查的國外的dns),那么ip沒有問題,而且我的包也是發往正確的ip的,只是響應內容被替換了。
防范手法:
OK,既然知道了整個過程和劫持的手段,遇到這種情況我們只能認宰了么?有沒有更好的辦法可以處理劫持。上面抓包的解釋充分說明,長寬的http劫持只是在目標網站返回前,丟你一個假的302的包,它也懶得去丟個rst 給目標網站,所以目標網站仍然發包給你,不過你會忽略掉而已了。
那么我們只需要識別出這個假的302的包然后丟棄就可以了嘛,那么什么工具可以做這個,顯然是防火墻的功能,而且是能寫包匹配規則和對包能操作的工具,linux上的iptables 正好做這個事情,IPtables含有一個string module 可以匹配包中的字符串,由于長寬丟回的302包中都有這個:9011/ 的關鍵字,而且這個302 Found用的很是典型,所以我用多個過濾條件進行過濾。
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 規則檢查源端口為80,且tcp-flags 為PSH,ACK的包,如果返回包中包含:”302 Found”,然后丟給check_for_9011 chain ,這個chain 會有另外一個規則額外處理,會匹配是否含有":9011/"的字樣,如果發現丟棄該包。
注意:上面我使用了iptables 的string 擴展和tcp擴展,我使用tcp-flags 來匹配PSH,ACK標志位的包,string 擴展從包的第45字節到80 字節之間進行尋找”302 Found” ,如果找到跳到check_for_9011 用戶表,然后check_for_9011表中有規則匹配是否含有“:9011/” ,我用了offset from70到180來防止過多匹配。這個offset 你可以使用wireshark來輔助,比如上面wireshark 截圖中的最下面的左邊為十六進制,右邊為ASCII解碼的界面里,最左邊有個0010,0020,0030這些行,每行16個字節,這樣你可以計算大概的offset了(TCP頭的大概差不多40個字節左右)。
注意iptables 的規則從上自下執行,如果前面有規則,比如對包狀態ctstate RELATED,ESTABLISHED的數據包放行的規則存在的話,你需要調整上面的iptables 為靠上(我上面的Iptables 命令用了-I,會把規則插入到最前面)
加了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
這樣才是正常不被劫持的狀態,如果劫持存在,就返回302了。
寬帶路由器上攔截的方法:
如果你的路由器使用openwrt 等linux系統,上面iptables 規則應用到路由器上非常簡單。只需要把命令改為下面(和上面規則相比,寬帶路由上只把INPUT表換成了FORWARD表)
下面命令輸入到openwrt --->網絡設置—>防火墻—>自定義規則中,然后重啟防火墻。
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 你的寬帶路由(假設是openwrt系統),請修改/etc/firewall.user 增加上面內容,這樣路由重啟后依然會應用這些策略。
那么規則放了,如何看規則有沒有生效呢?
1. 客戶端使用curl 或者瀏覽器訪問,測試目前url
2. 防火墻上使用iptables –L INPUT –xv && iptables –L FORWARD –xv && iptables –L check_for_9011 –xv 看狀態
3. 如果openwrt 網頁版,可用狀態—>防火墻里面來看,比如下圖:
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。