2

In setting up a hosting environment with multiple sites that should be isolated from each other, I did the obvious step of having PHP be configured so it runs as the user that's associated with each website rather than as the Apache user, but is there some way to be sure there's no way that one site can run a script written in some other language (e.g. Python) as the Apache user? I've seen clever attacks like the symlink attack which uses .htaccess rules and a symlink to trick Apache into serving PHP files from other websites as plaintext (this isn't related to the question, just an example), and since I'm not very familiar with the setup of server-side languages other than PHP, I didn't know what to check and/or prohibit such as via the Apache conf file in order to make sure scripts written in other languages can't be run as the Apache user.

For example, even though PHP is set to run as the website user, if a website got hacked, could the hacker create an .htaccess file which sets .abc files to run as Perl scripts and if things aren't configured properly on the server, then those run as the Apache user?

What's the best way to approach this?

4
  • Look for mod_itk on apache project
    – Navern
    Jul 11, 2015 at 22:22
  • @Navern I like the idea of mod_itk but it's drastically slower than other MPMs and also introduces the possibility that an attacker could gain root access to the server via a single exploit (see "quirks and warnings" section of its homepage at mpm-itk.sesse.net).
    – sa289
    Jul 12, 2015 at 16:49
  • yes, you are right, but it's the best solution for privelege separation. Another try you can run php-fpm with pool per user(however it's not apache and your users can't use .htaccess).
    – Navern
    Jul 13, 2015 at 7:26
  • Too bad MPM perchild isn't supported anymore - I think that at least solved some of the performance drawback.
    – sa289
    Jul 13, 2015 at 20:06

2 Answers 2

3
+50

So your main concern is that compromised one account cannot do anything bad to other accounts.

PHP and file permissions

If PHP is configured to run as different user for each domain, then your directories should set-up such that it doesn't have write access to anything outside its own domain. Then using PHP (or any other commands invoked via PHP) it can't do any harm to rest of the server.

Best practice is to have the scripts be owned by user1, but PHP to run under user2. For customer access, FTP should be configured for user1. User2 should be given write access only to specific directories where really needed (cache dir, generating thumbnails, file uploads via PHP).

But many people start to install Wordpress and other CMS, don't know what to do and give write access to everything (then badly written CMS plugin can compromise all php scripts for that domain). Wordpress and other CMS nowadays support install/upgrade even without write permissions for the PHP process (they just ask for FTP login and automatically use it).

Another best practice is to block direct web access to those directories where user2 has write access. File uploads should be checked by your script, and only if valid, moved to directory accessible from outside (otherwise someone can upload PHP script instead of JPG image and could fool your webserver to execute it).

Apache

Use Apache's AllowOverride None directive to disable usage of the .htaccess file, so that attackes cannot configure running of other CGI scripts. Apache should have only read access to the served files (PHP config files containing passwords don't need read permissions for Apache). With .htaccess disabled, user has no means of changing the Apache configuration.

Use Options -FollowSymLinks (or -SymLinksIfOwnerMatch) to prevent the symlink "attack".

Install mod_security to watch for suspicious activity and block hacking attemps like SQL injection.

EDIT: If .htaccess is needed, you need to decide what options your hosting will support and enable only those. Examples of commonly used options which are safe include (list them in AllowOverride):

  • AuthConfig - to enable Basic HTTP authentification
  • ErrorDocument - to define own URL instead of default for 404 response (as you are defining URL only, only already accessible content can be used, so no risk)
  • Indexes - if you want to enable plain directory listings
  • Limit - to limit access by IP address (usually used by the Deny from all directive to deny access to part of the dirs)
  • RewriteEngine, RewriteOptions, RewriteBase, RewriteCond, RewriteRule - for mod_rewrite
  • SymLinksIfOwnerMatch - needed for mod_rewrite (its documentation states that it needs FollowSymLinks, but it seems it works also with this one); besides mod_rewrite use, Apache would only follow the symlink if the destination file/dir is owner by the same user as the symlink itself.
5
  • I like your idea of different ownership and restricting web access, but a drawback is in some cases it'd require code changes or other additional work. Using AllowOverride None would do the trick for my specific concern, but it'd also disable functionality that devs and content management systems expect to be able to use in .htaccess files, and it'd require higher labor costs which may not be justified if there's a more targeted way to achieve the same result. I'd like to restrict things by the minimum required for good security - is there some way to do that with more targeted restrictions?
    – sa289
    Jun 15, 2015 at 16:10
  • It depends on what functionality you need. You can allow something in .htaccess, but not others. Auth, Indexes and Limit should be safe. ExecCGI, FollowSymLinks, Includes unsafe.
    – Marki555
    Jun 15, 2015 at 21:25
  • is there some list that you know of or that someone's compiled that could advise on this? For example, ExecCGI that you mentioned looks like a good one to block, but I believe AddType should also be blocked to prevent the type of attack I'm concerned about. I want to make sure nothing is missed. Thanks
    – sa289
    Jun 15, 2015 at 21:44
  • I have updated the answer
    – Marki555
    Jun 16, 2015 at 13:51
  • The whitelist approach you gave makes better security sense than the blacklist approach I was looking for - thanks.
    – sa289
    Jun 16, 2015 at 17:04
0

From reading http://httpd.apache.org/docs/2.4/misc/security_tips.html it appears that if suexec is being used properly, then CGI scripts being executed as the Apache user should not be a concern as they will get executed under the user defined by the suexec directives instead.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .