|
|
|
|
<html lang="en">
|
|
|
|
|
<head>
|
|
|
|
|
<meta charset="utf-8" />
|
|
|
|
|
<title>Chamilo Security Guide</title>
|
|
|
|
|
<link rel="stylesheet" href="../public/build/css/app.css" type="text/css" media="screen,projection" />
|
|
|
|
|
<link rel="stylesheet" href="../public/build/css/themes/chamilo/default.css" type="text/css" media="screen,projection" />
|
|
|
|
|
<link rel="stylesheet" href="default.css" type="text/css" media="screen,projection" />
|
|
|
|
|
<link rel="stylesheet" href="../public/build/css/print.css" type="text/css" media="print" />
|
|
|
|
|
<script src="../public/build/app.js"></script>
|
|
|
|
|
</head>
|
|
|
|
|
<body>
|
|
|
|
|
<div class="container">
|
|
|
|
|
<h1>Chamilo LMS: Security Guide</h1>
|
|
|
|
|
|
|
|
|
|
<a href="index.html">Documentation</a> > Security Guide
|
|
|
|
|
|
|
|
|
|
<p>We recommend you don't take security issues too lightly. Chamilo is security-audited at least once a year,
|
|
|
|
|
but you're never too sure. This list is a work in progress. Feel free to recommend additional measures by
|
|
|
|
|
sending us an e-mail at info@chamilo.org.</p>
|
|
|
|
|
|
|
|
|
|
<h2><b>Contents</b></h2>
|
|
|
|
|
<ol>
|
|
|
|
|
<li><a href="#1.Disclosing-server-info">Disclosing server info</a></li>
|
|
|
|
|
<li><a href="#2.Keeping-up-to-date">Keeping up to date</a></li>
|
|
|
|
|
<li><a href="#3.Using-safe-browsers">Using safe browsers</a></li>
|
|
|
|
|
<li><a href="#4.Moving-config-file">Moving your configuration file out of the web directory</a></li>
|
|
|
|
|
<li><a href="#5.Files-permissions">Restricting files permissions</a></li>
|
|
|
|
|
<li><a href="#6.HSTS">HTTP Headers Security</a></li>
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
<h2><a name="1.Disclosing-server-info"></a>1. Disclosing server info</h2>
|
|
|
|
|
<p>
|
|
|
|
|
It is considered a safer behaviour not to disclose server information from your Chamilo page. In order to avoid
|
|
|
|
|
both web server and PHP information disclosure, you might want to take the following actions:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>Locate the <i>ServerTokens</i> setting inside your Apache configuration and set it to "Prod"</li>
|
|
|
|
|
<li>Locate the <i>ServerSignature</i> setting inside your Apache configuration and set it to "Off"</li>
|
|
|
|
|
<li>Locate the <i>expose_php</i> setting inside your PHP configuration and set it to "Off"</li>
|
|
|
|
|
<li>Reload Apache</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h2><a name="2.Keeping-up-to-date"></a>2. Keeping up to date</h2>
|
|
|
|
|
<p>
|
|
|
|
|
Make sure you check <a href="http://support.chamilo.org/projects/chamilo-18/wiki/Security_issues">our security
|
|
|
|
|
issues page</a> from time to time.
|
|
|
|
|
Subscribe to our free security alerts mailing-list:
|
|
|
|
|
<a href="http://lists.chamilo.org/listinfo/security">http://lists.chamilo.org/listinfo/security</a> or that you
|
|
|
|
|
follow our security Twitter feed: <a href="http://twitter.com/chamilosecurity">http://twitter.com/chamilosecurity</a>.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h2><a name="3.Using-safe-browsers"></a>3. Using safe browsers</h2>
|
|
|
|
|
<p> Additionally to lacking the implementation of features that really improve the quality of your browsing the
|
|
|
|
|
Internet, older browsers tend to have many unresolved security flaws. Using an old browser, you put in danger the
|
|
|
|
|
security of your computer and the data it contains, but you can also put others in danger by letting crackers take
|
|
|
|
|
control of it and attacking others.</p>
|
|
|
|
|
<p>To avoid being a risk to yourself and others, you should download and install a recent browser. We recommend
|
|
|
|
|
<a href="http://www.getfirefox.com" target="_blank">the latest stable version of Firefox</a>.</p>
|
|
|
|
|
|
|
|
|
|
<h2><a name="4.Moving-config-file"></a>4. Moving your configuration file out of the web directory</h2>
|
|
|
|
|
<p>It is considered unsafe to leave the configuration file inside the app/config/ directory, as it will be directly
|
|
|
|
|
accessible for all users, which could lead crackers to download it, uninterpreted, and read through your
|
|
|
|
|
configuration, which could lead to illicit
|
|
|
|
|
access to your database if that one isn't well protected and many other stuff we'd prefer to avoid. To secure it,
|
|
|
|
|
move the configuration file out of your web directory. If your Chamilo installation is in /var/www/, move your
|
|
|
|
|
configuration to /etc/chamilo/configuration.php, for example. Then create a new app/config/configuration.php
|
|
|
|
|
file, open it, and write the following:</p>
|
|
|
|
|
<pre>
|
|
|
|
|
<?php
|
|
|
|
|
require '/etc/chamilo/configuration.php';
|
|
|
|
|
</pre>
|
|
|
|
|
<p>
|
|
|
|
|
This will prevent direct access to your settings and make it seem totally the same to Chamilo.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h2><a name="5.Files-permissions"></a>5. Restricting files permissions</h2>
|
|
|
|
|
<p>Making all the Chamilo files world-writable will help you install quickly, and it solves many
|
|
|
|
|
issues for people without much admin experience. However, it's more
|
|
|
|
|
secure to make a distinct user owner of all the chamilo files and folders,
|
|
|
|
|
and only give read access to the web server to all files, and write access
|
|
|
|
|
only to the directories previously mentioned.</p>
|
|
|
|
|
<p>This way, these files need
|
|
|
|
|
only be readable and writable by the Apache process owner, not by the
|
|
|
|
|
entire world. It would also be advisable to make all writable directory
|
|
|
|
|
refuse the interpretation of PHP files (except for the root of the courses
|
|
|
|
|
directories).</p>
|
|
|
|
|
<p>Don't hesitate to hire an experienced administrator to do that,
|
|
|
|
|
it might be a bit more expensive now, but you'll be happy not to have to loose
|
|
|
|
|
all of your data to a hacker who attacked your site.</p>
|
|
|
|
|
<p>Only the following directories have required (or optional) write
|
|
|
|
|
permissions from the web server:<br />
|
|
|
|
|
<ul>
|
|
|
|
|
<li>app/cache/</li>
|
|
|
|
|
<li>app/courses/</li>
|
|
|
|
|
<li>app/home/</li>
|
|
|
|
|
<li>app/logs/</li>
|
|
|
|
|
<li>app/upload/</li>
|
|
|
|
|
<li>main/default_course_document/images/</li>
|
|
|
|
|
<li>main/lang/ (optional, only for sublanguages)</li>
|
|
|
|
|
<li>web/css/ (optional, only for switching CSS through the web)</li>
|
|
|
|
|
</ul>
|
|
|
|
|
<br />
|
|
|
|
|
Because these directories have "write by the web server" permissions,
|
|
|
|
|
it is important to prevent the execution of PHP scripts from those
|
|
|
|
|
directories (because a specially-crafted attack could end up allowing
|
|
|
|
|
the upload of a PHP script to one of these). To do that, taking into
|
|
|
|
|
account we authorize overrides through .htaccess, we need to set
|
|
|
|
|
something that a .htaccess file cannot revert, and we need to set it
|
|
|
|
|
for each of those directories. This can be done as follows inside
|
|
|
|
|
your VirtualHost definition in Apache, where "/var/www/URL/" is the path of your VirtualHost web root:<br />
|
|
|
|
|
<pre>
|
|
|
|
|
<Directory /var/www/URL/app/cache>
|
|
|
|
|
php_admin_value engine Off
|
|
|
|
|
</Directory>
|
|
|
|
|
<Directory /var/www/URL/app/courses>
|
|
|
|
|
php_admin_value engine Off
|
|
|
|
|
</Directory>
|
|
|
|
|
<Directory /var/www/URL/app/home>
|
|
|
|
|
php_admin_value engine Off
|
|
|
|
|
</Directory>
|
|
|
|
|
<Directory /var/www/URL/app/logs>
|
|
|
|
|
php_admin_value engine Off
|
|
|
|
|
</Directory>
|
|
|
|
|
<Directory /var/www/URL/app/upload>
|
|
|
|
|
php_admin_value engine Off
|
|
|
|
|
</Directory>
|
|
|
|
|
<Directory /var/www/URL/app/Resources/public/css>
|
|
|
|
|
php_admin_value engine Off
|
|
|
|
|
</Directory>
|
|
|
|
|
<Directory /var/www/URL/main/default_course_document/images>
|
|
|
|
|
php_admin_value engine Off
|
|
|
|
|
</Directory>
|
|
|
|
|
<Directory /var/www/URL/main/lang>
|
|
|
|
|
php_admin_value engine Off
|
|
|
|
|
</Directory>
|
|
|
|
|
<Directory /var/www/URL/web/css>
|
|
|
|
|
php_admin_value engine Off
|
|
|
|
|
</Directory>
|
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
For Nginx, this would look like the following rules. However, do
|
|
|
|
|
remember that Nginx interprets rules in order of appearance, so these
|
|
|
|
|
rules would have to be at the top of your location rules to take the
|
|
|
|
|
highest priority:
|
|
|
|
|
<pre>
|
|
|
|
|
location ~ ^/app/(cache|courses|home|logs|upload|Resources/public/css)/.*\.ph(p[3457]?|t|tml|ar)$ {
|
|
|
|
|
deny all;
|
|
|
|
|
}
|
|
|
|
|
location ~ ^/main/default_course_document/images/.*\.ph(p[3457]?|t|tml|ar)$ {
|
|
|
|
|
deny all;
|
|
|
|
|
}
|
|
|
|
|
location ~ ^/main/lang/.*\.ph(p[3457]?|t|tml|ar)$ {
|
|
|
|
|
deny all;
|
|
|
|
|
}
|
|
|
|
|
location ~ ^/web/css/.*\.ph(p[3457]?|t|tml|ar)$ {
|
|
|
|
|
deny all;
|
|
|
|
|
}
|
|
|
|
|
</pre>
|
|
|
|
|
<br />
|
|
|
|
|
<hr />
|
|
|
|
|
<h2><a name="6.HSTS">HTTP Headers Security</a></h2>
|
|
|
|
|
<p>A relatively recent development in web security, HTTP headers can be modified either
|
|
|
|
|
from the web server or from the application (like Chamilo) to increase the security
|
|
|
|
|
of your visitors.</p>
|
|
|
|
|
<p>These implies several aspects, from simple to complex, to deal with, from stuff like
|
|
|
|
|
indicating which websites you say media or libraries can be loaded from, to adding
|
|
|
|
|
extra info about your SSL certificate to make sure a hacked certification authority
|
|
|
|
|
will not immediately make your certificate useless.</p>
|
|
|
|
|
<p>In Chamilo 1.11.6, we have added several parameters, together with recommendations,
|
|
|
|
|
to main/install/configuration.dist.php, that you are free to use or ignore,
|
|
|
|
|
depending on the level of security you want to achieve.</p>>
|
|
|
|
|
<p>To check your portal for possible improvements in terms of headers security,
|
|
|
|
|
we highly recommend the <a href="https://securityheaders.io/">securityheaders.io</a>
|
|
|
|
|
website. If you want to read more about CSP and all related headers
|
|
|
|
|
security techniques, check <a href="https://scotthelme.co.uk/">Scott Helme's blog</a>.
|
|
|
|
|
<h2>Authors</h2>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>Yannick Warnier, Zend Certified PHP Engineer, BeezNest Belgium SPRL,
|
|
|
|
|
<a href="mailto:yannick.warnier@beeznest.com">yannick.warnier@beeznest.com</a></li>
|
|
|
|
|
</ul>
|
|
|
|
|
</div>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
