native Bruteforce prevention in V3

[McPizza0]

with V2 we could implement fail2ban via the log files to mitigate bruteforce attacks on SMTP

the logfiles were removed with logging refactor as per: #2864

we would like to see a native way for Postal to handle bruteforce attacks, both on the SMTP server and potentially also the web server

[pjv]

We also use fail2ban on host-based log files with Postal V2. Migrating to V3 currently means running with no protection from bad actors which target SMTP servers mercilessly.

[McPizza0]

yup, its a bit of a shame v3 breaks this

[adamcooke]

The method that was used in v2 was not a good practice for containerised workloads. Those log files could end up fairly large without any option to easily rotate them.

However, there are ways to have your Docker logs piped to your local syslog which you can then monitor with fail2ban.

I haven't tried it but perhaps this article might help?

[pjv]

@adamcooke You’re completely right it’s a bad idea to log into a container. Redirecting STDIO to syslog on the host via docker’s config is probably the best stopgap in the interim but having brute-force protection in the SMTP container would be brilliant long-term.

[adamcooke]

I've added some docs about redirecting this log output to syslog so it can be used with fail2ban. https://docs.postalserver.io/features/logging#redirecting-logs-to-the-host-syslog