UFW Ermöglicht 22 für IPv4 und IPv6, aber SSH trennt die Verbindung beim Aktivieren

sudo ufw disablegefolgt von sudo ufw enabletritt mich aus SSH

DMESG-Berichte

[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

Ich kann mich wieder anmelden, ohne die Regeln über die Konsole ändern zu müssen (UFW ist weiterhin aktiviert).

Dies begann nach dem Upgrade von Xenial (16.04) von Kernel 4.4 auf 4.15 (HWE). Ein Upgrade auf 18.04.1 hat das Problem nicht behoben.

Versionen:

iptables v1.6.1
ufw 0,35
4.15.0-29-generic # 31-Ubuntu
Ubuntu 18.04.1 LTS

Der UFW-Status ist ausführlich (einige Regeln wurden weggelassen, aber alle sind ERLAUBT)

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)

Warum passiert dies oder wie kann man zumindest zum erwarteten Verhalten zurückkehren?

Ich habe mir diese Antwort angesehen und bin mir nicht sicher, ob sie zutrifft, aber hier ist /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: Ich habe nicht erwartet, dass dies das Problem "behebt", aber nur als Referenz habe ich den Port geändert, den SSHD abhört (und die entsprechende Regel), und das Problem bleibt bestehen.

— Gaia
quelle

Also funktioniert alles so, wie es sollte, außer dass Sie vorübergehend von der SSH-Sitzung getrennt werden, wenn Sie die Firewall aus- und wieder einschalten?

— Bernard Wei

ja, momentan wie drin trennt sich und ich muss mich wieder verbinden. es bleibt nicht "nur" stehen

— Gaia

Dies ist sehr seltsam, da das Aktivieren / Deaktivieren über ufw erst nach dem Neustart wirksam werden sollte. Sie können mithilfe des systemctl-Status ufw überprüfen, ob dieser noch ausgeführt wird (oder nicht ausgeführt wird), wenn diese Befehle ausgegeben werden.

— Bernard Wei

Dies scheint eine Kernel-Regression zu sein und scheint zwischen den Kerneln 4.13 und 4.14 eingeführt worden zu sein. Ich mache jetzt eine Kernelhalbierung. Es wird ein oder zwei Tage dauern. Wenn ein Leser den Schuldigen bereits kennt, posten Sie bitte hier, damit ich keine Zeit verschwenden kann.

— Doug Smythies

Noch keine Fehlernummer, ich habe gerade die Kernelhalbierung beendet. 4d3a57f23dec59f0a2362e63540b2d01b37afe0a Netzfilter: conntrack: Aktivieren Sie die Verbindungsverfolgung nur, wenn dies erforderlich ist. Gib mir ein paar Stunden und ich werde eine Antwort schreiben.

— Doug Smythies

Hintergrund und Grenzen des Problems:

Das Problem tritt nur auf, wenn UFW oder iptables mit diesen SSH-Zulassungsregeln aktiviert und eine SSH-Sitzung gestartet wird. dh Jede SSH-Sitzung, die überhaupt ohne iptables gestartet wurde, funktioniert einwandfrei, kann jedoch nach dem Einrichten des Regelsatzes zufälligen Ausfällen unterliegen.
Denken Sie daran, dass ufw lediglich ein Frontend für iptables ist.
Das Problem ist auch mit Kernel 4.18-rc8 vorhanden.

Was ist los?

Die sudo ufw allow in port 22Ergebnisse im folgenden iptables-Regelsegment:

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

Im sudo ufw disableAnschluss daran sudo ufw enableund obwohl die SSH-Verbindung selbst in Ordnung bleibt, scheint der resultierende iptables-Regelsatz die Zuordnung zu dieser bestimmten Verbindung vergessen zu haben und klassifiziert daher alle eingehenden Pakete als ungültig. Irgendwie ist die Verbindungsverfolgungstabelle verwirrt und das Paket wird nicht einmal als NEU betrachtet, sondern mit falschen Flags, noch wird es als Teil der bestehenden Verbindung betrachtet.

Betrachten Sie ein sehr einfaches iptables-Äquivalent zu dem, was ufwgerade getan wird. Zwei Skripte, eines zum Löschen des Regelsatzes und eines zum Erstellen:

#!/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.

Und:

#!/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

Das Ergebnis dieser Pakete zählt nach einem Lösch- / Ladezyklus mit einer SSH-Sitzung, die nach einem Ladezyklus gestartet wurde:

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

Beachten Sie die 35 ungültigen Pakete, die ich auf dem verkrüppelten SSH-Sitzungsterminal und vor dem Beenden von PuTTY eingegeben habe.

Warum hat das aufgehört zu funktionieren, es hat früher funktioniert?

Da dies zu 100% wiederholbar ist, war eine Kernhalbierung relativ einfach und nur zeitaufwändig. Die Ergebnisse waren:

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>

Link zum gesamten Commit.

Wie kann man zum erwarteten Verhalten zurückkehren?

Erstellen Sie nach dem Deaktivieren von ufw oder dem Löschen des iptables-Regelsatzes eine neue SSH-Sitzung. Es überlebt eine nachfolgende ufw-Aktivierung, kann jedoch irgendwann einem zufälligen Ausfall unterliegen.

Dieses Problem wird irgendwann über die zugehörige E-Mail-Liste vorgelagert.

BEARBEITEN: Upstream-E-Mail-Thread (enthält eine Problemumgehung). Problemumgehung hier kopiert:

echo 1 | sudo tee /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal

EDIT 2: Upstream vorgeschlagener Patch , den ich getestet und zurückgemeldet habe.

EDIT 3: 2018.11.06: Dies ist stromaufwärts ins Stocken geraten, und ich hatte keine Zeit, sie zu belästigen. Ich werde versuchen, bald darauf zurückzukommen.

EDIT 4: 2019.03.17: Ich kann dieses Problem mit Kernel 5.0 nicht zuverlässig reproduzieren.

— Doug Smythies
quelle

Das Problem besteht auch mit Kernel 4.18-rc8. Es besteht eine Beziehung zwischen dem Auftreten des Problems und der Frage, ob die Warteschlange für eine SSH-Sitzung leer ist oder nicht. Nein, diese Minderung ist nicht die Lösung. Ich brauche mehr Zeit.

— Doug Smythies

OK danke. Ich muss einige Änderungen an der Antwort vornehmen, weiß aber nicht wann. Hier gibt es mehrere Probleme. Ich bin auf dem Weg durch eine zweite Kernelhalbierung, die sich nur auf iptables bezieht. Ich versuche, UFW aus dem Problem zu entfernen. Die Dinge sind ein bisschen chaotisch (meine Meinung), und das Conntrak-Tool ist im Grunde wegen des ersten Commits, das ich gefunden habe, kaputt. Ich werde flussaufwärts gehen, sobald ich genügend Details dazu habe.

— Doug Smythies

@Gaia Wenn Sie vergeben nicht die volle Prämie dann nur 50% davon bekommen Doug wird IF zwei bis-Stimmen sind. Derzeit gibt es nur eine Up-Vote, daher füge ich eine weitere hinzu, teilweise für 50% Kopfgeld-Sicherheit, aber hauptsächlich, weil es eine ausgezeichnete Antwort ist.

— WinEunuuchs2Unix

@Gaia: Ich kann nur annehmen, dass Ihr Problem in irgendeiner Weise mit einigen Ihrer UFW-Regeln zusammenhängt. Ich habe eine Upstream-E-Mail gesendet (sie haben kein Fehlersystem), aber ich habe UFW vollständig entfernt und beziehe mich nur auf iptables. Da ich nicht auf dieser bestimmten E-Mail-Liste stehe und sie noch nicht im Archiv sehe, gehe ich davon aus, dass sie zur Moderation gehalten wird. Ich werde einen Link bereitstellen, sobald dieser verfügbar ist.

— Doug Smythies

@ Gaia: Ich kann nicht spekulieren. Alles was ich weiß ist, dass nur mit den SSH-Regeln UFW aktiviert ist und dann die SSH-Verbindung neu gestartet wird, zumindest für mich. Es wird bei einer nachfolgenden Deaktivierung / Aktivierung von UFW gelöscht.

— Doug Smythies