Los ataques de denegación de servicio (DoS) son uno de los ataques informáticos que hemos observado hace ya muchos años, y que aún siguen vigentes. En forma sencilla, consisten en un ataque hacia algún servicio informático (generalmente alojado en uno o varios servidores), con el ánimo de que este deje de funcionar. El ataque consiste en enviar determinados paquetes al objetivo, de forma tal de saturar los recursos que este puede procesar, y que así el servidor se vea en la necesidad de suspender la provisión del servicio. Como ataque derivado, aparecen los ataques de denegación de servicio distribuido (DDoS), donde el mismo es lanzado, no desde un sistema informático, sino desde múltiples nodos que realizan el ataque de forma simultánea.
Las redes botnets suelen ser utilizadas con estos fines, pudiendo lograr que todos los equipos zombis realicen el ataque contra el objetivo de forma simultánea, logrando mayor efectividad en el ataque. Asimismo, estos ataques están cada vez más asociados al hacktivismo, del cual ya hablamos en este mismo espacio. Un ejemplo de esto son los ataques contra la SGAE, o aquellos derivados contra PayPal, Visa y Mastercad a raíz del incidente de Wikileaks.
Es decir que, a pesar de su antigüedad, los ataques de denegación de servicio siguen vigentes, y es uno de los riesgos que las organizaciones deben considerar al momento de diseñar una estrategia de seguridad de la información. ¿Cómo controlar un ataque de denegación de servicio? Sobre este tema, hace unos días me encontré con esta interesante guía desarrollada por el CERT, titulada DDoS incident response (respuesta ante un incidente de DDoS), el cual recomiendo leer y tomar en cuenta para que la red de su empresa u organización esté preparada para enfrentar, si ocurriera, este tipo de ataque.
La guía considera seis pasos en el proceso de responder a un ataque de denegación de servicio. El primero de ellos, es la preparación. Aunque muchos habrán imaginado que la guía comenzaría cuando se detecta el incidente (segundo paso), la realidad es que para una correcta gestión de la seguridad, es necesario estar preparados, y es en esta etapa donde se recomienda, entre otras cosas, contar con un adecuado mapa de la red y conocimiento de la infraestructura, definir las personas a contactar ante la identificación del ataque y crear los procedimientos adecuados. Aunque sea redundante, estar preparados; y me animo a decir que este es el paso más importante.
Posteriormente, como ya se dijo, viene el paso de la identificación: detectar el ataque, determinar el alcance del mismo y, no menos importante, involucrar a las partes involucradas. Y este es, a mi criterio, un aspecto fundamental: ¿cuánto tarda el gerente de una empresa en enterarse de este incidente? Aunque muchas veces las comunicaciones suelen realizarse luego de haber controlado la situación, es recomendable involucrar a las personas correctas en esta etapa, donde luego será necesario hacer un análisis de la situación, y del ataque en particular.
Posteriormente, viene la etapa de contención. Esta, consiste en trabajar sobre los dispositivos de red, para lograr que el tráfico malicioso no afecte el funcionamiento del servicio, ya sea bloqueando o redirigiendo los paquetes del ataque, o bien buscando nuevos canales de comunicación entre el servicio y sus usuarios.
La cuarta etapa, consiste en la remediación: aún controlada la situación, es necesario detener el ataque de denegación de servicio. Cuánto más rápido se llegue a esta etapa, menor será el impacto (especialmente económico) del ataque. En esta etapa, es probable que se deba involucrar el proveedor de ISP, por lo que es recomendable saber cuál es el procedimiento para ello (primera etapa). El documento del CERT también aconseja, en caso de tener suficiente información, considerar involucrar a las fuerzas de seguridad en función de lo que determinen los departamentos legales de la empresa.
El ante último paso, la recuperación, consiste en volver el servicio al estado original. Si se realizaron direcciones de tráfico o cambios en las configuraciones durante el ataque, una vez que este ha terminado es necesario volver todo al estado original. Es importante estar seguro al momento de estar estos pasos, ya que si no se hicieron las etapas anteriores cuidadosamente, es probable que vuelvan a aparecer falencias en el servicio.
Finalmente, el sexto y último paso consiste en el post-ataque, etapa donde se debe analizar lo ocurrido y, entre otras acciones, se debe:
- Documentar los detalles del incidente.
- Discutir lecciones aprendidas y verificar si se pudiera haber evitado o controlado mejor el incidente.
- Volver a la etapa uno y prepararse mejor en caso de una nueva ocurrencia del ataque.
Fuente: ESET Latinoamérica
Protección contra ataques DDoS
Los ataques de Denegación de Servicio (Denial of Service, DoS) son casi tan antiguos como las redes de comunicaciones, pero de un tiempo a esta parte se han popularizado entre las bandadas de script kiddies, para atacar a todo lo que no les gusta. Ya sean partidos políticos, webs de ministerios e instituciones del estado, empresas privadas, etc. Nadie está a salvo de la “ira vengadora” de un quinceañero con ínfulas de guerrillero (mientras sus padres piensan que está haciendo “los deberes”).
Primera observación: es delito en España desde diciembre del 2010 participar en este tipo de ataques. Leo en Twitter a algunos que argumentan que ellos “sólo se ponen de acuerdo para visitar una página web“. Menuda desfachatez. Llamar al 112 no es delito, por supuesto. Ponerte de acuerdo con 1000 colegas para que cada uno haga mil llamadas al 112 a una hora concreta puede poner vidas en peligro si nadie puede avisar a los bomberos de un incendio o avisar a la policía de un crimen.
Pero dejándo disquisiciones ético-legales a un lado, ¿qué se puede hacer para defenderse de ataques DoS? No es fácil y no hay soluciones mágicas, pero hay cosas que se pueden hacer:
Estar preparado
Los ataques que consisten en miles de conexiones válidas por segundo funcionan porque cada una de las conexiones supone una carga en nuestros servidores (mostrar la información de la página web, quizá haciendo consultas a una base de datos, etc.)
Todo el mundo que tiene página web debería tener calculado el impacto en rendimiento de sus páginas, y tener siempre un “website” alternativo de bajo impacto para situaciones de sobrecarga. Por ejemplo, durante los ataques en Nueva York del 11-S, muchos medios de comunicación sufrieron un “ataque DoS” no intencionado al tener a millones de personas por todo el mundo intentando enterarse de qué pasaba. Algunos, como la CNN cambiaron su página normal por una de sólo texto, sin publicidad, ni elementos innecesarios, de forma que cada petición se pudiera procesar en menos tiempo y así poder atender más conexiones por segundo.
Esto se puede incluso automatizar, de forma que los servidores web cambien automáticamente a la versión “light” en cuanto detectan un aumento inesperado del nivel de peticiones.
Usar redes de distribución de contenido (CDN)
Los CDN son sistemas que permiten a las empresas distribuir su contenido estático por servidores distribuidos por todo el mundo, como los proporcionados por la empresa Akamai. Durante los ataques DDoS a partidos políticos a finales de diciembre de 2010, casi todos cayeron enseguida (PP, CiU, etc.). Algunos de ellos tienen sus páginas alojadas en empresas de hosting de las de 10€/mes, y se merecen lo que les pase. Sin embargo, hubo una web de un partido que, aparentemente, no sucumbió, y es la del PSOE. Simplemente hicieron que su página principal fuera estática y fuera servida por servidores de Akamai. Da igual que se caigan los servidores, en todo momento se podía seguir visitando la web (con una funcionalidad reducida). Algunos críos participantes en el ataque se indignaron por esta “trampa”.
Como si quiero entrar en tu casa y digo que haces trampa por echar la llave. En fin.
Que te ayude tu proveedor de acceso a Internet
Si tienes un proveedor de acceso serio, siempre podrás pedir que te ayuden en caso de ataque. Como mínimo deberían ser capaces de reenviar el tráfico que está dirigido a tus sistemas, a una ruta inválida (null route) de forma temporal.
El problema de este sistema es que nadie podrá acceder desde fuera, ni los atacantes ni tus usuarios legítimos. Entre los participantes en el ataque, que normalmente no tienen conocimientos suficientes, se cree que el ataque ha tenido éxito, ya que la página web deja de estar accesible.
Esto viene a ser la estrategia de “hacerse el muerto”, que puede ser muy válida en algunos casos, sobre todo combinada con contenido estático en CDN (ver punto anterior).
Utilizar una solución anti-DDoS proporcionada por tu proveedor de acceso
Esto suele ser lo necesario cuando quieres evitar el ataque, pero quieres mantener tu sitio accesible por usuarios legítimos, y que el contenido no sea estático, sino transaccional. Es decir, seguir operando “business as usual”. Estas soluciones son complejas, y normalmente las ofrecen los proveedores de acceso a Internet a las grandes empresas, con un coste por supuesto.
Suelen consistir en:
- Sistema de detección - elementos de red (tipo Arbor Peakflow) que detectan la anomalía en el tráfico de red y hacen análisis del tráfico. Si se situan en la “ruta” entre Internet y tu perímetro, suelen estar gestionados por el ISP. Si los situas en tu perímetro, pueden estar gestionados por el ISP o por la empresa cliente.
- Mecanismo de redirección – puede ser iniciado por el ISP o por la empresa atacada, y suele consistir en “publicar” una ruta nueva usando el protocolo de rutado BGP, de forma que el tráfico a ciertas IPs se redirija a través de un sistema de mitigación.
- Sistema de mitigación - son elementos de red (tipo Cisco Guard), gestionados por el ISP, que se “comen” todo el tráfico (suelen tener una capacidad enorme, difícil de saturar por el ataque típico), y se encargan de “separar el grano de la paja” mediante análisis estadístico, y reenvían a la empresa atacada el tráfico “limpio” mediante un túnel GRE cifrado.
Fuente: Blog de Alfredo Reino
No hay comentarios:
Publicar un comentario