Slowloris: DoS para Apache

julio 1, 2009
En líneas generales, para generar un DoS (o DDoS) en un sitio con suficientes recursos, es necesario hacer uso de una botnet, un montón de ordenadores zombies a nuestro servicio, que efectúan peticiones de forma simultánea contra un objetivo común, configurable en tiempo y en lugar por el atacante. Al final, la denegación de servicio del objetivo se puede hacer efectiva por varias causas:
  • Porque el servidor o los servidores, son incapaces de contestar a tantas peticiones de forma simultánea
  • Alguno de los mecanismos intermedios (routers, switches, firewalls, balanceadores…) que atraviesan dichas peticiones se satura de peticiones y se ve incapaz de gestionar la marabunta
  • El ancho de banda disponible de dicha organización se ve desbordado y el tráfico lícito se pierde en un gran porcentaje o se degrada el servicio.

El DoS que os presentamos actualmente corresponde a los del primer tipo descrito.

Hace ya una semana que se ha dado a conocer una nueva herramienta que ha puesto los pelos de punta a la comunidad: Slowloris. El autor de la criatura, Robert Hansen, publicó en http://ha.ckers.org/ el código fuente y el funcionamiento básico.

Este “sencillo” script hecho en Perl implementa una potente e inteligente manera de generar una denegación de servicio sobre un servidor web Apache. Para ello, se basa en la cantidad de peticiones que es capaz de mantener un servidor web de forma concurrente. La forma de saturar el pool de servicios es mediante la creación de “requests” HTTP (con HTTPS también funciona) de manera que se empiezan a enviar cabeceras y más cabeceras al servidor de manera que así se fuerza a mantener abierta las conexiones por parte del servidor. Los servidores web tienen determinado un número máximo global de sockets permitidos (configurados en los ficheros correspondientes).

Se trata de un DoS localizado al servicio web en concreto, manteniendo el resto de los servicios de la máquina accesibles.

¿Cómo mitigarlo?
Madre mía, qué buena pregunta. La verdad es que tiene una respuesta complicada.

He encontrado en Internet multitud de módulos Apache que se pueden incluir en el servidor web para efectuar diferente tipo de restricciones. Describo un poco los que más me han llamado la atención:

  • mod_evasive: Este módulo sirve para gestionar el número de peticiones por IP hacia una misma página en concreto o hacia el servidor en general. Se configuran los umbrales que permitimos así como diferentes sistemas de notificación (bloqueo dinámico con IPTables, correo de notificación de detección de intento de DoS, Syslog, etc,…)
  • mod_limitipconn: Mediante este simple módulo, podemos restringir el número de peticiones origen desde una única IP hacia un servidor. Permite configurar diferentes políticas según el Location, el tipo de fichero a descargar, etc,… para “abrir la mano” y no provocar una autodenegación de servicio.
  • mod_ip_count: Aún más simple que los anteriores, comprueba si el número de peticiones HTTP desde una única IP excede un tamaño máximo definido durante un periodo de tiempo.
Con todos ellos, la verdad es que hay que tener mucho cuidado, puesto que si configuramos de una forma excesivamente restrictiva estos módulos podemos generar la denegación de servicio nosotros mismos. Esto ocurriría por ejemplo, si los visitantes del servidor web acceden al mismo utilizando la misma dirección IP. Esto sucede cuando todas las peticiones salen desde una misma red cuyo router o firewall efectúa un NAT utiliza una única IP pública hacia Internet (lo más normal del mundo) o mediante un proxy.

Otra posible solución para paliar un ataque hecho mediante Slowloris es modificar, en el propio servidor web, el valor del parámetro TimeOut así como KeepAliveTimeOut. Para el primero por defecto son 300 segundos (o sea 5 minutos), lo cual puede hacer que efectivamente nuestro Apache sea carne de DoS en un corto espacio de tiempo. Si lo modificamos a un valor inferior (sin pasarse, puesto que una vez más, peticiones legítimas dejarían de funcionar), obligaríamos a que el atacante con slowloris hiciera uso de más y más máquinas para consumirnos muchas conexiones en muy poco tiempo. El segundo valor es el tiempo que espera para más peticiones bajo una misma conexión persistente. Por defecto viene a 15 segundos; un valor inferior liberará antes los recursos de esas conexiones persistentes.

Dentro de la propia máquina que alberga Apache (si es un *NIX) se pueden utilizar las herramientas propias del kernel de la máquina o del cortafuegos integrado para establecer políticas de conexión por cada IP.

Asimismo, utilizar las opciones de configuración provistas por los dispositivos intermedios (como firewalls o IPSs) podrían ser de utilidad también, para mitigar el flujo de tráfico que permitimos hacia el servidor web.


DoS a WorldWide DN

mayo 27, 2009

Al igual que el año pasado, el proveedor WorldWide DNS ha vuelto a ser víctima de ataques de denegación de servicio distribuido o DDoS desde las 1:00 a las 4:30 AM CST.

De momento, sólo lo indican en su página web, pero todos aquellos clientes de este proveedor (DNS fijos y dinámicos) se han encontrado esta mañana sin servicio. Las recomendaciones que el propio proveedor sugiere a sus clientes son aumentar el TTL (Time To Live) para las zonas DNS a 12 horas (43200 segundos) o más si no necesitan tener un valor de TTL muy bajo. La mayoría de los ISPs recomiendan un TTL de 24 horas (86400 segundos) o más.

Según WorldWide DNS, el ataque vino sin aviso ni provocación por su parte. Actualmente el servicio está restablecido, aunque no saben durante cuánto tiempo puesto que no conocen aún el origen del mismo.

En general, un ataque de denegación de servicio distribuido (DDoS) es uno de los más difíciles de defender debido al inmenso volumen de tráfico que viene desde diferentes orígenes (con muchas probabilidades de IPs spoofeadas). Hay que distinguir que, por un lado puede darse un ataque de denegación de servicio porque el caudal de ancho de banda entrante a una organización es colapsado, y por otra parte aquellos ataques basados en el comportamiento de una aplicación de procesamiento pesado (aquellas aplicaciones que una sola petición ya exige muchos recursos de una máquina).

En el primer caso, las soluciones son muy pocas. Por lo visto aquellos sitios que se han visto amenzados y/o atacados de esta manera, han podido mitigar el impacto mediante la utilización de servicios como Akamai (una red de cachés y aceleración de tráfico mediante la distribución de procesos). En el segundo caso, aplicaciones pesadas (pero el consumo de ancho de banda no se ve colapsado), hay otro tipo de soluciones, como incrementar el número de servidores que van a dar el servicio, utilización de dispositivos gestores de ancho de banda que permitan devolver a un cliente una respuesta de “ocupado” cuando los servidores aún no estén colapsados, permitiendo dar servicio con los recursos disponibles al menos a un número limitado de usuarios manteniendo la calidad del mismo.

Fuente:http://www.securitybydefault.com/2009/05/dos-worldwide-dns.html


Los fundadores de The Pirate Bay idean un ataque DDo$

mayo 13, 2009

Los 4 miembros del conocido portal de búsquedas de archivos torrent “The Pirate Bay” fueron condenados a un año de prisión y a pagar algo más de 2,7 millones de euros, en un juicio que podría catalogarse de poco imparcial. Esta sanción inspiró a Gottfrid Svartholm, uno de los 4 miembros del portal, a idear un método a través del que anima a pagar esta deuda, pero en cantidades pequeñas, de 1 corona sueca (SEK), unos 0,13 $. El fundamento del “ataque” está en que el banco no cobra por las primeras 1000 transacciones. A continuación cobra por cada una 2 SEK, con lo que el beneficiario tendría pérdidas en cada pago. ¿Se podría utilizar este tipo de pagos aquí para pagar las demandas contra blogs, portales,…?


Classic DOS Games: Abandonware en tu navegador

marzo 17, 2009

Verdaderos clásicos de los videojuegos han quedado cubiertos por el manto de la historia, y sólo algunos audaces se atreven hoy en día a revivir a aquellas joyas entre sistemas de doble núcleo y gigabytes de RAM. En muchos casos, los desarrolladores originales de dichos juegos ceden sus derechos convirtiéndolos en freeware, o en algunos casos, la empresa creadora desaparece, sin capacidad de reclamar al juego original. En esa categoría cae el “abandonware”, y una página ha puesto a varios de estos títulos en línea, con la posibilidad de ser jugados a través del navegador.

En realidad no es la primera vez que escuchamos algo así. Varios han recreado diferentes versiones de clásicos juegos bajo plataformas como Flash o JavaScript, permitiendo que cualquier visitante pueda jugar estos títulos con sólo una conexión a Internet y un navegador. Pero ClassicDosGames.com lleva esto un poco más allá, colocando a disposición de sus visitantes un listado de mas de 100 juegos para DOS que pueden ser disfrutados directamente desde el navegador. Muchos de ellos son shareware, ya que a pesar de los años sus creadores no han cedido sus derechos, pero dentro de la lista existen varios títulos freeware.

Un poco de “Jetpack” para distraernos

La página logra presentar estos juegos gracias a una emulación en línea cargada a través de un entorno Java. Primero se descarga la imagen del juego, se inicia FreeDOS como sistema operativo, se realizan algunas detecciones como ratón y teclado, y después el juego es iniciado. La velocidad de la emulación depende exclusivamente de la velocidad del ordenador y de qué tan pesado sea el juego que está siendo emulado, pero en este punto no hay mayores problemas. Donde sí los hay es a la hora de presentar el juego en la pantalla. En algunos casos hemos detectado que ciertos juegos ni siquiera pudieron ser ejecutados, mientras que otros se veían muy mal.

FreeDOS es parte del entorno de emulación
Nos quedamos con las ganas de jugar Lemmings. Una pena.

Otro punto flojo es la selección de juegos disponible. Los más atractivos sólo son presentados como shareware, mientras que los freeware y los abandonados no son precisamente llamativos, y hay que buscar entre el montón. Podemos extraer de esta lista al Jetpack y a Xargon, pero todo lo demás de interés se encuentra en versiones reducidas. De todas formas, es muy destacable el poder ver que se puede presentar un entorno de emulación en forma remota. Hay varios juegos freeware que necesitan de un emulador de DOS para poder ser ejecutados, y el que se pueda utilizar un navegador como base abre unas cuantas puertas para quien esté interesado en hacer una versión en línea de aquellos clásicos títulos… siempre y cuando no sea perseguido por sus desarrolladores originales.

Fuente: Neoteo.com