Serverseitiger Schutz – WordPress absichern Teil5

1. WordPress härtenServerseitiger-Schutz

Im letzten Artikel der Serie »WordPress absichern« habe ich euch Code-Snippets für Apache, nginx und Lighttpd vorgestellt, mit denen ihr das WordPress-Backend abschotten könnt. Durch den Zugriffsschutz haltet ihr euch bereits auf Serverebene ungebetene Gäste vom Hals und schont ganz nebenbei die Ressourcen eures Webservers – denn jeder Aufruf bedeutet Arbeit für den PHP-Interpreter und die Datenbank.

Im Allgemeinen sind .htaccess Dateien weitläufig unterschätzt – sie bieten weitaus mehr Potenzial, als den Zugriffsschutz mit Usernamen und Passwort. Mit entsprechenden Code-Ergänzungen lässt sich eine WordPress-Installation »härten«. Damit ist gemeint: WordPress für eine bestimmte Aufgabe maßzuschneidern und abzusichern, um damit die Angriffsfläche zu minimieren.

Mit weiteren Code-Snippets für Apache und nginx möchte ich die Artikelserie fortsetzen.

Dieser Beitrag ist Teil einer Artikelserie:

Update

März 2016: Die Artikelserie wurde das letzte Mal im März 2016 aktualisiert.

2. WordPress Struktur

WordPress besteht aus folgender Dateistruktur:

  • /: Das sogenannte Root-Verzeichnis. Die Wurzel der WordPress-Installation bzw. das höchste Verzeichnis der Domain bzw. Subdomain. Hier liegen beispielsweise die robots.txt, wp-config.php oder wp-login.php. Von hier aus verzweigt sich die Struktur in weitere Ordner.
  • /wp-admin/: Beinhaltet das Front-End für Administratoren und Autoren. Sozusagen die Schaltzentrale von WordPress.
  • /wp-content/: Dort liegen alle Themes, Plugins, Bilder und hochgeladene Dateien.
  • /wp-includes/: Die Logik von WordPress. Dieser Unterordner beinhaltet alle PHP-Funktionen, welche für die Ausführung von WordPress notwendig sind.

WordPress Struktur
Einige dieser Dateien und Ordner sind besonders schützenswert. Nicht jeder muss darauf zugreifen können – streng genommen sollte ein Besucher lediglich Seiten aufrufen können, welche ihm über die Links auf der Webseite angeboten werden. Die Realität sieht leider anders aus …

2.1 Beispiel wp-config.php

In der wp-config.php (direkt im Root-Verzeichnis der WordPress-Installation) speichert WordPress sensible Informationen zur Datenbank und eurer Installation. Auf diese Datei sollte niemand direkt über den Browser Zugriff haben. Im Normalfall sollte dies auch nicht passieren, da ein sorgfältig konfigurierter PHP-Interpreter den Quelltext einer PHP-Datei nicht ausgibt, sondern serverseitig interpretiert bzw. bearbeitet. Zwei Szenarien belegen das Gegenteil:

  • Ein schwerwiegender Bug setzt bei Plesk die Konfiguration von Subdomains auf Default-Werte zurück. Dadurch wird der PHP-Interpreter deaktiviert und der Inhalt des Unterordners ~/httpdocs/ direkt ausgegeben – das erlaubt die Ausgabe der wp-config.php (beinhaltet unter anderem das Passwort für den Datenbankzugriff) und weiteren PHP-Dateien direkt im Browser. Ein unscheinbarer Bug mit weitreichenden Folgen.
  • Durch eine Sicherheitslücke im PHP-CGI Interpreter (PHP-CGI query string parameter vulnerability) kann der Inhalt von PHP-Dateien ausgelesen werden. Ein Angreifer muss dazu lediglich die Zeichenkette »?-s« an die URL anhängen, um den Quelltext der PHP-Datei geliefert zu bekommen.

Das Resultat beider Szenarien:

  • Über den Aufruf der Datei »www.domain.de/wp-config.php« lassen sich bspw. Username und Passwort der Datenbankanbindung auslesen. Insbesondere durch Konfigurationsfehler oder Sicherheitslücken enstehen dadurch immer wieder Situationen, die Angreifer gerne missbrauchen.

Entsprechende Code-Snippets für Apache und nginx können den direkten Zugriff auf schützenswerte PHP-Dateien verhindern. Des Weiteren bieten sie gegen weitere Szenarien einen wirkungsvollen Schutz, sorgen für eine Entlastung der Webserver Ressourcen und reduzieren mögliche Angriffsvektoren. Ein Potenzial das von vielen WordPress- bzw. Webseiten-Betreiber unterschätzt wird – zugunsten der Bots und ungebetenen Gästen.

3. Vorsicht vor den Modifikationen

Anpassungen bzw. Modifikationen an .htaccess Dateien bzw. Server Konfigurationen sind nicht jedermanns Sache. Die folgenden Code-Snippets können unter anderem ein Fehlverhalten von WordPress hervorrufen oder im schlimmsten Fall zu einem Ausfall führen. Sie sind daher mit Bedacht durchzuführen!

Doch keine Angst: Falls mal ein Fehler auftritt genügt es das eingefügten Code-Snippet wieder zu entfernen. Wer sich die Modifikation selbst nicht zutraut kann mich gerne kontaktieren.

4. Directory Browsing unterbinden

Standardmäßig sollte das Directory Browsing aus Sicherheitsgründen ausgeschaltet sein. Es ermöglicht die automatische Ausgabe eines Inhaltsverzeichnisses von Dateien und Ordnern auf dem Webspace. Da WordPress weit verbreitet ist kennen viele die Dateistruktur und verschaffen sich durch Aufrufe wie »www.domain.de/wp-content/plugins« einen Einblick in die verwendeten Plugins – Directory Browsing gilt es daher zu deaktivieren.

4.1 Apache

# Prevent Directory Listings
Options -Indexes

Die Modifikation ist in der .htaccess Datei im Root-Verzeichnis von WordPress durchzuführen.

4.2 nginx

# Prevent Directory Listings
autoindex off;

5. Schutz sensibler Dateien / Informationen

Das Beispiel der »wp-config.php« unter Ziffer 2.1 zeigt deutlich, dass gewisse Dateien einer WordPress-Installation besonders geschützt werden sollten – dazu gehören sensible Informationen und versteckte Systemdateien.

Eine Sonderstellung nimmt die Datei xmlrpc.php ein. Seit WordPress 3.5 ist die XML-RPC-Schnittstelle standardmäßig aktiviert und kann nicht mehr über eine Option im WordPress-Backend deaktiviert werden. Sie wird immer wieder für eine Reihe von DDoS-Angriffen genutzt, um die WordPress-Installation mit möglichst vielen Anfragen in die Knie zu zwingen. Das Resultat ist eine nicht erreichbare Webseite.

Update

04.03.2016:Über die XML-RPC-Schnittstelle können sich Angreifer mit vertretbarem Aufwand Zugriff auf das WordPress-Backend verschaffen. Im neuen Artikel »WordPress: Angriffe auf die XMLRPC-Schnittstelle (xmlrpc.php) unterbinden« wird das Problem ausführlich dargestellt.

Nachteil der Sperrung: Trackbacks von anderen WordPress-Blogs können nicht mehr empfangen werden – ein Feature was eigentlich zur Vernetzung von Blogs dient. Des Weiteren ist es nicht mehr möglich WordPress über externe Tools, wie WordPress for iOS oder WordPress for Android zu verwalten. Einige dieser Tools können allerdings mit einem Passwortschutz umgehen. Wenn ihr euren Blog also weiterhin über externe Tools verwaltet möchtet, solltet ihr das Code-Snippet »Apache mit Zugriffsschutz für xmlrpc.php« nehmen.

Im Detail sperrt das Code-Snippet folgende Zugriffe:

  • Zugriffe auf versteckte Systemdateien (.htaccess oder .htpasswd)
  • Zugriff auf die wp-config.php
  • [Optional] Zugriff auf die xmlrpc.php
  • Zugriff auf jegliche Text-Dateien, außer der robots.txt
  • Zugriff auf Dateien mit dem Namen liesmich.* oder readme.*

5.1 Apache inklusive xmlrpc.php Schutz

# Bis einschließlich Apache 2.3
# Disallow access to important files
<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php|(?<!robots)\.txt|(liesmich|readme)\.*)"> 
   Order deny,allow 
   Deny from all 
</FilesMatch>

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

Die Modifikation ist in der .htaccess Datei im Root-Verzeichnis von WordPress durchzuführen.

5.2 Apache mit Zugriffsschutz für xmlrpc.php

# Bis einschließlich Apache 2.3
# Disallow access to important files
<FilesMatch "(^\.|wp-config\.php|(?<!robots)\.txt|(liesmich|readme)\.*)"> 
   Order deny,allow 
   Deny from all 
</FilesMatch>
# Auth protection xmlrpc.php 
<Files xmlrpc.php> 
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /pfad/zur/.htpasswd
   Require valid-user 
</Files>

# Ab Apache 2.4
# Disallow access to important files
<FilesMatch "(^\.|wp-config\.php|(?<!robots)\.txt|(liesmich|readme)\.*)"> 
   Require all denied 
</FilesMatch>
# Auth protection xmlrpc.php 
<Files xmlrpc.php> 
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /pfad/zur/.htpasswd
   Require valid-user 
</Files>

Die Modifikation ist in der .htaccess Datei im Root-Verzeichnis von WordPress durchzuführen.

WordPress auf Schwachstellen und Konfigurationsfehler prüfen

Für Deine WordPress-Installation habe ich ein spezielles Leistungspaket im Angebot:
  • Scan Deiner WordPress-Installation auf Schwachstellen
  • Auswertung und Beurteilung der gefundenen Schwachstellen
  • Auf Basis der Ergebnisse erhälst Du von mir individuelle Maßnahmenempfehlungen zur Behebung und Absicherung

Wenn du Deine WordPress-Installation nachhaltig absichern möchtest, kannst Du mich gerne kontaktieren.

Gut zu wissen: Sicherheit erlangst Du nicht durch die Installation unzähliger Security-Plugins, sondern durch eine saubere Konfiguration, stetige Updates und proaktive Maßnahmen zur Absicherung. Kontakt aufnehmen

5.3 nginx inklusive xmlrpc.php Schutz

# Disallow access to important files            
location ~* (/\.|wp-config\.php|xmlrpc\.php|(?<!robots)\.txt|(liesmich|readme).*) {
   return 444;
}

5.4 nginx mit Zugriffsschutz für xmlrpc.php

# Disallow access to important files            
location ~* (/\.|wp-config\.php|(?<!robots)\.txt|(liesmich|readme).*) {
   return 444;
}

# Auth protection xmlrpc.php 
location = /xmlrpc.php { 
   auth_basic "Restricted Admin-Area"; 
   auth_basic_user_file /etc/nginx/htpasswd; 

   include /etc/nginx/conf.d/fastcgi.conf; 
}

6. Admin Zugang auf IP-Adresse beschränken

Im Beitrag .htaccess Schutz – WordPress absichern Teil4 habe ich euch vorgestellt, wie der Admin-Bereich von WordPress mit einem Zugriffsschutz abgesichert werden kann. Durch die Limitierung auf eine IP-Adresse wird der Zugangsbereich zusätzlich geschützt – Zugriff erhalten dann lediglich autorisierte IP-Adressen. Problematisch wird es bei ständig wechselnden IP-Adressen, aber auch hierfür gibt es eine Lösung. Apache kann IP-Adressen über ihren Domain Namen auflösen.

Einfaches Beispiel:
Mit dem pingdig oder host Befehl könnt ihr die IP-Adresse zum jeweiligen Domain Namen herausfinden. Ein ping auf web.de:
Ping
Die Domain web.de löst also auf die IP-Adresse 212.227.222.8 auf. Eine Anfrage auf einen Domain Namen funktioniert damit ähnlich einer Telefonauskunft.

Mittels Dynamic DNS lässt sich das Problem der ständig wechselnden IP-Adresse lösen. Dadurch wird der Rechner immer über den selben Domainnamen erreichbar bzw. Apache führt ein DNS Lookup durch und erhält die dazugehörige IP-Adresse. Über eine FRITZ!Box könnt ihr euch recht fix ein Dynamic DNS Eintrag einrichten. Dazu hatte ich einen Artikel (Fritzbox 6360 Dynamic DNS mit Two DNS als Anbieter) verfasst, der sich im speziellen mit dem Anbieter TwoDNS befasst.

6.1 Apache

# Bis einschließlich Apache 2.3
# Protect wp-login.php
<Files wp-login.php>
   Order deny,allow
   Deny from all
   Allow from [DYNAMIC.DNS.NAME]
</Files>

# Ab Apache 2.4
# Protect wp-login.php
<Files wp-login.php>
   Require host example.org
</Files>

[DYNAMIC.DNS.NAME] dient als Platzhalter für den Domain Namen, den ihr beim Dynamic DNS Anbieter registriert habt. Die Modifikation ist in der .htaccess Datei im Root-Verzeichnis von WordPress durchzuführen.

Ihr könnt das Code-Snippet auch mit dem Zugriffsschutz kombinieren:

# Bis einschließlich Apache 2.3
# Protect wp-login.php
<Files wp-login.php>
   Order deny,allow
   Deny from all
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /pfad/zur/.htpasswd
   Require valid-user 
   Allow from [DYNAMIC.DNS.NAME] 
</Files>

# Ab Apache 2.4
# Protect wp-login.php
<Files wp-login.php> 
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /pfad/zur/.htpasswd
   Require valid-user 
   Require host example.org
</Files>

 6.2 nginx

# Protect wp-login.php
location = /wp-login.php {
   auth_basic "Restricted Admin-Area";
   auth_basic_user_file /etc/nginx/htpasswd;

   allow [IP-ADDRESS]; 
   deny all;

   include /etc/nginx/conf.d/fastcgi.conf;
}

Im Gegensatz zu Apache erlaubt nginx noch keine Auflösung des Domain Namens in eine IP-Adresse. Der Platzhalter [IP-ADDRESS] muss dementsprechend mit einer IP-Adresse gefüllt werden. Bei einer ständig wechselnden IP-Adresse kann man sich über ein IP-Update Skript behelfen. Hier eine »quick & dirty« bash Skript Lösung:

#!/bin/bash

# Simple shell script to convert domain name to IP for nginx. 
# IP is stored in a config file.
# Include it in your nginx config: include /etc/nginx/allow_list.conf;

DOMAIN=your-dyndns-domain.de
IP=$(host $DOMAIN | awk '{print $4}')
OUTPUT_FILE=/etc/nginx/allow_list.conf

echo -e "allow $IP; \ndeny all;" > $OUTPUT_FILE

7. Direkte Ausführung von PHP-Dateien unterbinden

Oftmals ist der Uploads Ordner unter »/wp-content/uploads« ein beliebtes Einfallstor für Angreifer, da dieser in den meisten Fällen beschreibbar sein muss. Mit cleveren Tricks oder unter Ausnutzung von Sicherheitslücken (bspw. WordPress Asset-Manager PHP File Upload Vulnerability, WordPress File Uploader Plugin PHP File Upload Vulnerability) werden PHP-Dateien in Verzeichnisse geladen und dort dann ausgeführt. Eine direkte Ausführung von PHP-Dateien in den Unterordnern »/wp-content« oder »/wp-includes« kann dieses Angriffsszenario begünstigen und sollte daher mit Code-Snippets vermieden werden.

Vorsichtig: Je nach Theme, verwendete Plugins oder selbstgeschriebene Erweiterungen können die Code-Snippets bestimmte Funktionen stören. Im Zweifelsfall sollte zumindest die PHP-Ausführung im Unterordner »/wp-content/uploads« deaktiviert werden.

7.1 Apache

# Bis einschließlich Apache 2.3
# Disable direct access of any *.php files in /wp_content folder
<FilesMatch \.php$>
   Order deny,allow
   Deny from all
</FilesMatch>

# Ab Apache 2.4
# Disable direct access of any *.php files in /wp_content folder
<FilesMatch \.php$>
   Require all denied
</FilesMatch>

Die Modifikation ist in der .htaccess Datei im »/wp-content« von WordPress durchzuführen.

# Bis einschließlich Apache 2.3
# Disable direct access of any *.php files in /wp_includes folder
<FilesMatch (?<!wp-tinymce)\.php$>
   Order deny,allow
   Deny from all
</FilesMatch>

# Ab Apache 2.4
# Disable direct access of any *.php files in /wp_includes folder
<FilesMatch (?<!wp-tinymce)\.php$>
   Require all denied
</FilesMatch>

Die Modifikation ist in der .htaccess Datei im »/wp-includes« von WordPress durchzuführen.

Falls die Anpassung aufgrund von Plugins oder Modifikationen nicht funktioniert, dann legt zumindest in »/wp-content/uploads« eine .htaccess Datei mit folgendem Inhalt an:

# Bis einschließlich Apache 2.3
# Disable direct access of any *.php files in /wp_content/uploads folder
<FilesMatch \.php$>
   Order deny,allow
   Deny from all
</FilesMatch>

# Ab Apache 2.4
# Disable direct access of any *.php files in /wp_content/uploads folder
<FilesMatch \.php$>
   Require all denied
</FilesMatch>

Der Kuketz-Blog ist spendenfinanziert!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

7.2 nginx

# Disable direct access of any *.php files in /wp_includes folder
location ~ ^/wp-includes/.+\.php$ {
   return 444;
}

# Disable direct access of any *.php in /wp_content folder
location ~ ^/wp-content/.+\.php$ {
   return 444;
}

Ausführung von PHP-Dateien lediglich im Unterordner »/wp-content/uploads« deaktivieren:

# Disable direct access of any *.php in /wp_content/uploads folder
location ~ ^/wp-content/uploads/.+\.php$ {
   return 444;
}

8. Fazit

Wer die vorgestellten Code-Snippets in seine WordPress-Installation integriert gewinnt ein weiteres Stück Sicherheit. Diverse Angriffsszenarien können dadurch wirkungsvoll verhindert werden – ein Potenzial, das gerade auf beliebten Blogs nicht unterschätzt werden sollte. Alle Code-Snippets zur Absicherung habe ich nicht vorgestellt – da ist noch etwas Luft nach oben.

Was viele WordPress-Betreiber beschäftigt sind Bots und deren Spam-Verhalten. Im kommenden Artikel werde ich euch zeigen was ihr effektiv gegen Spam-Schleudern und ständig unerwünschte Gäste unternehmen könnt.

Bildquellen:

Link icon: „#53154108“, https://de.fotolia.com/id/53154108

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

14 Ergänzungen zu “Serverseitiger Schutz – WordPress absichern Teil5”

  1. Comment Avatar Beate sagt:

    Wenn man den Admin-Bereich mit der .htaccess schützt, kann man dann die Seiten noch mit einem Tool wie infinitewp.com pflegen?

    • Comment Avatar Mike Kuketz sagt:

      Hallo Beate,

      sollte möglich sein – einfach mal ausprobieren. Viele Tools / Lösungen bieten Unterstützung für eine Username/Passwortabfrage.

  2. Comment Avatar Steffen Werner sagt:

    Hallo Mike!

    Vielen Dank für die guten Hinweise.

    Der Schutz wichtiger Dateien funktioniert bei mir leider mit dem o.g. Beispiel nicht. Ich erhalte einen Serverfehler 500 (Apache Server).

    Folgender Code ging bei mir:

    # Disallow access to important files

    order deny,allow
    deny from all

    Können die .htacces Dateien in den Ordnern /wp-content und /wp-includes auch schon eine Plugin-Installation stören?

    Aktuell habe ich gemerkt, dass ein .php Schutz in der /wp-content z.B. das Yoast WP SEO Plugin im Backend stört.

    Gruß

    Steffen

    • Comment Avatar Mike Kuketz sagt:

      Hallo Steffen,

      Error 500 ist ein „Internal Server Error“. Er kann durch folgende Dinge hervorgerufen werden:
      – Fehlkonfiguration des Webservers
      – Schreibfehler in der htaccess-Datei
      – Ein CGI-Skript funktioniert nicht richtig
      – usw.

      Kopiere das Code-Snippet direkt vom Blog. Damit sollte es funktionieren. Falls nicht ist es ein anderer Grund, der sich als „Ferndiagnose“ schwer feststellen lässt. ;)

  3. Comment Avatar Daniela sagt:

    Im Detail sperrt das Code-Snippet folgende Zugriffe:
    * Zugriff auf jegliche Text-Dateien

    Das beinhaltet auch die Datei robots.txt!

    Warum sollte der Zugriff auf jegliche Textdateien verhindert werden? Ich verstehe den Sinn nicht.

    • Comment Avatar Mike Kuketz sagt:

      Daniela vielen Dank! Das hatte übersehen. Hab die Snippets korrigiert. robots.txt sind jetzt nicht mehr ausgeschlossen. Ist mir leider beim schreiben gar nicht aufgefallen.

      Jetzt zu den Textdateien:
      Textdateien (zum Beispiel von Plugins) enthalten oftmals Versionsnummer. Eben nach diesen Textdateien crawlen Bots und suchen nach veralteten Plugins, die Sicherheitslücken aufweisen.

      Der Bot-Master bekommt dann eine Nachricht nach dem Muster: Auf Seite XY wurde das veraltete Plugin XZ gefunden – bitte angreifen.

      Daher macht es Sinn den Informationszugriff darauf zu blockieren.

  4. Comment Avatar Ulrich Eckardt sagt:

    Hi,

    danke für den Artikel. Wir setzen WP-Secure, so heisst das glaube ich ein, aber die Modifikation der .htaccess war mir so neu. Vielen Dank.

    Grüße

    Ulrich

  5. Comment Avatar Michael sagt:

    Hallo Mike,

    vielen Dank für diese äußerst informative Artikelserie zum Thema WP- Sicherheit. Hier kann man wirklich eine Menge lernen.Ich konnte schon einige der Empfehlungen umsetzen und werde mich auch noch weiterhin intensiv mit den Themen auseinandersetzen soweit dass meine Zeit als Hobby-Admin zulässt.
    Im Rahmen meiner Optimierungsmaßnahmen habe ich im Code-Snippet zur Unterbindung der Ausführung von php- Dateien einen kleinen Fehler entdeckt, der bei mir zu einem Server-Fehler geführt hat:

    FilesMatch … lässt sich nicht mit Files schließen sondern nur mit FilesMatch.

    Grüße Michael

  6. Comment Avatar ConnieM sagt:

    tja, wenn ich den wp-content-Ordner mit der o.g. .htaccess schütze, funktioniert der Editor nur noch im Text-Modus. Andere Plugins dann auch nicht

    Das kann es ja wohl nicht sein.

    • Comment Avatar Mike Kuketz sagt:

      Hallo Connie,

      ich habe nun die Datei wp-tinymce.php exkludiert. Diese liegt im Ordner »/wp-includes/js/tinymce« und verursacht das Problem. Du kannst das aktualisierte Code-Snippet nehmen.

      Mike

  7. Comment Avatar Voxs sagt:

    was ich mich schon lange frage – warum konstruiert WP seither diese typische Directories-Dateistruktur, deren Namen mit wp- beginnen etc.? Und versieht zudem CSS etc. zusätzlich mit Versionsnummern-Ergänzungen, sodass wir User dann an allen Enden und Ecken 1000 Tricks und/oder Plugins einsetzen müssen, um zu verschleiern was niemanden was angeht! Würde das o. Genannte entfallen, wären z.B. die Pfade doch auf den ersten Blick eher ununterscheidbar von anderen CMS. Liegt das etwa nur an der „proud to publish with WP“ – Kultur und Absicht unbenommen der Risiken immer weiter und weitreichend Werbung für die eigene Software machen zu wollen?

  8. Comment Avatar Stefan sagt:

    Hallo Mike
    Danke für diese tollen Tipps!
    Eine kleine Berichtigung hätte ich allerdings noch:
    Unter „5.2 Apache mit Zugriffsschutz für xmlrpc.php“ darfst du die xmlrpc.php nicht prinzipiell ausschließen, denn sonst funktioniert der Passwortschutz nicht, bzw. ist das Ziel dann ja wieder verboten ;)
    LG, Stefan

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.