UFW autorise 22 pour IPv4 et IPv6 mais SSH se déconnecte lors de l'activation

sudo ufw disablesuivi par sudo ufw enableme jette hors de SSH

Rapports 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

Je peux me reconnecter sans avoir à modifier les règles via la console (UFW toujours activé).

Cela a commencé après la mise à niveau de Xenial (16.04) du noyau 4.4 vers 4.15 (HWE). La mise à niveau vers 18.04.1 n'a pas résolu le problème.

Versions:

iptables v1.6.1
ufw 0,35
4.15.0-29-générique # 31-Ubuntu
Ubuntu 18.04.1 LTS

Le statut UFW est détaillé (certaines règles ont été omises, mais elles sont toutes AUTORISÉES)

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)

Pourquoi cela se produit-il, ou du moins, comment revenir au comportement attendu?

J'ai regardé cette réponse , et je ne suis pas sûr qu'elle s'applique, mais voici /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: Je ne m'attendais pas à ce que cela "corrige" le problème mais juste pour référence j'ai changé le port SSHD écoute (et la règle correspondante) et le problème persiste.

— Gaia
source

Donc, tout fonctionne comme il se doit, sauf que vous êtes momentanément abandonné de la session ssh lorsque vous désactivez puis réactivez le pare-feu?

— Bernard Wei

oui, momentanément comme dedans il se déconnecte et je dois me reconnecter. ça ne "décroche" pas

— Gaia

C'est très étrange car l'activation / désactivation via ufw ne devrait entrer en vigueur qu'après le redémarrage. Vous pouvez vérifier en utilisant systemctl status ufw pour voir qu'il est toujours en cours d'exécution (ou non) lorsque ces commandes sont émises.

— Bernard Wei

Cela semble être une régression du noyau et semble avoir été introduit entre les noyaux 4.13 et 4.14. Je fais une bissection du noyau maintenant. Cela prendra un jour ou deux. Si un lecteur connaît déjà le coupable, merci de poster ici pour ne pas perdre de temps.

— Doug Smythies

Pas encore de numéro de bug, je viens juste de terminer la bissection du noyau. 4d3a57f23dec59f0a2362e63540b2d01b37afe0a netfilter: conntrack: n'activez le suivi de connexion qu'en cas de besoin. Donnez-moi quelques heures et j'écrirai une réponse.

— Doug Smythies

Contexte et limites du problème:

Le problème se produit uniquement lorsque UFW, ou iptables, avec ces règles d'autorisation ssh, est activé et qu'une session ssh est démarrée. C'est-à-dire que toute session SSH qui a été démarrée sans iptables fonctionne très bien, mais peut être sujette à des abandons aléatoires une fois que le jeu de règles est mis en place.
rappelons que ufw est simplement un frontal pour iptables.
Le problème est présent même avec le noyau 4.18-rc8.

Que se passe-t-il?

Les sudo ufw allow in port 22résultats dans le segment de règles iptables suivant:

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

Après sudo ufw disablesuivi de sudo ufw enable, et même si la connexion ssh elle-même reste correcte, l'ensemble de règles iptables résultant semble avoir oublié l'association avec cette connexion particulière et classe donc tous les paquets entrants comme invalides. D'une manière ou d'une autre, la table de suivi des connexions est devenue confuse et le paquet n'est même pas considéré comme NOUVEAU, mais avec des indicateurs incorrects, ni considéré comme faisant partie de la connexion existante.

Considérez un équivalent iptables très basique de ce qui ufwse passe. Deux scripts, un pour effacer le jeu de règles et un pour le créer:

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

Et:

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

Le résultat de ces paquets compte après un cycle d'effacement / chargement avec une session ssh qui a été lancée après un cycle de chargement:

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

Remarquez les 35 paquets invalides que j'ai tapés sur le terminal de session ssh paralysé et avant la fin de PuTTY.

Pourquoi cela a-t-il cessé de fonctionner, il fonctionnait?

Parce que c'est 100% reproductible, une bissection du noyau était relativement facile, juste longue. Les résultats ont été:

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>

Lien vers l'intégralité du commit.

Comment revenir au comportement attendu?

Après avoir désactivé ufw ou effacé l'ensemble de règles iptables, créez une nouvelle session SSH. Il survivra à une activation ufw ultérieure, mais pourrait être sujet à une interruption aléatoire à un moment donné.

Ce problème sera repris en amont à un moment donné, via la liste de diffusion correspondante.

EDIT: fil de discussion en amont (contient une solution de contournement). Solution copiée ici:

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

EDIT 2: patch proposé en amont , que j'ai testé et rapporté.

EDIT 3: 2018.11.06: Cela a calé en amont, et je n'ai pas eu le temps de les harceler. J'essaierai d'y revenir bientôt.

EDIT 4: 2019.03.17: Je ne peux pas reproduire ce problème de manière fiable avec le noyau 5.0.

— Doug Smythies
source

Le problème persiste même avec le noyau 4.18-rc8. Il existe une relation entre si le problème se produira ou non, selon que la file d'attente pour une session ssh est vide ou non. Non, cette atténuation n'est pas la solution. J'ai besoin de plus de temps.

— Doug Smythies

OK merci. Je dois apporter quelques modifications à la réponse, mais je ne sais pas quand. Il y a plusieurs problèmes ici. Je suis à mi-chemin d'une deuxième bissection du noyau, liée aux iptables uniquement. J'essaie d'éliminer UFW du problème. Les choses sont un peu désordonnées (à mon avis), et l'outil conntrak est fondamentalement cassé à cause du premier commit que j'ai trouvé. J'irai en amont une fois que j'aurai suffisamment de détails pour le faire.

— Doug Smythies

@Gaia Si vous ne donnez pas la prime complète alors Doug ne Réussissez 50% de celui - ci IF , il y a deux up-voix. Actuellement, il n'y a qu'un seul vote positif, j'en ajoute un autre en partie pour une assurance de prime de 50%, mais principalement parce que c'est une excellente réponse.

— WinEunuuchs2Unix

@Gaia: Je peux seulement supposer que votre problème est en quelque sorte lié à d'autres règles UFW. J'ai envoyé un e-mail en amont (ils n'ont pas de système de bogue), mais j'ai complètement éliminé UFW, et ne me réfère qu'à iptables. Étant donné que je ne figure pas sur cette liste d'e-mails particulière et que je ne la vois pas encore dans les archives, je suppose qu'elle est conservée pour modération. Je fournirai un lien une fois disponible.

— Doug Smythies

@Gaia: Je ne peux pas spéculer. Tout ce que je sais, c'est qu'avec les règles ssh, UFW est activé, puis redémarrer la connexion ssh fonctionne bien, du moins pour moi. Il est abandonné lors d'une désactivation / activation UFW ultérieure.

— Doug Smythies