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

[Martinus33]

Hoffe trotzdem Martinus33 ein wenig geholfen zu haben.

Danke, hast du, wobei Gegenmeinungen durchaus willkommen sind und ebenfalls "helfen", sofern korrekt und sachlich bleibend.

Was die Hoster angeht, ich habe erst kürzlich bez. der Absicherung der xml-rpc.php von einem Fall gelesen, bei dem der Hoster von sich die Datei auf die Rechte 300 gesetzt hat. Ist nicht die gleiche Sache, aber hat mich daran erinnert, dass ein Hoster i.d.R. nicht unnötig seine Kunden verprellen will und Sicherheit auch in seinem eigenen Interesse ist. Keine Ahnung, was "üblich" ist, aber "Website einfach abschalten" + Unterlassungserklärung klingt für mich als Kunde ebenfalls überzogen.

 

[KeSch]

Zur Absicherung der XML-RPC Schnittstelle gibt es auch eine gute Anleitung.

Darin wird auch auf die Möglichkeit der Absicherung eben dieser Schnittstelle mittels Fail2Ban hingewiesen, die auch Daaron vorhin mal kurz mal erwähnt hat. Da aber nicht jeder die Möglichkeit hat selbst Software/Module auf dem Server zu installieren, gibt es auch dafür ganz einfach alternative Lösungen, wie eben in obiger Anleitung beschrieben.

 

[Martinus33]

Habe mir den Artikel gerade durchgelesen.
Im Hinblick auf die Zugangbeschränkung auf WP frage ich mich, ob das wirklich sicher ist. Könnte das nicht "nachgeahmt" bzw. vorgetäuscht werden von einem Angreifer?

Was auch andere Quellen so sagen, scheint die htaccess-Lösung wirklich die beste zu sein. Komplett auf Pingback/Trackback verzichten will halt nicht jeder.

Die Rechte auf 300 zu setzen, wäre nicht gleichwertig, weil es zwar den Zweck erfüllt, aber "unerwünschte Nebenwirkungen"
hat?

 

[KeSch]

Habe mir den Artikel gerade durchgelesen.
Im Hinblick auf die Zugangbeschränkung auf WP frage ich mich, ob das wirklich sicher ist. Könnte das nicht "nachgeahmt" bzw. vorgetäuscht werden von einem Angreifer?

Ja, ein Angreifer könnte einen "falschen" User-Agent vortäuschen. Steht so auch im Artikel.

Was auch andere Quellen so sagen, scheint die htaccess-Lösung wirklich die beste zu sein. Komplett auf Pingback/Trackback verzichten will halt nicht jeder.

Wenn man auf Pingbacks/Trackbacks nicht verzichten kann/will ist der Ausschluss von bestimmten Agents schon ein gutes Stück sicherer, als die Schnittstelle für alle Agents vollkommen offen zu lassen - offen bleibt sie aber dennoch. Einzig die komplette Deaktivierung der Schnittstelle verschließt diese Tür für zum Beispiel einfache DDoS-Angriffe.

Wirklich sicher, vorausgesetzt es können Module am Server installiert werden (bei Uberspace ist dies übrigens möglich), ist nur die Blacklist-Methode mit Fail2Ban. Wartung und Pflege der Blacklist und Firewall-Regeln sind auch hier Pflicht. Auch dazu gibt es von Sergej übrigens einen guten Artikel.

Die Rechte auf 300 zu setzen, wäre nicht gleichwertig, weil es zwar den Zweck erfüllt, aber "unerwünschte Nebenwirkungen"
hat?

Ein CHMOD bzw. Rechte von 300 kommt mir sehr seltsam vor und sind mir so noch nicht untergekommen. Wenn die Schnittstelle deaktiviert werden soll, dann einfach Variante 1 aus dem zuvor verlinkten Artikel, also komplett deaktivieren via .htaccess.

Wenn die Schnittstelle aktiv bleiben soll, ist 644 die richtige Einstellung, denn der Server muss die Datei lesen können.

Gruß KeSch

 

[Martinus33]

"...User-Agent-Wert zu manipulieren."
Sorry.

Das mit den Rechten klang für mich als "Halbwissenden" zunächst genial einfach und effektiv. Vermutete aber, dass es aus irgendwelchen Gründen langfristig nicht praktikabel ist oder unschöne Nebeneffekte hat.

"Wartung und Pflege der Blacklist und Firewall-Regeln sind auch hier Pflicht."
--> Also einmal mehr die .htaccess. Sicher und langfristig sauber erledigt, ohne regelmäßigen Aufwand.

Merci.

 

[Daaron]

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:

Dann fang dir mal ne Seuche (z.B. ein kompromittiertes WP) bei nem Dedicated bei Hetzner ein. Die drehen dir direkt den Saft ab, spätestens wenn sie ne Abuse-Mail erhalten.

Ein CHMOD bzw. Rechte von 300 kommt mir sehr seltsam vor und sind mir so noch nicht untergekommen.
...
Wenn die Schnittstelle aktiv bleiben soll, ist 644 die richtige Einstellung, denn der Server muss die Datei lesen können.

300 macht tatsächlich gar keinen Sinn, denn 3|0|0 wäre -wx------. Wozu bitte soll eine PHP-Datei ein X-Bit haben? Was soll w bringen, ohne r? Wenn, dann 400...
Aber 644 ist auch so eine Sache... Tatsächlich kann es bei Wordpress Sinn machen, Schreibrechte für den User zu entziehen. Das verhindert zuverlässig die klassischen base64-Geschichten. DAs sollte man aber als Hoster nur tun, wenn der User auf mehrere Ermahnungen hinsichtlich seiner Sicherheit nicht reagiert.