Cuán profundas son las aguas de la industria del ajedrez, lo saben los que se han metido en ella. Los DDoS golpean como un perro rabioso, pero los más insidiosos suelen ser los ataques lentos que te van machacando poco a poco: no son tan rimbombantes como un ataque por inundación, sino más bien como hervir una rana en agua tibia, y cuando te quieres dar cuenta, hace tiempo que los servidores están paralizados.
El año pasado, ayudé a una plataforma de ajedrez para hacer la respuesta de emergencia, su operación y mantenimiento en un primer momento también confía: “ancho de banda es suficiente, las reglas de firewall se apilan”. El resultado de una mirada en el monitor, la CPU no explotó, el tráfico no se disparó, pero el usuario está atascado maldiciendo. Por último, el análisis de paquetes sólo para encontrar que hay una IP lentamente cada 30 segundos para enviar un encabezado de paquete HTTP, pellizco de conexión en manos de los muertos no dejar ir, un servidor por cientos de este tipo de conexiones para agotar los recursos.
Lo desagradable de este ataque HTTP lento es que parece demasiado “normal”. Un cortafuegos tradicional podría dejarlo pasar, porque cada petición por sí sola se ajusta a la especificación del protocolo. Pero el atacante se basa en esta “lentitud” para agotar su reserva de conexiones, su reserva de hilos y, en última instancia, impedir que los usuarios normales accedan.
No cuentes con un cortafuegos de hardware para solucionar esto.. De hecho, he comprobado que cierta marca de cortafuegos de hardware multimillonario con política predeterminada casi no responde a los ataques de Slowloris, porque detecta picos de tráfico, no duraciones de conexión. Lo que realmente puede soportar la carga es también una CDN de alta seguridad combinada con un control preciso del tiempo de espera y un análisis del comportamiento.
Vamos a empezar con la configuración de tiempo de espera de solicitud. No es sólo una cuestión de cambiar `keepalive_timeout` en Nginx. Tienes que dividirlo en varias dimensiones basadas en las características del negocio: tiempo de espera de establecimiento de la conexión, tiempo de espera de recepción del encabezado, tiempo de espera de transmisión del cuerpo, tiempo de espera de conexión inactiva. Por ejemplo, para el negocio del ajedrez, la solicitud HTTP general debe ser completado dentro de 2 segundos, WS larga conexión puede mantener el nivel de minutos, pero debe haber un mecanismo de latido del corazón bajo el capó.
Tomando como ejemplo la configuración de Nginx, suelo ponerla en capas de la siguiente manera:
Pero eso por sí solo no basta. Algunos atacantes envían intencionadamente el cuerpo a una velocidad lenta, como 1 byte por segundo. Esta vez es necesario establecer una política de control de flujo global en el nodo de borde CDN. Como CDN5 esta casa ha hecho el desglose: 10 segundos no pasó el tamaño del cuerpo por defecto (como 1KB) directamente desconectado, y no ocupa la piscina de conexión back-end.
Aún más despiadada es la interceptación de comportamientos anómalos. Los ataques lentos son difíciles de defender porque una sola petición parece inofensiva. Pero si se observan varias peticiones en contexto, el diablo está en los detalles.
Normalmente capto anomalías en tres dimensiones:velocidad de conexión(Los usuarios normales no siguen creando nuevas conexiones sin enviar solicitudes),velocidad de transmisión(Los usuarios normales no tardan 10 minutos en pasar un paquete de inicio de sesión),Distribución del tiempo de supervivencia(Mientras que las sesiones de usuarios de ajedrez suelen fluctuar, las conexiones de ataque tienden a ser inusualmente estables).
El equipo de algoritmos de CDN07 ha desarrollado un conjunto de bibliotecas de funciones específicamente diseñadas para detectar este tipo de comportamiento de “falsa lentitud”. Por ejemplo, se detecta una IP que establece una conexión cada 10 segundos, pero cada conexión sólo envía 5 bytes y luego permanece en silencio, más de 10 veces consecutivas directamente en el proceso de desafío. La tasa de eliminación medida es inferior a 0,1%, pero puede interceptar variantes de ataque lento de 99%.
Otro truco es hacer una suma de comprobación de la integridad del protocolo. Muchas herramientas de ataque lento tienen en realidad implementaciones de protocolo defectuosas (por ejemplo, omiten deliberadamente ciertos campos de cabecera). Podemos preconstruir la lógica de la suma de comprobación en la CDN:
Por supuesto, la estrategia anterior debe aplicarse con flexibilidad. Por ejemplo, las interfaces API y las conexiones largas WS deben tratarse de forma diferente. Los nodos específicos de ajedrez de 08Host hacen una identificación inteligente: utilizan un tiempo de espera estricto (10 segundos) para la ruta /api/, y permiten conexiones largas para la ruta /ws/, pero exigen que el intervalo entre paquetes heartbeat no sea superior a 25 segundos.
Nunca te dejes llevar por una única solución. Hubo una vez un cliente que compró un CDN de un fabricante importante y pensó que todo iría bien, pero fue penetrado por Slowloris. Más tarde, descubrió que la configuración de tiempo de espera por defecto de la CDN era demasiado floja (se permitían 120 segundos de conexión inactiva). Más tarde, trabajamos con la política personalizada de CDN5 para reducir el umbral de tiempo de espera a 15 segundos y, al mismo tiempo, habilitamos su “Modo de aprendizaje de conexión lenta”: primero deja pasar 24 horas para establecer una línea de base y, después, intercepta automáticamente las IP que se desvían del comportamiento de la línea de base.
Por último, me gustaría mencionar un escollo: una configuración demasiado agresiva del tiempo de espera puede perjudicar erróneamente a los usuarios lentos de la red. Mi experiencia es combinar la política geográfica, por ejemplo, para los usuarios nacionales con un tiempo de espera uniforme de 10 segundos, para los usuarios del sudeste asiático relajar a 20 segundos, al mismo tiempo con el centro de gravedad algoritmo para determinar - si la IP del usuario está muy lejos de la distancia física, pero la latencia es muy baja, la probabilidad de que se trata de una falsificación de tráfico transfronterizo.
En la práctica también me gusta enterrar algunas estacas ocultas. Por ejemplo, en la configuración de la CDN mezclar unos pocos dominios fríos como cebo, estos dominios sólo serán escaneados por los atacantes, los usuarios normales nunca los visitarán. Una vez que se descubre que estos dominios tienen intentos de conexión lentos, bloquea directamente todo el segmento ASN. Este truco me ha ayudado a detener varias oleadas de ataques dirigidos.
Al final, la prevención de ataques lentos es como la captura de lochas, no sólo puede confiar en el bloqueo duro, tienes que aprender a “escuchar el sonido de la posición”.ventaja de CDN es que puede ver el tráfico global, combinado con el control de tiempo de espera y análisis de comportamiento, y con frecuencia se puede encontrar en el ataque temprano en la plántula. Pero recuerde, no hay una solución de una vez por todas, las reglas eficaces de hoy pueden ser eludidas el próximo mes, así que asegúrese de dejar un canal para la investigación manual y el juicio - el juicio de la máquina 70% sospechoso en el empuje de alarma, para que la gente tome la decisión final.
Si utiliza CDN07 o 08Host, recuerde indagar en el backend para encontrar su módulo de protección contra ataques lentos (algunos de ellos están ocultos en “Seguridad avanzada” o “Reglas personalizadas”). La mayoría de los clientes ni siquiera saben que existen estas funciones, y es un desperdicio de la prima anual. Después de todo, en estos días, incluso el CDN tiene que “evitar que los compañeros de equipo” - no para evitar que los atacantes, es para evitar que su propia no va a utilizar.
