martes, 16 de mayo de 2017

COMO PROTEGERSE DE ATAQUES WEB con modsecurity WAF

 

Descripción:

"ModSecurity es una herramienta que te ayudará a dormir mejor por la noche, y voy a explicar cómo. Normalmente llamo a ModSecurity un firewall de aplicaciones web (WAF), porque eso es lo general. Otras veces herramienta de detección de intrusiones HTTP, porque creo que describe mejor lo que hace ModSecurity. Ninguno de los dos nombres es totalmente adecuado, el caso es que las aplicaciones web, la tuya, la mía, la de todos son terriblemente inseguras en promedio. Hay que luchar para mantenerse al día con los problemas de seguridad y necesitamos cualquier ayuda que podamos obtener para protegernos." 
Extracto del libro: https://www.amazon.com/ModSecurity-Handbook-Complete-Application-Firewall/dp/1907117024

Tutorial:

Empezamos instalando modsecurity, lo haremos con el simple comando:
# apt-get install libapache2-modsecurity

Compronamos que está instalado correctamente:
# apachectl -M | grep --color security


Configuración:

El archivo de configuración predeterminado se establece en DetectionOnly que registra las solicitudes de acuerdo con las coincidencias de reglas y no bloquea nada, asíque vamos a editarlo:
  
$ nano /etc/modsecurity/modsecurity.conf
*También puede ser /etc/modsecuritymodsecurity.conf-recommended así que renombrarlo:
$ mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Buscamos la lína "SecRuleEngine DetectionOnly" y la cambiamos por:
SecRuleEngine On


Otra directiva a modificar es "SecResponseBodyAccess". Esto configura si los cuerpos de respuesta están almacenados en búfer (es decir, leídos por modsecurity). Esto sólo es necesario si se requiere detección y protección de fugas de datos. Por lo tanto, dejarlo activado utilizará los recursos de droplet y también aumentará el tamaño del archivo de registro.

Buscamos la línea "SecResponseBodyAccess On" y la cambiamos por:
SecResponseBodyAccess Off



Ahora limitaremos los datos máximos que se pueden publicar en la aplicación web. Dos directivas las configuran:

SecRequestBody
LimitSecRequestBody
NoFilesLimit 

La directiva SecRequestBodyLimit especifica el tamaño máximo de datos POST. Si algo más grande es enviado por un cliente, el servidor responderá con un error 413 Request Entity Too Large. Si tu aplicación web no tiene ninguna subida de archivos, este valor puede reducirse considerablemente. El valor mencionado en el archivo de configuración es:

SecRequestBodyLimit 13107200
Que es 12.5MB. 

Similar a esto es la directiva SecRequestBodyNoFilesLimit. La única diferencia es que esta directiva limita el tamaño de los datos POST menos subidas de archivos. Este valor debe ser "tan bajo como sea práctico". El valor en el archivo de configuración es:

SecRequestBodyNoFilesLimit 131072
Que es 128KB.

A lo largo de las líneas de estas directivas es otro que afecta el rendimiento del servidor: SecRequestBodyInMemoryLimit. Esta directiva es bastante evidente por sí misma; Especifica cuánto de los datos del "cuerpo de la petición" (datos POSTed) debe mantenerse en la memoria (RAM), cualquier cosa más se colocará en el disco duro (al igual que el intercambio). Se puede establecer un valor decente si tienes memoria RAM de sobra. 

SecRequestBodyInMemoryLimit 131072
Este es el valor (128KB) especificado en el archivo de configuración.  


Reglas:

Para hacer la vida más fácil, hay un montón de reglas que ya están instaladas junto con mod_security. Estos se llaman CRS (Core Rule Set) y se encuentran en:  /usr/share/modsecurity-crs/

La documentación está disponible en: /usr/share/doc/modsecurity-crs/ 

Para cargar estas reglas, necesitamos decirle a Apache que examine estos directorios.

$ sudo nano /etc/apache2/mods-enabled/modsecurity.conf
*El archivo estará vacío

Agrega las siguientes directivas dentro de <IfModule security2_module> </ IfModule>:
Include "/usr/share/modsecurity-crs/*.conf"
Include "/usr/share/modsecurity-crs/activated_rules/*.conf"


 

El directorio activated_rules es similar al directorio habilitado para mods de Apache. Las reglas están disponibles en directorios:
/usr/share/modsecurity-crs/base_rules
/usr/share/modsecurity-crs/optional_rules
/usr/share/modsecurity-crs/experimental_rules


Los enlaces simbólicos deben crearse dentro del directorio activated_rules para activarlos. Activemos las reglas de inyección de SQL:

$ cd /usr/share/modsecurity-crs/activated_rules/
$ sudo ln -s /usr/share/modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf . 
 
 
 
 

$ sudo service apache2 reload
$ sudo service apache2 restart

Podremos encontrar los logs en: /var/log/apache2/modsec_audit.log

PoC:

Una vez instalado todo vamos a probar un ataque de inyección SQL.
Nos vamos al log y lo abrimos con tailf, una vez hecho esto nos dirigimos a DVWA (admin:password), vamos al apartado SQL Injection, escribimos una ' y vemos como nos dará prohibido el acceso y nos saldrá un mensaje en el log.



Este artículo ha sido "una primera toma de contacto con modsecurity", ya que ofrece muchas posiblidades y aquí solo se ha visto un ejemplo básico, si quieres profundizar más sobre este campo te recomiendo leer el libro que puse al principio de la entrada.

Previous Post
Next Post

post written by:

0 comentarios: