Cómo evitar la inundación de sincronización TCP
Antes de discutir el principio de SYN Flood, primero debemos comprender el proceso de establecimiento de la conexión TCP:
TCP es diferente de UDP. Se basa en la conexión. entre el servidor y el cliente. Para transmitir datos TCP entre dos partes, primero debe establecer un circuito virtual, es decir, una conexión TCP. Es decir, el protocolo de enlace de tres vías en el protocolo TCP 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. significa 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;
El número de secuencia inicial de la conexión;
El El número de secuencia inicial de la conexión es el número de puerto del cliente. El mensaje de sincronización indica el puerto utilizado por el cliente y el número de secuencia inicial de la conexión TCP;
En segundo lugar, el servidor recibe el mensaje SYN del cliente y devuelve un mensaje SYN+ACK (confirmación), que indica el La solicitud ha sido aceptada y el número de secuencia inicial de la conexión TCP se incrementa automáticamente en uno.
Finalmente, el cliente devolverá un recibo de confirmación al servidor y el número de secuencia TCP se incrementará en uno nuevamente, completando así una conexión TCP.
Los ataques SYN Flood explotan el protocolo de enlace de tres vías de una conexión TCP. Supongamos que el usuario muere repentinamente o se desconecta después de enviar un mensaje SYN al servidor. El servidor no podrá recibir el mensaje ACK del cliente después de enviar una respuesta SYN + ACK (el tercer protocolo de enlace no se puede completar). generalmente se reiniciará. Intente enviar SYN + ACK al cliente y luego envíe un mensaje de confirmación al cliente. ACK al cliente) y espere un período de tiempo para descartar la conexión incompleta. La duración de este período de tiempo se denomina tiempo de espera SYN. En términos generales, este tiempo es del orden de varios minutos (entre 30 segundos y 2 minutos). ; un usuario El hilo del servidor que espera 1 minuto causado por la excepción no tendrá un gran impacto en el lado del servidor, pero si ocurre una gran cantidad de pérdidas en espera, el servidor consumirá muchos recursos para mantener un semi-gran tamaño. solicitud de conexión. Podemos imaginar que una gran cantidad de guardado y recorrido también consumirá mucho tiempo de CPU y memoria. Además, junto con el hecho de que el servidor reintenta constantemente SYN+ACK para las IP en la lista, la carga en el servidor será muy pesada. . Si la pila del protocolo TCP/IP del servidor no es lo suficientemente potente, el resultado final suele ser un fallo por desbordamiento 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 ocupado lidiando con las solicitudes de conexión TCP falsas del atacante y no tiene tiempo para considerar las solicitudes normales de los clientes. El cliente se mostrará como abriendo lentamente o el servidor no responde, esta situación a menudo se denomina ataques de inundación SYN del lado del servidor (ataques 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 que el servidor conserve la mitad del SYN. Número de conexiones, este valor = frecuencia de ataques SYN x tiempo de espera de SYN, por lo que se acorta el tiempo desde que se recibe el mensaje SYN hasta que se determina que el mensaje no es válido y se descarta la conexión. Por lo tanto, al acortar el tiempo desde la recepción de un mensaje SYN hasta determinar que el mensaje no es válido y abandonar la reconexión, por ejemplo, configurándolo en menos de 20 segundos, la carga en el servidor se puede reducir exponencialmente. Sin embargo, una configuración de tiempo de espera SYN demasiado baja puede afectar el acceso normal del cliente.
El segundo método consiste en configurar la Cookie SYN, que asigna una Cookie a cada dirección IP que solicita una conexión.
Si recibe mensajes SYN de una dirección IP repetidamente en un corto período de tiempo, se reconocerá como un ataque, se registrará la información de la dirección y se descartarán los paquetes futuros de esa dirección IP. El resultado de esto también puede afectar el acceso normal de los usuarios.
Los dos métodos anteriores solo pueden lidiar con los ataques SYN Flood más primitivos. Acortar el tiempo de espera de SYN solo será efectivo si la otra parte no ataca con frecuencia y la cookie SYN depende más del uso de la otra parte. una dirección IP real, por lo tanto, si un atacante envía mensajes SYN a una velocidad de decenas de miles de veces por segundo y usa SOCK_RAW para reescribir aleatoriamente la dirección de origen de la dirección IP en el mensaje, el método anterior será más efectivo. Si usa SOCK_RAW para reescribir aleatoriamente la dirección IP en el paquete, entonces el método anterior será inútil.