-1

I've setup a web server for production use. The OS is Windows Server, and it runs Apache 2.0 and PHP 5.3 as an apache module (and MySQL too...). It is used to host several virtual hosts (Apache vhosts) belonging to different customers.

At this point PHP is running as the system user. In the future FTP access might be granted to customers, so - by default - every customer would be able to access the whole system through PHP. That is obviously unacceptable.

I understand that I can set open_basedir in PHP, yet I am not sure if it is encompassing and solid enough to be considered a solution - does it limit access on all PHP functions, such as include...? How about PHP streams?

I also know that IIS offers a solution to that problem, but I prefer to keep Apache.

What I would ideally like to set up, is a solution that would fulfill the following requirements (mainly):

  • Be elegant and somehow automatic. I am manually managing the server - I want the setup of each vhost to involve the least amount of setup and configuration editing as possible.
  • Allow for an exception. Most hosted websites are developed by myself, and I'd like to link all of them to a single library folder, so read-only access should be allowed to that folder although it would be outside the root of the vhost.

So, what are the options available, if any? I already did some research and it seems that most work in that field was done on Linux systems.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Rolf
  • 223
  • 2
  • 10
  • 5
    You actually put live customers on WAMP?! This is designed for development, not production. – Michael Hampton Jun 14 '13 at 19:18
  • I have installed Apache on Windows and am using that. What is your source when you say that it is designed for development? Or do you mean those installable bundles... because that's not what I'm using. – Rolf Jun 14 '13 at 19:20
  • 2
    Ah, yes, I was referring to WampServer and similar stacks. Though you have effectively just made your own. – Michael Hampton Jun 14 '13 at 19:21
  • 3
    Apache on Windows is generally regarded as a *Bad Idea* -- it's the literal equivalent of trying to run IIS on Unix. As you've pointed out, the majority of work for/on Apache targets Unix systems. Is there some specific reason you're targeting Apache on Windows? – voretaq7 Jun 14 '13 at 21:28
  • With the exception that IIS doesn't run on Linux, whereas Apache has a Windows port which has been tried and tested over years - but maybe mostly as a development platform. Apache 2 has been coded with portability (including MS Windows) in mind. Anyway the reasons are familiarity with apache config syntax, and the need to translate some .htaccess files (not much, but I'd like to avoid it) should I switch, some bad experiences with setting up IIS and a dislike of it's interface, and last but not least, personal preference! – Rolf Jun 15 '13 at 00:59

2 Answers2

2

PHP and FTP have nothing to do with each other.
FTP is a (lousy, insecure, ancient) way of moving files from machine to machine.
PHP is a scripting language executed by your web server.

You can (and probably should) use the IIS FTP functionality to grant FTP access to your server, while denying your users access to things like the root volume (C:\) and your shared library directory.

The other half of your security problem is PHP itself -- mod_php isn't great at multi-tenant security, and open_basedir is not an all-encompassing solution (though it's better than nothing).

  • If you want real security you pretty much need to give everyone their own Apache, in a chroot.
    This is unpleasant (for you as the admin), but secure. It's also flexible since you can modify php.ini for each site.

  • Your next best option is PHP as a CGI.
    You can call PHP's CGI interpreter as the website owner's user ID - this gives you the benefit of the operating system's file permission functionality, and avoids having to maintain separate Apache/PHP instances for each site.
    The major downside is PHP has to be called as a CGI, so you lose any features that rely on PHP being a web server module.

  • Your third best option is open_basedir and disable_functions/disable_classes.
    open_basedir doesn't really secure anything as it only affects PHP: Your users can still upload/execute a binary to get access to other people's data.
    the disable_functions and disable_classes directives in php.ini let you turn off certain unsafe functions (you're on your own for a list of exploitable classes).

    • Here's the rub though: Those are blacklists and blacklists make for AWFUL security, because if you miss an exploitable/vulnerable function you're still vulnerable to attack.
      You can cover the obvious holes this way, but you're basically the little Dutch boy with his finger in the dike. You've only got so many fingers, and there's always one more hole...

You definitely shouldn't run Apache as Local System (or any account with elevated privileges).
Before putting this server into production ensure it's configured according to the best practices in the Apache documentation.

Community
  • 1
voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • How FTP is relevant here is that customers would have the ability to upload and modify files on my server, therefore they can upload PHP scripts, therefore I must implement some sort of containment so that one customer cannot access the files of another customer through PHP (fopen(), include(), etc.). In this case every customer equals a virtual host. Running apache as a normal user is of course better but that doesn't solve my problem. I'd need to run every virtual host under a different account. I know that is done on Linux; but Windows...? Hence my question. – Rolf Jun 15 '13 at 00:52
  • 1
    @RolfDergham Ah, I misread your question - If your users can upload arbitrary PHP you're pretty much screwed I'm afraid (but I'll update my answer with some possible ways to make yourself *less* screwed). – voretaq7 Jun 15 '13 at 01:38
  • `open_basedir` is also gone with PHP 5.4+, and was removed in large part because people were foolishly relying on it for "security". As for Windows, I wouldn't run a shared web host on Windows at all. – Michael Hampton Jun 15 '13 at 02:00
  • @MichaelHampton Is `open_basedir` gone as well? I know `safe_mode` was deprecated in 5.3 and removed in 5.4 because it was basically ineffective – voretaq7 Jun 15 '13 at 02:25
  • 1
    OK, I was wrong, `open_baesdir` is still there. It was `safe_mode` I was thinking of. – Michael Hampton Jun 15 '13 at 02:26
  • Thanks. "You can call PHP's CGI interpreter as the website owner's user ID": do you have any pointers on how to do that? (directives, etc.), and what about Fast CGI? – Rolf Jun 15 '13 at 02:43
  • @RolfDergham That information would be in the FastCGI documentation (I just know it's possible & FastCGI is the usual way to do it - I don't use FastCGI myself so I'm clueless as to the actual configuration bits you need to twiddle) – voretaq7 Jun 15 '13 at 03:26
0

I have solved that problem with a combination of:

  • Setting open_basedir for each vhost using apache_admin_value in the Apache config
  • Running Apache as a normal user with limited permissions ( @voretaq7 : thanks for the link)
  • Disabling some functions in php.ini: disable_functions = shell_exec, symlink, exec, system, passthu, popen, proc_open

It's by no means the most secure solution but, with regular backups, it should be sufficient for hosting a handful of low-profile websites.

Update (about a year later): This setup saved me - if one can say that in this context. One of my vhosts was an outdated Wordpress installation which got infected. I could see strange temporary files being created in the PHP logs. The vhost was limited through open_basedir, which I presume contained the problem - I'm afraid all my files, and not only the files of this vhost, would have been compromised hadn't it been for that.

Rolf
  • 223
  • 2
  • 10