Difference between revisions of "Security"

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Security.

m
m (formatting)
Line 1: Line 1:
<p class="note">Maybe we should take a look at the security in this "Security" page. :-/ Should it be a protected page maintained directly by http://security.moodle.org? Please, give us your opinion on this in the "page comments" label in this page.</p>
 
 
 
All web application software is highly complex, and every application has security issues that are found from time to time, usually involving some conbination of input that the programmers did not anticipate. The Moodle project takes security seriously, and is continuously improving Moodle to close such holes as we find them.
 
All web application software is highly complex, and every application has security issues that are found from time to time, usually involving some conbination of input that the programmers did not anticipate. The Moodle project takes security seriously, and is continuously improving Moodle to close such holes as we find them.
  
 
==Before all==
 
==Before all==
*In this document, you will find important security measures for your Moodle installation.
+
*In this article, you will find important security measures for your Moodle installation.
 
*You should report security problems directly at http://security.moodle.org - because developers might overlook it elsewhere, and they must not be released to general public until they are solved (to prevent attacks).
 
*You should report security problems directly at http://security.moodle.org - because developers might overlook it elsewhere, and they must not be released to general public until they are solved (to prevent attacks).
 
*You should not post actual exploits in the bugtracker or forums, for exactly the same reasons.
 
*You should not post actual exploits in the bugtracker or forums, for exactly the same reasons.
Line 16: Line 14:
 
==Basic recommendations==
 
==Basic recommendations==
 
*Update Moodle regularly on each release
 
*Update Moodle regularly on each release
**Published security holes draw crackers attention after release. The older the version, the more vulnerabilities it is likely to contain.
+
:Published security holes draw crackers attention after release. The older the version, the more vulnerabilities it is likely to contain.
 
*Disable register globals
 
*Disable register globals
**This will help prevent against possible XSS problems in third-party scripts.
+
:This will help prevent against possible XSS problems in third-party scripts.
 
*Use strong passwords for admin and teachers
 
*Use strong passwords for admin and teachers
**Choosing "difficult" passwords is a basic security practice to protect against "brute force" cracking of accounts.
+
:Choosing "difficult" passwords is a basic security practice to protect against "brute force" cracking of accounts.
 
*Only give teacher accounts to trusted users. Avoid creating public sandboxes with free teacher accounts on production servers.
 
*Only give teacher accounts to trusted users. Avoid creating public sandboxes with free teacher accounts on production servers.
**Teacher accounts have much freer permissions and it is easier to create situations where data can be abused or stolen.
+
:Teacher accounts have much freer permissions and it is easier to create situations where data can be abused or stolen.
 
*Separate your systems as much as possible
 
*Separate your systems as much as possible
**Another basic security technique is to use different passwords on different systems, use different machines for different services and so on.  This will prevent damage being widespread even if one account or one server is compromised.
+
:Another basic security technique is to use different passwords on different systems, use different machines for different services and so on.  This will prevent damage being widespread even if one account or one server is compromised.
  
 
==Run regular updates==
 
==Run regular updates==
Line 30: Line 28:
 
*Windows Update  
 
*Windows Update  
 
*Linux: up2date, yum, apt-get
 
*Linux: up2date, yum, apt-get
**Consider automating updates with a script scheduled via cron  
+
:Consider automating updates with a script scheduled via cron  
 
*Mac OSX update system
 
*Mac OSX update system
 
*Stay current with php, apache, and moodle
 
*Stay current with php, apache, and moodle
  
 
==Use mailing lists to stay updated==
 
==Use mailing lists to stay updated==
*CERT  
+
*CERT - http://www.us-cert.gov/cas/signup.html
**http://www.us-cert.gov/cas/signup.html
+
*PHP - http://www.php.net/mailing-lists.php - sign up for Announcements list
*PHP
+
*MySQL - http://lists.mysql.com - sign up for MySQL Announcements
**http://www.php.net/mailing-lists.php
 
**Sign up for Announcements list
 
*MySQL
 
**http://lists.mysql.com
 
**Sign up for MySQL Announcements
 
  
 
==Firewalls==
 
==Firewalls==
 
*Security experts recommend a dual firewall
 
*Security experts recommend a dual firewall
**Differing hardware/software combinations  
+
:Differing hardware/software combinations  
 
*Disabling unused services is often as effective as a firewall
 
*Disabling unused services is often as effective as a firewall
**Use netstat -a to review open network ports
+
:Use netstat -a to review open network ports
 
*Not a guarantee of protection
 
*Not a guarantee of protection
 
*Allow ports  
 
*Allow ports  
**80, 443(ssl), and 9111 (for chat),  
+
:80, 443(ssl), and 9111 (for chat),  
**Remote admin: ssh 22, or rpd 3389
+
:Remote admin: ssh 22, or rpd 3389
  
 
==Be prepared for the worst==
 
==Be prepared for the worst==
Line 58: Line 51:
 
*Practice recovery procedures ahead of time  
 
*Practice recovery procedures ahead of time  
 
*Use a rootkit detector on a regular basis  
 
*Use a rootkit detector on a regular basis  
**Linux/MacOSX:
+
**Linux/MacOSX - http://www.chkrootkit.org/  
***http://www.chkrootkit.org/  
+
**Windows - http://www.sysinternals.com/Utilities/RootkitRevealer.html
**Windows:
 
***http://www.sysinternals.com/Utilities/RootkitRevealer.html
 
  
 
==Moodle security alerts==
 
==Moodle security alerts==
 
*Register your site with Moodle.org
 
*Register your site with Moodle.org
**Registered users receive email alerts
+
:Registered users receive email alerts
 
*Security alerts also posted online
 
*Security alerts also posted online
*Web
+
*Web - http://security.moodle.org/  
**http://security.moodle.org/  
+
*RSS feed - http://security.moodle.org/rss/file.php/1/1/forum/1/rss.xml
*RSS feed
 
**http://security.moodle.org/rss/file.php/1/1/forum/1/rss.xml
 
  
 
==Miscellaneous considerations==
 
==Miscellaneous considerations==
*These are all things you might consider that impact your overall security
+
These are all things you might consider that impact your overall security:
 
*Turn off opentogoogle, esp for K12 sites
 
*Turn off opentogoogle, esp for K12 sites
 
*Use SSL, httpslogins=yes
 
*Use SSL, httpslogins=yes
Line 84: Line 73:
  
 
==Most secure/paranoid file permissions==
 
==Most secure/paranoid file permissions==
Assuming you are running this on a sealed server (i.e. no user logins allowed on the machine) and that root takes care of the modifications to both moodle code and moodle config (config.php), then this are the most tight permissions I can think of:
+
Assuming you are running this on a sealed server (i.e. no user logins allowed on the machine) and that root takes care of the modifications to both moodle code and moodle config (config.php), then this are the most tight permissions I can think of:
  
  1.- moodledata directory and all of its contents (and subdirs, includes sessions):
+
1. moodledata directory and all of its contents (and subdirs, includes sessions):
            owner: apache user (apache, httpd, www-data, whatever).
+
owner: apache user (apache, httpd, www-data, whatever)
            group: apache group (apache, httpd, www-data, whatever)
+
group: apache group (apache, httpd, www-data, whatever)
            perms: 700 on directories, 600 on files.
+
perms: 700 on directories, 600 on files
  
  2.- moodle directory and all of its contents and subdirs (including config.php):
+
2. moodle directory and all of its contents and subdirs (including config.php):
            owner: root
+
owner: root
            group: root
+
group: root
            perms: 755 on directories, 644 on files.
+
perms: 755 on directories, 644 on files.
  
If you allow local logins, then 2.- should be:
+
If you allow local logins, then 2. should be:
          owner: root
+
owner: root
          group: apache group
+
group: apache group
          perms: 750 on directories, 640 on files
+
perms: 750 on directories, 640 on files
  
 
Think of these permissions as the most paranoid ones. You can be secure enough with less tighter permissions, both in moodledata and moodle directories (and subdirectories).
 
Think of these permissions as the most paranoid ones. You can be secure enough with less tighter permissions, both in moodledata and moodle directories (and subdirectories).
 
==Running Moodle with PHP safe_mode=on==
 
 
Does any security guru dare to document that? I think it is possible to do that (both to run Moodle with safe_mode=on and to write the document). ;-)
 
  
 
==See also==
 
==See also==
*[http://moodle.org/mod/forum/discuss.php?d=39404 "Guide to Securing your Moodle Server" discussion] at [http://moodle.org http://moodle.org]
+
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=39404 Guide to Securing your Moodle Server] forum discussion
  
 
[[Category:Administrator]]
 
[[Category:Administrator]]

Revision as of 10:54, 16 February 2006

All web application software is highly complex, and every application has security issues that are found from time to time, usually involving some conbination of input that the programmers did not anticipate. The Moodle project takes security seriously, and is continuously improving Moodle to close such holes as we find them.

Before all

  • In this article, you will find important security measures for your Moodle installation.
  • You should report security problems directly at http://security.moodle.org - because developers might overlook it elsewhere, and they must not be released to general public until they are solved (to prevent attacks).
  • You should not post actual exploits in the bugtracker or forums, for exactly the same reasons.

Simple security measures

  • The best security strategy is a good backup! But you don't have a good backup unless you are able to restore it. Test your restoration procedures!
  • Load only software or services you will use
  • Perform regular updates
  • Model your security after the layers of clothing you wear on a cold winter day

Basic recommendations

  • Update Moodle regularly on each release
Published security holes draw crackers attention after release. The older the version, the more vulnerabilities it is likely to contain.
  • Disable register globals
This will help prevent against possible XSS problems in third-party scripts.
  • Use strong passwords for admin and teachers
Choosing "difficult" passwords is a basic security practice to protect against "brute force" cracking of accounts.
  • Only give teacher accounts to trusted users. Avoid creating public sandboxes with free teacher accounts on production servers.
Teacher accounts have much freer permissions and it is easier to create situations where data can be abused or stolen.
  • Separate your systems as much as possible
Another basic security technique is to use different passwords on different systems, use different machines for different services and so on. This will prevent damage being widespread even if one account or one server is compromised.

Run regular updates

  • Use auto update systems
  • Windows Update
  • Linux: up2date, yum, apt-get
Consider automating updates with a script scheduled via cron
  • Mac OSX update system
  • Stay current with php, apache, and moodle

Use mailing lists to stay updated

Firewalls

  • Security experts recommend a dual firewall
Differing hardware/software combinations
  • Disabling unused services is often as effective as a firewall
Use netstat -a to review open network ports
  • Not a guarantee of protection
  • Allow ports
80, 443(ssl), and 9111 (for chat),
Remote admin: ssh 22, or rpd 3389

Be prepared for the worst

Moodle security alerts

  • Register your site with Moodle.org
Registered users receive email alerts

Miscellaneous considerations

These are all things you might consider that impact your overall security:

  • Turn off opentogoogle, esp for K12 sites
  • Use SSL, httpslogins=yes
  • Disable guest access
  • Place enrollment keys on all courses
  • Use good passwords
  • Use the secure forms setting
  • Set the mysql root user password
  • Turn off mysql network access

Most secure/paranoid file permissions

Assuming you are running this on a sealed server (i.e. no user logins allowed on the machine) and that root takes care of the modifications to both moodle code and moodle config (config.php), then this are the most tight permissions I can think of:

1. moodledata directory and all of its contents (and subdirs, includes sessions):

owner: apache user (apache, httpd, www-data, whatever)
group: apache group (apache, httpd, www-data, whatever)
perms: 700 on directories, 600 on files

2. moodle directory and all of its contents and subdirs (including config.php):

owner: root
group: root
perms: 755 on directories, 644 on files.

If you allow local logins, then 2. should be:

owner: root
group: apache group
perms: 750 on directories, 640 on files

Think of these permissions as the most paranoid ones. You can be secure enough with less tighter permissions, both in moodledata and moodle directories (and subdirectories).

See also