WordPress y mod_security arreglan sus diferencias

Tras instalar todas las base_rules OWASP, mod_security me daba problemas con WordPress, lanzando errores aleatorios 403 Forbidden You don't have permission to access, entre otros errores Apache.

Tampoco podía gestionar mi panel de administración WordPress:

Ni podía publicar comentarios:

¿Son incompatibles WordPress y mod_security de Apache?

WordPress y mod_security no se comprenden muy bien el uno al otro.

Incompatibilidad

¿Cómo se arregla esta incompatibilidad en un hosting compartido?

Algunos webmasters incluyen esto en su archivo .htaccess:

Esta solución es rápida, sencilla, pero un poco radical, por así decir, que puedes aplicar en el peor de los casos.

¿Cómo arreglo la incompatibilidad en un servidor dedicado?

En mi caso, el problema viene porque he incluido todas las base_rules OWASP así:

Originalmente el directorio base_rules OWASP viene con todo esto:

De modo que he procedido a identificar qué archivos causaban los problemas. La idea es crear una nueva ruta de reglas base /etc/modsecurity/owasp-crs/base_rules_wp_front/ y ahí poner las reglas que no provoquen ningún problema:

Esta solución requiere que nos armemos de paciencia y vayamos comprobando uno a uno qué archivo lanza errores Apache, pero sin embargo es una solución segura porque en ningún momento modificamos ninguna de las base_rules OWASP originales.

Así pues he creado este directorio:

Y ahí he comenzado a copiar todos los archivos .data:

base_rules OWASP de la parte frontal de WordPress

Luego en /etc/modsecurity/owasp-crs/base_rules_wp_front he ido añadiendo los archivos .conf, uno a uno:

A medida que añadía archivos, justo después reiniciaba Apache:

Y a continuación probaba los casos de uso que daban problemas:

  • Navegar como si fuerea un usuario por la web
  • Hacer comentarios
  • Entrar al panel de administración

Así hasta identificar los .conf que lanzaban los errores.

Para que mi frontend WP no lance ningún error Apache mi directorio /etc/modsecurity/owasp-crs/base_rules_wp_front queda así:

La lista negra de base_rules OWASP que no cargo es esta:

Con modsecurity_crs_41_sql_injection_attacks.conf cargado, mi WordPress lanzaba errores 403 Forbidden You don't have permission to access aleatorios, y ya no he podido hacer comentarios, ni tampoco he podido acceder al panel de administración.

Con modsecurity_crs_50_outbound.conf, lanzaba errores de tipo Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

base_rules OWASP del panel de administración de WordPress

Para que mi panel funcione bien sin lanzar ningún error Apache, mi directorio /etc/modsecurity/owasp-crs/base_rules_wp_back queda así:

La lista negra de base_rules OWASP que no cargo es esta:

Razonamiento inductivo

¿Sabías que el razonamiento inductivo o lógica inductiva estudia las pruebas que permiten medir la probabilidad de los argumentos?

Lógica inductiva

Nosotr@s hemos solucionado este problema comprobando que las sospechas que al inicio considerábamos probablemente ciertas, efectivamente lo son.

Argumentos probablemente ciertos:

  • No todas las base_rules OWASP son incompatibles con WordPress

Procedimiento:

  • Hemos ido probando 1 a 1 los archivos base_rules OWASP hasta identificar los que causaban problemas

Conclusión:

Hemos comprobado que no todas las base_rules OWASP son incompatibles con WordPress; al contrario, se pueden aprovechar muchas de ellas por medio de este método inductivo, haciendo que nuestro sistema sea más seguro.

¡Esto es todo por hoy! Espero haber sido de ayuda. Si esta entrada te ha gustado te invito a comentarla y a compartirla con tus amig@s.