A la hora de filtrar paquetes en Linux, Nftables (que pretende reemplazar el marco Iptables) ha evolucionado tanto en los últimos años que se ha convertido en la herramienta por defecto.

Sin embargo, el marco Iptables sigue usándose mucho en sistemas modernos, por ejemplo, Debian buster.

A veces, las Nftables se usan como un mecanismo de respaldo para crear una sintaxis alternativa que defina reglas de filtrado de paquetes. Tanto si se emulan como si no, las Nftables y las Iptables se basan en un marco Netfilter subyacente.

Netfilter

El marco Netfilter crea, dentro de la pila de red del kernel de Linux, una serie de hooks (puntos de enganche que sirven como herramienta de filtrado) por los que deben pasar los paquetes de red (figura 1). Otros componentes del kernel pueden registrar funciones de callback en esos hooks, permitiéndoles inspeccionar los paquetes entrantes y decidir si se aceptan o rechazan.

Figura 1: Diagrama simplificado de los hooks del Netfilter

Cuando un dispositivo de red recibe un paquete, este pasa primero por el hook Prerouting. Aquí, el kernel decide si el paquete debe procesarse localmente (por ejemplo, por un puerto de escucha en un servidor del sistema) o si debe reenviarse (cuando el sistema opera como un router).

En el primer caso, el paquete pasa por un filtro de entrada (Input) y se procesa luego localmente. Si el paquete es reenviado, pasa por el hook Forward y por un último hook (Postrouting) antes de enviarse a un dispositivo red. En el caso de los paquetes generados localmente (por ejemplo, por un cliente o proceso del servidor al que le guste mandar cosas fuera), estos deben pasar antes por el hook Output y luego por el Postrouting, antes de enviarse a un dispositivo de red.

Los hooks llevan muchos años en el kernel, pero sus funcionalidades han cambiado muy poco desde la versión 2.4 del núcleo. Por supuesto, los kernel modernos sí muestran aspectos más complejos cuando son analizados en detalle (figura 2): los citados hooks no son aplicables para los protocolos IPv4 e IPv6. Por eso, los paquetes IPv4 e IPv6 tienen que atravesar filtros propios.

También existen hooks para paquetes ARP y Bridging. Además, todos figuran, de manera independiente, en el espacio de nombres de cada red. Asimismo, existe un hook de entrada (ingress) para cada dispositivo de red. Y la lista sigue…

Figura 2: Hooks Netfilter para IPv4, IPv6, ARP, Bridging y de entrada (Ingress)

Registro de callbacks

La figura 3 muestra la API que genera Netfilter para registrar funciones de callback en un hook. Se pueden registrar múltiples funciones en un mismo filtro, junto con un valor entero de prioridad (priority) que organiza las funciones en orden ascendente.

Figura 3: Registrar/eliminar una función de callback en un “hook” de Netfilter

Hook transversal y veredicto

Por cada paquete de red que atraviese un hook, las funciones de callback integradas se aplicarán una a una en el orden de prioridad establecido por el valor priority. Cada callback deberá devolver un “veredicto”: NF_ACCEPT o NF_DROP. Si el resultado es NF_ACCEPT, el paquete pasará al siguiente hook de callback (de existir).

Si todas las callbacks devuelven un mensaje de NF_ACCEPT, el paquete seguirá atravesando la pila de red del kernel. Sin embargo, si se devuelve un mensaje de NF_DROP, el paquete se borrará y no se realizarán más callbacks.

Figura 4: “Hook” transversal de las funciones de callback y veredicto

Nftables VS Iptables

Tanto las Nftables como las Iptables organizan sus normas de filtrado de paquetes en tablas y cadenas. Las tablas son un mero contenedor en el que se agrupan cadenas con un mismo propósito. Las normas en sí se integran en las cadenas. Ambos marcos registran sus cadenas (base) como callbacks en los hooks de Netfilter.

El marco Iptables cuenta con una serie de tablas y cadenas fijas y predefinidas (ver figura 5). Esto se debe a que las cadenas adoptan el nombre del hook en el que se registran. Además, el conjunto de Iptables se divide en herramientas de líneas de comando y sus módulos kernel correspondientes:

• Iptables para IPv4.
• Ip6tables para IPv6.
• Arptables para ARP.
• Ebtables para Bridging.

Figura 5: Cadenas de Iptables registradas en “hooks” Netfilter para IPv4 (+ rastreo de conexiones)

En el caso de las Nftables, no existen tablas y cadenas predefinidas (el usuario es el responsable de su creación). Esto se hace a través de una herramienta de línea de comando única conocida como nft, lo que nos lleva al concepto de “familias de direcciones”:

• ip: mapea “hooks” IPv4 (por defecto)
• ip6: mapea “hooks” IPv6
• inet: mapea “hooks” IPv4 e IPv6
• arp: mapea “hooks” ARP
• bridge: mapea “hooks” bridging
• netdev: mapea “hook” de entrada (ingress)

A la hora de crear una tabla, el usuario debe especificar una familia de direcciones. Esta selección se aplicará a todas las cadenas dentro de esa tabla. Al crear una cadena, el usuario debe especificar el hook de Netfilter en el que se registrará la cadena y el valor de prioridad (priority).

 Ejemplo: Hook de entrada para Ipv4

Crear una tabla llamada filter en la familia de direcciones ip y dos cadenas base (foo y bar) , registrándolas en el hook input del Netfilter para IPv4 con prioridades 0 y 50 (figura 6).

Figura 6: “Hook” de entrada (input) del marco Netfilter para IPv4

Ejemplo: pequeño router periférico

Hacer un filtrado sencillo de paquetes IPv4 y SNAT (ocultación) en un router periférico.

Figura 7: Router periférico

Figura 8: Cadenas de Nftables registradas en un “hook” de Netfilter para IPv4 (+ rastreo de conexiones)

En Teldat, creemos que los servicios como Nftables y Netfilter son bloques esenciales sobre los que construir las funcionalidades SD-WAN de nuestra solución be.SDx. Corp