I am running fail2ban 0.10.2-2 on a Debian testing email server running sendmail and use fail2ban as part of an IDS against botnet attacks.
Recidive finds and correctly matches the fail2ban-server sendmail bans in fail2ban.log but also matches and records the fail2ban-server PID in the log file. This isn't a problem unless fail2ban is restarted when the PID will change to a new value and recidive matching from bans logged before the server was started then fail. My recidive findtime is set to several days to overcome an ongoing botnet attack against my server, so if fail2ban is restarted I loose the data that has been historically gathered and recidive becomes severely performance limited. As a workround I have been editing fail2ban.log after restarting the server to change the PID of the previous fail2ban session to that of the current session but this doesn't work for data stored in the sqlite datadase. Any suggestions of how to make recidive not record the server PID which seems to be hard coded somewhere in fail2ban. Rob ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Fail2ban-users mailing list Fail2ban-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fail2ban-users
