{"id":21109,"date":"2020-11-10T12:25:10","date_gmt":"2020-11-10T10:25:10","guid":{"rendered":"https:\/\/www.teldat.com\/sin-categorizar\/21109\/nftables-and-netfilter-hooks-via-linux-kernel\/"},"modified":"2022-12-07T18:06:24","modified_gmt":"2022-12-07T16:06:24","slug":"nftables-and-netfilter-hooks-via-linux-kernel","status":"publish","type":"post","link":"https:\/\/www.teldat.com\/es\/blog\/nftables-and-netfilter-hooks-via-linux-kernel\/","title":{"rendered":"Netfilter, Nftables e Iptables: uniendo los puntos"},"content":{"rendered":"

\"nftables-and-netfilter-hooks-via-linux-kernel\"A la hora de filtrar paquetes en Linux, Nftables<\/em><\/strong> (que pretende reemplazar el marco Iptables<\/em><\/strong>) ha evolucionado tanto en los \u00faltimos a\u00f1os que se ha convertido en la herramienta por defecto.<\/p>\n

<\/p>\n

Sin embargo, el marco Iptables sigue us\u00e1ndose<\/strong> mucho en sistemas modernos, por ejemplo, Debian buster<\/em><\/strong>.<\/p>\n

A veces, las Nftables se usan como un mecanismo de respaldo <\/strong>para crear una sintaxis alternativa<\/em> 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<\/strong>.<\/p>\n

Netfilter<\/h2>\n

El marco Netfilter crea, dentro de la pila de red del kernel de Linux, <\/strong>una serie de hooks<\/em> (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<\/em><\/strong> en esos hooks, permiti\u00e9ndoles inspeccionar los paquetes entrantes<\/strong> y decidir si se aceptan o rechazan.<\/p>\n

\"nftables-and-netfilter-hooks-via-linux-kernel\"<\/p>\n

Figura 1: Diagrama simplificado de los hooks<\/em> del Netfilter<\/p>\n

Cuando un dispositivo de red recibe un paquete, este pasa primero por el hook Prerouting<\/em><\/strong>. Aqu\u00ed, 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).<\/p>\n

En el primer caso, el paquete pasa por un filtro de entrada (Input)<\/em> y se procesa luego localmente. Si el paquete es reenviado, pasa por el hook Forward <\/em><\/strong>y por un \u00faltimo hook (Postrouting)<\/em> 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 <\/em><\/strong>y luego por el Postrouting, <\/em><\/strong>antes de enviarse a un dispositivo de red.<\/p>\n

Los hooks llevan muchos a\u00f1os en el kernel, pero sus funcionalidades han cambiado muy poco desde la versi\u00f3n 2.4 del n\u00facleo. Por supuesto, los kernel modernos<\/strong> s\u00ed muestran aspectos m\u00e1s complejos cuando son analizados en detalle (figura 2): los citados hooks no son aplicables para los protocolos IPv4 e IPv6.<\/strong> Por eso, los paquetes IPv4 e IPv6<\/strong> tienen que atravesar filtros propios.<\/p>\n

Tambi\u00e9n existen hooks para paquetes ARP<\/em> y Bridging.<\/em><\/strong> Adem\u00e1s, todos figuran, de manera independiente, en el espacio de nombres de cada red. Asimismo, existe un hook de entrada (ingress)<\/em><\/strong> para cada dispositivo de red. Y la lista sigue…<\/p>\n

\"nftables-and-netfilter-hooks-via-linux-kernel\"<\/p>\n

 <\/p>\n

Figura 2: Hooks Netfilter para IPv4, IPv6, ARP, Bridging y de entrada (Ingress)<\/p>\n

Registro de callbacks<\/h2>\n

La figura 3 muestra la API<\/strong> que genera Netfilter para registrar funciones de callback en un hook<\/strong>. Se pueden registrar m\u00faltiples funciones en un mismo filtro, junto con un valor entero de prioridad (priority<\/strong>)<\/em> que organiza las funciones en orden ascendente.<\/p>\n

\"nftables-and-netfilter-hooks-via-linux-kernel\"<\/p>\n

Figura 3: Registrar\/eliminar una funci\u00f3n de callback en un \u201chook\u201d de Netfilter<\/p>\n

Hook transversal y veredicto<\/h2>\n

Por cada paquete de red<\/strong> que atraviese un hook, las funciones de callback integradas se aplicar\u00e1n una a una en el orden de prioridad establecido por el valor priority<\/em><\/strong>. Cada callback deber\u00e1 devolver un \u201cveredicto\u201d: NF_ACCEPT o NF_DROP. Si el resultado es NF_ACCEPT, el paquete pasar\u00e1 al siguiente hook de callback (de existir).<\/p>\n

Si todas las callbacks devuelven un mensaje de NF_ACCEPT, el paquete seguir\u00e1 atravesando la pila de red del kernel.<\/strong> Sin embargo, si se devuelve un mensaje de NF_DROP, el paquete se borrar\u00e1 y no se realizar\u00e1n m\u00e1s callbacks.<\/p>\n

\"nftables-and-netfilter-hooks-via-linux-kernel\"<\/p>\n

Figura 4: \u201cHook\u201d transversal de las funciones de callback y veredicto<\/p>\n

Nftables VS Iptables<\/h2>\n

Tanto las Nftables<\/strong> como las Iptables<\/strong> organizan sus normas de filtrado de paquetes en tablas y cadenas.<\/strong> Las tablas son un mero contenedor en el que se agrupan cadenas con un mismo prop\u00f3sito. Las normas en s\u00ed se integran en las cadenas. Ambos marcos registran sus cadenas (base) como callbacks en los hooks de Netfilter.<\/p>\n

El marco Iptables cuenta con una serie de tablas y cadenas fijas y predefinidas <\/strong>(ver figura 5). Esto se debe a que las cadenas adoptan el nombre del hook en el que se registran. Adem\u00e1s, el conjunto de Iptables se divide en herramientas de l\u00edneas de comando y sus m\u00f3dulos kernel correspondientes:<\/strong><\/p>\n