☰

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

tag-icon • tag-icon iptables
为什么第一个 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

因此我的问题或许可以重新表述为：

-j与 一起使用时该选项是否无用--set --name [some_name]？

iptables -L -n -v根据要求，以下是（从/到本地主机 ssh，因为我现在只有远程访问）的结果：

初始状态：

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

第四次尝试后：

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

“攻击”日志：

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

答案1

在我看来，答案就在数据包计数和规则的细节中。具体来说，在第 5 次尝试中，计数两个都规则集（ACCEPT， 和LOG/REJECT对）会增加。

我怀疑，在第五次尝试中，最初的 SYN数据包与规则匹配ACCEPT，并且被ACCEPTed 并增加计数。但由于计数已被该ACCEPTedSYN数据包增加，随后的新建立的连接中的数据包现在与后面的LOG/REJECT对匹配，因此被拒绝。日志有助于证实这一观点，因为您将看到两个REJECTed 数据包都没有SYN设置标志。

相关内容