3 mar 2014

¿Se puede relacionar un DDoS en un proceso de hacking ético?

Las DDoS y DoS son unos auténticos quebraderos de cabeza para la directiva de una organización, sobretodo si el negocio se encuentra en Internet. La posibilidad de ser el foco de un ciberataque es algo que a las grandes empresas, sencillamente acojona. Por ello, nace la necesidad de verificar y realizar stress sobre una organización y su infraestructura. La realización de mediciones sobre los carga de recursos de los sistemas o el ancho de banda que se consigue soportar de tope es algo necesario hoy en día. Con los ojos puestos en la ciberguerra y toda la tecnología que tenemos hoy en día, es totalmente necesario e indispensable estar preparado, aunque en algunas ocasiones es sencillamente (casi) imposible soportar estos ataques.

Este tipo de pruebas son, sin lugar a la duda, las más temidas por las empresas ya que buscan evaluar la fortaleza y recuperación ante situaciones de estrés de la infraestructura de una organización. Una prueba de estrés se define con varios componentes que los auditores deberán tener en cuenta. Es importante entender bien el entorno que rodea a la organización para poder llevar a cabo la prueba con la máxima eficiencia. El paradigma cloud computing y las botnets aparecen en muchas ocasiones como vías hacia la denegación de servicio.

Las pruebas que se realicen sobre una organización deben estar siempre bajo el control del equipo de auditoría y sin llegar a realizar alguna acción no legal. Por esta razón, las botnets deben ser descartadas, al menos desde el punto de vista ético, profesional y, sobretodo, legal.

La primera técnica que se presenta es Mail Bombing, la cual sirve para realizar denegación de servicio (DoS) a través del envío masivo de mensajes a una máquina. El objetivo es saturar el servicio con todos los correos electrónicos recibidos. Muy antigua. 

La segunda técnica para DoS es la denominada “pitufo” o smurfing. Esta técnica se basa en el envío de una trama ICMP, que corresponde con una petición ping, por la red. La trama lleva como dirección IP de origen la dirección IP de la víctima, utilizando la técnica IP Spoofing, y como dirección de destino la dirección IP de broadcast de la red a la que se ataca. El objetivo es que todos los equipos de la red contesten al equipo de la víctima de modo que saturen su ancho de banda. Esta técnica no funciona en redes actuales. Cómo suelen decir por aquí "más antigua que el fuego". 

La tercera técnica son los flood. Existen distintos tipos de flood, en función de la capa en la que se encuentre el ataque, por ejemplo, SYN flood, UDP flood, HTTP flood, etcétera. Con SYN flood el atacante utiliza una dirección IP inexistente y envía gran cantidad de tramas con el flag SYN de conexión a la víctima. La víctima no puede contestar al usuario que realiza la petición, ya que la dirección IP no existe, por lo que las peticiones llenan la cola de tal manera que las solicitudes reales no podrían ser atendidas.

Las técnicas para DDoS son una ampliación de las técnicas DoS, por lo que siempre o casi siempre se pueden utilizar dichas técnicas en un ámbito y en el otro. La diferencia es que cuando se habla de DDoS se debe visualizar un campo de batalla mayor, nivel global, un entorno en el que máquinas distribuidas geográficamente realizan técnicas basadas en DoS, y de manera, más o menos, sincronizada. 

Las técnicas flood son muy recurridas en las pruebas de estrés emulando una situación de DDoS. Una de las técnicas más utilizadas es la de DNS Amplification. Esta técnica utiliza a los servidores DNS de Internet como amplificadores en el volumen de bytes que se responderá a una víctima. En otras palabras, un atacante realiza peticiones DNS con una dirección IP falsa. Cuando el servidor DNS responde lo hará a la dirección IP que se ha spoofeado, por lo que le llegará a un equipo que no realizó tal petición. La petición DNS ocupa entre 40 y 70 veces menos que la respuesta, por lo que la amplificación está garantizada. Si estas peticiones alcanzan un volumen importante se puede inundar el equipo de la víctima, provocando la denegación de servicio.

Todo esto tiene sentido en una prueba dónde la organización quiere conocer si están preparados para la batalla contra los ataques provenientes de Internet. Próximamente hablaremos sobre los objetivos que tendremos exactamente en una prueba de este estilo.

1 comentario:

  1. Ahora me surge una duda con respecto a el mítico ataque smurf. Los paquetes de broadcast consumen recursos de cpu en la máquina que lo recibe. Siguiendo esto, en teoría, sería posible colapsar una máquina de una red lan. ¿Estoy en lo cierto o me estoy perdiendo algo?...Creo que ha llegado el momento de desempolvar el hping y probar.

    ResponderEliminar