1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

WP 4.7 Sicherheit config.php höhere Ebene und SEO

Dieses Thema im Forum "Konfiguration" wurde erstellt von Ria, 8. Januar 2017.

  1. Ria

    Ria Well-Known Member

    Registriert seit:
    24. September 2004
    Beiträge:
    408
    Zustimmungen:
    0
    Hallo WP-Fans,

    Sicherheit config.php höhere Ebene und SEO sind an sich 2 Dinge, die ich aber gerne mal im Zusammenhang verstehen würde.

    die wp-config.php sollte ja eine Ebene über dem Blog Root Verzeichnis liegen. Normal muss ich doch, wenn ich keinen "eigenen" Server habe, beim Hoster, mein WP ins root Verzeichnis (Stammordner)installieren oder in einen Unterordner.

    Wenn z.B. die URL meine Domain.com ist würde z.B. in einem Unterordner Wordpress sich die URL ändern in meine Domain.com/wordpress

    Mit einer entspr. .htaccess im Stammordner könnte die URL meine Domain.com jedoch so erhalten bleiben.

    FRAGEN 1.: wäre es dann richtig die config.php vom Unterordner in den höher gelegenen Stammordner zu verschieben?

    Oder ist das mit "eine Ebene über dem Blog Root Verzeichnis" anders gemeint?
    Bei einem normalen Hostingpaket habe ich ja über dem Stammordner keinen weiteren Ebenen Zugriff.

    Dann wäre die config.php ja immer noch im root-Stammverzeichnis?
    Andererseits wäre dies ja nicht mehr das Blog-root oder wie muss ich dies sehen und verstehen?

    Frage 2.: WP wird ja im root-Stammverzeichnis gesucht und gesehen wird nur z.B. die .htaccess:

    <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{HTTP_HOST} ^(www.)?example.com$
    RewriteCond %{REQUEST_URI} !^/my_subdir/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ /my_subdir/$1
    RewriteCond %{HTTP_HOST} ^(www.)?example.com$
    RewriteRule ^(/)?$ my_subdir/index.php [L]
    </IfModule>

    (Das ?example.com$ und das $ /my_subdir/$1 natürlich anpassen!)

    bzw. der Spider sieht die .htaccess doch nicht, oder? Hat das negative SEO Auswirkungen, weil die WP ja im Unterordner ist? Leider hab ich hier eine "Lücke".

    Würde da gerne meine "Denkblokade" zu 1. und 2. aufgelöst bekommen :) besten Dank im voraus!

    l.G. Ria

    PS. sorry, ich übernehme für die oben abgebildete .htaccess KEINE GARANTIE!
     
  2. helix

    helix Well-Known Member

    Registriert seit:
    28. Juli 2011
    Beiträge:
    1.808
    Zustimmungen:
    27
    Wo nimmst du denn das her?
    Oder: was verstehst du unter „Blog Root Verzeichnis“?

    Normalerweise liegt die wp-config.php in dem Ordner, „in dem WordPress liegt. Dort, wo du beim Download der aktuellen WP-Version die wp-config-sample.php vorfindest.
    Und sinnigerweise legst du dein WordPress nicht ins Root deines Hosting-Pakets (häufig public_html), sondern in einen Unterordner, auf den deine Domain routet.

    Aber was ist schon normal?
    Und wer schert sich schon um sinnvolles Vorgehen?

    Den Suchmaschinen ist das egal, in welchem Unterverzeichnis vom Hosting-Paket eine Seite liegt. Den Suchmaschinen ist nicht egal, wie tief runter von der Domain-Ebene aus die Pfade gehen. domain.tld/wordpress/die-ganze-seitenstruktur – wer braucht „wordpress“ im Pfad? (Die Suchmaschinen bestimmt nicht. Hacker auch nicht. Ganz normale menschliche Seitenbesucher? Vielleicht …)

    Gruß
    helix
     
  3. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.634
    Zustimmungen:
    1.778
    Alte Anleitungen zu PHP-/WordPress-Hardening bei "Shared Hosting" empfehlen wegen der beinhalteten Datenbank-Zugangsdaten das Auslagern von wp-config.php u.ä. aus dem "public_html" Ordner des Users, da dieser bzw. die Config-Datei von anderen Usern auf dem gleichen Server per PHP lesbar war.

    Diese Problematik dürfte aktuelle Server-Installationen nicht (mehr) betreffen, ggf. kann ein Hosting-Anbieter da noch Details ergänzen.
     
  4. danielgoehr

    danielgoehr Well-Known Member

    Registriert seit:
    13. Juli 2016
    Beiträge:
    2.674
    Zustimmungen:
    128
    Das habe ich tatsächlich auch noch nie gehört. Mir ist auch noch nicht ganz klar, inwiefern das sicherer sein soll.
    Es sei denn, man legt die wp-config in ein Verzeichnis, dass von aussen nicht erreichbar ist. Wobei mir nicht ganz klar ist, wie WordPress dann darauf zugreifen soll (oder geht das trotzdem?).

    Das wäre aber eh nur eine Lösung für einen eigenen Root-Server. Bei Shared Hosting hat man ja eigentlich nie Zugriff auf Verzeichnisse oberhalb des Webroot.

    Das höre ich auch zum ersten Mal und ich hoffe, dass das auch in der Vergangenheit nie so war. Das wäre ja die ultimative Sicherheitslücke!
     
  5. JABA-Hosting

    JABA-Hosting Well-Known Member

    Registriert seit:
    29. März 2016
    Beiträge:
    2.988
    Zustimmungen:
    198
    Das hätte auch früher nie passieren dürfen. Das wäre möglich, wenn der Hoster kein open_basedir setzt und das wäre sehr fatal.

    Der einzige - logische - Grund wäre, im Falle eines PHP Ausfalls/Server Konfigfehler das man nicht die wp-config.php als download angeboten bekommt.

    Ria möchte die wp-config.php außerhalb des Docroots setzen, sodass im Falle (siehe oben) da nichts passiert.

    @danielgoehr

    Ist bei shared Hosting auch kein Problem.
     
  6. danielgoehr

    danielgoehr Well-Known Member

    Registriert seit:
    13. Juli 2016
    Beiträge:
    2.674
    Zustimmungen:
    128
    Auf Verzeichnisse oberhalb des Web-Root zugreifen? Klar, technisch ist das kein Problem. Mir ist nur kein Anbieter bekannt der das erlauben würde...

    Oder meinst du die andere Variante? Also alles Domains nur auf Verzeichnisse unterhalb des Web-Root "legen"?
     
  7. JABA-Hosting

    JABA-Hosting Well-Known Member

    Registriert seit:
    29. März 2016
    Beiträge:
    2.988
    Zustimmungen:
    198
    Beispiel:

    / ist deine Standarf docroot

    Du änderst es in

    /wordpress/

    somit könntest du die wp-config.php in / legen und Wordpress in /wordpress/.

    Die Domain läuft trotzdem auf deinedomain.de und nicht deinedomain.de/wordpress da du deine docroot geändert hast.

    Die PHP scripte können weiterhin auf / zugreifen, wenn du dein open_basedit entsprechend einstellst. Ist bei uns so möglich.
     
  8. danielgoehr

    danielgoehr Well-Known Member

    Registriert seit:
    13. Juli 2016
    Beiträge:
    2.674
    Zustimmungen:
    128
    Ok, das wäre ja quasi die zweite Version in ausführlich beschrieben :)
     
  9. Ria

    Ria Well-Known Member

    Registriert seit:
    24. September 2004
    Beiträge:
    408
    Zustimmungen:
    0
    @ Jaba

    Richtig, Du hast mich verstanden und richtig was Du sagst, konfiguriert begrenzt die 'open_basedir'-Direktive z.B. den Zugriff auf das DocumentRoot der jeweiligen Domain. Wird normal im VHost gesetzt und an die php.ini komme ich ja normal auch nicht rann.

    'php_admin_value open_basedir /home/httpd/docs/meinedomain.com:/tmp'

    So, dazu hatte ich die Blokade:

    "/ ist deine Standar docroot

    Du änderst es in

    /wordpress/

    somit könntest du die wp-config.php in / legen und Wordpress in /wordpress/.

    Die Domain läuft trotzdem auf deinedomain.de und nicht deinedomain.de/wordpress da du deine docroot geändert hast."

    besten Dank!!!!!!!!!!!!!!!!

    Und ja sorry, die obige .htaccess brauche ich ja nur wenn ich eine fertige Installation in einen Unterordner verschiebe und das war ja hier von mir nicht geplant, bzw. nötig.

    Aber wo wir gerade dabei sind:

    Ich trage folgende Befehle in der .htaccess-Datei im Wurzelverzeichnis der WordPress-Installation ein, wo bei die .htaccess natürlich mit geschützt wird:

    Options All -Indexes
    <files readme.html>
    Order allow,deny
    Deny from all
    </files>
    <files .htaccess>
    order allow,deny
    deny from all
    </files>
    <files *.sql>
    order allow,deny
    deny from all
    </files>
    <files liesmich.html>
    Order allow,deny
    Deny from all
    </files>
    <files *.txt>
    Order allow,deny
    Deny from all
    </files>
    <files license.txt>
    Order allow,deny
    Deny from all
    </files>
    <files install.php>
    Order allow,deny
    Deny from all
    </files>
    <files wp-config.php>
    Order allow,deny
    Deny from all
    </files>
    <files wp-config-sample.php>
    Order allow,deny
    Deny from all
    </files>
    <files robots.txt>
    Order allow,deny
    Allow from all
    </files>

    Achtung: Der letzte Befehl erlaubt wiederrum den Zugriff auf die wichtige robots.txt.

    In eine separate .htaccess Datei, füge ich den folgenden Code hinein und lade die Datei in den wp-content Ordner hoch.

    Order deny,allow
    Deny from all
    <Files ~ ".(xml|css|jpe?g|png|gif|js)$">
    Allow from all
    </Files>

    Und sichere wp-admin durch einen zusätzliche Passwortabfrage mit der .htaccess Datei ab.

    Das ich die config.php entspr. bearbeite ist natürlich. Ich habe keinen "Verfolgungswahn" :)
    finde nur hier ist mehr einfach besser.

    l.G. Ria
     
  10. r23

    r23 Well-Known Member

    Registriert seit:
    9. Dezember 2006
    Beiträge:
    7.317
    Zustimmungen:
    582
    ^- funktioniert aber nur auf extrem alten Apache Server.

    und ein Datei *.sql verwendet WordPress auch nicht.
     
  11. danielgoehr

    danielgoehr Well-Known Member

    Registriert seit:
    13. Juli 2016
    Beiträge:
    2.674
    Zustimmungen:
    128
    Denk and das whitelisting der "wp-admin/admin-ajax.php". :)
     
  12. JABA-Hosting

    JABA-Hosting Well-Known Member

    Registriert seit:
    29. März 2016
    Beiträge:
    2.988
    Zustimmungen:
    198
    Warum? "10 Zeichen"
     
  13. danielgoehr

    danielgoehr Well-Known Member

    Registriert seit:
    13. Juli 2016
    Beiträge:
    2.674
    Zustimmungen:
    128
    Weil alle Ajax Requests in WordPress über die Datei "admin-ajax.php" laufen (nicht nur die, die den Admin-Bereich betreffen, sondern tatsächlich alle).
    In vielen Fällen kein Problem, ich hab aber selbst schon Seiten mit den eigenartigsten Fehlern gehabt, die am Ende genau daran lagen.

    https://www.wordfence.com/blog/2014/05/please-stop-password-protecting-your-wp-admin-folder-because-it-breaks-public-ajax-for-wordpress/

    Edit:
    Hier noch die offizielle Doku (da steht es auch nochmal drin, wenn auch nicht so explizit):
    https://codex.wordpress.org/Brute_Force_Attacks
     
    #13 danielgoehr, 8. Januar 2017
    Zuletzt bearbeitet: 8. Januar 2017
  14. Ria

    Ria Well-Known Member

    Registriert seit:
    24. September 2004
    Beiträge:
    408
    Zustimmungen:
    0
    @ danielgoehr

    Du meinst das?

    # Allow access to wp-admin/admin-ajax.php
    <Files admin-ajax.php>
    Order allow,deny
    Allow from all
    Satisfy any
    </Files>

    @ r23

    "funktioniert aber nur auf extrem alten Apache Server. "

    Wenn das stimmt, welche alternative hast Du im Ärmel?

    l.G. Ria
     
    #14 Ria, 9. Januar 2017
    Zuletzt bearbeitet: 9. Januar 2017
  15. danielgoehr

    danielgoehr Well-Known Member

    Registriert seit:
    13. Juli 2016
    Beiträge:
    2.674
    Zustimmungen:
    128
    Ja, genau :)
     
  16. Ria

    Ria Well-Known Member

    Registriert seit:
    24. September 2004
    Beiträge:
    408
    Zustimmungen:
    0
    Hallo danielgoehr ,

    danke für die Antwort! Kannst Du sagen was r23 meinte mit: "funktioniert aber nur auf extrem alten Apache Server. "
    Wenn das stimmt, eine alternative wird nicht genannt(?).

    Bin leider mit dem Server Gedöns auch kein Profi. Versuche nur das Sinnvollste zur Sicherheit zu finden.

    l.G. Ria
     
  17. JABA-Hosting

    JABA-Hosting Well-Known Member

    Registriert seit:
    29. März 2016
    Beiträge:
    2.988
    Zustimmungen:
    198
    r23 wollte dir nur sagen, dass

    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Für Apache 2.2 (alt) gültig ist.

    Für Apache 2.4 lautet der htaccess Teil dann ...

    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Aber bei vieles Hostern, egal ob neuere Apache Version, funktioniert noch Ordner Deny ...
     
  18. Ria

    Ria Well-Known Member

    Registriert seit:
    24. September 2004
    Beiträge:
    408
    Zustimmungen:
    0
    Hallo JABA-Hosting,

    "Require all denied" aha, danke Dir. Dann müsste ich quasi alles dahingehend ändern(?):

    <files wp-config.php>
    Require all denied
    </files>

    Also so?

    ich gebe zu, wenn man nur für sich eine Webseite macht dann ist die "Lernkurve" etwas höher und auch höher als ein Plugin.
    Habe aber die Vorstellung, dass nur ein Serverseitiges blockieren wirklich Sinn macht.
    Da das Plugin ja nicht von "Außen" sondern den Schutz von Innen angeht und oft ja nur die config Einstellungen macht, die man auch zu Fuß vornehmen könnte/kann.

    Keine Ahnung, ob ich das wirklich so richtig sehe, denke aber die Vorgehensweise kann ja nicht verkehrt sein.

    l.G. Ria

    PS. deswegen habe ich auch Linux-Mint anstelle Windows, vielleicht doch etwas "Verfolgungswahn" :)
     
  19. JABA-Hosting

    JABA-Hosting Well-Known Member

    Registriert seit:
    29. März 2016
    Beiträge:
    2.988
    Zustimmungen:
    198
    Ja, aber wie gesagt solange du keine Fehlermeldung erhälst, kannst du alles so belassen wie du es hast.

    Das ist schon bisschen zu viel Paranoia :) Die meisten Hacks kommen von Sicherheitslücken in WordPress/Themes oder Plugins. Das mal die wp-config.php ausgelesen wird, bisher nicht gehört.



    Verkehrt ist es nicht, wenn man damit klar kommt ist es auf alle Fälle ein tolles OS :)
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden