At 12:22 PM 7/30/2020, Gary Gapinski wrote:
I just took a look at (a copy of) the
/var/lib/fail2ban/fail2ban.sqlite3 database from
a system running fail2ban (version 0.11.1-1). It
contains a table which has most of the
information you mentioned (table columns are
jail, ip, timeofban, bantime, bancount, data
the data column contains JSON including the log line that triggered the match).
Sample data column content:
{
 "matches": [
   [
     "",
     "Jul 30 17:14:45",
     " test sshd[31513]: Connection from
195.84.49.20 port 39566 on 209.208.26.64 port 22 rdomain \"\""
   ],
   [
     "",
     "Jul 30 17:14:45",
     " test sshd[31513]: Connection closed
by 195.84.49.20 port 39566 [preauth]"
   ]
 ],
 "failures": 1,
 "mlfid": " test sshd[31513]: ",
 "ip4": "195.84.49.20",
 "mlfforget": "Connection closed"
}
Would that table's attributes suffice?
I am uncertain whether such table entries are
removed when a ban expires. On the system I
chose to inspect, the number of table rows was
approximately the same as the number of extant
bans. If table rows are removed as bans expire,
then perhaps a custom action could be used to
record the desired information at the time of
the ban (though I cannot find any documentation
of all of the variables available at action time).
On 7/30/20 1:01 PM, david wrote:
As a 'hack', I have solved this by looking
inside the internal implementation, and at
least until something changes, I can obtain the
information by using sqlite to read the
internal database, and then scanning the output
of journalctl for a match on the IP address.
Why is journalctl scanning necessary?
Regards,
Gary
Gary:
Sometimes I realize how careless I was .. your
comments drove me back to re-evaluate what was
actually in the sqlite database. So, I have a
good report producer that does not scan journalctl. Thanks for the pointer.
David
_______________________________________________
Fail2ban-users mailing list
Fail2ban-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
