Un Moodle expuesto a internet es, guste o no, un objetivo permanente de escaneo automatizado. No hace falta que nadie te “elija” específicamente para sufrir un intento de ataque, hay bots recorriendo constantemente instalaciones de Moodle en busca de versiones desactualizadas, configuraciones débiles o plugins vulnerables conocidos.
En esta guía vas a ver los vectores de ataque más comunes contra Moodle y las medidas concretas que reducen el riesgo real, no solo la sensación de seguridad.
Los vectores de ataque más habituales
Fuerza bruta contra el login
El intento más simple y más frecuente: probar combinaciones de usuario y contraseña de forma automatizada contra la pantalla de acceso. Sin protección, un atacante con tiempo suficiente puede comprometer cuentas con contraseñas débiles o reutilizadas de otras filtraciones. La variante más peligrosa no es la fuerza bruta clásica (miles de intentos contra un mismo usuario), sino el credential stuffing: probar pares usuario/contraseña filtrados de otros sitios, a razón de uno o dos intentos por cuenta, para no disparar los bloqueos. Contra eso, un límite de intentos por sí solo no basta.
Cómo se mitiga: activa el bloqueo de cuentas de Moodle (lo detallamos más abajo), fuerza una política de contraseñas mínima y añade fail2ban a nivel de servidor para cortar las IPs abusivas antes de que lleguen siquiera a PHP. La cuenta de administrador nunca debería llamarse admin a secas.
Explotación de plugins de terceros sin mantener
El núcleo de Moodle recibe parches con rapidez tras cada aviso de seguridad, pero los plugins de terceros no siempre siguen el mismo ritmo. Un plugin desactualizado con una vulnerabilidad conocida y públicamente documentada es, con frecuencia, la puerta de entrada más fácil para un atacante que ya sabe exactamente qué buscar. Y no hace falta que el plugin esté “en uso”: mientras su código siga en /mod, /blocks o /local, es superficie explotable aunque nadie lo haya activado en ningún curso.
Cómo se mitiga: antes de instalar nada, revisa la ficha del plugin en moodle.org/plugins, fíjate en la fecha del último release, la lista de versiones de Moodle soportadas y si el mantenedor sigue respondiendo. Un plugin sin actualizaciones en año y medio es un riesgo latente. Lo que ya no uses, desinstálalo (no solo lo desactives): borrar el código elimina el vector por completo.
Inyección (SQL) y cross-site scripting (XSS)
El núcleo de Moodle se prueba activamente contra inyección SQL y XSS, y usa APIs internas ($DB con parámetros, format_string(), format_text(), clean_param()) precisamente para neutralizarlos. El problema aparece cuando código de terceros o integraciones a medida saltan esas APIs: concatenan valores de usuario dentro de una consulta SQL, o pintan en pantalla texto sin sanear. Ahí es donde entra una inyección que roba datos de la base o un XSS que ejecuta JavaScript en la sesión de otro usuario, típicamente para robar su cookie de sesión y suplantarlo.
Cómo se mitiga: usar solo plugins que respeten las APIs de Moodle (otra razón para revisar su procedencia), mantener el núcleo al día (muchos avisos de seguridad de Moodle son exactamente parches de XSS/inyección en módulos concretos) y servir todo por HTTPS con la cookie de sesión marcada como secure, algo que cubrimos en SSL y HTTPS en Moodle.
Exposición pública de backups o de moodledata
Este es el vector que más vemos entrar por soporte y el que menos se comenta. moodledata (el directorio con archivos subidos, cachés y copias de seguridad de cursos) y los volcados de base de datos nunca deberían ser accesibles desde el navegador. El fallo clásico: dejar moodledata dentro de la raíz web (public_html), o soltar un backup.zip / dump.sql en un sitio público “solo un momento” y olvidarlo. Un .mbz de curso contiene datos personales de los alumnos; un volcado SQL contiene los hashes de todas las contraseñas. Los bots prueban rutas predecibles (/moodledata/, /backup.zip, /site.sql) de forma sistemática.
Cómo se mitiga: moodledata fuera de la raíz web, siempre. Si por la estructura del hosting no queda otra, protégelo con un .htaccess/regla del servidor que niegue todo acceso HTTP. Y no dejes nunca un backup manual a la vista: descárgalo por SFTP y bórralo del servidor.
Restauración de backups no confiables
La otra cara del backup: un archivo de copia de seguridad manipulado maliciosamente, si se restaura sin verificación, puede llegar a ejecutar código no autorizado en el servidor. Este vector es menos conocido que los anteriores, pero igual de real, y requiere que quien restaura el backup confíe en su procedencia sin comprobarlo.
Resumen: vector, cómo entra y cómo se corta
| Vector | Cómo entra | Cómo se mitiga |
|---|---|---|
| Fuerza bruta / credential stuffing | Login público probando credenciales filtradas | Bloqueo de cuentas + política de contraseñas + fail2ban + MFA en cuentas con privilegios |
| Plugin de terceros sin mantener | Vulnerabilidad conocida en código que sigue en el servidor | Revisar en moodle.org/plugins antes de instalar; desinstalar lo que no se usa |
| Inyección SQL / XSS | Código a medida que salta las APIs de saneado de Moodle | Solo plugins que usen las APIs; núcleo al día; HTTPS con cookie secure |
| Exposición de backups / moodledata | Archivos accesibles por URL (moodledata, dump.sql) | moodledata fuera de la raíz web; nunca dejar backups manuales servidos |
| Restauración de backup no confiable | .mbz/.sql manipulado restaurado sin verificar | Restaurar solo backups de origen conocido; probar antes en un entorno aislado |
El principio de la superficie de ataque
Toda esta lista comparte una idea de fondo: cada componente instalado es una puerta más que alguien tiene que vigilar. Un tema visual abandonado, un plugin de “gamificación” que se probó una tarde y se dejó ahí, un método de autenticación externo que ya nadie usa, todo eso amplía la superficie de ataque sin aportar nada. La regla es simple y poco glamurosa: menos plugins, menos riesgo. Antes de añadir funcionalidad, pregúntate si de verdad la vas a usar; y cada cierto tiempo, recorre la lista de plugins instalados y desinstala (no solo desactives) lo que no se justifique. Un Moodle con veinte plugins bien mantenidos es más seguro que uno con sesenta a medio actualizar.
Medidas concretas de protección
Mantén el núcleo y los plugins siempre actualizados
Es la medida más básica y, aun así, la más frecuentemente descuidada. La mayoría de exploits documentados contra Moodle atacan vulnerabilidades ya parcheadas en versiones más recientes, el riesgo real recae en quien no ha actualizado, no en quien está al día. Quedarse en una versión sin soporte multiplica el problema, porque deja de recibir parches aunque salgan avisos: lo desarrollamos en vulnerabilidades en versiones antiguas de Moodle. Suscríbete además al foro oficial de anuncios de seguridad de Moodle para enterarte de cada aviso el día que sale, no meses después.
Protección contra fuerza bruta en dos capas
Combina un plugin de protección a nivel de aplicación (que bloquea usuarios e IPs con patrones de intentos fallidos sospechosos) con fail2ban a nivel de servidor, que actúa sobre los logs del servidor web para bloquear IPs antes incluso de que lleguen a la aplicación.
Activa el bloqueo de cuentas por intentos fallidos
Moodle trae de serie el bloqueo de cuentas tras varios intentos de acceso fallidos. Está en Administración del sitio > Extensiones > Autenticación > Gestionar autenticación, en los ajustes de protección de contraseñas: activa Account lockout threshold con un umbral razonable (por ejemplo 5 intentos) y una ventana de bloqueo. Es la primera línea contra la fuerza bruta clásica y no depende de ningún plugin extra. Ojo con ponerlo demasiado agresivo: un umbral de 3 intentos genera bloqueos por despiste legítimo y satura al soporte con desbloqueos.
Exige verificación en dos pasos (MFA) en las cuentas con privilegios
Desde Moodle 4.3, la autenticación multifactor (MFA) forma parte del núcleo, antes era el plugin factor_* de la comunidad. Actívala en Administración del sitio > Extensiones > Autenticación multifactor y, como mínimo, hazla obligatoria para administradores, gestores y profesores con capacidad de editar. Una contraseña robada deja de ser suficiente para entrar: es la medida que más sube el listón contra el credential stuffing, precisamente el vector que los límites de intentos no frenan bien.
Revisa cada plugin de terceros antes de instalarlo
No instales plugins sin comprobar su historial de mantenimiento y si tienen vulnerabilidades conocidas documentadas. Un plugin sin actualizaciones recientes, aunque parezca funcionar bien, es un riesgo silencioso mientras siga activo en el servidor.
Verifica el origen de cualquier backup antes de restaurarlo
Nunca restaures un archivo de copia de seguridad de origen desconocido o no verificado, especialmente en un servidor de producción. Restaura primero en un entorno de pruebas aislado si tienes dudas sobre su procedencia.
Activa el informe de seguridad nativo y revísalo con regularidad
El informe de Comprobación de seguridad de Moodle (Administración del sitio > Informes > Comprobación de seguridad, Security Checks en inglés) valida automáticamente una batería de ajustes de seguridad y te devuelve cada uno con su semáforo. Entre lo que revisa: si moodledata está expuesto en la web, si el registro de usuarios abierto permite spam, si hay cuentas de administrador con contraseñas débiles, si el modo de desarrollador (debug) está activo en producción filtrando errores, o si falta la protección contra clickjacking. Ejecutarlo mensualmente y resolver cada aviso en rojo (y entender los ámbar antes de ignorarlos) es de las formas más rápidas de detectar configuraciones débiles antes de que las encuentre alguien más. Para llevarlo a un procedimiento repetible, combínalo con nuestro checklist de hardening de Moodle.
Limita la exposición de información en errores
Los mensajes de error detallados pueden filtrar información sensible sobre la estructura interna del servidor a quien los provoca deliberadamente. Configurar el servidor para no mostrar trazas de error completas al público reduce esta superficie de información.
Qué hacer si sospechas que tu Moodle ha sido comprometido
- Aísla el sitio poniéndolo en modo mantenimiento o desconectándolo temporalmente mientras investigas.
- Revisa los logs de acceso y de aplicación en busca de actividad anómala: accesos desde IPs inusuales, creación de usuarios inesperada, cambios de permisos no autorizados.
- Compara el código actual contra una copia limpia de la misma versión de Moodle para detectar archivos modificados o añadidos.
- Restaura desde un backup verificado anterior al incidente, nunca desde uno posterior a la fecha en que se detectó el compromiso.
- Cambia todas las contraseñas y claves (base de datos, usuarios administrativos, claves de API de integraciones) tras confirmar y resolver el incidente.
Errores comunes que facilitan un ataque
- No actualizar plugins de terceros, dejando vulnerabilidades ya conocidas y documentadas activas en el servidor.
- Confiar en la seguridad “por defecto” de Moodle sin revisar el informe de Security Checks.
- No tener protección contra fuerza bruta en ninguna capa, ni de aplicación ni de servidor.
- Restaurar backups sin verificar su procedencia, especialmente tras recibirlos por canales no controlados.
- Ignorar avisos de seguridad por no estar suscrito al canal oficial de anuncios de Moodle.
Preguntas frecuentes
¿Es normal que mi Moodle reciba intentos de ataque aunque sea pequeño? Sí. El escaneo automatizado no distingue por tamaño de instalación, cualquier Moodle expuesto a internet recibe intentos rutinarios de acceso y explotación de vulnerabilidades conocidas.
¿Los plugins de terceros son más vulnerables que el núcleo de Moodle? En la práctica, sí suelen ser el vector más común, porque no siempre reciben el mismo nivel de revisión y parcheo rápido que el núcleo oficial.
¿Qué hago si un plugin que uso tiene una vulnerabilidad conocida sin parche? Desactívalo hasta que exista una versión parcheada, o busca una alternativa mantenida, especialmente si la vulnerabilidad tiene explotación activa confirmada.
¿Cómo sé si mi Moodle ha sido comprometido? Revisa logs en busca de accesos o cambios anómalos, compara el código contra una copia limpia de la misma versión, y presta atención a usuarios o permisos que no reconozcas.
¿Restaurar un backup antiguo elimina un compromiso de seguridad? Solo si el backup es anterior a la fecha del incidente y su origen está verificado. Restaurar un backup posterior al compromiso puede reintroducir el mismo problema.
¿Necesito un firewall de aplicación web además de estas medidas? Es una capa adicional recomendable, especialmente si tu servidor está expuesto directamente a internet sin ninguna protección perimetral previa.
¿Con qué frecuencia debería revisar el informe de Security Checks? Al menos una vez al mes, y siempre después de instalar un plugin nuevo o actualizar el núcleo a una versión distinta.
¿Debería activar la verificación en dos pasos para todos los usuarios o solo para administradores? Empieza por hacerla obligatoria en las cuentas con privilegios (administradores, gestores, profesores editores): son las que, comprometidas, hacen más daño. Extenderla a todo el alumnado es más seguro pero genera fricción y carga de soporte; muchos sitios optan por dejarla opcional para estudiantes y obligatoria para el resto.
¿Cómo sé si mi moodledata está expuesto a internet?
El propio informe de Comprobación de seguridad lo señala. A mano, prueba a abrir en el navegador la ruta de moodledata seguida de un archivo que sepas que existe: si el servidor te lo descarga, está expuesto y hay que sacarlo de la raíz web de inmediato. Debería responder siempre con un error de acceso denegado.
Tengo muchos plugins instalados pero desactivados, ¿son un problema? Sí. Un plugin desactivado sigue teniendo su código en el servidor, y una vulnerabilidad en ese código puede ser explotable aunque no esté activo en ningún curso. Desactivar reduce el uso, pero no elimina la superficie de ataque: si no lo vas a usar, desinstálalo del todo.
Conclusión
Proteger Moodle de ataques no depende de una única barrera infranqueable, sino de reducir sistemáticamente cada vector de entrada conocido: plugins actualizados, protección contra fuerza bruta en dos capas, backups verificados antes de restaurar, y revisión periódica del informe de seguridad nativo. Ninguna medida es especialmente compleja por separado, lo que marca la diferencia es aplicarlas todas de forma consistente.
Si prefieres que alguien vigile esto de forma continua en vez de revisarlo tú mismo cada mes, en Avantys lo incluimos como parte del mantenimiento de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Checklist de hardening de Moodle
- Backups de Moodle: cómo verificar que restauran de verdad
- Vulnerabilidades en versiones antiguas de Moodle sin soporte
- Roles y permisos en Moodle: evitar accesos indebidos
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
