Verfasste Forenbeiträge

Ansicht von 15 Antworten – 1 bis 15 (von insgesamt 15)
  • Thread-Starter viehrig

    (@viehrig)

    Man sollte bei einem manuellen Update natürlich vermeiden, die separate htaccess im wp-admin-Ordner zu löschen, in welcher man die Abfrage der htpasswd angelegt hat.

    Jo. *kopfschüttel* Hat sich also geklärt.

    Thread-Starter viehrig

    (@viehrig)

    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?

    Thread-Starter viehrig

    (@viehrig)

    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.

    Thread-Starter viehrig

    (@viehrig)

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

    Standard für das WP-Verzeichnis:

    Für WP-Ordner: 755
    Für darin befindliche Dateien: 644

    • Diese Antwort wurde geändert vor 7 Jahren, 8 Monaten von viehrig.
    Thread-Starter viehrig

    (@viehrig)

    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, 8 Monaten von viehrig.
    • Diese Antwort wurde geändert vor 7 Jahren, 8 Monaten von viehrig.
    Thread-Starter viehrig

    (@viehrig)

    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)

    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, 8 Monaten von viehrig.
    • Diese Antwort wurde geändert vor 7 Jahren, 8 Monaten von viehrig.
    • Diese Antwort wurde geändert vor 7 Jahren, 8 Monaten von viehrig.
    Thread-Starter viehrig

    (@viehrig)

    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.

    kuketz-blog.de – WordPress: Angriffe auf die XMLRPC-Schnittstelle (xmlrpc.php) unterbinden

    Lesen und danach entscheiden, ob Pingbacks wirklich gebraucht werden.

    Mit dem Google-Crawler hat das (fast) nichts zu tun.

    Der Aufruf eines Beitrages mit den Standardwerten, beispielsweise unter „domain.de/?p=5275“ (natürlich nur, wenn es den in meinem Beispiel genannten Beitrag 5275 auch gibt) sollte immer funktionieren, unabhängig davon, was bei den Permalinks eingestellt wurde. Wenn das nicht geht, ist gröberes zerschossen.

    Folgendes erscheint mir dann am sinnvollsten:

    1. Datenbank-Backup anfertigen und auf dem Heimrechner abspeichern.
    2. Beiträge exportieren, insbesondere die seit dem WP-Update verfaßten (Export-Funktion innerhalb vom Adminbereich von WP). Wenn das nicht geht, dann die HTML-Version der jeweiligen Beiträge manuell als Text-Dateien auf dem Heimrechner abspeichern.
    3. Ein Datenbank-Backup von vor dem WP-Update einpielen und schauen, ob bis dahin alles ok ist.
    4. Auf das Standard-Theme der damaligen WP-Version umstellen und schauen, ob das funktioniert.
    5. WP manuell über FTP-Programm aktualisieren und zwar über mehrere Zwischenversionen bis zur aktuellen. Bei jeder Zwischenversion schauen, ob alles geklappt hat.
    6. Anschließend die fehlenden Beiträge wiederherstellen.

    Sorry, aber das sieht nach viel Arbeit aus. Zu große Versionssprünge können einfach schiefgehen. Genau das scheint passiert zu sein, wenn WP erst vor zwei Monaten nach zwei Jahren Pause aktualisiert wurde.

    • Diese Antwort wurde geändert vor 7 Jahren, 8 Monaten von viehrig.

    Wenn man auf Trackbacks verzichten kann…

    Die xmlrpc.php ist das zweite große Einfallstor für Angriffe. Verzichten kann man auf die Datei nur in seltenen Fällen, aber für Zugriffe von außen sperren geht schon:

    # Disallow access to important files
    
    <FilesMatch "(^\.|wp-config\.*|wp-mail\.*|xmlrpc\.*|wp-signup\.php|(?<!robots)\.txt|(liesmich|readme)\.*|error_log\.*)">
       Require all denied
    </FilesMatch>

    Da sind jetzt noch ein paar andere Dateien mit dabei, die man für Zugriffe von außen verriegeln sollte. Das obige vor dem eventuellen WordPress-Teil in die htaccess einfügen, dann sollte Ruhe einkehren.

    PS: Bots lassen niemals ab, deshalb ist dieser Schutz ja erforderlich.

    • Diese Antwort wurde geändert vor 7 Jahren, 8 Monaten von viehrig.
    • Diese Antwort wurde geändert vor 7 Jahren, 8 Monaten von viehrig.

    Wenn die Permalinks auf Standard gesetzt werden und das so abgespeichert wird, funktioniert dann der Aufruf eines einzelnen Beitrags?

    Thread-Starter viehrig

    (@viehrig)

    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, 8 Monaten von viehrig.
    • Diese Antwort wurde geändert vor 7 Jahren, 8 Monaten von viehrig.

    Kann sein, daß ich mich irre. Aber meiner Meinung nach ist hier ein Logikfehler versteckt. WP kann zunächst nur in einem eigenen Verzeichnis bzw. in auf direktem Pfad tiefer oder höher gelegenen Verzeichnissen auf dem Server suchen, dieses ist im genannten Beispiel „test.domain2.de“. WP liegt dann wahrscheinlich noch höher, also „test.domain2.de/public_html“ oder dergleichen, genau dort wird WP aber kein WP-Verzeichnis „test.domain1.de“ finden.

    MMn. müßte man in das Backend von WP bei der Domain „test.domain2.de“ unter

    Einstellungen -> Allgemein

    beim Punkt WordPress-Adresse (URL)

    „test.domain2.de“

    eintragen,

    beim Punkt Website-Adresse (URL) dann

    „test.domain1.de“.

    Ob das funktioniert, wäre auszuprobieren, ich bezweifle das. Ich kann es aber mangels dafür verfügbarer Domains auch nicht selber testen. Des weiteren wäre zu bedenken, daß ein von außen aufgerufenes WP beispielsweise im Quelltext zumindest teilweise die tatsächlichen Speicherpfade mit auswirft. Wenn es also darum geht, dem Erfindungsreichtum deutscher Rechtsprechung zu entgehen und deshalb „test.domain2.de“ vor ihr zu verbergen und dessen Inhalte nur mit „test.domain1.de“ auszugeben, wird das mit WP wohl eher nicht (jedenfalls nicht ohne weiteres) funktionieren.

    Da finde ich es zielführender, vielleicht einen im fernen Ausland ansässigen Webhoster zu wählen, der anonymes Hosting mit whois-Protection und anonymen Bezahlungsmöglichkeiten anbietet. Ich kenne nur einen, der sich dabei auch moralisch integer verhält. Da ich aber nicht alle kenne, gibt es an dieser Stelle keine Empfehlung von mir, lediglich den Hinweis, daß ich einen solchen Service selber nutze.

    • Diese Antwort wurde geändert vor 7 Jahren, 8 Monaten von viehrig. Grund: Rechtschreibung
    • Diese Antwort wurde geändert vor 7 Jahren, 8 Monaten von viehrig. Grund: Rechtschreibung
Ansicht von 15 Antworten – 1 bis 15 (von insgesamt 15)