Zitat von Cordesh
2. IP's der Angreifer sperren
Dafür gibt es ein hilfreiches Plugin "Limit Login Attempts", welches man direkt in WP installieren kann.
"Installed Plugins" - "Add new" - "Search Plugins" ...
Damit sperrt man die IP des Angreifers für eine gewisse Zeit wenn er die eingestellte Anzahl der Loginversuche aufgebraucht hat.
Antwort:
Daaron schrieb:
1. Diese IP-Sperre ist dann aber nur auf Basis des PHP-Scripts. Alle Anfragen des Brute Force gehen ERST einmal an das Login-Script um dort dann abgeschmettert zu werden. Das ist zwar besser als nichts, aber ein schönes sicheres Passwort würde auch so einem BF Stand halten... leider wird diese Sorte Passwörter vom typischen WP-Klientel eben nicht benutzt. Das typische WP-Klientel hat WP gewählt, weil es a) gerade hip ist und b) weil es auch DAU-tauglich zu sein scheint.
2. Eine IP-Sperre auf .htaccess wäre sinnvoller. Hier müsste "nur" der Apache noch Arbeit leisten und gucken, ob die IP blacklistet ist. Das ist aber auch keine Option, denn die .htaccess dynamisch wachsen und schrumpfen zu lassen ist nicht ganz ohne.
3. Viel sinniger, aber nur für Leute mit wirklich flexiblen Hostern möglich, wäre: erstelle aus fehlgeschlagenen Logins eine Log-File und lasse diese Logfile von Fail2Ban auswerten. Dann blockt bereits iptables den Traffic, der Server bleibt dadurch nahezu stressfrei.
4. Das Kernproblem bleibt: Wenn ich in ein CMS erst zig Addons installieren oder die .htaccess manipulieren muss, damit das CMS leidlich sicher ist, dann ist es ein wirklich schlechtes CMS.
Ich hab mal Ziffern eingefügt, um meine Antworten darauf berufen zu können.
Du machst in dem gequoteten Abschnitt den gleichen Fehler wie flugser.
Du beurteilst das CMS WP anhand seiner Popularität und der deswegen laufenden Bruteforceattacke.
Um das nochmal klar zu machen (scheint notwendig zu sein); es wird bei der laufenden Attacke KEINE vermeintliche Sicherheitslücke ausgenutzt.
Es wird einfach versucht sich einzuloggen.
Das wäre genauso, als wenn sich jemand in das von Dir vorgeschlagene CMS Contao einloggen wollte.
Zu 1:
Ja, das php-Script schmettert die Anfragen ab. Per Plugin welches man aus dem CMS heraus installieren kann.
Ob die Anfragen vom php-Script, Apache oder sonstwas abgefangen werden interessiert mich nicht.
Es läuft eh alles auf dem Server. Wer da jetzt die Tür zumacht ist mir egal.
WP zeigt einem die Passwortsicherheit an.
Wer trotzdem unsichere PW wählt, wird das auch in jedem anderen CMS machen.
Das kann man also nicht WP ankreiden.
Zu 2:
"Wäre" "hätte" "wenn" interessiert mich nicht.
Es ist "nicht ganz ohne", scheidet also aus. Außerdem, mit dem Plugin haben wir eine Lösung die funktioniert.
Zu 3:
Auch hier wieder "Wäre" "hätte" "wenn".
Wenn ich nen "wirklich flexiblen Hoster" brauche, dann scheidet das für die allermeisten CMS User aus. Punkt.
Zu 4.:
Es gibt kein "Kernproblem" in WP.
Diese Brutforceattacken auf den Login kann man gegen jedes System starten, welches von außen einen Login ermöglicht.
Sie finden nur statt, weil WP so viel genutzt wird.
Daaron schrieb:
Ja, diesmal geht es um BF... aber auch nur, weil WP eben auch dagegen keinen Schutz bietet. Contao deaktiviert z.B. Accounts nach ein paar Login-Versuchen temporär. Außerdem gibt es keinen standardmäßigen Admin-Account. DU als User entscheidest, wie dein Admin heißen wird.
Das findest Du besser?
Irgendwelche Typen die in mein CMS einbrechen wollen schaffen es damit also, dass ich mich nicht mehr einloggen kann, weil mein Account gesperrt ist?
Und dann?
Ich hab mal recherchiert (
http://www.contao-anleitungen.de/post/administrator-passwort-zuruecksetzen.html):
Man muss entweder eine
Erweiterung installiert haben ("Wenn ich in ein CMS erst zig Addons installieren...") mit der man sich sein PW per eMail zurücksetzen lassen kann.
Geht. Kann man machen.
Aber was ist daran besser? Bei einer Bruteforceattacke kann der Account innerhalb Sekunden nach Freigabe per eMail schon wieder gesperrt sein.
Oder:
Man muss sein PW in der Datenbank per Zugriff via phpMyAdmin zurücksetzen.
Dieser Vorgang, direktes Editieren in einer Datenbank, bedeutet erstmal ein Backup der Datenbank erstellen, und dann gut aufpassen und ja keinen Fehler bei diesem nicht ganz trivialen Unterfangen machen.
Für mich als IT'ler ist das kein Problem, aber willste das wirklich normalen Anwendern zumuten?
Beides ist für mich nicht akzeptabel.
Wenn ich eins als Admin doch ganz sicher nicht will, dann das mich diese Typen ärgern und zu Handlungen zwingen.
Dieses Deaktivieren eines Accounts, ist für mich das ganz klare AUS für Contao.
Wenn andere mich durch simples mehrmaliges Eingeben eines falschen PW aus meinem eigenen System ausperren können, dann hat das System für mich einen schweren Mangel.
WP mag nicht perfekt sein, aber es funktioniert, wird ständig weiterentwickelt und bekannt gewordene Fehler werden gefixed.
Da es nicht ständig Meldungen alla "wieder zig tausend WP Blogs gehackt" gibt, scheinen die angeblichen Sicherheitslücken wohl doch nicht so groß zu sein.
