![为什么第一个 iptables 规则不匹配重复的连接尝试?](https://linux22.com/image/634712/%E4%B8%BA%E4%BB%80%E4%B9%88%E7%AC%AC%E4%B8%80%E4%B8%AA%20iptables%20%E8%A7%84%E5%88%99%E4%B8%8D%E5%8C%B9%E9%85%8D%E9%87%8D%E5%A4%8D%E7%9A%84%E8%BF%9E%E6%8E%A5%E5%B0%9D%E8%AF%95%EF%BC%9F.png)
为了缓解 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
,并且被ACCEPT
ed 并增加计数。但由于计数已被该ACCEPT
edSYN
数据包增加,随后的新建立的连接中的数据包现在与后面的LOG
/REJECT
对匹配,因此被拒绝。日志有助于证实这一观点,因为您将看到两个REJECT
ed 数据包都没有SYN
设置标志。