Sécurité

Toute application web est complexe, et l'on découvre de temps en temps des trous de sécurité dans chacune d'entre elles. Habituellement, ces problèmes impliquent la saisie de texte que les développeurs n'ont pas anticipée. Le projet Moodle prend la sécurité très au sérieux et améliore continuellement Moodle de façon à résoudre de tels problèmes dès leur apparition, et même avant.

Préambule

• Dans cet article, vous trouverez d'importantes mesures de sécurité à prendre pour votre installation de Moodle.
• Les problèmes de sécurité que vous rencontrez doivent être rapportés directement à l'adresse http://security.moodle.org/, sans quoi les développeurs risquent de ne pas y être rendus attentifs, et aussi parce qu'ils ne doivent pas être rendus public avant d'avoir une solution (pour prévenir des attaques et éviter de faire peur indûment).
• Veillez à ne pas poster ni dans le gestionnaire de bogues, ni dans les forums, de messages avec du code permettant d'exploiter une faille de sécurité, afin là encore d'éviter les attaques.

Quelques mesures de sécurité simples

• La meilleure stratégie de sécurité est une bonne copie de sauvegarde ! Une copie de sauvegarde n'est bonne que si vous pouvez la restaurer. Testez vos procédures de restauration !
• N'utilisez que des logiciels et services que vous emploirez.
• Effectuez les mises à jour de façon régulière.
• Construisez votre modèle de sécurité comme les couches d'habits que vous portez lors d'un hiver froid.

Recommandations de base

• Mettez à jour Moodle régulièrement, lors de chaque nouvelle version :

les failles de sécurité publiées attirent l'attention des pirates après leur publication. Plus la version est ancienne, plus grand est la probabilité qu'elle contienne des failles.

• Désactivez l'option PHP register globals :

cela vous aidera à vous prémunir contre des éventuels problèmes XSS dans des scripts de tiers.

• Utilisez des mots de passe complexes pour les administrateurs et les enseignants :

l'utilisation de mots de passes difficiles à deviner est une pratique de protection de base pour éviter les attaques en force contre les comptes.

• Ne donnez des privilèges d'enseignants qu'à des utilisateurs fiables. Évitez la création de cours bac à sable avec des comptes d'enseignant ouverts sur des serveurs de production :

les comptes avec privilèges d'enseignant ont des permissions beaucoup plus larges et il est donc plus simple d'y créer des situations dans lesquelles les données peuvent être compromises.

• Séparez vos systèmes autant que possible :

une autre technique de base consiste à utiliser différents mots de passe sur des systèmes différents, à utiliser différentes machines pour des services différents, etc. Ceci évitera que les éventuels dommages ne se répandent, même si un compte ou un serveur est compromis.

Run regular updates

• Use auto update systems
• Windows Update
• Linux: up2date, yum, apt-get

Consider automating updates with a script scheduled via cron

• Mac OSX update system
• Stay current with php, apache, and moodle

Use mailing lists to stay updated

• CERT - http://www.us-cert.gov/cas/signup.html
• PHP - http://www.php.net/mailing-lists.php - sign up for Announcements list
• MySQL - http://lists.mysql.com - sign up for MySQL Announcements

Firewalls

• Security experts recommend a dual firewall

Differing hardware/software combinations

• Disabling unused services is often as effective as a firewall

Use netstat -a to review open network ports

• Not a guarantee of protection
• Allow ports

80, 443(ssl), and 9111 (for chat),

Remote admin: ssh 22, or rpd 3389

Be prepared for the worst

• Have backups ready
• Practice recovery procedures ahead of time
• Use a rootkit detector on a regular basis
  • Linux/MacOSX - http://www.chkrootkit.org/
  • Windows - http://www.sysinternals.com/Utilities/RootkitRevealer.html

Moodle security alerts

• Register your site with Moodle.org

Registered users receive email alerts

• Security alerts also posted online
• Web - http://security.moodle.org/
• RSS feed - http://security.moodle.org/rss/file.php/1/1/forum/1/rss.xml

Miscellaneous considerations

These are all things you might consider that impact your overall security:

• Turn off opentogoogle, esp for K12 sites
• Use SSL, httpslogins=yes
• Disable guest access
• Place enrollment keys on all courses
• Use good passwords
• Use the secure forms setting
• Set the mysql root user password
• Turn off mysql network access

Most secure/paranoid file permissions

Assuming you are running this on a sealed server (i.e. no user logins allowed on the machine) and that root takes care of the modifications to both moodle code and moodle config (config.php), then this are the most tight permissions I can think of:

1. moodledata directory and all of its contents (and subdirs, includes sessions):

owner: apache user (apache, httpd, www-data, whatever)
group: apache group (apache, httpd, www-data, whatever)
perms: 700 on directories, 600 on files

2. moodle directory and all of its contents and subdirs (including config.php):

owner: root
group: root
perms: 755 on directories, 644 on files.

If you allow local logins, then 2. should be:

owner: root
group: apache group
perms: 750 on directories, 640 on files

Think of these permissions as the most paranoid ones. You can be secure enough with less tighter permissions, both in moodledata and moodle directories (and subdirectories).

Voir aussi

• Discussion Guide to Securing your Moodle Server sur le forum de Using Moodle