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
_______________________________________________
Fail2ban-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
