Guide to Securing Your Moodle Server

Guide to Securing Your Moodle Server

by Jonathan Moore -
Number of replies: 18
I am putting together a guide on securing your Moodle Server. I have two purposes.

1) I don't seem to be able to find an official document (point me at it if I am wrong)

2) I have an upcomming presentation on Moodle and one area I will be covering is security and I would like some input on my material.

Below are my rough notes so far.  Am I missing anything? Is the material accurate? Once I get a little feedback I will work on polishing up and fleshing out the guide and see about getting it into the documentation section for the community's use.

The best security strategy is a good backup!

  • Model your security after the layers of clothing you wear on a cold winter day. No single layer by itself stops you from freezing, but multiple layers acting together keep you warm, and secure!

http://security.moodle.org/

Subscribe to the moodle security list

via cron

  • you use the up2date or apt systems to install your mysql and php software than this method updates not only your basic OS files, but also your php and mysql software
  • or affordable
n exploit due to human error.

, hence improving security

, but encrypts data between server and sender.

o connections from 127.0.0.1. If you need to have access from several remote machines than use mysql user permissions to restrict access to specific hosts.

ost secure file permissions

http://moodle.org/mod/forum/discuss.php?d=36185

http://moodle.org/mod/forum/discuss.php?d=38428

Average of ratings: -
In reply to Jonathan Moore

Re: Guide to Securing Your Moodle Server

by Don Hinkelman -
Picture of Particularly helpful Moodlers Picture of Plugin developers
Thanks a lot, Jonathan, for this guide!   A couple thoughts...
  1. Separate two or three main sections:  simple security, medium, and high (obsessive?) security
  2. Add to Moodle Docs (if you haven't already), so others can build on your fine work.   smile
Average of ratings: -
In reply to Don Hinkelman

Re: Guide to Securing Your Moodle Server

by Jonathan Moore -
Ok, I will have to see if I can figure out a way to organize these by level like that. I coud see where folks might want to pick a level and implement from there.
Average of ratings: -
In reply to Jonathan Moore

Re: Guide to Securing Your Moodle Server

by Iñaki Arenaza -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Debian Based
  • apt-get upgrade; apt-get upgrade
I guess you meant 'apt-get update && apt-get upgrade'. Better yet, use 'apt-get update && apt-get upgrade -u'. This way, you are asked to confirm the installation of the updates and have the opportunity to see what is going to be updated (and can stop working while your upgrading or after the upgrade).

Saludos. Iñaki.
Average of ratings: Useful (1)
In reply to Iñaki Arenaza

Re: Guide to Securing Your Moodle Server

by Jonathan Moore -
Yep, it was a typo. I have added a little more polished version of this to MoodleDocs, it is under Administration -> Security.

http://docs.moodle.org/en/Security

I did this during Helen's wonderful session at MoodleMoot Savanah and was just a little slow of making my post a live demonstration for the group.

So for those of you that want, you can add your comments there, or if not I will try to go through what has been posted here and add it to the current version.

Thanks again for all of your info.
Average of ratings: -
In reply to Jonathan Moore

Re: Guide to Securing Your Moodle Server

by koen roggemans -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Translators
Hi Jonathan. A few more things on this that crossed my mind.

I don't see anything about the php.ini and httpd.conf file in your note. When you open php.ini, there is  a warning on top like: don't use these settings on a production server, you must secure it first. What is necessary?
The register globals off is one thing, but it is off, by default.

Another thing is the mailserver. It might be out of the scope of your post, but do people run a mailserver on the same machine just for Moodle or use another one? How to secure that? Handling of the bounces eg?

There is also the configuration of the CLAMAV integration to mention.

Cheers, Koen
Average of ratings: -
In reply to koen roggemans

Re: Guide to Securing Your Moodle Server

by Jonathan Moore -
I will see if I can gather some information on php.ini and httpd.conf files and get it added in.

In terms of mailserver, I don't think there is a particular security issue with having mail on the same server. It is more of a performance and size issue in my opinion and I have set it up both on a single server and as seperate ones.  Mailconfig will probably be out of the scope of what I am working on, but I can say that I like to use MailScanner and clamav in front of my mail system and now that the guide is on MoodleDocs someone else could certainly work something up with a little on email security.

I will definetely get something up about clamav integration.


Average of ratings: -
In reply to Jonathan Moore

Re: Guide to Securing Your Moodle Server

by Martín Langhoff -

A few additional things...

  • Tighten down PHP settings, which for some reason default to developer settings, not production server settings. Errors written only to the logs is a very important thing on a server.
  • Make sure your dirroot directory and the files inside is not writable by apache. Moodle code files should be owned by root or by other user, not the apache user.
  • Make sure moodledata is not accessible via apache directly.

And of course, take advantage of the ClamAV goodness whenever possible... wink

Average of ratings: -
In reply to Martín Langhoff

Re: Guide to Securing Your Moodle Server

by Jonathan Moore -
Thanks Martin. I think I actually used your and Iñaki's posts regarding file permissions for the section on ownerships, but I think I managed to get the ownerships between the folders reversed (not enough sleep).

Does this look right?

  • The moodle directory
    • Owner root
    • Group root
    • Permissions 755 directories, 644 files
  • The moodledata directory
    • Should be placed outside the webroot, or restricted via .htaccess file
    • Owner root
    • Group apache group
    • Permissions 700 directories, 600 files



Average of ratings: -
In reply to Jonathan Moore

Re: Guide to Securing Your Moodle Server

by Iñaki Arenaza -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Does this look right?

I'm afraid not smile, according to this: http://moodle.org/mod/forum/discuss.php?d=36185#167980

Saludos. Iñaki.
Average of ratings: -
In reply to Iñaki Arenaza

Re: Guide to Securing Your Moodle Server

by Jonathan Moore -
Ok, I went ahead and just pasted the post into the doc. You might have a look to make sure it is now correct.
Average of ratings: -
In reply to Jonathan Moore

Re: Guide to Securing Your Moodle Server

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
I have merged some hints from security.moodle.org, feel free to tidy it up a bit wink

I guess there is also missing some basic info:
  1. users should report security problems directly at security.moodle.org - because developers might overlook it elsewhere
  2. users should not post actual exploits in the bugtracker or forums

skodak
Average of ratings: -
In reply to Petr Skoda

Re: Guide to Securing Your Moodle Server - Right forum and MoodleDocs

by David Delgado -

Mmmm... very interesting discussion but...

- I think it should be in the "Servers and performance" forum, not in this "Open Social" forum. Martin, could you please move this discussion there?

- We should be adding more conclusions to MoodleDocs at http://docs.moodle.org/en/Security

- I have added the important missing information from Petr, they were talking about it in the Talk page.

Average of ratings: -
In reply to David Delgado

Re: Guide to Securing Your Moodle Server

by Helen Foster -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators
Thanks everyone for your contributions to MoodleDocs. approve

Just moving this discussion to the Servers and Performance forum, as requested...
Average of ratings: -
In reply to Petr Skoda

Re: Guide to Securing Your Moodle Server

by Jonathan Moore -
Thanks Petr, I have been meaning to contact you regarding the page at the recommendation of Helen. Glad you found your way over hear.
Average of ratings: -
In reply to Jonathan Moore

Re: Guide to Securing Your Moodle Server

by Simon Aspray -
Rootkit detector for Windows on this site, as well as a number of other security utilities.
Confession: I've only just discovered it, so haven't tested it as yet.
http://www.sysinternals.com/Utilities/RootkitRevealer.html
Average of ratings: -
In reply to Simon Aspray

Re: Guide to Securing Your Moodle Server

by Tom Ceresini -
In my experience (CISSP and GSEC security certifications), sysinternals.com has always been rock-solid for security software and information. Disclaimer: I have no relationship with sysinternals.com except as a satisfied user.
Average of ratings: -
In reply to Tom Ceresini

Re: Guide to Securing Your Moodle Server

by Richie Foreman -
We presented to our higher-ups a while back about the security of Moodle.  One of the main pushing points for security we had was that all input from the user is cleaned in some way shape or form (in some places, it is cleaned a couple times).  This prevents SQL injections and the execution of arbitrary PHP code.  In addition, ADODB (the underlying DAL) does a little bit of its own cleaning.  I'd say for PHP sites, SQL injection and running arbitrary PHP code is probably the biggest overall threat to security.  Also, don't forget MySQL security!, that needs to be secure as well.  A MySQL with user:root, password:none is probably not a good idea.

--Richie Foreman
Average of ratings: -