Credit image

¿Te gusta el diseño web? ¡Echa un vistazo a la documentación de LenguajeCSS.com!

Mod Evasive: Evitando una Denegación de Servicio Distribuida

Una denegación de servicio DoS es un tipo de ataque donde se realizan una serie numerosa de peticiones a un servidor con el objetivo de que se sobrecargue atendiéndolas y se colapse.

Una denegación de servicio (DoS) es un tipo de ataque (muy común en ámbitos de servidores web) donde un atacante se encarga de realizar una serie muy numerosa de peticiones a un servidor (usualmente una petición de naturaleza muy costosa) con el objetivo de que se sobrecargue atendiéndolas y se colapse, denegando el servicio a otros posibles usuarios.

Este tipo de ataques, muy simples, no suelen tener mayor gravedad a no ser que se combinen con algún tipo de vulnerabilidad del sistema, ya que como se trata de un único usuario, basta con identificarlo y bloquearlo.

Sin embargo, existe otra variante, denegación de servicio distribuida (DDoS) en la que se utiliza el mismo concepto anterior, sólo que esta vez en lugar de tratarse de un sólo atacante se trata de una red distribuida de atacantes (conjunto de usuarios «sincronizados» como uno).

Este último caso si está considerado de los más peligrosos, ya que no se trata de una sola entidad la que intenta atacar, sino de una «flota» de atacantes muy numerosa, en la que un sólo servidor normalmente se desborda al recibir tantas peticiones.

Tengamos también en cuenta que, normalmente, estas redes distribuidas están formadas por miles de atacantes, que a su vez son víctimas (usuarios o servidores infectados con troyanos o virus, sin saberlo) que silenciosamente forman parte de botnets.

Para intentar frenar estos ataques vamos a utilizar un módulo para Apache llamado mod_evasive. Y digo intentar frenar, porque siempre hay que tener en cuenta cuál es el objetivo del DDoS: Si es provocar una denegación de nuestro servidor web (u otro) nos servirá perfectamente. Si se trata de provocar una denegación de nuestra red local, router u otro elemento relacionado con el flujo de red, de poco nos servirá, ya que el módulo actua a nivel de aplicación.

Este módulo se encarga de gestionar una tabla hash con las IPs con accesos más frecuentes al servidor. Así, si detecta un número desmesuradamente alto de peticiones desde una misma IP, las anulará por un tiempo.

Preparación y compilación de mod_evasive


Este módulo es compatible tanto con Apache 1.3 como con Apache 2.0 (además también de iPlanet), sin embargo esta guía está especificada concretamente para Apache en su versión 2.

  • Descargar mod_evasive: Desde la página oficial de mod_evasive se puede descargar la última versión o desde una terminal escribiendo:

    wget http://www.zdziarski.com/blog/wp-content/uploads/2010/02/mod_evasive_1.10.1.tar.gz
  • Desempaquetar mod_evasive: Procedemos a desempaquetar el módulo fuente de apache:

    tar -xzvf mod_evasive_1.10.1.tar.gz
  • Compilar y obtener el módulo: El paquete de mod_evasive descargado es el código fuente, así que hay que compilarlo para obtener el módulo de Apache. Para ello nos ayudaremos de la utilidad apxs (Apache Extension Tool).

    apxs -i -a -c mod_evasive20.c

    Si no tienes la utilidad apxs, asegurate e instala el paquete de desarrollo de Apache, Apache-devel, antes. También puedes utilizar el clásico make mediante el fichero Makefile.tmpl.

Una vez realizados estos pasos, la compilación nos habrá creado el fichero mod_evasive20.so en nuestra carpeta de módulos de Apache (/usr/lib/httpd/modules).

Instalación y carga de mod_evasive


Generalmente el apxs se encarga de realizar la compilación del módulo, copiarlo en la carpeta de módulos de Apache e incluir la linea de carga en la configuración de Apache. No obstante, no estaría de más que lo comprobaramos.

  • Comprobar carga de mod_evasive: En una terminal escribimos lo siguiente (NOTA: la carpeta puede variar según la distro de linux)

    grep evasive /etc/httpd/httpd.conf

    Lo que nos debería devolver algo similar a lo siguiente:

    LoadModule evasive20_module /usr/lib/httpd/modules/mod_evasive20.so

    Si no es así, debemos incluir dicha linea en el fichero de configuración de Apache, para cargar correctamente el módulo.

  • Incluir configuración mod_evasive: Finalmente, añadimos también la siguiente linea en el fichero anterior:

    Include mod_evasive.conf

    Creando, por consiguiente, un fichero llamado mod_evasive.conf en la misma carpeta, donde estableceremos las distintas directivas del módulo, que veremos a continuación.

Configuración de mod_evasive


Con la linea vim /etc/httpd/mod_evasive.conf cargaremos el fichero de configuración de nuestro modulo, preparandolo para adaptarlo a nuestro gusto.

DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10

Esta es la configuración que trae por defecto mod_evasive. Sin embargo, pasaremos a repasar todas las directivas para una mayor personalización.

  • DOSHashTableSize: Tamaño de la tabla hash que almacenará las IPs (nodos). Por defecto el valor es de 3097.

  • DOSPageCount / DOSPageInterval: Máximo (umbral) que se debe alcanzar para ser incluído en la lista de bloqueados. En este caso el objetivo será una página concreta. (Entiendase como «Máximo de DOSPageCount páginas en DOSPageInterval segundos»).

    Por defecto el máximo está establecido a 2 páginas por segundo.

  • DOSSiteCount / DOSSiteInterval: Máximo (umbral) que se debe alcanzar para ser incluído en la lista de bloqueados. En este caso el objetivo será cualquier objeto (imagenes, css...). (Entiendase como «Máximo de DOSSiteCount objetos en DOSSiteInterval segundos»).

    Por defecto el máximo está establecido a 50 objetos por segundo.

  • DOSBlockingPeriod: Tiempo en segundos (contador) que permanecerá bloqueada la IP de la lista. Dentro de este periodo, los accesos desde dicha IP obtendrán un error HTTP 403 (prohibido).

    En el caso de que la IP intente acceder dentro del periodo de bloqueo, el contador vuelve a ponerse en su valor inicial y tendrá que volver a transcurrir el número de segundos desde el principio de nuevo.

  • DOSEmailNotify: Opcional. Dirección de email a la que serán enviadas (mediante el comando mail) notificaciones cuando se bloqueen IPs. Incorpora sistema lock para no repetir varios emails y notificar una sola vez.

  • DOSSystemCommand: Opcional. Comando que será ejecutado cada vez que se añada una IP a la lista. Se reemplazará %s por la IP. De este modo, una buena técnica es hacer lo siguiente:

    DOSSystemCommand "/sbin/iptables -I INPUT -p tcp --dport 80 -s %s -j DROP"

    Lo que hará que se ejecute el firewall de Linux (iptables) y bloquee todas las peticiones entrantes por el puerto TCP/80 (web).

  • DOSLogDir: Opcional. Selecciona una carpeta como directorio temporal para los logs. Por defecto, si no es especificado, tiene el valor /tmp.

  • DOSWhitelist: Opcional. Incluye una lista blanca para IPs que no tendremos en cuenta para bloquear. Ideal para añadir por ejemplo, el rango de IPs de los bots de Google (rango CIDR 66.249.64.0/19):

    DOSWhitelist 66.249.73.*

    Puedes usar varias directivas DOSWhitelist y comodin de rangos de hasta los 3 últimos octetos.

Finalmente, guardamos el fichero de configuración y reiniciamos el servidor Apache /etc/init.d/httpd restart. Ya tenemos listo el mod_evasive para funcionar.

Testeo de mod_evasive


Para realizar una prueba y comprobar si funciona correctamente, utilizaremos el fichero test.pl incluido en el paquete descargado. Ojo con tener la opción del firewall activada, aconsejo desactivarla para la prueba. Se trata de un pequeño programa en Perl, que realiza 100 peticiones secuenciales a nivel local (muy rápido, menos de 1 segundo). Así, si sistema está funcionando bien, al ejecutar el programa perl test.pl, aparecería algo similar a esto:

[...]
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
[...]

A medida que se efectuan las conexiones, se irán sirviendo correctamente, hasta que el mod_evasive detecta que se ha sobrepasado el umbral e incluye la IP local (127.0.0.1) en la lista de bloqueados.

Escrito por Manz, el , en seguridad. Comentarios recibidos: 25.

25 comentarios de lectores
alberto
alberto
1

Hola impresionante modulo que desde luego me va a solventar mucho , pero tengo una duda en un sistema de gestión que se podría cargar este modulo , me explico . Si por ejemplo tenemos un sistema de gestión administrativa donde un usuario hace muchas peticiones ya que necesita el programa para trabajar, el modulo podría denegar el servicio puesto que le están llegando un huevo de peticiones desde la misma ip o se necesita muchísimas peticiones pare ello. Un saludo Manz

Pablo
Pablo
2

Un crack Manz, hoy no me sirve esto, pero en unos meses cuando decida contratar el dedicado me vendra genial. Directo a Del.icio.us esta entrada. Gracias!

Manz
Manz
3

Alberto hay que recalcar que este sistema no es infalible ni mucho menos. Lo único que hace es proveer una capa de seguridad a nivel de aplicación para proteger de DDoS que van dirigidos expresamente a servidores. Existen muchos otros tipos de DDoS, sobretodo los de fuerza bruta, que intentan hacer flood aprovechandose de que tienen más "caudal" de red y desbordan routers, switchs y demás sistemas hasta dejarlos inactivos temporalmente. Contra estos ataques hay poco (nada) que hacer a nivel de aplicación, eso hay que tenerlo claro. Sin embargo, para protegernos de ciertos ataques que tienen como objetivo el software, son muy efectivos. No todo el mundo tiene los recursos necesarios como para efectuar un DDoS con botnets a gran escala :) Pablo, ¡gracias a ti!

Angel
Angel
4

Interesante! La verdad es que mucho me ha pasado que a veces sin razón aparente mi web anda más lenta que a saber qué! Seguro habrán muchas formas de ataque de file y bdd injection, pero esto que comentás me es nuevo y voy a profundizar en ello. Me pregunto si habrán maneras de tener esa identificacion de apache a nivel de htaccess, me refiero para aquellos que no tengan acceso a la shell.

Manz
Manz
5

Angel desgracidamente, necesitarás acceso como administrador al servidor, a no ser que ya tengan instalado el módulo y permitan configurarlo a usuarios del sistema. Saludos,

Angel
Angel
6

Ya me lo temía. Pero así como dice Pablo cuando uno se mueva a un dedicado esto viene de maravilla.

Julio
Julio
7

Para descartar todas ip de los robots google son: t 66.249.73.* o será más aproximado 66.249.*.*. Podriamos indicar por resolucion inversa, es decir, si determinada ip nos da como resultado google. No estoy seguro, pero un determinado atacante nos puede enviar paquetes, con la ip de google (falsificacion de ip). A mi se me ocurre una manera, utilizando php, accediendo gmail, e enviar email. Pero demasiado complicado conseguir que se sincronizen tantos email para la negación, porque ademas el gmail te bloquearía rápidamente detentando que eres un spammer.

Manz
Manz
8

Julio, en primer lugar con lo de la IP tienes razón. Ya que Googlebot tiene el rango CIDR 66.249.64.0/19, el ejemplo que puse no los abarca todos, pero era más didáctico de ver. He mirado la documentación y no estoy seguro si habría que indicar 66.249.* o 66.249.*.*. Respecto a lo de la falsificación de IP, quizás no te he entendido bien, pero creo que no es posible. Gmail no participa para nada en estos ejemplos, ya que estamos hablando de accesos web a nivel de red. Saludos,

julio
julio
9

Manz, pues llevas razón gmail, no tiene nada que ver en lo del servidor web. Pero lo que pretendo decir si se pueden enviar paquetes con peticiones al servidor web, con una cabeceras falsas dónde indiquen la dirección ip de google ( que estaría en nuestra lista blanca). Seguramente creo que se podrá a bajo nivel de programación. De todas formas, con este módulo te puede quitar un gran número de ataques.

Manz
Manz
10

Julio ya he entendido a lo que te referias. Sin embargo, de la forma que mencionas (por ejemplo visualizando un email que contiene la página web de un servidor) la IP que llega al servidor es la del cliente que esta visualizando el correo (nosotros mismos) no la de Gmail. Saludos,

julio
julio
11

Ok, Entiendo. Otra pregunta, sobre la lista blanca para conseguir descartar la ip del googlebot. El problema que google tiene varios datacenter (seguro que distintos robot en cada datacenter). Entonces el rango que puesite no cubriría algunos datacenter. Por ejemplo esta ip 72.14.255.18. Entonces, habría buscar una solución más cómoda, por ejemplo que una determinada ip resuelve un dominio google.* . O si detectamos que el cliente se identifica como googlebot. Aunque creo que de resolución inversa no va enteder este módulo porque se encarga el bind. Pero ha veces preguntando descrubes cosas que no te esperas.

Manz
Manz
12

He estado mirando el código fuente del módulo y los DOSWhitelist hay que indicar comodin por octeto, tipo 66.249.*.*, como indicó Julio previamente. Por otra parte tengamos en cuenta que el ejemplo de Googlebot era simplemente didáctico para entender el DOSWhitelist. Estamos hablando de un limite por defecto de 50 peticiones de página por segundo para el mismo cliente. Googlebot no suele ser tan agresivo con su indexación, yo mismo revisando logs de Emezeta, como muy frecuente, hace peticiones en intervalos de 10 segundos. También tener en cuenta que se pueden usar varias instancias de DOSWhitelist.

Xelso
Xelso
13

Y cuando vas a poner los log, para ver como intentan tumbarte el servidor, que eso es divertido. (esta mierda no peta ahora!!)

Geri1590
Geri1590
14

Buenas, he seguido al pie de la letra todos los tutoriales que me he encontrado para el mod_evasive. Todos decian practimamente lo mismo.. asi que decidi postear en este. Cuando tengo el mod_evasive .. ejecuto el siguente comando: /usr/bin/apxs2 -c -i -a mod_evasive20.c y me muestra lo siguiente: /usr/share/apr-1.0/build/libtool --silent --mode=compile --tag=disable-static i4 86-linux-gnu-gcc -prefer-pic -DLINUX=2 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -D_RE ENTRANT -I/usr/include/apr-1.0 -I/usr/include/openssl -I/usr/include/postgresql -I/usr/include/xmltok -pthread -I/usr/include/apache2 -I/usr/include/apr-1. 0 -I/usr/include/apr-1.0 -I/usr/include/postgresql -c -o mod_evasive20.lo mod _evasive20.c && touch mod_evasive20.slo /usr/share/apr-1.0/build/libtool: line 1222: i486-linux-gnu-gcc: command not fou nd apxs:Error: Command failed with rc=65536 **Tengo la version 2.2 de Apache corriendo sobre Debian 4. - Si alguien me puede ayudar se lo agradecere :)

Manz
Manz
15

@Geri1590: Si te fijas hace referencia a un i486-linux-gnu-gcc que no existe. Quizás no tienes correctamente instalado el GCC. Prueba con lo siguiente: apt-get install gcc

Geri1590
Geri1590
16

Hola de nuevo, primero darte las gracias ya que el fallo era el que comentabas, de momento esto solucionado. Ahora aparece un fallo mas leve que creo que se podria instalar el evasive manual pero no me atrevo por intentos anteriores fallidos :S xd [........] more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- chmod 644 /usr/lib/apache2/modules/mod_evasive20.so apxs:Error: Activation failed for custom /etc/apache2/httpd.conf file.. apxs:Error: At least one `LoadModule' directive already has to exist.. Esta vez me ha surgido una duda. El apache2 tiene su archivo de configuracion en apache2.conf... y en etc, almenos en debian por defecto, no viene en /etc ninguna carpeta llamada httpd. ¿Es la configuracion automatica del evasive correcta? y en ese caso, que tendria que hacer? Gracias por adelantado y un saludo!! :D

Manz
Manz
17

@Geri1590: Como puedes ver, en la línea: chmod 644 /usr/lib/apache2/modules/mod_evasive20.so Ha creado el fichero de módulo mod_evasive20.so correctamente, y le ha dado los permisos adecuados con chmod. Al realizar la instalación, el apxs realiza una configuración automática, añadiendo la linea LoadModule en el fichero de configuración del Apache. En algunas distros la ruta es /etc/httpd/httpd.conf, en otras /etc/apache2/apache2.conf, etc. Tu apxs debería añadirla en el fichero apropiado, pero al fin y al cabo es un mal menor. Lo único que tienes que hacer es acceder a tu fichero de configuración (sea httpd o apache2) y añadir la linea correspondiente de forma manual, como indico más arriba. Saludos,

Geri1590
Geri1590
18

jajaj muchas gracias !!!! problema arregladoo!! y el test funciona :D Muchas gracias Manz, ya estaba desesperado :) Por cierto, felicidades por el blog -- es bueno y encima te atiende al instante ^^ :-) las viñetas molan bit y bite jaja :D

3plej-j
3plej-j
19

hola si la falsificacion ip se llama spoofing y puedes buscar info buscando 3ple-j en googla usa tu inmaginacion en keywords

bernardo
bernardo
20

la url de mod_evasive no es valida. me marca error 404. no pude encontrar 1 url que sirva :(

Manz
Manz
21

@bernardo: La web había cambiado de dirección, ya está corregida.

Abdelkarim
Abdelkarim
22

Tienes aqui un script para evitar meter las Ip de googlboot en denegacion, metiendolas en listablanca DosEvasive y googlebot

Hosting Chile
Hosting Chile
23

Excelente información. saludos.

Ivan
Ivan
24

En la siguiente url comentan un bug de programación en el mod_evasive. http://el-blog-de-thor.blogspot.com.es/2009/04/fallo-de-programacion-en-modevasive.html Parece ser que nadie se dió cuenta antes.

dennis
dennis
25

hola amigo, segui todos los pasos para instalar el mod_qos para apache. y en la ultima parte donde me indicas que reinicie el apache. me salio este mensaje : [root@nodo1 ~]# service httpd restart Parando httpd: [FALL?“] Iniciando httpd: httpd: Syntax error on line 1023 of /etc/httpd/conf/httpd.conf: Cannot load /usr/lib/httpd/modules/mod_qos.so into server: /usr/lib/httpd/modules/mod_qos.so: undefined symbol: EVP_DecryptFinal [FALL?“] ya no se puede iniciar el apache. que podria hacer en este caso gracias de antemano.

Publica tu opinión

Si lo deseas, puedes utilizar el siguiente formulario para publicar tu opinión o responder a alguna de las existentes:

Previsualización

Aquí se previsualizará su comentario. Revise que sea correcto antes de publicarlo.