Security:Insecure configuration management: Difference between revisions
(New page: This page forms part of the Moodle security guidelines. ==What is the danger?== Evil Hacker somehow gets access to your server some time and installs some nasty ...) |
No edit summary |
||
| Line 6: | Line 6: | ||
Unfortunately, you have no procedures in place for detecting that this is happening. | Unfortunately, you have no procedures in place for detecting that this is happening. | ||
Another problem is not updating to the latest Moodle release, which means that you will be running a version of Moodle with know security holes. | |||
| Line 11: | Line 13: | ||
This is not really a problem that can be solved from within Moodle code. However, any Moodle code that does install other PHP code (for example admin/langimport.php) must be written with extreme care. | This is not really a problem that can be solved from within Moodle code. However, any Moodle code that does install other PHP code (for example admin/langimport.php) must be written with extreme care. | ||
Moodle will soon have a feature that nags administrators to update to the latest version, when one becomes available. | |||
| Line 20: | Line 24: | ||
==What you need to do as an administrator== | ==What you need to do as an administrator== | ||
* Keep up-to-date with the latest Moodle release from whichever branch you are using. | |||
* Think about how you deploy the Moodle code to your server. For example, if you [[CVS_for_Administrators|use CVS]], then 'cvs status' will tell you which files have been edited. | * Think about how you deploy the Moodle code to your server. For example, if you [[CVS_for_Administrators|use CVS]], then 'cvs status' will tell you which files have been edited. | ||
* Alternatively, if you upload the Moodle code manually, delete all the old code except config.php before you upload a new version. | * Alternatively, if you upload the Moodle code manually, delete all the old code except config.php before you upload a new version. | ||
Revision as of 12:39, 6 November 2009
This page forms part of the Moodle security guidelines.
What is the danger?
Evil Hacker somehow gets access to your server some time and installs some nasty code. For example, they could add some code to the login page that records every username and password entered, and sends it back to evel-hacker.com.
Unfortunately, you have no procedures in place for detecting that this is happening.
Another problem is not updating to the latest Moodle release, which means that you will be running a version of Moodle with know security holes.
How Moodle avoids this problem
This is not really a problem that can be solved from within Moodle code. However, any Moodle code that does install other PHP code (for example admin/langimport.php) must be written with extreme care.
Moodle will soon have a feature that nags administrators to update to the latest version, when one becomes available.
What you need to do in your code
- If you are writing code like admin/langimport.php, make sure you know what you are doing.
What you need to do as an administrator
- Keep up-to-date with the latest Moodle release from whichever branch you are using.
- Think about how you deploy the Moodle code to your server. For example, if you use CVS, then 'cvs status' will tell you which files have been edited.
- Alternatively, if you upload the Moodle code manually, delete all the old code except config.php before you upload a new version.
- Be very careful who can access your servers.
