Moodle offers a quick way of detecting major security issues within your platform setup and that is the security overview report. Go to the Reports | Security overview page. A well configured Moodle should display the following screenshot. In case there are discrepancies, then review the explication near each issue that displays a warning and take the appropriate actions.
Right now, we will give you a simple what to do list in order to pass the security check report without going into too much details. Throughout this book, we will explain in more detail each item on this report list.
Note
The security overview report is available starting from Moodle 1.8.9 and 1.9.4. If you have an older version we strongly recommend you perform an upgrade to a more recent one. Meanwhile, follow the instructions and configure your LMS as suggested.
The checklist in security overview report consists of items that compare current configuration of your system with the recommended one and report the status. Some of the items in the checklist apply to the PHP configuration and others apply to the Moodle configuration.
PHP is configured through a special file called php.ini
. The location of this file may vary depending on your OS and type of installation. On Linux it may be usually found at /etc/php.ini
. To modify this file you can use any text editor available (vi, nano, notepad, etc.).
Note
After every modification of php.ini
you must restart your web server so that the changes may be applied to the system.
Moodle can be configured by using the configuration pages in the administrative part of the platform or by modification of a special configuration file called config.php
. Some configuration options are exclusive to the config.php
file while others are exclusive to administration interface.
Review the Moodle security overview report
We will now go through every option in the security overview report and explain briefly what it means together with the actual steps you need to perform in order to remedy potential security flaw.
Insecure dataroot: If the status for this item is not OK it means that the moodledata
folder is placed in a location accessible from the Web without any protection. The solution to this is either to move this folder to some other location or prevent public access with the appropriate web server configuration. For example, if your Moodle is located in /var/www/html/moodle
and your moodledata
is located in /var/www/html/moodledata
the report will show this as an error. To fix this you need to change the location of moodledata to some other directory, for example to /var/www/moodledata
.
Displaying PHP errors (display_errors option): The display_errors
directive determines whether error messages generated by PHP code should be sent to the browser. These messages frequently contain sensitive information about your web application environment, and should never be presented to mistrusted sources. Make sure it is configured like this in your php.ini:
Allow
EMBED
and
OBJECT:
A Moodle configuration option. Go to Administration | Security | Site policies in your Moodle and make sure that the option Allow EMBED and OBJECT tags is not checked. EMBED
and OBJECT
tags are used for inserting third-party web browser plug ins for reproducing multimedia content (Adobe Flash, Apple QuickTime, etc.) or for running special embedded applications like java-applets. Some of these plug ins have well-known security issues and therefore are not recommended for general public usage. By disabling this option we are preventing users to add these elements to their pages or other generated content or responses.
Enabled
.swf
media filter: Moodle configuration option. This should be disabled on production websites. Visit Administration | Modules | Filters | Multimedia Plugins and make sure it is disabled. This filter transforms any link to the Adobe Flash file to playable content by using integrated flash player. Since Flash has security issues this option is best left disabled.
Open user profiles: Moodle configuration option. Checks if user public profiles are open to anybody. Best practice is to require login before permitting somebody to actually take a look into other people's personal information. Go to Administration | Security | Site policies and make sure Force users to login for profiles is checked.
Open to Google: Moodle configuration option. Visit the Site policies page and uncheck Open to Google. With this option we choose whether we permit Google robots to scan the site's content and index it thereby permitting anybody to perform free-text search. In general, this is not a desired behavior in an LMS.
Password policy: A password policy is a set of rules designed to enhance computer security by encouraging users to employ strong passwords and use them properly. On the Site policies page check Password Policy. By enabling this we enforce usage of "strong" passwords therefore making it impossible to use dictionary attacks.
Password salt: Moodle stores encrypted versions of user passwords into database. Up until Moodle 1.9.8 it used the default way of encrypting user passwords which is prone to dictionary attacks. Password salt increases security of the generated encrypted passwords making a dictionary attack virtually impossible. As of Moodle 1.9.8 use of password salt is enabled by default. However, if you have an older version you can enable this by modifying the config.php
file. Place something like this in your Moodle config.php:
Be aware that enabling password salt is only possible by editing config.php
. You can generate good password salt by going to the special page designed for that purpose—http://dev.moodle.org/gensalt.php.
E-mail change confirmation: Go to the Site policies page and enable E-mail change confirmation. Every user in Moodle must have a valid e-mail address. A common way of fiddling with somebody's personal account is to change his password and registered mail address. To prevent these situations we enable e-mail change confirmation which forces a user to confirm changed e-mail address. This is done through a special e-mail sent to the new account.
Writable
config.php:
Make config.php
read-only. For example, on Linux you would do something like this:
XSS trusted users: Moodle has a set of seven standard roles. By default, any user with Administrative role on the platform level is completely trusted. Be very careful about which users can have this role. Keep it to a smallest possible group.
Administrators: Platform must have at least one user with Administrative role. By default that is user admin.
Backup of user data: User data are something very sensitive for every educational institution. Under the Family Educational Rights and Privacy Act (FERPA) student information can be disclosed only to limited set of people directly related with either student's family or educational institution. Only very limited group of people should be able to export student information tied to a course.
Default role for all users: This should be set to Authenticated user. If not go to Administration | Users | Permissions | User policies and configure it appropriately.
Guest role: This should be set to Guest.
Frontpage role: By default it is not set. You can leave it that way or create a special non-legacy role.
Default course role (global): The default setting for this is student. This is something that should seldom be changed.
Default course role: Same thing as the previous one but on the course level. Again the default value here is student.