Hallo,
die xmlrpc-Schnittstelle kannst du wie folgt abschalten, siehe auch folgenden Beitrag.
in der .htaccess:
# XML-RPC Schnittstelle komplett abschalten
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
Bei mir steht das bei einer Instanz oberhalb # BEGIN WordPress.
Viele Grüße
Hans-Gerd
Du solltest alle zusätzliches Regeln oberhalb des Blocks einfügen, der mit # BEGIN WordPress anfängt und mit # END WordPress endet. Ansonsten ist die Reihenfolge egal.
Bei der Gelegenheit kannst du deine Website gleich noch ein bisschen mehr absichern. Bernhard hat dazu gerade erst einen Blogbeitrag geschrieben:
Bessere Sicherheit für WordPress mit sicheren Server-Headern
Super. Vielen Dank für die Tipps!
Eine Frage noch zum Ordner in dem sich die .htaccess befindet. Die .htaccess gilt doch für alle Unterordner richtig?
Wenn der Aufbau der Ordnerstruktur bspw. wie folgt aussieht:
/seite
und in diesem Verzeichnis liegt ein Ordner /wordpress und weitere Ordner.
Muss die .htaccess dann unter /seite liegen oder im Verzeichnis /wordpress in dem auch die restlichen WordPress Dateien liegen? Oder ist beides möglich weil die .htaccess ja für alle Unterordner gilt?
Vielen Dank und viele Grüße Uli
Eine zusätzliche Sicherheitsmaßnahme ist, im Unterverzeichnis wp-content/uploads eine .htaccess mit
<Files *.php>
deny from all
</Files>
anzulegen und damit die Ausführung von PHP-Dateien unterbinden. Damit soll verhindert werden, dass als Bild-Datei (Endung .jpg) getarnte Skripte im Uploads-Verzeichnis (oder einem Unterverzeichnis von wp-content/uploads) umbenannt und dann der Code ausgeführt wird.
Ich nenne dieses Beispiel, weil es schön zeigt, dass eine .htaccess-Datei in Unterverzeichnisse vererbt wird, bis eine weitere .htaccess-Datei in Unterverzeichnissen Regeln hinzufügt oder überschreibt.
Grundsätzlich reicht bereits eine .htaccess-Datei im Web-Stammverzeichnis, in der WordPress die Weiterleitungsregeln für Pretty Permalinks ablegt. Alle zusätzlichen Regeln sind ergänzende Maßnahmen, um einen Angriff zu erschweren, aber WordPress ist ohne diese Maßnahmen grundsätzlich nicht unsicher.
Wenn man mal damit anfängt 🙂
Habe gleich noch ein Thema zur .htaccess. Habe mich in das Thema Ladegeschwindigkeit über das Browser Caching durch mod_expires.c in der .htaccess optimieren eingelesen.
Mit folgendem Tool habe ich die Ladegeschwindigkeit mehrfach getestet: https://tools.pingdom.com/
Als Grade „C“ kommt folgende Verbesserungsmöglichkeit: Add Expires headers
Das sollte ich doch durch folgenden Code beheben können oder?
#BEGINN BROWSER CACHING AKTIVIEREN
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css A31536000
ExpiresByType text/x-component A31536000
ExpiresByType application/x-javascript A31536000
ExpiresByType application/javascript A31536000
ExpiresByType text/javascript A31536000
ExpiresByType text/x-js A31536000
ExpiresByType text/html A3600
ExpiresByType text/richtext A3600
ExpiresByType image/svg+xml A3600
ExpiresByType text/plain A3600
ExpiresByType text/xsd A3600
ExpiresByType text/xsl A3600
ExpiresByType text/xml A3600
ExpiresByType image/bmp A31536000
ExpiresByType application/java A31536000
ExpiresByType application/msword A31536000
ExpiresByType application/vnd.ms-fontobject A31536000
ExpiresByType application/x-msdownload A31536000
ExpiresByType image/gif A31536000
ExpiresByType application/x-gzip A31536000
ExpiresByType image/x-icon A31536000
ExpiresByType image/jpeg A31536000
ExpiresByType application/json A31536000
ExpiresByType application/vnd.ms-access A31536000
ExpiresByType application/vnd.ms-project A31536000
ExpiresByType application/x-font-otf A31536000
ExpiresByType application/vnd.ms-opentype A31536000
ExpiresByType application/vnd.oasis.opendocument.database A31536000
ExpiresByType application/vnd.oasis.opendocument.chart A31536000
ExpiresByType application/vnd.oasis.opendocument.formula A31536000
ExpiresByType application/vnd.oasis.opendocument.graphics A31536000
ExpiresByType application/vnd.oasis.opendocument.presentation A31536000
ExpiresByType application/vnd.oasis.opendocument.spreadsheet A31536000
ExpiresByType application/vnd.oasis.opendocument.text A31536000
ExpiresByType application/pdf A31536000
ExpiresByType image/png A31536000
ExpiresByType application/vnd.ms-powerpoint A31536000
ExpiresByType image/svg+xml A31536000
ExpiresByType application/x-shockwave-flash A31536000
ExpiresByType application/x-tar A31536000
ExpiresByType image/tiff A31536000
ExpiresByType application/x-font-ttf A31536000
ExpiresByType application/vnd.ms-opentype A31536000
ExpiresByType application/vnd.ms-write A31536000
ExpiresByType application/font-woff A31536000
ExpiresByType application/vnd.ms-excel A31536000
ExpiresByType application/zip A31536000
</IfModule>
#END BROWSER CACHING AKTIVIEREN
Dooferweise kommt trotzdem die gleiche Meldung bei wiederholtem Test. Da ich keine Videos und Audiodateien auf meiner Seite verwende habe ich hierzu auch nichts gesetzt. Das dürfte aber nicht das Problem sein oder?
Vielen Dank schon Mal fürs Lesen und viele Grüße
Uli
Hallo,
sorry, aber das ist hier ein Support-Forum zu WordPress und Einstellungen in der .htaccess ist ein anderes Thema, worüber man sicher ohne Ende diskutieren könnte. Aber das würde an dieser Stelle definitiv zu weit führen.
Wenn es um Performance geht, schau dir z. B. mal die folgende Anleitung an, die einige Tipps hinsichtlich Performance bietet.
Viele Grüße
Hans-Gerd
Hallo Hans-Gerd,
ok, kein Problem. Trotzdem vielen Dank für den Link.
Schönes Wochenende.
Viele Grüße Uli
