WordPress Hardening: die Regeln für .htaccess

Verfasst von

in

Das WordPress Hardening des Plugins CSDN steckt ganz in einem Reiter: „Hardening / IDS“. Es sind fünf Schalter und ein Textfeld. Sie schließen Türen, die fast keine Website wirklich benutzt. Alle sind ausgeschaltet, und du schaltest sie eine nach der anderen ein.

Schema von WordPress mit dem Reiter Hardening / IDS des Plugins CSDN: WordPress Hardening

Wo du das WordPress Hardening findest

Öffne Einstellungen > Cisilino Site Defense Network (Punkt 1 im Bild). Klicke dann auf den Reiter Hardening / IDS (Punkt 2). Im Reiter findest du drei Abschnitte, in dieser Reihenfolge:

  • Punkt 3: unter dem Titel „Hardening / Zugriffskontrolle (IDS)“ die Zeile „.htaccess-Regeln“.
  • Punkt 4: „WordPress“.
  • Punkt 5: „Eigene zu blockierende Pfade“.

Oben steht im Reiter: „Optionale Regeln, angewendet auf Serverebene (.htaccess) oder in WordPress. Alle standardmäßig ausgeschaltet: aktiviere sie nur, wenn du weißt, dass sie nicht mit Themes/Plugins der Website in Konflikt stehen.“ Unten gibt es nur eine Schaltfläche: „Hardening-Regeln speichern“.

Wozu es dient

Die Regeln verringern die Angriffsfläche. Drei Schalter schreiben in die Datei .htaccess, wie auch das Feld der eigenen Pfade. Zwei Schalter sind WordPress-Filter. Es ist keine Firewall und analysiert keine Anfragen: „IDS“ bedeutet hier Zugriffsregeln für Dateien und Ordner.

Die .htaccess-Regeln (Punkt 3)

PHP-Ausführung in wp-content/uploads blockieren

Die vollständige Beschriftung lautet „PHP-Ausführung in wp-content/uploads blockieren (Schutz vor als „Bild“ hochgeladenen Shells)“. Das Plugin antwortet mit 403 auf jede Anfrage einer Datei mit der Erweiterung php, php3, php4, php5, php7, php8, php9, phtml, phps, phar oder pht, deren Adresse /wp-content/uploads/ enthält. Groß- und Kleinschreibung spielt keine Rolle.

Funktioniert nur mit Apache 2.4 (braucht das Modul mod_authz_core: fehlt es, tut die Regel nichts und meldet das nicht). Auf nginx wird die Datei .htaccess ignoriert, und keine Regel dieses Reiters hat Wirkung, abgesehen von den WordPress-Filtern. Erfasst den Standardordner uploads, nicht einen eigenen Ordner. Kann Plugins zerstören, die wirklich PHP-Dateien aus diesem Ordner ausliefern. Um zu wissen, ob es auf deiner Website funktioniert, nutze den Test aus dem Kapitel Reiter Test.

Dateiauflistung in Verzeichnissen ohne Index deaktivieren

Schreibt eine einzige Zeile: Options -Indexes. Öffnest du einen Ordner ohne Index-Seite, siehst du einen 403-Fehler statt der Dateiliste. Nutzt du einen Ordner als öffentliche Download-Liste, verschwindet diese Liste.

Direkten Zugriff auf wp-config.php, .htaccess, readme.html, debug.log blockieren

Das Plugin schreibt für jeden Namen eine Regel und antwortet mit 403. Die Prüfung gilt dem Dateinamen, nicht dem Pfad. Sie gilt also für jede Datei mit diesem Namen in jedem Ordner der Website, auch innerhalb anderer Plugins. Ein Plugin, das eine eigene readme.html oder debug.log veröffentlicht, wird blockiert.

Die WordPress-Regeln (Punkt 4)

Diese zwei Regeln des WordPress Hardening sind PHP-Filter. Sie berühren .htaccess nicht.

XML-RPC deaktivieren

Die Beschriftung lautet „XML-RPC deaktivieren (Bruteforce/Pingback, auf modernen Websites fast nie nötig)“. Die Datei xmlrpc.php bleibt an ihrem Platz, aber WordPress lehnt die XML-RPC-Methoden ab, die einen Login erfordern. Achtung: Es stoppen die mobile WordPress-App, ein Teil der Jetpack-Funktionen und die Veröffentlichung über externe Clients. Die Methode pingback.ping braucht keinen Login, und der Filter stoppt sie nicht: Verlass dich bei Pingbacks nicht auf diese Regel. Trackbacks nutzen kein XML-RPC und werden nicht berührt. Die Verbindung des Plugins zum Panel nutzt kein XML-RPC und wird deshalb nicht berührt.

Benutzer-Enumeration über ?author=N blockieren

Enthält die Anfrage den Parameter author mit einem Wert (ungleich leer und 0), erscheint auf der öffentlichen Website „Nicht gefunden.“ mit Antwort 404. Achtung: Diese Regel schützt die REST API nicht. Die Benutzerliste unter /wp-json/wp/v2/users bleibt erreichbar. Manche Themes und Plugins nutzen ?author=, um Archive zu filtern, und werden blockiert.

Eigene zu blockierende Pfade (Punkt 5)

Das Textfeld ist für alle, die einen bestimmten Ordner schließen wollen, zum Beispiel /wp-content/uploads/altes-backup/. Schreib einen Pfad pro Zeile. Leere Zeilen werden ignoriert.

Jede Zeile ist wörtlicher Text. Groß- und Kleinschreibung zählt, und der Teil nach dem ? der Adresse wird nicht verglichen. Die Hilfe unter dem Feld spricht von „Mustern“, aber hier gibt es keine. Es gibt keine Platzhalter: *, ^ und $ gelten als einfache Zeichen. Das Plugin blockiert mit 403 jede Adresse, die diese Zeichenkette an beliebiger Stelle enthält. Deshalb blockiert der Pfad /wp-content/uploads/altes-backup/ auch /blog/wp-content/uploads/altes-backup/x.

Dieses Feld hat keinen Schalter. Die Regel ist aktiv, sobald das Feld nicht leer ist und du speicherst.

Achtung: Schreibst du / oder wp, blockierst du die ganze Website, einschließlich des Verwaltungsbereichs. Um zurückzukommen, müsstest du .htaccess per FTP korrigieren. Auch eine Zeichenkette wie /uploads/ blockiert alle Bilder. Vermeide das Zeichen % in Pfaden.

Standardwerte

Fünf ausgeschaltete Schalter und ein leeres Feld. Die Einstellungen stehen in der Option csdn_hardening.

Wie man es benutzt

Geh ruhig vor: Das WordPress Hardening macht man eine Regel nach der anderen.

  1. Erstelle eine Kopie von .htaccess, bevor du anfängst.
  2. Aktiviere nur eine Regel.
  3. Klicke auf „Hardening-Regeln speichern“.
  4. Prüfe, ob die Website sich öffnet und der Verwaltungsbereich funktioniert.
  5. Geh zur nächsten Regel über.

Nach dem Speichern wirst du zum Reiter Allgemein zurückgeführt, nicht zu dem, in dem du gespeichert hast. Oben findest du den Hinweis. Bei Erfolg steht „Hardening-Regeln gespeichert und angewendet.“. Bei einem Fehler steht „Einstellungen gespeichert, aber das Schreiben in .htaccess ist fehlgeschlagen (Dateirechte?). Die Regeln sind nicht aktiv.“. Bei diesem Fehler bleiben die zwei WordPress-Filter trotzdem aktiv.

Achtung: Das Plugin legt keine Sicherung von .htaccess an. Es prüft auch nicht die Syntax, bevor es schreibt. Eine mit deinem Server unverträgliche Regel kann einen 500-Fehler auf der ganzen Website verursachen. In einem Multisite-Netzwerk ist es die Datei des Netzwerks: Der Fehler trifft alle Websites.

Was im Hintergrund passiert

Das Plugin schreibt zwischen zwei Markierungen: # BEGIN Cisilino Site Defense Network - Hardening und das zugehörige # END. Der Rest der Datei bleibt unberührt. Ein zweiter, getrennter Block enthält die blockierten IPs. Deaktivierst du das Plugin, werden beide Blöcke geleert. Schaltest du alles aus und speicherst, bleibt der Hardening-Block leer.

Wenn etwas nicht funktioniert

Zeigt die Website nach dem WordPress Hardening einen 500-Fehler, öffne .htaccess per FTP. Lösch die Zeilen zwischen den beiden Hardening-Markierungen. Versuch es dann mit weniger Regeln erneut. Wird nicht in die Datei geschrieben, prüfe die Rechte von .htaccess.

Für einen umfassenderen Überblick über gute Praktiken lies die offizielle Anleitung zum Hardening von WordPress: Sie erklärt weitere Maßnahmen außerhalb des Plugins.

Vorheriges Kapitel: Reiter Blockierte IPs: die Blacklist lesen. Nächstes Kapitel: Überwachung der Uploads und Integritätsprüfung. Für das vollständige Verzeichnis geh zur Einführung des Handbuchs zurück.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

WordPress Cookie Hinweis von Real Cookie Banner