Ordnerstruktur in WP, mehrere index.php und htaccess

    • Gerade eben
    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

    Lade ein frisches WordPress Archiv herunter, dann kannst Du abgleichen, welche Dateien mit welchem Inhalt standardmässig wo sind.

    Ergänzung: Viele Trojaner verstecken sich u.a. auch in diesen standardmässig vorhandenen index.php Dateien, das erkennt man an der dann abweichenden Grösse der Datei und natürlich auch am Inhalt.

    Eine solche .htaccess wird von WordPress selbst nirgends genutzt, vom Updraft Plugin vermutlich für seine eigenen Ordner.

    4 Mal editiert, zuletzt von b3317133 (19. Juni 2020 um 13:44)

    Zitat von Autor33


    ist es normal, dass eine "index.php" und "htaccess" in Unterordnern wie dem von "UpdraftPlus" oder "Themes" oder in "wp-content" sind?

    ja

    Zitat von Autor33


    In der index steht
    <?php
    // Silence is golden.

    Verhindert, dass der WebServer eine Inhaltsangabe des verzeichnisses erzeugt sondern eine helle Seite anzeigt

    https://exmaple/wp-content/

    Zitat von Autor33

    In der htaccess
    deny from all


    [/QUOTE]

    ist veraltet und funktioniert nur bei alten Apache WebServern.

    damit soll verhindert werden, dass man PHP Scripte per URL aufrufen kann

    Beispiel Hacker legt sich beispiel.php in das Verzeischnis und ruft auf

    https://exmaple/wp-content/beispiel.php

    Mit offenen Augen träumen

    Alles klar, dank euch.

    Und ich dachte, "Silence is golden" ist eine Veräppelung vom Hacker, denn diese Dateien waren schon letzte Woche dort drin.

    Hätte aber auch ohne Hacking und bei einem ganz neuen WP mit diesen beiden Dateien in vielen Unterordnern nichts anzufangen gewusst und mich gewundert.
    Ich kannte die immer nur vom Hauptverzeichnis.

    "Lade ein frisches WordPress Archiv herunter, dann kannst Du abgleichen, welche Dateien mit welchem Inhalt standardmässig wo sind."

    Für das hacking braucht es das nicht mehr, aber ich habe es vor einigen Tagen mal probiert und das hätte wohl Ewigkeiten gedauert, ist dann irgendwann plötzlich stecken geblieben. Habe dann gegoogelt nach den Standardpfaden und so, aber immer nur Teile gefunden.

    "Ergänzung: Viele Trojaner verstecken sich u.a. auch in diesen standardmässig vorhandenen index.php Dateien, das erkennt man an der dann abweichenden Grösse der Datei und natürlich auch am Inhalt."

    Das war bei mir auch so. Offenbar ein Backdoor-Trojaner, der durch eine Sicherheitslücke eines Editors im Theme reinkam. Kleiner Trost ist, dass es zumindest nicht an etwas lag, was ich in der Hand und mich darum gekümmert habe (Plugins, Passwort ect.).

    Schon erschreckend, ich meine, wirklich erschreckend, wenn du dein Herzblut in nicht nur primär kommerzielle Sites und sehr viel Zeit legst und alles aus deiner Sicht Erdenkliche tust, um auch der Sicherheit genüge zu tun und dann passiert es trotzdem.

    Eine Erfahrung, die mich lehrt, zukünftig etwas für den Fall zu tun, dass eine Infizierung geschehen ist, also dass das sofort entdeckt wird. Denn wirklich sicher vermeiden kann man es nicht, auch bei aller guter Absicht und Bewusstheit nicht. Selbst dann, wenn ich mir demnächst gleich zwei Sicherheitsplugins zulege.
    Sogar UpdraftPlus und Duplicator sind schon Mal Risiken gewesen und sogar Sicherheitsplugins selbst! Was soll man da noch sagen...

    5 Mal editiert, zuletzt von Autor33 (19. Juni 2020 um 14:09)

    Zitat von Autor33


    In der htaccess
    deny from all

    Zitat von r23

    damit soll verhindert werden, dass man PHP Scripte per URL aufrufen kann

    Beispiel Hacker legt sich beispiel.php in das Verzeischnis und ruft auf

    [plain]https://exmaple/wp-content/beispiel.php[/plain]


    Hinweis am Rande für Mitleser: Wenn man diese [FONT=Courier New].htaccess[/FONT] direkt in den [FONT=Courier New]/wp-content/[/FONT] Ordner legt, wird der ganze Website danach sehr seltsam aussehen, da dadurch nicht nur PHP Scripte sondern jeglicher Inhalt aus dem Ordner selbst und aus allen Unterordnern, also z.B. hochgeladene Bilder und alle Styles und Scripts des Themes und der Plugins blockiert werden.

    Zitat von Autor33

    Selbst dann, wenn ich mir demnächst gleich zwei Sicherheitsplugins zulege.


    Hierzu am Rande bemerkt, auch für Mitleser: Ein gleichzeitiger Betrieb verschiedener Sicherheitsplugins ist in WordPress nicht sinnvoll und führt mit relativ hoher Wahrscheinlichkeit später zu den unterschiedlichsten Problemen.

    Einmal editiert, zuletzt von b3317133 (19. Juni 2020 um 14:43)

    Zitat von b3317133

    Hinweis am Rande für Mitleser: Wenn man diese [FONT=Courier New].htaccess[/FONT] direkt in den [FONT=Courier New]/wp-content/[/FONT] Ordner legt, wird der ganze Website danach sehr seltsam aussehen

    Wer mit so einem alten WebServer, auf dem diese .htaccess funktioniert - verwendet - ... hat es nicht anders verdient.

    Mit offenen Augen träumen

    Zitat von r23

    Wer mit so einem alten WebServer, auf dem diese .htaccess funktioniert - verwendet..


    Auch mit einer [FONT=Courier New].htaccess[/FONT] mit entspr. Blockieranweisungen für den allerneusten Webserver wird sich der gleiche Effekt ergeben.

    Soweit es mich betrifft, liegt die htaccess im Updraft-Ordner, nicht in wp-content und die index.php in den beiden anderen, siehe Eingangspost und die Beispiele.
    "Kopfschüttel".

    Das "Kopfschüttel" war auf die Schadenfreude von r23 bezogen, das war missverständlich, weil nach deinem post, sorry.

    Ansonsten, es geht um die beiden genannten Dateien und die beiden Ordner, nur nicht "jeder in jedem". Die Schreenshots machen es dann aber deutlich. Würde man mit der falsch plazierten htaccess in wp-content dann gar nichts sehen, wäre die Frage diesbezüglich nach "kann das o.k. sein" überflüssig gewesen, denn dann hätte ich einen offensichtlichen Murks am Frontend gehabt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden