Results 1 to 21 of 21
  1. #1
    Join Date
    Jan 2014
    Location
    Montreal
    Posts
    121

    Question Using MoSec for Joomla and WP Brute force

    Hi, I'm adding the following rule in my modsec rule set :

    Code:
    SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134
     <Locationmatch "/wp-login.php">
     # Setup brute force detection.
     # React if block flag has been set.
     SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"
     # Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed.
     SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"
     SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
     SecRule ip:bf_counter "@gt 10" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"
     </locationmatch>
    But I would like to use the same rule for Joomla, how could I add Joomla in the same location match?

    Combining those two :

    Code:
    <Locationmatch "/wp-login.php">
    <LocationMatch "/administrator/index.php">
    Thank You!
    << Please review the Forum Guidelines regarding signatures >>

  2. #2
    Join Date
    Jun 2014
    Posts
    57
    The WP rule can be condensed to one collection (just ip, not ip and user). I recommend replacing the WP rule with this:

    Code:
    #Wordpress Brute Force detection
    SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000134
    <Locationmatch "/wp-login.php">
    # Setup brute force detection.
    # React if block flag has been set.
    SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"
    # Setup Tracking.  On a successful login, a 302 redirect is performed, a 200 indicates login failed.
    SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"
    SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
    SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
    </locationmatch>
    Doing Joomla requires egress filtering (you have to turn on SecResponseBodyAccess)

    Leaving your first rule in place for wp-login, that already makes the collection (initcol), you can use this for Joomla:

    Code:
    SecResponseBodyAccess on
    <Locationmatch "/administrator/index.php">
    # Setup brute force detection.
    # React if block flag has been set.
    SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000235,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"
    # Count brutes:
    SecRule RESPONSE_BODY "Username and password do not match" "phase:4,t:none,nolog,chain,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000237"
    SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
    </locationmatch>
    Last edited by quizknows; 07-17-2014 at 09:43 PM. Reason: revised WP rule

  3. #3
    Hi

    I'm also looking for a working rule to block this joomla brute force attacks. I tested the above rules on a server, it was blocking some ip addresses, but not all of them.

    I don't really understand how this rule is working, but does it look for "Username and password do not match" in the response? If yes, the problem could be a different language. Because most of my users are using german.

    Regards
    Michael

  4. #4
    Join Date
    Jun 2014
    Posts
    57
    Michael,

    That is exactly how it works. It looks at the response body of pages served for /administrator/index.php, and if the response contains "Username and password do not match" then it counts a point on the brute force counter.

    You should be able to modify the response body line as follows to accomodate another language:

    Code:
    SecRule RESPONSE_BODY "(Username and password do not match|alternate language here)" "phase:4,t:none,nolog,chain,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000237"
    If you do not use the WP rule, be sure to have this line from it above the joomla rule (you only need it once if using both rules)
    Code:
    SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000134

  5. #5
    ive seen recent increase in this type of bruteforce.
    thanks for the rule
    Looking for shared or reseller or VPS Hosting ?
    Try our service at https://www.sosys.net!
    Singapore - Indonesia - Malaysia

  6. #6
    Perfect, thanks a lot!

  7. #7
    Join Date
    Jan 2014
    Location
    Montreal
    Posts
    121
    I've modify my rules a bit, I'm blocking the IP for 30 minutes instead of 5 (and thinking about placing a 60 minutes).
    << Please review the Forum Guidelines regarding signatures >>

  8. #8
    Join Date
    Jan 2014
    Location
    Montreal
    Posts
    121
    I'm also using only one rule for both :

    Code:
    SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134
     <Locationmatch "/wp-login.php|/administrator/index.php">
     # Setup brute force detection.
     # React if block flag has been set.
     SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 30 minutes, more than 10 login attempts in 3 minutes.'"
     # Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed.
     SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"
     SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
     SecRule ip:bf_counter "@gt 10" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=1800,setvar:ip.bf_counter=0"
     </locationmatch>
    During an attack without the rule, I had a load average of above 5, when applying this rule, my load average drop below 1 !!!

    The same rule will block Joomla and Wordpress Using a pipe selector in the Locationmatch regex.
    << Please review the Forum Guidelines regarding signatures >>

  9. #9
    Join Date
    Jun 2014
    Posts
    57
    Quote Originally Posted by neutrall View Post
    I'm also using only one rule for both :

    Code:
    SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134
     <Locationmatch "/wp-login.php|/administrator/index.php">
     # Setup brute force detection.
     # React if block flag has been set.
     SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 30 minutes, more than 10 login attempts in 3 minutes.'"
     # Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed.
     SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"
     SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
     SecRule ip:bf_counter "@gt 10" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=1800,setvar:ip.bf_counter=0"
     </locationmatch>
    During an attack without the rule, I had a load average of above 5, when applying this rule, my load average drop below 1 !!!

    The same rule will block Joomla and Wordpress Using a pipe selector in the Locationmatch regex.
    This rule will NOT work properly for joomla. You cannot use response status for Joomla, because once logged in you are still at administrator/index.php and will continue to get 200 status responses from the server. I can almost guarantee this will block users for normal use after 5-10 clicks inside the joomla admin area. You have to filter for joomla with response body.

    The reason the 302/200 response status works for WP is because a successful login at wp-login.php will 302 redirect to wp-admin. A failed login 200's and re-loads wp-login. Joomla does not do this, thus the use of RESPONSE_BODY for filtering.

    If you want protection for both Joomla and WP, use both rules I posted in post #2, in the order they are in.
    Last edited by quizknows; 07-18-2014 at 02:08 PM.

  10. #10
    Join Date
    Jan 2014
    Location
    Montreal
    Posts
    121
    Quote Originally Posted by quizknows View Post
    The reason the 302/200 response status works for WP is because a successful login at wp-login.php will 302 redirect to wp-admin. A failed login 200's and re-loads wp-login. Joomla does not do this, thus the use of RESPONSE_BODY for filtering.

    If you want protection for both Joomla and WP, use both rules I posted in post #2, in the order they are in.
    Thanks for the tips! I'll modify my rule set!
    << Please review the Forum Guidelines regarding signatures >>

  11. #11
    Join Date
    Dec 2004
    Posts
    39
    Quote Originally Posted by quizknows View Post
    The WP rule can be condensed to one collection (just ip, not ip and user). I recommend replacing the WP rule with this:

    Code:
    #Wordpress Brute Force detection
    SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000134
    <Locationmatch "/wp-login.php">
    # Setup brute force detection.
    # React if block flag has been set.
    SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"
    # Setup Tracking.  On a successful login, a 302 redirect is performed, a 200 indicates login failed.
    SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"
    SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
    SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
    </locationmatch>
    Doing Joomla requires egress filtering (you have to turn on SecResponseBodyAccess)

    Leaving your first rule in place for wp-login, that already makes the collection (initcol), you can use this for Joomla:

    Code:
    SecResponseBodyAccess on
    <Locationmatch "/administrator/index.php">
    # Setup brute force detection.
    # React if block flag has been set.
    SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000235,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"
    # Count brutes:
    SecRule RESPONSE_BODY "Username and password do not match" "phase:4,t:none,nolog,chain,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000237"
    SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
    </locationmatch>
    Thanks.

    The Joomla rule works perfect for code 200, but it doesn't work for 302

    50.62.35.71 - - [18/Jul/2014:12:37:08 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:09 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:09 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:11 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:11 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:12 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:12 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:13 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:14 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:14 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:15 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:15 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:16 -0700] "GET /administrator/index.php HTTP/1.0" 302 -
    50.62.35.71 - - [18/Jul/2014:12:37:17 -0700] "GET /administrator/index.php HTTP/1.0" 302 -

  12. #12
    Join Date
    Jun 2014
    Posts
    57
    Those are simply GET requests, thus they are not login attempts. Login attempts are POSTs.

    You can block scans for /administrator/index.php that lack useragents/referrers with this rule:

    Code:
    # Block Joomla scans that are looking for sites to target; frequently they lack both UA and Referer fields
    SecRule REQUEST_URI "/administrator/index.php" "deny,status:411,id:5000223,chain,msg:'Joomla admin access blocked due to No UA and No referer'"
    SecRule &HTTP_REFERER "@eq 0" "chain"
    SecRule &HTTP_User-Agent "@eq 0"

  13. #13
    Join Date
    Dec 2004
    Posts
    39
    Got it. Thanks.

    I use your rule for many cpanel servers and they are working very good. On two servers, I found that it's not working. Both targets are addon domains in cpanel, does this matter?

    162.13.110.115 - - [18/Jul/2014:14:40:54 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:40:54 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:40:55 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:40:56 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:40:56 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:40:57 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:40:57 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:40:58 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:40:59 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:40:59 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:41:00 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:41:01 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:41:01 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:41:02 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:41:02 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:41:03 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:41:04 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:41:04 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:41:05 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:41:06 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:41:06 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:41:07 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:41:08 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:41:08 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:41:09 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:41:10 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:41:10 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:41:11 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:41:12 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:41:13 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:41:13 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:41:14 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:41:14 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:41:15 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457
    162.13.110.115 - - [18/Jul/2014:14:41:16 -0700] "POST /administrator/index.php HTTP/1.0" 303 -
    162.13.110.115 - - [18/Jul/2014:14:41:16 -0700] "GET /administrator/index.php HTTP/1.0" 200 4640
    162.13.110.115 - - [18/Jul/2014:14:41:17 -0700] "GET /administrator/index.php HTTP/1.0" 200 4457


    The other one:

    91.227.68.32 - - [18/Jul/2014:14:41:22 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:41:23 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:41:24 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:41:25 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:41:41 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:41:57 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:03 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:09 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:15 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:16 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:18 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:19 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:20 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:31 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:32 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:33 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:34 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:35 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:36 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:37 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:38 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:39 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:41 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:42 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:43 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:44 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:45 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:46 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:47 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:48 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824
    91.227.68.32 - - [18/Jul/2014:14:42:49 -0700] "GET /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4578
    91.227.68.32 - - [18/Jul/2014:14:42:50 -0700] "POST /administrator/index.php HTTP/1.0" 200 HTTP/1.0 4824

  14. #14
    Join Date
    Jun 2014
    Posts
    57
    Being an addon-domain should not matter, the rule(s) should still work.

    Being a cPanel server you should ensure that ModSecurity was indeed selected in the last EasyApache build, and that modsec2.conf is called as an includes in httpd.conf. Also ensure that something like configserver modsec control wasn't used to disable modsec for those domains (or entirely).

    I notice your domain access logs don't have the referrer or useragent listed, the logs in the apache domlogs folder should have that information, and it can help with modifying rules to block the attacks for your situation.

  15. #15
    Join Date
    Dec 2004
    Posts
    39
    Quote Originally Posted by quizknows View Post
    Being an addon-domain should not matter, the rule(s) should still work.

    Being a cPanel server you should ensure that ModSecurity was indeed selected in the last EasyApache build, and that modsec2.conf is called as an includes in httpd.conf. Also ensure that something like configserver modsec control wasn't used to disable modsec for those domains (or entirely).

    I notice your domain access logs don't have the referrer or useragent listed, the logs in the apache domlogs folder should have that information, and it can help with modifying rules to block the attacks for your situation.
    The modsecurity is installed, and the rule works for other domains on the same server. I've checked the CMC, the modsec is enabled for the main domain and this addon domain, also no rule in whitelist.

    I checked the domlog for this addon domain, I don't see referrer or useragent neither.

    91.227.68.32 - - [18/Jul/2014:15:21:09 -0700] "GET /administrator/index.php HTTP/1.0" 200 4578 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:10 -0700] "POST /administrator/index.php HTTP/1.0" 200 4824 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:11 -0700] "GET /administrator/index.php HTTP/1.0" 200 4578 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:12 -0700] "POST /administrator/index.php HTTP/1.0" 200 4824 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:18 -0700] "GET /administrator/index.php HTTP/1.0" 200 4578 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:24 -0700] "POST /administrator/index.php HTTP/1.0" 200 4824 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:25 -0700] "GET /administrator/index.php HTTP/1.0" 200 4578 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:26 -0700] "POST /administrator/index.php HTTP/1.0" 200 4824 "-" "-"

  16. #16
    Join Date
    Jun 2014
    Posts
    57
    Quote Originally Posted by garconcn View Post
    The modsecurity is installed, and the rule works for other domains on the same server. I've checked the CMC, the modsec is enabled for the main domain and this addon domain, also no rule in whitelist.

    I checked the domlog for this addon domain, I don't see referrer or useragent neither.

    91.227.68.32 - - [18/Jul/2014:15:21:09 -0700] "GET /administrator/index.php HTTP/1.0" 200 4578 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:10 -0700] "POST /administrator/index.php HTTP/1.0" 200 4824 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:11 -0700] "GET /administrator/index.php HTTP/1.0" 200 4578 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:12 -0700] "POST /administrator/index.php HTTP/1.0" 200 4824 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:18 -0700] "GET /administrator/index.php HTTP/1.0" 200 4578 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:24 -0700] "POST /administrator/index.php HTTP/1.0" 200 4824 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:25 -0700] "GET /administrator/index.php HTTP/1.0" 200 4578 "-" "-"
    91.227.68.32 - - [18/Jul/2014:15:21:26 -0700] "POST /administrator/index.php HTTP/1.0" 200 4824 "-" "-"
    Assuming everything is configured correctly, there is no reason the rule in post #12 should not be blocking those requests. Without access to your server to check all the configs there's not much else I can do.

    Check the file where you added that rule, and "break" it. Do something like remove the id:#### from the action chain. Save the file and run "httpd configtest" at a shell; you should get an error saying the rule needs an ID. If you do not, then the file you're making the rule in is not properly called as an includes to the apache configuration. Be sure to replace the rule ID, or else the next time you try to restart apache it will not start.
    Last edited by quizknows; 07-18-2014 at 06:36 PM.

  17. #17
    Join Date
    Dec 2004
    Posts
    39
    Quote Originally Posted by quizknows View Post
    Assuming everything is configured correctly, there is no reason the rule in post #12 should not be blocking those requests. Without access to your server to check all the configs there's not much else I can do.

    Check the file where you added that rule, and "break" it. Do something like remove the id:#### from the action chain. Save the file and run "httpd configtest" at a shell; you should get an error saying the rule needs an ID. If you do not, then the file you're making the rule in is not properly called as an includes to the apache configuration. Be sure to replace the rule ID, or else the next time you try to restart apache it will not start.
    I just tried removing the id, the configtest did fail and ask for the id. Anyway, Thanks a lot for your help, it did help a lot.

  18. #18
    Join Date
    Jun 2014
    Posts
    57
    Glad to help. If you have a managed hosting provider you may consider asking them (or cPanel) for help figuring out why your rules may not be working with addon domains. Best of luck.

  19. #19
    Join Date
    Oct 2004
    Location
    Germany
    Posts
    356
    We're using this set of rules:

    Code:
    # Joomla Brute Force Protection
    <LocationMatch "/administrator/index.php">
    SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:00107
    SecRule user:bf_block "@gt 0" "deny,status:403,log,id:00117,msg:'IP address blocked for 5 minutes. More than 60 Joomla POST requests within 30 seconds.'"
    SecRule REQUEST_METHOD "^POST$" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/30,id:00118"
    SecRule ip:bf_counter "@gt 60" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"
    </LocationMatch>
    Disclaimer: Use at your own risk and if you know what you're doing.

    It counts the number of POST requests and blocks the IP for 5 minutes if more than 60 POST requests are sent within 30 seconds.

    You may also want to activate LF_MODSEC and LF_MODSEC_PERM in CSF to deny the IP from the entire server.

    Some Joomla components may trigger the protection, but overall it works pretty well. If clients complain, simply add this to their .htaccess to disable the rules when running a component

    Code:
    # ModSecurity - Disable Joomla BF Rules
    <LocationMatch "/administrator/index.php?option=com_">
    SecRuleRemoveById 00113
    SecRuleRemoveById 00114
    SecRuleRemoveById 00115
    </LocationMatch>
    COMODO WAF now has brute force protection rules, as well, but they need improvement due to several false positives.
    MaxterHostsimply different.
    cPanel Shared Hosting, WHM Reseller Accounts, Managed/Self-Managed VPS Hosting and more
    17+ Years of Experience | Enhanced Security | 24x7 Support | 100% Uptime SLA

    Pure SSD Hosting

  20. #20
    Join Date
    Nov 2002
    Posts
    31
    Thanks for the rules MH_Stefan!

    Could these be combined in mod_security so the rule already excludes the false positives due to components?

    I've also found that tuning the number of requests/time can help with the false positives too.

  21. #21
    Join Date
    Oct 2004
    Location
    Germany
    Posts
    356
    My pleasure. Not tested, but this *might* work:

    Code:
    # Joomla Brute Force Protection
    <LocationMatch "^((?!/administrator/index.php?option=com_)|(/administrator/index.php))">
    SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:00107
    SecRule user:bf_block "@gt 0" "deny,status:403,log,id:00117,msg:'IP address blocked for 5 minutes. More than 60 Joomla POST requests within 30 seconds.'"
    SecRule REQUEST_METHOD "^POST$" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/30,id:00118"
    SecRule ip:bf_counter "@gt 60" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"
    </LocationMatch>
    MaxterHostsimply different.
    cPanel Shared Hosting, WHM Reseller Accounts, Managed/Self-Managed VPS Hosting and more
    17+ Years of Experience | Enhanced Security | 24x7 Support | 100% Uptime SLA

    Pure SSD Hosting

Similar Threads

  1. Help on Brute Force
    By blipper in forum Hosting Security and Technology
    Replies: 3
    Last Post: 03-27-2014, 11:47 AM
  2. Joomla sites under massive brute force attacks
    By elialum in forum Hosting Security and Technology
    Replies: 16
    Last Post: 05-30-2013, 12:21 PM
  3. Brute Force
    By YourReference in forum Hosting Security and Technology
    Replies: 6
    Last Post: 04-28-2013, 03:38 PM
  4. Brute Force
    By Dave W in forum Hosting Security and Technology
    Replies: 2
    Last Post: 09-14-2006, 01:54 PM
  5. brute force
    By Ten X in forum Hosting Security and Technology
    Replies: 1
    Last Post: 01-27-2005, 02:26 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •