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.

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.).

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.

• Register Globals: This is a PHP setting that can be configured by modifying the PHP configuration file—php.ini. This is the default setting in PHP since version 4.2. Make sure you have the following line in your php.ini:

register_globals = Off

• 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:

display_errors = Off

• No authentication: It is a Moodle configuration option. Make sure the "No authentication" plugin is disabled. Go to Administration | Users | Authentication | Manage authentication and configure it as displayed in the following screenshot:

• 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:

  $CFG->passwordsaltmain = '<randomly generated string>';
  

  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:

chmod ug=r,o= <Moodle path>/config.php

• 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.