Si estás leyendo esto es porque acabas de ver un error 403 Forbidden y sospechas que el culpable es ModSecurity. Vas bien encaminado: es la causa más habitual cuando un formulario, un plugin de WordPress o incluso tu propio panel de administración empieza a rechazar peticiones legítimas de golpe.
La solución rápida y mala es desactivar ModSecurity entero. La solución correcta es añadir tu IP (o la del cliente, la de la oficina, la del servicio externo que necesita acceso) a una lista blanca, sin bajar la guardia en el resto del tráfico.
En Avantys llevamos años administrando servidores cPanel y Plesk para agencias y PYMEs, y este es, con diferencia, uno de los tickets de soporte más repetidos: “mi web me bloquea a mí mismo”. En esta guía vas a ver cómo solucionarlo en los dos paneles, con la sintaxis exacta, las diferencias entre bloquear por IP y bloquear por regla, y los errores que hacen que la whitelist “no funcione” aunque la hayas configurado bien.
Si gestionas cPanel o Plesk en un VPS propio y esto te empieza a sonar a demasiada fontanería de servidor, al final del artículo verás la alternativa de dejarlo en manos de alguien que lo haga en 20 minutos y no vuelva a mirarlo.
¿Qué es ModSecurity y por qué bloquea tu IP?
ModSecurity es un firewall de aplicaciones web (WAF) que se ejecuta como módulo de Apache (o vía conector en Nginx/IIS) y analiza cada petición HTTP antes de que llegue a tu aplicación. Compara el contenido (URL, cabeceras, cuerpo del POST) contra un conjunto de reglas (normalmente el OWASP Core Rule Set) y, si algo coincide con un patrón de ataque, corta la petición con un 403.
El problema es que esas reglas trabajan por patrones de texto, no por intención. Un plugin de WordPress que envía HTML dentro de un campo de formulario, una URL con parámetros largos, o un editor de bloques que manda JSON con ciertas palabras puede activar una regla pensada para detectar inyección SQL o XSS. Es un falso positivo, no un ataque real.
Dato concreto: la propia documentación oficial de Plesk advierte de que con el ruleset OWASP CRS activado, WordPress deja de funcionar parcialmente, igual que el webmail o el compartido de archivos, si no se ajustan las reglas, es tan común que el propio fabricante lo documenta como comportamiento esperado, no como bug.
Ejemplo real que vemos a menudo: un desarrollador trabaja desde su IP fija de oficina, sube cambios por wp-admin, y de repente una regla como la 949110 (anomaly score excedido) le bloquea cualquier POST. La web funciona perfectamente para el resto del mundo, solo él está bloqueado. Ahí es donde entra la whitelist por IP.
Cómo confirmar que el 403 lo causa ModSecurity (y no otra cosa)
Antes de tocar nada, confirma el diagnóstico. Un 403 también puede venir de .htaccess, de permisos de archivo o del firewall de red (CSF, iptables). Revisa el log de errores de Apache:
tail -n 50 /usr/local/apache/logs/error_log | grep -i modsecuritySi el bloqueo es de ModSecurity, verás una línea parecida a esta:
[Wed Jul 15 10:22:14.123456 2026] [:error] [pid 24310] [client 203.0.113.45:52341]
ModSecurity: Access denied with code 403 (phase 2).
[id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [hostname "midominio.com"]Los dos datos que necesitas de esa línea son la IP del cliente (203.0.113.45) y el ID de la regla (949110). Con eso ya puedes decidir si vas a permitir esa IP para todas las reglas o solo excluirla de esa regla concreta, que es, siempre que puedas, la opción más segura.
En Plesk puedes llegar al mismo dato desde la interfaz: Tools & Settings > Web Application Firewall (ModSecurity) > log de auditoría, sin necesidad de tocar SSH.
Añadir una IP a la lista blanca en cPanel / WHM
cPanel no trae de fábrica un editor de whitelist por IP en la interfaz de usuario final, el toggle que ve el cliente en “Security > ModSecurity” solo permite encender o apagar el módulo entero por dominio, algo demasiado bruto para un falso positivo puntual. La gestión fina se hace desde WHM.
Opción 1: bypass total de una IP (rápido, pero menos seguro)
Desde WHM: ModSecurity™ Tools > Rules List > Edit Rules, edita el archivo de reglas propias del servidor (modsec2.user.conf) y añade:
<IfModule mod_security2.c>
SecRule REMOTE_ADDR "@ipMatch 203.0.113.45" "id:1000001,phase:1,t:none,nolog,allow"
</IfModule>Esto hace que ninguna regla de ModSecurity se aplique a esa IP, en ningún dominio del servidor. Cómodo, pero es un cheque en blanco: si esa IP se ve comprometida (un ordenador de oficina con malware, por ejemplo), pasa por delante de todo el WAF.
Opción 2: whitelist de una regla concreta (recomendado)
Si solo una regla te está dando problemas (como la 949110 del ejemplo anterior), exclúyela solo para esa IP, dejando el resto del WAF activo:
<IfModule mod_security2.c>
SecRule REMOTE_ADDR "@ipMatch 203.0.113.45" "id:1000002,phase:1,t:none,nolog,pass,ctl:ruleRemoveById=949110"
</IfModule>Si administras varios dominios de distintos usuarios y quieres aplicar la exclusión solo a uno, usar el plugin ConfigServer ModSecurity Control (CMC) (muy habitual en servidores WHM) simplifica el proceso: desde la Hits List localizas el ID de regla y la IP bloqueada, y desde ahí puedes guardar el whitelist a nivel global o solo para el dominio afectado, sin tocar archivos a mano.
Opción 3: alternativa nativa para cuentas sin acceso WHM
Si solo tienes acceso de usuario cPanel (sin root), la única palanca disponible es el toggle On/Off por dominio en Security > ModSecurity. Es una solución de “todo o nada”: desactiva completamente el WAF para ese dominio mientras dure el problema. Es honesto decir que no es una whitelist real, es apagar el detector de humo entero porque una alarma salta con el vapor de la ducha. Sirve para salir del paso mientras alguien con acceso WHM aplica una regla fina.
Si gestionas varios servidores con cPanel y este tipo de ajuste te toca hacerlo cada semana en cuentas distintas, en algún punto merece la pena comparar los dos paneles a fondo, lo hacemos en cPanel vs Plesk: comparativa completa y, si tu alternativa es un panel gratuito, en DirectAdmin vs cPanel: diferencias reales.
Añadir una IP a la lista blanca en Plesk
Plesk sí expone la whitelist en la interfaz gráfica, lo que la hace más accesible para quien no quiere tocar SSH.
Método recomendado: excluir una regla por IP desde Custom directives
Ve a Tools & Settings > Web Application Firewall (ModSecurity) > Settings y en el campo Custom directives añade:
SecRule REMOTE_ADDR "@ipMatch 203.0.113.45" "id:900001,phase:1,t:none,log,pass,ctl:ruleRemoveById=949110"Sustituye 949110 por el ID real de la regla que te está bloqueando y 203.0.113.45 por tu IP. Plesk valida la sintaxis antes de aplicar el cambio, si hay un error, te avisa antes de reiniciar el servicio web. El procedimiento exacto está documentado en el soporte oficial de Plesk para whitelist de IP en ModSecurity.
Un detalle que rara vez se explica bien: las reglas de whitelist deben cargarse antes que el resto de reglas del WAF, porque ModSecurity procesa las directivas en orden y una exclusión declarada después de la regla que bloquea no tiene efecto.
El problema del orden de carga (y cómo lo resolvemos en Avantys)
Si necesitas un bypass total (no solo de una regla, sino de todo el motor para esa IP), el campo de Custom directives desde la interfaz no siempre funciona: esas directivas se escriben en /etc/apache2/plesk.conf.d/modsecurity.conf, un archivo que Apache carga después de /etc/apache2/modsecurity.d/, donde viven las reglas del ruleset. El resultado es que tu exclusión “existe” pero nunca llega a tiempo de frenar la regla.
La solución real es crear el archivo manualmente en la carpeta que se carga antes:
nano /etc/apache2/modsecurity.d/custom_rules.confSecRule REMOTE_ADDR "@ipMatch 203.0.113.45" "id:1,phase:1,t:none,pass,nolog,ctl:ruleEngine=Off"Y después comprobar la sintaxis y aplicar cambios antes de reiniciar:
apachectl configtest
service apache2 reloadEs exactamente el mismo tipo de trampa que vemos con otras configuraciones de servidor donde el orden de lectura de archivos importa más que el contenido en sí: el sistema no respeta lo último que escribiste, respeta lo que carga primero.
Desactivar reglas concretas por dominio en Plesk
Si el problema afecta solo a un dominio (no a todo el servidor), ve a Domains > tudominio.com > Web Application Firewall (ModSecurity) y en la sección “Switch off security rules” indica el ID de regla, una etiqueta (por ejemplo CVE-2011-4898) o una expresión regular. Ojo: esto desactiva la regla para todos los visitantes de ese dominio, no solo para tu IP, es una herramienta distinta a la whitelist por IP, útil cuando el falso positivo lo sufren todos los usuarios legítimos, no solo tú.
Si trabajas a diario con varios paneles Plesk y cPanel a la vez, esta diferencia entre “excluir por IP” y “excluir por dominio” es de las que más confusión genera en equipos que migran de uno a otro, lo tratamos con más detalle en cómo migrar de cPanel a Plesk sin perder configuración.
Sintaxis @ipMatch: IP única, rangos y listas
El operador @ipMatch es el mismo en cPanel y Plesk porque ambos usan el motor ModSecurity estándar. Su referencia completa está en el manual oficial de ModSecurity, la fuente que ambos paneles enlazan en su propia documentación. Así se combina:
| Caso | Sintaxis | Cuándo usarlo |
|---|---|---|
| IP única | @ipMatch 203.0.113.45 | Un desarrollador, un cliente, una oficina con IP fija |
| Rango CIDR | @ipMatch 203.0.113.0/24 | Toda una oficina o proveedor con rango de IPs conocido |
| Varias IPs sueltas | @ipMatch 203.0.113.45,198.51.100.10 | Varios equipos o servicios concretos, sin rango común |
| Rango + IP suelta combinados | @ipMatch 203.0.113.0/24,198.51.100.10 | Mezcla de oficina + servicio externo puntual |
cPanel vs Plesk: gestión de whitelist de IP
| cPanel / WHM | Plesk | |
|---|---|---|
| Whitelist por IP desde la interfaz | No nativa (requiere plugin como ConfigServer CMC o edición de archivo vía WHM) | Sí, desde Custom directives en la interfaz |
| Whitelist por dominio (todos los visitantes) | Sí, toggle On/Off en cPanel de usuario | Sí, “Switch off security rules” por dominio |
| Exclusión de una regla concreta por IP | Sí, editando modsec2.user.conf o vía CMC | Sí, con ctl:ruleRemoveById en Custom directives |
| Bypass total del motor por IP | Sí, con ctl:ruleEngine=Off en reglas propias | Sí, pero requiere archivo en /etc/apache2/modsecurity.d/ por el orden de carga |
| Requiere reinicio de Apache | Sí, automático al guardar desde WHM | Sí, automático desde la interfaz; manual si editas el archivo directamente |
| Acceso de usuario sin root | Solo On/Off por dominio | Solo si tiene permisos de administrador de Plesk |
Si este cuadro te confirma que tu día a día es más de Plesk que de cPanel (o al revés), en cPanel vs Plesk: comparativa completa profundizamos en el resto de diferencias (rendimiento, licencia, curva de aprendizaje) y en VPS con cPanel o Plesk: cuál elegir lo llevamos al contexto específico de un VPS propio.
Buenas prácticas al hacer whitelist de IPs
- Exclusión por regla, no bypass total. Whitelistar solo la regla que da el falso positivo mantiene el resto del WAF vigilando esa IP. El bypass total (
ruleEngine=Offoallow) debería ser la excepción, no la norma. - Usa IPs fijas, no dinámicas. Si tu IP cambia (fibra doméstica sin IP estática), la whitelist deja de servir en cuanto el ISP la reasigna. Para eso, mejor una VPN corporativa con IP de salida fija.
- Documenta cada exclusión con su ID de regla y fecha. Un
custom_rules.confcon diez líneas sin comentarios, a los seis meses, es indescifrable. Añade un comentario por línea con motivo y fecha. - Revisa la whitelist cada cierto tiempo. Un desarrollador que dejó de trabajar en el proyecto hace un año probablemente no necesita seguir bypasseando el WAF.
- Nunca whitelistes rangos amplios “por si acaso”. Es la forma más rápida de anular el WAF entero sin darte cuenta.
Errores comunes al configurar la whitelist
- Poner la exclusión después de la regla que bloquea. En Plesk, si la escribes desde Custom directives y no funciona, revisa el orden de carga explicado arriba antes de asumir que la sintaxis está mal.
- Confundir “desactivar regla por dominio” con “whitelist de IP”. Son herramientas distintas: la primera afecta a todo el tráfico, la segunda solo a quien tú indiques.
- Olvidar el reinicio de Apache tras editar un archivo a mano. Si usas la interfaz de WHM o Plesk se hace solo; si editas
/etc/apache2/modsecurity.d/por SSH, no. - No verificar la sintaxis antes de aplicar. Un error de comillas o de operador puede tumbar Apache. Usa siempre
apachectl configtestantes de recargar. - Whitelistar la IP pública del router de la oficina sin control de quién está detrás. Si esa IP la comparten quince personas, estás dando vía libre a todas, no solo a ti.
Preguntas frecuentes
¿Por qué ModSecurity me bloquea si no estoy haciendo nada malo? Porque ModSecurity detecta patrones de texto, no intenciones. Un campo de formulario con HTML, una URL larga o ciertos parámetros de un plugin pueden coincidir con una regla pensada para bloquear ataques reales, generando un falso positivo.
¿Es lo mismo whitelistar una IP que desactivar ModSecurity? No. Desactivar ModSecurity apaga toda la protección del dominio para todos los visitantes. Whitelistar una IP mantiene el WAF activo para el resto del tráfico y solo exime a esa dirección concreta.
¿Puedo whitelistar un rango de IPs en vez de una sola?
Sí, usando notación CIDR en el operador @ipMatch, por ejemplo 203.0.113.0/24 para todo un rango de 256 direcciones.
¿La whitelist funciona igual en cPanel y en Plesk?
La sintaxis de la regla ModSecurity (SecRule REMOTE_ADDR "@ipMatch...") es idéntica en ambos, porque comparten el mismo motor. Lo que cambia es dónde se edita: Plesk lo expone en su interfaz, cPanel requiere WHM o un plugin.
¿Necesito acceso root para hacer esto? En cPanel, sí, para la gestión fina por regla (acceso WHM). En Plesk, necesitas permisos de administrador del panel, no necesariamente acceso SSH root, salvo para el bypass total por el problema de orden de carga.
¿Por qué mi exclusión en Plesk no funciona aunque la sintaxis es correcta?
Lo más probable es el orden de carga: si buscas un bypass total (ctl:ruleEngine=Off), el archivo de Custom directives se carga después de las reglas del ruleset. Necesitas colocarlo en /etc/apache2/modsecurity.d/ para que se lea antes.
¿Cómo sé qué regla exacta me está bloqueando?
Revisa el log de errores de Apache (error_log) o, en Plesk, el log de auditoría de ModSecurity desde la interfaz. Busca el campo [id "..."] en la línea del bloqueo.
¿Whitelistar mi IP afecta al SEO o a Google? No directamente. Los bots de rastreo legítimos (Googlebot, Bingbot) no suelen necesitar whitelist manual: los rulesets comerciales como Atomicorp los detectan y excluyen automáticamente para evitar falsos positivos que perjudiquen el rastreo.
¿Puedo automatizar la whitelist para varias IPs que cambian a menudo? Es posible con scripts que actualicen el archivo de reglas y recarguen Apache, pero en producción es más fiable y auditable mantener una lista fija y revisarla periódicamente que automatizar cambios frecuentes en un componente de seguridad.
¿Qué pasa si me equivoco al editar la regla y tumbo el sitio?
Por eso se recomienda apachectl configtest antes de recargar el servicio: valida la sintaxis sin aplicar el cambio. Si el sitio cae, revertir el archivo y recargar de nuevo restaura el servicio en segundos.
¿Un WAF externo (Cloudflare) sustituye a ModSecurity? Son complementarios, no sustitutos. Cloudflare filtra en el borde de su red antes de que la petición llegue a tu servidor; ModSecurity sigue protegiendo directamente la aplicación, incluido el tráfico que no pasa por Cloudflare.
Conclusión
Whitelistar una IP en ModSecurity no debería significar bajar la guardia del servidor entero. La diferencia entre un bypass total y una exclusión quirúrgica por regla es la diferencia entre “listo, no me vuelve a molestar” y “listo, y sigo protegido si esa IP alguna vez se ve comprometida”.
Si llegas hasta aquí después de perder una tarde entre logs de Apache, archivos de configuración y el orden de carga de Plesk, es una señal razonable de que este tipo de administración de servidor pesa más que el tiempo que le puedes dedicar. En Avantys nos encargamos de esto de forma recurrente: reglas de ModSecurity bien ajustadas, sin falsos positivos que bloqueen a tu equipo ni agujeros abiertos por whitelists demasiado amplias, una persona que responde, no un ticket que nadie lee. Si prefieres no tocar tú estos archivos cada vez que alguien se queda fuera, en administración de servidores nos encargamos de tu cPanel o Plesk de forma continua.
Artículos relacionados
¿Y si esto lo lleváramos nosotros?
Tu servidor, gestionado donde ya lo tengas, o montado por nosotros. Parches, copias, vigilancia y una persona que responde. Desde 60 €/mes.
