Results 1 to 25 of 69
Thread: suPHP on a dedicated server
-
10-18-2009, 10:51 PM #1Newbie
- Join Date
- Aug 2009
- Posts
- 29
suPHP on a dedicated server
I'm running a dedicated server (ie my site only) which is primarily a vbulletin powered site.
I was wondering if it is beneficial in running PHP as suPHP along with suhosin?
A lot of articles I see seem to be aimed at shared setups where there are other users with various (possibly) untrusted scripts.
It is a WHM/cPanel managed server which by default is set to run PHP5 as DSO (Apache module).
suexec is installed however this only affect CGI scripts correct?
I recently had a (paid) security audit completed and I asked the question about suhosin. The reply I got was:
You do not need suhosin as you do not run suPHP we enforce posix acl's which will prevent vulnerable scripts from being able to download to the system easily and prevent the automated attacks. You can try this by installing a phpshell and you will see it's not very effective, only php functions are really of any use (such as readfile() and so on) but it will prevent things like wget xxx.
Ta
-
10-19-2009, 08:17 AM #2Disabled
- Join Date
- Apr 2005
- Location
- Cochin
- Posts
- 2,452
if you are looking to track and looking for ore security, my vote definitely goes for running php with suphp.
Like Apache’s own suexec, suphp is a solution that allows PHP to run as the user and group that owns any particular website on a shared hosting server.
-
10-19-2009, 10:32 AM #3Web Hosting Master
- Join Date
- Feb 2006
- Location
- Buffalo, NY
- Posts
- 1,501
It's not really needed though it has its benefits. It will allow you to have more control of each individual website on the machine (if more than one) / have more sane permissions as the processes are ran as the user instead of a generic user/group.
Personally on my own dedicated machines I don't bother - just make sure the permissions on the files are proper and you shouldn't have much of an issue.
One of the more useful things is if a website gets exploited and a little script was uploaded - it makes finding which site it belongs to much faster as it's ran as the user..
**EDIT**
With ACL's it's likely to even be less needed█ Cody R.
█ Hawk Host Inc. Proudly Serving websites since 2004.
█ Official Let's Encrypt Sponsor
-
10-19-2009, 12:48 PM #4Web Hosting Master
- Join Date
- Mar 2008
- Posts
- 1,717
IMHO, suPHP is a double-edged sword. You trade protecting the webserver from itself, for protecting other users from each other. I personally don't see suPHP as being any more secure, it's just easier to audit when something goes bad (whether a security breach or just someone with a greedy script hogging resources).
I really dislike it when people claim that suPHP is "more secure" without any reasoning as to why (because most of the time by the way they talk, I'm inclined to think they're just reciting, rather than understanding).I used to run the oldest commercial Mumble host.
-
10-19-2009, 01:25 PM #5Junior Guru
- Join Date
- Jun 2009
- Location
- Baile Átha Cliath
- Posts
- 186
Other problem with suPHP is that it can be a bit of a pain to setup. For a dedicated server with only one (or possibly two) website(s), i would be more inclined to setup a jailed fastcgi PHP instance (lighttpd seems to prefer this method).
-
10-19-2009, 01:36 PM #6Disabled
- Join Date
- Apr 2005
- Location
- Cochin
- Posts
- 2,452
-
10-19-2009, 01:38 PM #7Web Hosting Master
- Join Date
- Jan 2008
- Location
- St. John's, NL
- Posts
- 2,201
You kidding? We found it dead easy to set up. And while it whether it is more secure on it's own merits, it does force (by default) saner file and folder permissions, which does contribute to making things more secure overall. It's harder to read/write/execute something that is not owned by you or Apache's nobody user.
Cpanel/WHM • PHP • Perl • Ruby • Full Time Support
LCWSoft - Canada web hosting (based in Newfoundland) since 2007
Servers based in the US and Canada (Uptime Report)
-
10-19-2009, 02:01 PM #8Web Hosting Master
- Join Date
- Jun 2003
- Location
- London, UK
- Posts
- 1,765
Have PHP as DSO, run Apache as the same user that the website is under. If you're hosting one website on the system it makes a lot more sense. That way you won't get any permission issues.
suPHP has a big performance overhead.Darren Lingham - Stablepoint Hosting
Stablepoint - Cloud Web Hosting without compromise
We provide industry-leading cPanel™ web hosting in 80+ global cities.
-
10-19-2009, 02:49 PM #9Web Hosting Master
- Join Date
- Jan 2008
- Location
- St. John's, NL
- Posts
- 2,201
For this particular OP, I would recommend the following:
suPHP
mod_security for Apache
good strong passwords for FTP, cPanel, etc.
suPHP performance issues are a myth. We have shared servers, each running 100+ sites, and the difference between DSO and suPHP is negligible. There has never been any concrete evidence to support the myth either.Cpanel/WHM • PHP • Perl • Ruby • Full Time Support
LCWSoft - Canada web hosting (based in Newfoundland) since 2007
Servers based in the US and Canada (Uptime Report)
-
10-19-2009, 02:53 PM #10Web Hosting Master
- Join Date
- Jun 2003
- Location
- London, UK
- Posts
- 1,765
It's not a myth... i've seen it in front of my eyes. Try Magento on a suPHP system compared to DSO... Being able to use opcode caching is also an advantage of PHP as DSO.
A GRsecurity hardened kernel will do a lot more for security than suPHP and mod_security though.Darren Lingham - Stablepoint Hosting
Stablepoint - Cloud Web Hosting without compromise
We provide industry-leading cPanel™ web hosting in 80+ global cities.
-
10-19-2009, 03:04 PM #11Web Hosting Master
- Join Date
- Jan 2008
- Location
- St. John's, NL
- Posts
- 2,201
I can say confidently that it IS a myth. I have one server here (right now) running 250+ moderate traffic sites and the load never goes beyond 20%. Running PHP as a DSO previously, load hovered around 14-15%, making the additional layer of security well worth it.
I wouldn't even use Magento as a metric for determining something like this, as it is beyond bloated and inefficient. Only an opcode cacher would make it run without consuming 100% CPU
When using an opcode cacher, yes there will be a difference. But so would there be from using an opcode cacher vs DSO.
And while GRsecurity is nice, and will aid against root type exploits and arbitrary code execution (such as stack smashing), it won't do squat to prevent a poorly coded PHP site from being defaced by XSS or having access to a file you shouldn't.Cpanel/WHM • PHP • Perl • Ruby • Full Time Support
LCWSoft - Canada web hosting (based in Newfoundland) since 2007
Servers based in the US and Canada (Uptime Report)
-
10-19-2009, 10:56 PM #12Newbie
- Join Date
- Aug 2009
- Posts
- 29
larwilliams, you mentioned that you recommend suPHP for this case however I'm not too sure why exactly given that this is a dedicated box and all the processes running will be mine (ie no other users). If all the file permissions are set correctly wouldn't that be enough to restrict scripts?
What are the thoughts on the second part of my post regarding suhosin and the fact that it is no required since I'm not using suPHP ?
If there are no security benefits (on a dedicated server with only one site) of running PHP as suPHP then I might just stick with PHP as DSO and just double check all the file permissions.
-
10-19-2009, 11:49 PM #13Web Hosting Master
- Join Date
- Jan 2008
- Location
- St. John's, NL
- Posts
- 2,201
I misunderstood the original question. In your particular case, you do not need suPHP. A good php configuration and some tools like mod_security and clamav will be sufficient.
Plus, with PHP as a DSO, you can use eAccelerator, which will help speed up your site considerably.Cpanel/WHM • PHP • Perl • Ruby • Full Time Support
LCWSoft - Canada web hosting (based in Newfoundland) since 2007
Servers based in the US and Canada (Uptime Report)
-
10-20-2009, 12:30 AM #14Web Hosting Master
- Join Date
- Mar 2008
- Posts
- 1,717
... and this is what I'm talking about (unless you didn't mean it this way, it doesn't sound like you did from the entire context, but this specific paragraph says something I don't think you mean) - you do realize that suPHP won't do squat to prevent a poorly coded PHP site from being defaced either, don't you?
XSS will work with/without suPHP, if the code allows it.
All suPHP will do in the event of arbitrary code execution is contain the ownage to that one account. I fully acknowledge that you probably (because you should) know this full well, but I've seen plenty of posts in the same vein as yours and I'm not entirely convinced everyone saying it has any idea what they're talking about.
There are no benefits to having suPHP on a single site on a server. As I stated earlier, suPHP trades off the ability to protect the website from itself, for the ability to protect one website from being owned through the compromise of another account on the same system.
Think about it in this example: the configuration files to a popular web software all must be writable by the webserver for it to function. That's not uncommon.
Without suPHP, the configuration files are likely going to be g+w if the group for the file is www/nobody (that's the way I like to do it in non-suPHP environments, I loathe chmod 777 and cringe every time I see it in instructions). Without suPHP, and without any protection stopping code running in one vhost from traversing to other vhosts, arbitrary code running on the webserver can go through and inject "you've been owned" code in every writable configuration file it can find on the server.
With suPHP, the configuration files are most likely going to be just u+w... with the script running in the context of the user, you can't traverse to other sites and "own" them too... the intrusion is contained to the one site/account at the moment (we're disregarding what happens if someone uploads a shell and continues). However, I've not seen very many people who keep their stuff 555 until they want to be able to write to it, so chances are pretty good that there's going to be a lot more stuff that's u+w than was g/o+w on the non-suPHP example.
I'm not saying that suPHP is a terrible idea - in a shared-hosting environment even if you completely disregard any notion of "security", the ease in administration by being able to track down offensive processes is worth it in and of itself.
If there's only one site on the server, I don't see it being any help at all. My recommendation: scripts running setuid www and setgid www, files in www directory are chown someuser and chgrp www. Make the files you want to writable chmod g+w (note that files created by the webserver will be owned by www:www, a minor annoyance) and then concentrate on things like sanitizing input, mod_security rules, and perhaps something like snort or some other kind of auditing.I used to run the oldest commercial Mumble host.
-
10-20-2009, 12:41 AM #15Web Hosting Master
- Join Date
- Jun 2006
- Location
- NYC / Memphis, TN
- Posts
- 1,454
Per the note from the audit people. I'd recommend tight mod_security rules and reconfigure with FCGId/SUexec.
You'd see some better performance as well.≈ PeakVPN.Com | Complete Privacy VPN | Cloud Hosting | Guaranteed Security | 1Gbps-10Gbps Unmetered
≈ PeakVPN | 31 VPN Servers | 17-Years Experience | Emergency 24/7 Support
≈ Visit us @ PeakVPN.Com (Coming SOON) | ASN: 3915
-
10-20-2009, 12:55 AM #16Web Hosting Master
- Join Date
- Jan 2008
- Location
- St. John's, NL
- Posts
- 2,201
Cpanel/WHM • PHP • Perl • Ruby • Full Time Support
LCWSoft - Canada web hosting (based in Newfoundland) since 2007
Servers based in the US and Canada (Uptime Report)
-
10-20-2009, 08:56 PM #17Newbie
- Join Date
- Aug 2009
- Posts
- 29
I'm not too sure I fully understand how suPHP trades off the ability to protect the website from itself. Could you elaborate or point me to some links which explain this? If the explanation is in your example then I'll have to re-read it (again) and try to comprehend it
That said, would there be any benefit / point in using suhosin with PHP as DSO?
I currently have Apache running as 'nobody' and all files/folders are user:user. Based on the comments above should I be running Apache as say www and then change my files/folders to user:www ?
Also thanks larwilliams for the ClamAV suggestion. I'm actually using x-cache (instead of eaccelerator) with mod_security rules from gotroot.com
-
10-20-2009, 10:16 PM #18Retired Moderator
- Join Date
- Apr 2005
- Posts
- 3,499
I use suPHP because I've found it's the easiest way to let clients run scripts like Joomla, vB, etc, that upload files and not have directories set to be world writeable (777). It's pretty easy to setup on cPanel, and cp-less (that is, if you have apt), and I haven't seen too much of a performance hit.
However, it can be a pain if you try to do anything that isn't considered "standard". We had a lot of issues using JoomlaPack (a popular snap-in backup module for Joomla) with suPHP - but it's worth it when I don't have to go through and clean phishing scripts out of directories.
Alex
-
10-20-2009, 10:20 PM #19Junior Guru
- Join Date
- Jun 2009
- Location
- Baile Átha Cliath
- Posts
- 186
-
10-21-2009, 11:13 AM #20Web Hosting Master
- Join Date
- Mar 2008
- Posts
- 1,717
With suPHP, the scripts are running as the user that owns them. The majority of the time, that user will have write access to almost all the files in his own directory, meaning that any script which is exploitable also has complete write access to all the web content for that site.
Conversely without suPHP, an attacker will only have write access to stuff that the webserver can write to (stuff that's either setgrp nobody and chmod g+w, or chmod 777), which is usually thinner, but does include other peoples' files much of the time, which is the chief advantage to using suPHP. If you have no "other people" there's no real advantage to having suPHP, and there's no fine-grained control of what files/directories the webserver can write to (well maybe you can with two non-daemon users, I'm not sure?) - it can more or less write to everything that's in it's content directories.
That said, would there be any benefit / point in using suhosin with PHP as DSO?
As far as DSO goes, you don't have to run mod_php (DSO) just because you're not running suPHP - in fact if you want to run a threaded webserver I think it's advised against.
I currently have Apache running as 'nobody' and all files/folders are user:user. Based on the comments above should I be running Apache as say www and then change my files/folders to user:www ?I used to run the oldest commercial Mumble host.
-
10-21-2009, 10:55 PM #21Newbie
- Join Date
- Aug 2009
- Posts
- 29
The audit team's comments are in the first post....which I've reproduced below:
You do not need suhosin as you do not run suPHP we enforce posix acl's which will prevent vulnerable scripts from being able to download to the system easily and prevent the automated attacks. You can try this by installing a phpshell and you will see it's not very effective, only php functions are really of any use (such as readfile() and so on) but it will prevent things like wget xxx.
That said, I'm not quite sure how my php scripts are run given that the all php files are user:user chmod 644 with Apache running as 'nobody'. Does this mean that php files are read as opposed to 'executed' ?
Appreciate you time with the replies. Slowly I'm getting my head around it
-
10-22-2009, 06:13 AM #22Web Hosting Master
- Join Date
- Apr 2003
- Location
- San Jose, CA.
- Posts
- 1,624
Daved @ Lightwave Networking, LLC.
AS1426 https:/www.lightwave.net
Primary Bandwidth: EGIHosting (NLayer, NTT, HE, Cogent)
Xen PV VPS Hosting
-
10-22-2009, 08:10 AM #23Web Hosting Master
- Join Date
- Dec 2005
- Posts
- 3,110
If you only have one website on your dedicated server and no other users, there is no real benefit in using SuPHP.
SuPHP is good in a shared environment but its overkill for a single site, and will reduce the performance slightly.
For a single site I would suggest DSO/FastCGI.
-
10-22-2009, 12:11 PM #24Web Hosting Master
- Join Date
- Mar 2008
- Posts
- 1,717
If no other daemons are running as 'nobody', then 'nobody' is Apache's user. 'nobody' isn't really a special account in any way AFAIK, I'm not really sure who chose that name anyway.
That said, I'm not quite sure how my php scripts are run given that the all php files are user:user chmod 644 with Apache running as 'nobody'. Does this mean that php files are read as opposed to 'executed' ?
The only time a script is "executed" from that respect is when you type ./script.php. If you type "php script.php", the script is "read" as far as the filesystem is concerned, but not executed (this is not limited to php, but any interpreted script, and in fact there's games you can play with LD_PRELOAD to execute arbitrary binaries without permission as well). Mounting noexec and/or removing execute permissions doesn't do anything to prevent the execution of something, if they really really want it.
Appreciate you time with the replies. Slowly I'm getting my head around itI used to run the oldest commercial Mumble host.
-
10-23-2009, 03:18 AM #25Web Hosting Master
- Join Date
- Nov 2004
- Location
- Australia
- Posts
- 1,737
What SuPHP (or similar mechanism that executes scripts as the user) does is prevent cross-account privilege escalation. If one account is compromised, it's otherwise easy to use it to check out .php files from other accounts and thus steal mysql passwords, which in turn can give you cpanel passwords (because they're the same) and so on.
However, anyone thinking that the installation of SuPHP by itself automatically makes you secure just is not thinking. There's no single magic solution to security - real security comes only from a matrix of tools and methods in active use. Mod_security (with a small pattern set) and CSF are actually more useful in reducing hacked accounts.
While you're - obviously! - correct about there being little/no performance penalty on the average shared server, there is a case where you will see a performance difference with DSO/mod_php - and that's where a site is really getting pounded very, very heavily. On most shared servers this never happens, and often these sites are bordering on really needing a dedicated server anyway. This accounts for the conflicting reports about performance, but really, most people shouldn't think twice about installing it. It's just too much work tracking down site hacking problems otherwise.
Similar Threads
-
migrating non-suphp server to suphp server
By sharmaine1111 in forum Hosting Security and TechnologyReplies: 4Last Post: 09-06-2009, 12:03 PM -
suphp and php.ini, is there a way to prevent custom php.ini using suphp
By sharmaine1111 in forum Hosting Security and TechnologyReplies: 9Last Post: 08-15-2009, 12:12 PM -
How to tell if server has suphp
By Skeptical in forum Programming DiscussionReplies: 4Last Post: 06-30-2009, 05:32 PM -
Suphp creating 500 internal server error
By ashras99 in forum Hosting Security and TechnologyReplies: 7Last Post: 06-18-2009, 06:25 PM -
suPHP - 500 Internal Server Error
By Green Tea in forum Web HostingReplies: 7Last Post: 04-20-2008, 07:37 AM