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

Godbach

Linux內核中提供了SYN Cookie的檢驗機制，用來防御SYN Flood攻擊。因此，延伸出來的在SYN Cookie Firewall，用來驗證SYN連接，并對通過驗證報文進行轉發(fā)。
具體的內容可以參考《SYN Cookie原理及其在Linux內核中的實現(xiàn)》
http://www.ibm.com/developerworks/cn/linux/l-syncookie/index.html

使用syn cookie檢驗機制的Firewall，實際上相當于一個syn proxy。它會代替server對client三次握手，對syn報文進行cookie驗證，然后再將client初始的syn報文發(fā)給server，并做三次握手。這個過程中，很明顯client記錄的server的seq實際上firewal初始的seq。
如下圖所示：


因此，F(xiàn)irewall就要負責這個序列號在client和server交互的報文之間進行轉換（維護一個差值），直到這個連接結束。

這里的問題如下：

通常情況下，F(xiàn)irewall對于多個syn連接處理的時候，F(xiàn)W是不是就得維護多個差值。 這樣的話是不是需要記錄連接的五元組，并且維護一個hash表。這個hash表應該包含那些內容呢？

dreamice

如果是完全的攔截，其實對序列號不需要多做考慮

Godbach

原帖由 dreamice 于 2009-3-12 21:31 發(fā)表
如果是完全的攔截，其實對序列號不需要多做考慮

關鍵是防火墻做一下驗證，正常的訪問還得繼續(xù)。不考慮序列號不行吧？

dreamice

原帖由 Godbach 于 2009-3-12 22:12 發(fā)表


關鍵是防火墻做一下驗證，正常的訪問還得繼續(xù)。不考慮序列號不行吧？

關鍵是你攔截在什么地方，包能否走到tcp層？
一個syn包，是不會走到應用層的，只是在內核檢查到有應用程序在監(jiān)聽這個端口，那么在tcp層就直接回ack＋syn包了，
所以，這個就看你在哪里攔截了，你若在ip層阻擋了，不讓他上去，那考慮序列號也沒什么意義，除非你在這個ip層模擬發(fā)ack。

Godbach

原帖由 dreamice 于 2009-3-12 22:23 發(fā)表


關鍵是你攔截在什么地方，包能否走到tcp層？
一個syn包，是不會走到應用層的，只是在內核檢查到有應用程序在監(jiān)聽這個端口，那么在tcp層就直接回ack＋syn包了，
所以，這個就看你在哪里攔截了，你若在ip層 ...

dreamice兄可能沒有理解那個附圖的意思吧。你首先代替服務器發(fā)送了SYNcookie ，但是真正再把這個SYN發(fā)送到服務器，建立連接之后，從server發(fā)向client的報文的seq和client預期的是不一樣的。

dreamice

看昏了，我以為是透明代理

Godbach

原帖由 dreamice 于 2009-3-12 22:47 發(fā)表
看昏了，我以為是透明代理

呵呵，有時間討論一下這個轉換以及實現(xiàn)啊。

dreamice

原帖由 Godbach 于 2009-3-12 22:59 發(fā)表


呵呵，有時間討論一下這個轉換以及實現(xiàn)啊。

現(xiàn)在內核支持透明代理，就不用考慮這些東東了

dreamice

不過我不太清楚這個應用，可能和我想的不一樣

qtdszws

我想可以參考ftp的conntrack和nat實現(xiàn)