TELDAT Blog

Communicate with us

Netfilter, Nftables e Iptables: uniendo los puntos

nftables-and-netfilter-hooks-via-linux-kernelA 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.

nftables-and-netfilter-hooks-via-linux-kernel

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…

nftables-and-netfilter-hooks-via-linux-kernel

 

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.

nftables-and-netfilter-hooks-via-linux-kernel

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.

nftables-and-netfilter-hooks-via-linux-kernel

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.

 

nftables-and-netfilter-hooks-via-linux-kernel

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).

 

 

nftables-and-netfilter-hooks-via-linux-kernel

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.

nftables-and-netfilter-hooks-via-linux-kernel

Figura 7: Router periférico

 

 

 

 

 

 

 

 

 

 

nftables-and-netfilter-hooks-via-linux-kernel

 

 

 

 

 

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

 

Andrej Stender

Andrej Stender

Ingeniero de comunicaciones. Trabaja en el departamento de I+D como ingeniero de software y responsable de equipo.

Nuestras Soluciones Relevantes

Our Relevant Solutions

Give us your opinion!

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

floating-i
Contact us
Copy link
Powered by Social Snap