29 septiembre 2011

Dispositivos IPS vs DDoS de Anonymous

Últimamente los ataques DDoS están ganando cierta importancia en el entorno de seguridad, sobre todo por parte de los ataques que Anonymous lanza contra diferentes compañías u organismos gubernamentales o no gubernamentales. Independientemente de nuestras ideologías o de si estamos a favor o en contra de estos movimientos, nuestro deber como profesionales de seguridad es intentar que la empresa para la que trabajamos no sufra ninguna interrupción en su servicio.

Se me ocurrió escribir este artículo raíz de una experiencia vivida en un cliente con un ataque de denegación de servicio del estilo de los que lanza Anonymous. Después de este ataque pasaron un elenco de comerciales de las diferentes marcas vendiéndonos las excelencias de sus productos y como me pico la curiosidad me puse a investigar que ofrecían los fabricantes para protección contra DDoS. Voy a intentar explicar como se comportan los IPS frente a este tipo de ataques y plantear algunas soluciones.

Para los que no sepáis nada de los ataques que Anonymous suele lanzar, se tratan de unos ataques DDoS mediante un programa llamado LOIC. Para los que no conozcáis LOIC, se trata de un programa para ataques de denegación de servicio, en la que los atacantes se reúnen en un canal IRC, y delegan ciertas partes de la configuración de LOIC al administrador del canal. Cada uno de los usuarios del canal IRC se convierte en un integrante de una botnet. No voy a entrar en detalle, ya que se ha escrito mucho en internet sobre esto. Solo decir que LOIC lo que generan son peticiones HTTP normales, como las que generamos cuando navegamos con cualquier navegador, pero con un volumen de peticiones por segundo importante.



En la práctica…


En una empresa u organismo de considerable tamaño, del tipo de las que Anonymous se fija como objetivo, deberían tener ciertas medidas de seguridad estas suelen ser a grandes rasgos IPS, Firewall y balanceadores. Sobre las labores que suele realizar cada uno se podría hablar largo y tendido, ya que los fabricantes integran de todo en todas partes, no es raro ver un IPS con ACL al mas puro estilo Firewall, y no es raro ver Firewalls con módulos IPS, en cuanto a los firewall de aplicación esto ya si que es un caos, en teoría un SQL Injection y un XSS lo debería parar un IPS, pero los Firewalls de gama alta suelen incluir un modulo de firewall de aplicación por no hablar de los balanceadores, que también suelen incluir protecciones de este tipo.

Aunque no hay un modelo estandarizado de que arquitectura de como se deben colocar los dispositivos en la DMZ, y esto depende de la calidad de estos, y además daría para otro articulo, lo mas aconsejable y lo que recomienda Garner (la gente famosa del cuadrante mágico), es poner IPS->FW->Balanceadores. Hay gente que coloca el IPS detrás del FW, esta solución es igualmente valida, y se suele aplicar cuando los IPS no son de mucha calidad y no pueden analizar mucho volumen de tráfico, y así evitar que analicen el trafico que el FW ya esta bloqueando.

El primer punto que tenemos que tener en cuenta es como detectar este tipo de ataques, teniendo en cuenta que se trata de peticiones HTTP totalmente válidas. Detectarlo no es tarea fácil. Uno de los métodos para detectarlo seria monitorizar el servidor web de alguna forma. O bien porque detectemos una carga inusual de la CPU o porque tengamos monitorizado el numero de peticiones web que se realizan, esto se puede hacer por algun sistema de correlación y sacando los datos del propio log del servidor.

Una vez que habéis detectado un DDoS y trabajáis en una empresa medianamente grande, todos los jefes o altos cargos que tengan nociones de seguridad van a mirar a los IPS. Los IPS, básicamente lo que hacen es buscar paquetes con trazas concretas en el trafico de red. Nos puede servir para detectar cualquier tipo de ataque tipo SQL Injection, XSS.. o también lo podemos usar para mitigar virus como Conficker. Como veis en la imagen anterior de LOIC, en attack options hay una parte que se llama subtittle, si todos la gente que nos está atacando se pusiera de acuerdo en el ataque y pusiese el mismo subtitulo, si que podríamos generar una firma en el IPS para bloquear esas peticiones HTTP, pero si activan la opción de “append random chars to the URL”, pues nos han fastidiado. No hay manera de diferenciar entra peticiones de ataque o peticiones de usuarios lícitos. Lo ideal seria que los IPS nos permitieran contar el número de conexiones, pero la mayoría de los IPS no son capaces de hacer esto. Y además los IPS no se diseñaron para contar conexiones, se diseñaron más para analizar patrones de trafico. Sobre que un IDS/IPS nos permita contar conexiones va a depender del fabricante. De si este a implementado un modulo con ese fin. Lo normal es que no la incluyan, o que no sea muy fiable.

Entrando en materia:
  1. Una de las soluciones que proponía uno de los fabricantes que mas me llamó la atención, es usar un correlador de eventos como detector de DDoS y usar el IPS para bloquearlo. Es decir, con un correlador correlas el log del servidor web con una regla para que cuente las conexiones web de las direcciones IP durante un tiempo determinado y cuando una IP exceda ese número de conexiones, el correlador se comunica con el IPS y bloquea esas direcciones IP. Por supuesto el fabricante ya tenia un módulo programado entre su correlador y su IPS. Pero podría ser una idea aplicable a cualquier empresa que tenga un sistema de correlación y un firewall, no seria difícil programar una serie de scripts que introdujeran reglas en el firewall. O delegar esta labor a los operadores de red si es que la empresa dispone de una línea de operación 24h.
  2. Otro fabricante proponía otra solución, su producto tenía un sistema o algoritmo de aprendizaje. Con lo que la idea era activar el modo aprendizaje una semana en el que se suponía que el tráfico iba a ser normal, el IPS aprendía ese patrón de tráfico. Una vez realizado el aprendizaje se supone que el IPS podría detectar volúmenes o patrones de tráfico anormales. Esta solución no es especifica para Ataques de tipo Anonymous y me resultaba un poco descabellada. No conozco al detalle como funciona el algoritmo de aprendizaje, pero suponer que una semana, o un mes tras otro, el trafico va a seguir siendo parecido me parece poco sensato, y dependería de a qué se dedica la empresa. Lo cierto es que con reglas así podríamos llegar a bloquear tráfico totalmente lícito y normal, con lo que eso supondría para las empresas.
  3. Investigando por la red encontré información de otro fabricante que ofrecía una solución muy parecida al anterior, tenía un sistema heurístico que era capaz de detectar cambios en los patrones del tráfico de red, pero esta vez sin proceso de aprendizaje.
  4. Por otro lado, tenemos snort que sí que permite definir una regla de tipo threshold para contar conexiones. Esto es básicamente lo que comentaba al principio: contar las conexiones. Pero tenemos que tener en cuenta que snort es en su origen un IDS, aunque se pueda configurar para que también haga labores de IPS. No he podido comprobar si la versión comercial de este IPS propone la misma solución.
  5. Mas tarde y hablando con gente del sector e investigando encontré un aparato que casi sin querer hace justo lo que se necesita para parar este tipo de ataques: se trata de un balanceador de carga web. Como ya sabréis la mayoría, un balanceador de carga web se coloca justo delante de los servidores web y lo que hace es gestionar las conexiones web repartiendo la carga entre varios servidores web. Algunos implementan un módulo para no colapsar esos servidores y lo que hace es muy sencillo: cuando el balanceador ve que el número de conexiones está saturando los servidores web, empieza a bloquear las direcciones IP que mas conexiones esté generando. Esto es justo lo que se necesita para bloquear los ataques de LOIC. Además tiene algo de sentido parar este tipo de ataques con estos aparatos, ya que son los que se encargan de gestionar las conexiones web y LOIC al fin y al cabo genera conexiones legítimas. Pero esto tiene sus inconvenientes; explicar a los altos cargos de la empresa de que disponiendo una infraestructura basada en IPS en Firewall, vas a tener que usar además un balanceador de carga para parar un ataque de DDoS.
La infraestructura normal de una empresa debería ser la siguiente:
Requisitos y Conclusiones:
  • Tenemos que tener en cuenta que para parar un ataque de este tipo nuestra infraestructura y ancho de banda debe soportar el volumen de tráfico del ataque, y por infraestructura me refiero a todo aparato por el que vayan a pasar las conexiones.
  • Si usamos un balanceador de carga para parar un ataque de este tipo, tienes que explicarle a los peces gordos de la empresa que aun teniendo IPS y Firewalls, vas a parar el ataque justo antes del servidor. Esto es comparable a decirles que vives en una casa con alambrada y puerta blindada, y al final paras a los malos en la puerta de la cocina.
  • Debe haber muchas otras soluciones de las cuales yo no tengo noticias, así que os ánimo a que expongáis cualquier otra solución que conozcáis en los comentarios.
  • Aunque Snort nos soluciona la papeleta, el que un software de este tipo no tenga un gran fabricante al que echar las culpas cuando falle, suele echar para atrás a las empresas.
---------------

Contribución por Manuel Bermúdez

30 comments :

Rodrigo Moreno dijo...

Si ademas de distribuir la carga se usa un proxy invertido? Yo no soy experto en estos temas, pero un amigo si, y justamente planteó el mismo problema de los DDoS de Anonymous y su respuesta fue un proxy invertido + el balanceador de carga: http://www.lastdragon.net/?p=585

Invitado dijo...

http://www.arbornetworks.com

Alf dijo...

Muy buen artículo, aunque se queda sólo en lo que se hace del perimetro "hacia dentro". Hace no mucho escribí uno en mi blog sobre lo que hacer del perímetro hacia fuera. http://www.areino.com/proteccion-contra-ataques-ddos/

Dracco dijo...

Muy interesante este artículo. ¿Existe algún appliance que contenga esas tres características? IPS, FW y LB

xfw dijo...

Cada vez que habláis de DDoS y de como se debería mitigar me da vergüenza ajena (sobretodo cuando dáis consejos a gente como telefónica, etc, que saben muy bien qué hacer y qué no)

Tenéis algo de idea de los que es un TMS de Arbor Networks por ejemplo? o la familia Pravail? Flow Sensors?

Documentaros un poco, que no cuesta mucho

Wi

Alejandro Ramos dijo...

Verguenza da la educación de algunas de las personas que comentan en este blog.

Tal vez, en vez de limitarte a criticar podrías mandar un artículo que aporte algo.

Eh, pero no vale que sean todos los white papers y data sheets que mandaría cualquier comercial con toda la gama de productos de arbornetworks :)

byhanzo dijo...

Y digo yo, ¿no valdría con servicios como los que ofrecen CloudFlare y Akamai? Solo pregunto porque no lo se...

https://es.cloudflare.com/

http://www.akamai.com/html/solutions/security/ddos_defense.html

Alejandro Ramos dijo...

Son ideales, el problema son los precios, por lo menos los de akamai. Cloudfare yo lo usé hace tiempo y por el precio (bajo), también da un poco de miedo...

byhanzo dijo...

Eso te iba a decir, porque lo de CloudFlare, para una empresa el pagar 20€ al mes no es nada...Y para un particular que tenga una web con bastante tráfico y publicidad tampoco...

Y respecto al miedo por el precio... En mi opinión el valorar las cosas por su precio, no me ha gustado nunca ni me gustará. Yo tengo una web con CloudFlare (gratuito) e hice algunas pruebas y me resultó bastante bueno.

Saludos!!!

Alejandro Ramos dijo...

Si, para un particular o una pyme, es genial. Yo también use la gratuita para verlo. Pero para una empresa grande, tiene pinta que se queda pequeño. Si akamai te cobra 20.000€ al mes (por ejemplo) y el otro 20€, algo no cuadra...

Juanma Merino dijo...

Como siempre las medidas que puedas adoptar y su coste irán en función de lo que se está protegiendo. Si nos olvidamos de eso lo mejor es un CDN con Akamai por ejemplo pero pocas empresas españolas pueden justificar esa inversión. 

Alf dijo...

Sobre justificar la inversión. Al final depende del coste de tener un servicio caido durante x horas. Los bancos, las tiendas online de gran volumen, etc. deberían tenerlo.

Otra cosa es que haya telcos (y no miro a nadie) que van ofreciendo por ahí un servicio de "mitigación de DDoS" y que cuatro críos les tiren la web un sábado cualquiera.

xfw dijo...

Alejandro yo no voy a una iglesia a decirle a un cura como dar misa, pero si cantase en élfico en vez de en latín o castellano si que me quejaría ;)



El problema es cuando la gente toma casi como axioma cualquier cosa que
lee en blogs con reputación (que no la pongo en duda ni mucho menos de
este blog, bien merecida en otras ocasiones);  en el caso del que
habláis poner balanceadores, IPS y firewalls es intentar apagar un fuego
a escupitajos, y ya que hay unas cuantas empresas que se dedican
exclusivamente a esto deberíais al menos mentarlas.. (haciendo tests un IPS de alta gama + balanceador F5, o un netscaler Citrix de los gordos se te viene abajo con un 15-18% de la carga que aguantó telefónica ese día en concreto y sólo de esa banda de niñatos, pero eso tampoco sale en las noticias, ni en vuestros análisis) Ni siquiera habláis de que balancear solicitudes no legítimas ya forma parte del problema; ese tráfico se debe categorizar y mitigar antes, ni siquiera debería llegar al load balancer como tráfico legítimo.


Me jodió bastante la otra vez (cuando le dábais recomendaciones a
telefónica para protegerse del club de fans del LOIC) porque de soslayo afectaba a mi trabajo y a muchas horas de trabajo de otros muchos
profesionales que cuando vieron ese artículo directamente se echaron a
reir; lo que no parece que sepáis es la pasta que se gastan los large ISPs en
granjas de mitigación, Threat Management Systems, Policy Enforcers (PRE´s),
colectores de NetFlow, soluciones DPI y cosas así, como para que le recomendéis
que se pongan snorts, o canutazos a akamai así a la ligera.. (y que al fin y al cabo está por demostrar que hubiese sido suficiente)



Puede que yo pecase de falta de educación pero si tu estás replicando lo
haces por soberbia, porque tampoco me rebates nada a nivel técnico; y no quería abrir polémicas absurdas, si no dejar claro que hay gente que trabaja mucho como para que llegue cualquiera a publicar en blogs de cierto prestigio sin verificar ni contrastar, ni ya de lejos conocer los entornos reales de trbajo de todo un sr. Tier1, como parece ser este artículo y el anterior al que hago referencia.

De todas formas delante de unas cervezas seguro que no te habría ofendido mi comentario, es lo que tiene esto de escribir, que no a todos se nos da bien la filología y la retórica sin haberlo estudiado.

Saludos

Webmaster dijo...

A la práctica:

Intentando detener un DDoS
http://foro.elhacker.net/tutoriales_documentacion/intentando_detener_un_ddos-t137442.0.html

Yago Jesus dijo...

 De entrada como bien decía Alejandro, que tu argumentación sea prácticamente ad-hominem, poniendo en duda conocimientos y tan paradógicamente emitiendo esas acusaciones diciendo 'porque yo se' pero sin decir quien eres y con quien has empatado, automáticamente te desacredita.

Te diré dos cosas, no se que has hecho tu en la vida, pero si te contaré que Lorenzo y yo fuimos contratado por 'cierto gran ISP del cable' (guiño guiño) en la época de los ataques DoS al IRC-Hispano, a falta de soluciones fiables al 100% diseñamos la nuestra, incluso fue objeto de estudio en varios foros especializados, revistas, etc.

Respecto a lo que dices de Telefónica, te confirmo que alguien del departamento de seguridad, 'con galones' me confirmó que el ataque DoS de anonymous a Telefónica fueron '4 gatos' -cita literal-

Manuel Bermúdez Casado Bermúde dijo...

Bueno "xfv", como pongo en el post no conozco
todas las soluciones DDoS que existen. La verdad que de la que comentas ni he
escuchado hablar a nadie ni he leído nada . Tampoco me las quiero dar ni me las
doy de mega experto en DDoS, solo hago un post con soluciones que conozco y
como podrás comprobar omito cualquier referencia a fabricantes cosa que tu no
haces.
En referencia a tu primer comentario la educación nunca hay que dejarla de lado
y creo que tú en ese comentario la dejas un poco de lado.


En vez de dar nombres comerciales de soluciones de un
fabricante concreto y de criticar, podías haber gastado el tiempo en explicar técnicamente
como funciona lo que propones, y así sacarme un poco de la ignorancia en la que
parece que vivo. Por último decirte que pareces más un comercial que intenta
vender sus productos generando polémica y criticando que un técnico interesado
en la materia.

Manuel Bermúdez Casado Bermúde dijo...

Cloudflare y akamai son muy buenas soluciones, pero en el
articulo me basaba mas en dispositivos IPS, aunque luego comenta algo de
balanceadores.
De todas formas comparto lo que dice Alejandro, muchas compañías tienen sus
reparos a la hora de contratar estos servicios.

Manuel Bermúdez Casado Bermúde dijo...

Efectivamente Juanma al final todo se puede saturar. Es mas los IPS tienen un sistema de Bypass que entra en funcionamiento cuando tienen mucho trafico, y lo que hace es dejar pasar el trafico sin analizar.

Manuel Bermúdez Casado Bermúde dijo...

Muchas gracias Rodrigo, tendremos que probarlo.

Gonzalo Asensio dijo...

hh

Rodrigo Moreno dijo...

Ojala puedan hacer pruebas reales y hacer un review sobre este tipo de solución, ya que yo no cuento con una infraestructura amplia para hacer pruebas!

He He dijo...

Sobre: "Aunque Snort nos soluciona la papeleta, el que un software de este tipo no tenga un gran fabricante al que echar las culpas cuando falle, suele echar para atrás a las empresas."

echadle un vistazo a:

http://www.sourcefire.com/

ya hay empresas MUY grandes de España apostando mucho por esta solución y no, no llevo comisión.

cgm dijo...

A lo mejor es que la Telco tiene sus equipos de mitigacion en un sitio "mal elegido" para sus .es desde un punto de vista  nacional pero si el ataque es a nivel global, y a sus clientes desde el extranjero si que son capaces de mitigarlo.

cgm dijo...

aah y debes pensar q las Telcos son muuuy grandes a veces y la division que comprar ese servicio no es la española si no la global , a veces pasa

Román Ramírez dijo...

A veces los vendedores de elixires cruzan la frontera de la osadía :D

El Doctor Doxio, famoso por su elixir que cura todos los males, hace fuerte al flojo y guapo al feo ;)

No hay forma humana de que te puedas defender de un DDoS bien organizado. No la hay. Podemos hablar de mitigación, podemos hablar de null-routing, de trucos dns, balanceos, multihomed etc.

El hecho es que la única forma que existe (real) para detener un DDoS en condiciones es que lo hagan los Tier1. Fin.

Ya me he tragado multitud de charlas con el tema de Arbor, con las redes de "tráfico" limpio... venga ya, que dosearon la web de Movistar (sí, es verdad, "unos minutos nada más") y se supone que TIWS les coloca toda la super infraestructura de la muerte doxia para parar "cualquier DDoS".

Me recuerda a cuando empezaron a vender IDS/IPS y eran la solución para todo, o las PKI que eran "imprescindibles", vamos que se hundían tus operaciones sin la PKI...

Es ridículo.

P.D: Excelente artículo sobre mitigación, la verdad. Lo leo con retraso, pero enhorabuena.

Anónimo dijo...

He sufrido este tipo de ataques en carne propia (como operador de un SOC) 14 veces en los últimos 8 meses y no sólo los lanzados desde un botnet LOIC, que no son tan difíciles de mitigar, también un par de slowloris, un nkiller2 y hasta un par de botnets rusos (blackenergy y darkmess).
Y ni firewalls, ni WAFs, ni IPS, ni balanceadores... Solo hemos tenido éxito con esta tecnología para mitigar este tipo de ataques:
http://www.arbornetworks.com/arbor-pravail-availability-protection-system.html

Busirako dijo...

Patético como CSO. A quién se le ocurre investigar soluciones DESPUÉS del ataque? Que carencia total de proactividad. Debo recordar el nombre del autor para jamás recomendarlo en un cargo de seguridad informática.

Pepe Dos Santos Torrijos dijo...

Excelente articulo.

Próximamente también publicare un articulo sobre el mismo tema basado en
el uso de la solución IDS Snort y el plugin SnortSAM para el bloqueo automático
de IP maliciosas consiguiendo de esta manera un IPS bastante efectivo y económico.

En mi opinión se debería desmitificar la alarma social creada por el grupo
anonymous con sus temidos comunicados y amenazas ,  puesto que de
anonimato no tiene nada. Se basan en esa falacia para conseguir adeptos para su
causa. pero no emplean sofisticados medios de ocultación de las IP de las
maquinas de los miembros que participan en las campañas de Ddos , por lo tanto
es muy fácil identificar dichas direcciones y bloquearlas antes de que lleguen
a causar daños mayores , así como recopilar las direcciones para posteriormente
reportarlas a los cuerpos de seguridad.


Su idea de anonimato esta basado en el concepto de la masa
como agrupamiento social (Somos Anónimos. Somos Legión ). La misma táctica que emplean las manadas
de mamíferos para defenderse de las fieras , agrupándose todos sus miembros
para protegerse y al final conseguir despistar a los atacantes debido a que
estos no logran decidirse por una víctima a no ser que localicen algún ejemplar
bastante débil.



Es cierto que sus canales de IRC van cifrados , pero de nada sirve eso si
cualquiera se puede incorporar a sus debates y leer las conversaciones. Es más
si se contabiliza el número de usuarios activos como nodos de ataque en las
campañas no llegan a mas de 200 miembros en el canal IRC. Lo triste es que con
tan pequeña cantidad de usuarios consigan paralizar los servidores webs de sus
victimas.

Así pues una vez que se inicia una campaña de derribo de algún sitio web los
miembros que tengan abierto la aplicación LOIC y empiecen a recibir ordenes de
enviar peticiones HTTP lo realizaran a través de la dirección IP de su máquina  durante todo el tiempo que el coordinador
considere que es necesario.

Aquí el tiempo de reacción es vital para ir bloqueando dichas IP y dejar fuera
de combate cada uno de los miembros que están actuando.

La primera alarma del incidente debería saltar en el departamento de
comunicaciones de la compañía . En los primeros instantes los operadores de
comunicaciones deberán advertir que el consumo de CPU de los firewalls está subiendo
a niveles de vértigo que no son habituales. Los 
gestores de ancho de banda de la infraestructura también son una
herramienta muy útil para detectar la subida de los picos de consumo de
peticiones como para darse cuenta que algo anómalo está sucediendo y 
empezar a poner medidas paliativas, incluso emplear el gestor de ancho de banda
para limitar dichas peticiones.

Una vez pasado este primer nivel de alerta entonces es cuando empiezan a actuar
los IDS / IPS que con una buena configuración de sus políticas de detección
empezaran a cortar el tráfico de cada atacante hasta dejar fuera de combate a
cada uno de los miembros de anónimos sin que consigan su objetivo de derribar
la web de la compañía atacada.

Crear firmas eficaces en los IDS contra el tráfico generado por anonymous es
bastante sencillo. Basta con reproducir los ataques en un laboratorio
capturando los paquetes que envía la herramienta LOIC y de esta manera obtener
los patrones de las peticiones que emplean que se van a emplear para construir las
firmas.
 

Odiseo dijo...

Tengo visto que por ejemplo en las nuevas versiones de
Fortinet incluyen  NBL y desde hace algún
tiempo tiene opciones para utilizar en caso de DDOS. Tienes algunos de los puntos
que planteas en la nota. En una de esas podrían llegar a ser usados para
detener algún tipo de DDOS. Ahora desconozco que carga de ataque podrían llegar
a soportar. Calculo que deber estar relacionado mucho con el hardware de cada
equipo.

Saludos.

Jevalenciap dijo...

Otra simplemente que se esta viendo en muchas empresas son los WAF (Web Firewall Aplicaction), los cuales detectan cualquier tipo de vulnerabilidad que exista en un Web Service,  actuan bloqueando al atacante y permitiendo mayor seguridad a los programadores de que su codigo no sea blanco de diversos ataques, muchos de estos Firewall detectan ataques de DDos mediante un umbral de conexiones permitidas desde una IP origen.
Muchas implementaciones de este Firewall se hacen como Proxy reverse o  en forma transparente (bridge).