Best Practices for Stopping POP3 and SMTP Brute Force Attacks with the Abuse rules.
Question asked by network admin - February 24, 2017 at 12:38 PM
Unanswered
    Am hoping that y'all might share your suggestions for best settings on the ABUSE brute force attack rule sets.  Any changes?  Anyone able to tell me the difference between relaxed and strict?  When looking at SMTP logs at the Admin level and searching on "Authorization failed" I was quite shocked at just how many attempts there are to access our server and are failing.  Failing in this case is good but I would really like to take an additional step of blocking the IP network of the user that is failing.  I had a Chinese network that tried repeatedly for 7 minutes.  Obviously the relaxed rule set with a 10 minute window and 300 events would not catch this.  Just looking for guidance on what others are generally doing.  Thank you.

1 Reply

Reply to Thread
0
Scarab Replied
We use the following settings in SECURITY > ABUSE DETECTION:
 
Detection Type Service Time Frame Count Block Time
Password Brute Force by Protocol SMTP 60 10 60
Password Brute Force by Protocol SMTP 1440 50 43200
 
The first rule usually deters the more common brute-force bots. The second rule catches the more pernicious and stealthy slow-drip brute-force bots. Unfortunately neither catches larger scale distributed brute-force botnets that utilize millions of different IPs all from different locations.
 
Note that both of these rules could potentially trigger false-positives when you have customers attempting to repeatedly connect with an incorrect password. When fielding Customer Support calls we routinely check the MANAGE > CURRENT IDS BLOCKS to make sure they didn't get automatically blocked before troubleshooting any deeper.
 
Another thing we do is set a SETTINGS > EVENTS Abuse Detection Rule Triggered to generate an email to an email account that we use to compile IP Blocklists. You can have a script that does this by parsing the email contents or if you have a low volume this can be done manually. When an IP Subnet has triggered our IDS settings 3x or more we evaluate that subnet with Senderbase and if the entire subnet has a POOR reputation (or no matching rDNS) then we permanently block the entire subnet in SECURITY > BLACKLIST.
 
We also regularly parse out the SMTP Logs for failures and look for common HELO/EHLO strings and block these in the SECURITY > SMTP BLOCKING. Many botnets will use the same or similar HELO/EHLO allowing them to be blocked that way (wildcards can be your strongest weapon). Just like with any other IPs or IP Ranges you have blocked they will continue to show up in the logs but no matter how many attempts they make to login they will never succeed.

Reply to Thread