Chamilo LMS: Security Guide

Documentation > Security Guide

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.

Contents

  1. Disclosing server info
  2. Keeping up to date
  3. Using safe browsers
  4. Moving your configuration file out of the web directory
  5. Restricting files permissions
  6. HTTP Headers Security
  7. Direct web access to files

1. Disclosing server info

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:

2. Keeping up to date

Make sure you check our security issues page from time to time. Subscribe to our free security alerts mailing-list: http://lists.chamilo.org/listinfo/security or that you follow our security Twitter feed: http://twitter.com/chamilosecurity.

3. Using safe browsers

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.

To avoid being a risk to yourself and others, you should download and install a recent browser. We recommend the latest stable version of Firefox.

4. Moving your configuration file out of the web directory

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:

<?php
require '/etc/chamilo/configuration.php';

This will prevent direct access to your settings and make it seem totally the same to Chamilo.

5. Restricting files permissions

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.

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).

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.

Only the following directories have required (or optional) write permissions from the web server:


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:
  <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>
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: 
  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;
  }

HTTP Headers Security

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.

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.

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.

>

To check your portal for possible improvements in terms of headers security, we highly recommend the securityheaders.io website. If you want to read more about CSP and all related headers security techniques, check Scott Helme's blog.

Direct web access to files

If .htaccess is enabled or the .htaccess rules are translated into the web server vhost configuration (see installation guide for that), Chamilo will do some natural files access protection.

This protection is executed through redirections of some URLs to make the request go through some kind of permissions validation script. For documents, this means going through the main/document/download.php script, but there are some more specific rules (see .htaccess for details).

While this does a great job to avoid access by unprivileged users, this also creates an efficiency issue, whereby some files, in version 1.11, can take up to 5 times the load time when it goes through the permissions validation.

Because of that, we have taken some decisions to reduce the impact in a reasonable way. For example, static files in SCORM content (in courses/[code]/scorm/) like CSS, JS, PNG, JPG and GIF are *not* scanned this way (there is an exception for that). We believe that these resources do not contain confidential information. If you *DO* have confidential information in images, CSS or JavaScript files, you will need to update these rules to suit your needs.

Authors