#mod_security

If mod security is blocking Google’s crawler for your website you need to add this on top of your rules:

SecRule REQUEST_HEADERS:User-Agent “compatible; Googlebot” “nolog,allow”

Mod_security can prevent edits  and you will get the error code that is configured within mod_security(while posting data).

Here is a useful way to have mod_security ignore your home / office IP and yet stay active for all other IP addresses:

SecRule REMOTE_ADDR “^127\.0\.0\.1$” phase:1,nolog,allow,ctl:ruleEngine=Off

1. Mod_security comes bundled with the nicely branded, free OWASP CRS. Thing is - it’s stale since 2013... and is pure hell of false positives.

2. The official commercial alternative is Trustware SpiderWeb WAF, which seems to receive updates daily (no list, nor trial) at a hefty 500$/y.

3. You google further, you find the Atomicorp Gotroot ModSecurity Rules. They claim superior history and performance (”works right out of the box without any tuning and without interference”). Again, no trial or update feed, and at 200$/y.

4. And then, hidden from sight, is the Comodo WAF, which is receiving updates (every month or biweekly, at least) - and is free (registration necessary). The set seems balanced and shows a decent detection rate so far for me.

Comodo seems to use emergingthreats (now by proofpoint.com) as an internal source. ET is a great source of free and premium snort/fw rules, but does not offer converted mod_security signatures.

Snort

Snort itself (by VRT, now Talos), has an extensive web-app section in it’s free registered set, but again, it’s not easy to convert to mod_security.

Snort can work in place of mod_security, but has a major drawback - it can not see inside HTTPS traffic - which mod_security can.

Error con mod_security + mod_ruid2: "ModSecurity: Audit log: Failed to unlock global mutex: Permission denied" #servidor #VPS

Hace mucho tiempo que no hablamos de servidores, sus tecnologías… y sus problemas. Cuando tienes alojado un blog o página web en un servidor VPS puedes encontrarte muchos retos debido a la gran cantidad de tecnologías que están presentes para que una web funcione. Por nombrar algunos de los más comunes: Linux, WHM/cPanel, Apache, PHP, MySQL, módulos de seguridad como Mod_security o Mod_ruid2 etc…

Blocking referrer spam with mod_security

Spam comes in may forms.

I had been noticing some odd traffic appearing in my referrer logs from “buttons-for-website.com”, and a few other places. Odd, I thought, but I wasn’t too concerned.

A client recently asked me about it, since similar traffic was starting to appear in their analytics for a brand new site. I did a little bit of research, and it turns out that this is actually a spam attack.

http://www.modsecurity.org/documentation/ModSecurity_Core_Rules.pdf

http://adminuser.wordpress.com/2008/06/08/mod-security-2-default-rules-and-ids/

https://github.com/SpiderLabs/ModSecurity/wiki/ModSecurity-Frequently-Asked-Questions-%28FAQ%29

http://www.linuxforu.com/2011/08/securing-apache-part-10-mod_security/

Imagina que te levantas un día notas que algo falla, tu servidor va lento y al ver el log de Apache descubres que estás sufriendo un ataque desde direcciones IP falsas. Para solucionarlo vamos a implementar una serie de modificaciones para evitar la saturación del servidor y daños mayores.

Imagina que como siempre, vas como el culo de tiempo, así que estos cambios están ordenados por prioridad/importancia, para conseguir el mayor beneficio en el menor tiempo posible.

Instalación de Mod_Security

Empezaremos instalando mod_security, funciona como un proxy de aplicación filtrando parte de los ataques y permitiendo una mayor configuración. No suele dar problemas con las aplicaciones conocidas y no penaliza el sistema. Lo instalamos y habilitamos mediante:

sudo apt-get install libapache_mod_security sudo a2enmod mod_security sudo /etc/init.d/apache2 force-reload 

Ahora el módulo debería estar disponible, también existe un archivo de configuración para el mismo en /etc/apache2/conf.d/security

Hago una copia del fichero primero:

cp /etc/apache2/conf.d/security /etc/apache2/conf.d/security.backup

luego edito security para cambiar la información que muestra el servidor, busca ServerTokens para que muestre la menor información posible y el apache no se identifique:

ServerTokens Prod

ServerSignature Off

Asegurate que no existan variables que se repitan o contradigan, luego vuelve a forzar la recarga, y vamos al siguiente cambio.

Conexiones al Apache

Un ataque DDoS genera un gran volumen de conexiones simultáneas, vamos a reducir nuestra "pista de aterriza" para tener menos tráfico:

MaxClients: el número de tiempo de conexiones simultáneas, baja de 150 a 50.

KeepAliveTimeout: Tiempo máximo entre peticiones de un mismo cliente y conexión, baja de 15 a 10.

Timeout: Tiempo hasta generar un timeout, baja de 300 a 60.

Deshabilitar módulos que no se utilicen

Mantener módulos activos de forma innecesaria aumenta los puntos por los que nos pueden atacar, así que desactivamos los siguientes con a2dismod NOM_MODULO

mod_status