[h]Ha llegado bpfilter, el firewall del futuro [/h]
https://www.wifi-libre.com/img/members/3/bpfilter_1.jpg
El evento más importante del año 2018 (en el mundo) es (indudablemente 
) la aparición de un “nuevo firewall” nativo en los Sistemas Linux.
Iptables (con netfilter), toda una institución, empieza a hacerse viejo: ¡Veinte años de buenos y leales servicios!
Se ha integrado desde la versión 4.18 del Kernel Linux a bpfilter que está llamado a tomar el relevo.
Varios Sistemas Operativos llevan bpfilter (por ejemplo** Ubuntu 18.10**), se puede ver durante el arranque del SO:
[h]¿Por qué las iptables se están haciendo viejas?[/h]
Es siempre algo problemático cuando se cambia una herramienta fundamental que lleva aquí veinte años.
Sobre todo que las iptables están muy apreciadas por su potencia y su versatilidad.
El problema es que el nivel de complejidad de las redes y el volumen de transferencia de datos no tienen nada que ver hoy en día con lo que eran en 1998…
Y la evolución que hemos observado estos 20 años en nuestras redes domesticas (ancho de banda multiplicado por 100, llegada de smartphone y objetos conectados) no es nada comparado con la evolución en entornos profesionales.
Todo ha ido evolucionando muy rápido y la redacción de reglas iptables se ha vuelto más y más complejas.
La obsolescencia de iptables viene de su sencillez.
Es un poco un paradoja porque es a la vez su gran ventaja: Podemos redactar un regla simple y gestionar un puerto o una IP en vivo. Directo al grano y sencillo.
El problema es que que el funcionamiento con lista es secuencial.
Es decir: Se redacta una lista de reglas y el demonio lee y aplica cada regla de la lista, una tras otra, para cada paquete mandado.
Desde una perspectiva de simple usuario con su red domestica no nos afecta.
En entornos profesionales, con listas de reglas extensas, un funcionamiento tan linear se transforma en cuello de botella: Genera latencia.
Otro problema es que la gestión de las reglas es muy complicada, es un gran lista que el administrador debe editar, es muy rudimentario.
Chiste ( advierto, es de informático, con alusión a roll-MPRG )
[quote] OH: “In any team you need a tank, a healer, a damage dealer, someone with crowd control abilities, and another who knows iptables”
— Jérôme Petazzoni (@jpetazzo) June 27, 2015[/quote]
Para mejorar la situación se ha creado ipset que “comprime” las reglas.
No se solventa el problema en el fondo (sigue siendo secuencial) pero se minimizan los efectos indeseados; Disminuye el tamaño de las reglas y aumenta la velocidad de lectura.
Esta solución “intermedia” no es suficiente hoy en día para empresas como facebook que gestionan cantidades excepcionales de conexiones (y reglas)
Para cumplir con las exigencias de los gigantes del sector se ha creado
[h]Berkeley Packet Filter[/h]
Antes de llegar al Kernel Linux, Bpfilter ha sido (y está) empleado por Google, Netflix, Facebook etc…
Parece ser “lo más” para mitigar los ataques DDoS ya que lo emplea cloudfare, el servicio mas empleado en el mundo para esto.
En fin, está comprobado a gran escala.
Lo que explica (y justifica) probablemente porque ha sido integrado tan rápido al kernel.
https://www.wifi-libre.com/img/members/3/bpfilter_2.jpg
La gran diferencia con el ecosistema iptables es que bpfilter funciona con compilador.
Las reglas se convierten en binarios ejecutables y esto lo cambia todo:
- La ejecución es mucho más rápida
- Se abren horizontes completamente nuevos para la gestión de las reglas ya que pueden programar.
Son programas** eBPF** que se redactan con ** lenguaje C**. Aquí podéis ver uno: bpf_load.c
El lenguaje C es perfecto: Máxima velocidad ejecución y las posibilidades para programar son infinitas…
Dichos programas se ejecutan “a dentro” de Bpfilter ya que es - voy a decir una palabra que está muy de moda ahora - un* fucking*
contenedor.
[h]¿Adiós iptables?[/h]
Todo esto suena muy bien si eres un profesional,
Pero es una pesadilla para el usuario medio: ¿Vamos a tener que aprender a programar en C para redactar una maldita linea iptables?
Don’t worry: Bpfilter es compatible con iptables. Entiende y ejecuta las reglas.
Si tenemos reglas iptables se ejecutan como siempre, no a la velocidad de un programa c.
Da igual porque a nuestra escala no cambia absolutamente nada: Es muy raro que alguien tenga mas de cien reglas iptables redactadas.
No hay necesidad de compilar, la lista se lee rápido en texto plano.
No es el fin de** iptables** aunque hace algo de tiempo que se ha introducido (y se preconiza) su sucesor: NFTables
Pero much@s usuari@s no han dado el paso y** iptable sigue aquí.
La situación se ha vuelto un poco más espesa aún con 3 herramientas “firewall”.
[list=1]
]- Deberíamos haber abandonado iptables para usar NFTables /]
]- Sabiendo que existe por encima a bpfilter que es aún más evolucionado/]
[/list]
Cada uno hará lo que le convenga…
Quizá iptables salga progresivamente y despacio de las distribuciones “estables” pero seguirá en los repositorio mucho tiempo.
El principal problema cuando se cambia algo en las herramientas fundamentales es la “retro”-compatibilidad.
Hemos visto en nuestro mundillo los terremotos provocados por un simple cambio en aircrack-ng de nombramiento de interfaces wifi.
Por poco ahorcaban a MisterX porque no rulaba tal o tal script.
En este caso han tenido cuidado para no provocar un seísmo: Lo que funciona con iptables** (tantas cosas en tantos servidores) sigue funcionando.
Para concluir este post dejo los vínculos hacía artículos que he consultado para redactar este mensaje:
[list=*]
]A thorough introduction to eBPF @ LWN/]
]Why is the kernel community replacing iptables with BPF? @ Cilium/]
[/list]