Ja, das geht nach X Versuchen, aber wäre natürlich uncool, wenn irgendwer daraus einen Pseudoangriff macht indem er die verdächtigen URLs auf irgendeiner Seite per Ajax / JSONP laden lässt und einfach den status (und mehr) checkt. Dann sperrst Du am Ende nur den Unschuldigen Doofen, der mit aktiviertem JavaScript auf Seiten geht, denen er nicht vertraut.

Dazu kommt: ich habe keine Erfahrungen mit fail2ban, aber auf einem Server den ich betreue hatte ich kürzlich zu Spitzenzeiten auf HTTP rund 10k Hits / Minute von rund 6k Clients.
Würde fail2ban da nicht potentiell viel Last erzeugen, wenn es clientbasiert aus access logs filtern will? Läuft es da eigentlich als Daemon mit tail oder geht es ab und an die logs durch und beginnt an der letzten Position?

Bei SSH und FTP ist der Traffic ja recht überschaubar, vor allem, wenn man, was ich immer empfehle, die Standardports meidet. Aber bei HTTP?
Klar, man könnte sich nur auf's Errorlog stürzen, aber z.B. WordPress (ja, damit habe ich zuletzt sehr viel zu tun) liefert seine eigenen Sachen dabei aus, die wiederum nicht im normalen errorlog von Apache als Error auftauchen, weil mit mod_rewrite ja auf die index.php umgeleitet wurde und die existiert.


Meine ganz wilde Vision für den Professionellen Einsatz ist immer noch eine Art DNSBL auch für HTTP-clients. Das komplette Sperren aller RZ-IP-Ranges finde ich zu hart, aber einen schnellen (+Cache!) DNS-Check, ob die IP in letzter Zeit für Angriffe/Scans/Spam/AggressiveSpidering/etc genutzt wurde, das wäre doch schon mal was wert.