Hardening Drupal para organizaciones: configuraciones de seguridad que reducen la superficie de ataque
Por Kike Gandia · Co-Fundador y CEO, OSCP
El hardening de Drupal establece la línea base de seguridad de la instalación: configuraciones que reducen la superficie de ataque visible antes de que se produzca cualquier intento de explotación. Para organizaciones que usan Drupal en contextos críticos —administraciones, universidades, medios, portales de salud— la configuración correcta es la primera barrera.
Hardening del sistema de permisos y roles
Drupal tiene un sistema de roles y permisos granular que, mal configurado, genera escaladas de privilegios entre roles editoriales. El hardening incluye: revisión de todos los permisos asignados a roles anónimos y autenticados básicos, verificación de que roles editoriales no tienen acceso a funciones PHP (el módulo PHP filter es un riesgo crítico), y auditoría de roles custom que pueden haber acumulado permisos innecesarios a lo largo del tiempo.
Hardening de la configuración del sitio
Fichero settings.php: Debe tener permisos 444 y no ser escribible por el servidor web. Contiene credenciales de base de datos y configuración de entorno. El fichero /sites/default/settings.php accesible desde el exterior es un hallazgo crítico en cualquier auditoría.
Trusted host patterns: La configuración trusted_host_patterns en settings.php previene ataques de HTTP Host header injection. Muchas instalaciones lo tienen vacío o demasiado permisivo.
Base URL y modo debug: Error reporting en producción que expone rutas del servidor, versión de PHP y estructura del sistema de ficheros debe estar deshabilitado. El modo de depuración de Drupal nunca debe estar activo en producción.
Hardening de módulos y actualizaciones
El equipo de seguridad de Drupal publica Security Advisories con un proceso estructurado. Las organizaciones con Drupal en contextos críticos deben tener un proceso formal de seguimiento y aplicación de parches de seguridad en un plazo máximo de 48-72 horas para advisories críticos.
El módulo Update Manager de Drupal notifica actualizaciones disponibles, pero no prioriza por criticidad. Para organizaciones con muchos módulos contrib, la gestión del ciclo de parcheo requiere un proceso propio.
Qué cubre el hardening y qué no
El hardening reduce la superficie de ataque, pero no sustituye ni al parcheo ni a la revisión de código. Conviene tener claro qué riesgo cierra cada cosa antes de dar una instalación por segura.
| Riesgo | ¿Lo cubre el hardening? | Qué hace falta además |
|---|---|---|
| Módulo contrib con vulnerabilidad conocida | No, solo reduce la exposición | Proceso de parcheo con seguimiento de los advisories |
| Escalada entre roles editoriales | En parte | Revisión de los permisos efectivos, rol a rol |
| Fallo en un módulo a medida | No | Revisión del código |
| settings.php escribible o accesible | Sí | — |
| Inyección en la cabecera Host | Sí, con trusted_host_patterns | — |
| Errores de PHP visibles en producción | Sí | — |
| Credenciales reutilizadas de un editor | No | Segundo factor y política de contraseñas |
| Contenido subido que se ejecuta como PHP | Sí, bloqueando la ejecución en el directorio de ficheros | — |
La lectura práctica: el hardening cierra bien los problemas de configuración, que son muchos y baratos de arreglar, y no toca los de código ni los de proceso, que son los que acaban provocando el incidente.
Los ficheros y rutas que conviene comprobar a mano
Hay un conjunto de comprobaciones que no requieren herramientas y que aparecen una y otra vez en auditorías de instalaciones por lo demás bien mantenidas.
- El directorio de ficheros subidos (/sites/default/files) no debe permitir la ejecución de PHP. Es la diferencia entre una subida de fichero molesta y una ejecución remota de código.
- Los ficheros CHANGELOG.txt del core revelan la versión exacta y deberían estar fuera del alcance público.
- /update.php no debería ser accesible sin autenticación.
- El registro de usuarios abierto en un sitio donde nadie debería registrarse es un hallazgo más frecuente de lo que parece.
- Copias olvidadas en el docroot: settings.php.bak, settings.local.php, volcados .sql, ficheros .patch y carpetas de despliegues antiguos.
- Un directorio .git expuesto entrega el código y, con frecuencia, credenciales del histórico.
- Los informes de estado del sitio, accesibles sin autenticar, resumen para un atacante la versión y los módulos instalados.
Ninguna de estas comprobaciones lleva más de unos minutos y cada una cierra un camino de reconocimiento que el atacante usa antes de elegir el exploit.
FAQ
¿El módulo Security Review de Drupal cubre todo el hardening?
El módulo Security Review automatiza la verificación de algunos controles básicos de configuración, pero no detecta problemas de lógica de permisos complejos, vulnerabilidades en módulos custom ni configuraciones de servidor. Es un punto de partida, no un sustituto de una auditoría.
¿Cuánto tiempo requiere aplicar hardening en una instalación Drupal enterprise?
Entre 1 y 3 días dependiendo del tamaño de la instalación, el número de módulos y la complejidad de los roles. El tiempo aumenta si hay módulos custom que requieren revisión de código.
¿El hardening puede romper funcionalidad del sitio?
Algunos ajustes sí pueden hacerlo, y por eso se aplican en preproducción antes que en producción. Los que más fricción generan son el bloqueo de la ejecución de PHP en el directorio de ficheros cuando algún módulo dependía de ello, la restricción de permisos sobre roles editoriales que llevaban años con más de lo necesario, y los trusted_host_patterns si el sitio responde en más dominios de los que el equipo recuerda.
¿Cada cuánto se revisa la línea base de hardening?
La revisión tiene sentido tras cada cambio relevante —una actualización mayor del core, un despliegue que añade módulos, un cambio de hosting o de CDN— y de forma periódica aunque no haya cambios, porque las configuraciones se degradan solas: alguien añade un rol, alguien deja un fichero de depuración, alguien amplía un permiso para salir del paso y no lo revierte.
Si el sitio ya está comprometido, ¿el hardening lo soluciona?
No. El hardening dificulta la entrada, pero no elimina lo que el atacante ya dejó dentro: usuarios creados, módulos modificados, ficheros PHP añadidos o tareas programadas. Con un compromiso confirmado, el orden correcto es respuesta a incidentes primero —conservar evidencia, averiguar la vía de entrada y limpiar— y hardening después, para que no vuelva a ocurrir por el mismo camino.