[歡迎進(jìn)入討論] 關(guān)于syn-proxy的一些問題

Godbach

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

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


因此，F(xiàn)irewall就要負(fù)責(zé)這個(gè)序列號在client和server交互的報(bào)文之間進(jìn)行轉(zhuǎn)換（維護(hù)一個(gè)差值），直到這個(gè)連接結(jié)束。

這里的問題如下：

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

dreamice

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

Godbach

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

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

dreamice

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


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

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

Godbach

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


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

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

dreamice

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

Godbach

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

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

dreamice

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


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

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

dreamice

不過我不太清楚這個(gè)應(yīng)用，可能和我想的不一樣

qtdszws

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