電信網(wǎng)頁訪問監(jiān)控欺騙另類對(duì)策（求證是否可行）

kevin.tan

在協(xié)議分析網(wǎng)上看到一篇<電信網(wǎng)頁訪問監(jiān)控原理分析>文章，寫得非常好，在此向作者致敬！��！

其中有下列一段話，如附圖中



原話

1. “從圖5解碼信息中可知，該數(shù)據(jù)包的TCP標(biāo)記中，同時(shí)將確認(rèn)位、急迫位、終止位置為1，
   
2. 這表示這個(gè)數(shù)據(jù)包想急于關(guān)閉連接，以防止客戶端（192.168.0.88）收到服務(wù)器
   
3. （[url]www.colasoft.com[/url]）的正常響應(yīng)，"

復(fù)制代碼

在這里，如果我們?cè)诜阑饓χ袑⑦@個(gè)欺騙報(bào)文DROP掉，不就是可以讓電信達(dá)不到欺騙的目地了嗎？如下語句

1. 
   
2. $IPTABLES -A bad_tcp_packets -p tcp --tcp-flags ACK,PSH,FIN ACK,PSH,FIN -j DROP
   

復(fù)制代碼

由于對(duì)知識(shí)有限，對(duì)TCP包頭一知半解，不知道正常的TCP連接的ACK FIN報(bào)文是否設(shè)置有PSH位，如果沒有的話，我想這是否是一個(gè)方法？

附原文：
方正apabi聯(lián)盟推薦.[電信監(jiān)控并記錄網(wǎng)民上網(wǎng)記錄原理分析及案例分析].pdf (220.37 KB, 下載次數(shù): 90)

2008-04-26 22:22 上傳

點(diǎn)擊文件名下載附件

請(qǐng)大家指正，謝謝

kevin.tan

自已頂一下，

查看了一宿舍路由器的匹配記錄，有匹配上的，目前還沒發(fā)現(xiàn)影響應(yīng)用。

1. 
   
2. [3839:2948145] -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,PSH,ACK FIN,PSH,ACK -j DROP
   

復(fù)制代碼

更正一下，上面說的那個(gè)欺騙報(bào)文不是一個(gè)ACK FIN包哦，只是一個(gè)HTTP應(yīng)答報(bào)文，文章內(nèi)有寫:wink: :wink:

ssffzz1

我沒有具體抓過這樣的包，但是個(gè)人認(rèn)為這篇文章有不實(shí)成分，很想科萊的廣告。如果要RST包中斷連接的話，這個(gè)包的源地址要是服務(wù)器的才行，不能隨便一個(gè)源地址發(fā)送個(gè)RST包，就能夠中斷一條TCP連接，這豈不又是一種新的攻擊方式嗎？

kevin.tan

謝謝ssffzz1版的關(guān)注。

建議版主看下那篇文章，“如果要RST包中斷連接的話，這個(gè)包的源地址要是服務(wù)器的才行，”確實(shí)沒錯(cuò)，但那個(gè)電信的服務(wù)器確實(shí)是偽造了發(fā)送RST包的服務(wù)器的源地址，文章里有寫。:wink: :wink:

ssffzz1

哦，可能是我沒有看細(xì)。

不過還有另一個(gè)問題，你當(dāng)然可以用防火墻阻擋RST包，但是這臺(tái)阻斷設(shè)備如果同時(shí)也向服務(wù)器端發(fā)送了RST包，那么結(jié)果同樣是中斷了TCP的連接。

還有另一個(gè)問題，IPTABLES 的conntrack機(jī)制是否會(huì)因?yàn)槭盏搅薘ST包，而清楚了連接狀態(tài)呢？

不過市面上好像有能夠破解的軟件了，我想原理可能也就是處理這些問題的。

platinum

原帖由 kevin.tan 于 2008-4-27 19:30 發(fā)表
謝謝ssffzz1版的關(guān)注。

建議版主看下那篇文章，“如果要RST包中斷連接的話，這個(gè)包的源地址要是服務(wù)器的才行，”確實(shí)沒錯(cuò)，但那個(gè)電信的服務(wù)器確實(shí)是偽造了發(fā)送RST包的服務(wù)器的源地址，文章里有寫。:wink: :wink:

沒用的，那種偽造斷開的設(shè)備會(huì)雙向發(fā)包，不僅發(fā)給你，也同時(shí)發(fā)給服務(wù)器
言外之意，你屏蔽掉了，使內(nèi)網(wǎng)機(jī)器不斷開，但遠(yuǎn)程服務(wù)器也認(rèn)為你斷開了而主動(dòng)結(jié)束 socket
關(guān)于這個(gè)問題我很早之前就考慮過，有一種方法可以實(shí)現(xiàn)
就是在你的防火墻和服務(wù)器前端同時(shí)加這種設(shè)備，防止 RST 以及 FIN 標(biāo)記的數(shù)據(jù)包進(jìn)入
但這么做又有一個(gè)弊端，就是正常的結(jié)束信號(hào)也無法斷開，導(dǎo)致 socket 不能自動(dòng)斷開（超時(shí)重傳仍然失敗除外），會(huì)造成服務(wù)器 socket 被大量占用

kevin.tan

哦，原來是這樣，確實(shí)。

沒法阻止向服務(wù)器端發(fā)送的RST包。

謝謝兩位版主解惑

kevin.tan

原帖由 platinum 于 2008-4-27 20:33 發(fā)表

沒用的，那種偽造斷開的設(shè)備會(huì)雙向發(fā)包，不僅發(fā)給你，也同時(shí)發(fā)給服務(wù)器
言外之意，你屏蔽掉了，使內(nèi)網(wǎng)機(jī)器不斷開，但遠(yuǎn)程服務(wù)器也認(rèn)為你斷開了而主動(dòng)結(jié)束 socket
關(guān)于這個(gè)問題我很早之前就考慮過，有一種方法可以實(shí)現(xiàn)
就是在你的防火墻和服務(wù)器前端同時(shí)加這種設(shè)備，防止 RST 以及 FIN 標(biāo)記的數(shù)據(jù)包進(jìn)入
但這么做又有一個(gè)弊端，就是正常的結(jié)束信號(hào)也無法斷開，導(dǎo)致 socket 不能自動(dòng)斷開（超時(shí)重傳仍然失敗除外），會(huì)造成服務(wù)器 socket 被大量占用

是的，這個(gè)也是我正想學(xué)習(xí)的。

因?yàn)椴涣私庹�常RST包頭flags的組成，想請(qǐng)求下知道的大牛們，正常的RST包flags中其 ACK,PSH,FIN是否同時(shí)置為"1"了，

如果不是，就能正常區(qū)分欺騙RST報(bào)文和正常的RST報(bào)文了，因?yàn)槠垓_的那個(gè)報(bào)文是同時(shí)置位了的

platinum

可以抓包看看，具體我也記不清了
PSH 是緊急位，催促用戶進(jìn)程盡快處理數(shù)據(jù)包，有可能與其他標(biāo)記一起使用
ACK 是應(yīng)答包，有的時(shí)候?yàn)榱颂岣咝�率也可以與 PSH 等一起復(fù)合使用
但 RST 和 FIN 絕對(duì)不會(huì)一起用的，因?yàn)樗麄兪莾煞N截然不同的結(jié)束 socket 的方式，至少我沒見過有這么用的

7717060

不錯(cuò),收藏了!!!!!!!