Solicitar código fuente de escaneo de sincronización e información relacionada con la detección del sistema operativo

Explicación detallada del principio y la prevención del ataque SYN Flood

SYN Flood es uno de los métodos DoS (ataques de denegación de servicio) y DDoS (ataques distribuidos de denegación de servicio) más populares. Un método de ataque que explota fallas en el protocolo TCP para enviar una gran cantidad de solicitudes de conexión TCP falsificadas, agotando así los recursos de la parte atacada (carga completa de la CPU o memoria insuficiente)...

Principio básico. de SYN Flood

SYN Flood es uno de los métodos DoS (ataques de denegación de servicio) y DDoS (ataques distribuidos de denegación de servicio) más populares. Utiliza fallas en el protocolo TCP para enviar una gran cantidad de conexiones TCP falsificadas. solicitudes, lo que hace que los ataques de agotamiento de recursos (carga completa de la CPU o memoria insuficiente) de la parte atacada eventualmente provoquen un tiempo de inactividad del sistema o del servidor.

Antes de discutir el principio de SYN Flood, debemos comenzar con el proceso de establecimiento de una conexión TCP:

TCP es diferente de UDP. Se basa en conexiones. comunicarse entre el servidor y el cliente. Para transmitir datos TCP entre terminales, primero se debe establecer un circuito virtual, es decir, una conexión TCP. Este es el protocolo de enlace de tres vías en el protocolo TCP del que escuchamos a menudo. El proceso estándar para establecer una conexión TCP es el siguiente:

Primero, el cliente envía un mensaje TCP que contiene el indicador SYN, SYN. Es decir, sincronización (Sincronizar), el mensaje de sincronización indicará el puerto utilizado por el cliente y el número de secuencia inicial de la conexión TCP;

En segundo lugar, después de recibir el mensaje SYN del cliente, el servidor devolver un mensaje SYN ACK (es decir, Acuse de recibo) indica que se acepta la solicitud del cliente y el número de secuencia inicial de TCP se incrementa automáticamente en uno.

Finalmente, el cliente también devuelve un mensaje de confirmación ACK al servidor. El número de secuencia TCP también aumenta en uno y se completa una conexión TCP.

El ataque SYN Flood aprovecha el protocolo de enlace de tres vías de la conexión TCP. Supongamos que un usuario falla o se desconecta repentinamente después de enviar un mensaje SYN al servidor. Entonces el servidor no puede recibir el mensaje de respuesta SYN ACK. después de enviarlo al cliente (el tercer protocolo de enlace no se puede completar), en este caso, el servidor generalmente volverá a intentarlo (enviará SYN ACK al cliente nuevamente) y esperará un período de tiempo antes de descartar la conexión incompleta. esta vez La duración se llama SYN Timeout. En términos generales, este tiempo es del orden de minutos (entre 30 segundos y 2 minutos, la excepción de un usuario que hace que un subproceso del servidor espere 1 minuto no tendrá ningún impacto importante); el servidor, pero si se produce una gran cantidad de pérdidas en espera, el servidor consumirá muchos recursos para mantener una solicitud de semiconexión muy grande. Podemos imaginar que una gran cantidad de guardado y recorrido también consumirá mucho tiempo de CPU y memoria. Además, el servidor reintenta constantemente SYN ACK para las IP en la lista, y la carga en el servidor será muy grande. Si la pila TCP/IP del servidor no es lo suficientemente potente, el resultado final suele ser un desbordamiento y una caída de la pila. En comparación con el flujo de datos del ataque, las solicitudes de los usuarios normales son muy pequeñas. El servidor está demasiado cansado para procesar las solicitudes de conexión TCP falsificadas por el atacante y no tiene tiempo para prestar atención a las solicitudes normales de los clientes. muestra que la apertura de la página es lenta o que el servidor no responde. Esta situación es lo que a menudo llamamos un ataque de inundación SYN del lado del servidor (ataque de inundación SYN).

Desde una perspectiva de defensa, existen varias soluciones:

La primera es acortar el tiempo de espera de SYN, porque el efecto del ataque SYN Flood depende de la mitad SYN mantenida en el servidor. Número de conexiones. Este valor = frecuencia de carga de ataques SYN. Sin embargo, una configuración de SYN Timeout demasiado baja puede afectar el acceso normal de los clientes.

El segundo método es configurar una cookie SYN, que consiste en asignar una cookie a cada dirección IP que solicita una conexión. Si recibe mensajes SYN repetidos de una determinada IP en un corto período de tiempo, es. se considera bajo ataque y registra la información de la dirección. Todos los paquetes futuros de esta dirección IP serán descartados. El resultado de hacerlo también puede afectar el acceso normal del usuario.

Los dos métodos anteriores solo pueden lidiar con ataques SYN Flood relativamente primitivos. Acortar el tiempo de espera SYN solo tendrá efecto cuando la frecuencia de los ataques de la otra parte no dependa más de la cookie SYN. otra parte que usa una dirección IP real, si un atacante envía mensajes SYN a una velocidad de decenas de miles por segundo y usa SOCK_RAW para reescribir aleatoriamente la dirección de origen en el mensaje IP, el método anterior será inútil.

SYN Flood es uno de los métodos DoS (ataques de denegación de servicio) y DDoS (ataques distribuidos de denegación de servicio) más populares. Utiliza fallas en el protocolo TCP para enviar una gran cantidad de solicitudes de conexión TCP falsificadas, y por lo tanto. Un método de ataque que hace que la parte atacada agote sus recursos (la CPU está completamente cargada o la memoria es insuficiente)...

Interpretación del código fuente de SYN Flooder

Analicemos la implementación del programa de Inundación SYN.

Primero, echemos un vistazo al formato del mensaje TCP:

0 1 2 3 4 5 6

0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

| Encabezado IP | Segmento de datos TCP | - - - - - - - - - - - - - - - - - - - - - - - - - -

Figura 1 Estructura del mensaje TCP

Como se muestra en la figura Como se muestra arriba, un mensaje TCP consta de tres Consta de: encabezado IP de 20 bytes, encabezado TCP de 20 bytes y segmento de datos de longitud variable. En la operación real, puede haber opciones de IP opcionales. En este caso, el encabezado TCP está retrasado. al revés, porque solo estamos enviando Una señal SYN no transmite ningún dato, por lo que el segmento de datos TCP está vacío.

La estructura de datos del encabezado TCP es:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

| Número de puerto de origen de dieciséis dígitos | Número de puerto de destino de dieciséis dígitos

- - - - - - - - - - - - - - - - - - - - - - - - -

| Número de serie de treinta y dos dígitos

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Número de confirmación de treinta y dos dígitos

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

|U|A|P|R|S|F | |

| Primera parte |Seis bits reservados|R|C|S|Y|I| Tamaño de ventana de dieciséis bits| H|T|N|N|

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

| Suma de comprobación de dieciséis dígitos y | Puntero de emergencia de dieciséis bits

- - - - - - - - - - - - - - - - - | - - - - - - - - - - - - - - -

| Opciones (si las hay) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Datos (si los hay)

- - - - - - - - - | - - - - - - - - - - - - - - - - - - - - - -

Figura 2 Estructura del encabezado TCP

Según el formato del mensaje TCP, defina una estructura TCP_HEADER para almacenar el encabezado TCP:

typedef struct _tcphdr

{

USHORT th_sport //puerto de origen de 16 bits

unsigned int th_seq; //número de secuencia de 32 bits

unsigned int th_ack; //número de confirmación de 32 bits

unsigned char th_lenres; //4 bits de la palabra reservada de 6 bits de longitud del encabezado

unsigned char th_flag //palabras reservadas de 2 bits y banderas de 6 bits

USHORT th_win;

/tamaño de ventana de 16 bits

USHORT th_sum; //suma de comprobación de 16 bits

USHORT th_urp; //desplazamiento de datos de emergencia de 16 bits

}TCP_HEADER;

Al completar esta estructura con los datos correctos y asignar TCP_HEADER.th_flag a 2 (binario 00000010), podemos crear un paquete SYN TCP. Al enviar este paquete en grandes cantidades, se puede lograr el efecto SYN Flood.

Sin embargo, para realizar una suplantación de IP para ocultarse y evitar la verificación de cookies SYN del servidor, también es necesario operar directamente en el encabezado de IP:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Versión | Longitud total de ocho dígitos |

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

| Bandera de dieciséis bits | Bandera | Desplazamiento de trece bits | - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

| Tiempo de vida de ocho dígitos | Protocolo de ocho bits | Suma de comprobación de encabezado de dieciséis bits

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Dirección IP de origen de treinta y dos dígitos

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

| /p>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

|

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Figura 3 Estructura del encabezado IP

También defina un IP_HEADER para almacenar el encabezado IP:

typedef struct _iphdr

{

unsigned char h_verlen; //Longitud del encabezado de 4 dígitos, número de versión de IP de 4 dígitos

unsigned char tos; //Tipo de servicio de 8 bits

unsigned short total_len; longitud (bytes)

ident corto sin firmar; //identificación de 16 bits

frag_and_flags cortos sin signo; //bit de bandera de 3 bits

ttl de char sin signo; //Tiempo de supervivencia de 8 bits TTL

unsigned char proto //8

Número de protocolo de bits (TCP, UDP u otro)

suma de verificación corta sin firmar; //suma de verificación del encabezado IP de 16 bits

unsigned int sourceIP //dirección IP de origen de 32 bits

unsigned int destIP; // dirección IP de destino de 32 bits

}IP_HEADER;

Luego pasa SockRaw=WSASocket(AF_INET, SOCK_RAW, IPPROTO_RAW, NULL, 0, WSA_FLAG_OVERLAPPED );

Crea un socket sin formato Dado que nuestra dirección IP de origen está falsificada, no podemos esperar que el sistema nos ayude a calcular la suma de verificación de IP. Tenemos que configurar IP_HDRINCL en setsockopt para indicarle al sistema que complete. la IP por sí misma y calcule la suma de verificación usted mismo:

flag=TRUE

setsockopt(SockRaw, IPPROTO_IP, IP_HDRINCL, (char *)amp; flag, sizeof(int)

p>

El método de cálculo de la suma de verificación de IP es: primero establezca el campo de suma de verificación del encabezado de IP en 0 (IP_HEADER.checksum=0) y luego calcule la suma del complemento binario de todo el encabezado IP (incluidas las opciones). Una función de suma de comprobación estándar es la siguiente:

suma de comprobación USHORT(USHORT *búfer, tamaño int)

{

unsigned long cksum=0;

while(tamaño gt; 1) {

cksum =*buffer

tamaño -=sizeof(USHORT); >

}

if(size ) cksum = *(UCHAR*)buffer;

cksum = (cksum gt; gt; 16) (cksum amp; 0xffff); /p>

cksum = (cksum gt; gt; 16);

return (USHORT)(~cksum);

}

Esta función No se ha sometido a ninguna optimización. Dado que la función de suma de verificación es una de las funciones más llamadas en el protocolo TCP/IP, en términos generales, al implementar la pila TCP/IP, la función de suma de verificación se optimizará de acuerdo con el sistema operativo.

La suma de verificación del encabezado TCP se calcula de la misma manera que la suma de verificación del encabezado IP, y se utiliza la misma función para calcularla en el programa.

Cabe señalar que, dado que el encabezado TCP no contiene información como la dirección de origen y la dirección de destino, para garantizar la validez de la suma de verificación de TCP, se debe agregar un pseudo encabezado TCP al calcular el Suma de comprobación TCP La suma de comprobación del encabezado se define de la siguiente manera:

struct

{

unsigned long saddr //Dirección de origen

unsigned long daddr ; //Dirección de destino

char mbz; //En blanco

char ptcl; //Tipo de protocolo

unsigned short tcpl; length

}psd_header;

Luego copiamos estos dos campos en el mismo búfer SendBuf y calculamos la suma de comprobación de TCP:

memcpy(SendBuf, amp; psd_header, sizeof(psd_header));

memcpy(SendBuf sizeof(psd_header), & tcp_header, sizeof(tcp_header));

tcp_header.th_sum=checksum((USHORT *) SendBuf, sizeof (psd_header) sizeof(tcp_header));

No es necesario incluir el pseudo encabezado TCP al calcular la suma de comprobación de IP:

memcpy(SendBuf, amp; ip_header, sizeof( ip_header ));

memcpy(SendBuf sizeof(ip_header), & tcp_header, sizeof(tcp_header));

ip_header.checksum=checksum((USHORT *)SendBuf, sizeof( ip_header) sizeof(tcp_header));

Luego copie el encabezado IP calculado y el encabezado TCP en el mismo búfer y envíelos directamente:

memcpy( SendBuf, amp; ip_header, sizeof(ip_header) );

sendto(SockRaw, SendBuf, datasize, 0, (struct sockaddr*) amp; DestAddr, sizeof(DestAddr));

Porque todas las partes del mensaje TCP completo son Escrito por nosotros mismos, el sistema operativo no causará ninguna interferencia, por lo que podemos colocar una dirección IP de origen aleatoria en el encabezado IP si realmente se utiliza la dirección IP de origen falsificada, y hay una dirección para ayudar con el tiempo. mensaje SYN ACK del servidor, se enviará un mensaje RST (el bit de bandera es 00000100) para notificar al servidor que no necesita esperar una conexión no válida, pero si la IP falsa no está vinculada a ningún host, habrá; No habrá ningún dispositivo para notificar al host que la conexión no es válida. Este es el ataque de inundación SYN del protocolo TCP que aplicamos ampliamente. El host continuará enviando recibos repetidamente hasta que expire el tiempo de espera SYN antes de descartar este mensaje no válido. .

Por lo tanto, cuando un atacante utiliza un segmento de dirección IP con una distribución dispersa de hosts para llevar a cabo un ataque SYN Flood que falsifica direcciones IP, la carga en el host del servidor será bastante alta. Según la prueba, utiliza una máquina Pen 3 de 128 MB a 100 Mbps. un SYN preliminar optimizado El programa Flooder puede enviar mensajes TCP SYN a una velocidad de 16.000 paquetes/segundo. Este poder de ataque es suficiente para derribar la mayoría de los servidores WEB.

Los usuarios que son buenos pensando encontrarán que es muy sencillo optimizar el programa SYN Flooder. Desde la perspectiva de la estructura del programa, el código en el bucle durante el ataque es principalmente para el cálculo de la suma de comprobación y el búfer. relleno, la idea general es aumentar la velocidad del cálculo de la suma de verificación, e incluso los desarrolladores expertos escribirán la función de suma de verificación en código ensamblador. De hecho, existe un método que se puede optimizar fácilmente sin requerir habilidades avanzadas de programación ni conocimientos matemáticos. Después de estudiar detenidamente dos mensajes TCP SYN con diferentes direcciones de origen, descubrimos que la mayoría de los campos de los dos mensajes son iguales (por ejemplo). , dirección de destino, protocolo, etc.), solo la dirección de origen y la suma de verificación son diferentes. Si calculamos una gran cantidad de tablas de correspondencia entre las direcciones de origen y las sumas de verificación de antemano, una vez completado el cálculo, el programa de ataque solo necesita una combinación simple. de buffers Área, utilice punteros para operar directamente ubicaciones específicas en el buffer, leer datos de la tabla de correspondencia precalculada y reemplazar los campos correspondientes en el buffer. Este simple trabajo depende completamente de la velocidad del sistema que envía paquetes IP y no tiene nada que ver con la eficiencia del programa. De esta manera, incluso un host con una frecuencia de CPU baja puede enviar rápidamente una gran cantidad de paquetes de ataque TCP SYN. Si considera el tiempo de empalme del búfer, incluso puede definir una matriz de búfer grande y enviarla después de llenarla.

SYN Flood es uno de los métodos DoS (ataques de denegación de servicio) y DDoS (ataques distribuidos de denegación de servicio) más populares. Utiliza fallas en el protocolo TCP para enviar una gran cantidad de solicitudes de conexión TCP falsificadas, con lo que se envían un gran número de solicitudes de conexión TCP falsificadas. Un método de ataque que agota los recursos del atacante (la CPU está completamente cargada o la memoria es insuficiente)...

Un estudio preliminar sobre el seguimiento y defensa de los ataques SYN Flood

Para los ataques SYN Flood, especialmente DDos, actualmente no existe un buen método de monitoreo y defensa, pero si el administrador del sistema está familiarizado con los métodos de ataque y la arquitectura del sistema, a través de una serie de configuraciones, la carga del sistema atacado se puede reducir al máximo. medida, sin afectar el normal funcionamiento del sistema provocando impactos irreparables. Si la carga de un host aumenta repentinamente o incluso deja de responder, y puede usar el comando Netstat para ver una gran cantidad de medias conexiones SYN_RCVD, se puede determinar que este host ha sufrido un ataque SYN Flood.

Después de ser atacado por SYN Flood, lo primero que debe hacer es recopilar evidencia. Utilice Netstat ?Cn ?Cp tcp gt en la línea de comando; es necesario registrar todo el estado actual de la conexión TCP. txt. Si hay herramientas como sniffers o TcpDump, registrar los mensajes TCP SYN en detalle será más útil para el seguimiento y la defensa. Los campos que deben registrarse son: dirección de origen, identificación en el encabezado IP, número de secuencia en TCP. encabezado, valor TTL (tiempo de vida, ciclo de vida), etc. Aunque es probable que el atacante falsifique esta información, es útil analizar el programa de ataque. Especialmente el valor TTL. Si una gran cantidad de paquetes de ataque parecen provenir de diferentes IP pero tienen el mismo valor TTL, a menudo podemos inferir la distancia del enrutador entre el atacante y nosotros. Al menos podemos reducir el riesgo de ser atacados mediante el filtrado. paquetes con valores TTL específicos La carga del sistema garantiza que los usuarios con valores TTL diferentes de los paquetes de ataque puedan reanudar el acceso normal.

Para sistemas Win2000, también puede reducir el daño de SYN Flood modificando el registro. Realice los siguientes cambios en el registro:

Primero, abra regedit y busque [HKEY_LOCAL_MACHINE\Sytem. \CurrentControlSet \Services\Tcpip\Parameters]

Agregue un valor clave de SynAttackProtect, escriba REG_DWORD, el rango de valores es 0-2. Este valor determina las medidas de protección tomadas cuando el sistema es atacado por SYN, incluida la reducción. sistema El número de reintentos SYN ACK, etc., el valor predeterminado es 0 (sin ninguna medida de protección), se recomienda configurarlo en 2;

Agregue un valor clave de TcpMaxHalfOpen, el tipo es REG_DWORD , el rango de valores es 100-0xFFFF, este valor es el número de medias conexiones que el sistema permite abrir al mismo tiempo. De forma predeterminada, Windows 2000 es 100 y la versión ADVANCED SERVER de Windows 2000 es 500. Es difícil de determinar y depende de la carga TCP del servidor y de la intensidad de posibles ataques. El administrador debe probar/predecir el valor específico para abrir la media conexión durante el período de acceso pico, y luego usarlo como referencia para establecer el valor de TcpMaxHalfOpenRetried. Se debe reservar un cierto margen y luego 1,25 veces. TcpMaxHalfOpenRetried se utiliza como valor de TcpMaxHalfOpen. Esto puede maximizar el mecanismo de protección contra ataques SYN del propio Windows 2000.

Agregue un valor clave de TcpMaxHalfOpenRetried, el tipo es REG_DWORD, el rango de valores es 80-0xFFFF, de forma predeterminada es 80 para Windows2000 y es 400 para ADVANCED SERVERwindows2000. Este valor determina bajo qué circunstancias. El sistema abrirá la protección contra ataques SYN.

Analicemos el mecanismo de protección contra ataques SYN de Windows 2000: en circunstancias normales, Windows 2000 tiene una configuración convencional para el protocolo de enlace de tres vías de las conexiones TCP, incluido el tiempo de espera SYN, el número de SYN-ACK reintentos y el retraso de los mensajes SYN desde el enrutador al sistema a Winsock, etc. Esta configuración general está optimizada para el rendimiento del sistema, por lo que puede proporcionar a los usuarios servicios convenientes y rápidos una vez que el servidor es atacado, la cantidad de medias conexiones SYN excede el; configuración de TcpMaxHalfOpenRetried, el sistema pensará que está bajo un ataque SYN Flood. En este momento, las opciones configuradas en el valor de la clave SynAttackProtect entran en vigor, el tiempo de espera SYN se acorta y el número de reintentos SYN-ACK se reduce. y el sistema responderá automáticamente a los informes en el búfer. El texto se retrasa para evitar un impacto excesivo en la pila TCP/IP y se esfuerza por minimizar el daño del ataque si la intensidad del ataque continúa aumentando y excede el valor de TcpMaxHalfOpen; el sistema ya no puede proporcionar servicios normales. Más importante aún, el propósito es garantizar que el sistema no falle, por lo que el sistema descartará cualquier paquete SYN que exceda el rango de valores de TcpMaxHalfOpen (debe usar una política de pérdida aleatoria de paquetes) para garantizar. la estabilidad del sistema.

Al configurar el registro para defenderse contra ataques SYN Flood, se adopta una estrategia pasiva No importa cuán poderoso sea el sistema, no puede ser respaldado por protección pasiva. .

Llamo a esta estrategia la estrategia de "sacrificio". Basado en una falla en el código de ataque SYN Flood, volvamos a analizar el proceso del atacante SYN Flood: el programa SYN Flood tiene dos métodos de ataque, según basado en IP y nombre de dominio. El primero es que el atacante realiza la resolución de nombres de dominio por sí mismo y pasa la dirección IP al programa de ataque. El segundo es que el programa de ataque realiza automáticamente la resolución de nombres de dominio. común, es decir, una vez que comienza el ataque, no habrá más Para la resolución de nombres de dominio, debemos aprovechar esto. Supongamos que un servidor cambia rápidamente su dirección IP después de ser atacado por SYN Flood. una dirección IP vacía y sin host. Los administradores de administración solo necesitan cambiar la resolución DNS a una nueva dirección IP para restaurar el acceso normal para los usuarios a través del nombre de dominio en un tiempo muy corto. Este enfoque depende del tiempo de actualización del DNS. Para confundir al atacante, podemos incluso colocar un servidor de "sacrificio" para desviar el flujo de datos del ataque.

Por la misma razón, entre muchas arquitecturas de equilibrio de carga, el equilibrio de carga basado en la resolución DNS en sí tiene inmunidad a SYN Flood. El equilibrio de carga basado en la resolución DNS puede asignar solicitudes de usuario a diferentes IP en un host de servidor. un atacante solo puede atacar uno de los servidores. Aunque el atacante puede continuar realizando solicitudes de DNS para continuar atacando a los usuarios, esto aumenta la intensidad del ataque del atacante. Al mismo tiempo, debido a que las solicitudes de DNS múltiples pueden ayudar a los administradores a encontrar la dirección del atacante. Esto se debe principalmente a que las solicitudes de DNS deben devolver datos, y estos datos son difíciles de falsificar.

A día de hoy todavía no existe una solución completa a los ataques DDOS, pero varios fabricantes están considerando el uso integral de tecnologías de equilibrio de carga, desvío de tráfico y control de ancho de banda, junto con las cada vez mayores capacidades de análisis de paquetes e incluso tecnología de virtualización. , en un esfuerzo por minimizar los ataques SYN Flood. Dejemos que los usuarios y yo esperemos y veamos el nacimiento de nuevos productos y nuevas tecnologías.