EiTheL Inside: Instalar ModSecurity2 (+OWASP) y Mod-Evasive en Ubuntu 13.10 con Apache

modSecurity™ es un firewall de aplicaciones Web embebible que ejecuta como módulo del servidor web Apache, provee protección contra diversos ataques hacia aplicaciones Web y permite monitorizar tráfico HTTP, así como realizar análisis en tiempo real sin necesidad de hacer cambios a la infraestructura existente.

(Fuente Wikipedia)

Mod_Evasive ayudará a detener los ataques básicos en un servidor (HTTP, ataques de denegación DDoS y ataques de fuerza bruta). La detección es realizada por la creación una tabla dinámica interna hash de las direcciones IP y URI, y denegando cualquier dirección IP por las siguientes causas:

-Solicitando las mismas páginas web muchas veces por segundo.

-Solicitando más de 50 conexiones simultaneas sobre el mismo objeto por segundo.

-Realizando solicitudes con listas negras temporales (sobre listas de bloqueo).

(Fuente Internexo)

Así pues, nuestra idea es instalar un servidor web Apache con un módulo que nos haga de cortafuegos de aplicaciones Web y con otro módulo que nos ayuden a detener los ataques básicos que recibimos en un servidor web. Además, tenedremos reglas generadas para programas comunes como:

Microsoft IIS, ASP, .Net and SharePoint
WordPress
cPanel
osCommerce
Joomla

Con estos sencillos pasos podremos tener un servidor web bastante más protegido que si simplemente instalamos nuestro servidor y lo dejamos desprotegido cara a Internet. Es hora de armar a nuestro Apache:

modsecurity

Instalamos modsecurity desde el repositorio de Ubuntu oficial:

apt-get install libapache-mod-security

Leyendo lista de paquetes... Hecho

Creando árbol de dependencias

Leyendo la información de estado... Hecho

Se instalarán los siguientes paquetes extras:

libapache2-modsecurity liblua5.1-0 modsecurity-crs

Paquetes sugeridos:

lua geoip-database-contrib ruby

Se instalarán los siguientes paquetes NUEVOS:

libapache-mod-security libapache2-modsecurity liblua5.1-0 modsecurity-crs

0 actualizados, 4 se instalarán, 0 para eliminar y 7 no actualizados.

Necesito descargar 664 kB de archivos.

Se utilizarán 3.741 kB de espacio de disco adicional después de esta operación.

En otras webs veréis que antes de instalar modsecurity se instalan unas dependencias. Eso tiene sentido si nos descargamos las fuentes de modsecurity y luego las queremos compilar. Nosotros lo estamos haciendo directamente desde el repositorio, así que si hay alguna dependencia ya nos lo dice el propio apt-get.

Ahora ya tenemos instalado el modsecurity. Nos queda configurarlo para que funcione como nosotros deseamos. Lo primero es crear el archivo de configuración basándonos en el que ya viene de ejemplo:

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Ahora tocará configurar el modsecurity como nosotros deseemos. Cada cual en su servidor sabe que puede o no hacer. O que se espera que pase y que no pase. Si por ejemplo nuestro servidor es un wordpress o Joomla! en donde permitimos subir archivos, seguramente nos va a interesar cambiar la directriz de modsecurity de esta manera:

SecRequestBodyLimit 16384000

SecRequestBodyInMemoryLimit 16384000

De esta manera cambiamos el límite de tamaño de archivos que subimos a nuestro servidor de 128Kb a 16Mb . Pero esto sólo si es lo que deseamos que haga. Si es una web que no espera que se suban archivos, lo mejor seria dejarlo como está.

Sea como sea, lo que seguro que tendremos que hacer es activar el motor modsecurity. Para ello modificaremos el modsecurity.conf :

SecRuleEngine On

Una vez configurado como deseamos el modsecurity, lo siguiente es bajarnos las reglas de OWASP Core Rule Set

OWASP Core Rule Set

OWASP Core Rule Set nos va a mejorar el conjunto de reglas de nuestro modsecurity de manera que se convierte en el compañero ideal en este viaje de seguridad que estamos haciendo.

Esto si que no lo podemos instalar desde repositorio, y aunque pudiéramos en esta ocasión si que creo que vale la pena bajarse la última versión. Es el corazón de reglas que hara que estemos seguros. Lo bajamos y lo descomprimimos:

wget -O SpiderLabs-owasp-modsecurity-crs.tar.gz https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master

tar -zxvf SpiderLabs-owasp-modsecurity-crs.tar.gz

Bien, ahora ya tenemos el conjunto de reglas que copiaremos en la carpeta de configuración de modsecurity (todos los .conf copiados allí se consideran archivos de configuración del programa modsecurity):

cp -R SpiderLabs-owasp-modsecurity-crs-*/* /etc/modsecurity/

mv /etc/modsecurity/modsecurity_crs_10_setup.conf.example /etc/modsecurity/modsecurity_crs_10_setup.conf

Llegado a este punto debemos activar las normas. Funciona del mismo modo que apache. Están disponibles pero sino creamos el acceso directo no las dejamos activadas (de esa manera puedes activar unas normas si y otras no si fuera el caso). Las normas disponibles se guardan en /etc/modsecurity/base_rules y las normas activadas se guardan en /etc/modsecurity/activated_rules. Vamos a activarlas todas:

cd /etc/modsecurity/base_rules

for f in * ;

sudo ln -s /etc/modsecurity/base_rules/$f /etc/modsecurity/activated_rules/$f ;

done

cd /etc/modsecurity/optional_rules

for f in * ;

sudo ln -s /etc/modsecurity/optional_rules/$f /etc/modsecurity/activated_rules/$f ;

done

Podemos comprobar que el directorio /etc/modsecurity/activated_rules de estar vacio ahora presenta muchos archivos:

/etc/modsecurity/activated_rules# ls

modsecurity_35_bad_robots.data modsecurity_crs_21_protocol_anomalies.conf modsecurity_crs_47_common_exceptions.conf

modsecurity_35_scanners.data modsecurity_crs_23_request_limits.conf modsecurity_crs_47_skip_outbound_checks.conf

modsecurity_40_generic_attacks.data modsecurity_crs_25_cc_known.conf modsecurity_crs_48_local_exceptions.conf.example

modsecurity_42_comment_spam.data modsecurity_crs_30_http_policy.conf modsecurity_crs_49_header_tagging.conf

modsecurity_50_outbound.data modsecurity_crs_35_bad_robots.conf modsecurity_crs_49_inbound_blocking.conf

modsecurity_50_outbound_malware.data modsecurity_crs_40_generic_attacks.conf modsecurity_crs_50_outbound.conf

modsecurity_crs_10_ignore_static.conf modsecurity_crs_41_sql_injection_attacks.conf modsecurity_crs_55_application_defects.conf

modsecurity_crs_11_avs_traffic.conf modsecurity_crs_41_xss_attacks.conf modsecurity_crs_55_marketing.conf

modsecurity_crs_13_xml_enabler.conf modsecurity_crs_42_comment_spam.conf modsecurity_crs_59_outbound_blocking.conf

modsecurity_crs_16_authentication_tracking.conf modsecurity_crs_42_tight_security.conf modsecurity_crs_60_correlation.conf

modsecurity_crs_16_session_hijacking.conf modsecurity_crs_43_csrf_protection.conf

modsecurity_crs_16_username_tracking.conf modsecurity_crs_45_trojans.conf

modsecurity_crs_20_protocol_violations.conf modsecurity_crs_46_av_scanning.conf

No basta con activarlas en modsecurity, ya que lo que tenemos que hacer es que el módulo modsecurity de apache las tenga en cuenta. Para ello haremos lo siguiente:

vim /etc/apache2/mods-available/security2.conf

y añadiremos la siguiente linea antes del

IfModule del final de linea

Include "/etc/modsecurity/activated_rules/*.conf"

Ya estamos en disposición de activar el módulo en nuestro servidor Apache:

sudo a2enmod security2

Considering dependency unique_id for security2:

Module unique_id already enabled

Module security2 already enabled

También tenemos que habilitar el módulo mod_headers para evitar este error que nos sale al reiniciar el Apache:

Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration

Así que lo activamos:

sudo a2enmod headers

Enabling module headers.

To activate the new configuration, you need to run:

service apache2 restart

Y ya lo tenemos todo instalado y configurado. Ahora reiniciamos Apache:

service apache2 restart

Y... ¿nos creemos que funciona y ya está?. No.. ¡vamos a probarlo!

Abre tu navegador y pon en la dirección http://nombredelhost/?id=23' or '1'='1 (Si es nuestro pc local podemos poner http://localhost/?id=23' or '1'='1 ) . Es importante darle un nombre al servidor que se resuelva, ya que sino puede detectar el sistema un problema con severidad "WARNING".

Una vez puesta esa dirección, el servidor nos devolverá un MSG 403 de error, pero además en el archivo /var/log/apache2/modsec_audit.log podremos apreciar que nos sale entre otras cosas:

msg "SQL Injection Attack: SQL Tautology Detected."

¡Ataque detectado! Ya tenemos a nuestro cortafuegos de aplicaciones web trabajando.

mod-evasive

Para instalarlo nos apoyaremos en el repositorio oficial de Ubuntu:

apt-get install libapache2-mod-evasive

Una vez instalado el paquete, el modulo ya estará activado.

El archivo de configuración del módulo es bien sencillo:

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

DOSEmailNotify mail@mimail.edu
#DOSSystemCommand "su - someuser -c '/sbin/... %s ...'"
DOSLogDir "/var/log/apache2/mod_evasive"

Como veis no hay mucho que configurar. Hay una explicación muy buena y extensa en www.tail-f.com.ar que transcribo tal cual:

DOSHashTableSize – Establece el número de nodos a almacenar para cada proceso de peticiones de la tabla hash (contenedor asociativo de recuperación de peticiones por medio de claves que agiliza las respuestas del servidor). Si aplicamos un número alto a este parámetro obtendremos un rendimiento mayor, ya que las iteraciones necesarias para obtener un registro de la tabla son menores. Por contra, y de forma evidente, aumenta el consumo de memoria necesario para el almacenamiento de una tabla mayor. Se hace necesario incrementar este parámetro si el servidor atiende un número abultado de peticiones, aunque puede no servir de nada si la memoria de la máquina es escasa.
DOSPageCount – Indica el valor del umbral para el número de peticiones de una misma página (o URI) dentro del intervalo definido en DOSPageInterval. Cuando el valor del parámetro es excedido, la IP del cliente se añade a la lista de bloqueos.
DOSSiteCount – Cuenta cuántas peticiones de cualquier tipo puede hacer un cliente dentro del intervalo definido en DOSSiteInterval. Si se excede dicho valor, el cliente queda añadido a la lista de bloqueos.
DOSPageInterval – El intervalo, en segundos, para el umbral de petición de páginas.
DOSSiteInterval – El intervalo, en segundos, para el umbral de petición de objetos de cualquier tipo.
DOSBlockingPeriod – Establece el tiempo, en segundos, que un cliente queda bloqueado una vez que ha sido añadido a la lista de bloqueos. Como ya se indicó unas líneas atrás, todo cliente bloqueado recibirá una respuesta del tipo 403 (Forbidden) a cualquier petición que realice durante este periodo.
DOSEmailNotify – Un e-mail será enviado a la dirección especificada cuando una dirección IP quede bloqueada. La configuración del proceso de envío se establece en el fichero mod_evasive.c de la forma /bin/mail -t %s, siendo %s el parámetro que queda configurado en este parámetro. Será necesario cambiar el proceso si usamos un método diferente de envío de e-mails y volver a compilar el módulo con apxs (por ejemplo, la opción t ha quedado obsoleta en las últimas versiones del comando).
DOSSystemCommand
– El comando reflejado se ejecutará cuando una dirección IP quede bloqueada. Se hace muy útil en llamadas a herramientas de filtrado o firewalls. Usaremos %s para especificar la dirección IP implicada. Por ejemplo, podemos establecer su uso con iptables de la forma siguiente:
```
DOSSystemCommand “/sbin/iptables –I INPUT –p tcp –-dport 80 –s %s –j DROP”
```
DOSLogDir – Establece una ruta para el directorio temporal. Por defecto, dicha ruta queda establecida en /tmp, lo cual puede originar algunos agujeros de seguridad si el sistema resulta violado.
DOSWhitelist
– La dirección IP indicada como valor del parámetro no será tenida en cuenta por el módulo en ningún caso. Para cada dirección IP a excluir ha de añadirse una nueva línea con el parámetro. Por ejemplo, dejaremos fuera del chequeo del módulo a un posible bot que use los siguientes rangos de direcciones:
```
DOSWhitelist 66.249.65.*
DOSWhitelist 66.249.66.*
```

Es quizás la opcion DOSSystemCommand la que nos da mucho juego ya que una vez detectado el ataque... ¿Que hacemos? Pues podemos crearnos un script y hacer lo que queramos. En el ejemplo de arriba te pone una posibilidad, que es añadir la ip en el iptables:

DOSSystemCommand “/sbin/iptables –I INPUT –p tcp –dport 80 –s %s –j DROP”

Si queremos hacer algo más complejo, pues nos hacemos un script que antes nos mande un mail, etc..

Hay que tener en cuenta crear la carpeta para los logs en /var/log/mod_evasive y darle permisos al usuario:grupo www-data (chown -R www-data:www-data /var/log/mod_evasive)

Ahora nos quedaría probarlo, para quedarnos tranquilos de que funciona. Para ello el mod-evasive viene con un script que nos hace la prueba:

perl /usr/share/doc/libapache2-mod-evasive/examples/test.pl

/var/log/apache2# perl /usr/share/doc/libapache2-mod-evasive/examples/test.pl
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
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
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
(...)

Podemos observar que hay tantos 200 0K como hemos configurado en la directiva DOSBlockingPeriod 10

Al /var/log/syslog podemos ver:
mod_evasive[28508]: Blacklisting address 127.0.0.1: possible DoS attack.