George is right, it will slow down server as hell
but i think special trick for example scanning specified response mime types (plain text) or requested file types (php) would solve performances issue and increases security as well

Each server can be hacked which is not support this feature. How can it be ignored?

Lets test it?

Click to expand...

I'd say more like a site can be hacked because they do not keep up to date versions of their software or make secure software. For hacking an entire server it be even more tricky assuming the site was on it's own account.

There are other mod_security rules which are already supported which can inflate memory (ones that use location match). I'd rather see the rules that are supported not slow down LSWS to Apache levels.

I'd say more like a site can be hacked because they do not keep up to date versions of their software or make secure software. For hacking an entire server it be even more tricky assuming the site was on it's own account.

Click to expand...

I think we have to protect customers web sites who doesn't have enough information about script security?

There are other mod_security rules which are already supported which can inflate memory (ones that use location match). I'd rather see the rules that are supported not slow down LSWS to Apache levels.

Click to expand...

Can you give me examples which rules are protecting from php shells? (for ex: r57, c99)

I think we have to protect customers web sites who doesn't have enough information about script security?
Can you give me examples which rules are protecting from php shells? (for ex: r57, c99)

Click to expand...

c99 phpshells can be defected by some tricks because of using common GET args but r57 is more tricky and couldnt be defected without response body check
All phpshells based on malicious functions such exec, shell_exec, system, etc but we can catch local attackers with response body check

I think we have to protect customers web sites who doesn't have enough information about script security?

Can you give me examples which rules are protecting from php shells? (for ex: r57, c99)

Click to expand...

There is only so much you can do without making your hosting service have absolutely no features. We have mod_security rulesets up which do have mechanisms to protect against a lot of the exploits of the scripts themselves.

For disabling php functions you have the issue of some scripts rely on them. I know gallery systems use exec and others use system. None use popen* so we disable those.

There is only so much you can do to protect your users if they will not take the time to update their scripts they'll deal with the consequences.

There are other avenues to put up malicious files. Do you not give your users FTP access? We've seen a growing number of hacked web sites come via ftp. Users using passwords that are the same as their username with one number in them. Or their own computers being hacked resulting in malicious files on their website.

This is all why we give users access to 7 days worth of backups that they can restore from themselves. If they get hacked they do have something to fall back on.

So in summary sites are going to get hacked if you want to protect them fully you'd want to not give users any access to their accounts. You'd also want to disable POST and GET via mod_security and whitelist based on domain (one host does this).

c99 phpshells can be defected by some tricks because of using common GET args but r57 is more tricky and couldnt be defected without response body check
All phpshells based on malicious functions such exec, shell_exec, system, etc but we can catch local attackers with response body check

I'am using gotroot's paid mod_sec rules and our private rules too. You should fear from turkish and russian hackers

I am looking for 2 years and only way response body rules to block completely hacking attempts

Click to expand...

Well the best way is for users to be not being hacked left and right. I guess it's too much to ask for them to use a wordpress version made in the past year.

If you can limit the damage to the user account then you've done your best. If you do not allow url includes you've dramatically reduced your risk on a lot of the php inclusion exploits. Those are where most of these shells get uploaded. You're still not going to stop someone really determined unless you flat out do not allow anything. Most of the dangerous attacks in the past few years have involved privilege escalation. They did not even require a r57 shell to do. You could do them via a perl script which most are not bothering to block anyways. The perl scripts do not have the same sort of shell restrictions either.

Oh and I mentioned rules that cause a lot of trouble for LSWS well one such example so something like this:

With a lot of them and a decent amount of vhosts you could see your memory usage being extremely high. We had a machine where we threw up some rules with that and we went from LSWS using 100MB of memory to 800MB of memory.

The request body scanning is another scary rule to really kill the performance. If it's not done well I don't think it's worth doing at the price in resources it's going to come at. It does not guarantee protection either from what I'd deemed very serious.

lol what do you mean by good hacker? most hackers are script kiddies which collect public exploits and rootkits from milw0rm and packetstorm

if i disable all c99's necessary functions then how could you use c99 shell on my server even without any mod_security rules defecting c99 shell?

In fact all php shells are woking based on common php security restriction bypass exploits, if you know php take a look into phpshells source codes and you will find all of 'em are based on some malicious functions

I doubt that safe_mode exploit will ever be fixed seeing as how PHP 6.0 will not have safe_mode. At least that's what was said back when 6.0 was in early development. openbase_dir although useful if someone does get around it in theory they should be unable to do any damage. PHP is running as their user they're going to need to find folders that have read and write for everyone to do any damage. So really not a ton they can do and considering suPHP which a lot of people use does not support openbase_dir and we're not reading about people suggesting mod_php is better.

Plus as I said if your server supports Perl then these c99, r57 ect. ect. shells are just a php entry point. If they can get a perl version up they do not have openbase_dir restrictions anyways and can run shell commands.