The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Going over to suPHP

Discussion in 'General Discussion' started by Parcye, May 12, 2008.

  1. Parcye

    Parcye Well-Known Member

    Joined:
    May 19, 2004
    Messages:
    56
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Eindhoven
    Hi,

    After some problems with permissions and exploits I want to make the step to suPHP.

    But as the server is now finaly up and running again and I don't want to put people through more outages, I want to be very well prepared before I go over to suPHP.

    I found some howto informatio, but that is back from halfway into 2006 (2 years ago thus). As much has happend since in the WHM/cPanel world I was wondering if somebody can provide me from accurate information and point out some things not to forget and to keep an eye on.

    Thank you.
     
  2. MattDees

    MattDees cPanel Product Owner
    Staff Member

    Joined:
    Apr 29, 2005
    Messages:
    417
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    Generally, moving over to SuPHP is painless, there are (as you know) a few pitfalls:

    The first thing I would keep my eye open for, is the fact that SuPHP will not execute scripts, or script inside of directories with world or group writable permissions. Before moving, I would advise running "find /home -name '*php" -perm 777" to see what will no longer execute. You can add "| xargs chmod 755" to the end of this command to automatically change these, but this is not always advised.

    The other thing that you need to keep your eye open for is .htaccess files and php.ini's. You cannot have php_flag or php_value in .htaccess files with SuPHP. Rather you will need to put "SuPHP_ConfigPath /path/to/php/ini" inside of the .htaccess and then create a php.ini with the desired values in it.
     
  3. electron33

    electron33 Well-Known Member

    Joined:
    Feb 24, 2004
    Messages:
    90
    Likes Received:
    0
    Trophy Points:
    16
    Thanks a lot Matt.

    I'd appreciate if there're any other potential issue you or anyone else can share.
     
  4. verdon

    verdon Well-Known Member

    Joined:
    Nov 1, 2003
    Messages:
    836
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Northern Ontario, Canada
    cPanel Access Level:
    Root Administrator
    File ownership is also important. If there were scripts that were uploading things (like images) before, they will likely be owned by 'nobody'. You need to change these to the user in question.

    I used these commands to change ownership and fix permissions. I was not as cautious as Matt
    Code:
    chown -R username:username /home/username/public_html/* ;
    find /home/username/public_html/ -type d -exec chmod 755 {} \;
    find /home/username/public_html/ -type f -exec chmod 644 {} \;
    
    Also, if you use a local php.ini file, it will over-ride all your custom settings in the global php.ini file and not just the one or two local directives. So, be sure to copy over any other custom settings from the global php.ini to a local one.
     
  5. mtindor

    mtindor Well-Known Member

    Joined:
    Sep 14, 2004
    Messages:
    1,281
    Likes Received:
    37
    Trophy Points:
    48
    Location:
    inside a catfish
    cPanel Access Level:
    Root Administrator
    SuPHP can have an adverse effect on performance - at least in my experience. Of course, I run SuPHP on all servers regardless. it makes perfect sense. But just be aware that web delivery of content may not be as robust if you are running SuPHP.

    mike
     
  6. verdon

    verdon Well-Known Member

    Joined:
    Nov 1, 2003
    Messages:
    836
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Northern Ontario, Canada
    cPanel Access Level:
    Root Administrator
    Same experience for me. For me, the cause was actually that you can't use eaccelorator or other php accelorators when using suphp.

    However, I upgraded my hardware and the performance issue isn't really discernible anymore. Mike's right though, if you have an older cpu and smaller amount of ram, you're really going to notice the difference.
     
  7. adapter

    adapter Well-Known Member
    PartnerNOC

    Joined:
    Sep 17, 2003
    Messages:
    391
    Likes Received:
    0
    Trophy Points:
    16
    is there any way to use SuPhp with FastCgi? i am try SuPhp on my Quad Core server and i see that all the Php process have a high cpu Usage, someone reach also 40% of usage, any way to optimize it?
     
  8. mambovince

    mambovince Well-Known Member

    Joined:
    Jan 15, 2005
    Messages:
    192
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    London, UK
    Hi,
    Also considering SuPHP
    Would you mind explaining what those 2 commands actually do, and can they be run server-wide instead of one account at a time?

    Many thanks,

    - Vince
     
  9. verdon

    verdon Well-Known Member

    Joined:
    Nov 1, 2003
    Messages:
    836
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Northern Ontario, Canada
    cPanel Access Level:
    Root Administrator
    The first one finds all items in /home/username/public_html/ that are of the type directory and then executes chmod 755 on them. The second command does something similar for files.

    You could use a small shell or perl script to do it server-wide, but I don't have an example at hand and am not smart enough to do it off the top of my head. If I find an example, I'll post back :)
     
  10. rustelekom

    rustelekom Well-Known Member
    PartnerNOC

    Joined:
    Nov 13, 2003
    Messages:
    290
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    moscow
    It's a big security hole. Any user can change main php settings and completely lost security settings which set by server admin. I had inform about this Cpanel team about year or more ago and for unknown reason your team ignore this warning. Not all WHM users has a experience to manually recompile suphp with correct settings and i don't know why Cpanel team ignore such important problem. It's require only one directive in suphp module code to be changed and may take about minute or less to get suphp work securely.
    Without such correction suphp main idea (security) just absolutely lost and user who are used suphp just alive with open securty hole (and it is too big to just ignore it).
     
  11. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    That is simply untrue. Firstly, you're only complaining about one part of suPHP which, there are other aspects that greatly improve server security. Secondly, If you want to prevent users from using their own php.ini files you can simply follow the recommendations in cPanel's own documentation and enable the global only php.ini files through /opt/suphp/etc/suphp.conf
     
  12. rustelekom

    rustelekom Well-Known Member
    PartnerNOC

    Joined:
    Nov 13, 2003
    Messages:
    290
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    moscow
    untrue what? I can give you real server where unexperienced admins just don't know about this hole. They select suphp option and sure they are now safe - which is not true at all.

    you can tell me that they need read manual etc. and i agree with you but fact is fact - in most times they just select option, compile php and that all. At least you need inform they about problem in settings.

    Way which you offer to get suphp settings secured is correct but when we follow it we will lost great suphp feature - we cannot customize php settings per user basis.

    Both option is bad - and it is not dilemma - go with security or with customizing, we already have third way and it give us both feature and without any compromise.
     
  13. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    I think you're confused; the fact that users can have php.ini files doesn't mean suphp is insecure, that's actually a feature.

    With suphp you aren't as reliant on PHP features being locked down by the system php.ini. As users are effectively locked into their own home directories, it doesn't matter as much that they can change their php.ini files. A server with suphp is still an order of magnitude more secure than a server without it.

    If you can provide a specific concrete example of how this was a problem in real life (other than users "not knowing about it") I'd be more than happy to discuss it and/or be proven wrong.

    An important point to make is that suphp isn't instant perfect security - there is no such thing. While suphp helps a lot, it only improves security in a number of areas. Suphp is best coupled with other tools as part of an overall security strategy - such as the excellent mod_security and CSF firewall for starters.

    BTW, if you run a high performance server with heavy hits, a good strategy is to restrict the users to highly trusted accounts and then you could remove suphp. But I'd always run suphp on a normal shared web server. High security = low maintenance = low costs of management.
     
  14. rustelekom

    rustelekom Well-Known Member
    PartnerNOC

    Joined:
    Nov 13, 2003
    Messages:
    290
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    moscow
    "I think you're confused; the fact that users can have php.ini files doesn't mean suphp is insecure, that's actually a feature."

    it is feature which should be controlled by sysadmin. Very simple example:

    What you will do if customer edit his php.ini like shown below:

    php_safe_mode = off;
    disable_function = ;
    open_base_directory = /;

    Hah? Your server will open for hacking at least by using php. Customer can set timeouts as big as he want (and his php scripts never limited by your limits). You completely lost admin control on php settings etc. Am i need show you how such php settings may used for run phpshell or exploits?
    Feature is nice but usage of this feature need to be controlled by system admin. Current situation is not right from all point of view. It make great suphp module as old phpsuexec which was is terrible for security.

    And regards percentage of customizing. You are not correct with your mention about our settings:).
    You should understand that at least few common php settings used by scripts developers oppositely. For example directive mime_magic_quote_gpc. Some scripts work perfect with On value and some only work with Off value. Sometimes customer need bit a more memory limits than others, sometimes he need bit a more time to run their script. Do you like refuse customer only due to fact that you cannot change this very very simple setting? I think no.
     
  15. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    Ah - I see, the source of your confusion :)

    Just because they can change these settings does not leave your server open for hacking under suphp, whereas without suphp there would have been things they could see that they shouldn't have been able to see. In other words, relax, the impact just isn't there with suphp.

    True, but I don't see this as such a big issue as a basic server check or CSF will show me long running processes.

    Yes, but calm down a little :) they can't upload files unless there are other security issues; ie you have incredibly insecure scripts; and if you have those, the PHP settings should really be the least of your concerns as there will be other things they can do. Again, mod_security along with CSF is the best way to change these, not disabling PHP so tightly that every customer needs a different set of PHp settings!

    Maybe I'm not right about your settings, but I'm right about mine. I'd say you have too many things locked down, making your PHP unusable.

    Huh? I never said I'd refuse the customer the ability to change those things. I said they could change these things themselves. Easy. And if set up right, they rarely need to change them.

    It's a matter of knowing where security matters, and where it doesn't, and I'm not convinced you've been able to make that distinction yet. I'm not meaning that in an unkind way, it simply takes time to get enough experience to understand what is important and what is not, and it helps if you know what "hacking" actually is. You're not being ignored; it's simply that your requests don't make logical sense and you haven't yet understood that.

    In my opinion where you're focussing your energy isn't where you're going to get the greatest security benefit. PHP.ini settings won't protect you from many insecure scripts (although perhaps they could save you from some). Mod_security will save you from some, CSF will block people probing, and suphp will lock hackers into their own home dir and make it obvious who runs what scripts.
     
    #15 brianoz, Sep 16, 2008
    Last edited: Sep 16, 2008
  16. UBERHOST

    UBERHOST Well-Known Member

    Joined:
    Jan 13, 2008
    Messages:
    102
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    California, US
    Inexperienced server administrators will always be a source of security holes. To blame it on suPHP would be like blaming airbags for accidents since they give inexperienced drivers a false sense of security.
     
  17. closet geek

    closet geek Well-Known Member

    Joined:
    Mar 19, 2004
    Messages:
    46
    Likes Received:
    0
    Trophy Points:
    6
    So what is this third way?
     
  18. blargman

    blargman Well-Known Member

    Joined:
    Sep 11, 2007
    Messages:
    99
    Likes Received:
    0
    Trophy Points:
    6
    suPHP is a good deal slower than DSO or fastcgi. I would recommend fastcgi over suphp if you want the scripts to run as the user. suPHP is ok for security but having php run as nobody in my opinion is better than giving it user level rights. There are other methods for securing php, mod_security/suhosin, disabling unneeded insecure functions.

    Ideally someday I'd like to see something in the way of chroot'd apache configurations for each domain. This would offer the best security although may be a bit more performance heavy.
     
  19. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    I guess it depends on whether your priority is performance or security.

    You'll never get as complete security at an application level - it's just bolted on. When you run as the user, there is no way around the file system permissions, there's no escaping that it's far more solid than a few checks in the application.

    Having said that, if performance is critical it's probably because there are heavy load sites and it should be easy enough to move them off to a restricted box (ie a few heavy users) and run as DSO to get the performance. Though app design can help there's no escaping that CGI has to be far, far slower.

    The problem with disabling unneeded functions is that they often end up being needed!
     
  20. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    I missed responding to this very intelligent and well made point which does make a lot of sense on the surface.

    The problem with running PHP as nobody is, if the PHP (application level) restrictions are broached, the baddies have access to database usernames and passwords across all accounts on the server, which is earth shatteringly bad for security on that server. Application level protection will always be able to be broached on way or another by someone who is persistent enough or smart enough. The issue here is that "nobody" isn't actually a nobody here, it's an account that has access to all user application files on the server, and has to have that access by design!

    Like anything it's a tradeoff; I'd guess it might be as much as an order of magnitude slower than pure DSO, and 2-5 times slower than fastcgi, and the figures could be worse! I dunno - I'd never run an open-access shared server without this level of security, I just see it as a minimum. If I need higher performance then I could move clients needing it to a DSO server.
     
Loading...

Share This Page