Where are the IDS Logs?
Question asked by Paul R - September 5, 2018 at 12:37 PM
Answered
Have a customer with a few hundred users in one office.  SOMEONE at that office's IP address is triggering an IDS block on the IMAP service for "brute force password", which is probably just an email client using the wrong password.

But when I go into the IMAP logs, there is no mention of "blocked" nor is the IP even searchable.  Nearly all IMAP log entries show "IP unknown".  When I search by their domain, NO entries appear, but I know many of them use IMAP.

Surely there has to be better IMAP logging than this?  And surely there must be a way to find out exactly who and what is triggering the IDS block, right?

Advice, please? 

Thanks in advance.

3 Replies

Reply to Thread
0
Andrea Rogers Replied
Employee Post Marked As Answer
Hi Paul,
 
What version of SmarterMail are you using? Are your IMAP logs set to Detailed? 
 
In version 16.x, with IMAP logging set to Detailed, information about failed IMAP login attempts and blocked IPs can be found by searching the logs. Here's an example what can be found:
[2018.09.05] 13:28:51 [IP ADDRESS][22941017] connected at 9/5/2018 1:28:51 PM
[2018.09.05] 13:28:51 [IP ADDRESS][22941017] command: A001 CAPABILITY
[2018.09.05] 13:28:51 [IP ADDRESS][22941017] disconnected at 9/5/2018 1:28:51 PM
[2018.09.05] 13:28:52 [IP ADDRESS][32715000] connected at 9/5/2018 1:28:52 PM
[2018.09.05] 13:28:52 [IP ADDRESS][32715000] command: A001 AUTHENTICATE CRAM-MD5
[2018.09.05] 13:28:52 [IP ADDRESS][32715000] admin@domain.com Cram MD5 authentication failed
[2018.09.05] 13:28:52 [IP ADDRESS][32715000] command: A002 LOGOUT
[2018.09.05] 13:28:52 [IP ADDRESS][32715000] disconnected at 9/5/2018 1:28:52 PM
[2018.09.05] 13:28:52 [IP ADDRESS][22504973] connected at 9/5/2018 1:28:52 PM
[2018.09.05] 13:28:52 [IP ADDRESS][22504973] command: A001 LOGIN "admin@domain.com" XXXX
[2018.09.05] 13:28:52 [IP ADDRESS][22504973]  login failed
[2018.09.05] 13:28:52 [IP ADDRESS][22504973] command: A002 LOGOUT
[2018.09.05] 13:28:52 [IP ADDRESS][22504973] disconnected at 9/5/2018 1:28:52 PM
[2018.09.05] 13:32:24 [IP ADDRESS][58343826] connected at 9/5/2018 1:32:24 PM
[2018.09.05] 13:32:24 [IP ADDRESS][58343826] command: A001 CAPABILITY
[2018.09.05] 13:32:25 [IP ADDRESS][58343826] disconnected at 9/5/2018 1:32:25 PM
[2018.09.05] 13:32:25 [IP ADDRESS][15963847] connected at 9/5/2018 1:32:25 PM
[2018.09.05] 13:32:25 [IP ADDRESS][15963847] command: A001 AUTHENTICATE CRAM-MD5
[2018.09.05] 13:32:25 [IP ADDRESS][15963847] Closing transmission channel: too many authentication failures from this IP
[2018.09.05] 13:32:25 [IP ADDRESS][15963847] command: A002 LOGOUT
[2018.09.05] 13:32:25 [IP ADDRESS][15963847] disconnected at 9/5/2018 1:32:25 PM
[2018.09.05] 13:32:25 [IP ADDRESS][42427958] connected at 9/5/2018 1:32:25 PM
[2018.09.05] 13:32:25 [IP ADDRESS][42427958] "421 Server is busy, try again later." response returned.
[2018.09.05] 13:32:25 [IP ADDRESS][42427958] IP blocked by brute force abuse detection rule
[2018.09.05] 13:32:25 [IP ADDRESS][42427958] disconnected at 9/5/2018 1:32:25 PM
 
When an IP address is blocked due to brute force, you can also find and remove that block in IDS Blocks (within the Manage section of the Admin login). The IP's Description column should show something like "IMAP Password Brute Force strict rule". And if you whitelist the office IP, it will prevent the IP from being blocked in the future. 
 
I hope this helps! 

Andrea Rogers
Communications Specialist
SmarterTools Inc.
877-357-6278

www.smartertools.com

0
We're running version 16.3.6816. Rather than white-listing the IP, we need to determine which specific user is at fault so the appropriate corrections at their end can be made. I don't want to give ~200 users a "pass" from bad behavior via white-list. Thanks for the tip on logging level-- for some reason that hadn't crossed my mind. Set IMAP to Detailed, so we should (hopefully) have our culprit shortly.
0
Alaa Majzoub Replied
Any news about this thread is there a way to know the email making the IDS to trigger.

As mentioned above, one user can cause the whole office to stop, while knowing the email making the block can save the office admin a lot of problems.

Sometimes the office has a dynamic IP, so whitelisting the ip would not solve the issue, when the ip is released with a new one, the same email making the problem will trigger the IDS to block the new ip which will result in blocking the whole office again.

Can we detect the email making such a trigger?

Reply to Thread