UFWはIPv4とIPv6に対して22を許可しますが、有効にするとSSHが切断します
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
- ufw 0.35
- 4.15.0-29-generic＃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
PS：これが問題を「修正」することを期待していませんでしたが、参考のために、SSHDがリッスンするポート（および対応するルール）を変更しましたが、問題は続きます。
背景、および問題の範囲：
- この問題は、これらの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ルールセットはその特定の接続との関連付けを忘れているため、着信パケットを無効として分類します。どういうわけか、接続追跡テーブルは混乱しており、パケットは新規とは見なされませんが、フラグが正しくありません。また、既存の接続の一部とも見なされません。
ufwが行っていることに相当する非常に基本的なiptablesを考えてください。ルールセットのクリア用と作成用の2つのスクリプト：
#!/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： 上流の提案されたパッチ 、これをテストして報告しました。
EDIT 3：2018.11.06：これはアップストリームで行き詰まっており、私はそれらを悩ませる時間がありませんでした。私はすぐにそれに戻ろうとします。
編集4：2019.03.17：カーネル5.0でこの問題を確実に再現できません。