Once a month, add it to your calendar, check the security report. Again, you may have made changes or given temporary permission to someone.
Check the report and fix any issues.
Site administration > Reports > Security overview
What does all this mean? Let’s have a quick look through.
| Insecure dataroot | Dataroot directory must not be accessible via the web. EXTREMELY IMPORTANT. This folder should be kept outside the web accessible area. If this is set as CRITICAL then it must be fixed. | |
| Displaying of PHP errors | The PHP setting to display errors is enabled. It is recommended that this is disabled. This would only be enabled on test or staging servers if needed. If this is CRITICAL, please FIX ASAP. | |
| Vendor directory | The vendor directory should not be present on public sites. If you have the vendor directory then you are probably not using a release version of Moodle. You should download a release version and use it instead. | |
| Node.js modules directory | The node_modules directory should not be present on public sites. You are probably using a development version of Moodle if the node.js directory is showing CRITICAL. You should download a release version and use it instead. | |
| No authentication | No authentication plugin is disabled. This allows non-authenticated users to access the site. This should be disabled for most users of Moodle. | |
| Allow EMBED and OBJECT | Unlimited object embedding is not allowed. This should show OK. You don’t want any and everyone to be able to embed content in your site. | |
| Enabled .swf media filter | Flash media filter is enabled – this is very dangerous for the majority of servers. Flash is no longer supported. But some plugins and features drop back to Flash objects to complete tasks that some browsers still don’t do natively. It is best to turn this off with a disclaimer to some older browser users that you have disabled Flash and some features may not work. They should update their browser. | |
| Open user profiles | Login is required before viewing user profiles. Why you would not have this on I would not know… | |
| Open to Google | Search engine access is not enabled. Most sites do not need Google to crawl through the content in a Moodle site so this would normally be disabled. | |
| Password policy |
Password policy enabled. The default policy is…
|
|
| Email change confirmation | Confirmation of change of email address in user profile. Email confirmation will help reduce spammers changing emails without explicit permissions. | |
| Writable config.php | PHP scripts may modify config.php. Make sure config.php is not writable by the web user as you do not want anyone to remotely change the configuration of your site. | |
| XSS trusted users |
RISK_XSS – found x users that have to be trusted. Keep an eye on this as you do not want to have too many users that have the ability to do this. From the Moodle Documentation: “Some forms of rich Multimedia content, like embedding Flash applets, or bits of JavaScript, which teachers want to use to enhance their courses, use exactly the same technologies that evil people use for cross-site scripting attacks. If you were solely concerned with security, you would not allow this. However, Moodle is also concerned with education, so we have to make a compromise. Historically, the compromise was that teachers, course creators, and admins were trusted, and could post complex, but potentially risky content; while students and guests were not trusted, and anything they posted had the risky stuff stripped out.” https://docs.moodle.org/37/en/Site_security_settings#Password_policy |
|
| Administrators | Found 1 server administrator(s). Check that there are very few admins. This can get a bit too much if too many people think they need administrator access. | |
| Backup of user data | Found 1 roles, 0 overrides and 2 users with the ability to backup user data. This comes back to who you think should be able to backup student data and should really be very limited. | |
| Default role for all users | The default user role “Authenticated user” is incorrectly defined! This is the message on my development server. You should check your default user role to make sure it is appropriate for your situation. See https://docs.moodle.org/37/en/Security_report_on_default_user_role | |
| Guest role | Guest role definition is OK. | |
| Frontpage role | Frontpage role definition is OK. | |
| Web CRON | Anonymous users can access CRON. If you see this message then you defintely need to modify your CRON access. | |
| Executable paths | Executable paths can be set in the Admin GUI. If you receive a warning for this item, it means your config is set to allow Admin interface changes to the executable paths. On production, this should be set in the config.php instead of in the database as this provides better security. |
Check through all your settings and make sure they all show as green and you will have a much more secure Moodle server.
I hope this has been useful. Let me know what your thoughts are on any additional security that you think should be required for Moodle.
Would you like a FREE copy of the Top 10 Admin Tasks that you must know for Moodle Administrators?
You will discover some simple things that you can do in Moodle that will make your life easier.
