brute force bei Wordpress abwehren: Login-Beschränkung oder htpassword

Martinus33 · 31. Juli 2014

Hallo,
brute force scheint von all den vielen Sicherheitsgefahren eine der größeren zu sein, gerade bei populären CMS wie Wordpress. Es geht also nicht um meinen PC zu Hause, sondern um meine WP-Installation.

Spezielle Plugins zur Abwehr möchte ich nicht benutzen. Wichtig scheint mir, den Angriffsversuch schon "vorher" abzublocken.

Empfehlenswert scheinen zu sein:

1. Eine zusätzliche Login-Ebene zu erstellen, bekannt unter dem Stichwort htpassword (wobei die Datei auch anders heißen könnte).

2. In der htaccess den Zugang auf meine IP zu beschränken, was aber voraussetzt, eine fixe IP zu haben. Soweit ich weiß, haben "Normal-User" wie ich aber eine dynamische. Vielleicht ließe sich aber statt der IP was anderes nehmen?

Lawnmower · 31. Juli 2014

Wiso willst dafür kein Plugin einsetzen? WP ist ein System das auf Plugins basiert, wenn Du also WP einsetzt/entschieden hast musst Du auch Plugins verwenden sonst kann das Ding so gut wie nix (lies: ist so nicht brauchbar).

Martinus33 · 31. Juli 2014

@Lawnmower:
Habe gerade länger zu dem Thema gegoogelt und ein paar Beiträge gefunden, die das als nicht so optimale Varainte bezeichnen und auch Gründe nennen, z.B. hier:
http://www.rackaid.com/blog/wordpress-brute-force/

Vor einem Jahr kam es offenbar zu einer großen Welle von solchen Angriffen gegen WP und viele Plugins haben versagt, besagt eine andere Quelle, die ich jetzt nicht mehr finde.

Hier im Forum gibt es ebenfalls einen Thread dazu.

Außerdem spare ich generell gern mit Plugins.

Wie viel WP kann, hängt doch nicht von den Plugins, sondern primär vom Theme ab.

Private · 31. Juli 2014

"Limit Login Attempts" läuft gut macht was es soll und ist aktuell. Auch wenn es ein Plugin ist.

Private

Daaron · 1. August 2014

Wenns der eigene Server ist... https://wordpress.org/plugins/wp-fail2ban/ klingt nett.

Martinus33 · 1. August 2014

Du (!) empfiehlst ein Plugin???

Ne, habe keinen eigenen Server.

Daaron · 1. August 2014

Ich empfehle es nicht. Ich sage nur, dass die oberflächliche Funktionsbeschreibung gut klingt. Einen professionellen Blick in den Code sollte man trotzdem werfen.

Ich sag eher: Schmeiß Wordpress auf den Müll. Anständige Systeme, wie z.B. Contao, haben von Haus aus einen BF-Schutz drin.

Martinus33 · 1. August 2014

Kann ich nicht mehr und will es eigentlich auch nicht. Ich habe schon so viel Zeit in WP investiert und es hat gerade für Laien wie mich auch sehr viele Vorteile.

An DEINER Stelle würde ich wahrscheinlich auch kein WP nehmen, aber aus meiner Sicht geht es nur darum, den Sicherheitsnachteil so gut wie möglich abzudecken. Und das geht auch. Klar, wenn jemand sich manuell und persönlich als prof. Hacker bemüht, mein WP zu knacken, schafft er es dennoch. Von diesem Fall gehe ich aber nicht aus. Und die automatisierten Angriffe kann man doch recht effektiv einschränken, wenn man alle Register zieht.

Immer (nicht nur wie hier bei Sicherheitsfragen) wenn etwas per Plugin und ebenso per htaccess machbar ist, empfiehlt sich m.E. doch eher die htaccess: Sicherer, schneller und langfristig stabil bzw. unabhängig bleibend von zukünftigen Änderungen von WP/Plugin selbst. Zum Beispiel auch beim Anhängen von .html an die URL, was ich im anderen Thread angesprochen habe. URL-Rewrites gehören ebenfalls ins Repetoire der htaccess und vieles andere...

Deshalb wundert mich die Resoanz hier im Thread ein wenig.

Daaron · 1. August 2014

Martinus33 schrieb:
...doch eher die htaccess: Sicherer, schneller und langfristig stabil bzw. unabhängig bleibend von zukünftigen Änderungen von WP/Plugin selbst.

Da täuschst du dich aber...
Tatsächlich ist die .htaccess einer der umfangreicheren Gründe dafür, dass der Apache im Vergleich zur Konkurrenz etwas lahmarschig daher kommt. .hta's werden rekursiv abgearbeitet, und zwar bei jedem Request. Bei tiefer verschachtelten Bäumen kann das richtig viel ausmachen.

Außerdem: Was passiert, wenn du mti deiner .htaccess - Lösung jetzt auf einen Hoster umziehst, der lieber auf nginx, Cherokee oder *grusel* IIS setzt? Arschkarte, würd ich mal sagen.

Martinus33 · 1. August 2014

Meine Sites und htacesses sind recht überschaubar. Sicher keine tiefer verschachtelten Bäume. Ich vermute, die Performance ist da immer noch recht flott.

Aber am wichtigsten ist mir ohnehin die Tatsache, dass man mit Plugins immer abhängig ist. Gerade wenn jemand wie ich langfristig denkt und als Nicht-Techniker nicht alle 5 Monate z.B. anlässlich eines WP-Updates sich wieder "rumschlagen" will mit Sachen, von denen ich nur Halbwissen habe.... schläft man mit gegenüber Plugins gleichwertigen Lösungswegen per htaccess ruhiger und hat langfristig weniger Aufwand.

Für DICH als Experten ist das vielleicht weniger relevant, du weißt dir immer irgendwie und mit wenig Aufwand zu helfen. Aber für mich als "Normal-Webmaster" ohne beruflichen technischen Hintergrund ist das wichtig.

Private · 2. August 2014

Martinus33 schrieb:
Aber am wichtigsten ist mir ohnehin die Tatsache, dass man mit Plugins immer abhängig ist. Gerade wenn jemand wie ich langfristig denkt und als Nicht-Techniker nicht alle 5 Monate z.B. anlässlich eines WP-Updates sich wieder "rumschlagen" will mit Sachen, von denen ich nur Halbwissen habe.... schläft man mit gegenüber Plugins gleichwertigen Lösungswegen per htaccess ruhiger und hat langfristig weniger Aufwand.

Dann ist WP nix für dich wie oben schon geschrieben. Dann nimm einen Homepagebaukasten.

Private

KeSch · 2. August 2014

Unabhängig davon ob man WordPress nun gut oder schlecht findet (ich arbeite sehr gerne mit WP) würde ich immer die .htaccess- einer Plugin-Variante vorziehen, um den Login-Bereich abzusichern.

Das hat auch einen ganz einfachen Grund: Bei der .htaccess-Variante werden die Loginversuche bereits auf Serverebene angefangen und bei einer (sehr) großen Zahl an automatisierten Loginversuchen wird somit nicht gleich die gesamte Performance/Erreichbarkeit deines Blogs negativ beeinflusst. Dies lässt sich mit Plugins nämlich nicht realisieren, da die Abwehr quasi immer erst durch WordPress selbst (mit Hilfe des Plugins) erfolgt und der "Eindringling" schon bis zum System + Datenbank vorgedrungen ist. Hilfreicher Artikel dazu: http://playground.ebiene.de/initiative-wordpress-sicherheit/

Gruß KeSch

Daaron · 3. August 2014

Dafür kannst du aber, ohne größeren Aufwand (Root-Zugang zwecks Manipulation der iptables), keinen Brute-Force - Schutz per .htaccess umsetzen. Auf PHP-Ebene ist das leicht...
Außerdem: Wenn ein Brute-Force deinen Server lahm legt, dann ahst du ganz andere Probleme.

Martinus33 · 3. August 2014

@KeSch:
Ja, und das ist nur einer der Gründe, die auf der von mir verlinkten Seite (post 3) ebenfalls genannt werden.

Aber wir leben zum Glück in einem freien Land und wer keine Lust hat, einmal zu klicken und die bereits gelieferten Infos durchzulesen, nur um weiterhin die häufige Scheinsicherheit von Plugins zu genießen... bitte.

Daaron · 3. August 2014

Wie wäre es, wenn du meine Antwort auch mal wirklich VERARBEITEST, anstatt sie nur zu überfliegen?
Mit .htaccess/.htpasswd ist, ohne Root-Zugang, nun einmal kein Brute-Force - Schutz möglich. Hierfür braucht es Werkzeuge wie Fail2Ban, die das Access/Error-Log nach 403ern filzen und entsprechende Einträge in iptables hinterlassen. Das darf aber, wie überraschend, nur ROOT!

Aber nehmen wir die verlinkte Seite doch mal auseinander...
Fakt ist: Das Backend eines Blogs darf nicht öffentlich zugänglich sein! Punkt.
Nö. Das ist kein Fakt. Das ist Illusion. Der große Vorteil an einem CMS ist doch, dass man es von überall aus bearbeiten kann. Man benötigt nur einen Brute-Force - Schutz und ein leidlich stabiles Passwort, und natürlich darf die Login-Page keine schweren Sicherheitslücken aufweisen.

Bei Angriffsversuchen auf den Administrationsbereich eines WordPress-Blogs übernimmt der Webserver die Auseinandersetzung, WordPress selbst wird nicht mal ausgeführt und schont somit den Server und die Datenbank.
Die zusätzliche Last auf PHP & die Datenbank kann vollkommen ignoriert werden. Wenn das System wegen einem versuchten Brute-Force zusammen bricht, dann bricht es auch bei einem etwas übermotivierten Suchmaschinen-Crawler zusammen, oder wenn der Blog tatsächlich mal gelesen wird...

Außerdem: Wie oben schon festgestellt bietet .htaccess keine Chance auf Brute-Force - Protection. Gleichzeitig ist der HTTP Auth deutlich schneller als der Wordpress-Auth. Also? Genau! Ein aggressiver Brute-Force führt durch die höhere Performance sogar SCHNELLER zum Erfolg...

Doch warum Ruhestörer erst auf WordPress (das System und die Datenbank) lassen, wenn fehlerhafte Anmeldungen bereits auf Server-Ebene abgefangen werden können?
Weil PHP-basierte Lösungen einen Fail2Ban - artigen Mechanismus nachbilden können. Logge jeden fehlerhaften Login-Versuch mit IP und Zeit. Wenn zu viele Login-Versuche von einer IP in einer Zeitspanne kommen, blocke diese IP.

Martinus33 · 3. August 2014

Daaron schrieb:
Wie wäre es, wenn du meine Antwort auch mal wirklich VERARBEITEST, anstatt sie nur zu überfliegen?

Falls du mich meinst, wegen meines Hinweises auf das Lesen der verlinkten Seite, ich bezog mich auf private. Du bist mir beim posten nur ein paar Minuten zuvorgekommen.

Was gefährlicher ist, ein Angriff auf den Server oder WP... mag vielleicht auch vom Hoster abhängen. Ein halbwegs guter Hoster bietet seinen Kunden Zugang zum root und trifft zusätzliche eigene Sicherheitsmaßnahmen. Ich vermute (!), wenn ein brute force wirklich den ganzen Server gefährdet, merkt das der Hoster und wird aktiv.

Und wenn es stimmt, was der Autor des von mir verlinkten Artikels schreibt, dann sind die meisten Angriffe nicht darauf ausgelegt, zwei Logins hintereinander abzuarbeiten. Gibt schließlich Millionen Sites, die nur ein Login haben, also warum es sich unnötig schwer machen.

Daaron · 3. August 2014

Martinus33 schrieb:
Ein halbwegs guter Hoster bietet seinen Kunden Zugang zum root und trifft zusätzliche eigene Sicherheitsmaßnahmen.

Ganz sicher nicht. Root hat Zugriff auf ALLES, was auf der Maschine passiert. Root kann die Webseiten anderer Kunden manipulieren, er kann deren Datenbanken lesen, wenn die Maschine gleichzeitig noch ein Mailserver ist, kann Root auch diese lesen. Root kann unter Umständen höherprivilegierte Zugriffe auf andere Maschinen im Firmennetzwerk durchführen.

Nein, kein Hoster wird seinen Kunden Zugriff auf Root gestatten, kein Hoster wird seine Kunden an iptables herumpfuschen lassen. Stell dir mal vor, ein Witzbold manipuliert den Paketfilter so, dass keine IP (bis auf seine eigene) in der Folge noch irgend eine Verbindung zu der Maschine herstellen kann....

Ich vermute (!), wenn ein brute force wirklich den ganzen Server gefährdet, merkt das der Hoster und wird aktiv.

Oh, der Hoster wird aktiv.
Erst einmal schaltet er die Webseite einfach ab, danach schickt er eine Mahnung an den Kunden, dass dieser sein System zu reinigen und abzusichern hat. Der Kunde muss dann eine Unterlassungserklärung abgeben, erst danach wird die Webseite wieder aktiviert. Handhaben wir mit unseren Kunden genauso.

Und wie gesagt, eine PHP-basierte Lösung, die einen IP-basierten Brute-Force - Schutz implementiert, ist der .htaccess deutlich überlegen.
Das einzige, was unabhängig davon WIRKLICH Sinn macht ist: Wenn du eine feste IP bzw. eine enge IP-Range hast, dann kannst du über die .htaccess jegliche Zugriffe von anderen IPs rundweg blocken.

KeSch · 4. August 2014

Daaron schrieb:
Und wie gesagt, eine PHP-basierte Lösung, die einen IP-basierten Brute-Force - Schutz implementiert, ist der .htaccess deutlich überlegen.
Das einzige, was unabhängig davon WIRKLICH Sinn macht ist: Wenn du eine feste IP bzw. eine enge IP-Range hast, dann kannst du über die .htaccess jegliche Zugriffe von anderen IPs rundweg blocken.

Ich habe gerade nochmals mit dem Autor meines oben verlinkten Artikels Rücksprache gehalten. Seine Antwort dazu:

Sergej Müller schrieb:
Die htaccess hat doch den wesentlichen Vorteil, dass der Schutz direkt auf der Serverebene stattfindet - PHP wird in diesem Fall nie ausgeführt. Würde man einen Schutz via PHP abwickeln, dann sind Webserver und PHP unter Last (im Falle eine Attacke). Zudem ist .htaccess Schutz wirklich, wirklich sicher (sicheres Passwort vorausgesetzt) - in meiner ganzen Praxis habe ich nie gehört, dass eine WP Site trotz htaccess fehlerhafte Login-Versuche vermeldetet hat (wenn auch xmlrpc.php ebenfalls abgedichtet ist).

Gruß KeSch

Daaron · 4. August 2014

Bringt nur alles nix, wenn WP selbst, spätestens durch schlecht gewartete Plugins, löchrig wie n Schweizer Käse ist.... und das ist es nun einmal quasi immer. Dann brauchst du keinen Zugriff auf den Admin-Ordner, um schalten und walten zu können.

KeSch · 4. August 2014

Gut, das steht aber wieder auf einem anderen Blatt und hat mit der Absicherung des Loginbereichs eher weniger zu tun. Du wirst kein WP-Freund mehr und das ist auch gut so.

Hoffe trotzdem Martinus33 ein wenig geholfen zu haben.

Gruß KeSch

Edit: Der Vollständigkeit halber habe ich auch noch bei meinem Hoster Uberspace angefragt, wie sie mit etwaigen Brute-Force-Attacken usw. umgehen. Die Antwort wie folgt:

Wenn wir sehen, dass ein Host lahmt, weil da eine Site attackiert wird (egal ob da WordPress-Logins bruteforced werden oder sonstwas; das können ja viele Dinge sein), dann schauen wir erstmal, ob wir die Attacke irgendwie mitigieren können. Insbesondere bei WordPress-Logins können wir ja prima gleich serverseitig attackierende IP-Adressen z.B. mit fail2ban sperren.

Eine Unterlassungserklärung haben wir noch nie von einem User gefordert. Dass wir Sites tatsächlich temporär abklemmen bzw. beschränken mussten, ist seit es uns gibt glaube ich zwei oder drei Mal vorkommen, wobei das dann keine Attacken waren, sondern zum Beispiel im letzten Fall ein einzelner Blogpost, der irgendwie so intensiv via Facebook geteilt wurde, dass da dermaßen viele Besucher reinkamen, dass da nichts mehr ging ... da haben wir dann in diesem Fall von dem betreffenden Blogpost eine statische HTML-Kopie gezogen und via RewriteRule alle Anfragen danach dorthin umgeleitet, und haben dann den User entsprechend angeschrieben und ihn darin unterstützt, sein WordPress allgemein zu optimieren, also insbesondere ein vollwertiges Caching zu implementieren.

So kann man mit seinen Kunden anscheinend auch umgehen.

brute force bei Wordpress abwehren: Login-Beschränkung oder htpassword

Lt. Commander

Maître de cuisine

Lt. Commander

Lt. Junior Grade

Fleet Admiral

Lt. Commander

Fleet Admiral

Lt. Commander

Fleet Admiral

Lt. Commander

Lt. Junior Grade

Lt. Junior Grade

Fleet Admiral

Lt. Commander

Fleet Admiral

Lt. Commander

Fleet Admiral

Lt. Junior Grade

Fleet Admiral

Lt. Junior Grade