¿Cómo protegerse de los ataques DDoS de SYN Flood?

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone

Según expertos de ethical hacking, SYN floods son uno de los ataques más antiguos y comunes, tan común que el núcleo de Linux incluye algo de ellos construidos en apoyo a la mitigación de los mismos. Cuando un cliente se conecta a un servidor a través de TCP, este utiliza el protocolo de tres vías para sincronizar:

synflood1

Un paquete SYN es esencialmente el cliente diciendo al servidor “Me gustaría conectar”. Durante este protocolo, el cliente y el servidor de generan aleatoriamente Initial Sequence Numbers (ISNs), que se utilizan para sincronizar la conexión TCP entre dos partes. Expertos de seguridad en páginas web explican que estos números de secuencia TCP permiten hacer un seguimiento de los mensajes que se han enviado y confirmado por la otra parte.

Acuerdo a curso de ethical hacking, SYN flood abusa de este protocolo de enlace sólo yendo por una parte del camino a través del protocolo. En lugar de progresar a través de la secuencia normal, un atacante inunda el servidor destino con el mayor número de paquetes SYN como puedan reunir, de tantos equipos diferentes como puedan, y suplantaciones de origen IP tanto como les sea posible.

synflood2

El host con nada de seguridad en páginas web que recibe el SYN floods debe responder a todos y cada uno de los paquetes con un SYN-ACK, pero por desgracia la IP de origen fue probablemente suplantada, por lo que irán a ninguna parte (o peor, volverá como rechazada). Estos paquetes son casi indistinguibles de los verdaderos paquetes SYN de clientes reales, lo que significa que es difícil o imposible de filtrar a los malos en el servidor.

Para empeorar las cosas, cuando el servidor está manejando las conexiones normales y recibe el ACK de un cliente real, sigue siendo necesario saber que se trataba de un paquete SYN que se envió, por lo que también debe mantener una lista de conexiones (en estado SYN_RECV) en la cual un SYN ha sido recibido y un ACK aún no ha sido recibido.

Si la cola de conexiones en SYN_RECV no tiene límite de tamaño, la memoria se agotará rápidamente menciona Dan Levis profesor de seguridad en páginas web de International Institute of Cyber Security. Si este tiene un límite de tamaño, como es el caso de Linux, entonces no hay más espacio para almacenar el estado y las conexiones serán simplemente fallidas y los paquetes serán descartados.

SYN cookies

SYN cookies son una forma inteligente de evitar el almacenamiento de estado de conexión TCP durante el protocolo de enlace inicial, aplazando dicho almacenamiento hasta que un ACK válido haya sido recibido. Funciona por la elaboración del Initial Sequence Number (ISN) en el paquete SYN-ACK enviado por el servidor de tal manera que criptográficamente desmenuza detalles sobre el paquete inicial SYN y sus opciones TCP, de modo que el servidor puede validar que generó el paquete SYN-ACK para el cual un ACK ahora se está recibiendo. El servidor no almacena ningún estado en la conexión hasta que el ACK (que contiene la SYN cookie validada) se recibe, y sólo en ese momento se el estado regenerado y se almacenado menciona Dan Levis profesor de seguridad en páginas web.

Acuerdo a curso de ethical hacking, esta hash es calculada con un secreto que sólo el servidor sabe, no debilita significativamente la selección del número de secuencia y aun así es difícil que alguien forje un ACK para una conexión diferente sin haber visto el SYN-ACK del servidor real.

Synproxy

Una solución de seguridad en páginas web para obtener lo mejor de ambos mundos era el módulo synproxy. Este se sienta en netfilter en el núcleo, antes del TCP Linux stack, y como su nombre indica, apoderada todas las conexiones, mientras que genera SYN cookies. Cuando un paquete SYN llega, responde con un SYN-ACK y tira a la basura todo el estado. Tras la recepción de un paquete ACK correspondientemente a SYN cookie, eso luego envía un SYN y completa la conexión TCP habitual. Por cada paquete siguiente en cada dirección, modifica los números de secuencia de manera que es transparente a ambos lados.

 

synflood3

 

Esta es una manera bastante intrusiva de resolver el problema de seguridad en páginas web, ya que afecta a todos los paquetes durante toda la conexión, pero no mitiga exitosamente SYN floods. Por desgracia, encontramos que bajo ataque se rompió y provocó una caída del sistema.

 

Synsanity

Introduzca synsanity, la solución es mitigar SYN floods en Linux 3.x usuado por expertos de ethical hacking. Synsanity se inspira en SYNPROXY, en que se trata de un módulo de iptables que se encuentra entre Linux TCP stack y la tarjeta de red. La principal diferencia es que en lugar de tocar todos los paquetes, synsanity simplemente genera una cookie SYN similar a la forma en que el núcleo de Linux generaría si el SYN queue estaba lleno, y una vez que se valida el paquete ACK, eso permite llegar hasta Linux SYN cookie code, que crea y completa la conexión. Después de este punto, synsanity no toca ningún paquete adicional en la conexión TCP menciona Dan Levis profesor de seguridad en páginas web en IICS(iicybersecurty).

synflood4

 

Synsanity permite mitigar múltiples ataques que han causado previamente una interrupción del servicio parcial o completo, tanto los ataques de larga ejecución y ataques a gran volumen.

synflood5

 

Fuente: http://githubengineering.com/

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone