- Thu 13 March 2014
- misc
A lot of folks use fail2ban, not just as a way of quashing brute force attacks on their infrastructure but also to keep the enormous logs that such attacks create in check. I was securing some boxes at $DAYJOB for a proof of concept rollout and ran into an interesting failure mode wherein fail2ban lives up to its name.
So there I was in Ubuntu-land, bolting things down. Secured sshd to not allow password (keys only). Then I install fail2ban. Just to be sure the right thing was happening I tried to log in multiple times with no key to see if I got banned.
Funny. Nothing happened. Looked in the logs. Saw a bunch of auth.log lines of the form: {% raw %} Mar 12 17:18:01 stream1-Dell710 sshd[2626]: Connection closed by 10.14.0.47 [preauth]
Interesting. That's not a login failure, just a protocol capabilities mismatch. So fail2ban... fails to ban.
No, there wasn't any risk of actual break-in, but an attempted brute force attack can still fill up your logs.