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

71 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
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
Add fail2ban to management interface
2016-03-23 11:29:12 +00:00
[management-daemon]
enabled = true
filter = miab-management-daemon
port = http,https
Write failed login attempts on the management interface to the syslog to allow fail2ban to ban repeat offenders
2016-03-24 13:00:23 +00:00
logpath = /var/log/syslog
Add fail2ban to management interface
2016-03-23 11:29:12 +00:00
maxretry = 20
findtime = 30
Add fail2ban checks for roudcube
2016-03-24 13:16:57 +00:00
[roundcube]
enabled = true
port = http,https
filter = roundcube
logpath = /var/log/roundcubemail/errors
maxretry = 20
findtime = 30
Add fail2ban checks for owncloud
2016-03-24 14:07:15 +00:00
[owncloud]
enabled = true
port = http,https
filter = owncloud
logpath = /home/user-data/owncloud/owncloud.log
maxretry = 20
findtime = 30
Add fail2ban filters for munin and postfix submission
2016-03-28 14:10:52 +00:00
[munin]
enabled = true
port = http,https
filter = munin
logpath = /var/log/nginx/access.log
maxretry = 20
findtime = 30
[postfix-submission]
enabled = true
port = 587
filter = postfix-submission
logpath = /var/log/mail.log
maxretry = 20
findtime = 30
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
Add fail2ban to management interface
2016-03-23 11:29:12 +00:00