Nftables en Linux, verifica las reglas antes de abrir un puerto

Un puerto parece estar cerrado desde el exterior, luego terminamos buscando del lado de la aplicación o del enrutador. Antes de modificar nada, mire las reglas realmente cargadas por nftables. El archivo /etc/nftables.conf puede ser diferente del estado activo, y un firewall local no explica por sí solo todo el trayecto de red.

Este método permite leer el ruleset, identificar la cadena que trata el tráfico entrante y probar una modificación sin perder una sesión SSH. Mantenga una segunda conexión abierta si está interviniendo de forma remota.

Comience por leer el firewall cargado

El siguiente comando no cambia nada. Muestra las tablas, las cadenas, las reglas y los posibles contadores actualmente presentes en el núcleo:

sudo nft list ruleset

Si la salida es larga, liste primero las tablas y luego diríjase a la que le interese:

sudo nft list tables
sudo nft list table inet filter

La familia inet puede contener reglas IPv4 e IPv6. Una tabla también puede pertenecer a ip, ip6, bridge o netdev. No reemplace una regla IPv6 con una regla IPv4 suponiendo que el problema esté resuelto.

En una tabla de filtrado, busque principalmente una cadena base con type filter hook input. Esta recibe el tráfico destinado a la máquina. Su línea policy drop significa que los paquetes que no coincidan con ninguna regla accept serán rechazados.

Para ver los identificadores de reglas, útiles si necesita eliminar una regla específica más tarde, agregue -a:

sudo nft -a list chain inet filter input

No confunda input, forward y output. Un servidor que recibe una conexión SSH generalmente utiliza input. Una máquina que enruta tráfico a otro host puede bloquear el paquete en forward. Una aplicación que sale hacia Internet pasa por output.

Verifique el puerto y el orden de las reglas

Las reglas de una cadena son evaluadas en orden. Una regla de rechazo colocada antes de la autorización del puerto gana. Busque el protocolo, el puerto y el estado de la conexión:

sudo nft list chain inet filter input
sudo ss -lntup

Para SSH, una regla esperada a menudo se parece a tcp dport 22 accept. El puerto puede ser diferente si el demonio escucha en otro lugar. La salida de ss -lntup permite verificar que un programa realmente escucha en el puerto y la dirección esperados. Un firewall abierto no hace disponible un servicio detenido.

También observe las reglas ct state established,related accept y la interfaz loopback iif lo accept. Estas evitan interrumpir las respuestas a conexiones ya establecidas y los intercambios locales. Si el ruleset tiene contadores, compárelos antes y después de una prueba de conexión para saber qué regla ve el tráfico.

Un rechazo puede permanecer fuera de la máquina: grupo de seguridad en la nube, enrutador, redirección NAT, VLAN, firewall corporativo o servicio vinculado solo a 127.0.0.1. Desde otra máquina, pruebe el puerto con nc -vz dirección_del_servidor 22 o con su cliente SSH. En el servidor, verifique la escucha con ss antes de tocar nftables.

Identifique la regla que realmente bloquea

Una cadena puede llamar a otra cadena con jump o goto. La autorización del puerto no siempre es visible en la primera cadena mostrada. Revise las llamadas de cadenas, los conjuntos nombrados y las reglas que llevan un prefijo de registro. Una regla de tipo counter drop o reject colocada antes del puerto a menudo explica el resultado.

Puede seguir un paquete dirigido con nft monitor trace, pero este comando produce muchos datos en una máquina activa. Resérvelo para una breve ventana de diagnóstico y filtre el tráfico por dirección o por puerto en una regla temporal. Luego elimine esta regla con su handle mostrado por nft -a list ruleset.

No deje una regla de traza o registro amplio en un servidor expuesto. Puede llenar los registros o añadir ruido al diagnóstico. Para un primer control, los contadores de la cadena y una prueba desde otra máquina a menudo son suficientes.

El ruleset activo y el archivo persistente pueden divergir

nft list ruleset lee el estado activo. No dice qué servicio ha cargado las reglas, ni qué archivo se retomará al reiniciar. En Debian y Ubuntu, consulte usualmente /etc/nftables.conf y el estado del servicio:

sudo systemctl status nftables
sudo systemctl is-enabled nftables
sudo grep -nE '^(table|include|flush)' /etc/nftables.conf

En una distribución que pasa por firewalld, UFW, Docker o una herramienta de hospedaje, varios componentes pueden escribir reglas. No copie un ruleset visto en un tutorial en /etc/nftables.conf si otro servicio ya lo está gestionando. Identifique primero el gestor declarado por su máquina y vuelva a leer las reglas después de su recarga.

Las reglas añadidas en la línea de comandos a menudo desaparecen al siguiente reinicio o al próximo recargado del servicio. Inversamente, modificar el archivo persistente no cambia nada hasta que se cargue. Esta es precisamente la razón para controlar ambos lados antes de concluir que un puerto está abierto.

Guarde y pruebe antes de aplicar una regla

Conserve el estado actual antes de cualquier escritura. El archivo de respaldo debe ser legible solo por el administrador:

sudo install -m 600 /dev/null /root/nftables-before-change.nft
sudo nft list ruleset | sudo tee /root/nftables-before-change.nft > /dev/null

Luego, prepare la modificación en un archivo temporal. nft -c verifica la sintaxis sin cargar las reglas:

sudo nft -c -f /etc/nftables.conf

Esta verificación no prueba que el nuevo ruleset le permitirá entrar. Mantenga una segunda sesión SSH conectada, aplique el archivo en la primera y luego intente una nueva conexión desde otra terminal. Si pierde el acceso, la sesión de respaldo permite restaurar la copia de seguridad:

sudo nft -f /etc/nftables.conf
sudo nft list ruleset
# En caso de corte o regla errónea:
sudo nft -f /root/nftables-before-change.nft

Evite flush ruleset ejecutado solo en un servidor remoto. Retira todas las reglas actuales antes de que haya confirmado el archivo de reemplazo. Cargue un archivo completo y verificado, luego controle el ruleset activo inmediatamente después.

Controles después de la modificación

Vuelva a ejecutar sudo nft list ruleset y verifique que la tabla y la cadena esperadas sigan presentes.
Pruebe el servicio desde otra máquina con el puerto realmente utilizado.
Controle sudo ss -lntup si el puerto sigue inaccesible.
Verifique el registro del núcleo con sudo journalctl -k -b si sus reglas registran los paquetes rechazados.
Después de un reinicio, verifique que el servicio nftables recargue correctamente el archivo persistente de su distribución.

Para los casos simples, el artículo sobre UFW en Linux es más adecuado. Si necesita diagnosticar la disponibilidad de un servicio antes de modificar el firewall, controle también los puertos abiertos con ss. La documentación nft(8) detalla las familias, las cadenas y la opción -c.