A sikertelen loginra vonatkozó naplók kezelése, feldolgozása (megőrzési idő, archiválás) picit más szint, mint egy f2b log. Az f2b hibakeresése nem sokkal több annál első körben, hogy iptables-save | grep "f2b-". Ha valami hibásan került bele, akkor annak ott lesz a nyoma az sshd logjában, ha meg hibásan _nem_ került bele, akkor szintén.
Van egy kis vps-em, minimális a forgalma, de az sshd-re raktam fail2ban-t, mert azért elég rendesen elkezdték töcskölni, és próba-cseresznye. Rövid idő (<1 nap) alatt a f2b-sshd lánc bő 42000 csomagot fogott meg (drop, van benne már most 5 cím). Ezek mind-mind ott lennének az /var/log/secure naplóban - nagyjáól-egészéből négy-négy sort (Invalid user/input_userauth_request/Received disconnect/Disconnected) belerondítva - és egy-egy sshd-t indítva, annak minden erőforrásigényével együtt. A fail2ban-nal kihajított ip-címek darabonként 5+1 sort termelnek a fail2ban logjában. Azaz 5*4 sor a secure logban, meg hat a fail2ban logjában, az 26 logsor. Ha nincs fail2ban, akkor n*4 sor a secure naplóban - azaz összességében ha hatnál többször próbálkozik egy adott ip (a f2b- iptables sorok számlálóin látszik, hogy igen), akkor kevesebblesz a log úgy, hogy erőforrást is spóroltunk (élve azzal a feltételezéssel, hogy az sshd indítása és a sikertelen authentikáció "drágább" műveletsor, mint a log figyelése és a csomagszűrő szükség szerinti matatása).
Rádiós meg hifista világban megy a vérpisálás a jel/jaj viszony javításán, vedd úgy, hogy ez is az.