Cómo recuperar el acceso tras romper las reglas de ufw

Volver a entrar

Si ufw le ha bloqueado el acceso a su VPS, la forma de recuperar el acceso es usar la consola del proveedor o el modo de rescate, porque no existe ninguna solución mediante SSH una vez que la regla de bloqueo está activa. El kernel descarta el paquete antes de que sshd llegue a verlo, por lo que no hay ningún servicio al que conectarse ni nada que reparar a través de la red. Abra la consola en el panel de control del proveedor, inicie sesión en ese indicador y ejecute un comando.

sudo ufw disable

Debería ver Firewall stopped and disabled on system startup. Las conexiones SSH nuevas vuelven a funcionar en uno o dos segundos. No se pierde nada de lo que haya configurado: disable descarga las reglas del kernel y escribe ENABLED=no en /etc/ufw/ufw.conf, mientras las reglas permanecen en disco en /etc/ufw/user.rules, a la espera del siguiente ufw enable.

No reinicie el sistema esperando que eso lo solucione. ufw se inicia durante el arranque, por lo que ENABLED=yes hace que el mismo conjunto de reglas vuelva a cargarse antes de que la red esté disponible. Reiniciar no cambia nada en un bloqueo causado por ufw.

La consola necesita una contraseña que quizá no tenga

La consola web (VNC o serie) es un teclado conectado a la máquina. No es una ruta de red, por lo que ninguna regla del firewall puede bloquearla. Sí necesita un inicio de sesión local, y aquí es donde fallan las configuraciones que sólo usan claves: si nunca estableció una contraseña para su usuario sudo y el inicio de sesión de root está bloqueado, la consola muestra un aviso al que no puede responder. Establezca esa contraseña ahora, mientras aún tiene SSH: sudo passwd yourname. La mayoría de los paneles también permiten restablecer la contraseña de root, lo que normalmente obliga a reiniciar.

Si la consola no se puede usar, arranque el sistema de rescate del proveedor. Ejecuta un sistema operativo independiente con el disco desmontado, por lo que puede desactivar ufw desde fuera.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Ejecute primero lsblk, porque la partición root no siempre es /dev/vda1. Reinicie en el sistema normal. ufw seguirá desactivado hasta que lo habilite manualmente.

Secuencia mínima de recuperación

Trabaje en este orden. Los cuatro primeros pasos son seguros. El siguiente no lo es.

1. sudo ufw disable para descargar las reglas y recuperar el acceso.
2. sudo ufw show added para mostrar las reglas que añadió, en forma de los comandos que las agregaron. Esto funciona mientras ufw está inactivo, a diferencia de ufw status.
3. sudo sshd -T | grep -i '^port' para confirmar en qué puerto escucha realmente sshd. Muestra port 22, salvo que lo haya cambiado.
4. sudo ufw allow 22/tcp, usando el puerto real, para que la próxima activación no repita el bloqueo.
5. sudo ufw enable, después de programar primero una reversión. Esto se explica más adelante en esta página.

Qué hace realmente ufw reset

ufw reset es el último recurso, no el primer paso. Deshabilita el firewall, hace una copia de seguridad de cada archivo de reglas y restablece los valores predeterminados para denegar las conexiones entrantes y permitir las salientes. Muestra una línea de copia de seguridad por cada archivo:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

Después de un restablecimiento no queda ninguna regla de permiso. Por tanto, ejecútelo desde la consola y no mediante SSH, y añada la regla de SSH antes de volver a habilitar el firewall. Las copias de seguridad son archivos de texto sin formato. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 muestra cuáles eran las reglas anteriores. Así puede reconstruir un conjunto de reglas que no pretendía eliminar.

Dónde guarda ufw sus reglas

Leer los archivos es más fiable que intentar recordarlo. Cinco rutas contienen todo el estado:

• /etc/ufw/user.rules y /etc/ufw/user6.rules: las reglas que añadió, en el orden en que se evalúan.
• /etc/ufw/before.rules y /etc/ufw/after.rules, además de las variantes 6: el marco que ufw coloca alrededor de sus reglas, incluida la aceptación de conexiones establecidas y las reglas de loopback.
• /etc/default/ufw: las políticas predeterminadas y el interruptor IPV6.
• /etc/ufw/ufw.conf: ENABLED y el nivel de registro.
• /var/log/ufw.log: lo que se bloqueó una vez activado el registro.

ufw escribe una copia con marca de tiempo de un archivo antes de reescribirlo, por lo que ls /etc/ufw/ se llena con nombres como user.rules.20260813_101500. Ese es el historial para deshacer cambios. Conviene leerlo antes de empezar a revertir la configuración.

Para ver lo que está cargado en el kernel y no lo que aparece en el disco, use sudo ufw show raw, o sudo iptables -S y sudo ip6tables -S. En Ubuntu 22.04 y 24.04, esos comandos usan las versiones basadas en nft, por lo que sudo nft list ruleset muestra las mismas reglas con la sintaxis nueva.

¿Por qué ufw cerró mi sesión SSH al habilitarlo?

La política predeterminada para las conexiones entrantes es denegar. Si habilita ufw sin crear una regla para el puerto SSH, se bloquean todas las conexiones nuevas. ufw muestra una advertencia: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Responder y sin una regla que permita SSH es la causa más habitual de los problemas descritos en esta página.

La parte confusa es el retraso. /etc/ufw/before.rules acepta los paquetes con estado ESTABLISHED,RELATED antes de aplicar sus propias reglas, por lo que la sesión desde la que ejecutó el comando sigue funcionando con normalidad. El bloqueo sólo aparece en la siguiente conexión, que puede producirse varias horas después. Para entonces, el cambio del firewall ya no parece estar relacionado. Abra siempre una segunda sesión SSH y confirme que funciona antes de cerrar la primera.

¿Por qué dejaron de funcionar apt y DNS después de cambiar la política?

sudo ufw default deny outgoing bloquea las consultas DNS (sistema de nombres de dominio) salientes y HTTP saliente, por lo que la resolución de nombres deja de funcionar y las actualizaciones de paquetes se detienen. apt update informa Temporary failure resolving 'archive.ubuntu.com'. El acceso SSH entrante sigue funcionando porque sus respuestas están en estado ESTABLISHED y pasan las reglas del framework. Esto hace que el firewall parezca inocente, aunque sea la causa.

Si quiere una política que deniegue las conexiones salientes, permita lo que realmente necesita la máquina:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Sin la última regla, el reloj se desfasa. Un reloj incorrecto impide validar los certificados TLS (seguridad de la capa de transporte), por lo que curl empieza a fallar por las fechas y no por los puertos. Este síntoma aparece varios días después del cambio. Por eso, denegar las conexiones salientes es una política adecuada para máquinas que supervisa, no para un servidor que configura una sola vez.

¿Por qué mi regla de ufw nunca coincide?

ufw evalúa las reglas del usuario en orden y se detiene en la primera coincidencia. Un deny añadido después de un allow amplio nunca se aplica, porque la regla allow ya ha decidido el destino del paquete. Muestre el orden con números e inserte la regla en la posición necesaria.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp muestra las reglas que se escribirían y no cambia nada. Es la forma segura de revisar una regla antes de activarla.

Los perfiles de aplicación también pueden causar problemas. sudo ufw allow OpenSSH usa el perfil de /etc/ufw/applications.d/openssh-server, y ese perfil corresponde al puerto 22. Si sshd escucha en 2222, la regla abre un puerto que no utiliza ningún servicio y puede dejarle sin acceso, aunque el conjunto de reglas parezca correcto. Use el número de puerto después de cambiarlo. El resto de la sintaxis se explica en los conceptos básicos del firewall ufw para un VPS.

¿Por qué las reglas de IPv4 no explican lo que observo?

Porque la mitad del tráfico no usa IPv4. Ubuntu incluye IPV6=yes en /etc/default/ufw y ufw mantiene después un conjunto de reglas paralelo para IPv6 en /etc/ufw/user6.rules. Una regla escrita con una dirección IPv4, como ufw allow from 203.0.113.10 to any port 22, no crea ninguna regla para IPv6. Si su VPS tiene un registro AAAA, el cliente prefiere IPv6 y la conexión agota el tiempo de espera, aunque ufw status muestre una regla que parece correcta. Compruebe la diferencia con ssh -4 user@host frente a ssh -6 user@host. Si la primera funciona y la segunda no, el problema está en el conjunto de reglas de IPv6.

El caso inverso es más grave para la seguridad. Con IPV6=no, ufw no administra ip6tables en absoluto, por lo que la política de IPv6 mantiene el valor predeterminado del kernel, ACCEPT. Un puerto que cree cerrado responde en su dirección IPv6 y ningún comando de ufw lo mostrará. Compruébelo con sudo ip6tables -S y ss -tlnp, y consulte cómo gestiona ufw los puertos de IPv6 para conocer todos los detalles.

¿Por qué está abierto un puerto de Docker si ufw lo deniega?

Docker publica un puerto escribiendo reglas DNAT (traducción de direcciones de red de destino) en la tabla nat e insertando su propia cadena en FORWARD. Las reglas de ufw se encuentran en la ruta INPUT. El tráfico hacia un contenedor se reenvía en lugar de entregarse al host, por lo que nunca llega a la cadena donde está la regla de denegación. docker run -p 5432:5432 es accesible desde Internet aunque ufw esté activo y deniegue todo.

sudo iptables -t nat -S DOCKER

La solución más sencilla es publicar el puerto en loopback: -p 127.0.0.1:5432:5432 enlaza el lado del host con 127.0.0.1, y ningún sistema externo puede acceder a él, independientemente de lo que indique ufw. Publicación de puertos de Docker alrededor de ufw explica los casos en los que el servicio debe ser público.

Programa la reversión antes de aplicar la regla

Este es el hábito que permite trabajar con el firewall sin quedar bloqueado. Antes de cualquier cambio arriesgado, programa la operación para deshacerlo. Si el cambio te deja sin acceso, la máquina se recupera sola en cinco minutos y no necesitas abrir la consola.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd muestra Running timer as unit: ufw-rollback.timer. Ahora realiza el cambio. Si todavía puedes abrir una nueva sesión SSH después, cancela la reversión:

sudo systemctl stop ufw-rollback.timer

Si no puedes abrir esa sesión, espera. ufw se detiene por sí solo y el siguiente intento podrá conectarse. El truco clásico de shutdown -r +5 no funciona con ufw porque ufw vuelve a cargar el mismo conjunto de reglas durante el arranque.

Mantenga una segunda vía de acceso

• Inicie sesión una vez en la consola del proveedor, antes de necesitarla, y confirme que la contraseña funciona. Una consola que nunca ha probado no es una copia de seguridad.
• Mantenga un segundo usuario con permisos sudo y su propia clave, para que un archivo authorized_keys dañado no le deje sin acceso.
• Compruebe si el proveedor ejecuta un firewall de red en el panel, independiente de ufw. Bloquea los mismos puertos, y ufw status nunca lo mencionará.
• No convierta ufw allow from <your home address> en su única regla de SSH si esa dirección es dinámica. El proveedor la cambia durante la noche y perderá el acceso.

El momento más económico para hacer todo esto es cuando el servidor está recién instalado, junto con las demás tareas de configuración descritas en los primeros diez minutos en un VPS nuevo.

Rechazado o agotado indica qué capa falló

Connection refused significa que un paquete llegó al servidor y que algo respondió con un restablecimiento TCP. La ruta de red funciona, por lo que sshd está detenido o escucha en otro puerto. Un firewall rara vez es la causa, porque ufw descarta las conexiones de forma predeterminada en lugar de rechazarlas.

Connection timed out significa que no regresó ninguna respuesta. Es el comportamiento característico de un descarte: ufw, un firewall de red del proveedor o una dirección incorrecta. Interpretar correctamente estos dos errores ahorra una hora de comprobaciones sin rumbo, y la diferencia entre una conexión rechazada y una conexión agotada permite resolver los casos restantes.

Activa el registro antes del siguiente cambio

sudo ufw logging on
sudo tail -f /var/log/ufw.log

Un paquete bloqueado aparece así:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 con tu propia dirección en SRC= demuestra que ufw es quien te bloquea, no la red ni sshd. En una imagen mínima sin rsyslog no existe /var/log/ufw.log, y las mismas líneas proceden de sudo journalctl -k | grep UFW. ufw limita la frecuencia de sus propias reglas de registro, por lo que la ausencia de una línea no demuestra que se haya permitido un paquete.

Si encuentra reglas que nunca añadió

Un conjunto de reglas que cambió por sí solo no indica un problema del firewall. Alguien con acceso a root lo modificó. Ejecute sudo grep ufw /var/log/auth.log para ver qué comandos de sudo se ejecutaron y con qué cuenta. Después, ejecute last para revisar los inicios de sesión cercanos a esa hora. Si las cuentas no corresponden a ninguna persona que conozca, deje de depurar el firewall y siga una lista de comprobación para un VPS comprometido. Volver a habilitar un firewall en un equipo que controla otra persona sólo oculta el problema.

Vuelva a ponerlo todo en su sitio

Cuando conozca la causa, vuelva a habilitar ufw de forma que el bloqueo no pueda repetirse. Permita el puerto SSH real, programe la reversión y habilite ufw. Después, abra una sesión SSH completamente nueva desde otro terminal y confirme que se conecta. Cierre la sesión en la que está trabajando sólo después de que la nueva sesión esté activa. Mantenga el registro habilitado durante un día, porque el registro muestra lo que olvidó permitir mucho más rápido que leer user.rules.

FAQ

¿ufw disable elimina mis reglas?

No. disable descarga el conjunto de reglas del kernel y escribe ENABLED=no en /etc/ufw/ufw.conf. Las reglas permanecen en /etc/ufw/user.rules y /etc/ufw/user6.rules, y sudo ufw show added las muestra mientras el firewall está inactivo. ufw reset es el comando que las elimina y primero crea una copia de seguridad de cada archivo. Muestra una línea similar a Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

¿Reiniciar mi VPS deshace un bloqueo de ufw?

No. ufw se inicia durante el arranque desde ENABLED=yes en /etc/ufw/ufw.conf, por lo que las mismas reglas se cargan antes de que se active la red y usted vuelve a quedar bloqueado. Reiniciar sólo ayuda después de desactivar ufw o de editar ese archivo desde el modo de rescate con el disco montado. Use la consola del proveedor y ejecute allí sudo ufw disable.

¿Por qué se puede acceder a mi contenedor Docker cuando ufw deniega el puerto?

Docker escribe sus propias reglas DNAT y FORWARD para cada puerto publicado. Ese tráfico se reenvía al contenedor en lugar de entregarse al host, por lo que nunca pasa por la cadena INPUT donde se encuentra la regla de denegación de ufw. Publique el puerto en loopback con -p 127.0.0.1:5432:5432 cuando sólo deba estar disponible para el host e inspeccione lo que Docker instaló con sudo iptables -t nat -S DOCKER.

No tengo contraseña de consola ni modo de rescate. ¿Qué opciones tengo?

Las opciones restantes dependen del proveedor: restablecer la contraseña desde el panel de control, lo que normalmente reinicia el servidor, o conectar el disco a otra instancia para editar /etc/ufw/ufw.conf desde allí. Consulte al soporte antes de reconstruir el servidor, porque una reconstrucción destruye los datos que contiene. Cuando vuelva a acceder, ejecute sudo passwd yourname y pruebe una vez el inicio de sesión en la consola, para que el próximo bloqueo sólo le haga perder dos minutos.