[歡迎進入討論] 關于syn-proxy的一些問題

ShadowStar

其實，我這邊也要作這個東西。目前有2個方法。

我覺得SYN－FLOOD這個問題需要考慮如下幾個關鍵點。
1. 效率，處理的速度（時間）。
2. 資源，防火墻的資源占用和被保護服務器的資源占用。

相比之下，代理握手的方式是效率相對較低、防火墻資源占用較大，服務器資源占用較小的。
尤其是保存syn包的方式，我覺得比較不可取。
我擔心在大流量SYN－FLOOD時，防火墻被打死。

而另一種正好相對。

so, I'm in thinking.

Godbach

有效的抵御SYN flood，也許得多種方法結合著使用。
ShadowStar兄可否介紹一下另一種方法。。

ShadowStar

所謂的另一種方法，是針對于SYN-FLOOD的危害的采取的。

SYN－FLOOD主要危害是由于服務器的半開連接消耗較大資源導致的。

所以，我們可以把半開連接處理為完成連接。
也就是，放過SYN和SYN－ACK。偽造一個發(fā)送給服務器的ACK，并丟棄原始client的ACK。

這種方法會造成受到SYN－FLOOD攻擊的服務器建立大量的連接。
但是防火墻本身的負擔小了很多。

Godbach

所謂的另一種方法，是針對于SYN-FLOOD的危害的采取的。

SYN－FLOOD主要危害是由于服務器的半開連接消耗較大資源導致的。

所以，我們可以把半開連接處理為完成連接。
也就是，放過SYN和SYN－ACK。偽造一個發(fā)送給服務器的ACK，并丟棄原始client的ACK。

這種方法會造成受到SYN－FLOOD攻擊的服務器建立大量的連接。
但是防火墻本身的負擔小了很多。

ShadowStar兄的意思是讓在server端建立起來連接。已建立的連接要比半連接節(jié)省資源。

但是本身使用fw保護server的，現(xiàn)在反而成了犧牲server保護fw，這樣合適嗎？

ShadowStar

原帖由 Godbach 于 2009-3-17 09:48 發(fā)表


ShadowStar兄的意思是讓在server端建立起來連接。已建立的連接要比半連接節(jié)省資源。

但是本身使用fw保護server的，現(xiàn)在反而成了犧牲server保護fw，這樣合適嗎？

其實這個問題看怎么考慮了，因為這種處理方式已經(jīng)處理了“SYN－FLOOD”攻擊的主要危害。
而且，從防火墻和服務器整體考慮的話，這種方式的整體效率要好于代理方式，資源占用也不大。

并且可以通過對超時的syn連接（防火墻偽裝完的）發(fā)送RST包，來降低服務器的連接數(shù)量。

可以保證正常的連接不受影響。

代理的方式在負載較大時，防火墻很容易成為網(wǎng)絡的瓶頸，進而崩潰，影響的就不是一臺服務器了。

Godbach

代理的方式在負載較大時，防火墻很容易成為網(wǎng)絡的瓶頸，進而崩潰，影響的就不是一臺服務器了。

恩，反正兩個是串在一個繩子上的。

ShadowStar

原帖由 Godbach 于 2009-3-17 10:09 發(fā)表


恩，反正兩個是串在一個繩子上的。

當然，這第二種方法與一般的用戶理解還是有沖突的。

Godbach

不知ShadowStar兄是否已經(jīng)采用了這種方式，效果怎么樣啊？

另外，怎么確定這個SYN連接是攻擊報文，而不是正常的請求呢? 因為你是攔截了server的SYN+ACK, 直接構造了ACK報文

Godbach

原帖由 ShadowStar 于 2009-3-17 10:13 發(fā)表


當然，這第二種方法與一般的用戶理解還是有沖突的。

恩，我也覺得現(xiàn)在一般的用戶可能還不容易接受這個方式。

ShadowStar

原帖由 Godbach 于 2009-3-17 10:16 發(fā)表
不知ShadowStar兄是否已經(jīng)采用了這種方式，效果怎么樣啊？

另外，怎么確定這個SYN連接是攻擊報文，而不是正常的請求呢? 因為你是攔截了server的SYN+ACK, 直接構造了ACK報文

并不攔截SYN－ACK，而是在收到SYN－ACK時，直接偽造一個ACK發(fā)給服務器。
這樣處理的成本小的多。

也不需要判斷是否是攻擊報文，只要在正常的SYN-RECV超時后發(fā)送RST就OK了；如果不超時，定時器刷新的話，自然也不會發(fā)送RST。

我還沒有作，因為我手里還有別的在忙。另外，還沒考慮好這樣是否是最優(yōu)的。