Joomla brute force attacks

S

stormy

Well-Known Member
#1
#1
I've noticed an increase in Joomla brute force attacks. I haven't been able to find a mod_security rule that stops these and is compatible with Litespeed. The few rules I've found all need to scan the response body.

Any ideas? It would be fantastic if Litespeed could support this natively.
 
W

wanah

Well-Known Member
#2
#2
I'm testing the following rule at the moment :

Code: 
# Joomla Brute Force Protection
#
<LocationMatch "/administrator/index.php">
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:00113
SecRule user:bf_block "@gt 0" "deny,status:403,log,id:00114,msg:'IP address blocked for 30 minutes. More than 15 Joomla POST requests within 3 minutes.'"
SecRule REQUEST_METHOD "^POST$" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:00115"
SecRule ip:bf_counter "@gt 15" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=1800,setvar:ip.bf_counter=0"
</LocationMatch>
 
S

stormy

Well-Known Member
#3
#3
I've had success with what appears to be a variant of the one you posted:

Code: 
<LocationMatch "/administrator/index.php">
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:00113
SecRule user:bf_block "@gt 0" "deny,status:403,log,id:00114,msg:'IP address blocked for 5 minutes. More than 3 Joomla POST requests within 10 seconds.'"
SecRule REQUEST_METHOD "^POST$" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/10,id:00115"
SecRule ip:bf_counter "@gt 3" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"
</LocationMatch>
 
W

wanah

Well-Known Member
#4
#4
Yes, I adapted that one to fit my needs. I didn't like the 3 in 10 seconds and prefered 15 in 3 minutes.

Adding just the Jooomla and the Wordpress rule reduced the load on our server by nearly half and hasn't noticibly reduced the response times. I'm quite impressed by litespeed's implementation of mod security. :)
 
W

wanah

Well-Known Member
#7
#7
Hello,

The rule mentionned above created false positives.

I'm now trying the following rule that's closer to wordpress's one :

Code: 
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:10011
<LocationMatch /administrator/index.php>
        # Setup brute force detection.

        # React if block flag has been set.
        SecRule user:bf_block "@gt 0" "deny,status:403,log,msg:'ip address blocked for 5 minutes, more than 15 login attempts in 3 minutes.',id:10011"

        # 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:10012"
        SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:10013"
        SecRule ip:bf_counter "@gt 15" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"
</locationMatch>
Found here :
http://forum.joomla.org/viewtopic.php?f=621&t=810233#p3159172
 
S

stormy

Well-Known Member
#8
#8
Yes, the rule I am using does create false positives. I didn't have any report until today, but I can see it in the logs.

I'm going to test your rule. How's it working for you?
 
S

stormy

Well-Known Member
#9
#9
The new rule is better but it still creates false positives. The problem is that many legit operations inside Joomla's administrator area cause a lot of requests, and admins get blocked.

Any ideas?

I don't think this can be solved until Litespeed can scan the response body.

It would be great to have some official comment.
 
M

Michael

Well-Known Member
Staff member
#10
#10
Howdy,

Ask and ye shall receive: Response body scanning is going to require the API we're working on in OpenLiteSpeed 1.3 right now. Because it's still in development (and on OpenLiteSpeed) it's going to be some time before we'll be able to support response body scanning on Enterprise.

Michael
 
S

stormy

Well-Known Member
#11
#11
Thanks Michael! :)

About the false positives, a possible fix would be for that rule to be executed ONLY in "/administrator/index.php", ignoring any string queries. How can I do that?
 
W

wanah

Well-Known Member
#12
#12
I don't suppose we could make use of args ? I haven't checked what joomla's variables are named or even if they always have the same name, but I'm thinking of something along the lines of checking if ARGS.password and ARGS.username are set ?
 
W

wanah

Well-Known Member
#13
#13
Hello,

I've just installed Comodo WAF rules and have disabled all groups except the one that contains the 4 brute force rules.

I'm now watching for Joomla and Wordpress brute force attacks (haven't got any at the moment) and also for false possitives.

I will update this thread in a few days when I've had enough time to make sure there are no false possitives and that the brute forces don't continue.
 
W

wanah

Well-Known Member
#15
#15
I had issues getting the rules to detect anything, that's when I noticed that the following line in modsec2.conf :

LoadFile /opt/lua/lib/liblua.so

was commented.

I uncommented it and restarted litespeed. It imediatly detected the ongoing brute force for wordpress that I had noticed but just once, almost as if detecting the brute force once made something crash in litespeed.

I'm waiting for an answer from comodo about this, but could it be a bug in the litespeed modsecurity engine ?
 
S

stormy

Well-Known Member
#17
#17
Still having a lot of false positives with the Joomla rule, although it's better than nothing. Image gallery modules are a problem because they generate a lot of requests.
 
W

wanah

Well-Known Member
#18
#18
It seems that the only way to do this correctly requires a feature that litespeed doesn't support. This is becomming quite urgent for us…
 
W

wanah

Well-Known Member
#19
#19
Will litespeed 5 have response body support when it makes it to stable ?

About half of our server ressources go to brute force attacks, forgetting about the security impact, just the ressource usage alone is costing us alot.

Recently attacks have been from bot,ets with lots of ip's and manually blocking each IP is very time consuming.

Thinking about trying to use geoip to block access to /administrator and wp-login.php in .htaccess file to try and reduce some of these attacks, mainly at the moment from russia and ukraine.
 
You must log in or register to reply here.
Top