mod_security RESPONSE_BODY

Discussion in 'LSWS 4.1 Release' started by yolte, Feb 26, 2009.

  1. yolte

    yolte New Member

    Hello,

    I have a problem about mod_security RESPONSE_BODY rules;

    Some mod_sec 2.x rules not working, for examlpe i have a rule set for blocking r57,c99 etc php shells;

    This rule is working when i switched the apache, but on LS it is not working.

    This rule have to return 404 error when someone run r57 shell script.

    Can you help to improve security by using SecRule RESPONSE_BODY ?
  2. mistwang

    mistwang LiteSpeed Staff

    Currently scanning response body is not supported by LiteSpeed yet.
    A rule like that will severely slow down the server when scan a large response body.
    So, we will think about it carefully.
  3. yolte

    yolte New Member

    Hello,

    Maybe it will slow down server. But security is more important for us.

    You can enable RESPONSE_BODY those who want to use security?

    We are looking for to use LiteSpeed instead of Apache in our 20 linux servers. But our security department doesn't approve because of mod_security respone rules.
  4. yolte

    yolte New Member

    Hello mistwang,

    It will be any progress on this issue?
  5. IrPr

    IrPr New Member

    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

    is it possible?
  6. yolte

    yolte New Member

    Yes it will slow down but this is our choice. Am i wrong? :)
  7. mistwang

    mistwang LiteSpeed Staff

    It is a low priority feature.
  8. yolte

    yolte New Member

    Security is low priority feature?

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

    Lets test it?
  9. Tony

    Tony Member

    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.
  10. yolte

    yolte New Member

    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)
  11. IrPr

    IrPr New Member

    Im totally agree with yolte

    However it may decrease performances but its a trade off between security and performances
    it can be disable by default and could be turned on with our own risk

    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

    Hope be implemented in future
    Last edited: Mar 29, 2009
  12. Tony

    Tony Member


    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).
  13. anewday

    anewday Moderator

    Tony, can you share your mod_security ruleset? PM me if preferred. :)
  14. Tony

    Tony Member

    I just use gotroot.com then when we find things that get past we add rules for them. We won't give away our added rules so gotroot.com as a starting point.
  15. yolte

    yolte New Member

    Thank you. I think disable_functions are nothing for a good hacker :)
  16. yolte

    yolte New Member

    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
    Last edited: Mar 29, 2009
  17. Tony

    Tony Member

    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:

    <LocationMatch /edit_css.ph>
    SecRuleRemoveById 340006
    SecRuleRemoveById 340007
    </LocationMatch>


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

    IrPr New Member

    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

    for example latest expoits for php is: PHP safe_mode bypass via proc_open() and custom environment which is not detectable by any mod_security rule! attacker can rename php filename to everything and bypass safe_mode/open_basedir restrictions easily

    This exploits is not patched in latest stable PHP version yet, tested on php 5.2.9 myself and its working properly

    The only way to patch this exploits is disabling proc_open function ;)

    mod_security is not enough to secure your server againts all remote and local attacks
    Last edited: Mar 30, 2009
  19. Tony

    Tony Member

    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.
  20. yolte

    yolte New Member

    You know that php shells are using lots of php functions which are using by otner normal php scripts (etc oscommerce, joomla)

    If we disable this functions other customers scripts has been blocking.

    If we disable this, it can break any php script?

    And finally, gotroot paid and real time rules, blocking %99 of php exploits on milw0rm and packetstorm. Did you try it?

Share This Page