Page 1 of 3 123 LastLast
Results 1 to 25 of 69
  1. #1

    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.
    Should I recompile Apache (via EasyApache) with suPHP and suhosin or just leave as is?

    Ta

  2. #2
    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.

  3. #3
    Join Date
    Feb 2006
    Location
    Buffalo, NY
    Posts
    1,501
    Quote Originally Posted by egsi View Post
    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:



    Should I recompile Apache (via EasyApache) with suPHP and suhosin or just leave as is?

    Ta
    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

  4. #4
    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.

  5. #5
    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).

  6. #6
    Join Date
    Apr 2005
    Location
    Cochin
    Posts
    2,452
    Quote Originally Posted by RemyHorton View Post
    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).
    Easyapache makes the suphp enabling a very simple process. Even if its plesk, its just an rpm away

  7. #7
    Join Date
    Jan 2008
    Location
    St. John's, NL
    Posts
    2,201
    Quote Originally Posted by RemyHorton View Post
    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).
    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)

  8. #8
    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.

  9. #9
    Join Date
    Jan 2008
    Location
    St. John's, NL
    Posts
    2,201
    Quote Originally Posted by dazmanultra View Post
    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.
    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. #10
    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.

  11. #11
    Join Date
    Jan 2008
    Location
    St. John's, NL
    Posts
    2,201
    Quote Originally Posted by dazmanultra View Post
    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.
    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)

  12. #12
    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.

  13. #13
    Join Date
    Jan 2008
    Location
    St. John's, NL
    Posts
    2,201
    Quote Originally Posted by egsi View Post
    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.
    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)

  14. #14
    Join Date
    Mar 2008
    Posts
    1,717
    Quote Originally Posted by larwilliams View Post
    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.
    ... 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.

    Quote Originally Posted by egsi View Post
    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.
    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.

  15. #15
    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

  16. #16
    Join Date
    Jan 2008
    Location
    St. John's, NL
    Posts
    2,201
    Quote Originally Posted by fwaggle View Post
    ... 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.
    Yes, i realize that completely. I misunderstood the OP and thought he'd have 2 or more sites on the same server. A mistake on my part.

    I agree with you on all points of securing his stuff too
    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)

  17. #17
    Quote Originally Posted by fwaggle View Post
    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.
    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?

    Quote Originally Posted by fwaggle View Post

    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 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

  18. #18
    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

  19. #19
    Join Date
    Jun 2009
    Location
    Baile Átha Cliath
    Posts
    186
    Quote Originally Posted by larwilliams View Post
    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.
    I tried and failed on several occasions to get v0.6 working, so ended up using v0.5 instead (in both cases, i built from source). Not tried v0.7 as last time i built a webserver i used lighty instead of Apache.

  20. #20
    Join Date
    Mar 2008
    Posts
    1,717
    Quote Originally Posted by egsi View Post
    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
    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?
    I don't know enough about suhosin, I do know that FreeBSD's ports system applies it by default, but I've also read of drawbacks to it. What'd your audit company say about it?

    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 ?
    No, "www" is just what Apache runs as on my machines - it could be anything. "nobody:nogroup" is fine as long as no other daemons are sharing that uid that could lower security. It looks less confusing having files chmod user:www than it does chmod user:nogroup, to know that the webserver has access to them... but that's the only reason I'd change it - with one site on the server it's probably not even worth it.
    I used to run the oldest commercial Mumble host.

  21. #21
    Quote Originally Posted by fwaggle View Post
    I don't know enough about suhosin, I do know that FreeBSD's ports system applies it by default, but I've also read of drawbacks to it. What'd your audit company say about it?
    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.
    Quote Originally Posted by fwaggle View Post
    No, "www" is just what Apache runs as on my machines - it could be anything. "nobody:nogroup" is fine as long as no other daemons are sharing that uid that could lower security. It looks less confusing having files chmod user:www than it does chmod user:nogroup, to know that the webserver has access to them... but that's the only reason I'd change it - with one site on the server it's probably not even worth it.
    Cheers. What I actually meant by 'www' was should I run apache as a user (as opposed to 'nobody').

    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

  22. #22
    Join Date
    Apr 2003
    Location
    San Jose, CA.
    Posts
    1,624
    Quote Originally Posted by fwaggle View Post
    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).
    On the contrary, I really like it. It easily classifies them as what I term "sheep-hosts".

    IMHO, There's NO good reason to use suPHP.
    There are better alternatives that do exactly the same thing without the HORRIBLE performance hit suPHP creates.
    Daved @ Lightwave Networking, LLC.
    AS1426 https:/www.lightwave.net
    Primary Bandwidth: EGIHosting (NLayer, NTT, HE, Cogent)
    Xen PV VPS Hosting

  23. #23
    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.

  24. #24
    Join Date
    Mar 2008
    Posts
    1,717
    Quote Originally Posted by egsi View Post
    Cheers. What I actually meant by 'www' was should I run apache as a user (as opposed to 'nobody').
    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' ?
    "Executed" is a murky concept on UNIX-like OSes, particularly with scripts - something that people who knee-jerk mount /tmp noexec "to prevent hacking" would do well to remember.

    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 it
    No problem, I just wanted to be a dissenting voice to what I was sure would be hordes of people going "lol install suphp or you'll get hacked".
    I used to run the oldest commercial Mumble host.

  25. #25
    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.

    Quote Originally Posted by larwilliams View Post
    [speaking re suphp performance] 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.
    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.

Page 1 of 3 123 LastLast

Similar Threads

  1. migrating non-suphp server to suphp server
    By sharmaine1111 in forum Hosting Security and Technology
    Replies: 4
    Last Post: 09-06-2009, 12:03 PM
  2. suphp and php.ini, is there a way to prevent custom php.ini using suphp
    By sharmaine1111 in forum Hosting Security and Technology
    Replies: 9
    Last Post: 08-15-2009, 12:12 PM
  3. How to tell if server has suphp
    By Skeptical in forum Programming Discussion
    Replies: 4
    Last Post: 06-30-2009, 05:32 PM
  4. Suphp creating 500 internal server error
    By ashras99 in forum Hosting Security and Technology
    Replies: 7
    Last Post: 06-18-2009, 06:25 PM
  5. suPHP - 500 Internal Server Error
    By Green Tea in forum Web Hosting
    Replies: 7
    Last Post: 04-20-2008, 07:37 AM

Tags for this Thread

Posting Permissions

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