This page aims at providing security advices you should follow as a TuxFamily hosted user. It will recall what the TuxFamily team tries to guarantee and define your responsibilities regarding your data, and especially your websites. This page will mostly focus on the management of your web areas. Indeed, their ability to generate pages dynamically (by executing custom Apache rules and/or various scripts) often make them an easy target for attackers. If by chance this looks tedious and/or boring, ... well, just try to imagine how bored you will be when your website is defaced and how tedious its reconstruction will be.
The cruel law of web hosting or Why security depends on you...
As a generic hoster, TuxFamily lets you generate your website with almost any tool you want as long as it talks "CGI". Still, most of you will stick to TuxFamily as being a PHP hoster. Once you chose PHP, you are either a web developer willing to build a website by yourself (possibly relying on existing frameworks such as Zend) or a non-developer who intends to rely on a Content Management System, aka a CMS, such as MediaWiki, WordPress, Drupal, Joomla, phpBB, etc, etc, etc. In both cases, one can easily get a functional website, but this does not guarantee its security. Common errors include:
- bad custom development: forgetting to sanitize input and output data, SQL injections, XSS, CSRF, ...
- letting sensitive files world-readable (e.g. a config.php file with your database credentials in it)
- NOT updating libraries and/or CMS you used: time slips by, known security issues pile up, and your website gets easier to attack, until some day you find it defaced or worse, you discover some kind of backdoor in your web area.
This is common enough for us to write this page. We do not intend to address a comprehensive list of advices for custom development; however, both remaining errors can be easily avoided.
What TuxFamily provides
From a technical point of view
Files you upload are created with your uid, the gid of your project group, and the permissions specified by your umask. If none of this makes sense to you, then you earned the duty to read and learn about Unix permissions.
TuxFamily uses PHP as provided by Debian stable, along with eAccelerator and suPHP. Unlike most Apache+PHP setup, scripts are not executed by the Apache user; instead, they are run as the owner of the executed file, which in most cases means... your own user.
TuxFamily applied extra security mechanisms that prevent your user (and thus your scripts) from reading files related to groups/projects you do not belong to. It also prevents you from setting your files world-writable (o+w).
Within a webarea, TuxFamily provides two interesting directories:
- htdocs: the DocumentRoot served by Apache. .htaccess files under that directory are interpreted by Apache. It may be used to store static resources and entry points such as index.php.
- php-includes: this directory can host any file (e.g. libraries, includes, ...) that will never be served by Apache directly; note the name includes PHP for historical reasons: its usage is not restricted to PHP-based websites.
Thus, TuxFamily enables you to split your web area content between served and non-served files. Note: our Apache daemon is able to read any world-readable file.
Summary: your responsibilities as a hosted user
TuxFamily does its best to separate hosted users while remaining a mutualized hoster. Applying the advices described below will enable you to benefit from these security measures. Failing to do so involves your responsibility when it comes to leaked data, stolen accounts/passwords and problems due to spam/phishing/other attacks made using your cracked web area.
- Read about Unix permissions. Seriously, it takes a page to know Unix permissions, you do not need a PhD, promised.
- When working on your website, adjust files permissions:
- your static resources (images, scripts, CSS) should be world-readable (o+r) -- actually, you could place them on a download repository to get better performance, but this is outside the scope of this page.
- your scripts acting as entry points (e.g. index.php) should also be world-readable (ensure they do not contain any important code/data)
- files included by entry points may be set world-readable as long as they do not contain anything relevant. Do not hesitate to set them non-world-readable though.
- files (.php, ini, etc.) containing credentials should NEVER be world-readable; chmod o-rwx is your friend.
- You need to upgrade your CMS regularly, i.e. as soon as possible after fixes are published.
- Some CMS include an alert system you may rely on to do so.
- You may also follow the mailing list and/or the RSS feed of the CMS project to stay tuned.
- Since security fixes and upgrades may bring regressions, bugs and downtime to your website, we strongly recommend you run a pre-production environment on a personal machine (preferably distinct from your development environment, so you may test your deployment procedure at least once).