作者:高张远瞩(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次。
命令:
1
2
|
-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论坛上看到另一个版本的命令,作者保证是从服务器上复制下来的,肯定能用:
1
2
|
-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一下就明白了:
1
2
|
-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,结果因为前面有一句
1
|
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
|
结果ping一直是通的,搞了半天才弄明白。