
平臺(tái) 論壇博客文庫

› 論壇 › 備份版區(qū) › 攻防交流區(qū) › Iptables求驗(yàn)證

Iptables求驗(yàn)證 [復(fù)制鏈接]

unigium

稍有積蓄

論壇徽章:: 0

電梯直達(dá)

1樓 [收藏(0)] [報(bào)告]

發(fā)表于 2005-09-19 15:02 |只看該作者 |倒序?yàn)g覽

寫在前面：\r\n為什么我自己不試驗(yàn)一下？\r\n因?yàn)槲易约簩?duì)Iptables了解非常少，僅對(duì)狀態(tài)檢測(cè)機(jī)制有所了解。\r\n希望驗(yàn)證的內(nèi)容：\r\n一、關(guān)于IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP 規(guī)則\r\n此規(guī)則是對(duì)于這樣的包進(jìn)行過濾：外部網(wǎng)絡(luò)主機(jī)已經(jīng)與防火墻內(nèi)部或者其自身建立了鏈接，而此規(guī)則后來生效的那些此連接的數(shù)據(jù)包\r\n具體實(shí)施環(huán)境：\r\n防火墻之外的主機(jī)A:10.1.1.2/24 \r\n放火墻F:10.1.1.1/24 與 10.1.2.1/24 \r\n受防火墻保護(hù)的網(wǎng)段：10.1.2.0/24 \r\n受防火墻保護(hù)的網(wǎng)段內(nèi)的一臺(tái)主機(jī)X：10.1.2.10/24（開啟telnet服務(wù)） \r\n具體實(shí)施分兩個(gè)種情況進(jìn)行模擬：\r\n\r\n情況I（公網(wǎng)訪問內(nèi)網(wǎng)）: \r\n1、主機(jī)A telnet 到主機(jī)X,并保持連接狀態(tài). \r\n2、開啟防火墻F上的iptables服務(wù)，并使規(guī)則： \r\nIPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP \r\n生效。 \r\n3、使用剛才的telnet客戶端執(zhí)行隨便一個(gè)命令，如:ls \r\n上面的ls命令應(yīng)該是執(zhí)行不成功的。 \r\n\r\n如果防火墻之外的主機(jī)A先連到了我們的內(nèi)部網(wǎng)絡(luò)主機(jī)X,防火墻F的規(guī)則發(fā)生了改變，禁止A發(fā)送SYN段鏈接進(jìn)入X，規(guī)則不生效.所以我們不的不應(yīng)用此規(guī)則，讓其重新鏈接。\r\n\r\n基與這一點(diǎn)，我想iptables雖然是工作在網(wǎng)絡(luò)層的防火墻，但是它會(huì)查看TCP包頭的，所以嚴(yán)格的說,iptables是一個(gè)傳輸層與網(wǎng)絡(luò)層的放火墻。但就象手機(jī)可以錄音一樣，我們還是稱之為手機(jī)，所以，iptables還是網(wǎng)絡(luò)層的防火墻。\r\n\r\n情況II(內(nèi)網(wǎng)為私用網(wǎng)地址，防火墻使用了SNAT):\r\n1、內(nèi)網(wǎng)的一臺(tái)機(jī)器X,telnet到防火墻F \r\n2、啟動(dòng)防火墻F的ppp時(shí)起用此規(guī)則 \r\n剛才的telnet會(huì)中斷。如果把conntrack和nat直接編譯進(jìn)內(nèi)核心，就不會(huì)出現(xiàn)上面的情況。 \r\n\r\n二、關(guān)于iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset 規(guī)則\r\n此規(guī)則是對(duì)這樣的包進(jìn)行過濾，并發(fā)出錯(cuò)誤報(bào)告：tcp包頭中的syn=1并且ack=1的段進(jìn)行過濾，并向此鏈接的發(fā)起端發(fā)出tcp-reset(也就是RST=1)的數(shù)據(jù)包，通知關(guān)閉其鏈接。\r\n具體實(shí)施：\r\n攻擊這A:10.1.1.2\r\n放火墻F:10.1.1.1/24 與 10.1.2.1/24 \r\n受防火墻保護(hù)的網(wǎng)段：10.1.2.0/24 \r\n受防火墻保護(hù)的網(wǎng)段內(nèi)的一臺(tái)主機(jī)O(無辜者)：10.1.2.10/24\r\n受害者V:11.22.33.44\r\n1、[A]以[O]的IP為源地址向[V]發(fā)SYN。\r\n\r\n2、[V]向[O]回應(yīng)SYN/ACK。(這也是為什么要三次握手才可以確定鏈接與否的原因，而不是兩次。)\r\n\r\n3、現(xiàn)在，若[O]以RST回應(yīng)這個(gè)未知的SYN/ACK，攻擊就失敗了，但如果[O]已經(jīng)沒有這個(gè)能力了呢？比如它早已被另外的攻擊（如SYN flood）降服，或者被關(guān)閉，或者它的RST包被防火墻拒絕。\r\n\r\n4、如果[O]沒能破壞這條連接，而且[A]猜對(duì)了序列號(hào)，那它就能以[O]的身份發(fā)出第三次握手并與V通信了。\r\n這條規(guī)則的存在還產(chǎn)生了另外一問題，就是有幾個(gè)portscan（端口掃描器）會(huì)看到我們的防火墻。因?yàn)镽ST=1的鏈接復(fù)位包是由防火墻發(fā)起的。\r\n注意：這條規(guī)則并不能防止你成為受害者。\r\n\r\n三、關(guān)于兩個(gè)規(guī)則的功能的相互替換。 \r\n1、可以用此規(guī)則：IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP 防止syn欺騙么？ \r\n不可以。因?yàn)樵诘?次握手(ack=1,syn=1)，如果iptables檢測(cè)到這個(gè)包是第一次到來，那么狀態(tài)是NEW。這樣就與規(guī)則ack=1（! --syn用來匹配那些 RST或ACK被置位的包）匹配。規(guī)則生效。但是這樣做只是把包drop掉了，并沒有發(fā)出RST以通知連結(jié)的發(fā)起者。 \r\n2、可以用此規(guī)則：iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset來防止外網(wǎng)先鏈接到本地機(jī)器，而規(guī)則后生效，并且阻止此鏈接的后續(xù)包進(jìn)入么？ \r\n不可以。因?yàn)樵诖艘?guī)則生效后，鏈接的后續(xù)包的狀態(tài)標(biāo)志位并不是syn=1。 \r\n多謝論壇里的兄弟和我探討，讓我有了更進(jìn)一步的了解。如果有任何錯(cuò)誤，請(qǐng)回帖。