Passwort zurücksetzen
-
Eine Website wird seit Wochen stetig mit „Passwort zurücksetzen“ Anfragen belästigt. Die Redakteure und ich als Admin bekommen täglich beinahe 100 solcher Mails.
Ja, ich versichere allen, das (wie in dieser Mail eben steht) nichts passieren kann – doch kann wirklich nichts passieren?Leider brachten die bisherigen Maßnahmen, dies abzustellen, nichts.
Jeder berechtigte Benutzer inkl. ich als Admin haben völlig verschiedene Namen in den Benutzerfeldern (Benutzername, Vor-Nachmame, Spitzname, öffentlicher Name … alles unterscheidet sich gravierend) und nichts davon wird auf der Seite angezeigt.
Ebenso habe ich den REST API Endpunkt users blockiert und nachträglich wieder alle Benutzerdaten aller Benutzer geändert.
Dennoch, nach ein paar Tagen gehen die nervigen Anforderungen wieder los. Und die kennen stets die neuen Benutzernamen – woher?Ich möchte jetzt die Site noch nicht nennen, die steht eh grade unter Dauerfeuer.
Nur wenns sein muss, das jemand das checken kann, dann muss es halt sein.Oder habt ihr noch andere Tipps, die ich vorher umsetzen sollte?
-
Ich würde noch folgendes empfehlen:
- Installiere https://de.wordpress.org/plugins/honeypot/ – das schützt meines Wissens nach auch das öffentlich sichtbare „Passwort vergessen“-Formular und hat vor kurzem bei einem ähnlichen Fall sofort geholfen.
- Deaktiviere die XMLRPC-Schnittstelle. Über diese können ebenfalls solche Anfragen kommen wie auch Nutzernamen ausgelesen werden. Ein von dir genutztes Sicherheitsplugin hat dafür sicherlich Einstellungen. Wenn du bisher kein Sicherheitsplugin hast, installiere eines. Eine Auswahl findest du hier: https://de.wordpress.org/plugins/tags/security/ – Alternativ ginge auch das hier: https://de.wordpress.org/plugins/disable-xml-rpc-api/ – aber Vorsicht: manche Plugins nutzen tatsächlich noch die XMLRPC-Schnittstelle. Sie zu deaktivieren würde auch Funktionen der Plugins stören. Da du keinen Website-Bericht geliefert hast, kann man da schwer beurteilen.
- Oder schütze dein Backend mit einem AuthBasic-Schutz. Auch das kann dir ein Sicherheitsplugin bereitstellen. Manche Hoster bieten es ebenfalls als Funktion an. Du müsstest dann vor jedem Zugriff auf
/wp-login.phpoder/wp-admin/ein zusätzliches Passwort eingeben. Diese Möglichkeit stellt einen 100%igen Schutz vor dem Spam dar. Ob man ihn einrichten kann, hängt aber von deinem Hosting oder deinen Plugins ab. - Prüfe, ob du öffentlich Nutzernamen ausgibst. Je nach eingesetztem Theme und Plugins kann das auch völlig unbewusst geschehen. SEO-Plugins tragen z.B. den Autor gerne in Meta-Daten ein, die für Vorschauen in Social Media genutzt werden. Prüfe auch, ob du Autoren-Seiten hast, die WordPress standardmäßig bereitstellt (und die man oft übersieht), die aber z.B. per SEO-Plugin deaktiviert werden können.
Danke für die umfangreiche Info!
In wie weit hilft es, „das öffentlich sichtbare „Passwort vergessen“-Formular “ zu verstecken? Wird damit auch
wp-login.php?action=lostpasswordverändert?XMLRPC-Schnittstelle:
Dzt. ist folgender Code in der functions.php:add_filter( 'xmlrpc_enabled', '__return_false' ); /* Den HTTP-Header vom XMLRPC-Eintrag bereinigen */ add_filter( 'wp_headers', 'AH_remove_x_pingback' ); function AH_remove_x_pingback( $headers ) { unset( $headers['X-Pingback'] ); return $headers; }Ob das überhaupt was hilft?
Weiters hat auch der Hoster (Site ist auf Nginx) etwas bez. XML deaktivieren in die Serverkonfiguration eingetragen.AuthBasic-Schutz: Gute Idee, das mache ich aber auch mithilfe des Hosters (das kann der einfach machen, hatten wir schon mal bei einem anderen Projekt – wobei: Gegen den Passwort rücksetzen Terror hilft das nichts.). Aber ansonsten ist es schon eine ratsame Sache – Danke!
SEO-Plugins tragen z.B. den Autor gerne in Meta-Daten ein:
Ah, das hatte ich nicht am Schirm, das prüfe ich noch nach!PS: Nein, es ist kein Sicherheitsplugin installiert. Ua. weil man oft liest, dass diese riesigen Dinger nicht einfach automatisch schützen, nur weil man alles anklickt. Und die bisher angesehenen überfordern einem echt.
Daher setzte ich bisher gerne auf kleine Lösungen wie eben das Thema XML RPC zeigt.Nach einigen Maßnahmen und Beobachtung der Lage, folgender Nachtrag:
Also honeypot hilft hier nichts; auch weil es, wie vermutet, den Link nicht verändert.
Ebenso erfolgt kein Logging der Zugriffsversuche oder was auch immer dieses Plugin loggen sollte.Die XML-RPC Schnittstelle ist seit vielen Jahren serverseitig deaktiviert
Der AuthBasic-Schutz half nichts
Im SEO-Plugins ist nichts bez. Sozial-Media hinterlegt.
Auch taucht keiner der Benutzenamen im Quelltext keiner Seite auf.Sicherheitsplugins haben wir 3 probiert, doch keins konnte die Flut von Passwort zurücksetzen eindämmen.
Auch eine temp. Abschottung mittels „Password Protected“ brachte nichts. Wie auch?Inzwischen gehen den Redakteuren und mir schon die Ideen aus, wie wir die Benutzer umbenennen sollen.
Aber es hilft eh nichts, irgendeine Lücke verrät die nach einigen Stunden Ruhe gleich wieder …Somit kann man da scheinbar nichts gegen machen, außer ignorieren.
Markiere als gelöst, weil WP selbst können wir nicht reparieren, selbst wenn man die Lücke finden würde.
Das ist ja echt merkwürdig. Beim AuthBasic-Schutz vermute ich, dass der falsch eingerichtet wurde, denn ich habe das bei einigen Projekten schon erfolgreich im Einsatz gehabt. Ein Link zur betroffenen Website könnte helfen für dich zu schauen, ob und was man von draußen sieht. Ebenso auch der Website-Bericht.
Ich denke auch, ein korrekt gesetzter AuthBasic-Schutz auf wp-login.php (Apache-Server =.htaccess-Passowort-Zugangsschutz) behebt das Problem nachhaltig und vollständig.
Versuche es mal mit folgendem Code. Speichere diesen als (z. B.)
deactivate-password-reset.phpab und lade diese Datei hoch in das Verzeichnismu-plugins(das Verzeichnis musst du wahrscheinlich auch erstellen)wp-content => mu-plugins
Also schlussendlich
wp-content => mu-plugins => deactivate-password-reset.php<?php /** * Hardened Password Reset Control (No Mail Handling) * * - Passwort-Reset nur für Administratoren * - Lostpassword / Reset-Actions mit 403 blockieren * - retrieve_password() technisch absichern * - Kein Redirect, kein UI-Trick */ defined('ABSPATH') || exit; /* |-------------------------------------------------------------------------- | 1. Reset nur für Administratoren erlauben |-------------------------------------------------------------------------- */ add_filter('allow_password_reset', function ($allow, $user_id) { if (!$user_id || !is_numeric($user_id)) { return false; } $user = get_userdata((int) $user_id); if (!$user || empty($user->roles)) { return false; } return in_array('administrator', (array) $user->roles, true); }, 10, 2); /* |-------------------------------------------------------------------------- | 2. Reset-Actions frühzeitig blockieren (vor Core-Ausführung) |-------------------------------------------------------------------------- */ add_action('login_init', function () { if (empty($_REQUEST['action'])) { return; } $blocked_actions = ['lostpassword', 'retrievepassword', 'rp', 'resetpass']; if (in_array($_REQUEST['action'], $blocked_actions, true)) { status_header(403); nocache_headers(); exit('403 Forbidden'); } }, 1); /* |-------------------------------------------------------------------------- | 3. retrieve_password() zusätzlich absichern |-------------------------------------------------------------------------- */ add_filter('retrieve_password', function () { return new WP_Error( 'password_reset_disabled', 'Password reset is disabled.' ); }); /* |-------------------------------------------------------------------------- | 4. Lost-Password-URL neutralisieren |-------------------------------------------------------------------------- */ add_filter('lostpassword_url', function () { return home_url('/'); });Aber Achtung: Nur Admins können ihr Passwort noch ändern, jedoch nur dann, wenn sie angemeldet sind. Wird die Passwort-Reset-Abfrage benötigt, dann kannst du die Datei
deactivate-password-reset.phptemporär (per FTP) entfernen oder das Passwort in der Datenbank ändern.Es besteht noch die Möglichkeit, den Code so zu erweitern, dass keine Passwort-Reset-E-Mails gesendet werden, das ist aber überflüssig, wenn der obige Code funktioniert (denn dann werden die erst gar nicht mehr generiert). Sollten weitherhin E-Mails eintreffen, funktioniert der Code nicht vollständig.
Danke, das liest sich sehr sicher!
Danke auch bez. der Hinweise im anderen Thema zu ?author=1 und der REST API (s. Eingangspost „… Ebenso habe ich den REST API Endpunkt users blockiert …“)
Also wenn man die ID der Benutzer unfallfrei ändern kann, dann würde ich das sogar noch vor dem Einsatz von diesem Script, eigentlich MU Plugin, machen.
Darf man das echt direkt in der DB machen?Wenn ja, reicht es die, oder sollte man das noch wo berücksichtigen?usersTabelle, FeldIDzu ändern
Eigenantwort: Leider reicht das nicht, danach ist dem geänderten Benutzer nichts mehr möglich …-
Diese Antwort wurde vor 2 Monaten, 3 Wochen von
onlaie geändert.
Die Fragen gehören in den anderen Thread
¯\_(ツ)_/¯
Du musst angemeldet sein, um auf dieses Thema zu antworten.