Command Center

Hmm looks like the only way to be fairly secure in a shared environment (unless I want to disable cgi/perl access to customers) is to run suexec or suphp and use Suhosin to control disable_functions per user and set open_basedir.

I also found an interesting page about vhosts and php/perl setups
http://lists.evolt.org/archive/Week-of-Mon-20030714/145126.html

I also found an interesting page about vhosts and php/perl setups
http://lists.evolt.org/archive/Week-of-Mon-20030714/145126.html

It's not completely true with suPHP. Here are my reasons why to use suPHP rather than normal PHP as Apache module :

- You can run PHP4 and PHP5 on the same account (great sales feature).

- You can make one file per version per customer (means on for php4 and one for php5), so you are able to control disable_function for all users, and allow some special function for one customer that could ask.

- You can off course control open_basedir for each user, so easly close them inside a single directory, their own.

- You can harden security by storing each user sessions into is own directory, so in case permission would be set wrong nobody would be able to play with, no like if they are in /tmp.

- You can offer to one customer eAccelerator, and not to other that don't wish.

- You can control which security level you want to apply per user like with Suhosin, or other kind of system.

- You don't need to write the line "#!/usr/bin/php", you simply put your php files in your public_html/private_html and the system does the rest.

- You can even play with ressource per user since they are leaded from that little php.ini file, so you can give more memory to one user without changing the behaviour of your whole system.

- You can EVEN handle PERL from suPHP, so you are completely free to manage what you want, the way you want.

- You will also not have to chown users file generated by apache that they cannot delete by themself, such as image generator system.

Now, if you are still undecided, you should consider that one of the most important hosting provider in France (OVH) uses PHP4/5 as CGI with suPHP (and some home-made hacks I guess), and they do host more website than you will ever.

-> http://60gp.ovh.net/test.php
-> http://60gp.ovh.net/test.php5

So, now you can make your choice.

Well I'm just trying to come up with a plan that will let me leverage security/speed/ host a certain amount of sites while also being able to have larger/busier sites on the server.

If I had a huge budget for super servers with seperate db and mail servers then I wouldnt be worrying about the overhead created by suphp.

Any suPHP won't break the current PHP, so you can switch for a few days and go back to PHP as Apache module if you see much higher load, but if you switch to suPHP you won't come back to PHP as module ;-)

Any suPHP won't break the current PHP, so you can switch for a few days and go back to PHP as Apache module if you see much higher load, but if you switch to suPHP you won't come back to PHP as module ;-)

Thanks.

I only got a few more days to figure it out before I need to move my customers sites to the new server.

Thanks.

I only got a few more days to figure it out before I need to move my customers sites to the new server.

Ok. In case you would run into trouble just PM me.

One word of caution with running suphp - make sure you have enough memory as you will need at least one php process running per customer.

This is my setup

Intel(R) Pentium(R) D CPU 3.40GHz with 2 gigs of RAM/raid 1/DirectAdmin.

I'm mostly hosting smaller sites and no reselling. Probably wont go higher then 100 sites on the sever, depending of how much resources are used. Obviously would like to be able to host larger sites and not worry too much about having customer sites grow with out issues.

Suhosin and SuPHP aren't really two things that can be compared to each other, for the simple reason that they don't do the same JOB!

SuPHP:
Requires scripts to run as the user. This doesn't FIX anything, it doesn't STOP vulnerable scripts from running, it doesn't FIX leaks, it simply requires a script to run as the user.

The benefit? If the user can't do something, the script can't. However, the user will STILL be able to download (and execute) a number of vulnerable applications, such as perl DDOS scripts, and a variety of other things that COULD ultimately get them access.

The drawbacks?
A> suPHP does not support the php_value/php_admin_value directive
B> suPHP itself has no support for code highlighting (sorry, no .phps)
C> mod_suphp in most cases will *NOT* work, when mod_php is installed (one or the other)
D> WILL break scripts if directory permissions are not set right, even IF the script is coded properly

Suhosin:
Fixes a LOT of the holes in php, shores various things up and keeps things somewhat secured.

The benefit? Many times (not all), vulnerabilities are stopped with suhosin, simply because the attacker is trying to take advantage of certain parts of php which are known to be flawed, through certain scripts. Unlike SuPHP, Suhosin STOPS many of these attacks dead on.

The drawback?
A> Will break SOME scripts if they are not properly coded

Nothing you install like this will work perfectly without screwing up someone's website. Eventually, you're going to get something broken, and have to fix it. This is part of life. Dealing with it is key

The point in enabling something like this is to provide as MUCH functionality to users as possible while actually providing secure services, and causing THEM as little pain as possible.

For advanced users that actually use php values for whatever reason in .htaccess, BOTH suphp AND phpsuexec will break sites and cause very upset individuals. Now, yes, there's a way around that, but the idea, again is to inconvenience the customer as little as possible while providing secure services.

Disabling functions should only be done if absolutely necessary, and honestly, it rarely is. Again, this will only drive customers away from your business and to others, when those functions are necessary.

The FreeBSD port of PHP now includes the suhosin core patch by default.

I'm running it alongside suPHP. No harm in having both!

Kev

So with out running suphp/suexec how do you prevent perl scripts from accessing other world writable files in the user directories? Especially when using a control panel like DirecAdmin or Cpanel.

Suhosin and SuPHP aren't really two things that can be compared to each other, for the simple reason that they don't do the same JOB!

SuPHP:
Requires scripts to run as the user. This doesn't FIX anything, it doesn't STOP vulnerable scripts from running, it doesn't FIX leaks, it simply requires a script to run as the user.



This is a one sided argument that is completely invalid. You just said they're not comparable products yet you are comparing them.....

PHPsuexec/suphp is being used in large environments without breaking scripts or troubling users with .htaccess issues. With proper planning you can easily migrate over and existing non phpsuexec environment to one. Any values in .htaccess can easily be sent into php.ini - issue fixed.

Secondly, you don't seem to have any experience with security. You're basically telling us that 777, world writable scripts, are fine as long as we're using magical Suhosin? Sorry but no, anything 777 is a major security risk since anyone on the server can write to that file, using PHP or not.

Suphp/PHPsuexec attempts to correct this and does a good job stopping users from wildly creating 777 directories and files. There are many different exploits that users are running on a shared environment which take advantage of these writable files, they go into users directories and change all the contents.

EG: Mass iframe defacements on users pages

Any host or client for that matter needs to understand that suhosin will still not help 777 permisions. Like you said, they are completely different products which deal with different issues.

suhosin attempts to correct PHP based flaws at the code level, IE holes in PHP source. While phpsuexec attempts to correct issues at the file level.

So with out running suphp/suexec how do you prevent perl scripts from accessing other world writable files in the user directories?

phpsuexec has nothing to do with perl
Yes, running the script as php with phpsuexec WILL save this to the user's name, but that's all. Big deal. That does absolutely NOTHiNG to prevent the initial problem (the user getting the vulnerability.


This is a one sided argument that is completely invalid

Hardly invalid. Just because you don't like the "argument", because it doesn't actually make SENSE to you that phpsuexec (and suphp) are BAD and BREAK SITES for no reason other than .htaccess modifications and symlinks is NOT my fault.


Any values in .htaccess can easily be sent into php.ini - issue fixed.

Wrong. Just because you can't understand that doesn't make it RIGHT, but yes, that scenario and situation is WRONG.
NOT every situation is the same, and NOT everything needs to be added to php.ini the same.

Example:
I have a number of sites under the same username for convenience. Each site has their own .htaccess storing sessions in separate directories, with separate session lengths, times, etc. This is done via .htaccess. Now, yes, I COULD rewrite the script to fit suphp, but that's just the point. Why should the USER have to rewrite their entire website because of one poorly designed "security enhancement"? They SHOULDN'T


Secondly, you don't seem to have any experience with security.

Not at all. The opposite in fact Just because I don't like one of the most intrusive php alternatives (it's not even php) out there doesn't mean I have "no experience with security", but that I have a different method of handling things.


You're basically telling us that 777, world writable scripts, are fine

AM I now? Or are you reading something that I have never ever said ? No, the SECOND is true, not the first.
Of COURSE 777 is bad. I've never, ever, ever said otherwise.
What I HAVE said repeatedly is that adding something like phpsuexec/suphp DOES and WILL screw up VALID code and VALID client setups because IT thinks it's God and everything must act as the way IT wants, whether that is right or wrong.


There are many different exploits that users are running on a shared environment which take advantage of these writable files

Again, agreed.
The difference? Suhosin will STOP most of these exploits dead on, because they take advantage of various flaws in php. Suphp will allow the users to continue to download the exploit, only set it as THEIR username. Why run the risk of even allowing the user to download the exploit?


suhosin attempts to correct PHP based flaws at the code level, IE holes in PHP source

And you clearly haven't USED suhosin at all, or you'd know the level at which this does this.
Suhosin not only patches php vulnerabilities which is a good thing, but it sets LIMITS on certain things, such as _POST and _GET length, patches the php setup itself to "harden" it, and PREVENTS most of the typical attacks out there.

Whatever method you choose, this isn't the end all and be all of security. Security is about knowing what is going on with your servers, whether that be through logs, active processes, whatever you may have, and acting on this information. Mod_security is a decent thing to add to your servers, if you can get a ruleset that is actually WORTH something (that doesn't load a server down), suhosin is a great addition to this layer of security, as is CSF & LFD (http://www.configserver.com/cp/csf.html). There are plenty of ways to lock down and secure a server WITHOUT breaking client's scripts here.

phpsuexec has nothing to do with perl
Yes, running the script as php with phpsuexec WILL save this to the user's name, but that's all. Big deal. That does absolutely NOTHiNG to prevent the initial problem (the user getting the vulnerability.

I didnt say it had anything to do with PERL.


Again, agreed.
The difference? Suhosin will STOP most of these exploits dead on, because they take advantage of various flaws in php. Suphp will allow the users to continue to download the exploit, only set it as THEIR username. Why run the risk of even allowing the user to download the exploit?

It will stop php related exploits but since you're not using suphp/suexec your files will have to have to be world writable for lots of scripts to function which now can be accesses with exploited/hacked PERL scripts.

My question is how do you minimize or eliminate PERL from being able to access other users files. Do you eliminate cgi-bin access to you customers or only offer it if they ask you for it?

My question is how do you minimize or eliminate PERL from being able to access other users files. Do you eliminate cgi-bin access to you customers or only offer it if they ask you for it?It's the underlying file system permissions and what user is allowed to run the perl script that allows perl to get access to other users' files. If you run suexec, Perl runs as a user and doesn't have generic access. If you don't run suexec, perl scripts run as nobody and thus get access to most of the server users' files.

How about cgiwrap for running perl scripts and using suhosin/open_basedir/disable_functions for php security.

Gotta correct some misinformation in your post.

- You can run PHP4 and PHP5 on the same account (great sales feature).

You can do this with mod_php and FastCGI, to do both at the same time. It's what we do to add on PHP 5 support, but still keep 4 around as the default since most people still use scripts that don't work in 5.

- You can make one file per version per customer (means on for php4 and one for php5), so you are able to control disable_function for all users, and allow some special function for one customer that could ask.

- You can off course control open_basedir for each user, so easly close them inside a single directory, their own.

- You can even play with ressource per user since they are leaded from that little php.ini file, so you can give more memory to one user without changing the behaviour of your whole system.

You can control these in the virtual host for a user with a php_value command. cPanel actually has the open_basedir stuff built right in to Tweak Security and I recommend enabling it for any server, since it prevents worms that replace or alter files from running.

- You don't need to write the line "#!/usr/bin/php", you simply put your php files in your public_html/private_html and the system does the rest.

You don't need to do this in mod_php, so I don't see why its an advantage... :confused:

Other than that, you're spot on. But I'd choose FastCGI over suPHP any day of the week. Keeps the speed up while still getting the advantages of SuExec. You can combine Suhosin for the best of both worlds.

I think I must also clarify,


You can do this with mod_php and FastCGI, to do both at the same time. It's what we do to add on PHP 5 support, but still keep 4 around as the default since most people still use scripts that don't work in 5.


Are you telling us that you run both PHP version as Apache module, without using suPHP at all ? I have seen for keeping PHP4 as CLI but I haven't seen a way for keeping both version without a handler. In case you can run both PHP version side to sided without a handler, explain me how.


You can control these in the virtual host for a user with a php_value command. cPanel actually has the open_basedir stuff built right in to Tweak Security and I recommend enabling it for any server, since it prevents worms that replace or alter files from running.


Yes, I know that most known panel have php_value/flags/and sendmail stuff inside the user' httpd.conf, but you cannot offer specific memory allocation to one user, or enable special functions as easily as building a php.ini for each customer. Moreover, the security that you can handle with suPHP is much higher. Clearly with PHP as Apache module, you cannot offer on requesr feature to one user, or you must lose security control, by offering the functions to all other users.


You don't need to do this in mod_php, so I don't see why its an advantage... :confused:


Please, when you want to come and add your remarks to a post read it from the beginning. I won't be saying this just so. It was an answer to a remark posted before.

linux-tech, easy now, jeez. I still find it funny how thousands of providers are using suphp/phpsuexec without any problems, except for you.... hmmm

If you want to be on a crusade for Suhosin by all means go for it. I understand it very well, it doesn't do anything special. I also believe the developer of the software/patch is a little cocky as well as he stated in the forums it will be a replacement for mod_security.


So with out running suphp/suexec how do you prevent perl scripts from accessing other world writable files in the user directories?

Because phpsuexec/suphp limits write access to the owner only and not world writable like regular PHP does. Again Suhosin doesn't offer protection on this....

The difference? Suhosin will STOP most of these exploits dead on, because they take advantage of various flaws in php. Suphp will allow the users to continue to download the exploit, only set it as THEIR username. Why run the risk of even allowing the user to download the exploit?

No it doesn't, that's a joke. You don't just need PHP to play with someones 777 files in another users directory and Suhosin won't stop it. Yes, it MIGHT stop a few functions trying to exploit things in PHP like open_base or something else but big deal. The fact is Suhosin is still allowing 777 directories and files which ARE the security risk in the first place....

Also there shouldn't be a patch for things like open_base flaws in the PHP core anyways, this is the responsibility of PHP.net to fix.... which they have in PHP 4.4.5
Problem solved, no Suhosin needed. See the PHP change log http://www.php.net/ChangeLog-4.php#4.4.5

And you clearly haven't USED suhosin at all, or you'd know the level at which this does this.
Suhosin not only patches php vulnerabilities which is a good thing, but it sets LIMITS on certain things, such as _POST and _GET length, patches the php setup itself to "harden" it, and PREVENTS most of the typical attacks out there.

That's what I just said....,It protects flaws at code level. I have used it and it doesn't protect from c99 shells and all their functions without a log of any malicious activity in site.

At it's current state, I believe Suhosin is far too young to make viable on production servers. If they start to get external rulesets then it may be a better option. Personally I find it useless right now.

/ End of argument.

Are you telling us that you run both PHP version as Apache module, without using suPHP at all ? I have seen for keeping PHP4 as CLI but I haven't seen a way for keeping both version without a handler. In case you can run both PHP version side to sided without a handler, explain me how.

I said I was using FastCGI, which is what we run PHP 5 through. People just add an AddType line in their .htaccess file or name their scripts .php5 to use it.

Yes, I know that most known panel have php_value/flags/and sendmail stuff inside the user' httpd.conf, but you cannot offer specific memory allocation to one user, or enable special functions as easily as building a php.ini for each customer. Moreover, the security that you can handle with suPHP is much higher. Clearly with PHP as Apache module, you cannot offer on requesr feature to one user, or you must lose security control, by offering the functions to all other users.

memory_limit and disable_functions work just fine in a virtual host. And you don't have to create separate files for each user. You just edit the one Apache config and that's all there is to it.

memory_limit and disable_functions work just fine in a virtual host. And you don't have to create separate files for each user. You just edit the one Apache config and that's all there is to it.

But can you handle the PHP memory limit and functions limitation for one, and only one user directly inside it's httpd.conf ? That's my question.