Where are the IDS Logs?

Question asked by Paul R - 9/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.

5 Replies

Reply to Thread

Andrea Free Replied

9/5/2018 at 1:37 PM

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 Free
SmarterTools Inc.
877-357-6278
www.smartertools.com

Jeffrey Wilkinson Replied

9/6/2018 at 9:16 AM

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.

Alaa Majzoub Replied

3/16/2019 at 6:58 AM

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?

Chase Hubbard Replied

7/31/2019 at 7:52 AM

After dealing with this problem for a while, I finally figured out a way to do this. I figured I would share, and hopefully someone finds these helpful.

To get to your logs, go to Troubleshooting -> View Logs. Then change the type of log to SMTP (these may have to be enabled for detailed logging, I am not sure on that).

You need to know the IP in question, so if you know it, you can skip this step
- To find the IP - search the SMTP logs for the domain in question
  - CTRL+F for "authenticating as" to find the IP
  - Or you could always just ask your client for the IP
Take that IP and search the SMTP logs again
- CTRL+F for "Authentication failed"
  - From here you can see specifically which user had the failed authentication attempts

As a quick edit for this - I was under the assumption at the time of writing that SMTP logs would contain all failed info, and that is incorrect. As mentioned above, you may need to set your IMAP/POP logs to 'detailed' and then use the steps above for those logs if searching SMTP logs doesn't cut it.

Paul R Replied

7/31/2019 at 12:31 PM

That's what Jeff and I ended up doing in that instance, because we knew the IP of the offending office. We usually diagnose by IP as a rule, given the lack of IDS logging.

Thanks for the tip, tho. I'm sure your tip will make someone day easier.

Back to Community Threads

Please leave this box unchecked

5 Replies

Reply to Thread

Tags

Related Knowledge Base Articles