Mostra la font per a Security recommendations

{{Security}}All web application software is highly complex, and every application has security issues that are found from time to time, usually involving some combination 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.


==Introduction==
*This page contains important security measures for your Moodle installation.
*You should report security problems to the [http://tracker.moodle.org/secure/CreateIssue!default.jspa  Moodle tracker] (and mark it as a security issue!) so that developers can see it and inform  registered Moodle sites about fixes as soon as possible.
*You should not post actual exploits in the forums or elsewhere on the web (to protect Moodle admins who have not upgraded yet).

==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.
*Register globals '''MUST''' be disabled!
: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==
*CERT - http://www.us-cert.gov/cas/signup.html
*PHP - http://www.php.net/mailing-lists.php - sign up for Announcements list
*MySQL - http://lists.mysql.com - sign up for MySQL Announcements

==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 rdp 3389

==Password policy==

A password policy may be set up in ''Settings > Site administration > Security > [[Site policies]]''.

There is a check box to determine if password complexity should be enforced or not, the option to set the minimum length of the password, the minimum number of digits, the minimum number of lowercase characters, the minimum number of uppercase characters and the minimum number of non alphanumeric characters.

If a user enters a password that does not meet those requirements, they are given an error message indicating the nature of the problem with the entered password.

Enforcing password complexity along with requiring users to change their initial password go a long way in helping ensure that users choose and are in fact using "good passwords".

However, making the check too onerous just results in them writing it down so be realistic.

==Password salting==

User passwords are stored as MD5 hashes in the database. It is relatively easy to derive original simple password from simple hash, this can be prevented by setting up password salt. See [[Password salting]] for more details.

==Be prepared for the worst==
*Have backups ready 
*Practice recovery procedures ahead of time 
*Use a rootkit detector on a regular basis 
**Linux/MacOSX - http://www.chkrootkit.org/ 
**Windows - http://www.sysinternals.com/Utilities/RootkitRevealer.html

==Moodle security alerts==
*Register your site with Moodle.org
:Registered users receive email alerts
*Security alerts also posted online
*Web - http://moodle.org/security
*RSS feed - http://moodle.org/rss/file.php/1/1/forum/996/rss.xml

==Miscellaneous considerations==
These are all things you might consider that impact your overall security:
*Use the secure forms setting
*Always set a mysql root user password
*Turn off mysql network access
*Use SSL, httpslogins=yes
*Use good passwords - set up a password policy in ''Settings > Site administration > Security > [[Site policies]]''
*Do not enable the ''opentogoogle'' setting (in ''Settings > Site administration > Security > [[Site policies]]'')
*Disable guest access
*Place enrollment keys on all courses or set Course Enrollable = No for all courses
*Ensure the enrolment key hint is disabled (which it is by default) in ''Settings>Site Administration>Plugins>Enrolments>Self enrolment.''


==Most secure/paranoid file permissions==

'''Note''': <u>The following information applies to Linux/Unix based installations only, as MS Windows permission system is quite different</u>.

Depending on your server setup there are two different scenarios:
# You are running Moodle on your own dedicated server.
# You are running Moodle on a shared hosting environment.

In the sections below, you are required to use the web service user account and group to set the permissions, so you need to know them. This can vary quite a bit from server to server but if this feature has not been disabled in your server, you can go to http://your.moodle.site/admin/phpinfo.php (logging in as admin), and then search for the line that reads 'User/Group', inside the 'apache' table. For example, I get 'www-data' for the user account and 'www-data' for the group too.

=== Running Moodle on a dedicated server ===
Assuming you are running Moodle 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 subdirectories, includes sessions):
 owner: apache user (apache, httpd, www-data, whatever; see above)
 group: apache group (apache, httpd, www-data, whatever; see above)
 permissions: 700 on directories, 600 on files

2. moodle directory and all of its contents and subdirectories (including config.php):
 owner: root
 group: root
 permissions: 755 on directories, 644 on files.

If you allow local logins for regular users, then 2. should be:
 owner: root
 group: apache group (apache, httpd, www-data, whatever; see above)
 permissions: 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).

=== Running Moodle on a shared hosting environment ===
If you are running Moodle on a shared hosting environment, then above permissions are probably wrong. If you set 700 as the permission for directories (and 600 for files), you are probably denying the web service user account access to your directories and files.

If you want to tighten your permissions as much as possible, you will need to know:

# the user account and the group the web service is running under (see above).
# the owner of the directories/files of both moodledata and the moodle directory (this should normally be your client user account), and the group of the directories/files. You can usually get this information from the file manager of your hosting control panel. Go to the moodle folder and pick any directory or file and try to view/change the permissions, owner and group of that file. That would normally show the current permissions, owner and group. Do the same for the moodledata directory.

Then, depending on the following scenarios you should use a different set of permissions (listed from more secure to less secure) for your moodledata directory:

# if the web service account and the owner of the directories/files is the same, you should use 700 for directories and 600 for files.
# if the web service group and the group of the directories/files is the same, you should use 770 for directories and 660 for the files.
# if none of the above, you will need to use 777 for directories and 666 for files, which is less secure but it is your only option. 707 and 606 would be more secure, but it might or might not work, depending on your particular setup.

In fact, you just need to set moodledata the permissions specified above, as all the directories and files inside are created by the web service itself, and will have the right permissions.

Regarding the moodle directory, as long as the web service user account can read the files plus read and execute the directories, that should be enough. There is no need to grant write permission to the web service account/group on any of the files or subdirectories. The only drawback is that you will need to create the config.php by hand during the installation process, as Moodle will not be able to create it. But that should not be a big problem.

==See also==

*[[Security FAQ]]
Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=39404 Guide to Securing your Moodle Server]
*[http://moodle.org/mod/forum/discuss.php?d=93561 How to secure Moodle website from hacking] including recommendations on emergency recovery

[[es:Seguridad]]
[[fr:Sécurité]]