Yesterday I experienced a distributed ssh attack on a SME-server. The server survived, but the attack put a heavy load on it. The server was setup to allow remote ssh access from a non-standard port, and this was the vulnerability the attack tried to exploit.
The server runs fail2ban, and consequently banned lots and lots of ip-addresses. Each banning involves a "fail2ban-update"-event, and the load from all these events was quite hard. Actually, banning involves 2 "fail2ban-update"-events for each IP-address: 1 for the ban and a little later 1 for the unban. And every event includes lots of calls to iptables: one call for each IP-address on the fail2ban-list.
So, e.g., if at present 1,000 IP-addresses are banned, a new "fail2ban-update"-event includes 1,001 calls to iptables.
From the logs I can count 3,390 remote IP-addresses used for the attack. Quite a large number, I think.
Moral of the story: don't count on fail2ban for handling distributed attacks
Jesper, Denmark