Results 1 to 10 of 10
  1. #1

    Question php 5 handler dso vs cgi vs SuPHP

    I wanted to ask an advice which php handler is the most secure to have on a shared server:

    dso vs cgi vs SuPHP

    I currently have dso with Suexec on and few accounts are getting phishing sites uploaded so I read that SuPHP is safer. What do you recommend?

    If I do change the server to SuPHP should I enable Suexec as well in the whm: Configure Suexec and PHP?

    Thank you for all your suggestions.

  2. #2
    Join Date
    Jul 2004
    Location
    Reporting Live from Marrz
    Posts
    254
    SuPHP + CGI:

    - somewhat slower output layer than DSO
    - no PHP directives are allowed in .htaccess anymore, must be either in httpd.conf, main php.ini or per-vhost php.ini (the latter by using the suPHP_ConfigPath directive within vhost)
    - more secure than DSO especially with Suhosin extension (Suhosin might require tweaking some of it's directives for some scripts)
    - won't allow http://$IPADDRESS/~username invocations anymore if it's compiled in PARANOID mode, which is preferred and most secure way of running it
    - since you are on cPanel, user 'nobody' can be disallowed to send mails to remote addresses in WHM

    Keep in mind that you will need to check and potentially adjust the suphp.conf after install to keep it fully effective (to name just one as example, the default settings Minimum UID and Minimum GID can be set to whichever number cPanel started creating vhost users from (as you are on cPanel reading your post - 31000 or 32000 or something).

    All in all suPHP is a very good and reliable piece of code, been using it myself whenever possible for quite a while.

    All phishings and exploits won't just go away (some really large percentage will though), it is the exploitable and insecurely coded script that is crucial. What you use to host and protect, the other side uses to test, breach, learn and spread, so keeping those scripts updated, patched or replaced is also a very important component in this matter.

  3. #3
    Join Date
    Mar 2008
    Location
    US
    Posts
    12
    PHP can be run as CGI or as DSO (module). As a module, the PHP runtime is loaded once, when Apache starts up and then reused for all requests. As CGI, a new process is spawned on each request. Obviously DSO only works with Apache, so other servers need to use CGI. (Actually I'm not entirely sure about how true this is). Since DSO is only loaded once, it is quite a bit faster than CGI, but it has some limitations. First of all, you can't have multiple versions of the same module loaded at once, so you can't run two versions of PHP (say 4 and 5) both as modules. CGI doesn't have this limitation.

    Another issue is that since the module is loaded inside Apache, the code is executed as the Apache user (Usually called www). This means that all sites on the same Apache server run under the same user. This is a huge security hazard on a shared host (Where different users are running as virtual hosts under the same Apache installation). PHP's safe_mode feature tries to remedy this on the PHP-runtime level, but it's a very patchy solution. Running PHP as CGI, you can assign different users for each host, which is the proper solution. I'm not sure, by I reckon that suexec is used for launching the CGI version as a different user than Apache, so it's part of the CGI solution, so to speak.

    Another difference between CGI and DSO is that the DSO version has direct access to some Apache-specific calls, which gives you some more fine-grained control on the HTTP-level.

    mod_security has no impact on the other settings, since it's a separate Apache module. It gets run before the PHP handler (CGI or DSO) is invoked. I haven't used mod_security, but I reckon that it's mostly useful for shared hosts.

  4. #4
    Join Date
    May 2007
    Posts
    79
    Could someone quickly tell me the difference between php handlers suphp and cgi?

  5. #5
    Join Date
    Mar 2008
    Location
    kolkata, India
    Posts
    102
    SAPI module that would somehow change the userid of the Apache
    process handling the request to that of the owner of the php file. But it looks to be a hardwired setuid CGI wrapper
    Sysfirm
    So you think your server is secure?
    Try our security Service
    With SysFirm

  6. #6
    It sounds like you are saying cgi is more secure than dso, but add that maybe it uses suexec.

    However we cannot use suexec on one server because of a particular app. (Also suphp won't work with a different app).

    So in that case, which would be more secure as a php 5 handler - cgi or dso?

    Thanks!

  7. #7
    It's really hard to say which is best. suexec / cgi will run PHP as the user who owns the php file. This has the disadvantage that the php script will have all the same permissions as that user, to delete or modify any files owned by that user. In a DSO setup, all the php files are run by "nobody" so only world writable files can be edited by your php scripts. On the other hand, with suexec you can restrict php from reading files owned by other users, and with DSO you're not able to do that. So it's a trade off. Neither is totally secure, they have advantages and disadvantages to each other.

    If you want to talk about performance instead of just security, then FCGI will use a lot less ram under apache than DSO will. In DSO, a copy of php is loaded into each apache client slot. With FCGI, the apache client slots will stay much smaller, and you only have to load as many copies of php as the number of php scripts you're running at any given time. So when you're loading images and things in apache, the apache client handling that image request isn't wasting several megs of ram also having a copy of php built in.

    So FCGI is a good choice for saving ram although the security implications of having php run as an actual user instead of nobody means that your system needs to be secure from malicious users uploading their own php files or exploiting the php files already on the server.
    Phoenix Dedicated Servers -- IOFLOOD.com
    Email: sales [at] ioflood.com
    Skype: funkywizard
    Backup Storage VPS -- 1TBVPS.com

  8. #8

    DSO vs. CGI vs. suPHP vs. FastCGI

    Choosing the right PHP handler for your site is critical. Unfortunately, handlers are often the least understood.

    I researched the different PHP handlers pretty extensively and tested them on large number of servers. I was able to compile together a great description guide with the results.

    It has helped a large number of customers at the web hosting company I work for. I hope it'll help you guy out as well:

    DSO vs. CGI vs. suPHP vs. FastCGI << BoomShadow.net

  9. #9
    Quote Originally Posted by boomshadow View Post
    Choosing the right PHP handler for your site is critical. Unfortunately, handlers are often the least understood.

    I researched the different PHP handlers pretty extensively and tested them on large number of servers. I was able to compile together a great description guide with the results.

    It has helped a large number of customers at the web hosting company I work for. I hope it'll help you guy out as well:

    DSO vs. CGI vs. suPHP vs. FastCGI << BoomShadow.net
    I'm going to have to disagree with a couple of your main points here:

    1) FCGI uses more memory than CGI or DSO: Wrong

    DSO uses more memory than FCGI or CGI because DSO puts a copy of PHP into every apache client slot. Serving up a static file? Yeah, that's going to have a copy of php compiled in.

    FCGI only loads up php for as many copies are required to service your php requests, leaving your apache slots much leaner. The overall memory savings here can be immense, and it will be basically the same as with CGI as well. The tiny bit of memory you save by not immediately killing a copy of php as you would in cgi is almost nothing, and more than offset by the massive cpu savings in not recycling a copy of php for every request.

    2) FCGI / CGI suPHP is more secure than DSO: Not necessarily

    Running scripts as "nobody" is generally more secure than running scripts as the owner of the file, because "nobody" doesn't have arbitrary write permissions to modify files owned by the user. under FCGI / CGI suPHP, where you run as the user, there's nothing you can do to stop a buggy / insecure php script from modifying important files, or editing the webpages owned by that particular user. In a non-shared hosting environment, FCGI / CGI suPHP opens up a really bad security hole with no particular security benefit.

    In a shared hosting environment, there is a tradeoff, that DSO is less secure insofar as one user's scripts reading / messing with another user's files, whereas FCGI / CGI suPHP makes it easier for an external attacker to mess with one particular user's files. Which tradeoff you want to pick is up to you, there's no right answer there. But for a single-user environment, DSO is demonstrably more secure.
    Phoenix Dedicated Servers -- IOFLOOD.com
    Email: sales [at] ioflood.com
    Skype: funkywizard
    Backup Storage VPS -- 1TBVPS.com

  10. #10
    Quote Originally Posted by funkywizard View Post
    I'm going to have to disagree with a couple of your main points here:

    1) FCGI uses more memory than CGI or DSO: Wrong

    DSO uses more memory than FCGI or CGI because DSO puts a copy of PHP into every apache client slot. Serving up a static file? Yeah, that's going to have a copy of php compiled in.

    FCGI only loads up php for as many copies are required to service your php requests, leaving your apache slots much leaner. The overall memory savings here can be immense, and it will be basically the same as with CGI as well. The tiny bit of memory you save by not immediately killing a copy of php as you would in cgi is almost nothing, and more than offset by the massive cpu savings in not recycling a copy of php for every request.

    2) FCGI / CGI suPHP is more secure than DSO: Not necessarily

    Running scripts as "nobody" is generally more secure than running scripts as the owner of the file, because "nobody" doesn't have arbitrary write permissions to modify files owned by the user. under FCGI / CGI suPHP, where you run as the user, there's nothing you can do to stop a buggy / insecure php script from modifying important files, or editing the webpages owned by that particular user. In a non-shared hosting environment, FCGI / CGI suPHP opens up a really bad security hole with no particular security benefit.

    In a shared hosting environment, there is a tradeoff, that DSO is less secure insofar as one user's scripts reading / messing with another user's files, whereas FCGI / CGI suPHP makes it easier for an external attacker to mess with one particular user's files. Which tradeoff you want to pick is up to you, there's no right answer there. But for a single-user environment, DSO is demonstrably more secure.

    My tests have shown otherwise. FastCGI has persistent connections that it leaves open. I often seen where Apache needs to be restarted just to close them all out. This causes a high memory issue.

    The security question you raise is true. It can be argued which is more secure. suPHP and FastCGI will allow a script to have write access to the rest of your account files, letting it corrupt the rest of them. However, the damage is limited to just that one account. It cannot write to any other accounts or system files.

    I personally feel that restoring/cleaning just one account is far easier.

    DSO has the capability that a hacker could compromise more than just the account files, they could get to your system files. Although they are limited in how many they can get, and they typically only go after certain ones, I personally do not want any possibility of anything other than user files getting corrupted.

Related Posts from theWHIR.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •