it-swarm.com.de

Gibt es Möglichkeiten, sich in der Bypass-Datei wp-login.php einzuloggen?

Ich habe eine WP -Installation, die in den letzten Tagen von Anmeldeversuchen mit brutaler Gewalt gehämmert wurde.

Auf der Site ist das Plug-In Anmeldeversuche beschränken installiert. Und als ich anfing, häufig Benachrichtigungen über Sperrungen zu erhalten, entschied ich mich, da ich nur von einer Stelle aus auf die wp-login.php-Datei und den wp-admin zugreife, um alle IPs außer meinen eigenen über .htaccess zu blockieren. Ich habe den .htaccess-Block getestet, indem ich meine IP-Adresse aus der Ausnahmeliste entfernt habe, und er blockiert in der Tat den Zugriff auf wp-login.php. Es scheint also unter diesem Aspekt zu funktionieren.

Selbst wenn IP-Adressen blockiert sind, werden bei "Anmeldeversuche beschränken" weiterhin (häufige) Sperren von IP-Adressen gemeldet. Ich fand das merkwürdig, da es mit dem .htaccess-Block anscheinend unmöglich sein sollte, an das wp-login.php-Skript heranzukommen, geschweige denn, einen Anmeldeversuch vom Plug-in verarbeiten zu lassen.

Also habe ich es mit einem anderen Experiment versucht: Während ich bereits in WP angemeldet war, habe ich den Namen von wp-login.php in wp-login.xyz geändert, wodurch das Skript nicht mehr vollständig ausgeführt werden kann. Selbst wenn das Anmeldeskript vollständig deaktiviert ist, werden Anmeldeversuche durchgeführt und IP-Adressen gesperrt.

Dann dachte ich, vielleicht hat jemand einen Auth-Cookie. Also habe ich die Salze gewechselt. Trotzdem kommen die Versuche.

Ich habe im Codex nach Hilfe für die Authentifizierungs-API gesucht, aber die meisten Quellen sind unvollständig, und auf jeden Fall finde ich nicht heraus, wie es möglich sein könnte, eine andere Anmeldung als über wp-login.php zu versuchen.

Meine Frage lautet also: Was sind, falls überhaupt, andere Möglichkeiten, um sich anzumelden, ohne das Skript wp-login.php? Und wie können solche alternativen Anmelderouten deaktiviert werden?

BEARBEITEN: .htaccess-Code (erste Zeile der Datei): Befindet sich im Stammverzeichnis WP (gleicher Speicherort wie wp-login.php).

<FilesMatch wp-login.php>
order deny,allow
Deny from all

# Allow from this IP address
allow from xx.xxx.xxx.xx  #My IP
</FilesMatch>

ErrorDocument 401 "Sorry. No logins here!"
ErrorDocument 403 "Sorry. No logins here!"
1
Caspar

Die Antwort ist höchstwahrscheinlich XML-RPC, das für die Kommunikation mit den mobilen WordPress-Apps verwendet wird und in neueren Versionen immer aktiviert ist. Wenn Sie keine mobilen Apps verwenden, um Ihr WP zu verwalten, können Sie mein Plugin - http://wordpress.org/plugins/control-xml-rpc-publishing/ verwenden, um es zu deaktivieren.

2
Mark Kaplun

Wie @MarkKaplun andeutete, handelte es sich tatsächlich um XML-RPC. Ich kontaktierte die Hosting-Firma und bat um ein Auslesen der Protokolle. xmlrpc.php wurde in weniger als 24 Stunden mehr als 3500 Mal aufgerufen (und dies ist eine kleine Site, auf der niemand einen Grund hätte, so oft auf irgendetwas zuzugreifen!).

Bearbeiten

Ich vermute, dass hier etwas passiert ist. Aus Antti Vilpponens Blog zur Abwehr von xmlrpc-Angriffen:

Bei den von mir durchgeführten Tests habe ich festgestellt, dass WordPress auch URLs mit Anmeldeinformationen unterstützt. Ein Angreifer kann also eine URL wie http://admin:[email protected]/changeDNS.asp?newDNS=aaaa verwenden, um den internen Router neu zu konfigurieren.

Es schlägt also xmlrpc.php mit der Anforderung mit Berechtigungsnachweis, die die gleiche Wirkung hat wie die Verwendung von wp-login.php und WP auslöst, um in die Authentifizierungsroutine zu gelangen - was wiederum das Plug-in "Anmeldeversuche beschränken" auslöste und die Sperrungen erzeugte.

/ Bearbeiten

Anstatt ein Plug-In zu verwenden (dies war vor der Beantwortung von @MarkKaplan), habe ich mich dafür entschieden, einfach den gesamten Zugriff auf xmlrpc.php auf dem Server zu unterbrechen, indem ich .htaccess im Stammverzeichnis WP wie folgt verwendete:

<Files xmlrpc.php>
    Order allow,deny
    Deny from all
</Files>

Lief wie am Schnürchen. Mein Login war stumm.

Bearbeiten

Der Dateiname in der Apache-Direktive wurde als xlmrpc.php falsch geschrieben. Es wurde versucht, dies zu korrigieren, aber das Bearbeitungslimit für Stapelaustausch-Zeichen ließ mich erst zu, als ich diesen nutzlosen Absatz schrieb. Es ist jetzt richtig.

1
Caspar