We have enabled Suspicious IP Throttling but whitelisted 4 IP addresses using the IP AllowList. However, one of the IP addresses in the AllowList is occasionally blocked. When I query logs with “type:limit_mu” if see an event with the description:
“Someone behind the IP address: xx.xx.xx.xx attempted too many consecutive logins with different usernames. A shield to prevent this attack is enabled, further attempts are blocked from this IP address”
IP address xx.xx.xx.xx is included in the AllowList so I do not expect this log event. Is this expected behavior? If so, are there limitations to the IP AllowList?
I understand that you are encountering issues with Suspicious IP Throttling.
First, I’d like to clarify that the limit_mu log event type describes an event where:
An IP address is blocked with 100 failed login attempts using different usernames, all with incorrect passwords in 24 hours, or 50 sign-up attempts per minute from the same IP address.
Because of this, could you please clarify if you have a script performing a large number of logins/signups?
Next, given that only one of the whitelisted IP addresses is occasionally blocked, could you please clarify if the issue persists when using another whitelisted IP address to perform your operations?
That’s correct. Including an IP address in the IP AllowList will not have attack protection enforced against them.
Note that there are special cases involving Resource Owner Password flows. If applicable, you may find our documentation on handling special cases with resource owner password flows useful: Suspicious IP Throttling Special Cases
We have web application that is running within a VDI infrastructure. The IP address that is exposed to Auth0 is the same for all users. We onboarded a significant number of user around the time of this event, so I’m not surprised to see a large number of failure. Additionally, the users are logging in via a database connection and a DB timeout will cause a failed login attempt. We white listed the IP address of the VDI infrastructure to address these type of issues.
Turns out the IP white listing wasn’t a complete solution, or at least the one we initially implemented. We also ended up needing to update the security/attack protection/suspicious IP throttling section as well as the brute-force protection sections to allow traffic to pass without security blocks creating problems.