In this section, we deal with configuration settings, login via the secure HTTP, the IP blocker, and the Safe Exam Browser integration.
There are a number of general configuration settings that potentially have an impact on the security of your system.
In the Notifications screenshot at the beginning of the chapter, you would have probably spotted the warning that the dataroot directory is directly accessible via the Internet. Moodle requires additional space on a server to store uploaded files, such as course documents and user pictures. The directory is called dataroot and must not be accessible via the Web. If this directory is accessible directly, unauthorized users can get access to content.
To prevent this, move your dataroot directory outside the web directory (ensure not to mangle permissions) and modify config.php accordingly by changing the $CFG->dataroot entry.
In externally hosted environments, it is often not possible to locate the directory outside the web directory. If this is the case, create a file called .htaccess in the data directory and add a line containing denyfromall.
We have already described the cron process in Chapter 1, Moodle Installation, and will go into more detail about this in Chapter 12, Moodle Performance and Optimization. This is a script that runs regularly to perform certain operations, such as sending notifications, processing statistics, cleaning up temporary files, and so on. Scripts that run at the operating system level can potentially contain malicious code.
It is possible to run the script via a web browser by simply typing in the URL, which is <yourMoodlesite>/admin/cron.php. To prevent this, two mutually exclusive settings can be seen by navigating to Security | Site policies.
If you only allow the cron process to be executed from the command line, running the script via a web browser will be disabled and a message will be displayed saying Sorry, internet access to this page has been disabled by the administrator. The cron process can still be executed automatically if it's set up correctly.
If the Cron password for remote access parameter is set, Moodle requires that executing the cron script via a web browser requires the provision of a password in the form of a parameter, such as <yourMoodlesite>/admin/cron.php?password=yourpassword. If the password is not provided or is incorrect, an error message, which is the same as the one we saw earlier, is displayed.
Moodle offers HTTPS support, which runs HTTP requests over SSL (a more secure but slower socket layer). The login of every system is a potential vulnerability. To run the authentication via SSL, enable the Use HTTPS for logins parameter, which can be activated by going to Security | HTTP security:
If using manual authentication, HTTPS encrypts the username and password before it is transferred from a user's browser to the server that hosts Moodle. HTTPS has to be enabled on your web server, and you will have to purchase or generate an SSL certificate. Every web server has a different method to enable HTTPS, so you will have to consult the documentation of your server. A good starting point of how to set up SSL/TSL for Apache can be found at http://httpd.apache.org/docs/current/ssl/ssl_howto.html.
By default, HTTPS is only used for the login procedure itself; once a user has logged in, Moodle reverts to HTTP. It is possible to run your entire Moodle system via HTTPS by changing the $CFG->wwwroot variable in the config.php file to the new secure URL. However, be aware that using HTTPS across the whole site will cause an increase in CPU load on your web server. If this becomes an issue, you can get the HTTPS/SSL accelerator cards that offload the encryption from the main CPU.
Web servers can be configured in a way that they only accept HTTPS URLs. If this is the case on your system, it is recommended that you enable the Secure cookies only parameter. Moodle already supports a new feature that instructs web browsers to send cookies only with real requests, which prevents some cross-scripting attacks. However, the Only http cookies feature is not supported by all web browsers.
Users will access your system from stationary and mobile devices. The one thing they all have in common is that they will access your site via an IP address. You have the ability to limit this access by specifying a whitelist and a blacklist by going to Security | IP blocker:
The whitelist (Allowed IP list) can contain IP addresses in a number of formats (the full IP address, partial address, ranges of IPs, and the CDIR notation). The same applies to the blacklist (Blocked IP list). By default, the blacklist has priority over the whitelist. If you wish to reverse this, select Allowed list will be processed first.
As an example, you might want to add 10.*.*.* to your whitelist and blacklist for a particular IP, say, 10.123.45.67, that was trying to guess your admin password multiple times.