Nos complace anunciar la disponibilidad general de las sesiones de cliente Zero Trust. Durante la CIO Week de 2021, anunciamos el programa beta para esta función. Hemos incorporado los comentarios de los primeros usuarios a la versión disponible para el público general. En esta publicación, volveré a explicar por qué son importantes las sesiones de cliente Zero Trust, cómo funciona la función y lo que hemos aprendido durante la versión beta.

Diseñamos las sesiones de cliente Zero Trust para mejorar la seguridad del acceso a la red Zero Trust (ZTNA) de Cloudflare. El cliente Zero Trust es un software que se ejecuta en el equipo de un usuario y reenvía todo el tráfico del equipo a Cloudflare antes de que se envíe por Internet. Esto incluye el tráfico destinado a las direcciones IP y nombres de host internos que suelen albergar aplicaciones empresariales con información confidencial. Tradicionalmente se accedía a estas aplicaciones confidenciales con una VPN. A diferencia de las VPN, la solución ZTNA de Cloudflare permite que los administradores establezcan políticas granulares sobre quién puede acceder a un recurso específico. La única pieza que faltaba era que una vez que un usuario registraba su equipo con el cliente Zero Trust, la sesión se quedaba abierta para siempre. Debido a esto, los portátiles perdidos o robados, las estaciones de trabajo compartidas y los dispositivos personales suponían un riesgo mayor del debido. Creamos sesiones basadas en el cliente Zero Trust para solucionarlo.

Las sesiones de cliente Zero Trust requieren que el usuario se vuelva a autenticar con su proveedor de identidad antes de poder acceder a determinados recursos. La ventana emergente de autenticación solo se activa cuando un usuario intenta acceder a un recurso protegido. Con esto, se evitan ventanas emergentes innecesarias para los usuarios, en los casos en los que no sea necesaria una sesión. Los administradores pueden especificar la frecuencia con la que quieren que sus usuarios se vuelvan a autentificar, en función del recurso. Esto es posible porque se guarda la última autenticación correcta del usuario, y se evalúa con respecto a cualquier política de ZTNA con una sesión configurada.

Durante la versión beta de las sesiones de cliente Zero Trust, hemos trabajado estrechamente con nuestros clientes y con el propio equipo de seguridad de Cloudflare para identificar las áreas que necesitaban una mejora inmediata. Identificamos dos áreas principales de mejora antes de abrirlo al público general: las ventanas emergentes, que pueden llegar a ser molestas, y la autenticación basada en el navegador, que no siempre es posible. Identificamos nuevas estrategias para servir correctamente una ventana emergente de autenticación a un usuario sin que fuera demasiado molesta. En el futuro, los usuarios podrán controlar cuándo reciben las notificaciones para autenticarse. La otra área de mejora era que, en ciertos equipos y sistemas operativos, la autenticación basada en el navegador no siempre era posible. Tenemos planeado añadir una opción para autenticar directamente desde el propio cliente Zero Trust.

Esto es solo el comienzo de la autenticación basada en el cliente Zero Trust. En el futuro, tenemos planeado añadir opciones para la autenticación multifactor escalonada, y opciones de inscripción automatizada mediante certificados y tokens de servicio. ¡Empezar es fácil! Consulta esta guía para configurar sesiones basadas en el cliente Zero Trust en tu panel de control Cloudflare Zero Trust.

En los últimos nueve años, hemos creado una red global sólida y escalable que actualmente se extiende a 193 ciudades en más de 90 países y se sigue expandiendo. Todos los clientes de Cloudflare se benefician con este alcance gracias a dos técnicas importantes. La primera es la red de direccionamiento anycast. Cloudflare fue uno de los primeros en adoptarla, y utilizó esta técnica de enrutamiento para distribuir el tráfico de internet a través de nuestros centros de datos. Esto significa que cualquier centro de datos puede manejar el tráfico de cualquier cliente, y podemos crear nuevos centros de datos sin la necesidad de adquirir y suministrar nuevas direcciones IP. La segunda técnica es la arquitectura de servidor homogénea. Todos los servidores en cada uno de nuestros centros de datos periféricos puede ejecutar cada tarea. Construimos nuestros servidores en hardware básico, lo que permite aumentar rápidamente nuestra capacidad de procesamiento mediante la adición de nuevos servidores a los centros de datos existentes. Al no tener que depender de un hardware especial, hemos adquirido experiencia en ir hasta el límite de lo posible en las redes utilizando técnicas modernas del núcleo Linux.

Magic Transit se ha creado en la misma red utilizando las mismas técnicas, lo que significa que nuestros clientes ahora pueden ejecutar sus funciones de red en Cloudflare. Nuestra ventaja global rápida, segura y confiable se convierte en una ventaja para nuestros clientes. Para ver cómo funciona, sigamos el recorrido de un paquete desde un usuario en internet hasta la red de un cliente de Magic Transit.

En announcement blog post describimos un ejemplo de implementación para Acme Corp. Continuemos con este ejemplo aquí. Cuando Acme trae su prefijo de IP 203.0.113.0/24 a Cloudflare, comenzamos a anunciar ese prefijo a nuestros proveedores de tránsito, colegas y a los intercambios de internet en cada uno de nuestros centros de datos de todo el mundo. Además, Acme deja de anunciar el prefijo a sus propios ISP. Esto significa que cualquier paquete de IP en internet con una dirección de destino dentro del prefijo de Acme se entrega a un centro de datos de Cloudflare cercano, no al enrutador de Acme.

Supongamos que quiero acceder al servidor FTP de Acme en 203.0.113.100 desde mi computadora en la oficina de Cloudflare en Champaign, IL. Mi computadora genera un paquete TCP SYN con la dirección de destino 203.0.113.100 y lo envía a Internet. Gracias a anycast, ese paquete termina en el centro de datos de Cloudflare en Chicago, que es el centro de datos más cercano (en cuanto a distancia de enrutamiento de internet) a Champaign. El paquete llega en el enrutador del centro de datos, que utiliza el enrutamiento ECMP (Multitrayecto de igual costo) para seleccionar qué servidor debe administrar el paquete y enviarlo al servidor seleccionado.

Una vez en el servidor, el paquete fluye a través de nuestras funciones de detección y mitigación de DoS XDP e iptables. Si se determina que este paquete TCP SYN forma parte de un ataque, se descartaría y sería el fin de este. Afortunadamente para mí, el paquete puede pasar.

Hasta ahora, esto es exactamente igual que cualquier otro tráfico en la red de Cloudflare. Debido a nuestra experiencia en la gestión de una red anycast global, podemos atraer el tráfico de clientes de Magic Transit a cada centro de datos y aplicar la misma solución de mitigación de DoS que ha estado protegiendo a Cloudflare durante años. Nuestra solución de DoS ha controlado algunos de los ataques más grandes que se registraron, lo que incluye un ataque SYN de 942 Gbps en 2018. A continuación se muestra una captura de pantalla de un reciente ataque SYN de 300 millones de paquetes por segundo. Nuestra arquitectura nos permite escalar para detener los ataques más grandes.

Lo anterior es idéntico a la forma en que se procesa todo el resto del tráfico de Cloudflare, pero aquí es donde se acaban las similitudes. Para nuestros otros servicios, el paquete TCP SYN ahora se enviaría a un proceso de proxy local (por ejemplo, nuestra pila HTTP/S en nginx). Para Magic Transit, queremos suministrar y aplicar de manera dinámica funciones de red definidas por el cliente como firewalls y enrutamiento. Necesitábamos una manera de acelerar y configurar estas funciones de red, y al mismo tiempo proporcionar un aislamiento entre redes. Para ello, recurrimos a los espacios de nombres de red.

Los espacios de nombres son una serie de características del núcleo Linux para crear instancias virtuales ligeras de recursos del sistema que se pueden compartir entre un grupo de procesos. Los espacios de nombres son un componente fundamental para la contenerización en Linux. En particular, Docker se crea en espacios de nombres de Linux. Un espacio de nombres de red es una instancia aislada de la pila de la red Linux, que incluye sus propias interfaces de red (con sus propios ganchos eBPF), tablas de enrutamiento, configuración de netfilter, etc. Los espacios de nombres de red nos proporcionan un mecanismo de bajo costo para aplicar rápidamente configuraciones de red definidas por el cliente en forma aislada, con las características integradas del núcleo Linux para que el rendimiento no se vea afectado por el reenvío de paquetes del espacio de usuario o el proxy.

Cuando un nuevo cliente comienza a usar Magic Transit, creamos un nuevo espacio de nombres de red para ese cliente en todos los servidores de nuestra red perimetral (¿mencioné que cada servidor puede ejecutar cada tarea?). Creamos un daemon que se ejecuta en nuestros servidores y se encarga de administrar estos espacios de nombres de red y sus configuraciones. Este daemon lee constantemente las actualizaciones de configuración de Quicksilver, nuestra tienda clave distribuida a nivel global, y aplica las configuraciones definidas por el cliente para firewalls, enrutamiento, etc., dentro del espacio de nombres del cliente. Por ejemplo, si Acme desea suministrar una regla de firewall para permitir el tráfico de FTP (puertos TCP 20 y 21) a 203.0.113.100, esa configuración se propaga a nivel global a través de Quicksilver y el daemon de Magic Transit aplica la regla de firewall mediante la adición de una regla nftables al espacio de nombres del cliente Acme:

# Apply nftables rule inside Acme’s namespace
$ sudo ip netns exec acme_namespace nft add rule inet filter prerouting ip daddr 203.0.113.100 tcp dport 20-21 accept

# Aplicar regla nftables en el espacio de nombres de Acme

$ sudo ip netns exec acme_namespace nft add rule inet filter prerouting ip daddr 203.0.113.100 tcp dport 20-21 accept

Llevar el tráfico del cliente a su espacio de nombres de red requiere una configuración de enrutamiento en el espacio de nombres de red predeterminado. Cuando se crea un espacio de nombres de red, también se crea un par de interfaces ethernet virtuales (veth): una en el espacio de nombres predeterminado y la otra en el espacio de nombres recién creado. Este par de interfaz crea un "cable virtual” para enviar el tráfico de red dentro y fuera del nuevo espacio de nombres de red. En el espacio de nombres de red predeterminado, mantenemos una tabla de enrutamiento que reenvía los prefijos de IP del cliente de Magic Transit a las veth que corresponden a los espacios de nombres de esos clientes. Utilizamos iptables para marcar los paquetes que están destinados a los prefijos del cliente de Magic Transit, y tenemos una regla de enrutamiento que especifica que estos paquetes marcados especialmente deben utilizar la tabla de enrutamiento de Magic Transit.

(¿Por qué tomarse la molestia de marcar los paquetes en iptables y mantener una tabla de enrutamiento separada? Aislamiento. Al mantener separadas las configuraciones de enrutamiento de Magic Transit, reducimos el riesgo de modificar accidentalmente la tabla de enrutamiento predeterminada y afectar el flujo del tráfico que no es de Magic Transit en nuestra periferia).

Los espacios de nombres de red ofrecen un entorno ligero donde un cliente de Magic Transit puede ejecutar y administrar funciones de red de manera aislada, lo que nos permite poner el control total en manos del cliente.

Después de pasar las funciones de red perimetral, el paquete TCP SYN está listo finalmente para ser entregado nuevamente a la infraestructura de red del cliente. Debido a que Acme Corp. no tiene un espacio físico de red en una instalación con Cloudflare, necesitamos enviar su tráfico de red a través de la internet pública.

Esto plantea un problema. La dirección de destino del paquete TCP SYN es 203.0.113.100, pero la única red que anuncia el prefijo IP 203.0.113.0/24 en internet es Cloudflare. Esto significa que no podemos simplemente reenviar este paquete a internet, ¡ya que volvería a nosotros como un bumerán! Para enviar este paquete a Acme necesitamos utilizar una técnica que se denomina tunelización.

La tunelización es un método que permite transportar tráfico desde una red a través de otra red. En nuestro caso, esto implica la encapsulación de los paquetes de IP de Acme dentro de los paquetes de IP que se pueden enviar al enrutador de Acme a través de internet. Hay una serie de protocolos de tunelización comunes, pero la encapsulación de enrutamiento genérico (GRE) se utiliza con frecuencia por su simplicidad y el soporte generalizado que brindan los proveedores.

Los extremos del túnel de GRE se configuran tanto en los servidores de Cloudflare (dentro del espacio de nombres de red de Acme) como en el enrutador de Acme. Luego, los servidores de Cloudflare encapsulan los paquetes de IP con destino a 203.0.113.0/24 dentro de los paquetes de IP con destino a una dirección IP enrutable públicamente para el enrutador de Acme, que desencapsula los paquetes y los libera en la red interna de Acme.

Ahora bien, he omitido un detalle importante en el diagrama anterior: la dirección IP del lado de Cloudflare del túnel de GRE. La configuración de un túnel de GRE exige la especificación de una dirección IP para cada lado, y el encabezado IP externo para los paquetes enviados por el túnel debe utilizar estas direcciones específicas. Pero Cloudflare tiene miles de servidores, cada uno de los cuales puede necesitar el envío de paquetes al cliente a través de un túnel. Entonces, ¿con cuántas direcciones IP de Cloudflare (y túneles de GRE) necesita hablar el cliente? La respuesta: solo una, gracias a la magia de anycast.

Cloudflare utiliza direcciones IP de anycast para los extremos de nuestro túnel de GRE, lo que significa que cualquier servidor en cualquier centro de datos puede encapsular y desencapsular paquetes para el mismo túnel de GRE. ¿Cómo es posible? ¿Un túnel no es un enlace de extremo a extremo? El protocolo GRE en sí es un protocolo sin estado, cada paquete se procesa de manera independiente y no se necesita ninguna negociación o coordinación entre los extremos del túnel. Si bien el túnel está técnicamente vinculado a una dirección IP, no necesita estar vinculado a un dispositivo específico. Todo dispositivo que pueda quitar los encabezados externos y luego enrutar el paquete interno puede administrar cualquier paquete de GRE enviado por el túnel. En realidad, en el contexto de anycast el término “túnel” resulta confuso, ya que implica un enlace entre dos puntos fijos. Con GRE de Anycast de Cloudflare, un único “túnel” le brinda un conducto a cada servidor en cada centro de datos en el perímetro global de Cloudflare.

Una ventaja muy importante del GRE de Anycast es que elimina las fallas individuales que luego generan una falla global. Tradicionalmente, el GRE en internet puede resultar un problema, ya que un corte de internet entre los dos extremos del GRE rompe completamente el “túnel”. Esto significa que para enviar datos de manera segura es necesario configurar y mantener túneles de GRE adicionales que terminen en diferentes sitios físicos y volver a enrutar el tráfico cuando uno de los túneles se rompe. Pero como Cloudflare encapsula y envía el tráfico de los clientes desde cada uno de los servidores de cada centro de datos, si se rompe un “túnel”, están los adicionales. Esto significa que los clientes de Magic Transit pueden aprovechar la redundancia y la fiabilidad de las terminales de los túneles en varios sitios físicos y configurar y mantener un único extremo de GRE, lo que simplifica sus trabajos.

Magic Transit es una manera novedosa y potente de implementar funciones de red a escala. No solo le brindamos una instancia virtual, le ofrecemos una ventaja virtual a nivel global. Magic Transit toma los componentes de hardware que usted normalmente colocaría en la red en sus instalaciones y los distribuye entre todos los servidores de cada centro de datos en la red de Cloudflare. Esto le brinda acceso a nuestra red de anycast global, a nuestra flota de servidores con capacidad de ejecutar sus tareas y a nuestra experiencia en ingeniería para construir redes rápidas, confiables y seguras. Nuestra escala ahora es su escala.

Aquí presentamos una transcripción de una versión ligeramente adaptada de esa charla.

En Cloudflare, ejecutamos Linux en nuestros servidores. Operamos dos categorías de centros de datos: los centros de datos “básicos” grandes, donde procesamos registros, analizamos ataques y hacemos cálculos analíticos, y la flota de servidores “perimetrales”, que envían contenido de clientes desde 180 ubicaciones en todo el mundo.

En esta charla, nos concentraremos en los servidores “perimetrales”. Es aquí donde utilizamos las características más recientes de Linux, optimizamos el rendimiento y nos ocupamos en gran medida de la resiliencia del DoS.

Nuestro servicio perimetral es especial debido a nuestra configuración de red, estamos utilizando ampliamente el enrutamiento anycast. Anycast significa que todos nuestros centros de datos anuncian la misma serie de direcciones IP.

Este diseño tiene enormes ventajas. En primer lugar, garantiza la velocidad óptima para los usuarios finales. Independientemente del lugar en que usted se encuentre, siempre llegará al centro de datos más cercano. Luego, anycast nos ayuda a extender el tráfico de DoS. Durante los ataques, cada una de las ubicaciones recibe una pequeña fracción del tráfico total, lo que facilita la asimilación y el filtrado del tráfico no deseado.

Anycast nos permite mantener la uniformidad de la configuración de red en todos los centros de datos perimetrales. Aplicamos el mismo diseño en nuestros centros de datos: nuestra pila de software es uniforme en todos los servidores perimetrales. Todas las piezas de software se ejecutan en todos los servidores.

En principio, cada equipo puede gestionar cada tarea, y nosotros ejecutamos una cantidad de tareas diversas y exigentes. Tenemos una pila HTTP completa, el mágico Cloudflare Workers, dos series de servidores DNS - autorización y resolución, y muchas otras aplicaciones públicas como Spectrum y Warp.

Si bien en cada servidor se está ejecutando todo el software, las solicitudes suelen pasar por muchas máquinas en su trayecto hacia la pila. Por ejemplo, una máquina diferente puede gestionar una solicitud HTTP durante cada una de las 5 etapas del procesamiento.

Permítanme guiarlos en las primeras etapas del procesamiento de paquetes entrantes:

(1) En primer lugar, los paquetes llegan a nuestro enrutador. El enrutador genera una multirruta de igual costo (ECMP) y reenvía los paquetes a nuestros servidores Linux. Utilizamos ECMP para distribuir cada IP de destino entre muchas máquinas, al menos 16. Esto se utiliza como una técnica rudimentaria de equilibrio de carga.

(2) En los servidores tomamos paquetes con eBPF de XDP. En XDP ejecutamos dos etapas. En primer lugar, ejecutamos mitigaciones de DoS volumétricas y eliminamos los paquetes que pertenecen a ataques muy grandes de la capa 3.

(3) Luego, aún en XDP, llevamos a cabo el equilibrio de carga de la capa 4. Todos los paquetes que no son de ataque se redirigen a través de los equipos. Esto se utiliza para solucionar los problemas de ECMP, nos da un equilibrio de carga de granularidad fina y nos permite sacar correctamente de servicio a los servidores.

(4) Después de la redirección, los paquetes llegan a un equipo designado. En este punto, la pila de redes de Linux normal los toma, pasan por el firewall de iptables habitual y se envían a un socket de red adecuado.

(5) Por último, una aplicación recibe los paquetes. Por ejemplo, las conexiones HTTP son manejadas por un servidor de “protocolo” encargado del cifrado TLS y el procesamiento de los protocolos HTTP, HTTP/2 y QUIC.

Es en estas primeras fases de procesamiento de solicitudes donde utilizamos las características nuevas más interesantes de Linux. Podemos agrupar las funciones modernas útiles en tres categorías:

• Control de DoS

• Equilibrio de carga

• Envío de sockets

Analicemos el control de DoS en más detalle. Como se mencionó anteriormente, el primer paso después del enrutamiento ECMP es la pila XDP de Linux donde, entre otras cosas, ejecutamos mitigaciones de DoS.

Históricamente, nuestras mitigaciones de ataques volumétricos se expresaban en la gramática clásica de estilo de iptables y BPF. Recientemente, hicimos una adaptación para ejecutar en el contexto de eBPF de XDP, lo que resultó ser increíblemente difícil. Siga leyendo sobre nuestras experiencias:

• L4Drop: Mitigaciones de DDoS XDP

• xdpcap: Captura de paquetes XDP

• Charla de mitigación de DoS en función de XDP de Arthur Fabre

• XDP en la práctica: integración de XDP en nuestra canalización de mitigación de DDoS(PDF)

Durante este proyecto nos encontramos con una serie de limitaciones de eBPF/XDP. Una de ellas fue la falta de primitivas de concurrencia. Resultó muy difícil implementar cosas como algoritmos token buckets sin competencia. Más tarde, descubrimos que la ingeniera de Facebook Julia Kartseva tenía los mismos problemas. En febrero, este problema se solucionó con la introducción de la aplicación auxiliar bpf_spin_lock.

Si bien nuestros modernos sistemas de defensa de ataques DoS volumétricos se hacen en la capa XDP, aún contamos con iptables para aplicar las mitigaciones de la capa 7. Aquí, resultan útiles las características de un firewall de nivel superior: connlimit, hashlimits e ipsets. También utilizamos el módulo de iptables xt_bpf para ejecutar cBPF en iptables que coincidan con las cargas útiles del paquete. Ya hablamos de esto antes:

• Lecciones de defensa de lo indefendible (PPT)

• Presentación de herramientas del BPF

Después de XDP e iptables, tenemos una última capa de defensa DoS del lado del núcleo.

Considere una situación en la que fallan nuestras mitigaciones del protocolo de datagramas de usuarios (UDP). En tal caso, podríamos recibir una avalancha de paquetes que llegan a al socket de UDP de nuestra aplicación. Esto podría desbordar el socket y generar la pérdida de paquetes. Esto es un problema, ya que se eliminarán indiscriminadamente tanto los paquetes buenos como los malos. Para aplicaciones como DNS esto resulta catastrófico. En el pasado, para reducir el daño ejecutamos un socket de UDP por dirección IP. Una inundación sin mitigar era algo malo, pero al menos no afectaba el tráfico a otras direcciones IP del servidor.

En la actualidad, esa estructura ya no resulta adecuada. Estamos ejecutando más de 30 000 IP DNS, y la ejecución de esa cantidad de sockets UDP no es una situación óptima. Nuestra solución actual es la ejecución de un único socket UDP con un filtro de socket eBPF complejo - utilizando la opción de socket SO_ATTACH_BPF. En publicaciones anteriores, hablamos sobre la ejecución de eBPF en sockets de red:

• eBPF, sockets, distancia de salto y escritura manual de ensamblado de eBPF

• SOCKMAP - Empalme de TCP del futuro

El tipo de eBPF mencionado limita los paquetes. Mantiene el estado - recuento de paquetes - en un mapa de eBPF. Estamos seguros de que una sola IP inundada no afectará al resto del tráfico. Esto funciona bien, sin embargo, mientras trabajábamos en este proyecto encontramos un error bastante preocupante en el verificador de eBPF:

• ¡¿eBPF no puede contar?!

Supongo que ejecutar eBPF en un socket UDP no es una tarea común.

Aparte del DoS, en XDP también ejecutamos un equilibrador de carga de capa 4. Este es un proyecto nuevo, y aún no hemos hablado mucho de este. Sin entrar en tantos detalles: en ciertas ocasiones, necesitamos hacer una búsqueda de socket desde XDP.

El problema es relativamente simple - nuestro código necesita buscar la estructura del núcleo del “socket” para una tupla-5 extraída de un paquete. Por lo general, esto es fácil - hay una asistencia bpf_sk_lookup disponible para esto. Como era de esperar, hubo algunas complicaciones. Un problema fue la incapacidad de verificar si un paquete ACK recibido era una parte válida del protocolo de enlace de tres vías cuando se activan las cookies SYN. Mi colega Lorenz Bauer está trabajando para lograr más apoyo para este caso fuera de lo habitual.

Después de la denegación de servicio (DoS) y las capas de equilibrio de carga, los paquetes pasan a la pila de TCP / UDP de Linux habitual. Aquí hacemos un envío de socket - por ejemplo, los paquetes que van al puerto 53 pasan a un socket que pertenece a nuestro servidor DNS.

Hacemos todo lo posible por utilizar características estándar de Linux, pero las cosas se vuelven complejas cuando se usan miles de direcciones IP en los servidores.

Convencer a Linux para enrutar paquetes correctamente es bastante fácil con el truco “AnyIP. Verificar que los paquetes se envían a la aplicación correcta es otra cuestión. Lamentablemente, la lógica de envío de sockets Linux estándar no es lo suficientemente flexible para nuestras necesidades. Para puertos populares como TCP/80 queremos compartir el puerto entre varias aplicaciones, cada una de las cuales lo maneja en un rango de IP diferente. Linux no es compatible de manera directa. Usted puede llamar enlazar() a una dirección IP específica o a todas las IP (con 0.0.0.0).

Para solucionar este inconveniente, desarrollamos un parche de núcleo personalizado que agrega una opción de socket SO_BINDTOPREFIX. Como su nombre lo indica, nos permite llamar enlazar() un prefijo de IP seleccionado. Esto resuelve el problema de aplicaciones múltiples que comparten puertos populares como 53 u 80.

Luego nos encontramos con otro problema. Para nuestro producto Spectrum, necesitamos escuchar en los 65535 puertos. Ejecutar tantos sockets de escucha no es una buena idea (ver nuestro viejo blog con historias de guerras), por lo tanto, tuvimos que encontrar otra manera. Después de algunos experimentos, aprendimos a utilizar un módulo de iptables no muy conocido - TPROXY - para este propósito. Leer sobre este aquí:

• Abuso del firewall de Linux: el hack que nos permitió crear Spectrum

Esta configuración está funcionando, pero no nos gustan las reglas de firewall adicionales. Estamos trabajando para resolver correctamente este problema, en realidad estamos ampliando la lógica de envío de socket. Adivinó, queremos extender la lógica de envío de socket mediante la utilización de eBPF. Estamos desarrollando algunos parches.

Luego, hay una manera de utilizar eBPF para optimizar las aplicaciones. Recientemente, nos interesamos en el empalme de TCP con SOCKMAP:

• SOCKMAP - Empalme de TCP del futuro

Esta técnica ofrece un gran potencial para mejorar la latencia de cola en muchas piezas de nuestra pila de software. La implementación de SOCKMAP actual aún no está lista para el horario de mayor tráfico, pero el potencial es enorme.

Del mismo modo, los nuevos enlaces TCP-BPF también conocidos como BPF_SOCK_OPS ofrecen una excelente manera de inspeccionar los parámetros de rendimiento de los flujos de TCP. Esta funcionalidad resulta muy útil para nuestro equipo de rendimiento.

Algunas características de Linux no soportaron bien el paso del tiempo y tenemos que trabajar en esto. Por ejemplo, estamos llegando a los límites de las métricas de red. No quiero que me malinterprete: las métricas de red son increíbles, pero lamentablemente no tienen la granularidad suficiente. Cosas como TcpExtListenDrops y TcpExtListenOverflows se informan como contadores globales, y nosotros necesitamos la información de cada aplicación.

Nuestra solución es utilizar un sondeo de eBPF para extraer los números directamente del núcleo. Mi colega Ivan Babrou desarrolló un exportador de métricas Prometheus que se llama “ebpf_exporter” para facilitar esto. Seguir leyendo:

• Presentación de ebpf_exporter

• https://github.com/cloudflare/ebpf_exporter

Con “ebpf_exporter”, podemos generar todo tipo de métricas detalladas. Es muy potente y nos salvó en muchas ocasiones.

En esta charla analizamos las 6 capas del BPF que se ejecutan en nuestros servidores perimetrales:

• Las mitigaciones de DoS volumétricas se ejecutan en eBPF de XDP

• Iptables xt_bpf cBPF para ataques de capas de aplicaciones

• SO_ATTACH_BPF para límites de velocidad en sockets UDP

• Equilibrador de carga, que se ejecuta en XDP

• Auxiliares de aplicaciones que se ejecutan en eBPF como SOCKMAP para el empalme de socket TCP y TCP-BPF para mediciones de TCP

• “ebpf_exporter” para métricas granulares

¡Y eso es solo el comienzo! Pronto haremos más con el envío de socket basado en eBPF, eBPF que se ejecuta en la capa Linux TC (Control de tráfico) y más integración con enlaces eBPF para cgroup. Además, nuestro equipo de ingeniería de confiabilidad del sitio (SRE) lleva una lista cada vez más extensa de scripts BCCqué resulta útil para la depuración.

Parece que Linux dejó de desarrollar nuevas API y todas las características nuevas se implementan como auxiliares y enlaces eBPF. Esto está bien y presenta muchas ventajas. Es más fácil y seguro actualizar el programa de eBPF que tener que volver a compilar un módulo del núcleo. Algunas cosas como TCP-BPF, que exponen un gran volumen de datos de seguimiento del rendimiento, probablemente serían imposibles sin eBPF.

Algunos afirman que “el software se está comiendo el mundo”, yo diría que: “el BPF se está comiendo el software”.

Imagen CC BY 2.0 por Isaí Moreno

Sin embargo, no se le ha prestado la atención suficiente a un tema: las inundaciones SYN. Utilizamos Linux y resulta que el manejo de paquetes SYN en Linux es verdaderamente complejo. En esta publicación revelaremos información para aclarar este tema.

En primer lugar, debemos entender que cada socket enlazado, en el estado TCP de “ESCUCHA” tiene dos colas separadas:

• La cola SYN

• La cola de aceptación

En los textos, a estas colas se les suelen dar otros nombres como “reqsk_queue”, “registro de ACK”, “registro de escucha” o incluso “registro de TCP”, pero usaré los nombres anteriores para evitar confusiones.

La cola SYN almacena los paquete SYN entrantes[1] (en concreto: struct inet_request_sock). Se encarga de enviar paquetes SYN+ACK y de reintentar el envío en el tiempo de espera. En Linux, el número de reintentos se configura con lo siguiente:

$ sysctl net.ipv4.tcp_synack_retries
net.ipv4.tcp_synack_retries = 5

Los documentos describen esta alternancia:

tcp_synack_retries - INTEGER

	Number of times SYNACKs for a passive TCP connection attempt
	will be retransmitted. Should not be higher than 255. Default
	value is 5, which corresponds to 31 seconds till the last
	retransmission with the current initial RTO of 1second. With
	this the final timeout for a passive TCP connection will
	happen after 63 seconds.

Después de transmitir el SYN+ACK, la cola SYN espera un paquete ACK del cliente: el último paquete en el protocolo de enlace de tres vías. Todos los paquetes ACK que se reciben primero se deben hacer coincidir con la tabla de conexiones totalmente establecida, y solo después con los datos en la cola SYN correspondiente. En la coincidencia de cola SYN, el núcleo elimina el elemento de la cola SYN, establece una conexión completa (en concreto: struct inet_sock), y lo agrega a la cola de aceptación.

La cola de aceptación tiene conexiones completamente establecidas: listas para que la aplicación las tome. Cuando un proceso anuncia aceptar(), los sockets se eliminan de la cola y pasan a la aplicación.

Esta es una visión bastante simplificada del manejo de paquetes SYN en Linux. Con la alternancia de sockets como TCP_DEFER_ACCEPT[2] y TCP_FASTOPEN, las cosas funcionan un poco diferente.

La longitud máxima permitida de ambas colas Accept y SYN se toma del parámetro registro que la aplicación transmite a la llamada del sistema escucha(2). Por ejemplo, esto determina los tamaños de la cola Accept y SYN en 1,024:

listen(sfd, 1024)

listen(sfd, 1024)

Importante: en los núcleos anteriores a 4.3, la longitud de la cola SYN se consideró de manera diferente.

$ sysctl net.core.somaxconn
net.core.somaxconn = 16384

Este límite de cola SYN solía ser configurado por la alternancia net.ipv4.tcp_max_syn_backlog,, pero ya no se hace de este modo. Actualmente net.core.somaxconn limita ambos tamaños de cola. En nuestros servidores lo establecemos en 16k:

Teniendo en cuenta todo eso, podríamos hacer la siguiente pregunta: ¿cuál es el valor ideal del parámetro de registro?

La respuesta es la siguiente: depende. Para la mayoría de los servidores TCP triviales, realmente no es importante. Por ejemplo, antes de la versión 1.11 Golang no respaldó, como es de público conocimiento, la personalización del registro. Sin embargo, hay razones válidas para incrementar este valor:

• Cuando el ritmo de las conexiones entrantes es realmente importante, incluso con una aplicación de rendimiento, es posible que la cola SYN entrante necesite un mayor número de espacios.

• El valor del registro controla el tamaño de la cola SYN. Esto efectivamente se puede leer como “paquetes ACK en proceso”. Cuanto mayor sea el tiempo promedio de ida y vuelta al cliente, más espacios se utilizarán. En el caso de muchos clientes que están lejos del servidor, a cientos de milisegundos de distancia, tiene sentido aumentar el valor del registro.

• La opción TCP_DEFER_ACCEPT hace que los sockets permanezcan en el estado SYN-RECV por más tiempo y contribuyan con los límites de cola.

Exceder el registro también es malo:

• Cada espacio en la cola SYN utiliza cierta memoria. Durante una inundación SYN no tiene sentido desperdiciar recursos en el almacenamiento de paquetes de ataque. Cada entrada struct inet_request_sock en la cola SYN utiliza 256 bytes de memoria en el núcleo 4.14.

$ ss -n state syn-recv sport = :80 | wc -l
119
$ ss -n state syn-recv sport = :443 | wc -l
78

Para dar un vistazo a la cola SYN en Linux, podemos utilizar el comando ss y buscar los sockets SYN-RECV. Por ejemplo, en uno de los servidores de Cloudflare podemos ver 119 espacios que se utilizan en la cola tcp/80 SYN y 78 en tcp/443.

Se pueden mostrar datos similares con nuestro overenginered SystemTap script: resq.stp.

¿Qué sucede si la aplicación no puede mantener el ritmo rápido de la llamada de aceptación()?

¡Aquí es cuando sucede la magia! Cuando la cola de aceptación está completa (tiene un tamaño de registro+1) entonces:

• Los paquetes SYN entrantes a la cola SYN se caen.

• Los paquetes ACK entrantes a la cola SYN se caen.

• El contador TcpExtListenOverflows / LINUX_MIB_LISTENOVERFLOWS se incrementa.

• El contador TcpExtListenDrops / LINUX_MIB_LISTENDROPS se incrementa.

Hay una sólida razón para descartar los paquetes entrantes: es un mecanismo de rechazo. La otra parte, tarde o temprano, reenviará los paquetes SYN o ACK, y para ese entonces se espera que la aplicación lenta se haya recuperado.

Este es el comportamiento que se desea para la mayoría de los servidores. Para completar: se puede ajustar con la alternancia global net.ipv4.tcp_abort_on_overflow, pero es mejor no tocarlo.

Si su servidor necesita manejar una gran cantidad de conexiones entrantes y tiene problemas con la aceptación() del rendimiento, lea nuestra publicación Ajuste de Nginx / Distribución de trabajo de Epoll y un seguimiento que muestre scripts útiles de SystemTap.

$ nstat -az TcpExtListenDrops
TcpExtListenDrops     49199     0.0

Puede rastrear las estadísticas de desbordamiento de la cola de aceptación mediante el análisis de los contadoresnstat:

$ ss -plnt sport = :6443|cat
State   Recv-Q Send-Q  Local Address:Port  Peer Address:Port
LISTEN  0      1024                *:6443             *:*

Este es un contador global. No es lo ideal: a veces veíamos que aumentaba cuando el estado de todas las aplicaciones no tenía problemas. El primer paso siempre debe ser imprimir los tamaños de la cola de aceptación con ss:

La columna Recv-Q muestra la cantidad de sockets en la cola de aceptación, y Send-Q muestra el parámetro de registro. En este caso, vemos que no hay sockets pendientes de aceptación(), pero aún vemos el incremento del contador ListenDrops.

$ sudo stap -v acceptq.stp
time (us)        acceptq qmax  local addr    remote_addr
1495634198449075  1025   1024  0.0.0.0:6443  10.0.1.92:28585
1495634198449253  1025   1024  0.0.0.0:6443  10.0.1.92:50500
1495634198450062  1025   1024  0.0.0.0:6443  10.0.1.92:65434
...

Resulta que nuestra aplicación se atascó por fracciones de segundo. Esto fue suficiente para que la cola de aceptación se desbordara por un período de tiempo muy breve. Momentos después se recuperaría. Los casos como este son difíciles de solucionar con ss, así que escribimos un acceptq.stp SystemTap script a modo de ayuda. Se enlaza en el núcleo e imprime los paquetes SYN que se están cayendo:

Aquí usted puede ver con precisión qué paquetes SYN se vieron afectados por ListenDrops. Con este script, no tiene importancia entender qué aplicación está eliminando conexiones.

Imagen CC BY 2.0 por internets_dairy

Si es posible que se desborde la cola de aceptación, también puede ser posible que se desborde la cola SYN. ¿Qué sucede en ese caso?

De esto se tratan los ataques de inundación SYN. En la última inundación, la cola SYN con paquetes SYN falsificados fue un verdadero problema. Antes de 1996, se podía denegar el servicio de prácticamente cualquier servidor TCP con muy poco ancho de banda, solo con completar las colas SYN.

La solución es Cookies SYN. Las cookies SYN son una construcción que permite que SYN+ACK se genere sin estado, sin guardar en realidad el SYN entrante ni desperdiciar la memoria del sistema. Las cookies SYN no interrumpen el tráfico legítimo. Cuando la otra parte es real, responderá con un paquete ACK válido que incluye el número de secuencia reflejado, que se puede verificara nivel criptográfico.

Las cookies SYN se activan de manera predeterminada cuando es necesario - para sockets con una cola SYN completa. Linux actualiza un par de contadores en las cookies SYN. Cuando se envía una cookie SYN:

• TcpExtTCPReqQFullDoCookies / LINUX_MIB_TCPREQQFULLDOCOOKIES se incrementa.

• TcpExtSyncookiesSent / LINUX_MIB_SYNCOOKIESSENT se incrementa.

• Linux solía incrementar TcpExtListenDrops pero eso no sucede desde el núcleo 4.7.

Cuando un ACK entrante se dirige a la cola SYN con cookies SYN activadas:

• TcpExtSyncookiesRecv /  LINUX_MIB_SYNCOOKIESRECV se incrementa cuando la validación de criptografía es correcta.

• TcpExtSyncookiesFailed / LINUX_MIB_SYNCOOKIESFAILED se incrementa cuando se produce un error en la criptografía.

Un sysctl net.ipv4.tcp_syncookies puede desactivar las cookies SYN o forzar las activaciones. El valor predeterminado es bueno, no lo cambie.

+----------+--------+-------------------+
|  6 bits  | 2 bits |     24 bits       |
| t mod 32 |  MSS   | hash(ip, port, t) |
+----------+--------+-------------------+

La magia de las cookies SYN funciona, pero existen ciertas desventajas. El principal problema es que se pueden guardar muy pocos datos en una cookie SYN. En concreto, solo 32 bits del número de secuencia se devuelven en el ACK. Estos bits se utilizan de la siguiente manera:

Con la configuración de MSS reducida a solo 4 valores distintos, Linux no conoce ningún parámetro TCP opcional de la otra parte. La información sobre marcas de tiempo, ECN, ACK selectivos o escalado de ventana se pierde y puede disminuir el rendimiento de la sesión de TCP.

+-----------+-------+-------+--------+
|  26 bits  | 1 bit | 1 bit | 4 bits |
| Timestamp |  ECN  | SACK  | WScale |
+-----------+-------+-------+--------+

f, Linux ha trabajado en este tema. Si las marcas de tiempo de TCP están activadas, el núcleo puede reutilizar otro espacio de 32 bits en el campo de marcas de tiempo. Contiene:

$ sysctl net.ipv4.tcp_timestamps
net.ipv4.tcp_timestamps = 1

Las marcas de tiempo de TCP deben estar activadas de manera predeterminada, para verificar el sysctl:

Históricamente, se ha debatido mucho sobre la utilidad de las marcas de tiempo de TCP.

• Anteriormente, las marcas de tiempo generaban pérdidas del tiempo activo del servidor (si eso es importante sería tema d). Esto se solucionó hace 8 meses.

• Las marcas de tiempo de TCP utilizan una cantidad insignificante de ancho de banda - 12 bytes en cada paquete.

• Pueden agregar aleatoriedad a las sumas de comprobación del paquete, lo que puede ayudar con cierto hardware dañado.

• Como se mencionó anteriormente, las marcas de tiempo de TCP pueden aumentar el rendimiento de las conexiones TCP si se activan las cookies SYN.

Actualmente, en Cloudflare las marcas de tiempo de TCP están desactivadas.

Por último, con las cookies SYN activadas, algunas características interesantes no funcionarán, como por ejemplo [TCP_SAVED_SYN](https://lwn.net/Articles/645128/), TCP_DEFER_ACCEPT oTCP_FAST_OPEN.

Las cookies SYN son un excelente invento y resuelven el problema de las inundaciones SYN de menor magnitud. Sin embargo, en Cloudflare, tratamos de evitarlas en la medida de lo posible. Si bien el envío de un par de miles de paquetes SYN+ACK verificables a nivel criptográfico por segundo se puede hacer correctamente, vemos ataques de más de 200 millones de paquetes por segundo. En esta proporción, nuestras respuestas SYN+ACK simplemente llenarían la internet de basura, sin generar ningún beneficio.

En lugar de hacer esto, tratamos de eliminar los paquetes SYN maliciosos en la capa de firewall. Usamos las huellas digitales SYN p0f compiladas para BPF. Puede obtener más información en esta publicación del blog Introducción al compilador p0f BPF. Para detectar e implementar las mitigaciones, hemos desarrollado un sistema de automatización que denominamos “Gatebot”. Lo describimos aquí Conoce a Gatebot - el bot que nos permite dormir

Para obtener más información, un poco desactualizada, sobre el tema, lea una excelente explicación de Andreas Veithen de 2015 y un documento exhaustivo de Gerald W. Gordon de 2013.

El panorama del manejo de paquetes SYN de Linux evoluciona constantemente. Hasta hace poco, las cookies SYN eran lentas debido a un bloqueo obsoleto en el núcleo. Esto se solucionó en 4.4 y ahora usted puede confiar en el núcleo para enviar millones de cookies SYN por segundo, y resolver prácticamente el problema de inundación SYN de la mayoría de los usuarios. Con el ajuste adecuado, es posible mitigar incluso las inundaciones SYN más fastidiosas sin afectar el rendimiento de las conexiones legítimas.

El rendimiento de las aplicaciones también está recibiendo una atención considerable. Ideas recientes como SO_ATTACH_REUSEPORT_EBPF introducen una capa totalmente nueva de programabilidad en la pila de red.

Resulta extraordinario ver cómo las innovaciones y los pensamientos renovados se canalizan en la pila de redes en un mundo de sistemas operativos que de otra manera estaría estancado.

Agradecemos a Binh Le por colaborar con esta publicación.

¿Está tratando de que los aspectos internos de Linux y NGINX suenen interesantes? Únase a nuestro equipo de reconocimiento internacionalen Londres, Austin, San Francisco y nuestra selecta oficina en Varsovia, Polonia.

1. Estoy simplificando, técnicamente hablando, la cola SYN almacena las conexiones aún no ESTABLECIDAS, no paquetes SYN sí. Aunque con TCP_SAVE_SYN se acerca lo suficiente. ↩︎

2. Si TCP_DEFER_ACCEPT es nuevo para usted, definitivamente verifique la versión de FreeBSD - acepta filtros. ↩︎SYN TCP Programación