Amir Caspi wrote: > Well, I've figured out the problem -- it's a bug in fail2ban's systemd > backend. Specifically, when a matching logline is created after the > offending connection has already closed, f2b fails to respond when using > the systemd backend. If the logline is created while the connection is > still open, f2b responds properly. Switching the backend to "polling" > restores the expected (correct) functionality. > > The discovery moment came after noticing that sendmail-reject (a stock > filter) ALSO failed to respond to some pre-greeting rejections. After a > bunch of testing, it turns out that if the client issues the "quit" > command before the pre-greeting rejection is logged, f2b will not respond > when using systemd. Non-quit pre-greeting commands (e.g., helo) that keep > the connection open will result in f2b responding properly... but a 'quit' > will cause no response. > > For now, I've switched over to the polling backend instead of systemd, and > all is working as it should. > > I've filed an official bug report: > https://github.com/fail2ban/fail2ban/issues/2385 > > This is a potential DoS vector so anyone using sendmail and the systemd > backend should take note and switch to polling until this is resolved in > the code. >
I'm pleased you sorted the problem. I'm not surprised it was systemd related as some while ago I changed my logtarget back from SYSLOG to /var/spool/fail2ban.log because I couldn't get the recidive filter working again after the debian distro was upgraded and added systemd. This probably explains why I didn't see your symptoms. Regards Rob _______________________________________________ Fail2ban-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fail2ban-users
