Recommandations de sécurité

Toute application web étant hautement complexe, et toute application présentant des problèmes de sécurité de temps en temps, elle implique généralement une combinaison d'inputs que le développeur n'avait pas anticipée. Le projet Moodle prend la sécurité au sérieux, et améliore continuellement Moodle pour colmater de telles failles au fur et à mesure que nous les découvrons.

Introduction

• Cette page contient des mesures de sécurité importantes pour votre installation Moodle
• Il convient de signaler les problèmes de sécurité sur le tracker Moodle (en les marquant comme des problèmes de sécurité!) pour que les développeurs puissent les voir et informer le plus tôt possible des correctifs les sites Moodle référencés des correctifs le plus tôt possible
• Ne pas poster les exploits eux-mêmes sur les forums ou ailleurs sur le web (afin de protéger les administrateurs Moodle n'ayant pas encore fait la mis à jour)

Mesures de sécurité élémentaires

• La meilleure stratégie est une bonne sauvegarde ! Mais vous ne disposez pas d'une bonne sauvegarde tant que vous ne savez pas la restaurer. Testez vos procédures de restauration !
• Ne chargez et activez que des logiciels ou services que vous allez utiliser
• Effectuez des mises à jour régulières
• Prenez exemple pour votre sécurité sur les couches de vêtements que vous portez dans les jours froids de l'hiver

Recommandations de base

• Mettre à jour Moodle à chaque nouvelle version

Les failles de sécurité publiées attirent l'attention des hackers après la sortie d'une nouvelle version. Plus la version est ancienne, plus elle est susceptible de contenir des vulnérabilités

• La fonction « Register globals » DOIT être désactivée

Ceci aidera à prévenir de potentiels problèmes XSS avec des scripts tiers. Ceci n'est plus utile depuis Moodle 2.7 (voir cette discussion).

• Utiliser des mots de passe robustes pour les administrateurs et les enseignants

Choisir des mots de passe « difficiles » est une pratique de base en sécurité pour se prémunir d'attaques brute force contre les comptes utilisateurs

• Ne donner des comptes d'enseignants qu'aux utilisateurs auxquels vous faites confiance. Éviter les bacs-à-sable publics avec des comptes enseignants libres sur des serveurs de production.

Les comptes enseignants ont des permissions moins strictes et il est ainsi facile de créer des situations dans lesquelles des données pourraient être abusivement modifiées ou volées

• Séparer vos systèmes le plus possible

Une autre technique de sécurité de base est d'utiliser des mots de passe différents sur des systèmes différents, d'utiliser des machines différentes pour des services différents, et ainsi de suite. Ceci réduira l'étendue des dégâts même si un compte ou un serveur a été compromis.

Effectuer des mises à jour régulières

• Utiliser des systèmes de mise à jour automatique
• Windows Update
• Linux : up2date, yum, apt-get

Pensez à automatiser vos mises à jour avec un script planifié via cron

• Le système de mise à jour de Mac OSX
• Pensez à être à jour de vos versions de php, apache et moodle

Utiliser les listes de diffusion pour se tenir à jour

• CERT - http://www.us-cert.gov/cas/signup.html
• PHP – http://www.php.net/mailing-lists.php – s'inscrire aux « Announcements list »
• MySQL – http://lists.myself.com – s'inscrire aux annonces MySQL

Pares-feu

• Les experts en sécurité recommandent l'usage d'un pare-feu

• Utiliser des combinaisons hardware/software différentes

• Désactiver les services non-utilisés est souvent aussi efficace que l'emploi d'un pare-feu

• Utilisez netstat -a pour passer en revue les ports ouverts

• Un pare-feu n'est pas la garantie absolue d'une sécurité parfaite

• Autoriser les ports : 80, 443 (SSL), et 9111 (pour le tchat)
• Administration à distance : ssh 22, ou rdp 3389

Politique des mots de passe

• La politique des mots de passe peut être définie dans Paramètres > Administration du site > Sécurité > Règles site

• Il y a une case à cocher pour déterminer si une politique de complexité du mot de passe doit être appliquée ou non, avec l'option pour déterminer une longueur minimale du mot de passe, le nombre minimal de chiffres, de lettres minuscules, de lettres majuscules et le nombre minimal de caractères non-alphanumériques.

• Si un utilisateur entre un mot de passe qui ne respecte pas ces critères, un message d'erreur leur indique alors la nature du problème rencontré avec leur mot de passe.

• L'imposition de la complexité du mot de passe combinée à celle d'un changement régulier de leur mot de passe initial fournit une aide réelle pour faire en sorte que les utilisateurs utilisent effectivement de « bons mots de passe ».

• Cependant, si vous forcez une trop forte complexité, vous courez le risque qu'ils notent par écrit leur mot de passe quelque part. Soyez donc réaliste !

Salage des mots de passe

Uniquement pour les versions de Moodle 2.4 et antérieures. Les versions 2.5 et ultérieures salent les mots de passe individuellement, sans nécessiter de configuration particulière. Une variable globale n'est donc plus nécessaire pour les nouvelles installations de Moodle 2.5 ou ultérieures. Pour des sites mis à jour, le sel de mot de passe est nécessaire jusqu'à ce que tous les utilisateurs se soient connectés une fois au moins sur le site mis à jour (ce qui peut prendre du temps).

• Les mots de passe utilisateur sont stockés sous forme de hashs MD5 dans la base de données. Il est relativement facile de dériver des mots de passe originaux simples à partir de hashs simples. Il est possible de prévenir ce problème en paramétrant le salage des mots de passe. Voir salage des mots de passe pour plus de détails.

Se préparer au pire

• Prévoir de disposer à l'avance de sauvegardes
• S'entraîner à l'avance aux procédures de récupération
• Utiliser un détecteur de rootkits de façon régulière :
• Linux / MacOS X – http://www.chrootkit.org/
• Windows – http://www.sysinternals.com/Utilities/RootkitRevealer.html

Alertes de sécurité Moodle

• Référencez votre site sur Moodle.org

• Les utilisateurs inscrits reçoivent des alertes par courriel

• Les alertes de sécurité sont aussi postées en ligne
• Web – http://moodle.org/security
• Flux RSS – http://moodle.org/rss/file.php/1/1/forum/996/rss.xml

Considérations diverses

• Il vous est également conseillé de prendre en compte les éléments suivants, qui peuvent avoir un impact sur votre sécurité globale :
• Utiliser des paramètres de formulaires sécurisés
• Toujours paramétrer un mot de passe pour le superutilisateur MySQL
• Désactiver l'accès à MySQL par le réseau
• Utiliser SSL, httpslogins = yes
• Utiliser de bons mots de passe – paramétrer des règles pour les mots de passe dans Paramètres > Administration du site > Sécurité > Règles site
• Ne pas activer le paramètre opentogoogle (dans Paramètres > Administration du site > Sécurité > Règles site)
• Désactiver les accès invités (guest)
• Placer des clefs d'inscription sur tous les cours ou paramétrer « Cours disponible pour auto-inscription » = Non pour tous les cours
• Vérifier que l'indice de clef d'inscription soit désactivé (il s'agit du paramètre par défaut) dans Paramètres > Administration du site > Plugins > Inscriptions > Auto-inscription

Permissions les plus sécurisées / paranoïaques

Note : L'information ci-dessous s'applique aux installations basées sur Linux/Unix uniquement, le système de permissions de MS Windows étant très différent

En fonction de la configuration de votre serveur il y a deux scénarios différents :

1. Vous faites tourner Moodle sur votre propre serveur dédié
2. Vous faites tourner Moodle sur un hébergement mutualisé

Dans la section ci-dessous, il vous faut utiliser les bons utilisateur et groupe du service web pour paramétrer les permissions ; vous devez donc les connaître. Ceci peut varier sensiblement de serveur à serveur mais si cette fonctionnalité n'a pas été désactivée de votre serveur, vous pouvez aller à : http://votre.site.moodle/admin/phpinfo.php (en vous authentifiant en tant qu'admin), puis chercher la ligne « User/group », dans le tableau « Apache ». Par exemple, je trouve « www-data » pour le compte d'utilisateur et « www-data » pour le groupe aussi.

En faisant tourner Moodle sur un serveur dédié

En admettant que vous fassiez tourner Moodle sur un serveur scellé (à savoir un serveur interdisant l'authentification d'utilisateurs sur la machine) et que l'utilisateur root s'occupe des modifications à la fois du code Moodle et de la configuration Moodle (config.php), alors voici la configuration la plus stricte à laquelle je puisse penser :

1. Pour le répertoire moodledata et tout ce qu'il contient (y compris les sous-répertoires et les sessions) :

owner: apache user (apache, httpd, www-data, quelquechose ; voir ci-dessus)
group: apache group (apache, httpd, www-data, quelquechose ; voir ci-dessus)
permissions: 700 sur les répertoires, 600 sur les fichiers

2. Pour le répertoire Moodle et tout ce qu'il contient (y compris les sous-répertoires et config.php) :

owner: root
group: root
permissions: 755 sur les répertoires, 644 sur les fichiers

Si vous permettez les connexions locales d'utilisateurs, alors l'alinéa 2. doit se lire ainsi :

owner:root
group:apache group (apache, httpd, www-data, quelquechose ; voir ci-dessus)
permissions : 750 sur les répertoires, 640 sur les fichiers

Il faut concevoir les permissions ci-dessus comme étant les plus paranoïaques. Vous devriez être suffisamment en sécurité avec des permissions moins strictes, dans moodledata comme dans les répertoires et sous-répertoires moodle.

En faisant tourner Moodle sur un hébergement mutualisé

Si vous faites tourner Moodle sur un environnement mutualisé, alors les permissions ci-dessus sont probablement les mauvaises. Si vous définissez 700 comme permission pour les répertoires (et 600 pour les fichiers), vous bloquez probablement l'accès au compte d'utilisateur du service web à vos répertoires et fichiers.

Si vous voulez renforcer vos permissions le plus possible, vous devrez connaître :

1. le compte d'utilisateur et le groupe du service web (voir ci-dessus)
2. le propriétaire des répertoires/fichiers à la fois de moodledata et du répertoire moodle (cela devrait normalement être votre compte d'utilisateur client), ainsi que le group des répertoires / fichiers. Habituellement, il est possible de récupérer cette information via le gestionnaire de fichiers du panneau de contrôle de l'hébergeur. Allez dans le répertoire moodle et choisissez n'importe quel répertoire ou fichier et tentez de voir / modifier les permissions, propriétaire et groupe du fichier. Vous devriez voir apparaître les permissions, propriétaire et groupe actuels. Répétez l'opération pour le répertoire moodledata

Ensuite, en fonction des scénarios, il faudra utiliser des séries de permissions différentes (listées ici de la sécurité la plus forte à la moins forte) :

1. si le compte du service web est le même que le propriétaire des répertoires/fichiers, alors il faut utiliser 700 pour les répertoires et 600 pour les fichiers
2. si le groupe du service web est le même que le groupe des répertoires/fichiers, alors il faut utiliser 770 pour les répertoires et 660 pour les fichiers
3. à défaut, il faudra utiliser 777 pour les répertoires et 666 pour les fichiers, ce qui est mois sécurisé mais constitue la seule option possible. 707 et 606 seraient plus sûrs, mais peuvent ne pas forcément marcher, en fonction des particularités de votre installation.

En fait, il vous suffit de paramétrer moodledata avec les paramètres ci-dessus, comme tous les répertoires et les fichiers sont créés par le service web lui-même, et auront les bonnes permissions.

Concernant le répertoire moodle, dès lors que le compte d'utilisateur du service web peut lire les fichiers et lire et exécuter les répertoires, cela devrait suffire. Il n'est pas nécessaire de donner des permissions en écriture au service web sur les fichiers et les répertoires. Le seul inconvénient est qu'il va vous falloir créer config.php à la main pendant le processus d'installation, parce que Moodle ne sera pas en mesure de le créer. Mais cela ne devrait pas être un gros problème.

Voir aussi

Utiliser les forums de discussion Moodle :

• Guide to Securing your Moodle Server (en anglais)
• How to secure Moodle website from hacking including recommendations on emergency recovery (en anglais)