6
Wie auf Brute Force Angriff auf ein Wordpress reagieren
Hallo,
mal was ganz anderes.
Ein Kunde betreibt ein Wordpress-CMS auf einem Server (Lamp).
Auf diesen läuft seit ca. 2 Stunden ein Brute Force Angriff. Es wird versucht sich im Backend mit zwei verschiedenen Benutzernamen und wechselnden Kennwörtern anzumelden.
Auf dem Wordpress läuft ein Sicherheitssystem was bei falschen Zugangsdaten die IPs sperrt.
Überlicherweise würden wir per iptables die IP-Adressen oder das Subnetz einfach auf IP-Ebene sperren.
Das geht hier nur nicht.
Bis jetzt haben wir ca. 420 IP-Adresse aus ca. 25 Class-A-Subnetzten und mindestens 8 Ländern festgestellt.
Vermutlich also ein Bot-Netz.
Wir haben nun die Anmelde-Dateien per htaccess abgesichert, da mit dem System weiter gearbeitet werden muss.
Sonst noch Vorschläge?
Viele Grüße
Stefan
mal was ganz anderes.
Ein Kunde betreibt ein Wordpress-CMS auf einem Server (Lamp).
Auf diesen läuft seit ca. 2 Stunden ein Brute Force Angriff. Es wird versucht sich im Backend mit zwei verschiedenen Benutzernamen und wechselnden Kennwörtern anzumelden.
Auf dem Wordpress läuft ein Sicherheitssystem was bei falschen Zugangsdaten die IPs sperrt.
Überlicherweise würden wir per iptables die IP-Adressen oder das Subnetz einfach auf IP-Ebene sperren.
Das geht hier nur nicht.
Bis jetzt haben wir ca. 420 IP-Adresse aus ca. 25 Class-A-Subnetzten und mindestens 8 Ländern festgestellt.
Vermutlich also ein Bot-Netz.
Wir haben nun die Anmelde-Dateien per htaccess abgesichert, da mit dem System weiter gearbeitet werden muss.
Sonst noch Vorschläge?
Viele Grüße
Stefan
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 277392
Url: https://administrator.de/forum/wie-auf-brute-force-angriff-auf-ein-wordpress-reagieren-277392.html
Ausgedruckt am: 12.04.2025 um 15:04 Uhr
6 Kommentare
Neuester Kommentar
Hi,
Schau dir mal Fail2Ban an. Das scannt das log und kann automatisch IP-Adressen nach regeln per iptables sperren.
Regeln sind sehr frei definierbar. Z.B. 1h sperren wenn innerhalb von 5 min 10 fehlgeschlagene Anmeldeversuche rein kommen.
Dann musst nu nicht per Hand 420 IP adressen reinklopfen.
mfg
Cthluhu
Schau dir mal Fail2Ban an. Das scannt das log und kann automatisch IP-Adressen nach regeln per iptables sperren.
Regeln sind sehr frei definierbar. Z.B. 1h sperren wenn innerhalb von 5 min 10 fehlgeschlagene Anmeldeversuche rein kommen.
Dann musst nu nicht per Hand 420 IP adressen reinklopfen.
mfg
Cthluhu
Zitat von @Cthluhu:
Schau dir mal Fail2Ban an. Das scannt das log und kann automatisch IP-Adressen nach regeln per iptables sperren.
Regeln sind sehr frei definierbar. Z.B. 1h sperren wenn innerhalb von 5 min 10 fehlgeschlagene Anmeldeversuche rein kommen.
Dann musst nu nicht per Hand 420 IP adressen reinklopfen.
Dafür haben wir wordfence im Einsatz.Schau dir mal Fail2Ban an. Das scannt das log und kann automatisch IP-Adressen nach regeln per iptables sperren.
Regeln sind sehr frei definierbar. Z.B. 1h sperren wenn innerhalb von 5 min 10 fehlgeschlagene Anmeldeversuche rein kommen.
Dann musst nu nicht per Hand 420 IP adressen reinklopfen.
Ich würde normalerweise den Angriff einfach durch das blocken des Subnetzes beenden, aber das geht hier leider nicht.
ich mache bei sowas gerne den Bruteforceangriff "kaputt", indem ich die Response modifiziere und ihm so antworte, als hatte er gerade das Passwort geknackt.
idR hört der Angriff dann ruckzuck auf und irgendwer versucht verweifelt sich mit dem vermeintlich gecrackten PW einzuloggen ...
ist teils recht witzig das mit anzusehen ;)
idR hört der Angriff dann ruckzuck auf und irgendwer versucht verweifelt sich mit dem vermeintlich gecrackten PW einzuloggen ...
ist teils recht witzig das mit anzusehen ;)
nabend
warum kannst du nicht des Subnetzes blocken ?
Arbeiten den alle im CMS von einem netzwerk aus ? dann würde ich nur den zugriff von einer Externen IP zulassen.
lg
frank
warum kannst du nicht des Subnetzes blocken ?
Arbeiten den alle im CMS von einem netzwerk aus ? dann würde ich nur den zugriff von einer Externen IP zulassen.
lg
frank
Meistens kann man auch Gemeinsamkeiten wie den User-Agent erkennen. Es hat sich als erstaunlich effektiv herausgestellt, Requests mit leeren User-Agent per Regel (z.B. im Apache) direkt vorne zu filtern.
Wenn die Bots da alle mit dem selben User-Agent ankommen und der sich nicht mit welchen von euren Nutzern überschneiden, kann man hart auf diesen exakten User-Agent filtern. Zur Sicherheit würde ich den Filter nur für den Admin-Login einrichten, um keine harmlosen Besucher auszusperren.
Wenn die Bots da alle mit dem selben User-Agent ankommen und der sich nicht mit welchen von euren Nutzern überschneiden, kann man hart auf diesen exakten User-Agent filtern. Zur Sicherheit würde ich den Filter nur für den Admin-Login einrichten, um keine harmlosen Besucher auszusperren.
Sendet den 403-Status-Code bei fehlerhaften Login-Versuchen in WordPress. Reduziert die Anzahl der Brute-Force-Anmeldungen ins WordPress-Admin.
https://gist.github.com/sergejmueller/5582131
sergejmueller / functions.php
Gruß
ITesla
https://gist.github.com/sergejmueller/5582131
sergejmueller / functions.php
Gruß
ITesla
