A las tres de la madrugada, recibí un mensaje de texto de alerta y me levanté para echar un vistazo: el número de conexiones WebSocket se disparó hasta el pico, y la CPU del servidor directamente se arrodilló. Los atacantes se basan en el protocolo WS características de conexión de largo, difícil de arrastrar el negocio - en estos días, incluso la comunicación en tiempo real tienen que llevar chalecos antibalas.
Mucha gente piensa que un conjunto de CDN en todo está bien, hasta que el ataque de inundación WebSocket a través de los ojos. CDN de alta defensa en el final no puede prevenir WebSocket... He demolido la arquitectura de siete proveedores, directamente a la conclusión: los principales proveedores son compatibles, pero la configuración de la fosa más que suficiente para ser capaz de caer muerto.
El propio protocolo WebSocket es un “fantasma”. Abandona el modo solicitud-respuesta de HTTP y lo sustituye por una conexión larga full-duplex, lo que significa que la estrategia tradicional de almacenamiento en caché CDN y la limitación de velocidad son casi inválidas. Los atacantes sólo necesitan establecer una conexión para seguir consumiendo recursos del servidor, el coste del DDoS es diez veces inferior al del HTTP.
He probado la configuración por defecto de un proveedor: tras activar la compatibilidad con WebSocket, no se ajusta el tiempo de espera de la conexión. El atacante establece 100.000 conexiones largas y mantiene cada conexión durante 15 minutos, agotando directamente los recursos del back-end. Si una CDN de alta defensa sólo protege contra HTTP, equivale a instalar una cerradura acorazada en la puerta pero dejar un agujero para el perro.
Una protección verdaderamente fiable debe cumplir tres puntos: capacidad de reconocimiento de protocolos, control del comportamiento de las conexiones y filtrado de la lógica empresarial. cdn5 ha hecho un gran trabajo en este ámbito: no sólo reconoce los protocolos WS/WSS, sino que también detecta anomalías en los paquetes de latido de conexión. El año pasado fuimos atacados por un pool de minería de criptomonedas, y nos basamos en su biblioteca de huellas de tráfico para cortar las conexiones maliciosas.
La clave de la configuración no es tan sencilla como marcar la casilla “Activar WebSocket” en la interfaz. En el caso de CDN07, por ejemplo, hay que ajustar simultáneamente las cuatro capas de protección:
No te creas los “valores por defecto inteligentes” de los que hablan los vendedores. Una vez fui perezoso y utilicé directamente la configuración por defecto, el resultado fueron 3000 nuevas peticiones de conexión por segundo directamente al umbral. Más tarde, configuré manualmente el número máximo de conexiones por IP a 20, y el número de conexiones anormales cayó en picado a 90%.
La estrategia de 08Host es aún más radical: soporta el análisis profundo del protocolo WebSocket. No sólo puede detectar anomalías en el protocolo SSL, sino también verificar el contenido de las tramas de datos WebSocket. Tras haber encontrado ataques CC con cifrado de la capa de transporte, su motor de reglas descarta con precisión los paquetes maliciosos mediante la coincidencia de códigos de características de carga.
Detrás de la guerra de precios se esconde una trampa de rendimiento. Un vendedor barato afirmó “soporte con todas las funciones”, el uso real de la latencia WebSocket encontrado hasta 200ms. desempaquetar sólo para encontrar que sus nodos hacen la conversión de protocolo: el tráfico WS en HTTP respuesta en trozos, el nombre de la optimización de la compatibilidad.
La comparación del rendimiento real depende de tres conjuntos de datos: retardo en el establecimiento de la conexión, estabilidad de la conexión a largo plazo y eficacia en la interceptación de ataques. Hemos probado a presión los nodos de Hong Kong de los tres:
CDN5 primer apretón de manos promedio 87ms, 10.000 conexiones para mantener las fluctuaciones de latencia ≤ 15ms; CDN07 conexión más rápida (62ms), pero anti-ataque cuando la CPU picos significativos; 08Host equilibrada óptima, especialmente en el rendimiento de descarga SSL por delante de 40%.
El efecto de protección también depende de la batalla real. Una plataforma de juegos sufrió un ataque de reflexión WS, el atacante falsificó la IP de origen para enviar un gran número de paquetes pequeños, la estrategia de protección de CDN5 habilitó directamente la limitación de velocidad + detección de longitud de paquetes, una sola IP más de 50 paquetes por segundo activó inmediatamente la verificación hombre-máquina.
Lo más lamentable es la “falsa protección” de algunos vendedores: sólo en la capa TCP para hacer la limpieza de tráfico, completamente al margen de los protocolos de la capa de aplicación, los ataques WebSocket penetran como de costumbre, post-venta también tiró la olla, dijo que “el código de negocio tiene problemas”. Más tarde, cambié a usar la protección de siete capas de CDN07, y añadí esta regla para curarlo:
La protección de la capa de negocio es el arma definitiva. El año pasado, un proyecto financiero fue atacado por el abuso de la API WS, y el atacante simuló clientes normales para enviar solicitudes de transacciones de alta frecuencia. Al final, las reglas personalizadas de CDN5 rompieron el juego: detectando el número de peticiones por minuto de una sola conexión, y obligando a la conexión que supera el umbral a desconectarse y piratear la IP.
Ahora elija una CDN de alta defensa debe ver los detalles de protección WebSocket: ¿si soporta el límite de longitud de conexión? ¿Puede identificar la suplantación de protocolo? ¿Existe algún vínculo de control de riesgos empresariales? Un proveedor puede incluso acoplar el sistema de control de viento auto-construido, la emisión en tiempo real de las instrucciones de interceptación - esta ha sido la capacidad del nivel WAF.
En una nota ofensiva: los problemas de protección WebSocket de 90% provienen de una mala configuración. El incidente más escandaloso que he visto fue el de un ingeniero que olvidó desactivar una regla de prueba y bloqueó todas las conexiones legítimas al entorno de producción. Realmente no es que el proveedor no pueda hacerlo, es que mucha gente ni siquiera entiende la consola.
En el futuro, los ataques evolucionarán definitivamente hacia protocolos híbridos, con WebSocket sobre HTTP/2 y abusos del protocolo QUIC que ya circulan en el mercado negro. Lo menos que puedes hacer es asegurarte de que el proveedor actualiza las reglas de protección mensualmente. La base de datos de inteligencia de amenazas de 08Host se actualiza tres veces por semana, lo que supone un verdadero alivio.
Si está seleccionando un modelo, recuerde estas tres reglas de hierro: la prueba debe ser presionado WS rendimiento, el contrato especifica el índice de protección, y regularmente hacer ejercicios de ataque y defensa. No espere a que la empresa se derrumbe para comprobar los documentos, la protección de la comunicación en tiempo real nunca es un proyecto de conmutación, sino una confrontación continua.
La protección de WebSocket ya no es una cuestión de “hacer o no hacer”, sino una carrera de “qué tan detallado hacer”. Las principales CDN están acumulando modelos de aprendizaje automático para desenterrar patrones de ataque a partir del comportamiento de las conexiones. La próxima vez que se encuentre con ventas que alardeen de una protección QPS de un millón de niveles, pregúntese directamente: ¿con qué granularidad se pueden prevenir los ataques WS long connection CC?
La tecnología es en última instancia una herramienta, la verdadera protección radica en la comprensión profunda de la lógica de negocio. Todavía mantengo el hábito: cada servicio WS en línea, debe utilizar Slowloris, WS-Attacker herramienta de auto-prueba. No hay una bala de plata para la seguridad, pero una CDN de alta seguridad al menos nos da derecho a llevar una armadura.
