[Análisis técnico] En profundidad y fácil de entender: Introducción al ataque y defensa en red

Los ataques DDoS (Denegación de Servicio Distribuida) son uno de los más potentes y difíciles de defender, ya que el principal objetivo de los ataques DDoS es impedir que un objetivo designado preste servicios normales o incluso desaparezca de Internet.

Los DDoS pueden dividirse simplemente en tres categorías según la forma en que se inicien.

La primera categoría gana por la fuerzaEnormes paquetes de datos inundan desde todos los rincones de Internet, bloqueando la entrada a IDC, haciendo inútiles varios sistemas de defensa hardware potentes y procesos de emergencia rápidos y eficientes. Ejemplos típicos de este tipo de ataque son ICMP Flood y UDP Flood, que ahora son poco comunes.

La segunda categoría gana por astucia, inteligente e imperceptible, enviar un paquete cada pocos minutos o incluso solo necesitar un paquete puede hacer que el lujoso servidor de configuración deje de responder. Este tipo de ataque se lanza principalmente explotando vulnerabilidades en protocolos o software, como ataques Slowloris, ataques de colisión de hash, etc., y requiere coincidencias ambientales específicas.

La tercera categoría es una mezcla de las dos anterioresNo solo aprovecha los defectos del protocolo y del sistema, sino que también tiene una gran cantidad de tráfico, como el ataque SYN Flood y el ataque DNS Query Flood, que es el método de ataque actual y corriente.

Este artículo describirá uno a uno estos métodos de ataque más comunes y representativos y presentará sus opciones de defensa.

SYN Flood es uno de los ataques DDoS más clásicos en Internet, apareciendo por primera vez alrededor de 1999, siendo Yahoo la víctima más famosa en ese momento. Los ataques SYN Flood explotan fallos de triple handshake TCP que pueden dejar el servidor objetivo insensible y difícil de rastrear a un coste pequeño.

El proceso estándar de apretón de manos TCP de tres vías es el siguiente:

• El cliente envía un paquete TCP que contiene la bandera SYN, SYN está sincronizado y el paquete de sincronización indica el puerto utilizado por el cliente y el número de serie inicial de la conexión TCP.
• Tras recibir el paquete SYN del cliente, el servidor devolverá un paquete SYN+ACK (es decir, confirmación de acuse de reconocimiento), indicando que la solicitud del cliente ha sido aceptada y que el número de serie inicial TCP se añade automáticamente por 1.
• El cliente también devuelve un mensaje de acuse de acuse de recibo ACK al servidor, y el número de serie TCP también se añade con 1.
  

Tras estos tres pasos, se establece la conexión TCP. Para lograr una transmisión fiable, el protocolo TCP ha establecido algunos mecanismos de manejo de excepciones durante los tres apretones de mano. En el tercer paso, si el servidor no recibe el paquete final de acuse de acuse de recibo ACK del cliente, el servidor permanecerá en el estado SYN_RECV, añadirá la dirección IP del cliente a la lista de espera y reenviará el paquete SYN+ACK en el segundo paso. Las republicaciones suelen realizarse entre 3 y 5 veces, y la lista de espera se consulta una vez con intervalos de unos 30 segundos para reprobar a todos los clientes. Por otro lado, después de que el servidor envía el paquete SYN+ACK, preasigna recursos para almacenar información para la próxima conexión TCP, que se mantiene mientras se espera el nuevo intento. Más importante aún, si los recursos del servidor son limitados, el estado SYN_RECV que se pueda mantener dejará de aceptar nuevos paquetes SYN tras superar el límite, es decir, nuevas conexiones TCP serán rechazadas.

SYN Flood utiliza los ajustes del protocolo TCP mencionados anteriormente para lograr el propósito del ataque. Los atacantes disfrazan un gran número de direcciones IP para enviar paquetes SYN al servidor y, dado que las direcciones IP falsificadas son casi imposibles de existir, casi ningún dispositivo responderá al servidor. Como resultado, el servidor mantiene una enorme lista de espera y sigue intentando enviar paquetes SYN+ACK, lo que consume muchos recursos y no puede liberarse. Más importante aún, la cola SYN_RECV del servidor atacado está llena de paquetes maliciosos, ya no se aceptan nuevas solicitudes SYN, y los usuarios legítimos no pueden completar tres apretones de mano para establecer conexiones TCP. En otras palabras, el servidor fue denegado al servicio por SYN Flood.

Si te interesa SYN Flood, puedes echar un vistazo al http://www.icylife.net/yunshu/show.php?id=367, que escribí en 2006, y que más tarde hice varios cambios, corrigió errores y redujo la agresividad, y se usó únicamente para pruebas.

Como el servicio más básico y fundamental de Internet, el DNS es, naturalmente, uno de los objetivos importantes de los ataques DDoS. Dejar caer un servicio DNS puede afectar indirectamente todo el negocio de una empresa o un servicio de red en una región. Hace algún tiempo, el popular grupo de hackers anónimo también anunció que atacaría 13 servidores DNS en Internet global, pero al final no tuvo éxito.

Los ataques UDP son el método más sencillo para iniciar tráfico masivo, y la falsificación de IP de origen aleatorio es difícil de rastrear. Sin embargo, el filtrado es más fácil porque la mayoría de las IPs no proporcionan servicios UDP, así que puedes simplemente descartar el tráfico UDP. Por lo tanto, los ataques puramente de tráfico UDP son relativamente raros hoy en día y son reemplazados por ataques de Inundación de Consultas DNS llevados por el protocolo UDP. En pocas palabras, los ataques DDoS lanzados cuanto más alto es el protocolo, más difícil es defenderse de él, porque cuanto más alto es el protocolo, más relacionado con el negocio es y más complejo se enfrenta el sistema de defensa.

La inundación de consultas DNS ocurre cuando un atacante manipula un gran número de máquinas sockpuppet para lanzar un gran número de solicitudes de consulta de nombre de dominio al objetivo. Para evitar el filtrado basado en ACL, es necesario mejorar la aleatoriedad de paquetes. Una práctica común es falsificar aleatoriamente la dirección IP de origen, falsificar aleatoriamente el puerto fuente y otros parámetros en la capa UDP. En la capa del protocolo DNS, el ID de consulta se falsifica aleatoriamente junto con el nombre de dominio a resolver. Además de evitar filtrados, los nombres de dominio falsificados aleatorios también pueden reducir la probabilidad de acceder a la caché DNS y consumir la mayor cantidad posible de recursos de CPU del servidor DNS.

En cuanto al código de DNS Query Flood, escribí un código en julio de 2011 para probar el rendimiento del servidor, y el enlace es http://www.icylife.net/yunshu/show.php?id=832. De manera similar, este código es artificialmente menos agresivo y solo es para fines de prueba.

El SYN Flood y el DNS Query Flood descritos anteriormente pueden defenderse eficazmente en esta etapa, y el verdadero dolor de cabeza para los grandes fabricantes y empresas de Internet son los ataques HTTP Flood. HTTP Flood es un ataque a un servicio web en un protocolo de séptima capa. Su gran daño se manifiesta principalmente en tres aspectos: iniciación conveniente, filtrado difícil y un impacto de gran alcance.

Tanto SYN Flood como DNS Query Flood requieren que los atacantes controlen un gran número de bots con privilegios root. Se necesita tiempo y esfuerzo para obtener un gran número de privilegios root, y durante el ataque, la máquina títere tarda en reponerse debido a la rápida pérdida de recursos por parte del atacante debido al tráfico anormal detectado por el administrador, lo que resulta en una reducción significativa de la intensidad del ataque y no puede mantenerse durante mucho tiempo. Los ataques HTTP Flood son diferentes, los atacantes no necesitan controlar un gran número de bots, sino que utilizan escáneres de puertos para encontrar proxies HTTP anónimos o proxies SOCKS en Internet, a través de los cuales el atacante inicia solicitudes HTTP al objetivo del ataque. Los proxies anónimos son un recurso relativamente rico, y no es difícil conseguirlos en pocos días, por lo que los ataques son fáciles de iniciar y pueden durar mucho tiempo.

Por otro lado, los ataques de inundación HTTP se lanzan en la capa HTTP, que imita vigorosamente el comportamiento de peticiones de página web de los usuarios normales, lo cual está estrechamente relacionado con el negocio del sitio web, dificultando que los proveedores de seguridad proporcionen una solución común que no afecte a la experiencia del usuario. Reglas que funcionan bien en un solo lugar, cambiar de escenario puede llevar a un gran número de homicidios involuntarios.

Por último, los ataques de inundación HTTP pueden provocar reacciones en cadena graves, no solo provocando una respuesta lenta directamente del front-end web atacado, sino también atacando indirectamente la lógica de Java y otros servicios de base de datos de la capa de negocio y de base de datos back-end, aumentando su presión e incluso afectando a los servidores de almacenamiento de logs.

Curiosamente, HTTP Flood también tiene un apodo histórico llamado ataque CC. CC es una abreviatura de Challenge Collapsar, que es un dispositivo de protección DDoS de una conocida empresa de seguridad en China. A juzgar por la situación actual, no solo Collapsar, sino todo el equipo de defensa sigue siendo cuestionado, y el riesgo no se ha eliminado.

En cuanto a ataques, la primera reacción es un tráfico masivo y paquetes enormes. Pero hay un ataque que hace lo contrario, conocido por ser lento, de modo que algunos objetivos de ataque mueren sin saber cómo mueren, que es el ataque de conexión lento, el más representativo es Slowloris inventado por rsnake.

El protocolo HTTP estipula que las solicitudes HTTP terminan en \r\n\r\n, indicando que el cliente ha terminado de enviar y que el servidor ha comenzado a procesarse. ¿Y qué pasa si nunca envías \r\n\r\n? Slowloris aprovecha esto en ataques DDoS. El atacante configura la Conexión en Keep-Alive en la cabecera de la petición HTTP, pide al servidor web que mantenga la conexión TCP no desconectada y luego envía lentamente un formato clave-valor al servidor cada pocos minutos, como a:b\r\n, haciendo que el servidor piense que la cabecera HTTP no ha sido recibida y espere. Si un atacante utiliza multihilo o un títere para hacer lo mismo, el contenedor web del servidor se verá rápidamente saturado por el atacante y dejará de aceptar nuevas solicitudes.

Pronto, comenzaron a aparecer varias variantes de Slowloris. Por ejemplo, el método POST envía datos al servidor web, llena un gran contenido de longitud de contenido pero lento byte por byte de contenido real de datos POST, etc. En cuanto al ataque de Slowloris, rsnake también da un código de prueba, véase http://ha.ckers.org/slowloris/slowloris.pl.

Lo anterior introduce varios métodos básicos de ataque, cualquiera de los cuales puede usarse para atacar la red e incluso derrotar grandes sitios web como Alibaba, Baidu y Tencent. Pero eso no es todo, diferentes niveles de atacantes pueden lanzar ataques DDoS completamente distintos, y su uso es lo mismo.

Los atacantes avanzados nunca usan un solo vector para atacar, sino que los combinan de forma flexible según el entorno objetivo. El Flood SYN ordinario es fácil de filtrar mediante dispositivos de limpieza de tráfico mediante detección inversa, cookies SYN y otros medios técnicos, pero si los paquetes SYN+ACK se mezclan en SYN Flood, de modo que cada paquete SYN falsificado tiene un paquete de confirmación de cliente falsificado correspondiente, el correspondiente aquí se refiere a la dirección IP de origen, puerto fuente, IP de destino, puerto de destino, tamaño de ventana TCP, TTL, etc., todos están en línea con las características del mismo host y del mismo flujo TCP. La presión sobre el rendimiento de la detección inversa y las cookies SYN de los equipos de limpieza de flujo aumentará significativamente. De hecho, los paquetes de datos SYN y varios otros bits de bandera tienen efectos de ataque especiales, que no se introducen aquí. También existen técnicas únicas para el DNS Query Flood.

En primer lugar, el DNS puede dividirse en DNS ordinario y DNS de dominio autorizado, atacando el DNS ordinario, la dirección IP debe ser falsificada aleatoriamente y el servidor requiere resolución recursiva; Sin embargo, al atacar el DNS de dominio autorizado, la dirección IP de origen falsificada no debe ser puramente aleatoria, sino que debe ser las direcciones DNS de los ISP de todo el mundo recopiladas de antemano, para lograr el máximo efecto de ataque, de modo que el dispositivo de limpieza de tráfico se encuentre en la situación embarazosa de añadir o no la lista negra de IP. Añadirlo provocará un gran número de homicidios involuntarios, y si no añades una lista negra, cada paquete debe ser revisado al revés, lo que aumenta la presión de rendimiento.

Por otro lado, como se mencionó antes, para aumentar la presión de limpiar el dispositivo, es necesario aleatorizar el nombre de dominio solicitado sin acceder a la caché, pero debe señalarse que el nombre de dominio a resolver debe tener cierta regularidad en la falsificación, como falsificar solo una parte concreta del nombre de dominio y solidificar una pieza para romper la lista blanca establecida por el dispositivo de limpieza. La razón es sencilla: los servidores de Tencent solo pueden resolver los nombres de dominio de Tencent, y nombres de dominio completamente aleatorios pueden descartarse directamente y necesitar ser consolidados. Pero si está completamente arreglado, es fácil descartarlo directamente, así que debe ser forjado.

En segundo lugar, los ataques al DNS no deberían centrarse únicamente en los puertos UDP, que también son servicios estándar según el protocolo DNS. En caso de un ataque, tanto los ataques UDP como TCP pueden realizarse simultáneamente.

El objetivo de HTTP Flood es atravesar la caché en el frontend y llegar directamente al propio servidor web a través de la configuración del campo en la cabecera HTTP. Además, HTTP Flood también es muy crítico para la selección de objetivos, y los atacantes ordinarios elegirán páginas que requieren muchas consultas de datos, como la búsqueda, como objetivo de ataque, lo cual es muy correcto y puede consumir la mayor cantidad posible de recursos del servidor. Pero este ataque es fácil de identificar limpiando equipos mediante identificación humano-máquina, así que ¿cómo resolver este problema? Es muy sencillo, intenta elegir páginas a las que los usuarios normales también acceden a través de la APP, en general, varias APIs web. Los usuarios normales y el tráfico malicioso provienen de la APP, y la diferencia entre hombre y máquina es muy pequeña, por lo que es difícil distinguir entre integración básica.

Cada conexión TCP existe tanto en el lado del servidor como en sí misma, y también necesita consumir recursos para mantener el estado TCP, por lo que la conexión no puede mantenerse en exceso. Si esto se resuelve, la agresividad se verá enormemente mejorada, es decir, Slowloris puede lanzar ataques de forma sin estado, capturar el número de serie TCP y confirmar el mantenimiento de las conexiones TCP en el cliente mediante sniffing, y el núcleo del sistema no necesita prestar atención a los diversos cambios de estado de TCP, y un notebook puede generar hasta 65.535 conexiones TCP.

Las descripciones anteriores son todas mejoras técnicas de ataque. En el lado humano, hay otros medios. Si SYN Flood envía una gran cantidad de paquetes y va acompañado de conexiones lentas de Slowloris, ¿cuántas personas descubrirán el secreto? Incluso si el servidor cae, solo pueden encontrarse ataques SYN, intentando reforzar la limpieza de la capa TCP e ignorando el comportamiento de la capa de aplicación. Todo tipo de ataques pueden trabajar juntos para lograr el máximo efecto. La elección del momento de ataque también es un punto clave, como elegir al personal de mantenimiento cuando están comiendo, cuando el personal de mantenimiento se queda atascado en la carretera tras salir del trabajo o cuando no hay señal en la tarjeta de red inalámbrica del metro, y cuando la empresa objetivo está organizando un evento a gran escala y el tráfico aumenta.

Esto es un ataque puro, así que no se proporciona código ni explicación detallada.

Los métodos de ataque anteriores requieren más o menos algunos bots, incluso HTTP Flood requiere buscar un gran número de proxies anónimos. Si hay un ataque, solo necesitas emitir algunas instrucciones y la máquina se acercará automáticamente para ejecutarlo, lo cual es la solución perfecta. Este ataque ya ha aparecido, y eso viene de redes P2P.

Como todos sabemos, los usuarios y el tráfico P2P en Internet son un número extremadamente grande. Si todas van a un lugar designado para descargar datos y conectar miles de direcciones IP reales, ningún dispositivo puede soportarlo. Tomemos BT Download como ejemplo: falsificar torrents de algunos vídeos populares y publicarlos en motores de búsqueda es suficiente para engañar a muchos usuarios y al tráfico, pero esto es solo un ataque básico.

Los ataques P2P avanzados son suplantaciones directas de servidores de gestión de recursos. Por ejemplo, el cliente Thunder subirá los recursos que encuentre al servidor de gestión de recursos y luego los enviará a otros usuarios que necesiten descargar los mismos recursos, para que se publique un enlace. Mediante la inversión de protocolos, los atacantes forjan una gran cantidad de información popular de recursos y la distribuyen a través del centro de gestión de recursos, que puede difundirse instantáneamente por toda la red P2P. Lo que da aún más miedo es que este ataque no puede ser detenido, ni siquiera por el propio atacante, y el ataque continúa hasta que el oficial P2P detecta el problema, actualiza el servidor y el usuario de descarga reinicia el software descargado.

Eso es todo lo que hay en la introducción a los ataques DDoS, y no quiero profundizar más—basta con entender que tanta defensa es suficiente.

En general, los ataques DDoS pueden ser diestros y gráciles. La belleza de la aplicación reside en la unidad de la mente.