The Password Brute Force By Email IDS rule type doesn't determine whether an account exists or not. It just tracks how many times a given email address was used to attempt authentication. If enough failed attempts occur, then the account is blocked by IDS.

Shouldnt it block the offender and not the account?

It doesn't seem to do that any longer.

I used to have hundreds of blocked IP addresses. Now I have only a few blocked IP Addresses and a few blocked accounts. I guess none of the IP Addresses that are attempting to login to the blocked accounts end up getting blocked. So, as soon as I unblock an email account, a few more "non-blocked" IP Addresses will end up getting the account blocked again...even if those "non-blocked" IP Addresses have been trying to hack into an account while it was blocked.

Thats not good... that was one of the reasons I moved away from Mailenable.

It should block the offender and not the offended.

SM has always blocked the source IP and the account.   Blocking the account is needed for protection against distributed attacks.   Blocking the server is needed to protect against account guessing by a single server.

If something has changed in your release, I would suspect that it is related to the DNS performance problems.   But support should be able to help you parse logs to prove if IP blocks are being applied correctly.

Imagine a very busy server with thousand of users.... one would need to hire a team to support the annoyed uysers that gets locked out of their accounts.

That cannot be true that you have to accept that in these modern times.

Brian,

As Douglas mentioned, SmarterMail has different IDS rule types to prevent different attack scenarios. The two relevant to this thread are the Password Brute Force by Email and Password Brute Force by IP. Password Brute Force by IP is intended to block attacks coming from a single IP. These could be attempts to access a single account, or several different accounts. Password Brute Force by Email is designed to prevent distributed attacks against a single account - where multiple attempts to access an account come from multiple IP addresses. With a distributed attack, the only form of mitigation available is to lock the account being attacked, as there is no single IP to block. It is even possible that every attempt could come from a unique IP address.

If you want to prevent accounts from being locked by IDS rules, you will need to disable the Password Brute Force by Email IDS rule. However, this would leave your server open to distributed attacks

Thanks Andrew :)

Andrew,

I do indeed see the distributed attacks... What happens to the IPs that attempt AFTER the email address is locked? Do they get recorded?

Brian

If an attempt is made to try logging into an account that is blocked by IDS, future attempts to connect are recorded in the relevant protocol log. Most of the protocol logs use a message along the lines of "too many authentication failures", while SMTP uses the phrase "Authentication failed - blacklisted". These messages should show the IP address the request came from, and should also indicate whether it was the account or the IP that was blocked.

Would it be an option to limit the amount of IP's that try to log on to an account and blacklist it that way?

Like 10 IP's every 2 minutes and then block the offending IP's??

A normal user comes from a single IP and not 10 different ones within 2 minutes....

Couldn't this potentially result in the server DOS'ing itself at some point?  Imagine if an attacker flooded the server with, say, 10 million bogus login IDs and passwords enough times to trigger the IDS/IPS and fill the blocklist with million and millions of entries.  This would be almost trivial with even the most basic of botnets, or a few well-connected PCs.

Wouldn't that put an undue load on the server, having to parse a HUGE blocklist every time a legitimate login is made, to verify that the (legitimate) user isn't blocked before granting access?

I agree with the others-- at some threshold the IP itself needs to be blocked.  Not so aggressive that some clueless user with a misconfigured mail client ends up getting the whole office blocked, but also sane enough to keep an attacker from building millions (or even thousands) of entries onto the blocklist.

 

Don't forget that local lP addresses are hard-code-whitelisted now. 🤦‍♂️

Jay,

That scenario can be mitigated by the Password Brute Force By IP rule. If both Brute Force by IP and Brute Force by Email rules are configured, then a typical botnet would trigger both rules, blocking their IPs and the accounts they were trying to access, probably well before they had blocked hundreds of user names, let alone millions.

It took adjustment and tweaking but we managed to find a balance between the distributed attack Password Brute Force by Email and Password Brute Force by IP -- we set the IP timespan very long and the block time very long -- so long-term attacks or slow-rolling spam attacks are caught.  We set the Email timespan to be very short -- with a lockout timeout of 10-20 minutes.  We've seen good success with IPs getting caught while the email account lockouts are down to a minimum.  No solution will perfect but having some control over the timespans and offense counts made a huge difference over our MailEnable installation.