Un conjunto mínimo de reglas nftables para un único servidor

Objetivo

Exponer únicamente los puertos que un servidor debe servir, tanto para IPv4 como para IPv6, en un conjunto de reglas que cabe en una pantalla y se recarga de forma segura.

Requisitos previos

Acceso root, el binario nft y una lista de los puertos que sirve el host.

Pasos

1. Escribir /etc/nftables.conf siguiendo la estructura del ejemplo de servidor del wiki de nftables: flush ruleset, y luego una única table inet filter para que un solo conjunto de reglas cubra ambas familias de direcciones.
2. Definir chain input { type filter hook input priority 0; policy drop; ... } y, en orden: ct state vmap { established : accept, related : accept, invalid : drop }, iifname lo accept, meta l4proto { icmp, ipv6-icmp } accept (ICMPv6 lleva el descubrimiento de vecinos; bloquearlo rompe IPv6, por lo que el ejemplo del wiki acepta al menos los tipos nd-*), y luego tcp dport { 22, 80, 443 } accept.
3. Añadir chain forward { type filter hook forward priority 0; policy drop; } solo si el host ni enruta ni ejecuta contenedores: nft(8) indica que un paquete se acepta únicamente si ninguna cadena base lo descarta, de modo que una cadena forward que descarta también bloquea el tráfico del puente de un runtime de contenedores. Dejar output sin definir, lo cual equivale a aceptar.
4. Mientras se depura, terminar la cadena input con log prefix "nft-drop " counter drop.
5. Validar la sintaxis sin aplicarla: nft -c -f /etc/nftables.conf.
6. Armar una reversión antes de cargar: systemd-run --on-active=120 nft flush ruleset programa un flush en dos minutos (--on-active está documentado en systemd-run(1)). Cargar con nft -f /etc/nftables.conf, confirmar que funciona una nueva sesión SSH, y luego detener el temporizador transitorio cuyo nombre de unidad imprimió systemd-run.
7. Inspeccionar el estado en vivo con nft list ruleset; nft(8) indica que esta salida puede usarse como entrada para nft -f, de modo que también sirve como respaldo.
8. Habilitar el servicio nftables de la distribución para que el archivo se cargue en el arranque.

Resultado esperado

nft list ruleset muestra exactamente las cadenas previstas; un escaneo de puertos desde el exterior muestra solo los puertos listados; una recarga con nft -f sustituye el conjunto de reglas antiguo por el nuevo en una sola operación (el "reemplazo atómico de reglas" del wiki), de modo que no hay ningún momento sin reglas, y las conexiones existentes siguen coincidiendo con ct state established.

Límites y base de verificación

El conjunto de reglas no sabe qué proceso escucha en un puerto. Los runtimes de contenedores insertan sus propias tablas y prioridades; con redes en modo puente, el tráfico hacia los puertos publicados de los contenedores normalmente se traduce y reenvía en lugar de entregarse localmente, de modo que evita esta cadena input y pasa por el hook forward. Conviene consultar la documentación de firewall del runtime antes de añadir reglas forward, y no mezclar el iptables heredado con nft. La sintaxis sigue el wiki y el manual citados; no se reivindica ninguna medición de rendimiento ni de seguridad.

Revertir al conjunto de reglas anterior, no a la nada

Un flush ruleset programado deja al host sin ninguna regla y elimina tablas de las que depende otro software. Conviene guardar primero el estado actual y armar una restauración en su lugar:

nft list ruleset > /root/nft-before.conf
systemd-run --on-active=120 nft -f /root/nft-before.conf
nft -f /etc/nftables.conf

Confirmar una nueva sesión SSH, y luego detener el temporizador transitorio. Por la misma razón, conviene evitar flush ruleset en el archivo de configuración en hosts que ejecutan un runtime de contenedores: elimina las tablas ip nat e ip filter del runtime, y los puertos publicados dejan de funcionar hasta que el runtime se reinicia. Vaciar solo la tabla propia (table inet filter {} seguido de flush table inet filter), lo cual sigue siendo atómico para esa tabla.