9
Fix IDS in the "NEXT" SmarterMail -- Everything Logged by IP Address -- VOTE NOW!!!
Idea shared by Howell Dell - 9/1/2023 at 9:10 AM
Proposed
The IDS Rework is NOT helpful in stopping the HACKERS!!! I am running SmarterMail Build 8566 (Jun 15, 2023). We have hackers that are trying to login to eMails accounts that may or may not exist, however, while they are getting blocked which is great...

The block is NOT logged against an IP Address like SMTP. If this happened for a valid eMail Address, it also locks out the REAL user. When this happens, I have to manually go in to the IDS and unblock them.

1. "Password Brute Force By Email" should be logged against an IP Address which would allow the "real" user to continue to login without an issue while ONLY blocking the hackers. This also does not tell us the source SMTP, POP, IMAP, WebMail, EAS, EWS nor MAPI.

2. If you have 2FA enabled and you enter a bade 2FA Code it is logged into the Administrative Log, however, the IDS does not block this as it would with just a username and password. The hackers are doing this all the time. In the log you see:

[2023.09.01] 15:52:37.328 [192.168.168.200] Webmail Login failed: User [<eMail Address>] gave invalid two step code from rfc

3. We needs IDS Rules for EAS, EWS and MAPI as these protocols are getting very popular

3. For the IP Address BlackList we don't have an option to block access to Web Mail by IP Address

6 Replies

Reply to Thread
3
Amen to that!

+1
2
yes, this is important to be optimized
0
One thing I was just reading is about the move, by SmarterTools, to proxy HTTP requests to Kestrel directly as part of the move to .NET Core which apparently is coming very soon (Weeks? Month? This was discussed quite some time ago in 2021 -- https://portal.smartertools.com/community/a93846). I had mentioned my VoIP Provider did the same -- enabled cross-platform, however, their code base is C++, however, they moved away from .NET quite some time ago.

Certainly, with this concept we can easily add significant more IDS functionality inside SmarterMail Web UI to enforce more control over who is allowed to access all of the HTTP protocols (EAS, EWS, MAPI and Web UI) to slow, pause and/or stop hacker activity.

+1 idea: Another Security thing is that RBLs lookups should apply EAS, EWS, MAPI and Web UI. By doing this I can automate a lot of security I now do manually.

The question becomes I guess we have to wait for the .NET Core Version?

Specifically, I would like to see an HTTP option in the IP Address Blacklist for all of the new protocols EAS, EWS, and MAPI along with general SmarterMail Web End User UI. SMTP, POP and IMAP are now legacy protocols as far as I am concerned given significant feature parity with the above Microsoft specific protocols for Outlook with MAPI, and gMail with EAS. Plus we have eM Client but I have to learn about that one.

TechNote: I had to lookup Kestrel -- this is an open-source and cross-platform Web Server that is written using .NET Core, by Microsoft, and supports IIS and NGINX and in theory can be Docker-ized. Linux has not had Web Sever process isolated for a long time, but Docker has simplified all of this. If you read the post elsewhere SmarterMail is moving to .NET Core and opens lots of possibilities which I won't opine on here.
1
Andrew Barker Replied
Employee Post
Howell,

I'll try to address each of your points here.

1. "Password Brute Force By Email" should be logged against an IP Address which would allow the "real" user to continue to login without an issue while ONLY blocking the hackers. This also does not tell us the source SMTP, POP, IMAP, WebMail, EAS, EWS nor MAPI.
The Password Brute Force by Email rule type is designed as a measure to interrupt distributed attacks - that is, multiple attempts to authenticate an account from multiple IP addresses. In such attacks, it is likely that no two triggering authentication failures come from the same IP address, so there isn't typically a single IP to block when the rule is triggered.

Password Brute Force by IP is designed to address multiple attacks coming from the same IP address. whether the attacks are against the same account or not.

If you are seeing many cases where the Password Brute Force by Email rule is being triggered by failed attempts from a single IP, it may benefit you to add a Password Brute Force by IP rule. If you already have a brute force by IP rule, it may be worthwhile to review the limits on your rules and consider adjusting them to better handle the specific types of attacks you are seeing.

As for the source of the block, IDS rules currently work independent of protocol. This means that the rules can be triggered even if the attacker spreads their authentication attempts over two or more protocols. However, if you check the administrative logs, you should see entries like this to help you track down which protocols are being used in the attacks:

00:15:06.639 [98.185.70.250] MAPIEWS NtlmAuthenticate Login failed: Authenticate parse failed for <user@example.com>.
        Brute force attempts increased to 1 of 25 in 5 minutes.
        User brute force attempts increased to 1 of 50 in 10 minutes.
        Next clean available at 8/30/2023 12:15:56 AM
2. If you have 2FA enabled and you enter a bade 2FA Code it is logged into the Administrative Log, however, the IDS does not block this as it would with just a username and password.
This sounds like a potential bug. Please open a support ticket so we can gather more details.

3. We needs IDS Rules for EAS, EWS and MAPI as these protocols are getting very popular
In the current version of SmarterMail, most of the IDS rules are protocol independent and will track failed authentications for webmail, IMAP, POP, EAS, EWS, etc. The only exceptions to this are the "Bad SMTP Sessions (Harvesting)" as that rule is specific to an attack that only works over SMTP, and the "Internal Spammer" and "Bounces Indicates Spammer" rules which operate at the spool level.

3. For the IP Address BlackList we don't have an option to block access to Web Mail by IP Address
The current implementation of the IP Blacklist is designed to prevent socket connections, which are easily managed for IMAP, POP, and SMTP. Webmail, EAS, EWS, MAPI, and WebDAV are all HTTP based communications, so they have not been made options in the IP Blacklist. However, with some of the changes we are working on, we have been discussing how we can add these protocols as options for the IP Blacklist and Whitelist.

Andrew Barker
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com

1
I have already reported this issue and have done so again, however, it was rejected saying this was a feature and NOT a BUG! I just opened another to try again.

The problem with the new IDS is it breaks the pattern I've been using for years to analyze the nature of the hacker activity and then go on to block them either in SmarterMail or my Firewall. Regardless of how many IP address the hackers of using I need the source IPs to block them. The goal is to slow down the hackers and have them waste more password guessing attempts.

Further, note is the Hackers have also moved on from just attacking SMTP, POP and IMAP. They know "we" (eMail Services Providers) have moved on to EAS, EWS, MAPI and more directly Web Mail thus we have new quarters to defend.

Frist, I want to say I really like "Password Brute Force By Email" when the hackers try invalid or "old" no longer user eMail Addresses. I can see the hackers trying to break into Web Mail, however, the downside is the real client@example.com is getting locked out as well.

The basic question is what is the value or purpose of the IDS to me? I view it as a tool that slows down the hacker's password guessing activity especially when are using "dumb" scripts. If they try password "xyz" and they don't know they are blocked by IP Address, then Mail Server is just ignoring them -- that is good because the next 100 password guesses effectively are meaningless even if they landed on the right password. Yes, I know we have an eMail harvesting is a problem as well but password guessing IMHO is more vital to stop.

Web Mail access by the real client is an issue.  Because a hacker is attempting password guessing and then client can no longer get access to Web Mail -- now we have moved into a DDOS mode. I unlock the IDS for the client then the hackers continue to try -- now the client is calling and calling -- cat and mouse.

I'm not sure how practical the "Password Brute Force By Email" IDS is without linking it to an IP Address or take a different tack if it is a real eMail Address. I want the IDS be punitive against the hacker only and slow them down -- not the client as well.

So how to I defend against that? Turn off "Password Brute Force By Email" IDS because it is not helping me to defend the Server. Before, when the hackers were going after SMTP, POP or IMAP and we blocked by IP was good because it had no impact on the client 99.99% of the time.


0
I have two eMail Servers and I was testing a different one than I reported. The 2FA issues was tested actually on Build 8451 (Feb 20, 2023) and not Build 8566 (Jun 15, 2023). I just performed the test again, this time against Build 8566 (Jun 15, 2023) to double confirm my findings.

Looks like we have different issues with different builds. Looks like the IDS for Build 8451. 

Unfortunately, Build 8566 may have a different issue with 2FA which I won't chat about for now.

Reply to Thread