4
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.

12 Replies

Reply to Thread
0
Employee 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! 
0
Jeffrey Wilkinson Replied
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?
0
Chase Hubbard Replied
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.
1
Paul R Replied
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.
1
Sérgio Rocha Replied
Hi,

It will be nice have logs on IDS, we are dealing with a clients with user that use pop and IMAP. Its a pain look in IMAP, POP and SMTP to find what account its blocking the IP.

It will be nice to have IDS log: block the IP X because of the threshold Y in protocol A,B,C with the account Z at HH:00, 

I think that is a simple request and will speedup our support. 
Some staff have access to SM interface, but don't have access to server file system, need to escalate the problem and an issue that can be solved in 5 minutes take days.

Regards,

SR
2
Andrew Barker Replied
Employee Post
Sérgio,

The current version of SmarterMail includes logging for the IDS brute force rules similar to what you are looking for in the Administrative logs. Look for entries like this:

00:00:27.103 [IP ADDRESS] SMTP Login failed: Invalid username (EMAIL ADDRESS) and password combination.
	Brute force attempts increased to 6 of 25 in 600 minutes.
	User brute force attempts increased to 1 of 50 in 10 minutes.
	Next clean available at 10/12/2023 12:01:16 AM
The line starting with "Brute force attempts..." indicates the progress toward triggering a Brute Force by IP rule, while the "User brute force attempts..." indicates the progress toward triggering a Brute Force by Email rule.

The administrative logs will also include lines like the following when a rule is triggered:

0:01:32.308 [IpBruteForceDetector] [IP ADDRESS] Added to IDS block list for violating rule Type: Password Brute Force by IP, Description: Default Brute Force by IP rule
00:01:32.310 [IpBruteForceDetector] Added IP ADDRESS to IDS block list. Duration: 30000 seconds, Description: Default Brute Force by IP rule
Due to the order of handling, these lines should be shortly before an entry like the first I provided which indicates the count has been reached.
Andrew Barker Software Developer SmarterTools Inc. www.smartertools.com
0
Sérgio Rocha Replied
Hi Andrew,

I switch the administrative log for detail, ans I dont se any logs like you send.
Can you confirm that de log is the Administrative? I only the lines like this:

(2023.10.17-administrative.log)

17:40:15.826 [1x.8x.210.96] [AUTHENTICATION SERVICE] 1 guidHash was null
17:41:38.216 [1x9.4x.34.89] [AUTHENTICATION SERVICE] 1 guidHash was null
17:41:38.545 [14x.69.1x0.211] [AUTHENTICATION SERVICE] 1 guidHash was null
17:41:48.076 [1xx8.69.2x4.7] [AUTHENTICATION SERVICE] 1 guidHash was null

Regards,

SR
0
Andrew Barker Replied
Employee Post
Yes, the examples I provided are for entries in the Administrative log. The examples I provided are how we have logged data for IDS brute force rules since build 8495.

The first example I provided is only really applicable for Password Brute Force by IP and Password Brute Force by Email rules.

The second example I provided is specific to Password Brute Force by IP rules, but similar entries will be made when Password Brute Force by Email or Password Retrieval Brute Force rules are triggered.

When other types of IDS rules are triggered, an entry like this one should be created in the Administrative log:

[IDS_TYPE IP_ADDRESS] Added IP to IDS block list. Duration: 30000 seconds, Description: RULE_DESCRIPTION
Andrew Barker Software Developer SmarterTools Inc. www.smartertools.com
0
Sérgio Rocha Replied
Hi Andrew,

I can see nothing like that. Do I need to stop service after change of log level to detail?

Regards,

SR
0
Sérgio Rocha Replied
Hi Andrew,

After a service restart I'm seeing the log with full detail.

Thanks,

SR
0
Sérgio Rocha Replied
Hi Andrew,

The logs area better now, but I'm dealing with a DDOS block for a client IP. I can see smtp connection going well and then the information about the DDOS block with the blocked IP, But I don't now what was the reason to block. 

I don't see to many logon request by minute in the log, if I check User connection page,  IMAP/POP and SMTP by IP they have 2 connections for imap and most of the time 0 for POP or SMTP.

Can you propose the enrich this administrative log with more useful information, I hate whitelist.

Regards,

SR

Reply to Thread