AW: Schutz Wordpress Dateien via httpd.conf (ID=544)

[#1]

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

[#2 · Accepted solution]

@tws_snoopy

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.

[#3 · Accepted solution]

@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

[#4 · Accepted solution]

@tws_snoopy

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.

[#5 · Accepted solution]

Hallo @tws_snoopy

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.

[#6]

Der Schutz erfolgt zweckmäßig durch eine Kombination aus User/Passwort in der Datei .htpasswd und einem Einrag in der Datei .htaccess, der auf die .htpasswd verweist. Erklärung z. B. unter https://www.webtimiser.de/wordpress-login-schuetzen/

[#7]

@mboettcher 

Guten Morgen, danke für dieses Tipp. Das habe ich mir angesehen (ist ja im Prinzip das gleiche Verfahren innerhalb wordpress). Allerdings finde ich die Idee nicht ganz uninteressant, den Schutz bereits "vor" wordpress zu installieren.

Und generell möchte ich natürlich wissen, warum das beschriebene Verfahren nicht funktioniert.

Könnten dazu vielleicht @Ingo F. , @Nadine H. oder @Stephie G.  etwas sagen?

Danke schön!

[#8 · Accepted solution]

Hallo @tws_snoopy

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.

[#9]

@Nadine H. 

Hallo Nadine - super, gerade getestet - plop und das Anmeldefenster durch httpd.conf Schutz war da. 😁

Zur Nachfrage wegen der Änderung. Meine Datei hat als letztes Änderungsdatum den 02.01.2021 (und ich habe das nach der Änderung auch direkt hochgeladen). Ich denke mal, dass ich auch die letzten Versuche mit einer Neuanmeldung (in anderem Browser) am 02.01./03.01. durchgeführt habe, da ich auf dem Dashboard durchgehend angemeldet war. Von daher kann ich jetzt nicht sagen, wann das wirksam wurde (oder jetzt mit eurem Eingriff). Ich hatte allerdings noch bis heute Zugriffsversuche im WP-Plugin angezeigt erhalten - daher ist das aller Wahrscheinlichkeit durch euren Eingriff erst jetzt wirksam geworden.

Jedenfalls finde ich das sehr schön - dann sollte ja das WP Plugin in Zukunft für die beiden Dateien keine Zugriffsversuche mehr anzeigen. Ich gehe ja davon aus, dass der Schutz für die xmlrpc-Datei jetzt genau so gut funktioniert.

Danke für die schnelle Hilfe und auch ein schönes, ruhiges Wochenende. Passt auf euch auf.

Michael

[#10]

@Nadine H. 

Guten Tag, Nadine.

Ein kleiner Nachtrag zum Thema. Ich habe in meinem Dashboard beim Prüfen des Zustandes der "Webseite" eine neuen Warnhinweis.

Um diesen Hinweis genau lokalisieren zu können habe ich zunächst komplett alle Plugins deaktiviert - Fehlermeldung kam weiterhin. Daraufhin habe ich die httpd.conf ohne die beiden hier im Thread aufgeführten Einträge zum Schutz der beiden Dateien wp-login.php und xmrlpc.php entfernt, diese httpd.conf hochgeladen und mit dem Command "apachectl reload" auch gleich aktiviert. 

Nach Entfernung der Einträge wurde die Warn-Meldung im Dashboard nicht mehr angezeigt. Anschließend wieder die originale Datei mit den Einträgen hochgeladen und aktiviert - danach wurde die Warn-Meldung wieder angezeigt.

Ich habe beim googlen die Meldung mehrmals gefunden, aber nicht so richtig einordnen können. Mit dem Status-Code 401 (Unauthorized) allerdings überhaupt keine Fundstellen.

Es könnte natürlich damit zusammenhängen, dass die WP-Seite jetzt durch den Schutz außerhalb selbst nicht mehr in der Lage ist ggf. einen entsprechenden Zustand zu prüfen?

Ist das ggf. bekannt bei euch mit der Meldung und kann ich das ignorieren?

Danke schon einmal für Feedback.

Liebe Grüße Michael

[#11]

@tws_snoopy

Hallo Michael,

ich habe schnell bei meinem Kollegen nachgefragt, denn mir ist das nicht bekannt. Dem Kollegen aus der Fachabteilung aber aktuell auch nicht, was aber nicht heißt, dass die Aussage nicht stimmt. Er möchte das einmal näher prüfen, daher habe ich ein Ticket weitergeleitet. Sobald er mir eine Rückmeldung gibt, melde ich mich wieder hier.

Lieben Gruß Nadine H.

[#12 · Accepted solution]

@tws_snoopy

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.

[#13 · Accepted solution]

@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

[#14]

@tws_snoopy

Das klingt doch perfekt, ich danke dir für deine nette Rückmeldung. Das werde ich natürlich auch an meinen Kollegen weiterleiten.

Einen schönen Start in die Woche.
Lieben Gruß Nadine H.

[#15]

@Nadine H. 

Liebe Nadine, ich bin (leider) auf noch ein Problem gestoßen im Zusammenhang mit der "Vorprüfung" der wp-login.php.

Ich habe in WordPress die Möglichkeit eine einzelne Seite (ohne Plug-in!) mit einem Passwort-Schutz zu veröffentlichen. Ich habe heute eine erste Seite von meiner alten Seite in WordPress erstellt (bisher durch Euren PW-Schutz / Artikel ID=440 geschützt) und nach Erstellung mit PW-Schutz veröffentlicht.

Zunächst wird auch ganz normal nach dem vergebenen Passwort gefragt, aber danach wird leider auf die wp-login.php Seite verzweigt und nach dem Passwort für diese Datei gefragt (danach ist die Seite lesbar - es wird also NICHT das eigentlich WordPress PW erfragt!).

Um das genau zu verifizieren, habe ich mehrere Tests durchgeführt. Sobald ich die Vorprüfung für die wp-login.php aus der httpd.conf entferne, hochlade und aktiviere, läuft der Schutz korrekt ab. Es wird das vergebene PW für die Seite abgefragt und danach ist die Seite sichtbar. Wenn ich danach die httpd.conf mit dem Schutz der wp-login.php hochlade, kommt nach der PW-Eingabe für die WordPress-Seite wieder das Pop-up für die wp-login.php Vorprüfung.

Mir ist die Logik dahinter zwar nicht ganz klar, wieso das passiert, aber ich hoffe, dass Ihr auch für dieses Problem eine Lösung habt - das wäre wunderbar (dann müsste ich nicht extra ein Plug-in für diese (wenigen) Seiten installieren).

Ansonsten ein schönes Wochenende oder einen guten Start in die neue Woche.

Liebe Grüße aus Frankfurt mit viel Schnee von oben - der aber unten direkt zu Wasser wird

Michael

[#16]

Hallo @TW_snoopy,

das müssen wir uns etwas genauer anschauen. Sobald ich mehr herausgefunden haben, melde ich mich wieder.

Viele Grüße
Stephie G.

[#17 · Accepted solution]

@tws_snoopy

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.

[#18]

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

[#19]

@tws_snoopy

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.