Solved
Schutz Wordpress Dateien via httpd.conf (ID=544)
4 years ago
Guten Tag,
ich versuche die beiden Dateien wp-login.php und xmlrpc.php via httpd.conf zu schützen (ID=544). Das klappt aber nicht.
zu 1: wp-login.php
Eintrag entsprechend erfolgt wie beschrieben. Ich komme aber weiterhin direkt auf WordPress-Login Panel.
Ergänzend dazu: Das Verfahren als solches klappt, da ich ein Verzeichnis (außerhalb von Wordpress) mit diesem Verfahren schütze und dies auch in diesem Zusammenhang extra noch einmal getestet habe. Beim Aufruf einer Datei in diesem Verzeichnis kommt direkt das Anmeldefenster für UID/PW. Generell klappt also das Verfahren.
zu 2: xmlrpc.php
Ebenso eingetragen wie beschrieben. Ich denke aber, dass dieser Schutz auch nicht wirkt, da ich im WP-Dashboard (SecurityPlugin) Zugriffsversuche erhalte, die abgewehrt wurden. Die dürften da ja eigentlich nicht auftauchen, wenn der Schutz bereits auf der httpd.conf Seite erfolgt wäre.
Ich habe zwei Dinge im Verdacht, kann das aber nicht verifizieren:
1. ggf. die bei WP-Installation automatisch generierte .htaccess Datei im WP-Verzeichnis
2. Eine Weiterleitung der Domain auf das Wordpress-Verzeichnis
Der Punkt 2 scheint mir am wahrscheinlichsten, da das Verfahren mit PW-Schutz ja für ein Verzeichnis außerhalb Wordpress problemlos funktioniert.
Falls jemand eine Idee hat, was das Problem sein könnte bzw. welche Möglichkeiten ich habe um die Ursache lokalisieren zu können, wäre ich für Hilfe dankbar.
Grüße Michael
815
0
17
Accepted Solutions
All Answers (17)
Sort by
Oldest first
Newest first
Oldest first
Author
All
This could help you too
3 years ago
242
0
2
258
0
2
6 years ago
270
0
3
Accepted Solution
Nadine H.
Telekom hilft Team
accepted by
tws_snoopy
4 years ago
Ich habe mir das Ganze mal mit einem Kollegen genauer angeschaut. Es wurde alles richtig gemacht, es war nur noch nicht umgesetzt. Mit apachectl reload aus https://homepagecenter.telekom.de/index.php?id=277 wurden die Änderungen jetzt umgesetzt.
Aktuell haben wir dazu gerade einen Störungseintrag, hier nachzulesen: https://homepagecenter.telekom.de/index.php?id=stoerungen-und-fehler
Interessant wäre noch, wann genau die Änderungen gemacht wurden und ob das jetzt wirklich mehrere Tage nicht übernommen wurde oder in welchem Zeitraum ungefähr?
Danke schon mal für die Rückmeldung & ein schönes Wochenende.
Nadine H.
2
11
Load 8 older comments
Ingo F.
Telekom hilft Team
Answer
from
Nadine H.
4 years ago
Hallo Michael,
und jetzt haben wir auch dazu eine Information für Dich.
Laut den Kollegen kommen sich hier die zwei Passwortabfragen in die Quere, da WordPress im Hintergrund bei verschiedenen Login-Möglichkeiten die wp-login.php nutzt. Wenn man seinen Besuchern eine Login Option über Wordpress anbietet, dann kommt man mit diesem zusätzlichen Schutz leider an die Grenze, da dann ebenfalls die zusätzlich gesicherte wp-login.php im Hintergrund ausgeführt werden muss.
Man könnte jetzt vielleicht auf den Passwortschutz im Wordpress verzichten und diese Extraseiten auch über den Passwortschutz mit der httpd.conf sichern. Dies hat aber den optischen Nachteil, dass Besucher sich nicht auf der eigentlichen Seite einloggen, sondern schon vor dem Aufruf der Seite vom Browser die Abfrage bekommen. Spätestens wenn sich Nutzer auch registrieren können sollen, funktioniert das aber nicht mehr. In diesem Fall würden die Kollegen empfehlen, den zusätzlichen Schutz der wp-login.php nicht mehr zu verwenden.
Gruß
Ingo F.
1
tws_snoopy
Answer
from
Nadine H.
4 years ago
Guten Morgen, @Ingo F.
Danke für die Information. Schade, aber nicht zu ändern. Ich habe für mich jetzt eine Lösung gefunden, da der eigentliche Schutz auf einer Bildergalerie (jAlbum) liegt, die aber nicht WP-intern läuft.
So habe ich jetzt die eigentliche Seite mit "unverfänglichen" Daten normal veröffentlicht und den Link zur Bildergalerie dort eingebunden. Dort wird dann UID/PW über den Schutz für Verzeichnisse (ID=440) abgefragt. Und bei mir sind es nur 4 "persönliche" Galerien, sodass ich damit leben kann. Von daher belasse ich den Schutz für die wp-login.php auch.
Danke auch an die Kolleg:innen für eure Mühe. Ich würde das Thema dann (zum dritten Mal 😉) als erledigt kennzeichnen.
Gruß aus Frankfurt Michael
2
Nadine H.
Telekom hilft Team
Answer
from
Nadine H.
4 years ago
Hallo Michael,
vielen Dank für deine Rückmeldung, schön, dass du für dich eine Lösung gefunden hast. Wir helfen gerne weiter, also wenn noch mehr Fragen aufkommen, weißt du, wo du uns findest.
Viele Grüße Nadine H.
1
Unlogged in user
Answer
from
Nadine H.
Accepted Solution
Nadine H.
Telekom hilft Team
accepted by
Nadine H.
4 years ago
Guten Abend Michael,
folgende Rückmeldung habe ich nun von meinem Kollegen bekommen:
Tatsächlich ist es so, dass damit interne Zugriffe auf die wp-login.php auf den Fehler 401 laufen. Wahrscheinlich könnte man das einfach ignorieren, es sind zumindest keine Einschränkung bekannt. Besser wäre es aber, den internen Zugriff zu erlauben. Der Kollege hat den Artikel https://homepagecenter.telekom.de/index.php?id=544 etwas angepasst, schaue doch bitte einmal dort.
Mit dem zusätzlichen Eintrag "Require host hosting.telekom.de" werden Zugriffe, die vom Server selbst kommen, zugelassen. Damit ist bei seinem Test auch nicht mehr der Hinweis im Dashboard.
Vielen Dank noch für deinen Hinweis.
Lieben Gruß & schönen Abend noch.
Nadine H.
1
0
Accepted Solution
tws_snoopy
accepted by
tws_snoopy
4 years ago
@Nadine H.
Liebe Nadine,
SUPER! - vielen Dank auch an deinen Kollegen. Ich habe das gleich geändert, aktiviert und danach im WP-Dashboard geprüft - Meldung ist weg.
Super und einen schönen Abend noch (oder einen guten Start in den Tag).
Lieben Gruß Michael
2
0
Accepted Solution
Ingo F.
Telekom hilft Team
accepted by
tws_snoopy
4 years ago
Hallo Michael,
und jetzt haben wir auch dazu eine Information für Dich.
Laut den Kollegen kommen sich hier die zwei Passwortabfragen in die Quere, da WordPress im Hintergrund bei verschiedenen Login-Möglichkeiten die wp-login.php nutzt. Wenn man seinen Besuchern eine Login Option über Wordpress anbietet, dann kommt man mit diesem zusätzlichen Schutz leider an die Grenze, da dann ebenfalls die zusätzlich gesicherte wp-login.php im Hintergrund ausgeführt werden muss.
Man könnte jetzt vielleicht auf den Passwortschutz im Wordpress verzichten und diese Extraseiten auch über den Passwortschutz mit der httpd.conf sichern. Dies hat aber den optischen Nachteil, dass Besucher sich nicht auf der eigentlichen Seite einloggen, sondern schon vor dem Aufruf der Seite vom Browser die Abfrage bekommen. Spätestens wenn sich Nutzer auch registrieren können sollen, funktioniert das aber nicht mehr. In diesem Fall würden die Kollegen empfehlen, den zusätzlichen Schutz der wp-login.php nicht mehr zu verwenden.
Gruß
Ingo F.
1
0