UFWはIPv4およびIPv6に対して22を許可しますが、有効にするとSSHが切断されます


10

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による有効化/無効化は、再起動後にのみ有効になるため、これは非常に奇妙です。systemctl status ufwを使用して、これらのコマンドが発行されたときにがまだ実行されている(または実行されていない)ことを確認できます。
バーナードウェイ

2
これはカーネル退行のようで、カーネル4.13と4.14の間に導入されたようです。現在、カーネルの二分法を行っています。1〜2日かかります。読者が犯人のコミットをすでに知っている場合は、時間を無駄にしないようにここに投稿してください。
Doug Smythies 2018

1
まだバグ番号はありません。カーネルの二分割を終えたところです。4d3a57f23dec59f0a2362e63540b2d01b37afe0a netfilter:conntrack:必要がない限り、接続追跡を有効にしないでください。数時間ください。返事を書きます。
Doug Smythies 2018

回答:


9

背景と問題の境界:

  • この問題は、これらの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ルールセットはその特定の接続との関連付けを忘れているため、着信パケットを無効として分類します。どういうわけか、接続追跡テーブルは混乱しており、パケットはNEWとは見なされていませんが、フラグが正しくないか、既存の接続の一部と見なされていません。

ufwをしているのと同等の非常に基本的なiptablesを検討してください。ルールセットをクリアするスクリプトと作成するスクリプトの2つのスクリプト:

#!/bin/sh
FWVER=0.01
#
# clear_firewall_min 2018.08.10 Ver:0.01
#       clear iptables minimum.
#       Currently for this question:
#       /ubuntu/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:
#       /ubuntu/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 <fw@strlen.de>
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 <edumazet@google.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

コミット全体にリンクします。

予想される動作に戻す方法は?

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ではこの問題を確実に再現できません。


1
この問題は、カーネル4.18-rc8でも引き続き発生します。sshセッションのキューが空かどうかに基づいて、問題が発生するかどうかに関係があります。いいえ、その緩和策は解決策ではありません。私にはもっと時間が必要です。
Doug Smythies 2018

1
わかりました。答えを変更する必要がありますが、いつなのかわかりません。ここには複数の問題があります。私は、iptablesのみに関連する2番目のカーネルの2分割の途中です。私は問題からUFWを排除しようとしています。物事は少し混乱しています(私の意見)。conntrakツールは、最初に見つけたコミットのために基本的に壊れています。十分な詳細があれば、アップストリームに行きます。
Doug Smythies

1
@Gaiaあなたは完全な恵みを割り当てない場合、ダグはそれの50%を取得するのIF 2のアップ票があります。現在、賛成票は1つしかないので、50%の賞金保証のためにもう1つ追加しますが、それは優れた回答だからです。
WinEunuuchs2Unix 2018

1
@ガイア:私はあなたの問題が何らかの形であなたのUFWルールの他のいくつかに関連していると思います。アップストリームメールを送信しましたが(バグシステムはありません)、UFWを完全に排除し、iptablesのみを参照しました。私はその特定のメーリングリストに参加しておらず、アーカイブにもまだ表示されていないため、モデレートのために保留されていると思います。利用可能になり次第、リンクを提供します。
Doug Smythies、2018

1
@ガイア:私は推測することはできません。私が知っているのは、sshルールのみでUFWを有効にしてから、再起動ssh接続が正常に機能することです(少なくとも私にとっては)。後続のUFW無効化/有効化時にドロップされます。
Doug Smythies、2018
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.