nicht angemeldet
M.E. erstmal gar keinen - ich hab allerdings keine Ahnung ob dein "apache-auth Filter" irgendwas taugt - was auch immer für einer das sein mag.
Zu „dein“:
Bei mir sind das „out of the Box“:
- /etc/fail2ban/filter.d/apache-auth.conf
- /etc/fail2ban/filter.d/apache-common.conf
- /etc/fail2ban/filter.d/common.conf
Nicht vergessen:
- /etc/fail2ban/jail.conf, respektive eine eventuell anzulegende Datei in /etc/fail2ban/jail.d
Nun, so lange diese Dateien nicht angepasst wurden (und danach zum übergroßen Teil) steht der Autor drin…
Und nun zu Piets „fail2ban ist schon gut.“:
Wirklich?
fail2ban hat den Vorteil, ein recht universelles Werkzeug zu sein. Und weil wir hier neulich Links zu lustigen Fotos von faktisch unbenutzbaren Schweizer „Messern“ hatten gebe ich zu denken, dass es auch die Nachteile universeller Werkzeuge hat.
Da man nun den Apache mit
ErrorDocument 401 /pfad/zum/skript
überreden kann, bei Anmeldefehlern z.B. ein PHP-Skript auszuführen (dem dann sogar der benutzte Username und (wohl sogar) das Passwort zur Verfügung stehen), könnte man überlegen, ob man in dem Fall womöglich auch abhängig vom Benutzernamen nur dessen Login sperrt oder, ob man aus Effektivitätsgründen die Sperre dann durch PHP triggern lässt. Also so ähnlich wie hier die IP zeitweise gleich mittels firewall sperrt.
Immerhin muss das PHP-Skript nur loslegen, wenn Benutzername oder Passwort falsch waren - und nicht das gesamte Logfile ständig gefiltert und (teilweise) in eine sqlite-Datenbank geschrieben werden...
Da das aber beides viel und unerhörte Sorgfalt erfordernde Arbeit macht UND weil eine Attacke auf Passwörter SEHR viele Versuche erfordert (insbesondere eine „brut force“-Attacke) könnte es gut sei, dass das hoffentlich ohnehin konfigurierte mod_evasive bereits ausreichend Abhilfe schafft.
TS