Recomendaciones de Seguridad

Todo el software de aplicación web es altamente complejo, y en todas las aplicaciones se encuentran ocasionalmente aspectos relacionados con la seguridad, que por lo general implican alguna combinación de entrada (escritura de datos) que los programadores no anticiparon. En el proyecto Moodle tomamos en serio la seguridad, y estamos continuamente mejorando Moodle para cerrar cada agujero tan pronto como lo encontramos.

Introducción

• Esta página contiene importantes medidas de seguridad para su instalación de Moodle.
• Usted debería informar sobre problemas de seguridad directamente a http://security.moodle.org - dado que en cualquier otro lugar los desarrolladores podrían pasarlos por alto. Por otra parte, con el fin de prevenir ataques, los desarrolladores no deberían hacer públicos los problemas hasta que estuvieran resueltos.
• Por idénticas razones, usted no debería publicar los exploits (i.e., códigos escritos con el fin de aprovechar un error de programación para obtener privilegios) ni en el rastreador de errores (bugs) ni en los foros.

Medidas de seguridad simples

• ¡La mejor estrategia de seguridad es una buena copia de seguridad (Respaldo) ! Pero su copia de seguridad no será buena a menos que pueda restaurarla. ¡Compruebe sus procedimientos de Restauración !
• Cargue únicamente el software o los servicios que vaya a usar.
• Actualícese con regularidad.
• Diseñe su seguridad en diferentes capas (exterior, intermedia e interior como mínimo) como se abrigaría en un día frío de invierno, superponiendo diferentes prendas de ropa.

Recomendaciones básicas

• Actualice Moodle regularmente en cada lanzamiento/versión.

Los agujeros de seguridad publicados atraen la atención de los crakers después del lanzamiento. Cuanto más antigua sea la versión, tanto más probable es que tenga vulnerabilidades.

• Desactive Register globals (Registros globales).

Esto ayudará a prevenir contra posibles problemas XSS en scripts de terceros.

• Use Contraseñas complejas seguras para el administrador y los profesores.

Elegir contraseñas "difíciles" es una práctica de seguridad básica para proteger contra el cracking por "fuerza bruta" de las cuentas.

• Proporcione cuentas de profesor únicamente a usuarios dignos de confianza. Evite crear cajas de arena (sandboxes) públicas con cuentas gratuitas de profesor en servidores de producción.

Las cuentas de profesor tienen permisos mucho más libres y es más fácil crear situaciones donde sea posible abusar de los datos o robarlos.

• Separe sus sistemas todo lo que le sea posible

Otra técnica básica de seguridad es usar diferentes contraseñas en diferentes sistemas, usar diversas máquinas para diversos servicios, etc. Esto impedirá que el daño se extienda, incluso si una cuenta o un servidor son atacados.

Ejecute actualizaciones regulares

• Utilice sistemas de actualización automática
• Windows Update
• Linux: up2date, yum, apt-get

Considere automatizar las actualizaciones mediante un scritp programado vía cron

• Sistema de actualización Mac OSX
• Manténgase actualizado en php, apache y moodle

Utilice listas de correo para mantenerse actualizado

• CERT - http://www.us-cert.gov/cas/signup.html
• PHP - http://www.php.net/mailing-lists.php - suscríbase a la lista Announcements
• MySQL - http://lists.mysql.com - suscríbase a MySQL Announcements

Cortafuegos (firewall)

• Los expertos en seguridad recomiendan un cortafuegos (firewall)] dual

Existen diferentes combinaciones hardware/software

• El desactivar servicios no usados es a menudo tan efectivo como un cortafuegos

Use netstat -a para revisar puertos de red abiertos

• No es una garantía de protección
• Permita los puertos

80, 443(ssl), y 9111 (para el chat),

Admin remoto: ssh 22, o rpd 3389

Política de contraseñas

Se puede configurar una política para contraseñas en Configuraciones > Administración del sitio > Seguridad > Políticas del sitio.

Hay una casilla seleccionable para determinar si debe hacerse obligatoria la complejidad de las contraseñas; la opción para configurar la longitud mínima de la contraseña, el número mínimo de dígitos, el número mínimo de letras minúsculas y MAYÚSCULAS y el número mínimo de caracteres especiales no-alfa-numéricos (como $, %, &, ...).

Si un usuario escribe una contraseña que no reune estos requisitos, les aparece un mensaje de error que les indica la naturaleza del problema con la contraseña que escribieron.

El hacer obligatorias las contraseñas complejas, junto con exigirles a los usuarios que cambien su contraseña inicial, ayuda mucho para asegurarse de que en realidad los usuarios elijan y usen "buenas contraseñas".

Sin embargo, si se les piden contraseñas demasiado complicadas, lo que resulta es que las escriben en un papelito, por lo que hay que ser realista.

Nota: Una opción interesante es mostrarle a los usuarios cómo construir contraseñas fáciles de recordar; del estilo, por ejemplo, de Los3Cochinito$, que tiene un dígito, dos mayúsculas y un caracter especial ($).

Esté preparado para lo peor

• Tenga copias de seguridad disponibles
• Practique con antelación procedimientos de recuperación
• Utilice regularmente un detector rootkit
  • Linux/MacOSX - http://www.chkrootkit.org/
  • Windows - http://technet.microsoft.com/en-en/sysinternals/bb897445.aspx and http://technet.microsoft.com/de-de/sysinternals/bb897445.aspx

Alertas de seguridad de Moodle

• Registre su sitio en Moodle.org

Los usuarios registrados recibirán alertas por correo electrónico

• Las alertas de seguridad se pondrán también en línea
• Web - http://security.moodle.org/
• Canal RSS - http://security.moodle.org/rss/file.php/1/1/forum/1/rss.xml

Otras consideraciones

He aquí algunas otras otras consideraciones que favorecen su seguridad general:

• Use la configuración de formularios (formatos) seguros (secure forms)
• Siempre configure una contraseña para el usuario root en MySQL
• Desactive el acceso por red a MySQL
• Utilice SSL, httpslogins=yes
• Utilice buenas contraseñas; Configure una Política de contraseñas en Configuraciones > Administración del sitio > Seguridad > Políticas del sitio.
• Desactive opentogoogle, especialmente en sitios K12, en Configuraciones > Administración del sitio > Seguridad > Políticas del sitio.
• Desactive el acceso de invitados
• Incluya clave de matriculación (Clave de inscripción) en todos los cursos, o configure todos los cursos a No Matriculables (No Inscribibles)
• Asegúrese de que esté deshabilitada la pista para la clave de matriculación (inscripción), lo que debería de estar así por defecto, en Administración > Políticas del sitio > Plugins > Inscripción > Auto inscripción .

Permisos de archivo más seguros/paranoides

Nota: La información siguiente aplica solamente para instalaciones basadas en Linux/Unix, ya que el sistema de permisos en MS Windows es bastante diferente.

Dependiendo de la configuración de su servidor, hay dos diferentes escenarios:

1. Usted está corriendo Moodle en su propio servidor dedicado.
2. Usted está corriendo Moodle en un ambiente de alojamiento compartido.

En la sección inferior, a Usted se le pedirá que use la cuenta y grupo para usuario de servicio web para configurar los permisos, por lo que necesitará saberlos. Esto puede variar bastante de un servidor a otro, pero si esta característica no ha sido deshabilitada en su servidor, Usted puede ir a http://your.moodle.site/admin/phpinfo.php (ingresando como administrador), y entonces buscar la línea que diga 'User/Group', dentro de la tabla 'apache'. Por ejemplo, yo tengo 'www-data' para la cuenta de usuario y 'www-data' también para el grupo.

Corriendo Moodle en un servidor dedicado

Suponiendo que ejecute el programa en un servidor sellado (por ejemplo, en la máquina no se permiten entradas a usuarios) y que el root cuida de las modificaciones tanto del código de Moodle como de la configuración de Moodle (config.php), los siguientes son los permisos más restrictivos en los que podemos pensar:

1. directorio moodledata y todo su contenido (y subdirectorios, incluyendo sesiones):

owner: apache user (apache, httpd, www-data, lo_que_sea)
group: apache group (apache, httpd, www-data, lo_que_sea)
perms: 700 en directorios, 600 en archivos

2. directorio moodle y todo su contenido y subdirectorios (incluyendo config.php):

owner: root
group: root
perms: 755 en directorios, 644 en archivos.

Si usted permite entradas (logins) locales, entonces 2. debería ser:

owner: root
group: apache group
perms: 750 en directorios, 640 en archivos

Considere estos permisos como los más paranoides. Debería estar suficientemente seguro con permisos menos restrictivos, tanto en el directorio de moodle como en el de moodledata (junto con todos sus subdirectorios).

Corriendo Moodle en un ambiente de alojamiento compartido

Si Usted está corriendo Moodle en un ambiente de alojamiento compartido ( shared hosting environment ), entonces los permisos arriba descritos probablemente estén mal. Si Usted configura 700 como el permiso para los directorios, y 600 para los archivos, Usted probablemente le esté negando al usuario de la cuenta de servicio web el acceso a sus directorios y archivos.

Si Usted quiere aligerar sus permisos tanto como sea posible, Usted necesitará saber:

1. la cuenta de usuario y el grupo en donde está corriendo el servicio web (vea debajo).
2. el propietario de los directorios/archivos, tanto de moodledata como del directorio moodle (esto normalmente sería la cuenta de usuario de su cliente), y el grupo de los directorios/archivos. Usted generalmente puede obtener esta información del gestor de archivos de su panel de control de su servicio de alojamiento (hosting). Vaya a la carpeta moodle y elija cualquier directorio o archivo y trate de ver/cambiar los permisos, el propietario y el grupo de dicho archivo. Esto normalmente mostraría los permisos actuales, el propietario y el grupo. Haga lo mismo para el directorio moodledata.

Entonces, dependiendo de los siguientes escenarios, Usted debería de usar un conjunto diferente de permisos (enlistados en orden del más seguro al menos seguro) para su directorio moodledata:

1. si la cuenta del servicio web y el propietario de los directorios/archivos es el mismo, Usted debería de usar 700 para directorios y 600 para archivos.
2. si no es alguno de los arriba descritos, Usted necesitará usar 777 para directorios y 666 para archivos, lo que es menos seguro pero es su única opción. 707 y 606 serían más seguros, pero podrían o no trabajar, dependiendo de su configuración particular.

De hecho, Usted solamente necesita configurar en moodledata los permisos arriba especificados, dado que todos los directorios y archivos adentro son creados por el servicio web mismo, y tendrán los permisos correctos.

Con respecto al directorio moodle, en tanto que la cuenta del usuario del servicio web pueda leer los archivos y además leer y ejecutar los directorios, eso debería de ser suficiente. No hay necesidad de otorgar permisos de escritura a la cuenta/grupo de servicio web en cualquiera de los archivos o subdirectorios. La única desventaja de esto es que Usted necesitará crear el archivo config.php a mano durante el proceso de instalación, dado que Moodle no podrá crearlo. Pero esto no debería de ser un gran problema.

Vea también

• Seguridad FAQ
• Top security tips for Moodle administrators article

Using Moodle forum discussions:

• Guide to Securing your Moodle Server
• How to secure Moodle website from hacking including recommendations on emergency recovery
• https://docs.moodle.org/24/en/Why_porn_spam_has_been_appearing_in_Moodle_sites