general issues

- general server security, see wiki

what is "political webhosting"?

a)- what's different to commercial hosting?

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?

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.


- 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?

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 "", 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:

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.

mod_security can check every uploaded files.

Disable Content Negociation might help with the 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:

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. :D

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.


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.

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

STAMP: MeetingNotes/SecureWebHosting (dernière édition le 2008-12-19 18:59:49 par anonyme)