external
/
mailinabox
mirror of https://github.com/mail-in-a-box/mailinabox.git
1
0
Fork 0
Code Issues Releases Wiki Activity
mailinabox/conf/fail2ban/jail.local

42 lines
1.2 KiB
Plaintext
Raw Normal View History

Cleanup blank lines, comments and whitespace to make it easier to follow
2015-07-02 09:19:37 +00:00
# Fail2Ban configuration file for Mail-in-a-Box
fail2ban: whitelist our machine's public ip address so status checks dont cause bans of the machine itself
2015-12-07 13:45:59 +00:00
[DEFAULT]
# Whitelist our own IP addresses. 127.0.0.1/8 is the default. But our status checks
# ping services over the public interface so we should whitelist that address of
# ours too. The string is substituted during installation.
ignoreip = 127.0.0.1/8 PUBLIC_IP
Configure fail2ban jails to prevent dumb brute-force attacks against postfix, dovecot and ssh. See #319
2015-03-08 00:13:55 +00:00
# JAILS
Added more bantime and lowered max retry attempts Ban time was too low for preventing ssh brute force attacks, this change also allows to keep the auth.log more clean and avoid wasting cpu and i/o on this. Bots eventually will flag your IP as secure and move along.
2015-07-02 15:55:43 +00:00
[ssh]
maxretry = 7
bantime = 3600
Configure fail2ban jails to prevent dumb brute-force attacks against postfix, dovecot and ssh. See #319
2015-03-08 00:13:55 +00:00
[ssh-ddos]
enabled = true
[sasl]
enabled = true
[dovecot]
enabled = true
filter = dovecotimap
Ultra safe dovecot findtime and maxretry settings Explicitly set the timings and counts for the dovecot jail rather than change the global [DEFAULT] and inherit it for this one jail. These settings are far too safe so a future PR should increase security here.
2015-07-06 12:44:53 +00:00
findtime = 30
maxretry = 20
Configured Dovecot to log into its own logfile
2016-04-26 17:49:25 +00:00
logpath = /var/log/mail.log
Activate FAIL2BAN recidive jail Recidive can be thought of as FAIL2BAN checking itself. This setup will monitor the FAIL2BAN log and if 10 bans are seen within one day activate a week long ban and email the mail in a box admin that it has been applied . These bans survive FAIL2BAN service restarts so are much stronger which obviously means we need to be careful with them. Our current settings are relatively safe and definitely not easy to trigger by mistake e.g to activate a recidive IP jail by failed SSH logins a user would have to fail logging into SSH 6 times in 10 minutes, get banned, wait for the ban to expire and then repeat this process 9 further times within a 24 hour period. The default maxretry of 5 is much saner but that can be applied once users are happy with this jail. I have been running a stronger version of this for months and it does a very good job of ejecting persistent abusers.
2015-07-07 11:37:42 +00:00
[recidive]
enabled = true
maxretry = 10
Stop fail2ban recidive from sending emails, like all other jails
2016-03-26 08:04:51 +00:00
action = iptables-allports[name=recidive]
Add documentation on why the notification was removed from the recidive jail
2016-03-26 12:37:33 +00:00
# In the recidive section of jail.conf the action contains:
#
# action = iptables-allports[name=recidive]
# sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log]
#
# The last line on the action will sent an email to the configured address. This mail will
# notify the administrator that someone has been repeatedly triggering one of the other jails.
# By default we don't configure this address and no action is required from the admin anyway.
# So the notification is ommited. This will prevent message appearing in the mail.log that mail
# can't be delivered to fail2ban@$HOSTNAME.