Security Abuse Rules not working correctly - Denial of Service (DOS) - SM 15.7.6474

Problem reported by Jay Altemoos - 1/18/2018 at 3:41 PM

Submitted

Maybe it's just me, but is there a way for me to run a report to see who tripped one of my security measures in SM? We are running SM Enterprise Version 15.7.6474. The reason I ask is because I have a Denial of Service (DOS) rule setup for SMTP. Time frame 2 minutes, 20 connections before block. Well today one of my clients for whatever reason tripped the rule and their entire office got blocked from sending email. The rule currently is set to 5 minutes for the block but their connection was blocked for 1.5hrs. before they called me to find out what is wrong. So it seems that the rule is bugged big time. It should have released the connection in 5 minutes but I am guessing since their mail client kept trying to connect and send it prolonged the rule.

Looking at my SMTP log, which is where I started they were sending emails out previous to the rule getting tripped but far enough in between that they should have never tripped the rule. 1 user would send an email and then about 4-5 minutes later another user from the office would send a message and so on. So the 20 connections should not apply here unless the rule is counting POP and IMAP connections too. Which is why I set the service to SMTP, it should be looking at total SMTP connections in that time frame that I specified correct? And then trip the rule if someone gets the connections before block number. Am I correct in this thinking?

Is there a reason why we don't have a specific report for Security? It seems that we should. That way I don't have to guess when I have to sift through 8 million lines in my SMTP log to find out why someone was blocked. In fact, at no time did the SMTP log report that this user tripped the DOS rule, one entry showed them sending an email to a client and then 6 minutes later there's entries in the log specifying 421 server busy error. Here's a snippet of what I am talking about from the SMTP log:

    Line 177111: 14:22:23 [XX.XX.XX.XX][46528154] disconnected at 1/18/2018 2:22:23 PM
   Line 178830: 14:28:56 [XX.XX.XX.XX][47845102] connected at 1/18/2018 2:28:56 PM
   Line 178831: 14:28:56 [XX.XX.XX.XX][47845102] "421 Server is busy, try again later." response returned.
   Line 178832: 14:28:56 [XX.XX.XX.XX][47845102] IP blocked by brute force abuse detection rule

So as you can see the rule should not have tripped at all. There's 6 minutes in between the connections via SMTP from their IP address. I could see if all their office staff sent an email all at once in the office at the same time for the rule to trip. But at no time should this have tripped like it did if this is just supposed to count towards SMTP connections. In fact I have had this rule in place for months. So who knows how many times it tripped and I never knew about it unless someone called me.

4 Replies

Reply to Thread

Jay Altemoos Replied

1/19/2018 at 8:49 AM

Just to add some info here, the log shows "IP blocked by brute force abuse detection rule" but in reality in the "Current IDS Blocks" list the correct rule was listed for the SMTP DOS block for their IP. So even the log file does not even report the correct rule. We really need a security report and have it show the proper rule that got tripped. That would make troubleshooting these types of issues a whole lot easier instead of skimming through millions on entries in the SMTP log. Our logs get quite large and it takes forever to go through them. I would think that a security report would be a lot smaller and save a lot of time.

Employee Replied

1/19/2018 at 9:13 AM

Employee Post

Jay, does the admin logs show anything that would correlate to bad login attempts? Regardless, I agree that a security log specifically to log IDS rules could be beneficial. I've added to our feature requests list for inclusion in SM 17.x. In the mean time, I will try to replicate your scenario in my test environment.

Jay Altemoos Replied

1/19/2018 at 9:42 AM

Good morning Robert.

Thank you for the reply on this. To answer your question on the Admin log, I checked and all login attempts from their office IP were successful logins. At no point was there a bad login attempt happening. Plus with the DOS rule, this should really just be SMTP connections correct? Or does it look at POP and IMAP connections as well?

The rule is set as follows:

Detection Type: Denial of Service (DOS)
Service: SMTP
Time Frame: 2 minutes
Connections Before Block: 20
Time to Block: 5 minutes

So with that said, the way I see this is the rule should be paying attention to the SMTP service correct? Between the SMTP log and the Administrative log at no point did either log give us any indication there was a problem. One minute they are sending email just fine and then a few minutes later the log shows "421 server is busy". All emails are sent from their static IP at their office.

Employee Replied

1/19/2018 at 9:56 AM

Employee Post

You are correct that the DOS rule counts only SMTP connections not the POP or IMAP connections. Those protocols have their own separate DOS rules. As stated above, I am testing the scenario in my test environment.

Back to Community Threads

Please leave this box unchecked

4 Replies

Reply to Thread

Tags

Related Knowledge Base Articles