Fail2Bad kann alles mögliche blockieren, allerdings keine Dateien an sich. Fail2Bad arbeitet mit Logfiles bzw. wertet diese aus. Wenn Du also ein Login-Script hast, dann kannste rein theoretisch bei einem Fehllogin eine Zeile in eine Log schreiben und dieses Log von Fail2Ban überwachen lassen.
Über die Logs und die entsprechende Conf für Fail2Ban (Filter) kannste eigentlich alles abwickeln, auch eine Sperre bei zu vielen 404ern in zu kurzer Zeit.
Da werden alle ips gesperrt, die in den apachelogs und anderen Errors produzieren - also müsste da nicht generell jeder mehrfach vergebliche Login gesperrt werden?
Da bekommst Du das Grauen wenn du Dir die Logdateien anschaust. Ein Heer von Vandalen und Einbrechern steht vor den Servertüren.
bei Alex müsste im Prinzip /var/www/vhosts/http://deinedomain.de/statistics/logs/error_logs
in die jail.config integriert werden, und in dem augenblick werden die error_logs von der Domain überwacht.
edit - war zu langsam, deshalb weiter unten noch einmal.
guppy
Kommt drauf an, ob der Filter für Apache auch geladen ist. Default ist glaube ich nur SSH. Und wenn der Apache-Filter geladen ist, dann reagiert der auf Fehllogins, aber nur als apache-auth, also Fehllogins über htaccess. Ist das aber ein Loginsystem von PHP, dann steht das nicht im Log.
ja. Es lässt sich alles blocken, was in einem Log steht und per Fail2Ban-Filter erkannt wird / werden kann. Wenn Confixx also eine entsprechende Meldung in ein Log schreibt, dann ja. Die Filter sind schon umfangreich vorhanden, können aber auch selbst erstellt werden.
Genau genommen würde sogar ein Dateizugriff zu sperren sein, z.B. Download zu schnell und zu oft. Der Download muss dann halt nur eindeutig im Logfile erkennbar sein und vor allem so sein, dass den ein Filter filtern kann. Also einfach das Access.Log auswerten geht nicht, denn das wären ja alle Dateizugriffe. Aber ein Filter, der genau auf eine Datei achtet, das geht.
guppy
Kommt drauf an, ob der Filter für Apache auch geladen ist. Default ist glaube ich nur SSH. Und wenn der Apache-Filter geladen ist, dann reagiert der auf Fehllogins, aber nur als apache-auth, also Fehllogins über htaccess. Ist das aber ein Loginsystem von PHP, dann steht das nicht im Log.
bei Alex müsste im Prinzip /var/www/vhosts/http://deinedomain.de/statistics/logs/error_logs
in die jail.config integriert werden, und in dem augenblick werden die error_logs von der Domain überwacht.
Jupp, hier ist es beschrieben, geht sogar noch einfacher:
*** Link veraltet ***
Hm, Guppy, ich glaube da reden wir aber aneinander vorbei.
Ich meinte das hier:
"Wenn jemand 100x pro Minute z.B. auf eine Loginseite im Shop per http zugreifen will und dabei PWs austestet"
Das macht der Default-Filter nicht. Der reagiert vielleicht auf Fehler, aber dann auf alle, egal wo und wie die entstehen. Um explizit den Login zu schützen bedarf es einer extra Regel, einem Filter ähnlich dem hier, der auf WP-Fehllogins reagiert.
*** Link veraltet ***
Wobei der aber auch nicht unterscheidet zwischen erfolgreicher Login oder fehlerhaft. Der geht einfach über die Anzahl im Zeitraum.
Ein Fehlerhafter Login in einem PHP-Script schreibt ja selbst keine Meldung ins Error-Log. Das ist für den Apache auch kein Fehler, sondern ein normaler Seitenaufruf bei dem Daten per POST übertragen werden. Die Antwort, also erfolgreich oder nicht, das ist dann ganz normal GET. Das Apache-Modul auth ist da gar nicht beteiligt. Beim Passwortschutz der htaccess allerdings schon, denn hier übernimmt die Authentifizierung der Apache und nicht PHP.
Hi platter Kater,
um IMSCP brauchste dich nicht sorgen. Wenn du grade nicht dran arbeiten willst, kannste ja mal ein paar mal falsche Login Daten eingeben. Nach dem 3. mal wird deine IP gesperrt.
Fail2Ban ist ganz nett, aber dieser von Guppy gegebene Pfad stimmt so nicht. Das sind die Kundenlogs, die werden alle 6 Stunden geschrieben. Die Live Logs liegen woanders, unter var/log/häuptling
Dann werden die einzelnen IPs immer erst dann gesperrt, wenn das Limit überschritten ist. Anders geht es ja nicht, könnten ja auch hundert Kunden gleichzeitig auf dem Login sein und die sollen ja rein kommen 
ah ganz vergessen. Das ist natürlich wie Syno sagte dann ein normaler request bei imscp. Für alle meine Joomla Kunden hab ich noch ein umfangreiches Software Paket was die Sicherheit managed. Wie eine WAF ( Web Anwendungs Firewall ) uvm wie einen PHP File Scanner, Datenbank Tools und noch einiges mehr. Ist auch nix illegales, das ist mit den Programmierern abgesegnet.
Warum hast du denn kein Joomla CC?
Ist Geschmackssache, ich bleibe bei meinen eigenen Projekten aber dabei. Hab da auch gut investiert 
EDIT: Wie stoppst Du z.B. DDOS auf meine IMSCP-Loginseite?
Das müsste so gehen wie voher im Beispiel mit dem WP-Login. Habe kein imscp, daher anhand deren Demo-Seite.
[Definition]
failregex = ^ .*"POST .*/admin/index\.php HTTP.* 200 .*$
ignoreregex =[apache-imscp]
enabled = true
filter = apache-imscp
action = iptables-multiport[name=apache-imscp, port="http,https", protocol=tcp]
port = http,https
logpath = /var/www/*/log/access_log
maxretry = 5
findtime = 15
bantime = 240
Natürlich ungetestet, aber so in der Art. Pfade müssen angepasst werden. Ob imscp eine eigene Fehlermeldung schreibt, keine Ahnung. Wenn ja, dann könnte man auch die nehmen als Suchstring.
Ich will sagen: Wenn sich 10 echte Kunden pro Minute in meinem Shop einloggen wollen, das ist das gut.
Aber was macht fail2ban, wenn sich dazu noch 100 falsche Kunden einloggen wollen und nur Loginnamen und PWs testen?
Das wäre egal. Fail2Ban reagiert nur auf IP-Adressen, deren Limits überschritten sind, also mehr als maxretry in findtime. Die anderen Kunden, bzw. deren andere IPs sind dann nicht betroffen, denn die werden ja alle extra gezählt. Summiert wird also immer nur eine IP. (Ähnlich mysql. sum(Zugriffe) *** GROUP BY ip)
Bei der Angabe
maxretry = 50
findtime = 120
wird also jede IP gesperrt, zu binnen 2 Minuten mehr als 50 Zugriffe hat.
bei Joomla haben die das ab 3er Reihe so vorkonfiguriert das jeder User, Kunde oder was auch immer nach der Registrierung erstmal seine E-Mail validieren muss und DANACH vom Administrator freigeschaltet werden MUSS.
Ist ganz nützlich, praktisch und komfortabel. Hält den Spam fern, ist allerdings ein Aufwand den man machen muss.
Es gibt jetzt neu auch eine 2 Faktor auth.
Joomla ist besser als sein Ruf, aber wie gesagt Geschmackssache.
Fail2Ban ist ganz nett, aber dieser von Guppy gegebene Pfad stimmt so nicht. Das sind die Kundenlogs, die werden alle 6 Stunden geschrieben. Die Live Logs liegen woanders, unter var/log/häuptling
ah ok, dazu kommt noch dass die Dateien mit Plesk (bei mir)woanders liegen sollen, habe ich beim überfliegen gesehen.
Hm, Guppy, ich glaube da reden wir aber aneinander vorbei.
Ich meinte das hier:
"Wenn jemand 100x pro Minute z.B. auf eine Loginseite im Shop per http zugreifen will und dabei PWs austestet"
Jup haben wir aneinander vorbei geredet.
bei Joomla
Ja toll. Das ist doch Moppelkotze^^
Und was mache ich, wenn meine 90% Kunden, die als Gast was kaufen wollen shoppen wollen? Die wollen sich nicht anmelden. Und die wollen schon gar nicht drauf warten, das ich alle 2 Wochen mal Thunderbird aufmache und Validierungsemails verschicke.
Schonmal sowas gesehen: *** Link veraltet *** ?^^
Ehrlich gesagt nicht wirklich. So was in der Art hatte ich auch mal laufen, da musste auch vorher eine bestimmte Seite aufgerufen werden. Die kleinen Kiddies hält das ab, weil die einfach doof sind, aber wenn die mal etwas vernünftig denken und den Login einmal per Hand durchspielen, dann sehen die auch den Referer und senden den mit.
Fail2Ban ist auch hier besser und zuverlässiger. Sagt ja keiner, dass die Zugriffe 5 binnen 30 Sekunden sein müssen. Kann ja auch 100 binnen 2 Stunden sein oder so. Muss halt ein Wert sein, der normale Kunden nicht beeinträchtigt bzw. der bei normalen Kunden nicht vorkommt.
Und bei DDOS dann eben ganz kleine Werte, etwa 15 Zugriffe binnen 2 Sekunden oder so. Das macht ein normaler Mensch normalerweise auch nicht.
Wenn der das aber wirklich so macht, dass der alle 2-3 Versuche pro Sekunde die IP wechselt und das vielleicht noch simultan mit 50 oder mehrt Requests, dann sehe ich da ganz andere Probleme. Das wird der Server auf Dauer gar nicht mitmachen. Wobei 2-3 schon sehr wenig ist, deren Kontingent ist hoch, aber nicht unendlich. Aber klar, wenn der oft genug wechselt und immer unter dem Limit bleibt, dann bringt Fail2Ban auch nichts und es kommt eher der Server an die Leistungsgrenze.