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.