Moodle Health Check: Security

Also check http://docs.moodle.org/en/Security for upcoming security-related issues.

S1 dataroot directory directly accessible via the web (Chapters 2 and 10)

Moodle requires additional space on a server to store uploaded files such as course documents and user pictures. The directory is called dataroot and should not be accessible via the web.

Locate your dataroot directory outside the web directory and modify config.php accordingly ($CFG->dataroot entry).

If it is not possible to locate the directory outside the web directory, create a file .htaccess in the data directory and add a line containing deny from all.

S2 Usernames are protected (Chapters 5 and 10)

By default, forget_password.php does not display any hints that would allow guessing of usernames or email addresses.

Go to Site policies settings in the Security section and turn on Protect usernames.

S3 Guest access (Chapter 10)

Moodle provides a Guest role, which allows visitors to see certain content without being authenticated by the system. This should be avoided if possible.

Go to Authentication settings in the Users section and set Guest login button to Hide.

S4 Auto-login guests (Chapters 5 and 10)

Visitors can be logged in as guests automatically while entering courses with guest access.

Go to User Policies settings in the Permission subsection in the Users section, and turn off Auto-login guests.

S5 Open to Google (Chapter 10)

If you enable, Google bots will be allowed to enter your site as a Guest. Additionally, people coming in to your site via a Google search will automatically be logged in as Guests.

Go to Site policies settings in the Security section and turn off Open to Google.

S6 Disable register globals (Chapter 10)

The register_globals directive will inject PHP scripts with a number of variables such as request variables from HTML forms, which allows writing of insecure scripts. Turning it off will help prevent against possible XSS problems in third-party scripts.

Add php_flag register_globals 0 to .htaccess.

Add register_globals = Off to php.ini.

S7 Force users to log in for profiles (Chapter 5)

It is recommended that users log in to a real (non-guest) account before being allowed to see the user profile pages.

Go to Site policies settings in the Security section and turn on Force users to login for profiles.

S8 Allow EMBED and OBJECT tags (Chapters 8 and 10)

As a default security measure, normal users are not allowed to embed multimedia (such as Flash) within texts using explicit EMBED and OBJECT tags in their HTML (although it can still be done safely using the media plug-ins filter).

Go to Site policies settings in the Security section and turn off Allow EMBED and OBJECT tags.

S9 Enable trusted content (Chapter 10)

By default, Moodle will always thoroughly clean the text that comes from users to remove any possible bad scripts, media, and so on that could be a security risk. The Trusted Content System is a way of giving your trusted users the ability to include these advanced features in their content without interference. To enable this system, you need to first enable this setting and then grant the Trusted Content permission to a specific Moodle role. Texts created or uploaded by such users will be marked as trusted and will not be cleaned before display.

Go to Site policies settings in the Security section and turn off Enable Trusted Content.

S10 Blog visibility (Chapter 10)

Using this setting, the visibility of user blocks can be restricted to a particular level on this site. It is recommended to avoid the The world can read entries set to be world-accessible setting.

Go to Site policies settings in the Security section and set Blog Visibility to All site users can see all blog entries or less.

S11 Email notification enabled (Chapter 10)

If login failures have been recorded, email notifications can be sent out. They can be an indication of somebody unauthorized trying to get access to the Moodle system.

Go to Notifications settings in the Security section and set Email login failures to to Administrator or All administrators.

S12 Email or display notification threshold set (Chapter 10)

If notifications about failed logins are active, it is possible to specify the threshold of failed login attempts by one user or one IP address before an email is sent. The value should not be set to anything less than 10.

Go to Notifications settings in the Security section and set Threshold for email notifications to 10.

S13 Use strong Moodle admin password (Chapter 10)

Strong administrator password increases the security of your Moodle system.

Go to the user profile of each admin account and change the password to a strong version (mix upper- and lowercase characters, use numbers and special characters).

S14 Use strong Moodle database password (Chapter 10)

A strong Moodle database password increases the security of your Moodle system.

Change the Moodle MySQL password to a strong version (mix upper- and lowercase characters, use numbers and special characters). Also update config.php ($CFG->dbpass).

S15 Set MySQL root password (Chapter 10)

By default, the MySQL password is empty, which allows anybody with shell permission to get access to the Moodle database.

Go to your shell as superuser and use the following command to change the root password:

mysqladmin -u root password NEWPASSWORD

S16 Set course manager to appropriate role (Chapter 6)

The course manager should be set to the Teacher role.

Go to Course managers setting in the Appearance section, and select Teacher from the Course managers list.

S17 SWF Filter disabled (Chapters 8 and 10)

As a default security measure, normal users should not be allowed to embed swf flash files.

Go to Filters settings in the Modules section and select Multimedia Plugins Settings within these, and disable the .swf filter.

S18 Visitor role (Chapters 6 and 10)

Users who are not logged in to the site will be treated as if they have this role granted to them at the site context. This should be set to Guest.

Go to User policies settings in the Permissions sub-section in the Users section and select Guest as Role for visitors.

S19 Guest role (Chapters 6 and 10)

This role is automatically assigned to the guest user. It is also temporarily assigned to 'not enrolled users' when they enter a course that allows guests without a password. This should be set to Guest.

Go to User policies settings in the Permissions sub-section in the Users section and select Guest as Role for guest.

S20 Default role for all users (Chapters 6 and 10)

All logged-in users will be given the capabilities of the role you specify here at the site level, in addition to any other roles they may have been given. This should be set to 'Authenticated'.

Go to User policies settings in the Permissions sub-section in the Users section and select Authenticated user as Default role for all users.

S21 Default role for users in a course (Chapters 4, 6, and 10)

Users who enrol in a course will be automatically assigned this role. It should be set to "Student".

Go to User policies settings in the Permissions subsection in the Users section, and select Student for Default role for users in a course.

S22 Creator's role in new courses (Chapters 6 and 10)

This role is automatically assigned to creators in new courses they created. It should be set to Teacher.

Go to User policies settings in the Permissions subsection in the Users section, and select Teacher for Creators role in new courses.

S23 Minimize global roles assignments (Chapter 6)

Global roles will apply to the assigned users throughout the entire site, including the front page and all the courses. It is recommended to keep the number of global roles to a minimum.

Go to Assign global roles settings in the Permissions subsection in the Users section, and remove as many global roles as possible.

S24 Networking turned off (Chapter 14)

Moodle supports very powerful networking that allows connecting multiple Moodle systems in a peer-to-peer style or a hub topology. If not needed, this feature should be turned off.

Go to Networking | Settings and turn off Networking.

S25 XML-RPC hosts (Chapter 14)

The trusted hosts mechanism allows specific machines to execute calls via XML-RPC to any part of the Moodle API. This is available for scripts to control Moodle behavior and can be a very dangerous option to enable.

Go to XML-RPC hosts settings in the Networking section and delete any specified hosts, unless required.

S26 Backups specified (Chapter 12)

Moodle provides a backup facility that creates backups automatically. It is recommended to be activated unless you have alternative backups in place.

Go to Backups settings in the Courses section and activate backups.

S27 Block deleting files referenced by resources

Block deleting of files and directories referenced by resources. Please note that images and other files referenced from html are not protected.

Go to Resource settings in Activities in the Modules section, and set resource_blockdeletingfile to Yes.

S28 HTML Purifier disabled (Chapter 8)

Use HTML Purifier instead of KSES for cleaning of untrusted text. HTML Purifier is actively developed and is believed to be more secure, but it is more resource intensive. Expect minor visual differences in the resulting html code. Please note that embed and object tags cannot be enabled, and that MathML tags and old lang tags are not supported.

Go to Experimental settings in the Miscellaneous section and disable "Enabled HTML Purifier".

S29 Set password policy (Chapter 10)

A password policy may be set up to ensure that users choose passwords of certain length and so on.

Go to Site policies settings in the Security section and turn on Password policy.

Go to Site policies settings in the Security section and specify the following settings (minimum values):

• Password length: 8

• Digits: 1

• Lowercase letters: 1

• Uppercase letters: 1

• Non-alphanumeric characters: 1

S30 Email change notification

An email confirmation step is required when users change their email address in their profile.

Go to Site policies settings in the Security section and turn on Email change confirmation.

S31 ReCAPTCHA support (Chapter 5)

If you support email-based registration, it is advisable to turn on the ReCAPTCHA facility.

Go to the Authentication section in Users and provide private and public ReCAPTCHA keys.

Go to Email-based self-registration in the Uses | Authentication section, and enable turn on Enable ReCAPTCHA element.