25 febrero 2010

Syn Flood, que es y como mitigarlo

Hoy día es sorprendente ver como ataques que fueron descritos a principios de los 90 perduran y siguen siendo efectivos en un buen numero de situaciones.

Uno de ellos, tal vez de los más clásicos, es el Syn Flood. Este tipo de ataque es posible debido a la forma en la que funcionan las conexiones TCP. Cuando un extremo desea iniciar una conexión contra otro equipo, inicia la conversación con un 'SYN', el otro extremo ve el SYN y responde con un SYN+ACK, finalmente el extremo que empezó la conexión contesta con un ACK y ya pueden empezar a transmitir datos.


Un ataque de tipo Syn Flood lo que hace es empezar un numero especialmente alto de inicios de conexión que nunca son finalizados, dejando al servidor a la espera del ack final, y por tanto consumiendo recursos de forma desproporcionada. Existen muchas herramientas escritas en todo tipo de lenguajes para hacer un ataque de tipo Syn Flood y no se requiere especial habilidad para llevar acabo un ataque de ese tipo.

Mitigando un ataque Syn Flood

A la hora de fortificar un sistema para contrarrestar un ataque de tipo Syn Flood existen parámetros que se pueden configurar en el sistema operativo para hacerlo mas resistente.

En sistemas Linux:

Primer paso, activar las syn cookies (mas información sobre que es y como se construye una syn cookie aquí)

# sysctl -w net.ipv4.tcp_syncookies="1"

Segundo paso, aumentar el 'backlog queue' (es decir, dar mas holgura al sistema para procesar peticiones entre-abiertas)

# sysctl -w net.ipv4.tcp_max_syn_backlog="2048"

Tercer paso, hacer que el sistema minimice el tiempo de espera en la respuesta al SYN+ACK. En principio un sistema Linux 'por defecto' esperará 3 minutos, nosotros lo vamos a dejar en 21 segundos

#sysctl -w net.ipv4.tcp_synack_retries=2

(una vez probados los cambios, hay que hacerlos permanentes en /etc/sysctl.conf)

En sistemas Windows :

Activación de la protección anti Syn Flood:

C:\>reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v SynAttackProtect /t REG_DWORD /d 1

Aumentamos el 'backlog queue'

C:\>reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v EnableDynamicBacklog /t REG_DWORD /d 1

C:\>reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v MinimumDynamicBacklog /t REG_DWORD /d 20

C:\>reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v MaximumDynamicBacklog /t REG_DWORD /d 20000

C:\>reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v DynamicBacklogGrowthDelta /t REG_DWORD /d 10
 
Decrementamos el tiempo de espera en conexiones 'Half Open'

C:\>reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v TcpMaxConnectResponseRetransmissions /t REG_DWORD /d 2

Ya solo queda rebootar Windows para que los cambios tengan efecto

[+] Las configuraciones han sido extraídas de este magnífico artículo 

8 comments :

Iván dijo...

Triste realidad que esto siga presente en la mayoría de sitios..

vierito5 dijo...

El Kerio Personal Firewall 2.1.5 era vulnerable a SYN Flood, lástima, porque me gustaba todo sencillo que era de usar y configurar, y sin chorradas extra.

Anónimo dijo...

Buff... Pues que un firewall comercial sea vulnerable a este ataque tiene tela...

Buen texto!

Un dia de estos seria guay si pudieráis hacer una especie de resumen sobre los pasos a seguir para mitigar un DOS.

Gracias!

Newlog

Anónimo dijo...

Falta alguna tilde en el título :P

Luciano Laporta Podazza dijo...

Me pareció un excelente artículo y bien sintético. Suelo robarles artículos a su blog porque simplemente son geniales y ando sin tiempo para escribir unos propios.

Sigan así, su trabajo es admirable :)

Juan dijo...

Interesante el artículo, pero leyendo la configuración de mi ubuntu (laptop) encontré esto:
# Uncomment the next line to enable TCP/IP SYN cookies
# This disables TCP Window Scaling (http://lkml.org/lkml/2008/2/5/167),
# and is not recommended.
#net.ipv4.tcp_syncookies=1

Aparentemente no es recomendable activar la opción syncookies porque desactiva la función TCP Window Scaling, entre otras según el link que se ve allí (esto es un fragmento de mi /etc/sysctl.conf).

vierito5 dijo...

@anónimo 1: Es una versión de Kerio del año de la pera, sin soporte, fíjate: 2.1.5 (puede que de 2001) el problema es que para mí era mejor esa versión (excepto por eso) que las versiones de los siguientes 8 años, que cambió de rumbo.

robinson dijo...

muy buen aporte, me sirbio de mucho!
claro sta en tener algo de teoria  sobre Tcp.