Ataques SYN Flood

Los ataques SYN flood son bastante conocidos por su antiguedad y facilidad de uso con montones de herramientas, su objetivo es provocar una denegacion de servicio en cualquier equipo que guarde un estado de las conexiones, una servidor, un router…

Antes de ver como funciona y como mitigarlo, veamos como funciona SYN

El paquete SYN es el primero enviado por el cliente en el hanshake de TCP para la creacion de una nueva conexion TCP, y debería ir seguido de SYN-ACK y ACK. Veamoslo a continuación:

TCP Handshake

1 – Cliente envia SYN (Synchronize) para sincronizar con el Servidor

2 – El Servidor envía un SYN-ACK para informar al cliente de que ha recibido el mensaje

3 – El Cliente al recibir el SYN-ACK del servidor, Responde con un ACK para informar al servidor de que lo ha recibido.

4 – Se establece la conexión! 🙂 Maravilloso

 

Al ataquerr!

Bien, cuando nos lanzan un ataque SYN FLOOD, lo que hacen es enviarnos miles de paquetes SYN a nuestra máquina, nuestra maquina envia el SYN_ACK y… ahí se queda, esperando al ACK del cliente.

Nuestra máquina tiene un limite para guardar estas solicitudes y un timeout por si el ACK del cliente no nos llega,  que no se quede ahí para siempre.

En un router que he podido ver por aquí, el limite de registro lo tengo en 218080 y el timeout en 5s.

En este caso, si nos pudieran enviar 218080/5=43616 SYN’s/segundo, nos bloquearían el router.

Formas de ver SYN’s a la espera de respuesta:

En router mikrotik:

IP>Firewall>Connections (Columna TCP State)

En linux:

watch –interval=5 ‘netstat -tuna |grep «SYN_RECV»|wc -l’

netstat -tuna

 

Mitigación

TCP_SYNCOOKIES:

Esto pasa por una solución bastante simple, y es que podemos hacer que en vez de guardar el estado de la conexión en SYN en nuestro sistema de tracking, que tiene recursos limitados, enviamos este estado a otra parte que no ocupe tantos recursos en el Tracking y dejarle enviado un SYN-ACK al cliente, entonces abrir un estado con conexión establecida en el sistema de Tracking al recibir el ACK del cliente.

Para activarla:

Mikrotik -> IP>Settings (Checkbox tcp-syncookies)

En linux además podemos ampliar el backlog (Donde guardamos las conexiones incompletas de TCP) y los synack_retries (Reintentos de SYNACK, antes de darse por vencido)

En /etc/sysctl.conf

# TCP SYN Flood Protection
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 3

sysctl -p /etc/sysctl.conf (Para cargar la conf)

 

Espero que os sirva mi primer post! Pronto seguire con más, Se aceptan sugerencias!!

 

Webgrafia:

https://www.ndchost.com/wiki/server-administration/hardening-tcpip-syn-flood

http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html

http://cr.yp.to/syncookies.html

http://security.stackexchange.com/questions/34607/why-is-the-server-returning-3-syn-ack-packets-during-a-syn-scan