5 ms·
Have you considered more conservative rate-limiting external IPs on login endpoints? E.g. with nginx it will make sense to set a custom rate limiting zone to p
by alexk 9y ago
Have you considered more conservative rate-limiting external IPs on login endpoints?
E.g. with nginx it will make sense to set a custom rate limiting zone to prevent many requests from the same IP specifically to the login page:
https://www.nginx.com/blog/rate-limiting-nginx/ https://www.nginx.com/blog/rate-limiting-nginx/
This will not fix the root cause, but will make it considerably harder to scan for matching passwords.
You can also set up Fail2Ban to block IPs that failed to authenticate many times:
https://serverfault.com/questions/421046/how-to-limit-nginx-auth-basic-re-tries https://serverfault.com/questions/421046/how-to-limit-nginx-...
- methodover 9y agoWe do have fail to ban type logic in place. The attacker used a botnet; requests came in from many different IP addresses.
- greenyouse 9y agoHave you tried rate limiting based on the user account? That should block a distributed attack since each login would count against the rate limit independent of the IP address.
- ScottBurson 9y agoHow would that help in this situation? The attacker had a database of user/password pairs they were trying; they weren't trying to brute-force a particular account.
- greenyouse 9y agoOops, you're completely correct. I was thinking of the brute force scenario.