The following lines were added (+) and removed (-):
== monitoring ==It is a fact that today most mail servers are frequently scanned for username and password combinations. These dictionary attacks against mail servers seems to be all the rage since about 2010, hitting an all time high in 2014. Most attacks from from the APNIC IP blocks, however, compromised systems in your own area might be under the control of someone doing system scanning on your machine. Blindly blocking foreign subnets isn't enough.Closely monitoring the log file: tail -f /var/log/secureprovides a very clear view of the user and pass being tried. Several combinations are attempted per connection. For each one line of failed authentication in the maillog there may be a dozen or more lines of user/pass combinations being tried visible in the secure log. The number depends on your dovecot configuration limits. It is interesting to see the "common" usernames being attempted. The attacker is typically running a script that automates the attack. Sometimes an improperly configured script being ran by the attacking script-kiddie will hammer dovecot with a username like 'null' repeatably for hours. The entertainment value in that is that it is a waste of the attackers time. The sad part is that it is also a waste of your system and network resources.Once you have fail2ban properly configured, you can monitor it with a high debug level to see how well it is performing. A debug level of "4" is the most verbose. Use this for a short duration while you are working out the glitches and fine tuning. A debug level of "2" or "1" is appropriate for continued use. tail -f /var/log/fail2ban-test.logAlthough you can configure fail2ban to add log entries to the syslog, it is recommended you have it log to its own file while debugging. With a debug level of 4 a lot of entries are added to the log. Plus it is easier to monitor fail2ban when it has a dedicated log file. Once you have it running smoothly you may opt to configure it to log to the syslog, or continue to log to a unique file. This setting is in the fail2ban.local configuration file. logtarget = /var/log/fail2ban-test.logWhen you see iptables rules being added by fail2ban, they will be in chains labeled "fail2ban-postfix" (depending on your own customized configuration). Here is an example of an attacker being blocked by an iptables rule generated by fail2ban: iptables -I fail2ban-postfix 1 -s 105.237.97.175 -j DROPIf your system has very few static iptables rules, then you can view what is going on with a simple iptables -LHowever, for systems with 1000s of iptables rules, it is more useful to list only those created by fail2ban iptables -L fail2ban-postfixNow we see all firewall rules generated by fail2ban for postfix. Lastly, a most useful feature of fail2ban is the ability to send you reports by email. You can configure fail2ban to send you email notifications when it bans a host. By default fail2ban is configured not to send any mails. You will have to make modifications to enable it. Edit jail.local to set up email notifications. Email notification is sent as an "action" and in the case of notifications for these smpt auth attacks, is under the label [sasl-iptables]Using action.d/mail.conf to email you a notification on common activities such as: fail2ban service start, banning and unbanning an address. vi ./fail2ban/jail.localFind the line in the enabled action. An action can have multiple lines. Add a line under action = mail[name=postfix-sasl, dest=yourmailbox, sender=fail2ban@localhost, sendername="Fail2Ban SASL"]In this example, actions adding iptables rules for smtp attack will result in an email sent to yourmailbox.