Recientemente, he ayudado a una estación de comercio electrónico para hacer la respuesta de emergencia, y me encontré con una cosa mala - el servidor no se cayó, el ancho de banda no se ejecutó completo, pero el sitio web estaba tan atascado que ni siquiera podía iniciar sesión en el fondo. Después de medio día de investigación, me encontré con que los hackers en estos días están empezando a jugar "trabajo lento": cada conexión con usted para moler media hora, miles de usuarios falsos pueden ocupar el grupo de conexión simultánea, los usuarios serios simplemente no puede ser exprimido pulg
Este ataque lento (Slowloris) se aprovecha de los puntos débiles de los cortafuegos tradicionales. WAFs ordinarios se centran en los picos de tráfico y la frecuencia de las solicitudes, pero este ataque cada solicitud se disfraza de tráfico legítimo, como el agua que gotea a través de la piedra como drenar lentamente sus recursos. He probado un firewall corriente, la configuración por defecto es en realidad un solo cliente con un ataque POST lento arrastrado hacia abajo el servidor back-end.
Si una CDN de alta defensa puede o no evitar esto depende de dos puntos clave: si puede identificar con precisión la solicitud de "molienda", y si se atreve a tomar la iniciativa para cortar las conexiones anormales. La siguiente parte de la integración real del programa de CDN5, CDN07 dos vendedores de la lógica subyacente, por cierto, escupir algunos vendedores de fantasía, pero no el uso de la función.
Empecemos por el ajuste del tiempo de espera de las peticiones. Esto no es un simple conjunto de un tiempo de espera global en el extremo de la cuestión, debe ser controlado en diferentes niveles. Los clientes frontales a los nodos de borde CDN, los nodos de borde a la estación de origen, la política de tiempo de espera de los dos enlaces tienen que ajustarse por separado. No crea a esos vendedores que alardean de "tiempo de espera inteligente", he rastrillado la configuración por defecto de CDN07, el tiempo de espera por defecto del front-end está relajado a 300 segundos, es simplemente una puerta trasera para ataques lentos.
Esta es la forma recomendada de segmentar la configuración (usando Nginx como ejemplo):
Preste especial atención al parámetro client_body_timeout - ataque POST lento es pasando lentamente el cuerpo de la solicitud para consumir recursos. La prueba encontró que más de 30 segundos no ha terminado de transferir el cuerpo de la solicitud, 99,9% es una conexión maliciosa. Hay un pozo para recordar: algunos proveedores de CDN ajustes de tiempo de espera de la consola ocultos en la "configuración avanzada", el valor predeterminado es demasiado alto, recuerde bajar manualmente.
Sin embargo, sólo confiar en el tiempo de espera para interceptar dañará erróneamente la carga normal de archivos grandes. El año pasado, cuando realizamos pruebas de penetración para 08Host, descubrimos que establecían el tiempo de espera de forma demasiado agresiva, lo que provocaba que el diseñador no pudiera cargar archivos PSD todo el tiempo. Más tarde, añadimos una política de tiempo de espera dinámico: la ruta /content/upload se relaja a 120 segundos, mientras que otras rutas mantienen 30 segundos. Este movimiento CDN5 hacer bastante inteligente, el apoyo para el establecimiento de umbrales de tiempo de espera por ruta URL.
Una jugada más avanzada es la identificación de comportamientos anómalos. Los ataques lentos, aunque imitan a los usuarios normales, exponen características en la capa de protocolo. Por ejemplo, un usuario normal no enviaría un byte sólo cada 30 segundos ni mantendría 500 conexiones inactivas continuamente. Hemos desplegado un conjunto de reglas de detección en CDN07, y la lógica central consiste en contar la "eficacia de conexión" de cada IP:
Este conjunto de reglas es particularmente precisa en la captura de ataques lentos, pero hay que tener cuidado de distinguir entre los rastreadores y los usuarios reales. Algunos rastreadores de motores de búsqueda se ralentizará deliberadamente para evitar molestar al sitio, hemos sufrido la pérdida de erróneamente bloqueado - más tarde añadió una lista blanca, el Googlebot verificado para relajar la política.
Lo que realmente me salva son los módulos de programación inteligente de CDN5. No se limitan a mirar el tiempo de espera, sino que también lo combinan con el análisis del estado de la pila TCP. Por ejemplo, si de repente hay un gran número de conexiones TCP atascadas en el estado LAST_ACK, o la cola SYN_RECV sigue llena, el sistema activará automáticamente el modo de limpieza de ataque lento. Esta característica se mide para reducir 70% intervención manual, es el precio es un poco hermoso.
Respuesta de emergencia también encontró una operación de mal gusto: algunos atacantes utilizarán HTTP lento + baja velocidad CC ataque combo. El primero dio cuenta de la piscina de conexión no deja ir, al mismo tiempo con los ataques de CC de baja velocidad para consumir la CPU, esta vez a CDN07 mecanismo de defensa de vinculación entró en juego - cuando la detección de conexiones lentas y solicitudes de baja frecuencia desde el mismo segmento IP, directamente negro todo el segmento C, en lugar de matar erróneamente no ser perdonados.
Por último, una sugerencia real: no espere confiar únicamente en la CDN para evitar todos los ataques lentos. En el lado del cliente, hemos hecho tres capas de defensa: capa de borde CDN para el bloqueo de tiempo de espera, capa WAF para el análisis de comportamiento, e iptables para la limitación de conexiones concurrentes en el servidor de origen. En concreto, el ajuste de los parámetros del kernel de Linux puede triplicar la capacidad del servidor para resistir ataques lentos:
Los ataques lentos no pueden impedir la esencia de la guerra por el consumo de recursos. El año pasado, probamos la capacidad de tres proveedores de CDN para resistir velocidades lentas, y CDN5 ganó gracias a los pools de recursos elásticos: amplía automáticamente el límite de conexión cuando se detecta un ataque, y libera recursos después de que el ataque se detiene.08Host es el más realista, aunque la función no es tan elegante, pero la configuración por defecto es más segura que otras, y es adecuada para sitios web pequeños y medianos que no quieren hacer un gran alboroto.
Los hackers son cada vez más sofisticados y ya utilizan ataques lentos distribuidos: cada broiler sólo abre unas pocas conexiones lentas y no se diferencia en nada de un usuario normal. En el futuro, me temo que tendremos que utilizar el aprendizaje automático para analizar los patrones de comportamiento de los usuarios. En este momento, sin embargo, con la configuración correcta de los tiempos de espera y la detección de anomalías se ha podido acabar con el ataque lento 90%. Recuerda, la política de seguridad no es tan complicada, la clave está en ser capaz de implementarla.
Para evaluar el CDN de alta defensa, le recomendamos que construya su propio entorno para probar: utilice la herramienta slowhttptest para simular el ataque, para ver si el informe de la consola puede alarmar con precisión, la política de limpieza es realmente eficaz. No crea en el alarde de ventas "100% de protección", he probado un importante paquete de alta defensa, las reglas por defecto ni siquiera detuvieron el ataque lento básico - al final, usted tiene que ajustar manualmente las reglas.
La seguridad web es un proceso iterativo de ataque y defensa. Una estrategia que funciona hoy puede ser burlada mañana. Mantener la transparencia de la configuración y ensayar regularmente respuestas de emergencia es mucho más realista que amontonar productos de seguridad. Después de todo, hoy en día, incluso los CDN tienen que "prevenir a los compañeros de equipo" - algunos vendedores con el fin de reducir la tasa de falsos positivos, relajan intencionadamente las políticas de seguridad, las cosas van mal en lugar de volcar el tarro a la mala configuración del cliente.
