Back to Community Threads

Testing the password bruteforce protection

Question asked by Somo IT - Today at 8:50 AM

Answered

Hello,

I'm testing the IDS brute force protection in SmarterMail and I'm seeing some behavior that I don't understand.

I have the default IDS rules enabled, including:

Password Brute Force by Email (Block after 50 attempts in 10 minutes)
Password Brute Force by IP (Delay after 15 attempts, Block after 25 attempts)

To test this, I repeatedly attempted to log in with a valid existing user and an incorrect password.

I tested both:

The Webmail login page.
The REST API endpoint: POST /api/v1/auth/authenticate-user.

After more than 300 failed login attempts:

The Login failures counter increases as expected.
However, IDS Violations remain at 0.
Neither Brute Force by Email nor Brute Force by IP is triggered.
I also don't observe any delay or temporary blocking.

My questions are:

Are the IDS brute force rules supposed to protect both the Webmail login and the /api/v1/auth/authenticate-user API endpoint?
Is there any additional configuration required to enable these rules?
Are there any exclusions (other than trusted/local IPs) that would prevent these rules from triggering?

I'm trying to understand whether this is the expected behavior or whether my configuration is incorrect.

Thank you.

1 Reply

Reply to Thread

Andrew Barker Replied

Today at 10:52 AM

Employee Post Marked As Answer

Are the IDS brute force rules supposed to protect both the Webmail login and the /api/v1/auth/authenticate-user API endpoint?

Yes, the brute force rules help to protect the authenticate-user endpoint. Since webmail login uses that endpoint, both are covered by IDS.

Is there any additional configuration required to enable these rules?

No, simply having the rules configured is enough to enable them.

Are there any exclusions (other than trusted/local IPs) that would prevent these rules from triggering?

One thing to keep in mind is that SmarterMail avoids repeatedly counting identical attempts within a short window. If all your attempts were from the same IP with the same email/password combination, only the first one in that window will be counted. This was added a few years ago after we noticed a couple behaviors that were triggering IDS blocks when we didn't expect them. First, some clients will re-try authentication with the exact same credentials after a failed authentication. The worst I remember seeing was several years ago when an EWS client tried to authenticate 4 times in a row with the same bad credentials. The second scenario we observed was users just submitting the credentials again without changing anything. Since this behavior it is keyed off a combination of IP and provided credentials, and because a hacker won't waste time retrying credentials they know are bad, this allows us to prevent those scenarios from triggering a lockout without reducing the security of the IDS system.

Andrew Barker
Lead Software Developer
SmarterTools Inc.
www.smartertools.com

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text