'Re: [mod-security-users] Brute force attacks ... only phase:1 analysed'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mod-security-users
Subject:    Re: [mod-security-users] Brute force attacks ... only phase:1 analysed
From:       David R <rewt () linux-elite ! org>
Date:       2015-01-12 17:41:42
Message-ID: loom.20150112T184111-779 () post ! gmane ! org
[Download RAW message or body]

Thank you Chaim it is working perfectly :)


Chaim Sanders <CSanders <at> trustwave.com> writes:

>
>
>
> David,
> There are a few things here of interest. The most important being the
usage of setvar. As is noted (and recently expanded) in the reference docs,
setvar "will
>  be executed when an individual rule matches and not the entire chain"
(https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#setvar).
>  What this means for your rule is that ip.auth_attempt is being
incremented every time that the REQUEST_FILENAME is matched, regardless of
if the method is of type POST, the ARG s_action is login, or the response is
200. To match the entire rule the setvar
>  should be placed in the last rule of the chain. I also recommend the use
of ARGS_POST which should simplify your rule and putting it in the lowest
phase possible (phase:3 - response headers). Best practice wise it is
suggested that you keep related rules with
>  different phases in order from lowest to highest phase (helps
readability), escape slashes in regex, and explicitly specify  <at> rx (but
these are just best practices
> J). Lastly, it is assumed you are using OWASP CRS which creates an IP
collection (https://github.com/SpiderLabs/owasp-modsecurity-
crs/blob/master/modsecurity_crs_10_setup.conf.example#L391-435).
>    If this is not true you must also initiate the IP collection (initcol)
or use TX. Ultimately your rule ends up looking as follows. If you have any
other problems be sure to reach out.
>   
> #
> # Check IP:AUTH_ATTEMPT SCORE and block if more than 10
> #
> SecRule IP:AUTH_ATTEMPT " <at> gt 10" "log,drop,phase:1,id:8,msg:'Possible
Brute Force Attack',logdata:'Brute Force DETECTED'"
>   
> #
> # Increase IP:AUTH_ATTEMPT SCORE
> #
> SecRule REQUEST_FILENAME " <at> rx ^.*\/(login|my-account)$"
"chain,id:7,phase:3,t:none,nolog"
>    SecRule ARGS_POST:s_action " <at> streq login" "chain,t:none"
>            SecRule RESPONSE_STATUS " <at> streq 200"
"t:none,setvar:ip.auth_attempt=+1,deprecatevar:ip.auth_attempt/60,expirev
ar:ip.auth_attempt600"
>   
>   
> Chaim Sanders
> Security Researcher, SpiderLabs
>   
> Trustwave  |  SMART SECURITY ON DEMAND
> www.trustwave.com
>   
> From: rewt rewt [mailto:rewt <at> linux-elite.org]
> Sent: Friday, January 9, 2015 8:20 AMTo: mod-security-users <at>
lists.sourceforge.netSubject: [mod-security-users] Brute force attacks ...
only phase:1 analysed
>   
>
> Dear all,
>
> I am not sure to understand everything...
>
>
>   
>
>
> I have the following directives:
>
>
>   
>
>
>   
>
>
>   
>
>
>
> SecRule REQUEST_FILENAME "^.*/(login|my-account)$"
"chain,phase:5,t:none,id:'7',nolog,setvar:ip.auth_attempt=+1,deprecatevar:ip
.auth_attempt/60,expirevar:ip.auth_attempt600"
>
>
>   SecRule REQUEST_METHOD " <at> streq POST" "chain,t:none"
>
>
>    SecRule ARGS:s_action " <at> streq login" "chain,t:none"
>
>
>      SecRule RESPONSE_STATUS " <at> streq 200" "t:none"
>
>
> SecRule IP:AUTH_ATTEMPT " <at> gt 10" "log,drop,phase:1,id:8,msg:'Possible
Brute Force Attack',logdata:'Brute Force DETECTED'"
>
>
>
>   
>
>
> It is supposed to block BF attacks on /login url if this is POST, if the
arg s_action contains login, and if the response status is 200...
>
>
> also tried to replace  <at> streq by ^POST or ^200 etc.. same results...
>
>
>   
>
>
> This is working partially, indeed with Burp i have tried to modify the
HTTP Method to GET, i am still blocked after 10 attempts (i should not be)
>
>
> Same if i set the value of s_action to something different than "login"...
>
>
> I have tried to set phase:3 and :5 -> same result :(
>
>
> It is just as if only phase:1 was considered...
>
>
>   
>
>
> Furthermore, in the github documentation the following directives are
supposed to block BF attacks on login args.
>
>
> SecAction phase:1,id:109,initcol:ip=%{REMOTE_ADDR},nolog
>
>
> SecRule ARGS:login "!^$"
"nolog,phase:1,id:110,setvar:ip.auth_attempt=+1,deprecatevar:ip.auth_attempt
 /120"
> SecRule IP:AUTH_ATTEMPT " <at> gt 25"
"log,drop,phase:1,id:111,msg:'Possible Brute Force Attack
> But if you consider normal phase transactions the login ARGS are not
supposed to be treated in phase:1 (except if the authentication process goes
thorugh a GET request)...
> Could you tell me what i am doing wrong ?
> Kind regards,
> David R
>   
>   
>   
>
>
>
>
> This transmission may contain information that is privileged,
confidential, and/or exempt from disclosure under applicable law. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution, or use of the information
>  contained herein (including any reliance thereon) is strictly prohibited.
If you received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic or
hard copy format.
>
>
> --------------------------------------------------------------------------
----
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
>
> _______________________________________________
> mod-security-users mailing list
> mod-security-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>





------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
www.gigenet.com
_______________________________________________
mod-security-users mailing list
mod-security-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/

[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic