Cómo securizar y proteger tu web Drupal frente a ciberataques y vulnerabilidades

Cuando entras a limpiar un Drupal comprometido a las tres de la mañana, casi siempre encuentras lo mismo: un módulo contrib que llevaba dos años sin actualizar, un formulario que aceptaba HTML sin filtrar, o un settings.php con permisos 644 que cualquier proceso del servidor podía leer. El core de Drupal rara vez es el problema. El equipo de seguridad de Drupal hace un trabajo serio: avisos publicados los miércoles, parches coordinados, severidad documentada con NIST. El problema casi nunca está en el software. Está en cómo lo operas tú.

Los ataques masivos contra sitios Drupal no buscan zero-days exóticos. Buscan lo predecible. Versiones que llevan meses sin tocar, módulos abandonados, contraseñas que un diccionario rompe en segundos, servidores con puertos abiertos que nadie audita. La mala noticia es que el atacante automatizado escanea internet entera cada pocas horas. La buena es que con higiene básica bien ejecutada bloqueas el 90 % de lo que va a llamar a tu puerta.

Esta guía sobre cómo securizar y proteger tu web Drupal frente a ciberataques y vulnerabilidades es lo que llevamos en la cabeza cuando hacemos hardening Drupal en un cliente nuevo. No teoría: lo que de verdad mueve la aguja.

Actualizar antes de que te actualicen ellos

El core de Drupal

Las actualizaciones de seguridad de Drupal se publican los miércoles a las 19:00 UTC. Apúntatelo. En cuanto un Drupal Security Advisory sale, los escáneres automatizados empiezan a buscar sitios sin parchear. Hablamos de horas, no de días.

Lo que necesitas:

• Suscríbete al feed de Drupal Security Advisories. No es opcional.
• Las críticas (PSA y SA-CORE marcadas como Highly Critical) se aplican en menos de 48 horas. Punto.
• Ten un entorno de staging que sea idéntico a producción. Aplicar parches a ciegas es cómo se rompen sitios.
• Automatiza con Composer y Drush. Un composer update drupal/core --with-dependencies seguido de drush updb y drush cr lleva minutos si tu pipeline está montado.

Los módulos contrib (donde está el 70 % de los disgustos)

He visto sitios con 180 módulos instalados de los que se usaban 40. Cada uno sumando superficie de ataque. Antes de añadir un módulo contrib, mira esto:

• Que tenga el badge "Covered by Drupal's security advisory policy". Sin eso, el equipo de seguridad no lo revisa.
• Última versión publicada. Si lleva más de un año sin commits, busca alternativa.
• Instalaciones activas. Un módulo con 200 instalaciones recibe menos escrutinio que uno con 50.000.
• Issue queue vivo. Maintainers que responden.

Y audita lo que ya tienes. drush pml --status=enabled te da la lista. Lo que no se usa, fuera. Lo que está abandonado, se sustituye o se mantiene un fork interno con presupuesto asignado.

PHP y el resto del stack

A día de hoy (2026) PHP 8.2 está en security-only y 8.3 recibe parches activos. Cualquier cosa por debajo es deuda técnica que ya está cobrando intereses. Lo mismo aplica al sistema operativo, a Apache o Nginx, a MariaDB o PostgreSQL. Drupal puede estar al día y el atacante entrar por una vulnerabilidad de OpenSSL del año pasado.

Configurar Drupal sin dejar la puerta abierta

Permisos: el principio de mínimo privilegio, en serio

Entra a /admin/people/permissions y mira la columna de usuario anónimo con ojos de atacante. ¿Puede crear nodos? ¿Puede ver el listado de usuarios? ¿Puede subir ficheros? Cada checkbox marcado de más es una invitación.

Tres reglas que aplicamos siempre:

• Mínimo privilegio en cada rol. No copies permisos de otros sitios. Empieza con nada y añade lo justo.
• El rol administrador es para tres personas como máximo. Cada cuenta admin es una llave maestra y un objetivo de phishing.
• Formatos de texto restringidos. "Full HTML" o cualquier formato con el filtro PHP solo para administradores. Un editor con acceso a HTML completo puede plantar XSS almacenado sin saberlo.

El sistema de ficheros

Esto es lo primero que reviso cuando aterrizo en un Drupal nuevo:

• settings.php con permisos 444 en producción. Si está en 644 o peor, en 666, cualquier proceso del servidor puede leer las credenciales de tu base de datos.
• Directorio sites/default/files que no ejecute PHP. En Nginx, un location con deny all para archivos .php. En Apache, el .htaccess que Drupal trae ya lo hace, pero verifica que AllowOverride lo respeta.
• Archivos privados fuera del document root. Si los sirves desde dentro, cualquier ruta mal pensada los expone.
• No toques los .htaccess que Drupal incluye en directorios sensibles. Están ahí por algo concreto.

Base de datos

El usuario de base de datos que usa Drupal no es root. No tiene GRANT ALL. Tiene SELECT, INSERT, UPDATE, DELETE y CREATE TEMPORARY TABLES sobre el esquema de Drupal y nada más. Si Drupal y la base están en máquinas separadas, conexión cifrada con TLS. Y los backups que verificas restaurando, no los que ocupan terabytes pero nunca has probado.

Cabeceras HTTP que no cuestan nada y bloquean mucho

Estas cabeceras se configuran una vez en el servidor web y dan dividendos durante años:

• Content-Security-Policy. La más útil contra XSS. Define orígenes permitidos para scripts, estilos, imágenes, iframes. Empieza con Content-Security-Policy-Report-Only para no romper nada, recoge violaciones, ajusta.
• Strict-Transport-Security con max-age=31536000; includeSubDomains; preload. HTTPS forzado a nivel navegador.
• X-Content-Type-Options: nosniff. Una línea, evita ataques basados en MIME sniffing.
• X-Frame-Options: SAMEORIGIN. Clickjacking fuera.
• Referrer-Policy: strict-origin-when-cross-origin. Razonable por defecto.
• Permissions-Policy. Apaga cámara, micrófono, geolocalización y sensores si tu sitio no los usa.

Pásalas por securityheaders.com cuando termines. Sale una nota. Que sea A o A+.

WAF, rate limiting y proteger el perímetro

Web Application Firewall

Un WAF analiza el tráfico HTTP antes de que llegue a Drupal y bloquea patrones conocidos. Las tres opciones que solemos plantear:

• Cloudflare. El más fácil de poner. Reglas managed específicas para Drupal, protección DDoS y CDN en el mismo paquete. Para la mayoría de sitios, sobra.
• AWS WAF. Si ya estás en AWS, integración con ALB o CloudFront. Las reglas administradas de AWS cubren el OWASP Top 10 sin que tengas que escribirlas.
• ModSecurity con CRS. Más control, más mantenimiento. El Core Rule Set actualizado cubre mucho terreno, pero los falsos positivos los gestionas tú.

Rate limiting

El formulario /user/login es el primero que escanean los bots. Sin rate limiting, una IP puede probar miles de credenciales por minuto. Configura límites en el WAF o en el servidor web, y activa el módulo Flood Control en Drupal para ajustar los umbrales por usuario y por IP. Mientras estás, protege también /user/password y cualquier endpoint de API que tengas expuesto.

Detectar lo que pasa cuando pasa

Logs que sirvan para algo

Watchdog en la base de datos no es un sistema de logs serio. El día que tengas un incidente, el atacante puede haber borrado esas filas. Manda los logs a algo externo: ELK, Grafana Loki, Datadog, lo que tu equipo mantenga. Captura como mínimo:

• Intentos de login fallidos con IP y user-agent.
• Respuestas 403 y 404 en cantidades sospechosas.
• Errores PHP que sugieran inyección o explotación.
• Cambios de permisos y de configuración.

Integridad de archivos

AIDE u OSSEC en el servidor avisan cuando aparece un fichero PHP nuevo donde no debería haberlo. Es la forma más fiable de detectar un webshell. En paralelo, el módulo Security Review hace una pasada periódica sobre la configuración de Drupal y te marca lo evidente: settings.php escribible, formato PHP activo, permisos sospechosos.

Escaneos periódicos

Mete en el calendario:

• Droopescan mensual. Detecta versión de Drupal, módulos instalados y vulnerabilidades conocidas. Es lo que usaría el atacante para fingerprintearte; mejor que lo uses tú primero.
• OWASP ZAP trimestral. Cubre el OWASP Top 10 contra tus formularios y endpoints. Lo lanzas contra staging, no contra producción.
• Qualys SSL Labs después de cada cambio en el certificado o en la configuración TLS. Que la nota se quede en A+.

Cuando te toca limpiar el desastre

Tener un plan escrito antes del incidente es la diferencia entre una respuesta ordenada y tres días sin dormir. El nuestro siempre cubre cuatro fases:

Detección y contención. ¿Cómo te enteras? Alerta del WAF, aviso de Google Search Console marcando el sitio como dañino, un usuario que reporta algo raro. Quién decide poner el sitio en modo mantenimiento. Cómo aislas la máquina sin destruir la evidencia forense (snapshot antes de tocar nada).

Investigación. Logs del servidor, logs de Drupal, logs del sistema. Buscas el vector. Buscas ficheros PHP creados después de cierta fecha en directorios donde no deberían existir. Buscas usuarios nuevos en la tabla users_field_data. Buscas cron jobs que no pusiste tú.

Remediación. Parche de la vulnerabilidad explotada. Limpieza de backdoors. Rotación completa de credenciales: admins de Drupal, base de datos, SSH, claves API, tokens de servicios externos. Si no puedes garantizar la integridad del sistema, restauras desde un backup anterior al compromiso y reaplicas los cambios legítimos desde cero.

Comunicación. Si hay datos personales comprometidos, el reloj de las 72 horas para notificar a la AEPD ya está corriendo según el RGPD. Comunicación clara a los usuarios afectados: qué pasó, qué datos suyos, qué tienen que hacer.

Checklist rápido para el lunes por la mañana

• Core de Drupal en la última versión de seguridad publicada.
• Módulos contrib actualizados; los abandonados, fuera.
• PHP en 8.2 o 8.3.
• Permisos por rol revisados, con el anónimo bajo lupa.
• settings.php en 444.
• HTTPS forzado con HSTS y preload.
• Cabeceras de seguridad con nota A+ en securityheaders.com.
• WAF activo con reglas para Drupal y rate limiting en /user/login.
• Backups automáticos verificados restaurando en staging.
• Logs centralizados fuera del servidor de Drupal.
• Plan de respuesta a incidentes escrito y leído por el equipo.

El plan del lunes por la mañana

La seguridad Drupal no se completa, se mantiene. Hay sitios que llevan diez años sin un incidente porque alguien dedica dos horas a la semana a revisar avisos, aplicar parches y leer logs. Y hay sitios que se comprometen tres veces en un año porque nadie se ha hecho responsable del mantenimiento desde que terminó el proyecto inicial.

Si quieres una auditoría de seguridad sobre tu Drupal, un plan de hardening priorizado por riesgo real, o un equipo que se haga cargo del mantenimiento continuo y la monitorización, cuéntanos qué Drupal tienes entre manos. Trabajamos con equipos que prefieren dormir tranquilos a esperar la próxima llamada a las tres de la mañana.