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.
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 * ;
do
sudo ln -s /etc/modsecurity/base_rules/$f /etc/modsecurity/activated_rules/$f ;
done
cd /etc/modsecurity/optional_rules
for f in * ;
do
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
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
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"
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:
Si queremos hacer algo más complejo, pues nos hacemos un script que antes nos mande un mail, etc..
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:
