《利用iptables限制黑客暴力猜解LINUX服務器SSH密碼（續）：深入 recent 模塊》要點：
本文介紹了利用iptables限制黑客暴力猜解LINUX服務器SSH密碼（續）：深入 recent 模塊，希望對您有用。如果有疑問，可以聯系我們。

相關主題：服務器安全 / iptables配置

作者：高張遠矚(HiLoveS)

博客：http://www.cnblogs.com/hiloves/

在《使用iptables限制黑客暴力猜解密碼》中介紹了如何使用iptables的recent模塊限制一段時間內的連接數后。查閱網上文章，發現不同的文章有不同的recent命令，而且每位作者都言之鑿鑿說他的命令可以用。

這些recent的命令大體有如下不同：1、set句在前，update（或rcheck）句在后，2、update（或rcheck）句在前，set句在后，3、set句帶或不帶-j ACCEPT。基本是上面這三項的排列組合。我用來用去不覺得很好用，這一篇就再深入一下。

先從案例開始：

案例：對連接到本機的SSH連接進行限制，每個IP每小時只限連接5次。

命令：

-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSHPOOL --rcheck --seconds 3600 --hitcount 5 -j DROP
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSHPOOL --set -j ACCEPT

模擬一下某個電腦連接本機SSH服務的數據包流程，假設以下數據包是在一小時內到達本機的：

1、當這個電腦的第1個SSH包到達本機，規則1檢查SSHPOOL列表中這個源IP是否有hitcount，因為是第一個包，顯而易見，列表是0，規則1判定這個數據包不必執行DROP，并且也不處理這個數據包，將數據包轉給下條規則。

2、規則2將這個數據包計入SSHPOOL列表，就是做+1，因為規則中有-j ACCEPT，規則2放行這個包。

3、第1個數據包進入本機，不用再在iptables里轉了。

4、當第2個SSH包到達本機，規則1檢查SSHPOOL列表的hitcount，發現是1沒有超過5，于是判定不執行DROP并轉給下條規則處理。

5、規則2在SSHPOOL中+1，并放行，第2個數據包進入本機。

6、第3、4、5個包同上。

7、第6個包到達本機，規則1檢查SSHPOOL列表中的hitcount，發現是5了已經連接5次了，于是規則2執行DROP，不必再轉給下條規則了丟棄該包。

8、第7、8…個包同上。

實際上recent的處理更為復雜，這里只是粗淺的描述一下，set也并非簡單的做+1。詳細的列表在/proc/net/xt_recent/目錄下，用cat查看即可。

從上面的流程可以看出，--set的功能在于計錄數據包，將源IP加入列表。--rcheck（update）的功能在于判定數據包在seconds和hitcount條件下是否要DROP。

我在CU論壇上看到另一個版本的命令，作者保證是從服務器上復制下來的，肯定能用：

-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSHPOOL --set
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSHPOOL --rcheck --seconds 3600 --hitcount 5 -j DROP

但在我的服務器上這兩行命令就是不能用，所有的SSH包都被丟棄了。最后問題找到了，這兩行命令僅能工作在INPUT鏈的默認策略為ACCEPT的情況下，而我的INPUT鏈的默認策略為DROP。這個命令與我的命令的區別在于：set句在前，且set句不帶-j ACCEPT。這導致數據包的流程也不同。

1、第1個數據包到達規則1后馬上計入SSHPOOL列表，并且規則1因為沒有-j ACCEPT，直接將數據包轉給下條規則。規則2拿到這個數據包后檢查SSHPOOL列表，發現是1，也不處理這個包，轉給下條規則。如果后續的規則都沒有再處理這個數據包，則最后由INPUT鏈的默認策略ACCEPT處理。由于我的策略是DROP，所以丟棄該包，于是這兩行命令在我的服務器上不能用。

2、這里有個問題，由于set句在前，數據包進入是先計入列表，再判定是否合法。這導致第5個包到達后，先在列表中+1，結果是5，再由規則2判定，發現是5，結果丟棄該包，最后真正ACCEPT的只有4個包。本人認為這樣寫的代碼不符合正常的思維邏輯。而且這樣寫只能正常工作于默認策略是ACCEPT的情況，所以本人不建議用這個版本的命令，我的版本ACCEPT、DROP策略都能用。

從上面可以看出，如果大家在網上看到不同的recent模塊的命令，記得一定要先問問作者INPUT鏈的默認策略是什么。

最后，rcheck和update的區別：

rcheck從第1個包開始計算時間，update是在rcheck的基礎上增加了從最近的DROP包開始計算阻斷時間，具有準許時間和阻斷時間，幫助中說update會更新last-seen時間戳。

放在案例中，rcheck是接收到第1個數據包時開始計時，一個小時內僅限5次連接，后續的包丟棄，直到一小時過后又可以繼續連接。update則是接收到第1個數據包時計算準許時間，在一個小時的準許時間內僅限5次連接，當有包被丟棄時，從最近的丟棄包開始計算阻斷時間，在一個小時的阻斷時間內沒有接收到包，才可以繼續連接。所以rcheck類似令牌桶，一小時給你5次，用完了抱歉等下個小時吧。update類似網銀，連續輸錯5次密碼，停止一小時，只不過update更嚴格，阻斷時間是從最近的一次輸錯時間開始算，比如輸錯了5次，過了半個小時又輸錯一次，這時阻斷時間不是剩半小時，而是從第6次重新計算，剩一小時。這個區別我不太會表述，大家自己做做測試就明白了。

給大家一個測試用的命令，自行替換rcheck、update，然后ping一下就明白了：

-A INPUT -p icmp -m recent --name PINGPOOL --rcheck --seconds 30 --hitcount 5 -j DROP
-A INPUT -p icmp -m recent --name PINGPOOL --set -j ACCEPT

最最后，再啰索一句

ICMP包和UDP包在iptables中的state情況是一樣的，因為是無狀態的，不同于TCP，iptables可以靠SYN等flags確定state，而iptables是基于ICMP包/UDP包到達服務器的間隔時間來確定state的。像我在做上面測試的時候，使用ping 192.168.1.1 -t時，除了第一個ICMP包state是NEW，后續的包state都是ESTABLISHED，結果因為前面有一句

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

結果ping一直是通的，搞了半天才弄明白。

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/47.html