Autor
Como sabéis, el cortafuegos en Linux es un componente más del núcleo y no una aplicación que corre en el espacio de usuario ("userland"; es decir, el entorno en el que se ejecuta todo lo que no sea el núcleo), a diferencia de muchos cortafuegos comerciales que existen para Windows, por ejemplo. Herramientas como UFW (o su interfaz gráfica gufw) no son en realidad cortafuegos, sino tan solo interfaces más fáciles para operar con iptables/netfilter, que es el subsistema encargado de controlar el acceso a los puertos TCP/IP del sistema. El mecanismo ha dado resultados desde su implementación en 2006, pero se ha quedado corto.
El problema, principalmente, es que iptables es demasiado complejo, lento y, además, no conoce nada más que los protocolos TCP/IP y UDP para IPv4. Para IPv6, ARP o protocolos de puenteo Ethernet, existían otras herramientas que interactuaban con netfilter, con la consiguiente duplicación de código (que es peligrosa porque multiplica la posibilidad de que un mismo error se haya multiplicado en diferentes partes del código) y también la duplicación de configuración cuando uno quiere tener las mismas reglas para los diversos tipos de conexión.
El nuevo candidato se llama nftables y es un proyecto revolucionario que estuvo a punto de morir en el año 2009; hasta su página web llegó a desaparecer por la falta de apoyo que tenía. Sin embargo, el desarrollador Pablo Neira Ayuso, experto en el subsistema de redes del núcleo, decidió revivirlo y ha liderado su resurrección. Obviamente, iptables no desaparecerá en un tiempo, pero con la inclusión de nftables, ya tiene sus días contados, especialmente porque el equipo de nftables ha creado también una capa de compatibilidad con iptables que ayudará a hacer más fácil la transición.
¿Qué se gana con nftables? Mucho. El nuevo nftables consiste básicamente en un intérprete o máquina virtual provista de un lenguaje de programación especializado que permite trasladar buena parte del código al entorno de usuario (las reglas, principalmente) mientras que tan solo el mecanismo de filtrado de paquetes se queda en el núcleo. Mientras menos cosas haya en el núcleo, mejor, pero sin caer en el pecado de los cortafuegos comerciales para Windows que solo operan en el entorno de usuario porque no son parte del sistema operativo y, por tanto, son lentas y obstruyen el correcto funcionamiento del mismo. Además, nftables abstrae los protocolos y tan solo necesita que se le diga de dónde viene o adónde va el paquete con la correspondiente dirección para adivinar el protocolo y adoptar el filtrado pertinente. De hecho, escribir las reglas se reducirá a escribir código en un fichero de texto y dejar que nftables lo interprete; mucho más amigable que la actual interfaz de comandos de iptables.
No es la primera vez que hay un cambio de cortafuegos en el núcleo. El primer cortafuegos integrado fue ipfwadm, que duró hasta Linux 2.0. Linux 2.2 incluyó ipchains e iptables hizo su debut en 2.4. Pero es evidente que es un componente bastante crítico que provocará que las distribuciones necesiten más tiempo para probar Linux 3.13. Es un componente que debe ser estable para que pueda ser incluido en sistemas como Debian o RHEL, los reyes en el mundo de los servidores, y no dudarán en retrasar la adopción del núcleo nuevo hasta que nftables no dé suficiente confianza. Así que es esperable que, aunque los núcleos a partir de 3.13 contengan el nuevo cortafuegos, las distribuciones se lo pensarán dos veces antes de utilizarlo como el predeterminado.
Todo esto da bastante confianza: no es la primera vez que tenemos un cambio en este componente, así que es terreno conocido, y las ventajas son interesantes. Habrá que seguirlo de cerca y ver cómo evoluciona, si nftables cumple las expectativas y cuán rápido se termine imponiendo como el nuevo cortafuegos predeterminado del núcleo.
Publicado por Eugenio M. Vigo en 19:45
Fuente : http://etccrond.blogspot.com.es/2013/10/hola-nftables-adios-iptables.html
En línea
