[solved] Comodo Waf brute force rules issues

Discussion in 'Bug Reports' started by wanah, Aug 13, 2014.

  1. wanah

    wanah Member

    Hello,

    Comodo brute force rules work once then stop working. If I have an ongoing brute force and I restart litespeed their rules add one entry then stop adding entries and don't filter anything.

    On their forum their final anwser was :

    Any chance you could look into it with them to try and get these rules working ?

    We are especially interested in the Wordpress and Joomla brute force rules.

    Other rules seem to continue to work, just the brute force onces that only work once and don't seem to caus any 403 errors for the attacker, not even when the rule is triggered, almost as if it crashes just fater triggering the rule before factually blocking the query.

    http://forums.comodo.com/free-modse...ction-not-working-on-litespeed-t106187.0.html

    Thanks
  2. mistwang

    mistwang LiteSpeed Staff

    We need the exact set of rules you used. related to id "230007" .
  3. wanah

    wanah Member

    Hello, not sure what I'm exactly allowed to publish here, I will e-mail what I can to the bugs email address.

    Thanks
  4. mistwang

    mistwang LiteSpeed Staff

    go ahead, we have not received any thing yet. it is "bug@..." not "bugs@...".
  5. wanah

    wanah Member

    Sorry, it was blocked by our outgoing antispam:)
  6. mistwang

    mistwang LiteSpeed Staff

    have not received it yet.
  7. wanah

    wanah Member

    It defenetly went this time, if it got stuck by my antispam maybe it also got caughty yours.

    I've reworded it and hopefully this time you will recieve it.
  8. mistwang

    mistwang LiteSpeed Staff

    make sure you did not sent it litespeed.com, should be litespeedtech.com
  9. wanah

    wanah Member

    Seems like it was Comodo in the subject that our spam server didn't like, thought it was a phishing attempt, your Google antispam might have thought the same.

    I see your Google MX servers recieved it about 6 minutes ago but I don't know if it was delivered. I'm going to send it again without mentionning Comodo.
  10. mistwang

    mistwang LiteSpeed Staff

    got it now, the problem is due to the "block" action used in those rules, causes the engine did not do anything, fixing it.
  11. wanah

    wanah Member

    Great ! Thanks :)

    Let me know when to update.
  12. mistwang

    mistwang LiteSpeed Staff

    Please force reinstall 4.2.14 see if it has been fixed or not.
  13. wanah

    wanah Member

    Thanks, I don't seem to have any brute force attacks at the moment (server load us low, hackers seem to have gone on holiday with their parents… :D ). I will watch it and let you know next time I get a definate brute force.
  14. wanah

    wanah Member

    The brute force rule doesn't seem to be triggering anymore.

    Before it would trigger once when restarted litespeed without blocking the request but now it's just not doing anything.

    Can you also please confirm if I need to have :

    LoadFile /opt/lua/lib/liblua.so

    Every time I update something in Comodo's WAF this line is commented again. Does litespeed use this for detecting mod security rules.

    Before with this line I caught a brute force trigger when I restarted litespeed, now with or without it it doesn't trigger.
  15. mistwang

    mistwang LiteSpeed Staff

    That line does not matter. Will check what happened with the rule.
  16. mistwang

    mistwang LiteSpeed Staff

    We tested those rules, looks working fine.
    The default threshold of those rules only trigger the blocking when there are more than 30 hits in 60 seconds, you may need to lower the threshold.
  17. JulesR

    JulesR New Member

    We're seeing a similar issue here with the same rules and same ID. We're using the latest version of Litespeed (force upgraded just now to be sure).

    What's happening is, the CWAF rules are triggering a brute force detection on rule ID 230007. This is working fine, and the detection is correct, a brute force attack was happening. The problem is, it's only logged once and nothing is blocked. The attack continues and the rule is no longer triggered.

    Is this a Litespeed issue or a rule issue?
  18. mistwang

    mistwang LiteSpeed Staff

    please check if the latest build works properly or not.
    The older build does not implemented the "block" action, so it does not really deny any request. You can verify it from the audit log, the latest build default "block" to "deny".
  19. JulesR

    JulesR New Member

    Thanks for the update. I just force updated Litespeed and I'm afraid it's the same behaviour. The brute force is detected and logged once in mod_security, but the attack is continuing and doesn't get logged/detected again until Litespeed is restarted.
  20. mistwang

    mistwang LiteSpeed Staff

    I have tested it again in our lab, it is working fine. I think your force update may not be successful, or the server was not restarted properly after the update. .
    The size of 64bit binary of lshttpd.4.2.14 is
    1547936

    try the force update from command line instead of from web GUI.

Share This Page