Package: fail2ban
Version: 0.10.2-2.1
Severity: serious
Justification: filing up filesystem, slow startup
Hi,
I've noticed this on both stretch and buster hosts with the default
configuration: the database (/var/lib/fail2ban/fail2ban.sqlite3) doesn't
seem to get any kind of clean-up. I'm seeing this at the moment on those
two internet-connected hosts:
626M /var/lib/fail2ban/fail2ban.sqlite3
940M /var/lib/fail2ban/fail2ban.sqlite3
Toying with sqlite3 and a "select * from bans limit 1;", I'm seeing:
sshd|ANO.NYM.IZ.ED|1519714548|{"matches": ["Feb 27 07:46:29 […]
sshd|ANO.NYM.IZ.ED|1520144221|{"matches": ["Mar 4 07:16:36 […]
(I'm not even sure which year those entries come from…)
The only thing that seems related returns:
Current database purge age is:
`- 86400seconds
which matches this in /etc/fail2ban/fail2ban.conf:
# Options: dbpurgeage
# Notes.: Sets age at which bans should be purged from the database
# Values: [ SECONDS ] Default: 86400 (24hours)
dbpurgeage = 1d
and I'm not sure it's taken into account. Or whether that's meant to
control that the database grows forever.
A cheap workaround might be to switch the dbfile setting to:
dbfile = :memory:
but having to do that seems very wong.
Looking around in the BTS, #823892 and #898536 seemed related but they
were closed already (with inappropriate versions since the BTS doesn't
know about backports anyway?)
Please let me know if I can help debug this further.
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
