sudo ufw disable
然后sudo ufw enable
将我踢出 SSH
DMESG 报告
[UFW BLOCK] IN=eth0 OUT= MAC=30:........ SRC=192.168.1.me DST=192.168.1.server LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=15776 DF PROTO=TCP SPT=55640 DPT=22 WINDOW=253 RES=0x00 ACK URGP=0
我可以重新登录,而无需通过控制台更改规则(UFW 仍然启用)。
在将 Xenial (16.04) 从内核 4.4 升级到 4.15 (HWE) 后,这个问题就开始出现了。升级到 18.04.1 并没有解决这个问题。
版本:
- iptables v1.6.1
- 0.35 UFW
- 4.15.0-29-通用#31-Ubuntu
- Ubuntu 18.04.1 LTS
UFW 状态详细为(省略了一些规则,但它们都是允许的)
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22 ALLOW IN Anywhere
22 (v6) ALLOW IN Anywhere (v6)
为什么会发生这种情况,或者至少,如何恢复到预期的行为?
我在看这个答案,我不确定它是否适用,但这是 /etc/ufw/before.rules
#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
# ufw-before-input
# ufw-before-output
# ufw-before-forward
#
# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines
# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT
# quickly process packets for which we already have a connection
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# drop INVALID packets (logs these in loglevel medium and higher)
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
# ok icmp codes for INPUT
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT
# ok icmp code for FORWARD
-A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type source-quench -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT
# allow dhcp client to work
-A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT
#
# ufw-not-local
#
-A ufw-before-input -j ufw-not-local
# if LOCAL, RETURN
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
# if MULTICAST, RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
# if BROADCAST, RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
# all other non-local packets are dropped
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT
# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT
# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT
附言:我没想到这能“解决”这个问题,但仅供参考,我改变了 SSHD 监听的端口(和相应的规则),但问题仍然存在。
答案1
问题的背景和界限:
- 仅当启用具有这些 ssh 允许规则的 UFW 或 iptables 并启动 ssh 会话时,才会发生此问题。即,任何在没有 iptables 的情况下启动的 SSH 会话都可以正常工作,但是一旦规则集到位,可能会随机中断。
- 回想一下,ufw 仅仅是 iptables 的前端。
- 即使内核为 4.18-rc8,该问题仍然存在。
到底是怎么回事?
sudo ufw allow in port 22
以下 iptables 规则段中的结果:
Chain ufw-before-input (1 references)
pkts bytes target prot opt in out source destination
16 1553 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
386 300622 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
15 1068 ufw-logging-deny all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
15 1068 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
之后sudo ufw disable
,sudo ufw enable
尽管 ssh 连接本身仍然正常,但生成的 iptables 规则集似乎忘记了与该特定连接的关联,因此将任何传入数据包归类为无效。不知何故,连接跟踪表变得混乱,数据包甚至不被视为新数据包,而是带有不正确的标志,也不被视为现有连接的一部分。
考虑一个非常基本的 iptables 等效程序ufw
。两个脚本,一个用于清除规则集,一个用于创建规则集:
#!/bin/sh
FWVER=0.01
#
# clear_firewall_min 2018.08.10 Ver:0.01
# clear iptables minimum.
# Currently for this question:
# https://askubuntu.com/questions/1059781/ufw-allows-22-for-ipv4-and-ipv6-but-ssh-disconnects-when-enabling
#
echo "Loading clear_firewall_min version $FWVER..\n"
# The location of the iptables program
#
IPTABLES=/sbin/iptables
#Set some stuff
#
EXTIF="ens5"
UNIVERSE="0.0.0.0/0"
#Clearing any previous configuration
#
echo " Clearing any existing rules and setting default policies.."
$IPTABLES -P INPUT ACCEPT
$IPTABLES -F INPUT
# Reset all IPTABLES counters
$IPTABLES -Z
#sleep 10
echo clear_firewall_min $FWVER done.
和:
#!/bin/sh
#
# test_firewall 2018.08.13 Ver:0.01
# Minimum version of most basic iptables firewall.
#
# test_firewall 2018.08.09 Ver:0.01
# Most basic iptables firewall.
# Currently for this question:
# https://askubuntu.com/questions/1059781/ufw-allows-22-for-ipv4-and-ipv6-but-ssh-disconnects-when-enabling
#
#sleep 50
# The location of the iptables program
#
IPTABLES=/sbin/iptables
#Set some stuff
#
EXTIF="ens5"
UNIVERSE="0.0.0.0/0"
#Clearing any previous configuration
#
#echo " Clearing any existing rules and setting default policies.."
$IPTABLES -P INPUT DROP
$IPTABLES -F INPUT
# loopback interfaces are valid.
#
$IPTABLES -A INPUT -i lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT
$IPTABLES -A INPUT -i $EXTIF -p tcp -m conntrack --ctstate INVALID -j LOG --log-prefix "IINVALID:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -p tcp -m conntrack --ctstate INVALID -j DROP
$IPTABLES -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j LOG --log-prefix "NEW TCP no SYN:" --log-level info
$IPTABLES -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
$IPTABLES -A INPUT -i $EXTIF -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -i $EXTIF -p tcp -m conntrack --ctstate NEW --dport 22 -j ACCEPT
echo "test_firewall_min $FWVER done..." >> /dev/kmsg
sleep 3
在加载循环后启动的 ssh 会话经过清除/加载循环后,这些数据包会进行计数:
doug@s17:~$ sudo iptables -v -x -n -L
Chain INPUT (policy DROP 3 packets, 220 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
35 6388 LOG tcp -- ens5 * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID LOG flags 0 level 6 prefix "IINVALID:"
35 6388 DROP tcp -- ens5 * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 ctstate NEW LOG flags 0 level 6 prefix "NEW TCP no SYN:"
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 ctstate NEW
9 680 ACCEPT all -- ens5 * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp -- ens5 * 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:22
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 12 packets, 1408 bytes)
pkts bytes target prot opt in out source destination
请注意,当我在损坏的 ssh 会话终端上输入时,以及在 PuTTY 终止之前,有 35 个无效数据包。
它以前是可以工作的,为什么现在停止工作了?
由于这是 100% 可重复的,因此核二分相对容易,只是耗时。结果是:
4d3a57f23dec59f0a2362e63540b2d01b37afe0a is the first bad commit
commit 4d3a57f23dec59f0a2362e63540b2d01b37afe0a
Author: Florian Westphal <[email protected]>
Date: Fri Jul 28 11:22:04 2017 +0200
netfilter: conntrack: do not enable connection tracking unless needed
Discussion during NFWS 2017 in Faro has shown that the current
conntrack behaviour is unreasonable.
Even if conntrack module is loaded on behalf of a single net namespace,
its turned on for all namespaces, which is expensive. Commit
481fa373476 ("netfilter: conntrack: add nf_conntrack_default_on sysctl")
attempted to provide an alternative to the 'default on' behaviour by
adding a sysctl to change it.
However, as Eric points out, the sysctl only becomes available
once the module is loaded, and then its too late.
So we either have to move the sysctl to the core, or, alternatively,
change conntrack to become active only once the rule set requires this.
This does the latter, conntrack is only enabled when a rule needs it.
Reported-by: Eric Dumazet <[email protected]>
Signed-off-by: Florian Westphal <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
关联整个提交。
如何恢复预期行为?
禁用 ufw 或清除 iptables 规则集后,创建一个新的 SSH 会话。它将在后续 ufw 启用后继续存在,但可能会在某个时候随机中断。
该问题将在某个时间点通过相关电子邮件列表向上游解决。
编辑:上游电子邮件线程(包含解决方法)。解决方法复制到此处:
echo 1 | sudo tee /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
编辑2:上游建议的补丁,我已测试并报告。
编辑 3:2018.11.06:这已停滞在上游,我还没来得及打扰他们。我会尽快回复。
编辑 4:2019.03.17:我无法使用内核 5.0 可靠地重现此问题。