Brute force detected, throttle

J

jkeegan

Active Member
#1
#1
I am seeing lines like these in my error logs:
Code: 
2018-01-10 22:11:03.423 [NOTICE] [XXX.XXX.XXX.XXX:39804] Brute force detected, throttle.
I know the IP Address is from a Cloudflare Railgun on my network, so I do not want its access to ever be throttled. I assumed the throttling was being caused by the new WordPress Brute Force Attack Protection feature. So I disabled that, but still getting the throttling error. The IP Address has been added to the Allowed List under Access Control...

So how do I get Litespeed to stop throttling this IP?
 
Last edited by a moderator:
M

mistwang

LiteSpeed Staff
#2
#2
Please update to the latest build of 5.2.3 with command
Code: 
/usr/local/lsws/admin/misc/lsup.sh -f -v 5.2.3
the cloudflare IP is not the IP being throttled. the log message has been updated with the correct IP.
 
Last edited by a moderator:
J

jkeegan

Active Member
#3
#3
OK I had been running 5.2.3 but ran the updater, perhaps I had an earlier build. But just as FYI the IP address noted in LSWS error_log was the IP of the Railgun on my network, not the external Cloudflare IP... Will let you know if I see any different behavior with the new version.

But to be clear, is this message a result of the new WordPress Brute Force Attack Protection feature? What exactly is causing the throttling?
 
J

jkeegan

Active Member
#4
#4
OK now in the logs I see the new format,
Code: 
Brute force detected for IP [XXX.XXX.XXX.XXX], throttle.
2018-01-10 23:49:37.523 [NOTICE] [XXX.XXX.XXX.XXX:42318] Brute force detected for IP [YYY.YYY.YYY.YYY], throttle.
where XXX.XXX.XXX.XXX remains the Cloudflare Railgun server on my network and YYY.YYY.YYY.YYY is the remote IP. But the railgun server on internal network continues to show these errors:
Code: 
origin timeout: cloudflare/http: timeout awaiting response headers
concurrent to the errors appearing on the Cloudflare log... So it looks like LSWS is throttling my internal railgun (like a proxy) and not the original IP of the offender...
 
Last edited by a moderator:
M

mistwang

LiteSpeed Staff
#5
#5
that's as expected, as all traffic proxy through railgun, LSWS does not talk to the abusive client IP directly.
However, only request for the specific client IP is throttled. other visitors through railgun wont be affected.
 
J

jkeegan

Active Member
#6
#6
OK but I am 100% certain the Railgun is being affected. I am tailing both LSWS' error_log and the messages log on the Railgun server, and whenever LSWS issues
Code: 
Brute force detected for IP [xxx.xxx.xxx.xxx], throttle.
the railgun rg-listener log shows
Code: 
origin timeout: cloudflare/http: timeout awaiting response headers
. At that point, ANY user on the site sees a Cloudflare error...

So this is still an issue for me... Any other information I can share to help shed light on this?
 
M

mistwang

LiteSpeed Staff
#7
#7
the brute force request going through Railgun, LSWS throttle it, Railgun detects that request timed out, Railgun failed the request, the client sending the abuse request see a failure.
That's all suppose to happen in this setup. It IS the desire effect of this feature.
Only if the throttle affect other users going through Railgun, that is a problem. but, it is likely a Railgun issue, if it mix other requests with this throttled request together, so other requests got affected. But I doubt it is the case.

What you see is what suppose to happen. And there is nothing we can do about that, only the detected brute force request are throttled and get an error reported by Railgun.
If you do not want to see any error in Railsgun, means that LSWS cannot throttle any attack, just turn the whole feature off.
 
J

jkeegan

Active Member
#8
#8
OK thanks for clarifying. If I do see other requests get affected, how do I turn the throttling off?

That's part of what I was asking originally, what piece of LSWS is actually doing the throttling and how is it that the requests are getting throttled if I have added the Railgun IP to the Allowed List under Access Control?
 
J

JVQ

Member
#10
#10
It is possible to extend this protection to other files with configuration changes? For example in cve-2018-6389 adding similar ratelimiting to load-scripts.php could be beneficial.
 
You must log in or register to reply here.
Top