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

Security recommendations: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
Line 1: Line 1:
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.
==Simple security measures==
==Simple security measures==
*The best security strategy is a good backup!  
*The best security strategy is a good backup!  
Line 4: Line 6:
*Perform regular updates
*Perform regular updates
*Model your security after the layers of clothing you wear on a cold winter day
*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==
==Run regular updates==

Revision as of 17:20, 12 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.

Simple security measures

  • The best security strategy is a good backup!
  • 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

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

  • 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