ModSecurity: cómo funciona el WAF que protege tu web a nivel de servidor
La diferencia entre un plugin de seguridad de WordPress y ModSecurity está en dónde se ejecuta cada uno. Un plugin de seguridad corre dentro de PHP, lo que significa que el ataque ya ha llegado a tu aplicación cuando el plugin lo evalúa. ModSecurity actúa antes: analiza la petición HTTP en el servidor web y la descarta si coincide con un patrón de ataque conocido, sin que PHP llegue a ejecutarse.
Qué es ModSecurity y dónde vive en la pila del servidor
ModSecurity es un módulo de Apache (también disponible para Nginx como ModSecurity-nginx y para IIS) que implementa un Web Application Firewall (WAF) en la capa del servidor web. Se integra como un módulo que intercepta el ciclo de vida de cada petición HTTP en varios puntos: tras recibir los headers, tras recibir el body, antes de enviar la respuesta y tras enviarla.
En cada uno de esos puntos puede ejecutar reglas que analizan el contenido de la petición o la respuesta. Las reglas pueden rechazar la petición (devolviendo un 403), registrar la petición sin bloquearla, modificar la petición antes de pasarla a la aplicación o modificar la respuesta antes de enviarla al cliente.
El ruleset OWASP Core Rule Set
ModSecurity sin reglas no hace nada. Las reglas son lo que define qué patrones se consideran ataques. El conjunto de reglas más usado y mantenido es el OWASP Core Rule Set (CRS), un proyecto open source de la Open Web Application Security Project Foundation.
El CRS cubre las principales categorías de ataques web: SQL injection (SQLi), Cross-Site Scripting (XSS), Local File Inclusion (LFI), Remote File Inclusion (RFI), Remote Code Execution (RCE), HTTP protocol enforcement, y detección de bots y scanners automatizados. Las reglas del CRS tienen un sistema de puntuación: cada regla que coincide suma puntos al score de anomalía de la petición, y si el score supera un umbral configurable, la petición se bloquea.
Este sistema de puntuación es clave para reducir falsos positivos. Una petición que coincide con una regla de baja confianza no se bloquea automáticamente, sino que necesita acumular más señales antes de considerarse un ataque. En ISPACTIVO tenemos el CRS configurado con un umbral de anomalía calibrado para entornos WordPress, donde algunas peticiones legítimas del editor de bloques generan patrones que reglas genéricas podrían bloquear incorrectamente.
SQLi: cómo ModSecurity bloquea inyecciones de SQL
Una inyección SQL es un ataque donde el atacante introduce fragmentos de SQL en parámetros que luego se usan en consultas a la base de datos. Por ejemplo, un campo de búsqueda que recibe ' OR 1=1 -- puede manipular la consulta resultante para devolver todos los registros de la base de datos.
ModSecurity analiza todos los parámetros de la petición (GET, POST, cookies, headers) buscando patrones de SQL. Las reglas del CRS identifican palabras reservadas SQL (UNION, SELECT, INSERT, DROP), operadores lógicos fuera de contexto (OR 1=1), comentarios SQL (--, /**/) y codificaciones alternativas de estos patrones (URL encoding, HTML encoding, unicode escapes).
XSS: protección contra scripts maliciosos
Los ataques XSS (Cross-Site Scripting) inyectan código JavaScript en páginas que luego se sirven a otros usuarios. Pueden robar cookies de sesión, redirigir usuarios a sitios maliciosos o modificar el contenido de la página en el navegador del visitante.
ModSecurity detecta intentos de inyección de scripts buscando etiquetas HTML activas en contextos donde no deberían aparecer, atributos de eventos JavaScript (onclick, onload, onerror), y URIs de javascript:. También detecta intentos de evasión mediante codificación alternativa de caracteres.
Por qué ModSecurity complementa a Wordfence pero no lo sustituye
Wordfence y plugins similares conocen WordPress por dentro. Pueden detectar cambios en archivos del núcleo, accesos a funciones PHP específicas de WordPress, patrones de ataque en el contexto de WordPress (intentos de login, explotación de APIs de plugins concretos). ModSecurity no sabe que hay un WordPress detrás, solo ve peticiones HTTP.
La combinación ideal es ModSecurity bloqueando ataques genéricos en la capa del servidor (donde el coste de proceso es mínimo y el bloqueo es antes de que PHP arranque) y Wordfence o similar añadiendo conciencia de contexto de WordPress. En nuestro hosting web incluimos ModSecurity con el OWASP CRS activo por defecto en todos los planes, sin coste adicional.
Modo de detección vs. modo de bloqueo
ModSecurity puede funcionar en dos modos principales. En modo de detección (DetectionOnly) registra todas las coincidencias con reglas pero no bloquea ninguna petición. Es útil para auditar qué reglas se activarían en un sitio existente antes de activar el bloqueo, para identificar falsos positivos sin afectar el tráfico legítimo.
En modo de bloqueo (On), las peticiones que superan el umbral de anomalía reciben un 403. En ISPACTIVO usamos modo de bloqueo con un umbral configurado para minimizar los falsos positivos en instalaciones WordPress estándar, y ofrecemos ajuste de reglas específicas bajo petición cuando algún plugin legítimo genera conflictos con el WAF.
