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
C:\>reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v SynAttackProtect /t REG_DWORD /d 1
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
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 :
Triste realidad que esto siga presente en la mayoría de sitios..
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.
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
Falta alguna tilde en el título :P
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 :)
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).
@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.
muy buen aporte, me sirbio de mucho!
claro sta en tener algo de teoria sobre Tcp.
Publicar un comentario