How can i stop PHP Shells being hosted?

Portal Home > Knowledgebase > Articles Database > How can i stop PHP Shells being hosted?

Posted by davida50000, 03-21-2010, 05:56 PM
Hi everybody, glad i found this Forum, i could really use some help I am helping a friend with a Web Hosting Company and its going pretty strong at the moment, however we appear to be having particular problems with people hosting PHP shells, how can i stop this from happening? Thank you all for reading, and i hope you can help, also, sorry if this is posted in the wrong place. David.
Posted by RDSNetworking, 03-21-2010, 06:17 PM
Add it to disable_functions in your php.ini. You should also consider ensuring that safe_mode is on and register_globals is off.
Posted by ScottSwezey, 03-21-2010, 06:21 PM
Having safe_mode on will likely cause a lot of problems and headaches. I personally would never stay with a host that ran with safe_mode on. Update your ToS and contact the owners of the accounts and ask them to stop. Then terminate the account if they refuse.
Posted by davida50000, 03-21-2010, 06:27 PM
shell_exec is in the in the disabled functions. Safe mode is on and has been on for a long time without problems. Register_globals is off. How would I go about finding those people who are using things like php shells on my hosting? This is what we are finding difficult. David.
Posted by davida50000, 03-22-2010, 06:52 PM
Can anybody help us stop this type of high outgoing rates from happening See link: http://img682.imageshack.us/img682/8922/18089573.jpg
Posted by HostXNow_Chris, 03-22-2010, 07:04 PM
I don't think you need safe_mode on when running suPHP.
Posted by jon-f, 03-22-2010, 07:25 PM
using mod_security with good ruleset, clamav (can be used for cpanel and/or php uploads), and a good cron to search for them nightly is about all you can do. Running suexec is a big help too for the good of the server.
Posted by Crashus, 03-23-2010, 06:04 AM
use mod_security and disable some php functions
Posted by brianoz, 03-27-2010, 07:35 AM
Use the following: mod_security with a good *short* ruleset - will stop scripts being attackedCSF firewall or similar - will block IPs of people attacking your site, and stop most PHP shells getting outConsider configserver's upload scanner cxs - will stop the scripts being uploaded in the first place (and possibly get the uploading IP blocked)Turn on cpanel's outgoing default limit for mails per hour per account to 200 - will seriouly limit outgoing spam - you can up the limit in /var/cpanel/maxemailsRun suphp so you can identify running scripts more easily Seriously consider getting someone to harden your server - they'll do all of the above and more. Configserver does this for us; although it prices a little, they're experts with knowledge it would take you years to gain - the hardening will save you many, many hours of pain - worth every cent I paid.
Posted by sam0, 03-27-2010, 11:12 AM
1) Sensible permissions 2) Good disabled functions line 3) Make sure remote includes is disabled 4) Enable open base dir 5) Maybe suphp Is the best way to protect from the php shells. mod_security will only offer limited protection and in the process slow down your server.
Posted by brianoz, 03-27-2010, 08:32 PM
Sorry, I didn't take time to explain that. Yes, a badly setup mod_security can have horrible performance impact. However, used with a small, good ruleset (under 100 rules) mod_security can not only provide very good protection but also has no observible impact on server performance. I've used it for about 5 years on 3-5 busy shared servers. The particularly invaluable part of mod_security is that, coupled with CSF, a firewall ban is applied to hackers which pretty much prevents them hacking, or trying to hack, the original site or any other sites on your server. (of course the really good hackers will try straight away from another IP, but since they also only get 10 tries from that before being banned, it still makes it much harder for them) Of course, if you put 1000s of rules from gotroot (or similar source) into the rule file, you can see quite visible performance decrease. Don't do that. This is not to imply that I disagree with Sam's other suggestions which were all very good. The key thing with PHP hardening is to remove access to the shell functions, which they are using, but also to stop your users being hacked, which is probably how the PHP shells are getting onto your server. Mod_security is one of the few ways you have to stop that. Although disabling remote includes also helps a lot. Suphp is more important than some realize - without it, or something similar to it, once a hacker gets into one account, they can leapfrog to other accounts very quickly and easily. (Essentially without suphp, every user can read every other user's PHP files. PHP's open_basedir helps, but will never stop a smart hacker - you need the defence of having users accounts have separate user permissions, which is what suphp gives you.) If your server is under very heavy load, suphp can be an issue - research alternatives such as fastcgi or MPM prefork in that case. Of course, once you have CSF, they can start PHP shells but they can't get out as well, or at all; occasionally we find a shell sitting there unable to communicate, always makes me chuckle. Good security is systematic and covers a lot of bases and layers; what you miss with PHP hardening you catch with suphp, what they miss you catch with CSF. And mod_security stops many attacks even getting in. That's why I recommend the use of a hardening expert; they know a lot of stuff it would take even a seasoned Unix admin years to learn. Last edited by brianoz; 03-27-2010 at 08:35 PM.
Posted by sam0, 03-27-2010, 11:02 PM
Like I said, with a small 'good' ruleset it will only offer limited protection, which usually smart hackers would be able to bypass (and in my experience even a small ruleset noticeably reduces performance) and with a big ruleset it will definitely cause a big reduction in performance. Concerning open base dir - it's very important to use it, as long as your PHP is up to date and you're using both the suhosin extension and patch its unlikely a hacker will be able to get around it, coupled with minimum permissions it is almost, if not as good as suphp and without any performance reduction. And I completely agree with brianoz concerning hiring a hardening expert, as its not something you can learn in a day or even weeks/months. Make sure the person knows what they're doing, check their CV and also make sure they can do it without the need of a control panel (even if you're using one) - as alot of 'hardening experts' will refuse to do it if you don't have a control panel as it can make their job slightly harder - a sign that they don't know what they're doing.
Posted by brianoz, 03-27-2010, 11:37 PM
We do use a very small ruleset and I'll say why it's useful - we use it to stop the following rather successfully: known attack patternssql injection via generic signaturesBcc/To injection via mail forms Even if an attacker is smart, if they trigger enough hits on the above the firewall blocks them and then they move onto the next target - we've made ourselves too hard via a collection of simple strategies, and there are easier pickings elsewhere. For example, if they start off with known attacks they get blocked before they can try anything else. And of course it's great catching most form injections right off the cuff. I'll take note of what you say about performance and mod_security - as we use reasonable spec dedicated servers (which you may well, too) we haven't seen anything noticeable, but then again I'd feel a bit like I was walking around with my pants down if I ran a server without mod_security so I'm not about to try! On reflection we probably only use about 50 rules.
Posted by Sileep Kumar M S, 03-28-2010, 12:56 AM
PHP Shell is using the build-in php function only, so, there is no need to use csf, mod_security etc. Just disable the following functions in your php.ini. Thats all!
Posted by -Ray-, 03-29-2010, 12:01 AM
Do you have Clam AV installed on the server? When you run the scan command clamdscan through the SSH Terminal it will return all locations to scripts that use PHP Shell and provide a report..
Posted by brianoz, 03-29-2010, 01:45 AM
While you can stop a PHPshell running, and detect it with ClamAV, and both are good ideas, the trick is to stop them getting onto your server in the first place. Once they're on there, it's too late - they've got past one layer of your security already. You never know when they'll find a way to work around your other security measures. A standard security principle for those interested: Access to a local account login will inevitably lead to root access if a good hacker's involved - luckily, most aren't that good!
Posted by Sileep Kumar M S, 03-30-2010, 01:02 AM
Uploading a PHPShell is not a big deal. If you have an FTP account in a server, you can simply upload that script. But we can easily prevent the execution of such scripts by disabling the above mentioned php function.
Posted by HostXNow_Chris, 03-30-2010, 08:40 AM
I use the following for a VPS offering free hosting You can remove quite a lot of them for paid hosting.
Posted by HSN-Saman, 03-30-2010, 03:26 PM
Install mod_sec on your server and configure it. Linux kernel and PHP , Apache hardening. Install good firewall on your server like csf or apf (i recommened csf). Install Clamav and set a cronjob to auto scanning and update. Purchase & install CXS to remove viruses and exploits realtime. Prevent users to run cgi/perl script(they can execute commands with cgi or perl) Search "howto disable execute cgi script other extention" In Google.
Posted by brianoz, 03-30-2010, 06:35 PM
True, it's not such a big deal if they upload something like that by FTP as they are probably the account owner (unless they've stolen the password). However, I prefer to keep the burglar out of my house rather than going around bolting my furniture down so it can't be stolen. If they get a script on the server, a knowledgeable hacker can bypass or work around any mere PHP restrictions, given time, in one way or another. The trick is to stop them getting on the server AND harden PHP. Both together makes your protection very strong; that's why all the more experienced people responding here have listed multiple levels of protection. And of course, there are users that like to use some of the PHP functionality you remove, so it's not as easy as just turning off everything you don't like. Good security is "security in depth" - multiple different layers. If you do that you'll survive nicely without seeing root compromises or any serious attacks. And low attacks = low maintenance/admin prices = more efficient hosting (and performance is usually better).
Posted by ALEXEI_M, 03-30-2010, 10:09 PM
The issue you are having is most likely due to insecure code.I think safe_mode is not a solution. Once you put to Safe_mode most of php programs ( joomla , word press , drupal etc.. will go down. There is have so many interruption to PHP programs. Apache and PHP have been recompiled to be more secure. All the most common security features have been added, such as suphp and suhosin. I will give a good solution. recompile apache and php to be more secure (suphp, suhosin etc...)If you want to run a secure server, you will need to include these features especially with Joomla. Otherwise you will continue to have the same problems. If your sites are not working with these features on, then that would be more of an issue you will need to discuss with the developer.
Posted by ALEXEI_M, 03-30-2010, 10:13 PM
Yes I agree with you. Once you put Safe_mode most of PHP programs will go down. Specially Joomls sites. Another thing this if you are reselling web space that will be big trouble for your customers.
Posted by gillboss, 04-09-2010, 03:37 AM
well as my experience in wap line (wml/xhtml mobile sites ) you should turn on open_basedir and if you have a open public uploader without any kind of security people could hack by using php shell when they rename it like shell.php.jpg or shell.php.mp3 and link to file and you should do Open_BaseDir On safe_mode off Register Global Off‎ magic_quotes_gpc() to be off above things could help also stop mysql attack or injections
Posted by MrSaints, 04-09-2010, 06:51 AM
Yeap, most of everything mentioned already - you can take a look around: http://www.gotroot.com/mod_security+rules for some rulesets. With CSF, you can get an e-mail notification in the event someone has been sending over "X" limit of e-mails, it will also trace which script is sending the e-mails out, thus allowing you to resolve any cases of 'spam'. Not to mention, CSF has a security audit tool with security recommendations. But most definetly mod_security is the best way around. I would also recommend disabling: "ini_set()" with Safe CGI enabled - however, with ini_set disabled, most of your scripts may not work, another solution for fixing this is commenting out the ini_set lines, or you could configure it to allow only specific users use ini_set() whilst it is disabled on default.
Posted by ideamine, 04-09-2010, 05:04 PM
Enable mod_security, compile PHP with suphp support and disable some php functions on php.ini