Sommaire
general issues
- general server security, see wiki
what is "political webhosting"?
a)- what's different to commercial hosting?
- - trust - security standards
or radicial webhosting, what is different from commercial provision. It is easy to got PHP hosting or what ever. They know us, they trust us. Most people who want to host don't know about the specific issues, but they trust that the security we implement are better.
b) what sensitive data is stored?
- - logfiles (from the web server, uploads etc.) - private information stored in their website directories (adresses etc) - info in "closed" websites (private wikis etc)
People trust the password protection or what ever on their websites or their webhosting diectorites. We need to make it clear to users that they shouldn't be using this hosting for information like this, it isn't sufficient means of protection for the data.
users
- user's interests <-> security - special issues of webhosting users
They want to do everything, every languages, gadgets, etc. Not specialists on websites, and cut and paste, install from base etc.
2b) data transfer / communication with users
Technicaly speaking, stop using unencrypted FTP. Authentication at least should be HTTPS.
webserver (httpd)
Which webservers are generally used?
- apache
- lighttpd - being used recently in activist circles - no modules, have to use cgi
- (thanks to Ruby on Rails, it seems)
- Does not have a php module so has to be run as a cgi.
Most of the focus on apache:
Apache run with for example php. Can be run as module or cgi
user seperation, sandboxing
Generally all web hosting should be separated somehow from the core server. Ideally all web sites should run in a separated context, but not realistic when hosting 100 websites to have 100 vservers.
scponly, chrooted, is nice but complicated to setup up (tutorial requested!). There was a security flaw though, but related to bad documentation, if set up properly now it should be secure scpjailer, alternaive, no experience here.
4b) seperation of webserver and database server context
Using vservers (or real servers) so they only communicate through network in an isolated fashion.
apache + php security issues
An example for webserver extensions/scripting languages
If you have the php module installed in apache 1 or 2, and you have a file containing some PHP call the file ".php.world", one would expect the source code to be shown. Nope, apache sees ".world" doesn't recognise so moves back to ".php" and executes the file as PHP. Same as Windows viruses and hidden extensions.
Upload form inside the website and verification scripts fails to check this, enabling attacks.
php security
some common examples of php settings:
- /etc/php4/apache/php.ini:
- session.use_trans_sid = off register_globals = off allow_url_fopen = off
- php_admin_flag register_globals 0 php_admin_flag session.use_trans_sid 0 php_admin_flag allow_url_fopen 0
To lock down PHP somewhat, you can disable the functions which most often cause problems. This only works in the global php.ini file, you can't enable and disable functions in a per site basis.
- /etc/php4/apache/php.ini: disable_functions = escapeshellarg, escapeshellcmd, exec, passthru,
- proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, shell_exec, system, apache_child_terminate, apache_get_modules, apache_get_version, apache_getenv, apache_lookup_uri, apache_note, apache_request_headers, apache_reset_timeout, apache_response_headers, apache_setenv, getallheaders, virtual, popen, pclose
mod_security can check every uploaded files.
Disable Content Negociation might help with the .php.world issue, but that needs to be verified. In general, web applications shouldn't allow files to be uploaded in directories which are served by the webserver.
Uploaded files should be uploaded outside the executable part of the website.
setup: apache + suexec + apache + php-cgi
If this is an option. "It would kill performance on our machines" (riseup)
The difference between module and cgi, is that you have real user seperation. The module in vhosting environment, it is like giving root access and then securing the shell. You are better doing it before.
There is safe_mode in PHP, it tries to solve a problem that shouldn't be solved by the software.
PHP's safe_mode looks a bit like user separation. Tries to solve the problem but this particular problem should not be address at the PHP level but with user separation.
Rasmus Lerdof (founder of PHP) says "the biggest problem with safe mode is that people use it." ref
open_basedir can provide basic user-seperation.
suphp can chroot each website and has similar performance problems than using php-cgi+suexec basically.
To help solve the performance issues there are several options, including: FastCGI or cgid in Apache 2, but it never gets to the module version performances.
The user seperation, can have a different php.ini file for each user. You can define enabled function in a very precise way using this. Much more work to maitain, though.
If you serve both mediawiki and drupal, they have different needs and functions. PHPxref can be used to find all the functions being called, you can then customise for the specific functions being called; e.g. two configuration templates for these two codebases.
As it is being used in user space, shell commands or admin web aps you can use sudo to have very specific configuration for rights promotion.
php programming security
6) future ideas to secure hosting seperation (vservers, chroot, even inside vservers, to isolate each users's data/web site) / Using XEN (?) encryption in userspace
An example of vserver set up 
Biggest problem the mass hosting of Drupal.
Boum example: http://wiki.boum.org/Frangipane/WebSiteDiscussion
Hosting standard, all user data on encrypted partitions. The user still has to trust the admins to handle the data correctly.
Think of a system to include the user to the responsability to encrypt data on the hard disk: for webhosting have crypted containers which could only be decrypted with cooperation with the user. If the police seize the server, they would have to ask 10 000 users for each private keys. 
A side note:- With content like: websites the data is "public", to have encrypted data is too much for public info. Unlike mail services which should not be on the same server, not backed up, and if it is really important push gpg
Mass hosting installations, common installs of ... systems
Common exploits can be stopped by blocking specific commands, or commands not used by programs.
Needs for users are so different that common installs don't work. You get mad working with updates and individual requirements. It is better to first secure the environment.
You can have the two at the same time using suExec for people who need custom code (on lower performance servers), and the common installs for everyone else on higher performance servers.
discussion
Q: why suexec and not suphp
A: we have experienc of suexec - suphp has notes about possible, just possible, questions about design flaws. concern that suphp is not well maintained.
php.ini file generated for each different install, automatically generated at started with apache using apache-perl. http://trac.riseup.net/privacy/browser/trunk/libapache-mod-removeip
Some concrete proposals requested for the webhosting section of the Security Protocols.
mod_removeip! \o/ patches collection to remove ips and enable HTTPS access => topic for future online collaboration