[Tutorial de seguridad] Ataques SYN Flood, defensa de cookies SYN y modificación de parámetros del kernel para Linux/FreeBSD

HackerEs una carrera deseable y prometedora. Aprecio a los buenos hackers y odio a los malos. El llamado hacker malo es el tipo de persona que hace que alguien del otro lado trabaje horas extra.

    Los ataques SYN Flood son un ataque típico de denegación de servicio. El llamado ataque de denegación de servicio consiste en lograr indirectamente el propósito del ataque haciendo que el anfitrión o la red víctima no pueda proporcionar un buen servicio. A los hackers les gusta jugar esto para demostrar que son nivelados, capaces y valientes haciendo que la otra parte trabaje horas extra, pero en realidad no es nada.

   1: ¿Qué es un ataque SYN Flood?

    Los ataques SYN Flood aprovechan el proceso de handshake triple del protocolo TCP en IPv4. Este protocolo estipula que si un extremo quiere iniciar una conexión TCP al otro extremo, primero debe enviar un paquete TCP SYN (sync) a la otra parte, y la otra parte envía un paquete TCP SYN + ACK tras recibirlo, y luego el iniciador envía un paquete TCP ACK (ACKnowledge Character), de modo que los tres handshakes terminan.

    En el proceso anterior, hay algunos conceptos importantes:

    La cola no está conectada: En el protocolo de handshake de tres vías, el servidor mantiene una cola no conectada que abre una entrada para cada paquete SYN del cliente (syn=j) que indica que el servidor ha recibido el paquete SYN y emite una confirmación al cliente, esperando el paquete de confirmación del cliente. La conexión identificada por estas entradas está en un estado Syn_RECV en el servidor, y cuando el servidor recibe un paquete de confirmación del cliente, la entrada se elimina y el servidor entra en el estado ESTABLECIDO. En otras palabras, cuando el servidor TCP recibe el paquete de solicitud TCP SYN, antes de enviar el paquete TCP SYN+ACK de vuelta al cliente TCP, el servidor TCP debe asignar primero un área de datos para servir la conexión TCP formada por esta mano. Generalmente, el estado de conexión es cuando se recibe el paquete SYN pero el paquete ACK aún no se ha recibidoConexión semiabierta(Conexión medio abierta)。

    Parámetro de backlog: Indica el número máximo de colas no conectadas.

    Número de retransmisiones SYN-ACK: Después de que el servidor envía el paquete SYN-ACK, si no se recibe el paquete de confirmación del cliente, el servidor realiza la primera retransmisión, espera un periodo de tiempo y no recibe el paquete de confirmación del cliente, y realiza la segunda retransmisión; si el número de retransmisiones supera el máximo especificado por el sistema, el sistema elimina la información de conexión de la semi-cola de conexión. Ten en cuenta que el tiempo de espera para cada repaso no es necesariamente el mismo.

    Tiempo de supervivencia semi-conectado: Se refiere al tiempo máximo que una entrada en la cola de semi-conexión sobrevive, es decir, el tiempo máximo desde que el servicio recibe el paquete SYN hasta el momento en que se confirma que el paquete es inválido, y el valor de tiempo es la suma del tiempo máximo de espera para todos los paquetes de solicitud de retransmisión. A veces también llamamos tiempo de supervivencia semi-conectado, SYN_RECV tiempo de supervivencia.

    En el ataque de inundación SYN más común, el atacante envía un gran número de paquetes TCP SYN a la víctima en un corto periodo de tiempo, momento en el que el atacante es el cliente TCP y la víctima el servidor TCP. Según la descripción anterior, la víctima asignaría una zona de datos específica a cada paquete TCP SYN, siempre que los paquetes SYN tuvieran direcciones de origen diferentes (lo que sería fácil de falsificar para los atacantes). Esto pondrá mucha presión en el sistema de servidor TCP y, eventualmente, hará que el sistema no funcione correctamente.

    2. El principio de las cookies SYN

    Una de las formas de prevenir eficazmente los ataques SYN Flood son las cookies SYN. Razón D: Cookie SYN. Inventado por J. Bernstain y Eric Schenk.

    Las cookies SYN son una modificación del protocolo de handshake de tres vías TCP en el lado del servidor para prevenir ataques SYN Flood.Su principio es:Cuando el servidor TCP recibe un paquete TCP SYN y devuelve un paquete TCP SYN+ACK, no asigna un área de datos dedicada, sino que calcula un valor de cookie basado en este paquete SYN. Cuando se recibe un paquete TCP ACK, el servidor TCP verifica la legitimidad del paquete TCP ACK basándose en ese valor de cookie. Si es legal, se asigna un área de datos dedicada para gestionar futuras conexiones TCP.

    Hablemos de cómo configurar los parámetros del kernel para implementar cookies SYN en Linux y FreeBSD

    Tres: Configuración de Linux

    Si la configuración de tu servidor no es buena, el número de sockets TCP TIME_WAIT llega a 20.000 o 30.000, y el servidor puede ser arrastrado hasta la muerte. Modificando los parámetros del núcleo de Linux, se puede reducir el número de sockets de TIME_WAIT en el servidor.

    TIME_WAIT puede verse con el siguiente comando:

En Linux, como CentOS, puedes conseguirlo modificando el archivo /etc/sysctl.conf.

    Añade las siguientes líneas:

Ilustrar:

net.ipv4.tcp_syncookies = 1 significa que las cookies SYN están habilitadas, lo cual es un BOOLEANO. Cuando SYN espera a que la cola se desborde, habilita las cookies para gestionarlo, lo que puede evitar un pequeño número de ataques SYN, y el valor predeterminado es 0, lo que significa que está cerrado.
net.ipv4.tcp_tw_reuse = 1 significa que la reutilización está habilitada, lo cual es un BOOLEANO. Permite reutilizar sockets TIME-WAIT para nuevas conexiones TCP, por defecto en 0, indicando cierre;
net.ipv4.tcp_tw_recycle = 1 significa permitir el reciclaje rápido de zócalos TIME-WAIT en conexiones TCP, que es BOOLEANO, y el valor predeterminado es 0, lo que significa que está cerrado.
net.ipv4.tcp_fin_timeout = 30 significa que si el socket se cierra por una petición local, este parámetro determina cuánto tiempo permanecerá en el estado FIN-WAIT-2. La unidad es de segundos.
net.ipv4.tcp_keepalive_time = 1200 indica con qué frecuencia TCP envía mensajes keepalive cuando se utiliza keepalive. El valor por defecto es 2 horas, cambiado a 20 minutos. La unidad es de segundos.
net.ipv4.ip_local_port_range = 1024 65000 indica el rango de puertos usados para conexiones de salida. El caso por defecto es pequeño: de 32768 a 61000, cambiado de 1024 a 65000.
net.ipv4.tcp_max_syn_backlog = 8192 indica la longitud de la cola SYN, que por defecto es 1024, y la longitud de la cola aumentada es 8192 para acomodar más conexiones de red esperando conexión.
net.ipv4.tcp_max_tw_buckets = 5000 indica el número máximo de sockets que el sistema mantiene al mismo tiempo TIME_WAIT y, si se supera este número, TIME_WAIT sockets se borrarán inmediatamente y se imprimirá un mensaje de advertencia. El valor predeterminado es 180000, cambiado a 5000. Para servidores como Apache y Nginx, los parámetros en las líneas anteriores pueden reducir TIME_WAIT el número de sockets, pero para Squid, el efecto no es muy bueno. Este parámetro controla el número máximo de sockets TIME_WAIT para evitar que el servidor Squid sea arrastrado por un gran número de sockets TIME_WAIT.
net.ipv4.tcp_synack_retries y net.ipv4.tcp_syn_retries definen el número de intentos SYN.

Ejecuta el siguiente comando para que la configuración entre en vigor:

Si no quieres modificar /etc/sysctl.conf, también puedes usar el comando para hacerlo:

Cuarto, configurado bajo FreeBSD

    Punto de vista personal de aprendizaje de yayu: la defensa contra la syn en FreeBSD puede no ser la misma que en Linux, los parámetros configurados no son exactamente los mismos y la configuración y comprensión relevantes pueden no ser correctas :)

    Hay uno en el enlace TCPMSL (vida útil máxima del segmento)El concepto deTiempo máximo de generaciónEl valor MSL se toma durante 30 segundos en implementaciones generales, y algunas implementaciones tardan 2 minutos. "Apagado pasivo" en la máquina de estados TCP: De CLOSE_WAIT a LAST_ACK, hay una regla de la siguiente: Cuando TCP realiza un apagado activo y envía de vuelta el último ACK, la conexión debe permanecer en el estado TIME_WAIT el doble de tiempo que el MSL. Esto permite que TCP envíe de nuevo el último ACK en caso de que se pierda (el otro extremo expira y reenvía el último FIN).

    La existencia de esta regla tiene como consecuencia que el enlace (dirección del cliente, puerto y dirección del lado del servidor, puerto) en esa dirección no puede usarse durante este tiempo de 2*MSL. Por ejemplo, si cerramos un enlace tras crearlo y luego lo reiniciamos rápidamente, entonces el puerto no estará disponible.

    TIME_WAIT tiempo es 2*MSL. Así que puedes reducir TIME_WAIT tiempo ajustando net.inet.tcp.msl. Para el servidor web, este valor puede ajustarse a 7500 o 2000 (accede a una web, la página no puede estar flasheada más de 4~15 segundos, puedes considerar renunciar a -_-)

    Referencia de configuración de parámetros:

En FreeBSD, yayu no vio un comando como "/sbin/sysctl -p" que pudiera hacer efectivo el contenido de /etc/sysctl.conf, así que simplemente usó el comando: