Password Brute Force by Protocol, show the user that failed authentication
Idea shared by Tim DeMeza - May 2 at 8:59 AM
Under Consideration
If a rule such as "Password Brute Force by Protocol", can you please show the email address of the user that failed authentication.  It would make cleaning this up if a user blocked themselves so much easier.  Also, it should show me which users to make aware of a stronger password.  

8 Replies

Reply to Thread
1
This is a great idea. Though I assume it would just show the email address that triggered the block, as if the IP is hammering the server with all sorts of bogus logins, the field may be misleading.

Christopher

0
@echoDreamz I completely agree, but it is another piece of data that will help us quickly identify issues and reach out to specific users if needed, etc.  I just think we need more info in the reports to make them more useful to all of us.  I would also love to see a notification that can be triggered that says something like: user@domain.com has attempted to log into the mailserver from > X unique IP addresses.  I would also like to see that if the user is authenticated and logged into the server from > X unique IP addresses.  It's just another tool to allow us to quickly identify and remediate issues if needed.
0
Kyle Kerst Replied
Employee Post
This has been submitted as a feature request. Great suggestion!
Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Hi Kyle,
Has this gained any traction?  It really would have helped me find an account that has been isolated and getting hit with login attempts.  

Thank you,
Tim

0
Kyle Kerst Replied
Employee Post
Tim, it looks like this one is still on our discussion list for the future. With our focus currently being on MAPI it may be a couple more weeks at least before we have any real feedback on these and other feature requests. 
Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
This concept could actually be taken further.

What if abuse detection rules allowed for a user provided script/program to be run when a rule has been triggered and for key parameters such as email address getting hit by brute force attacks or IP address of failed login attempts etc to be passed to the script.  This script/program could then interact with the server environment to enable further security actions.

That way, installation specific actions could be configured  that greatly expand the management of the rules once triggered.  An example would be being able to block persistent attackers at the firewall level thereby taking the load of SM or creating additional infomation such as user login by country and (possibly) acting on it.  I currently check the list of failed login attempts and if a particular IP/country is over represented, I block it at the firewall level.  
Yes, admin intensive and maybe OTT but when you are being hammered by certain countries, blocking IPs at the firewall level is the only real alternative.






0
I asked in another thread for another simple idea: keep a list of IPs that triggered the abuse detection rules (I know you can find them in the logs, but come on - we cannot spend our lives continuously combing logs) which should be viewable in the Web Interface and you should be also able to download it.

This way one could use API to retrieve the list or download a CSV, which then can be imported in another system (e.g. we block repeat offending IPs at the edge firewall, but maintaining this manually is a real pain).
1
Bumping again, just to get an update.  

Hope this doesn't drive the ST folks nuts.

Thanks!

Reply to Thread