UFW consente 22 per IPv4 e IPv6 ma SSH si disconnette durante l'abilitazione

10

sudo ufw disableseguito da sudo ufw enablecalci fuori da SSH

Rapporti 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

Posso accedere di nuovo senza dover cambiare le regole tramite la console (UFW ancora abilitato).

Questo è iniziato dopo aver aggiornato Xenial (16.04) dal kernel 4.4 a 4.15 (HWE). L'aggiornamento a 18.04.1 non ha risolto il problema.

versioni:

  • iptables v1.6.1
  • uww 0.35
  • 4.15.0-29-generic # 31-Ubuntu
  • Ubuntu 18.04.1 LTS

Lo stato UFW è dettagliato (alcune regole sono state omesse, ma sono tutte CONSENTI)

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)

Perché sta succedendo, o almeno, come ripristinare il comportamento previsto?

Ho esaminato questa risposta e non sono sicuro che si applichi, ma ecco /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: Non mi aspettavo che questo "risolvesse" il problema, ma solo per riferimento ho cambiato la porta su cui SSHD è in ascolto (e la regola corrispondente) e il problema persiste.

kernel  ssh  18.04  firewall  ufw 
— Gaia
fonte
Quindi tutto funziona come dovrebbe, tranne per il fatto che si esce momentaneamente dalla sessione ssh quando si spegne e si riaccende il firewall?
— Bernard Wei, il
sì, momentaneamente come in esso si disconnette e devo riconnettermi. non "solo" si blocca
— Gaia,
Questo è molto strano perché l'abilitazione / disabilitazione tramite ufw dovrebbe entrare in vigore solo dopo il riavvio. Puoi controllare usando lo stato systemctl ufw per vedere che è ancora in esecuzione (o non in esecuzione) quando vengono emessi quei comandi.
— Bernard Wei,
2
Questa sembra essere una regressione del kernel e sembra essere stata introdotta tra i kernel 4.13 e 4.14. Sto facendo una bisection del kernel ora. Ci vorranno un giorno o due. Se qualche lettore conosce già l'impegno del colpevole, pubblica qui in modo da non perdere tempo.
— Doug Smythies,
1
Nessun numero di bug ancora, ho appena finito la bisection del kernel. 4d3a57f23dec59f0a2362e63540b2d01b37afe0a netfilter: conntrack: non abilitare il tracciamento della connessione se non necessario. Dammi qualche ora e scriverò una risposta.
— Doug Smythies,

Risposte:

9

Contesto e limiti del problema:

  • Il problema si verifica solo quando UFW o iptables, con queste regole di autorizzazione ssh, sono abilitati e viene avviata una sessione ssh. vale a dire qualsiasi sessione SSH che è stata avviata senza iptables funziona correttamente, ma può essere soggetta a dropout casuali una volta che il set di regole è stato messo in atto.
  • ricorda che uww è semplicemente un front-end per iptables.
  • Il problema è presente anche con il kernel 4.18-rc8.

Cosa sta succedendo?

I sudo ufw allow in port 22risultati nel seguente segmento delle regole 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

Su sudo ufw disableseguito da sudo ufw enable, e anche se la connessione ssh stessa rimane soddisfacente, iptables risultanti regola insieme sembra aver dimenticato l'associazione con quel particolare connessione e quindi classifica eventuali pacchetti in ingresso come valido. In qualche modo la tabella di tracciamento della connessione è diventata confusa e il pacchetto non è nemmeno considerato NUOVO, ma con flag errati, né è considerato parte della connessione esistente.

Considera un equivalente iptables di base di ciò che ufwsta facendo. Due script, uno per cancellare il set di regole e uno per crearlo:

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

E:

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

Il risultato di questi pacchetti conta dopo un ciclo di cancellazione / caricamento con una sessione ssh che è stata avviata dopo un ciclo di caricamento:

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

Notare i 35 pacchetti non validi durante la digitazione sul terminale di sessione ssh paralizzato e prima che PuTTY terminasse.

Perché questo ha smesso di funzionare, funzionava?

Poiché questo è ripetibile al 100%, una bisection del kernel era relativamente semplice, richiedendo solo tempo. I risultati furono:

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>

Collegamento a tutto il commit.

Come ripristinare il comportamento previsto?

Dopo aver disabilitato ufw o aver cancellato il set di regole iptables, creare una nuova sessione SSH. Sopravviverà ad una successiva abilitazione uww, ma potrebbe essere soggetto a un abbandono casuale a un certo punto.

Questo problema verrà portato a monte ad un certo punto, tramite la relativa lista e-mail.

EDIT: thread di e-mail upstream (contiene un work around). Soluzione alternativa copiata qui:

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

EDIT 2: patch proposta a monte , che ho testato e riportato indietro.

EDIT 3: 2018.11.06: Questo si è bloccato a monte e non ho avuto il tempo di assillarli. Proverò a tornarci presto.

EDIT 4: 2019.03.17: Non riesco a riprodurre in modo affidabile questo problema con il kernel 5.0.

— Doug Smythies
fonte
1
Il problema persiste anche con il kernel 4.18-rc8. Esiste una relazione tra se il problema si verificherà o meno in base al fatto che la coda di una sessione ssh sia vuota o meno. No, quella mitigazione non è la soluzione. Ho bisogno di più tempo.
— Doug Smythies,
1
Ok grazie. Devo apportare alcune modifiche alla risposta, ma non so quando. Ci sono più problemi qui. Sto attraversando una seconda sezione del kernel, relativa solo a iptables. Sto cercando di eliminare UFW dal problema. Le cose sono un po 'un casino (la mia opinione), e lo strumento conntrak è sostanzialmente rotto a causa del primo commit che ho trovato. Andrò a monte una volta che avrò i dettagli sufficienti per farlo.
— Doug Smythies,
1
@Gaia Se non assegni la taglia completa, Doug riceverà solo il 50% di essa SE ci sono due voti positivi . Attualmente c'è solo un voto positivo, quindi ne sto aggiungendo un altro in parte per il 50% di garanzia di taglie, ma soprattutto perché è un'ottima risposta.
— WinEunuuchs2Unix
1
@Gaia: posso solo supporre che il tuo problema sia in qualche modo correlato ad altre tue regole UFW. Ho inviato un'e-mail a monte (non hanno un sistema di bug), ma ho eliminato completamente UFW e mi riferisco solo a iptables. Dal momento che non sono in quella particolare lista e-mail e non la vedo ancora nell'archivio, presumo che sia trattenuto per moderazione. Fornirò un collegamento una volta disponibile.
— Doug Smythies,
1
@Gaia: non posso speculare. Tutto quello che so è che, con solo le regole SSH, UFW abilitato e quindi riavviare la connessione SSH funziona bene, almeno per me. Viene rilasciato dopo una successiva disabilitazione / abilitazione UFW.
— Doug Smythies,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.