mod_rewrite-Regeln von WP hebeln Schutz der wp-login.php aus

viehrig
(@viehrig)

vor 7 Jahren, 10 Monaten
Hallo in die Runde!

Will man die Permalinks anders als in der Standardkonfiguration haben und ändert entprechend die htaccess-Datei (bzw. läßt diese durch WP ändern), so wird bekanntlich folgender Code generiert:
```
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
```
Dieser sorgt unter anderem auch dafür, daß „index.php“ aus dem URL entfernt wird. So weit, so gut.

Schon lange wollte ich meine wp-login.php über die htaccess mit einer htpasswd-Datei absichern, was mir aber nie gelang, ohne in Erfahrung bringen zu können, wieso. Letztens war ich darüber aufgrund von rund tausend Angriffen pro Tag auf die wp-login.php derart frustriert, daß ich eine neue htaccess anlegte, die um die mod_rewrite-Regeln von WP bereinigt war und stattdessen ausschließlich den Code zum Schutz der wp-login.php mittels htpasswd-Datei enthielt:
```
#Absicherung wp-login

<Files wp-login.php>
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /Pfad/zur/Datei/.htpasswd
   Require valid-user
</Files>
```
Nun funktionierte der zusätzliche Schutz der wp-login.php plötzlich.

Wenn ich die mod_rewrite-Regeln wieder einfüge, funktioniert dieser Schutz nicht mehr. Es spielt auch keine Rolle, an welcher Stelle ich das einfüge.
Gleiches Verhalten tritt bei allen Regeln der 6G Firewall auf. Auch hier kann ich die Positionen der einzelnen Blöcke frei variieren, sie sind sofort wirkungslos, sobald der WP-Block eingefügt wird.

Ich könnte notfalls auch ohne die mod_rewrite-Regeln von WP leben, möchte aber wenigstens den index.php-Teil aus den Permalinks verbannen und wie die Jahre zuvor das Format

/%year%/%monthnum%/%postname%/

verwenden, weiß aber eben nicht, wie ich das hinbekommen soll.

Derzeit habe ich eine Umleitungsregel als Notbehelf in die htaccess geschrieben:

RedirectMatch 301 ^/([0-9]{4})/([0-9]{2})/(?!page/)(.+)$ https://viehrig.net/index.php/$3

Der funktioniert immerhin, also bleibt meine Seite auch mit den bisherigen Verlinkungen ohne index.php im URL weiterhin erreichbar.
Aber eigentlich möchte ich es lieber umgekehrt, also von dem URL mit index.php auf einen ohne umleiten, doch dazu müßte dieser erst kreiert werden.

Keine Ahnung, wie ich das machen soll, ohne die obigen Schutzmaßnahmen auszuhebeln. Hat jemand Vorschläge, die natürlich ohne weitere Plugins auskommen sollen?
- Dieses Thema wurde geändert vor 7 Jahren, 10 Monaten von viehrig.

Ansicht von 14 Antworten – 1 bis 14 (von insgesamt 14)

Moderator Bego Mario Garde
(@pixolin)

vor 7 Jahren, 10 Monaten
Ich möchte dir eine andere Vorgehensweise vorschlagen, bei der du den Zugriff auf die wp-login.php komplett sperrst und trotzdem Permalinks nutzen kannst:

Installiere das Plugin Rename wp-login.php und vergib in diesem Plugin einen eigenen Seitennahmen für das Anmeldeformular (z.B. https://deinedomain.de/anmelden). Dann fügst du in der .htaccess noch rasch folgende Regel hinzu:
```
<FilesMatch "(.htaccess|.htpasswd|wp-config(-sample)\.php|wp-login|liesmich|readme|wp-mail)">
  order deny,allow
  deny from all
</FilesMatch>
```
Da die meisten Angriffen mit Hilfe von Skripten ausgeführt werden (auch Hacker versuchen effizient zu arbeiten), reicht die Fehlermeldung 403 – Forbidden, um die meisten Angriffe auszuhebeln. (Alle anderen, die zufällig doch auf der Anmeldeseite landen sollten, scheitern dann an Usernamen und Passwort.)
Thread-Starter viehrig
(@viehrig)

vor 7 Jahren, 10 Monaten
Danke für die Antwort und den Hinweis auf die wp-mail.php, die man besser auch noch verriegeln sollte.

Wahrscheinlich habe ich mich unklar ausgedrückt. Das Problem besteht darin, daß unter anderem keine 403-Meldung ausgegeben wird, sobald ich die mod_rewrite-Regeln von WP in die htaccess einfüge. Vielmehr wird stattdessen eine 404-Meldung erzeugt und die entsprechende Seite des Themes geladen, womit ein Hauptziel, nämlich den Traffic durch „Hackroboter“ auf das unvermeidbare zu reduzieren, verfehlt wird. Des weiteren habe ich ganze IP-Bereiche in der htaccess gesperrt, aus denen ausschließlich entsprechende Zugriffe kommen. Wenn jedesmal erst die 404-Seite des Themes statt der 403-Meldung ausgegeben wird, produziert das schlicht zuviel und vor allem völlig unnötige Serverlast.

Lasse ich die mod_rewrite-Regel von WP weg, wird der allermeiste Dreck abgefangen, noch bevor WP überhaupt ins Spiel kommt.

Und schließlich kann man wahrscheinlich darüber streiten, mit welcher Methode die wp-login.php besser abgesichert ist. Beim gegenwärtig von mir praktizierten Zugriffsschutz über die htaccess wäre erst eine Wahrscheinlichkeit von 1 zu 62^100 zu überwinden, bevor die wp-login.php überhaupt geladen wird. Anschließend hat man genau 1 Versuch, um die richtige von nochmal 62^100 Möglichkeiten zu treffen. Schlägt dieser fehl, wird die IP für ein Jahr gesperrt. Selbst wenn der Hacker Zugriff auf alle 4.294.967.296 IPv4-Adressen hätte, er käme nicht weit.
- Diese Antwort wurde geändert vor 7 Jahren, 10 Monaten von viehrig.
- Diese Antwort wurde geändert vor 7 Jahren, 10 Monaten von viehrig.
archesis
(@anchises)

vor 7 Jahren, 10 Monaten

Vorschlag: Eine eigene htaccess im Ordner wp-admin anlegen. („admin-ajax.php“ ausnehmen)

Thread-Starter viehrig
(@viehrig)

vor 7 Jahren, 10 Monaten

Danke.

Ganz gleich, wie ich es derzeit anstelle, ich bekomme es nicht hin, ohne den Paßwortschutz der wp-login.php sowie die anderen Zugriffsbeschränkungen bei bestimmten Abfragen auszuhebeln.

Wie ich schon schrieb, ich kann damit leben. Der Teil

/index.php/

im URL ist zwar eigentlich komplett entbehrlich, aber andererseits verkraftbar, dennoch unschön.

Nun ja.
archesis
(@anchises)

vor 7 Jahren, 9 Monaten
Noch mal:

1) .htaccess im wp-admin Ordner anlegen. Dort kommt Folgendes rein:
```
#Zugriff auf ajax erlauben
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>

#Passwortschutz
AuthType Basic
AuthName "Bitte anmelden"
AuthUserFile /kompletter/server/pfad/zu/dem/verzeichnis/.htpasswd
require valid-user 

#Zugriff auf ajax erlauben
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>
```
2) .htpasswd erstellen:
http://www.htaccesstools.com/htpasswd-generator/

Automatische IP-Sperren für 404-Zugriffe auf nicht existente Seiten kann z. B. das Plugin „All In One WP Security & Firewall“:
https://de.wordpress.org/plugins/all-in-one-wp-security-and-firewall/
- Diese Antwort wurde geändert vor 7 Jahren, 9 Monaten von archesis.
Thread-Starter viehrig
(@viehrig)

vor 7 Jahren, 9 Monaten
Danke, aber es funktioniert nicht.

Versucht habe ich, während ausschließlich die mod_rewrite-Regeln von WP in der htaccess im WP-Verzeichnis standen:

1. Den Code so zu implementieren, wie oben vorgegeben, also damit eine htaccess in wp-admin angelegt, lediglich den Pfad zur htpasswd habe ich angepaßt.
Ergebnis: htpasswd wird nicht abgefragt, die wp-login.php ist wüst zerschossen, Login-Versuche führen zur 404-Seite des Themes

und weil es mir irgendwie logisch erschien, die admin-ajax.php nicht zweimal zu erlauben, habe ich probiert, in der htaccess im wp-admin-Ordner:

2. die Freigabe der admin-ajax.php nur vor der Abfrage der .htpasswd einzufügen
Ergebnis: wie bei 1.

3. die Freigabe der admin-ajax.php nur nach der Abfrage der .htpasswd einzufügen
Ergebnis: wie bei 1.

4. die Varianten 1. bis 3., aber den obigen Code zur Abfrage der htpasswd erweitert:
```
<Files wp-login.php>
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /kompletter/server/pfad/zu/der/Datei/.htpasswd
   Require valid-user
</Files>
```
Ergebnis in den Fällen 4. bis 6: htpasswd wird nicht abgefragt, ich kann mich ungehindert über die wp-login.php normal einloggen.
- Diese Antwort wurde geändert vor 7 Jahren, 9 Monaten von viehrig.
- Diese Antwort wurde geändert vor 7 Jahren, 9 Monaten von viehrig.
- Diese Antwort wurde geändert vor 7 Jahren, 9 Monaten von viehrig.
Thread-Starter viehrig
(@viehrig)

vor 7 Jahren, 9 Monaten

Um eventuelle Zweifel auszuschließen, ein Nachtrag: Ich habe natürlich nach jedem Versuch die komplette Historie des Browsers gelöscht.

Wenn ich die mod_rewrite-Regeln von WP im WP-Verzeichnis weglasse, stattdessen dann dort die Abfrage der htpasswd implementiere, funktioniert auch deren Abfrage.
Thread-Starter viehrig
(@viehrig)

vor 7 Jahren, 9 Monaten
Und noch ein Nachtrag, weil es vielleicht dabei hilft, dem Problem auf die Spur zu kommen: Füge ich im Verzeichnis wp-admin eine htaccess ein, die folgenden Code enthält:
```
AuthUserFile /Pfad/zur/Datei/.htpasswd
 AuthGroupFile /dev/null
 AuthName "Restricted Admin-Area"
 AuthType Basic
<limit GET POST>
 require valid-user
</limit>

#Zugriff auf ajax erlauben
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>
```
dann funktioniert die Paßwortabfrage durch die htpasswd genau solange, bis ich die mod_rewrite-Regeln in die htaccess im WP-Hauptverzeichnis wieder einfüge.
- Diese Antwort wurde geändert vor 7 Jahren, 9 Monaten von viehrig.
- Diese Antwort wurde geändert vor 7 Jahren, 9 Monaten von viehrig.
Moderator Marcus Spanier
(@espiat)

vor 7 Jahren, 9 Monaten

Als gelöst markiert.

Thread-Starter viehrig
(@viehrig)

vor 7 Jahren, 9 Monaten

Ist aber nicht gelöst. Als ungelöst markiert.

Moderator Marcus Spanier
(@espiat)

vor 7 Jahren, 9 Monaten

Entschuldigung. Ich hatte da an einer Stelle was falsch verstanden.

Du bist nach dieser Anleitung vorgegangen?
https://codex.wordpress.org/Brute_Force_Attacks#Password_Protect_wp-login.php

Thread-Starter viehrig
(@viehrig)

vor 7 Jahren, 9 Monaten

Es gibt mehrere Möglichkeiten, die htpasswd und die htaccess, die die zusätzliche Paßwortabfrage auslöst, zu plazieren. Entweder liegt der Code zur Paßwortabfrage im WP-Hauptverzeichnis in der dortigen htaccess oder man richtet eine zusätzliche htaccess im wp-admin-Verzeichnis ein, die das übernimmt. Die htpasswd kann man nahezu beliebig irgendwo im Serververzeichnis ablegen (sollte man zwar nicht, geht aber prinzipiell), sofern man den genauen Pfad zu ihr angibt.

Alle diese Wege funktionieren.

Bis ich die mod_rewrite-Regeln von WP in die htaccess im WP-Hauptverzeichnis einfüge, wo sie ja hingehören. Dann funktioniert keiner dieser Wege mehr.

Gegenwärtig nutze ich die hier geschilderte Variante.

Aber grundsätzlich ist das egal, welche Variante man nimmt. Die mod_rewrite-Regeln von WP lösen das Problem aus. Und ich habe noch immer keinen Schimmer, wieso.

Moderator Torsten Landsiedel
(@zodiac1978)

vor 7 Jahren, 9 Monaten

In welcher Reihenfolge fügst du die Code-Teile in die .htaccess ein? Kann es sein, dass du den Passwortblock unter den WP-Block eingefügt hast? Dann versuche es mal andersherum.

Bei welchem Hoster bist du? Hast du deren Support mal angesprochen?

Gruß, Torsten

Thread-Starter viehrig
(@viehrig)

vor 7 Jahren, 9 Monaten

Danke für die Antwort.

In welcher Reihenfolge fügst du die Code-Teile in die .htaccess ein? Kann es sein, dass du den Passwortblock unter den WP-Block eingefügt hast? Dann versuche es mal andersherum.

Siehe erster Beitrag.

Bei welchem Hoster bist du? Hast du deren Support mal angesprochen?

Steckt da eine konkrete Idee hinter der Frage, was der Hoster verbockt haben könnte? Welche wäre das?