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:

You dont have permission to access /wp-admin/post.php on this server.

Ni podía publicar comentarios:

You don't have permission to access /wp-comments-post.php on this server.

¿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:

<IfModule mod_security.c>
    SecFilterEngine Off
    SecFilterScanPOST Off
</IfModule>

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í:

<IfModule security2_module>
	Include /etc/modsecurity/owasp-crs/modsecurity_crs_10_config.conf
	Include /etc/modsecurity/owasp-crs/base_rules/*.conf
</IfModule>

Originalmente el directorio base_rules OWASP viene con todo esto:

modsecurity_35_bad_robots.data
modsecurity_35_scanners.data
modsecurity_40_generic_attacks.data
modsecurity_50_outbound.data
modsecurity_50_outbound_malware.data
modsecurity_crs_20_protocol_violations.conf
modsecurity_crs_21_protocol_anomalies.conf
modsecurity_crs_23_request_limits.conf
modsecurity_crs_30_http_policy.conf
modsecurity_crs_35_bad_robots.conf
modsecurity_crs_40_generic_attacks.conf
modsecurity_crs_41_sql_injection_attacks.conf
modsecurity_crs_41_xss_attacks.conf
modsecurity_crs_42_tight_security.conf
modsecurity_crs_45_trojans.conf
modsecurity_crs_47_common_exceptions.conf
modsecurity_crs_48_local_exceptions.conf.example
modsecurity_crs_49_inbound_blocking.conf
modsecurity_crs_50_outbound.conf
modsecurity_crs_59_outbound_blocking.conf
modsecurity_crs_60_correlation.conf

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:

<IfModule security2_module>
	Include /etc/modsecurity/owasp-crs/modsecurity_crs_10_config.conf
	Include /etc/modsecurity/owasp-crs/base_rules_wp_front/*.conf
</IfModule>

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:

mkdir base_rules_wp_front

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

root@myhostname:/etc/modsecurity/owasp-crs/base_rules# cp *.data ../base_rules_wp_front

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:

cp modsecurity_crs_20_protocol_violations.conf ../base_rules_wp_front

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

service apache2 restart

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í:

modsecurity_35_bad_robots.data
modsecurity_35_scanners.data
modsecurity_40_generic_attacks.data
modsecurity_50_outbound.data
modsecurity_50_outbound_malware.data
modsecurity_crs_23_request_limits.conf
modsecurity_crs_30_http_policy.conf
modsecurity_crs_35_bad_robots.conf
modsecurity_crs_42_tight_security.conf
modsecurity_crs_45_trojans.conf
modsecurity_crs_47_common_exceptions.conf
modsecurity_crs_49_inbound_blocking.conf
modsecurity_crs_59_outbound_blocking.conf
modsecurity_crs_60_correlation.conf

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

modsecurity_crs_20_protocol_violations.conf
modsecurity_crs_21_protocol_anomalies.conf
modsecurity_crs_40_generic_attacks.conf
modsecurity_crs_41_sql_injection_attacks.conf
modsecurity_crs_41_xss_attacks.conf
modsecurity_crs_50_outbound.conf

Con modsecurity_crs_41_sql_injection_attacks.conf cargado, mi WordPress lanzaba errores

403 Forbidden You don't have permission to access

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í:

modsecurity_35_bad_robots.data
modsecurity_35_scanners.data
modsecurity_40_generic_attacks.data
modsecurity_50_outbound.data
modsecurity_50_outbound_malware.data
modsecurity_crs_21_protocol_anomalies.conf
modsecurity_crs_23_request_limits.conf
modsecurity_crs_30_http_policy.conf
modsecurity_crs_35_bad_robots.conf
modsecurity_crs_42_tight_security.conf
modsecurity_crs_45_trojans.conf
modsecurity_crs_47_common_exceptions.conf
modsecurity_crs_49_inbound_blocking.conf
modsecurity_crs_59_outbound_blocking.conf
modsecurity_crs_60_correlation.conf

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

modsecurity_crs_20_protocol_violations.conf
modsecurity_crs_40_generic_attacks.conf
modsecurity_crs_41_sql_injection_attacks.conf
modsecurity_crs_41_xss_attacks.conf
modsecurity_crs_50_outbound.conf

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 compartirla con tus amig@s.