El filtro de paquetes Berkeley extendido ( eBPF ) se puede actualizar de forma rápida y continua, lo que lo hace ideal para manejar cambios frecuentes en la configuración de seguridad.
Traducido de Cómo administrar XDP/eBPF de manera efectiva para una mejor protección DDoS , autor Ivan Koveshnikov.
El mapa Extended Berkeley Packet Filter ( eBPF ) sirve como una interfaz de alto nivel para actualizaciones atómicas de los segmentos de memoria compartida utilizados como memoria compartida y proporciona una poderosa interfaz de configuración para programas eBPF. El mecanismo de lectura, copia y actualización minimiza la sobrecarga de rendimiento en la ruta activa. Además, el mapeo eBPF permite el acceso exclusivo a segmentos de memoria compartida. Pueden manejar tipos de mapas mixtos (matrices, tablas hash, filtros de floración, colas y buffers en anillo), lo que los hace ideales para configuraciones complejas como la seguridad .
A medida que aumenta la complejidad de la configuración, también aumenta la necesidad de conexiones entre diferentes entradas de mapeo. Si hay demasiadas conexiones entre las entradas del mapa, la capacidad de realizar actualizaciones de configuración atómica comienza a degradarse. Actualizar solo una entrada del mapa puede significar que otras entradas deben actualizarse al mismo tiempo, lo que puede causar inconsistencias durante las actualizaciones.
Aplique XDP para una gestión avanzada del tráfico
Considere un programa simple eXpress Data Path (XDP) que clasifica y filtra el tráfico según un conjunto de reglas de cinco tuplas de prioridad. El programa procesa el siguiente paquete según la prioridad de la regla y una combinación de la dirección IP de origen, la dirección IP de destino, el protocolo y los puertos de origen y destino del paquete.
Diagrama de flujo de clasificación que conduce al procesamiento.
El siguiente es un ejemplo de una regla de configuración de red:
- Siempre se permite cualquier tráfico de la subred A.
- Restrinja el acceso de los clientes de la subred C al servidor web de la subred B.
- Restrinja el acceso al servidor web en la subred B.
- Se deniega cualquier otro acceso.
Estas reglas requieren que se almacenen reglas y restricciones de clasificación de tráfico en la configuración, lo que se puede lograr mediante asignaciones de eBPF.
Comprender la configuración del programa eBPF como una estructura de árbol
Puede visualizar la configuración como un árbol jerárquico, con una "raíz de configuración" como base. Esta raíz (posiblemente virtual) organiza las diversas entidades de configuración para formar la configuración activa. Las entidades están conectadas directamente a la raíz para un acceso global inmediato o anidadas dentro de otras entidades para una organización estructurada.
El acceso a una entidad específica comienza en la raíz y continúa secuencialmente ("eliminando las referencias" de cada nivel) hasta llegar a la entidad deseada. Por ejemplo, para recuperar un indicador booleano de una estructura de "opciones" en una colección, debe navegar hasta la colección, buscar la estructura y luego recuperar los indicadores.
El enfoque de Gcore para abordar los desafíos de complejidad de eBPF
Esta estructura de árbol proporciona flexibilidad en la gestión de la configuración, incluido el intercambio atómico de cualquier subárbol, lo que garantiza transiciones fluidas y sin interrupciones. Sin embargo, la mayor complejidad trae consigo desafíos. A medida que las configuraciones se vuelven más complejas, las entradas se vuelven más interconectadas. Es común que varias entradas principales apunten a una única entrada secundaria, o que una entrada desempeñe un doble papel, como propiedad de una entidad y como parte de una colección.
Los lenguajes de programación modernos han desarrollado mecanismos para gestionar configuraciones complejas. Los desarrolladores utilizan contadores de referencias, referencias mutables e inmutables y recolectores de basura para garantizar actualizaciones seguras. Sin embargo, gestionar la seguridad de estas configuraciones no garantiza la atomicidad al cambiar entre versiones de configuración.
El panorama siempre cambiante del tráfico en línea significa que los equipos de operaciones de seguridad deben realizar cambios frecuentes en las políticas de seguridad. Por ello, Gcore ha realizado actualizaciones rápidas y frecuentes de la protección DDoS de Gcore e incorporado características importantes como un motor de expresiones regulares . Pasamos de las actualizaciones estándar de una o dos por día para las soluciones autohospedadas a las actualizaciones casi constantes que requieren los proveedores de servicios. Este requisito, que a menudo se pasa por alto en las aplicaciones de Linux, ha llevado a la adopción de la tecnología eBPF, que permite actualizaciones rápidas e ininterrumpidas.
Al explorar soluciones eBPF, debemos explorar a fondo estrategias para garantizar que nuestra configuración de eBPF se maneje de la mejor manera posible. Específicamente, las limitaciones del mapeo eBPF hicieron que nuestro equipo reconsiderara nuestra estrategia de almacenamiento de configuración.
Debido a la validación de seguridad del kernel, las entradas del mapa eBPF no pueden almacenar punteros directos a segmentos de memoria arbitrarios, lo que requiere una clave de búsqueda para acceder a la entrada del mapa, lo que ralentiza el proceso de búsqueda. Pero esta deficiencia proporciona un beneficio: nos permite dividir árboles de configuración complejos en segmentos más pequeños y manejables, vinculados directamente a la raíz de configuración. cual es el resultado? Consistencia, incluso durante actualizaciones no atómicas.
Nuestros hallazgos y estrategias resaltan la importancia de una planificación y ejecución cuidadosas de los programas eBPF para optimizar la eficiencia. Entonces, pasemos ahora a las estrategias de actualización de configuración específicas para entornos eBPF y su aplicabilidad a los requisitos y limitaciones únicos del sistema.
Política de actualización de configuración de seguridad
Descubrimos que tres estrategias de actualización son particularmente efectivas para mejorar las actualizaciones del programa y al mismo tiempo garantizar un alto rendimiento y flexibilidad.
Estrategia de actualización 1: transición gradual
Una estrategia de actualización gradual significa actualizaciones de configuración incrementales en múltiples asignaciones. Esta es una opción útil al procesar datos en un mapa para proporcionar una clave de búsqueda para otro mapa. En este caso, es necesario actualizar varias entradas del mapa y la conversión atómica no es factible. Pero las operaciones de actualización precisas y secuenciales permiten actualizaciones metódicas de la configuración. Algunas operaciones en subárboles de configuración a los que se hace referencia se vuelven seguras si se realizan en el orden correcto.
Por ejemplo, en el contexto de clasificación y procesamiento, la capa de clasificación proporciona claves de búsqueda para coincidir con las políticas de seguridad, lo que significa que las operaciones de actualización deben seguir un orden específico:
- Es seguro insertar una nueva política de seguridad porque aún no se ha hecho referencia a ella.
- También es seguro actualizar las políticas de seguridad existentes porque actualizarlas individualmente generalmente no causa problemas. Aunque las actualizaciones atómicas son deseables, no proporcionan ventajas significativas.
- Es seguro actualizar la asignación de la capa de clasificación para hacer referencia a la nueva política de seguridad y eliminar las referencias a la política obsoleta.
- Es seguro eliminar las políticas de seguridad no utilizadas de la configuración una vez que ya no se haga referencia a ellas.
Incluso sin actualizaciones atómicas, se pueden realizar actualizaciones seguras secuenciando adecuadamente el proceso de actualización. Este método funciona mejor para asignaciones independientes que no están estrechamente relacionadas con otras asignaciones.
Recomendamos realizar actualizaciones incrementales en lugar de actualizar todo el mapa a la vez. Por ejemplo, las actualizaciones incrementales de matrices y mapas hash son completamente seguras. Sin embargo, este no es el caso de las actualizaciones incrementales de un mapa de coincidencia de prefijo más largo (LPM), porque la búsqueda depende de elementos que ya están en el mapa. El mismo problema ocurre cuando la creación de una clave de búsqueda para otra tabla requiere operar con elementos de múltiples mapas.
Las capas de clasificación a menudo se implementan utilizando múltiples LPM y tablas hash, lo que proporciona un ejemplo de esta complejidad:
La búsqueda fluye desde la clasificación hasta LPM y el hash, y desde la clasificación hasta el procesamiento y el hash, con una descripción del problema de actualización de mapeo.
Estrategia de actualización 2: Reemplazo de mapeo
Para las asignaciones que no se pueden actualizar incrementalmente sin inconsistencia (como las asignaciones LPM), la mejor solución es reemplazar toda la asignación. Para reemplazar el mapeo del programa eBPF, necesita un mapeo del mapeo. Una aplicación de espacio de usuario puede crear un nuevo mapa, completarlo con las entradas necesarias y luego reemplazar atómicamente el mapa anterior.
El mapeo mapeado da como resultado dos nodos con capacidades de reemplazo y aislamiento de recursos.
Dividir la configuración en mapas separados, cada uno de los cuales describe la configuración de una sola entidad, proporciona el beneficio adicional del aislamiento de recursos y elimina la necesidad de volver a crear la configuración completa durante actualizaciones menores. La configuración de cada entidad múltiple se puede almacenar en un mapa reemplazable.
Este método tiene algunas desventajas. El espacio de usuario necesita desanclar la asignación anterior para mantener la ruta fija anterior, porque la asignación de reemplazo no se puede fijar en la misma ubicación que la asignación anterior. Esto es especialmente importante para programas a largo plazo que actualizan con frecuencia su configuración y dependen de la fijación de mapas para su estabilidad.
Estrategia de actualización 3: Reemplazo del programa
El método de reemplazo de mapas puede fallar al vincular varios mapas. La actualización de la asignación por sí sola puede dar como resultado un estado inconsistente o no válido que no refleje ni la configuración anterior ni la nueva configuración esperada.
Para resolver este problema, las actualizaciones atómicas deberían realizarse en un nivel superior. Aunque eBPF carece de un mecanismo para reemplazar atómicamente un conjunto de asignaciones, las asignaciones generalmente están vinculadas a un programa eBPF específico. Este problema se puede resolver dividiendo las asignaciones interconectadas y el código correspondiente en programas eBPF separados vinculados por llamadas finales.
Canalización de paquetes al diagrama de flujo de mapeo de programas, lo que resulta en código reemplazable y paquetes de mapeo para programas eBPF.
Lograr esto requiere cargar un nuevo programa eBPF, crear y completar la asignación para él, fijar ambos y luego actualizar la asignación del programa desde el espacio del usuario. Este proceso es más laborioso que el simple reemplazo de mapeo, pero permite que el mapeo y el código asociado se actualicen simultáneamente, lo que facilita los ajustes del código en tiempo de ejecución. Sin embargo, usar este enfoque no siempre es particularmente eficiente, especialmente cuando se usan múltiples mapas y subrutinas para actualizar una única entrada de mapa en un programa complejo.
Manejo de errores
Manejar errores al administrar eBPF puede ser complicado. Es importante actualizar la configuración para evitar inconsistencias. Si se produce un error durante una actualización, puede causar caos, por lo que tener copias de seguridad automáticas puede ayudar a reducir la necesidad de realizar correcciones manuales.
Puede dividir los errores en dos categorías: errores recuperables y errores irrecuperables. Para errores recuperables, si algo sale mal durante una actualización, simplemente puede detenerla y no se realizarán cambios. Puedes corregir cualquier error sin riesgo.
Los errores irrecuperables son un poco más complicados. Debe manejarlos con cuidado, ya que pueden afectar entidades de configuración específicas, lo que puede dañar todo el sistema.
Es mejor organizar las actualizaciones por entidad de configuración en lugar de por tipo de actualización. De esta forma, si se produce un error, sólo afectará a una entidad de configuración específica y no a todo a la vez. Por ejemplo, si se definen reglas de clasificación y políticas de seguridad para diferentes segmentos de red, sería más eficiente actualizarlas en ciclos separados según el segmento de red en lugar de por tipo de actualización. Esto facilita el manejo de copias de seguridad automatizadas y, si ocurre un error irrecuperable, sabrá exactamente cuál es el impacto. Solo una parte de la red se configura de manera inconsistente, mientras que el resto no se ve afectado o puede cambiarse rápidamente a una nueva configuración.
Administre el ciclo de vida del programa eBPF para obtener actualizaciones
El seguimiento del ciclo de vida de un programa eBPF es fundamental para los programas que requieren persistencia, actualizaciones frecuentes y retención de estado en diferentes instancias de código. Por ejemplo, si su programa XDP requiere actualizaciones frecuentes de código mientras mantiene las sesiones de clientes existentes, administrar su ciclo de vida de manera efectiva es fundamental.
Para los desarrolladores que desean maximizar la flexibilidad y evitar restricciones, el objetivo debe ser retener sólo información importante entre recargas: datos que no se pueden recuperar del almacenamiento no volátil. De esta manera, puede utilizar asignaciones de eBPF para ajustes de configuración dinámica.
Para que el proceso de recarga de código activo sea más sencillo, debe poder distinguir entre mapas de estado y de configuración, reutilizar el mapa de estado durante la recarga y volver a llenar el mapa de configuración desde el almacenamiento no volátil. La transición del procesamiento del programa antiguo al nuevo y notificar a todos los usuarios de mapeo eBPF sobre los cambios puede ser un poco engorroso.
Hay dos formas comunes de implementar transiciones:
- Reemplazo de programa atómico : este método implica conectar un programa XDP directamente a una interfaz de red e intercambiarlo atómicamente durante una actualización. Puede que este no sea el más apropiado para programas eBPF grandes y complejos que interactúan con una gran cantidad de programas y mapas de espacio de usuario.
- Un enfoque similar a libxdp : el programa planificador se vincula a la interfaz de red y utiliza llamadas de cola para realizar el procesamiento en el siguiente programa en el mapa de programas donde se realiza el procesamiento real. Además de gestionar el uso y la fijación del mapa, coordina varios controladores, lo que permite transiciones rápidas entre ellos.
La tarjeta de interfaz de red (NIC) se conecta al programador, al mapa del programa y al mapa de estado, lo que da como resultado la configuración real del programa.
El proceso de recarga en caliente detecta y corrige rápidamente problemas de configuración y vuelve rápidamente a una versión estable anterior si es necesario. Para escenarios complejos como las pruebas A/B, el programador puede usar tablas de clasificación para dirigir tráfico específico a nuevas versiones del programa XDP.
en conclusión
A través de la programación eBPF/XDP, Gcore ha superado los límites de la seguridad de la red y la optimización del rendimiento. Nuestro viaje demuestra nuestro compromiso de combatir las amenazas emergentes a través de capacidades avanzadas de eBPF/XDP. A medida que continuamos mejorando nuestro núcleo de procesamiento de paquetes, nos comprometemos a ofrecer soluciones de vanguardia que ayuden a mantener las redes de nuestros clientes sólidas y ágiles.
Decidí renunciar al código abierto Hongmeng Wang Chenglu, el padre del código abierto Hongmeng: El código abierto Hongmeng es el único evento de software industrial de innovación arquitectónica en el campo del software básico en China: se lanza OGG 1.0, Huawei contribuye con todo el código fuente. Google Reader es asesinado por la "montaña de mierda de código" Ubuntu 24.04 LTS se lanza oficialmente Antes del lanzamiento oficial de Fedora Linux 40, desarrolladores de Microsoft: el rendimiento de Windows 11 es "ridículamente malo", Ma Huateng y Zhou Hongyi se dan la mano, "eliminando rencores" Conocidas empresas de juegos han emitido nuevas regulaciones: los obsequios de boda de los empleados no deben exceder los 100.000 yuanes Pinduoduo fue sentenciado por competencia desleal Indemnización de 5 millones de yuanesEste artículo se publicó por primera vez en Yunyunzhongsheng ( https://yylives.cc/ ), todos son bienvenidos a visitarlo.