为什么这第一个iptables规则不匹配重复的连接尝试?

试图减轻我的盒子上的SSH暴力攻击,我复制/粘贴下列规则到我的iptables (没有真正理解他们,我必须承认):

 $> iptables-save # Generated by iptables-save v1.4.14 on Wed Jun 11 15:13:01 2014 *filter :INPUT ACCEPT [1255:139338] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1099:174390] -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -m recent --rcheck --seconds 60 --hitcount 5 --rttl --name SSH --rsource -j LOG --log-prefix "[iptables] SSH brute-force " -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset COMMIT # Completed on Wed Jun 11 15:13:01 2014 

令我高兴的是,它按预期工作(重复的连接尝试被拒绝,而合法的尝试通过)。 我认识到还有其他方法可以达到同样的效果: 例1 , 例2 。

我(相信我)了解其他方法是如何工作的,但是我不明白上面的第一条规则是如何匹配“ 未经追踪的新来的连接”的。

这与我从手册中了解的内容相矛盾:

--set:这将永远返回成功

这个规则是什么使它匹配重复的连接尝试? 我假设第一个规则不匹配重复的连接尝试,否则后续规则永远不会踢。

我希望任何新的传入连接匹配此规则。

在其他例子中,他们没有提到目标-j ACCEPT

 -A INPUT (...) -m state --state NEW -m recent --set --name SSH --rsource 

所以也许我的问题可以改写:

--set --name [some_name]一起使用时, -j选项是无用的吗?


根据要求,以下是iptables -L -n -v (从/到localhost的ssh'ing,因为我现在只有远程访问)的结果:

初始状态:

 Chain INPUT (policy ACCEPT 895 packets, 101K bytes) pkts bytes target prot opt in out source destination 18 1080 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: SET name: SSH side: source 19 962 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 recent: CHECK seconds: 60 hit_count: 5 TTL-Match name: SSH side: source LOG flags 0 level 4 prefix "[iptables] SSH brute-force " 19 962 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 recent: UPDATE seconds: 60 hit_count: 5 TTL-Match name: SSH side: source reject-with tcp-reset Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 776 packets, 119K bytes) pkts bytes target prot opt in out source destination 

尝试#4之后:

 Chain INPUT (policy ACCEPT 1040 packets, 121K bytes) pkts bytes target prot opt in out source destination 22 1320 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: SET name: SSH side: source 19 962 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 recent: CHECK seconds: 60 hit_count: 5 TTL-Match name: SSH side: source LOG flags 0 level 4 prefix "[iptables] SSH brute-force " 19 962 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 recent: UPDATE seconds: 60 hit_count: 5 TTL-Match name: SSH side: source reject-with tcp-reset Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 911 packets, 141K bytes) pkts bytes target prot opt in out source destination 

尝试#5(被拒绝)后:

 Chain INPUT (policy ACCEPT 1063 packets, 122K bytes) pkts bytes target prot opt in out source destination 23 1380 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: SET name: SSH side: source 21 1054 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 recent: CHECK seconds: 60 hit_count: 5 TTL-Match name: SSH side: source LOG flags 0 level 4 prefix "[iptables] SSH brute-force " 21 1054 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 recent: UPDATE seconds: 60 hit_count: 5 TTL-Match name: SSH side: source reject-with tcp-reset Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 933 packets, 144K bytes) pkts bytes target prot opt in out source destination 

logging“攻击”:

 Jun 11 15:07:02 [hostname_hidden] kernel: [249278.516231] [iptables] SSH brute-force IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=59245 DF PROTO=TCP SPT=36129 DPT=22 WINDOW=0 RES=0x00 RST URGP=0 Jun 11 15:07:18 [hostname_hidden] kernel: [249294.514964] [iptables] SSH brute-force IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=59246 DF PROTO=TCP SPT=36129 DPT=22 WINDOW=0 RES=0x00 RST URGP=0 

在我看来,答案在于数据包的数量和规则的细节。 具体来说,在尝试5时, 两个规则集( ACCEPTLOG / REJECT对)的计数递增。

我怀疑,试图5, 初始 SYN数据包匹配ACCEPT规则,并且都是ACCEPT和冲突的计数。 但是由于计数已经被ACCEPT SYN分组递增,所以新build立的连接中的后续分组现在匹配后面的LOG / REJECT对,因此被拒绝。 日志有助于确认这个视图,因为您将看到REJECT ed数据包都没有设置SYN标志。