sudo ufw disable
seguido por sudo ufw enable
me echa de SSH
DMESG informa
[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
Puedo volver a iniciar sesión sin tener que cambiar las reglas a través de la consola (UFW todavía está habilitado).
Esto comenzó después de actualizar Xenial (16.04) del kernel 4.4 a 4.15 (HWE). La actualización a 18.04.1 no resolvió el problema.
Versiones
- iptables v1.6.1
- ufw 0.35
- 4.15.0-29-genérico # 31-Ubuntu
- Ubuntu 18.04.1 LTS
El estado de UFW es detallado (se omitieron algunas reglas, pero todas están PERMITIDAS)
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)
¿Por qué sucede esto, o al menos, cómo volver al comportamiento esperado?
Miré esta respuesta , y no estoy seguro de que se aplique, pero aquí está /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
PD: No esperaba que esto "solucionara" el problema, pero solo como referencia, cambié el puerto en el que escucha SSHD (y la regla correspondiente) y el problema persiste.
Respuestas:
Antecedentes y límites del problema:
Que esta pasando?
Los
sudo ufw allow in port 22
resultados en el siguiente segmento de reglas de iptables:Una vez
sudo ufw disable
seguidosudo ufw enable
, y aunque la conexión ssh en sí misma permanece bien, el conjunto de reglas iptables resultante parece haber olvidado la asociación con esa conexión en particular y, por lo tanto, clasifica los paquetes entrantes como no válidos. De alguna manera, la tabla de seguimiento de la conexión se ha confundido y el paquete ni siquiera se considera NUEVO, sino con indicadores incorrectos, ni se considera parte de la conexión existente.Considere un equivalente de iptables muy básico de lo que
ufw
está haciendo. Dos scripts, uno para borrar el conjunto de reglas y otro para crearlo:Y:
Como resultado, estos paquetes cuentan después de un ciclo de limpieza / carga con una sesión ssh que se inició después de un ciclo de carga:
Observe los 35 paquetes no válidos mientras escribía en el terminal de sesión ssh paralizado, y antes de que PuTTY terminara.
¿Por qué esto dejó de funcionar, solía funcionar?
Debido a que esto es 100% repetible, una bisección del núcleo fue relativamente fácil, solo tomó mucho tiempo. Los resultados fueron:
Enlace a todo el commit.
¿Cómo volver al comportamiento esperado?
Después de deshabilitar ufw o borrar el conjunto de reglas de iptables, cree una nueva sesión SSH. Sobrevivirá una habilitación posterior de ufw, pero podría estar sujeto a un abandono aleatorio en algún momento.
Este problema se abordará en algún momento, a través de la lista de correo electrónico relacionada.
EDITAR: hilo de correo electrónico ascendente (contiene una solución alternativa). Solución alternativa copiada aquí:
EDIT 2: parche propuesto aguas arriba , que he probado e informado.
EDIT 3: 2018.11.06: Esto se ha estancado río arriba, y no he tenido tiempo de molestarlos. Intentaré volver pronto.
EDIT 4: 2019.03.17: No puedo reproducir de manera confiable este problema con el kernel 5.0.
fuente