ModSecurity en Apache: Guía WAF paso a paso

📅 Publicado el 27 de septiembre, 2026 · Por Equipo RedServicio

ModSecurity en Apache es la solución de WAF (Web Application Firewall) más popular del mundo open source, y en esta guía aprenderás a instalarlo y configurarlo paso a paso para proteger tu servidor web contra ataques comunes como inyecciones SQL, XSS y exploits de aplicaciones. Si gestionas tu propia web, añadir esta capa de seguridad es una de las inversiones más rentables que puedes hacer, y al final del artículo verás que contar con un hosting de calidad con soporte 24/7 como RedServicio facilita enormemente esta tarea.

¿Qué es un WAF y por qué necesitas ModSecurity?

Un WAF (Web Application Firewall) es un firewall que opera a nivel de aplicación web, analizando el tráfico HTTP/HTTPS que llega a tu servidor antes de que las peticiones alcancen tus aplicaciones PHP, WordPress u otros CMS. A diferencia de un firewall tradicional, que filtra por puertos e IPs, el WAF inspecciona el contenido de las peticiones: parámetros GET y POST, cabeceras, cookies y cuerpos de solicitud.

ModSecurity actúa como un módulo de Apache (o Nginx) que intercepta cada petición y la evalúa contra un conjunto de reglas. Con el paquete de reglas OWASP Core Rule Set (CRS) —el más utilizado— obtienes protección inmediata contra:

• Inyección SQL (SQLi) y ataques a bases de datos.
• Cross-Site Scripting (XSS).
• Local File Inclusion (LFI) y Remote File Inclusion (RFI).
• Escaneo de vulnerabilidades y bots maliciosos.
• Ataques a plugins y temas vulnerables de WordPress, Joomla o Drupal.

El beneficio clave es que protege tus aplicaciones aunque estas tengan vulnerabilidades sin parchear, dándote tiempo para actualizar mientras el WAF bloquea los intentos de explotación. En servidores con múltiples sitios alojados, es una red de seguridad común para todos.

Requisitos previos para instalar ModSecurity en Apache

Antes de comenzar, asegúrate de cumplir estos requisitos:

1. Servidor Linux con Apache 2.4 o superior y acceso root o sudo (Ubuntu 20.04/22.04/24.04, Debian 11/12, CentOS/RHEL 8/9 o AlmaLinux).
2. Acceso SSH al servidor y permisos para reiniciar el servicio Apache.
3. Conexiones TLS activas (recomendado): si el tráfico viaja cifrado, necesitas SSLtermination en Apache o ModSecurity no podrá inspeccionar el contenido.
4. Copia de seguridad de la configuración de Apache: siempre guarda /etc/apache2/ o /etc/httpd/ antes de tocar nada.
5. Modo mantenimiento planificado: aunque la instalación no provoca caídas, un reinicio breve de Apache es necesario.

Instalación de ModSecurity paso a paso (Ubuntu/Debian y CentOS)

En Ubuntu/Debian

Primero, actualiza los repositorios e instala el módulo:

1. Ejecuta sudo apt update && sudo apt upgrade -y.
2. Instala ModSecurity con sudo apt install libapache2-mod-security2 -y.
3. Activa el módulo en Apache: sudo a2enmod security2.
4. Reinicia el servicio: sudo systemctl restart apache2.

En CentOS/RHEL/AlmaLinux

En sistemas basados en Red Hat, el proceso varía según la versión:

1. En CentOS 7 instala desde EPEL: sudo yum install epel-release && sudo yum install mod_security mod_security_crs -y.
2. En AlmaLinux/RHEL 8/9 usa el módulo AppStream: sudo dnf install mod_security mod_security_crs -y.
3. Habilita e inicia Apache: sudo systemctl enable httpd && sudo systemctl restart httpd.

Para verificar que el módulo está cargado, ejecuta apachectl -M | grep security2 (Debian) o httpd -M | grep security2 (CentOS). Si aparece security2_module (shared), ModSecurity está activo, aunque todavía en modo detección. En la siguiente parte de esta guía configuraremos el OWASP Core Rule Set y cambiaremos del modo detección al modo bloqueo de forma segura.

Configurar el conjunto de reglas OWASP Core Rule Set

Aquí está el verdadero motor del asunto. El OWASP Core Rule Set (CRS) es un paquete de reglas mantenido por la comunidad que cubre las vulnerabilidades web más habituales: inyecciones SQL, XSS, inclusiones de archivos y bastante más. ModSecurity sin CRS tiene poco que hacer; te quedarías solo con las reglas que escribas a mano, y no, no es suficiente en la práctica.

Instalarlo es sencillo. Clonas el repositorio oficial en el directorio de tu servidor:

1. Entra por SSH y sitúate en /etc/modsecurity (Debian/Ubuntu) o /etc/httpd/modsecurity.d (CentOS).
2. Ejecuta: git clone https://github.com/coreruleset/coraza… un momento, ese no es. El repositorio correcto es git clone https://github.com/coreruleset/coreruleset.git crs.
3. Copia el archivo de configuración de ejemplo: cp crs/crs-setup.conf.example crs/crs-setup.conf.
4. Incluye el CRS en la configuración principal de ModSecurity, normalmente en modsecurity.conf o mediante un include dentro del VirtualHost:

IncludeOptional /etc/modsecurity/crs/crs-setup.conf
IncludeOptional /etc/modsecurity/crs/rules/*.conf

Reinicia Apache con systemctl restart apache2 o systemctl restart httpd y echa un vistazo al log de errores: no deberían aparecer fallos al cargar las reglas. Y si trabajas con cPanel o Plesk, revisa primero si el panel trae su propia integración del CRS. Duplicados, los que quieras; ahí empiezan los dolores de cabeza.

Ajustar reglas, evitar falsos positivos y pasar a modo de bloqueo

¿El error más común al activar un WAF? Pasar directo a modo bloqueo sin ajustar nada antes. Y es un error caro, porque el CRS es estricto por defecto: un formulario de contacto con acentos, un editor visual que envía HTML o una URL con parámetros largos bastan para disparar alertas sin que haya ataque alguno detrás.

El proceso que funciona es otro:

1. Déjalo en modo detección (DetectionOnly) al menos una o dos semanas, con tráfico real de tu web. Sí, semanas. Merece la pena.
2. Analiza el log de auditoría en /var/log/apache2/modsec_audit.log o /var/log/httpd/modsec_audit.log. Busca los IDs de reglas que se activan con tráfico legítimo.
3. Excluye esas reglas de forma quirúrgica. Por ejemplo, para desactivar la regla 942100 solo en el campo de búsqueda:

SecRule REQUEST_URI «@beginsWith /buscar» «id:1000001,phase:1,pass,nolog,ctl:ruleRemoveTargetById=942100;ARGS:q»

Lo que nunca deberías hacer es desactivar reglas completas de forma global. Excluye en lo posible una URL concreta y un parámetro concreto, nada más amplio. Cuando los logs muestren que los falsos positivos son mínimos, ya puedes pasar a bloqueo editando modsecurity.conf:

SecRuleEngine On

Reinicia Apache y lanza una carga útil típica, algo como ?id=1 OR 1=1, contra tu web. Si recibes un 403, tienes un WAF bloqueando de verdad.

Conclusión: protege tu servidor con un WAF bien configurado

ModSecurity en Apache es probablemente la defensa más eficaz que puedes añadir a tu infraestructura sin gastar más: filtra ataques antes de que toquen tu aplicación, deja registro de los intentos de intrusión y te da el control sobre qué se bloquea y qué no. La clave, insisto, es la paciencia. Primero detección. Luego ajuste de falsos positivos. Y solo al final, el modo bloqueo.

Ojo, eso sí: un WAF no sustituye al resto de medidas. Mantén Apache, PHP y tus aplicaciones al día, haz copias de seguridad con regularidad y vigila los logs más de lo que te gustaría. Si prefieres no complicarte y delegar la seguridad del servidor, en RedServicio ofrecemos hosting con ModSecurity preconfigurado, actualizaciones gestionadas y soporte técnico 24/7 para cualquier ajuste que necesites. Un servidor bien protegido no es un gasto: es la base sobre la que crece tu proyecto.