On some machines localhost is defined as something other than 127.0.0.1, and if we mix "127.0.0.1" and "localhost" then some connections won't be to to the address a service is actually running on.
This was the case with DKIM: It was running on "localhost" but Postfix was connecting to it at 127.0.0.1. (https://discourse.mailinabox.email/t/opendkim-is-not-running-port-8891/1188/12.)
I suppose "localhost" could be an alias to an IPv6 address? We don't really want local services binding on IPv6, so use "127.0.0.1" to be explicit and don't use "localhost" to be sure we get an IPv4 address.
Fixes#797
https://discourse.mailinabox.email/t/status-check-emails-empty-after-upgrading-to-v0-16/1082/3
A user on that thread suggests an alternate solution, adding `PYTHONIOENCODING=utf-8` to `/etc/environment`. Python docs say that affects stdin/out/err. But we also use these environment variables elsewhere to ensure that config files we read/write are opened with UTF8 too. Maybe all that can be simplified too.
* added IMAP_SMTP_METHOD to z_push/backend_imap
* reverting that line accidentally deleted in commit 5055ef
* cf pull request GH-580 that commit is part of
Signed-off-by: Bernard `Guyzmo` Pratz <guyzmo+github@m0g.net>
I propose that the default 600s/10minute find time is a better test duration for this ban. The altered 120s findtime sounds reasonable until you consider that attackers can simply throttle to 3 attempts per minute and never be banned.
The remaining non default jail settings of maxretry = 7 and bantime = 3600 I believe are good.
Nginx should be connecting over the local interface, not to the IP the resolver gives it. Elsewhere in this file proxy_pass uses 127.0.0.1 as it should.
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.
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.
Reverts the remaining FAIL2BAN settings to default: findtime 600 and maxretry 3. As jail settings override default settings this was hardly being used anyway so it is better to explicitly set it per jail as and when required.
Modify outgoing_mail_header_filters and mail-postfix.sh
files to result in the primary hostname, and the public
ip of the server showing in the first mail header route
instead of unknown and 127.0.0.1. This could help lower
the spam score of mail sent from your server to some
public mail services.
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.
No legitimate admin will require 20 login attempts. The default 6 is a sane middle ground especially since in 10 minutes they can try again or immediately from another IP anyway.
A 60 second/1 minute ban time is not long enough to counter brute force attacks which is the main purpose of fail2ban for mail in a box. The default bantime of 10 minutes is still sane and I think we have proven fail2ban is reliable enough not to cause problems in general. It is not worth sacrificing security for the rare case where an admin locks themselves out for 10 minutes.
* Set ssl_stapling_verify to off per https://sslmate.com/blog/post/ocsp_stapling_in_apache_and_nginx ('on' has no security benefits).
* Set resolver to 127.0.0.1, instead of Google Public DNS, because we might as well use our local nameserver anyway.
* Remove the commented line which per the link above would never be necessary anyway.
OCSP seems to work just fine after these changes.
Corey Hinshaw
Michael Kroes
Chris Blankenship
Joshua Tauberer
Tibor Blaho
Bernard `Guyzmo` Pratz
Michael Kroes
anoma
Stefan Dimitrov
PortableTech
kri3v
Marc Schiller
bizonix