The recent changes made to IDS rules are still working for IMAP. The only real change is that the rules are no longer protocol specific. This lightened the administrative load and also let us easily extend the IDS rule checks to cover the HTTP based protocols - EWS, MAPI, EAS, and WebDAV.

IDS rules are not triggered for authentication attempts that meet one of the following criteria:

Further, repeated attempts from the same source with the same user name and login are counted at a throttled rate. Repeated attempts using the exact same credentials are typically a result of a client trying to make multiple connections simultaneously, a user having changed their password on the server but not in their client, or something similar.

If you want to test the IDS rules, you need to make the attempts from an external IP that is not whitelisted or bypassed and you need to change the auth credentials you are attempting with for each attempt.

<<<<

IDS rules are not triggered for authentication attempts that meet one of the following criteria:

>>>>

The problem is this: what happens if a criminal hacker manages to get into any of my systems and from this local network tries to forcefully attack the SmarterMail passwords?

Or if he manages to reach the SmarterMail server doing IP Spoofing and presenting himself with an IP that you have arbitrarily excluded from the checks?

From what you say he can try as much as he wants and will never be blocked by the IDS system...

The IDS system must work for ANY IP address, even 127.0.0.1 or a private ip (example: 192.168.1.10/24...).

Then it will be up to the administrator to White List the private IPs he wants.

Excluding from the IDS check all the IPs of the private classes (and/or any other "special" IP) in HardCoded mode without giving the administrator the possibility to decide WHICH are excluded or not is a big security hole!!!!

Hi Gabriele! Any time we've seen the IDS system be problematic for an environment, its usually centered around an internal user who has forgotten to change a password in their connected email clients. As such, these criteria are implemented to prevent these scenarios and prevent the complete lockout when it happens, specially on NAT-enabled networks where all clients report back with the same router IP or something along those lines. As you're aware, that can introduce some potential vectors for problems. But;

The ability to spoof the IP address would need to take place at the network level, and so the recommendation is to handle this at that level before it reaches the SmarterMail server. SmarterMail will see whichever IP address your network hardware passes along as the requesting IP, so implementing controls to prevent spoofing at that level should prevent this possibility. 

Arguably the same approach should be applied for compromised devices on the network as well, as anything on your internal network should be safeguarded and will be highly problematic if compromised, not just for the SmarterMail server but other devices on the network as well. 

This is not to say we could not implement further changes in these areas, just that there are already tools/utilities and suites that are purpose-built for this. If you need any help evaluating specific scenarios please submit a ticket with us and we'll see what we can come up with for you. Have a good one!

I wonder if instead of hardcoding the private IP ranges in the code that we instead whitelist the ranges by default then not touch them again. This would allow our desired behavior to take place while allowing the system admins to simply disable or remove those whitelist entries.

I can try to bring it up next time we do a meeting.

I agree with Brian.

This is simply wrong.

I totally not agree with this hardcoded IP whitelist(which by the way is also invisible and therefore unknown to the administrators...), it's simply an intentional security hole.

A system admin can whitelist local address and loop back address if he wants, and it is simply wrong to enforce it if the admin doesn't want to white list theese IPs...

This is my opinion.

Hardcoding IP whitelists has failed security scans, as some pen tests are initiated from wihin a corporate network, not just from external facing.

There are major attack vectors from within corporate networks, host based protection is one level of security that is a requirement and with these new releases of SmarterMail, I believe it has taken major steps backwards.

Allow the users to make the choices to enable or disable levels of security based on their own requirements.

Just wanted to update this thread based on the meeting we had this morning. We discussed this and we're on board with putting the hardcoded entries in the whitelist. They will not able to be deleted but they CAN BE DISABLED. 

Great!