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

Un puerto parece cerrado desde el exterior, luego se termina buscando en la aplicación o el enrutador. Antes de modificar cualquier cosa, observe 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 recorrido de la 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 manera 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 interesa:

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 por una regla IPv4 suponiendo que el problema está resuelto.

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

Para ver los identificadores de las 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 hacia 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 se evalúan en el 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 está escuchando en otro lugar. La salida de ss -lntup permite verificar que un programa realmente está escuchando 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 romper las respuestas a las conexiones que ya están 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.

Una negativa puede permanecer fuera de la máquina: grupo de seguridad en la nube, enrutador, redirección NAT, VLAN, firewall empresarial o servicio relacionado solo con 127.0.0.1. Desde otra estación, 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 a nftables.

Identifique la regla que realmente bloquea

Una cadena puede llamar a otra cadena con jump o goto. Por lo tanto, la autorización del puerto no es necesariamente visible en la primera cadena mostrada. Vuelva a leer 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 específico 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 identificador mostrado por nft -a list ruleset.

No deje una regla de rastreo o de registro amplia en un servidor expuesto. Puede llenar los registros o agregar ruido al diagnóstico. Para un primer control, los contadores de la cadena y una prueba desde otro terminal suelen ser 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 será retomado tras el reinicio. En Debian y Ubuntu, normalmente mire /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 usa firewalld, UFW, Docker o una herramienta de hosting, varios componentes pueden escribir reglas. No copie un ruleset visto en un tutorial a /etc/nftables.conf si otro servicio ya lo gestiona. Identifique primero el gestor declarado por su máquina y relea las reglas después de su recarga.

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

Haga una copia de seguridad 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

A continuación, 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 dejará entrar. Mantenga una segunda sesión SSH conectada, aplique el archivo en la primera, y luego intente una nueva conexión desde otro 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 de regla errónea:
sudo nft -f /root/nftables-before-change.nft

Evite flush ruleset lanzado 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, y luego controle el ruleset activo inmediatamente después.

Controles después de la modificación

Reinicie sudo nft list ruleset y verifique que la tabla y la cadena esperadas siguen presentes.
Pruebe el servicio desde otra máquina con el puerto realmente utilizado.
Controle sudo ss -lntup si el puerto sigue siendo 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 recarga 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.