On Fri 21/Jun/2024 14:55:16 +0200 Slavko via mailop wrote:
Dňa 21. júna 2024 11:50:23 UTC používateľ Alessandro Vesely via mailop
<mailop@mailop.org> napísal:
That db currently holds 2,014,973 records. Rather than ipset or single
iptables rules, the IPs are stored on a Berkeley DB. They get blocked by a few
iptables rules ending in -j NFQUEUE. That passes the packet to a userspace
daemon which consults the database and decides whether to drop the packet or
not. See https://savannah.nongnu.org/projects/ipqbdb/
It's much more do-it-yourself than fail2ban.
I use fail2ban's bantime increment to incremental bantime with custom
action, which on configured repeat count adds IP to "permanent" ipset
(currently when bantime reach 60 days). That permanent ipset is daily
inspected (by cron job), its counters are stored in sqlite DB and removed
after (configurable -- currently 120 days) time of inactivity. Ipset itself
allows to process IPv6 in /64 manner, thus no need to worry.
While fighting with Submission/IMAP logins i found, that max ipset's
timeout (~24 days) is not enough to catch botnet repeating - common
repeat interval was ~50-60 days.
I keep them short. I track "good" IPs and don't report their failed logins.
However, it's still possible for real users to flunk their password. This kind
of bans have to rehabilitate rather quickly.
Login attempts don't seem to follow any kind of decent dictionary attack
strategy, as they try random userid/ password combinations, and repeat failed ones.
Best
Ale
--
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
