Wo du es findest

Öffne den Eintrag Plugins > Installierte Plugins (Punkt 1 im Bild). In der Zeile von Cisilino Site Defense Network (Punkt 3) findest du den Link Deaktivieren. Nach der Deaktivierung (Punkt 4) zeigt dieselbe Zeile Aktivieren und Löschen.

Was bei der Deaktivierung passiert

Das Deaktivieren stoppt das Plugin, ohne die Daten zu berühren. Bei der Deaktivierung tut das Plugin vier Dinge.

1. Es erfasst das Ereignis „Plugin auf dieser Website deaktiviert“ und versucht, es dem Panel zuzustellen, falls konfiguriert.
2. Es löscht die drei geplanten Aufgaben.
3. Es leert beide Blöcke von .htaccess, den der blockierten IPs und den des Hardening.
4. Es aktualisiert die Rewrite-Regeln von WordPress.

Achtung: Im deaktivierten Zustand bleibt keine Regel in Kraft. Die blockierten IPs können wieder zugreifen, und das Hardening wird nicht mehr angewendet. Das Plugin wird nicht einmal geladen, also wirken auch die anderen Schutzmaßnahmen nicht. Es enden auch die Sicherheitsheader, aber ein Browser, der HSTS schon erhalten hat, erinnert sich für die eingestellte Zeit.

Die Datenbank bleibt unberührt. Aktivierst du das Plugin erneut, werden die Blöcke von .htaccess wiederaufgebaut, und du findest die Einstellungen, wie du sie verlassen hast.

Plugin deinstallieren, Schritt für Schritt

Um das Plugin zu deinstallieren, musst du auf Löschen unter Installierte Plugins klicken, nachdem du es deaktiviert hast. Bevor du das tust, folge diesen Schritten.

1. Prüf im Reiter Aktivitätsprotokoll, ob die Zeile „wartend auf Versand an das Panel“ bei null steht, falls du das Panel nutzt.
2. Lad im Reiter Debug-Log die Dateien herunter, die du brauchst. Klick dann, wenn du willst, auf Alle Dateien löschen.
3. Erstell eine Sicherungskopie, falls du das nicht schon getan hast.
4. Deaktivier das Plugin und klick auf Löschen.

Was entfernt wird und was bleibt

Entscheidest du dich, das Plugin zu deinstallieren, erfasst es zuerst „Plugin von dieser Website deinstalliert: lokale Daten entfernt“ und versucht, es dem Panel zuzustellen. Dann löscht es, unabhängig vom Ausgang der Zustellung.

Entfernt wird Folgendes.

• die vier Tabellen csdn_events, csdn_overrides, csdn_rate_hits und csdn_activity.
• fast alle Optionen, deren Name mit csdn_ beginnt, einschließlich der Panel-Zugangsdaten, der Whitelist und der Einstellungen der Reiter. Drei bleiben, weiter unten aufgelistet.
• der Sperrstatus des Rate Limiting bei allen Benutzern.
• die temporären Daten des Plugins.
• die Regeln der zwei Plugin-Blöcke in .htaccess und die Rewrite-Regeln. Die Markierungen # BEGIN und # END bleiben leer in der Datei.

Es bleibt dagegen Folgendes.

• die Dateien des Debug-Logs im Ordner csdn-debug-* innerhalb von uploads, weil es deine eigenen Daten sind: Lösch sie von Hand oder mit der Schaltfläche Alle Dateien löschen, bevor du deinstallierst.
• die schon an das Panel zugestellte Historie, die auf dem Panel liegt und nicht auf deiner Website.
• die Zeilen von .htaccess, die außerhalb der Plugin-Markierungen stehen.
• drei kleine Optionen: csdn_registration_lock (die Richtlinie der Benutzerregistrierung), csdn_remote_ban_reasons (Gründe empfangener Sperren) und csdn_trigger_token (vom Panel empfangenes Token). Es bleiben auch das Benutzerdatum csdn_registration_blocked_at, falls vorhanden, und die temporären Daten csdn_rl_block_*, die von selbst ablaufen. Du kannst sie von Hand aus der Datenbank entfernen.

Achtung: Das Plugin deinstallieren löscht auch das lokale Aktivitätsprotokoll. Noch nicht an das Panel zugestellte Zeilen gehen verloren, falls das Panel nicht antwortet.

Vom Plugin verarbeitete personenbezogene Daten

Das Plugin hält die Daten auf deiner Website, in der Datenbank. Nie das Passwort. Hier siehst du, was es verarbeitet.

• Fehlgeschlagene Logins: IP-Adresse, versuchter Benutzername, Anzahl der Versuche, erstes und letztes Vorkommen, Sperrstatus. Es gibt keine automatische Löschung: Sie bleiben in der Datenbank, bis du das Plugin deinstallierst.
• Aktivitätsprotokoll: Datum und Uhrzeit, WordPress-Benutzer (ID, Login, Rolle), IP, Art der Aktion, betroffenes Objekt (bei Inhalten der Titel) und eine kurze Beschreibung. In manchen Fällen kommen Details hinzu: bei einem neuen Benutzer die E-Mail und die Rollen, bei einer Profiländerung der vorherige und der neue Wert von E-Mail, Login, Anzeigename und Website. Es speichert nicht den Inhalt von Beiträgen, Kommentaren oder Dateien. Bei Optionen mit verdächtigem Namen, wie Schlüsseln oder Tokens, erfasst es nur, dass sie geändert wurden.
• Rate Limiting: IP und Art der Einsendung der Gäste, einen Tag lang aufbewahrt. Die Sperrungen der Autoren liegen in den Benutzerdaten.
• IP-Overrides, Whitelist und empfangene Blacklist.
• Debug-Log, wenn du es einschaltest: Dateien, die Pfade und Datenfragmente enthalten können.

Das lokale Protokoll hält standardmäßig 30 Tage und höchstens 500 Zeilen. Du kannst beide Werte im Reiter Aktivitätsprotokoll ändern.

Was die Website verlässt

Nur wenn du das Panel verbindest. Alle 15 Minuten sendet das Plugin die fehlgeschlagenen Logins: IP, Benutzername, Ergebnis „failed“ und Datum. Es sendet bis zu 200 pro Mal. Es fügt den Customer Code und die URL der Website hinzu. Es empfängt die blockierten IPs. Das Aktivitätsprotokoll, mit den oben genannten Details, wird normalerweise sofort am Ende der Anfrage gesendet, und was in der Warteschlange bleibt, geht mit dem 15-Minuten-Durchlauf. Es startet nur, wenn sowohl das Protokoll als auch die Option „Aktivitäten an das Panel senden“ aktiv sind. Die manuellen Overrides werden nie gesendet.

Was in die Datenschutzerklärung soll

Solange du nicht das Plugin deinstallieren willst, nenn in der Datenschutzerklärung der Website mindestens diese Punkte.

• dass die Website IP und Benutzername der fehlgeschlagenen Zugriffsversuche aus Sicherheitsgründen erfasst.
• dass sie ein Protokoll der Benutzeraktionen führt, mit IP, und wie viele Tage sie es aufbewahrt.
• dass, wenn du das Panel verbunden hast, einige dieser Daten an den externen Dienst gesendet werden.
• wer der Verantwortliche ist und wie Benutzer ihre Rechte ausüben können.

Pass den Text an deine Situation an, mit deinem Berater, falls du einen hast: Das Handbuch ersetzt keine Rechtsberatung. Für die Grundlagen zu Plugins erklärt die offizielle Anleitung von WordPress auch den Unterschied zwischen Deaktivieren und Löschen.

Wenn etwas nicht funktioniert

Zeigt die Website nach der Deaktivierung einen Fehler, prüf .htaccess per FTP und sieh das Kapitel Fehlerbehebung und häufige Fragen. Hast du dich entschieden, das Plugin irrtümlich zu deinstallieren, kommen die lokalen Daten nicht zurück: Du brauchst eine Sicherungskopie der Website.

Vorheriges Kapitel: Fehlerbehebung und häufige Fragen. Zurück zum Verzeichnis mit der Einführung zum CSDN Handbuch.

The post Plugin deinstallieren: was bleibt und personenbezogene Daten first appeared on Matteo Cisilino.

Fehlerbehebung CSDN: wo du anfängst

Bevor du nach der genauen Antwort suchst, geh diese Checkliste durch.

1. Kommst du noch in wp-admin? Wenn ja, löst sich fast alles über die Einstellungsseite des Plugins.
2. Lies die Hinweise oben. Das Plugin erklärt das Ergebnis der Aktionen mit farbigen Kästen.
3. Erinnere dich an die letzte Änderung: eine Hardening-Regel, eine Richtlinie, eine Grenze.
4. Gibt es eine Schaltfläche Jetzt prüfen oder Jetzt verifizieren, nutz sie, bevor du rätst.
5. Kommst du nicht mehr auf die Website, bereite den FTP-Zugang oder den Dateimanager des Hostings vor.

Logins und Sperrungen

Ich habe mich selbst ausgesperrt: was tue ich?

Hast du noch Zugang zu WordPress, zum Beispiel vom Telefon aus mit dem Mobilfunknetz, öffne den Reiter Blockierte IPs. Such deine IP und klick auf Entsperren. Steht deine IP nicht in der Liste, aber du bist gesperrt (kann von der optionalen Sicherheitsliste kommen), geh zum Reiter Allgemein, Abschnitt „Lokale IP-Overrides“: Trag die IP ein, wähl „Immer entsperren (unban)“ und klick auf Override speichern. Klick danach im Reiter Allgemein auf Zur Whitelist hinzufügen.

Bist du auch von der Website gesperrt und siehst einen 403-Fehler, geh per FTP hinein und öffne .htaccess. Entfern die Zeile mit deiner IP, oder den ganzen Block zwischen # BEGIN Cisilino Site Defense Network und # END Cisilino Site Defense Network.

Achtung: Die Änderung von Hand ist vorübergehend. Die Sperre wird von derselben Quelle beim nächsten Ereignis neu geschrieben: ein fehlgeschlagener Login, eine Synchronisierung oder der 15-Minuten-Durchlauf. Sobald du wieder drin bist, nutz „Entsperren“ und die Whitelist.

Warum hat mich die Whitelist nicht entsperrt?

Die Whitelist verhindert nur, dass fehlgeschlagene Logins gezählt werden. Sie hebt bestehende Sperren nicht auf. Um eine Sperre aufzuheben, brauchst du Entsperren, das einen permanenten Entsperrungs-Override für diese Website anlegt.

Ein berechtigter Benutzer wurde gesperrt

Der Zähler der Versuche ist pro IP kumulativ und setzt sich nicht von selbst zurück. Auch über Wochen verteilte Fehler können die Schwelle erreichen, die standardmäßig 10 ist. Entsperre die IP und setz sie auf die Whitelist, oder erhöh die Schwelle in Remote-Einstellungen, wo das Feld „Lokale Sperrschwelle (fehlgeschlagene Versuche)“ heißt.

Die Sperre einer IP endet nie

Eine lokale Sperre läuft nicht ab. Eine manuelle Sperre läuft mit der gewählten Dauer ab, von 1 Stunde bis 7 Tage. Hast du „Permanent (bis du es entfernst)“ gewählt, läuft sie nicht ab. Eine vom Panel empfangene Sperre verschwindet, wenn das Panel sie von der Liste nimmt. Ein befristetes Entsperren stellt die Sperre beim Ablauf wieder her, wenn die ursprüngliche Quelle noch da ist. Für ein endgültiges Entsperren nutz Entsperren, das permanent ist.

Hinter einem Proxy oder einer CDN sind die Sperren seltsam

Das Plugin liest die IP nur aus REMOTE_ADDR und ignoriert den Header X-Forwarded-For, weil er sich fälschen lässt. Sieh den Satz „Deine aktuelle IP ist …“ unter dem Feld IP-Adresse im Reiter Allgemein. Ist das nicht deine öffentliche IP, sieht das Plugin die Adresse des Proxys. In dem Fall vermeide es, diese Adresse zu sperren oder auf die Whitelist zu setzen, bis du die Situation mit der Person geklärt hast, die den Proxy verwaltet.

Fehler nach den .htaccess-Regeln

Dieser Teil der Fehlerbehebung CSDN betrifft die in die Serverdatei geschriebenen Regeln.

Die Website zeigt Fehler 500 nach dem Speichern des Hardening

Das Plugin legt keine Kopie von .htaccess an und prüft die Syntax nach dem Schreiben nicht. Ein Fehler, oder eine Regel, die der Server nicht akzeptiert, zeigt sich sofort als Fehler 500.

1. Geh per FTP oder über den Dateimanager hinein.
2. Erstelle eine Kopie von .htaccess.
3. Lösch den Block zwischen # BEGIN Cisilino Site Defense Network - Hardening und # END Cisilino Site Defense Network - Hardening.
4. Lad die Website neu, korrigier dann die Einstellungen im Reiter Hardening / IDS.

Der Hardening-Block wird nur neu geschrieben, wenn du den Reiter speicherst oder das Plugin erneut aktivierst, nicht vom 15-Minuten-Durchlauf. Deine Änderung von Hand bleibt also bestehen.

Ich habe einen eigenen Pfad geschrieben, und die ganze Website gibt 403

Im Feld der eigenen Pfade ist jede Zeile wörtlicher Text, ohne Platzhalter. Die Regel blockiert jede Adresse, die diese Zeichenkette enthält. / oder wp zu schreiben blockiert alles, einschließlich wp-admin. Entfern per FTP den Hardening-Block, wie oben. Korrigier oder leer dann im Reiter Hardening / IDS das Feld „Eigene zu blockierende Pfade“ und speicher. Korrigierst du es nicht, schreibt ein neues Speichern oder eine Reaktivierung des Plugins die Regel neu, und die Website gibt wieder 403.

Es erscheint „Einstellungen gespeichert, aber das Schreiben in .htaccess ist fehlgeschlagen“

Die Datei .htaccess ist nicht beschreibbar: Prüf die Rechte. Die Regeln dieses Blocks sind nicht aktiv. Weiter aktiv bleiben die beiden Schalter, die in PHP wirken, also XML-RPC und ?author=N.

Der Test sagt, die PHP-Blockade in uploads funktioniere nicht

Im Reiter Test meldet der Kasten „Prüfung der PHP-Ausführungsblockade in uploads“, ob die Testdatei ausgeführt wurde. Prüf, ob das Hosting .htaccess in diesem Ordner erlaubt und ob keine spezifischere <Directory>-Blockade existiert. Auf nginx haben die Regeln keine Wirkung. Die Regel deckt nur den Standardordner uploads ab.

Ein Plugin oder das Theme haben aufgehört zu funktionieren

Schalt die letzte aktivierte Regel aus und speicher. Die häufigsten Fälle: Die PHP-Blockade in uploads zerstört Plugins, die dort PHP-Dateien schreiben; das Deaktivieren von XML-RPC stoppt Apps und Remote-Funktionen; die Blockade ausführbarer Uploads lehnt auch Dateien wie .svg ab.

Benutzer, Autoren und Besucher

Ein Autor kann nicht mehr veröffentlichen: „dein Konto ist gesperrt“

Das Rate Limiting hat zu viele in kurzer Zeit erstellte Inhalte gesehen. Standardmäßig liegt die Grenze bei 150 Inhalten in 300 Sekunden, mit einer Sperrung von 3600 Sekunden. Klick im Reiter Rate Limiting, in der Tabelle der gesperrten Benutzer, auf Sperrung aufheben. Andernfalls warte den Ablauf ab.

Das Ausschalten von „Rate Limit aktiv“ hebt eine laufende Sperrung nicht auf. Erhöh vor einem großen Import die Grenze N oder schalte die Grenze aus.

Ein Besucher sieht „Zu viele Einsendungen“

Ein Gast hat zu viele Kommentare oder Formulare in kurzer Zeit gesendet: standardmäßig mehr als 2 in 60 Sekunden, und die Sperrung dauert 3600 Sekunden. Die Sperrung ist pro IP, kann also mehrere Personen im selben Büro treffen. Erhöh den Wert N im Abschnitt Besucher. Es gibt keine Ausnahmeliste.

Ich kann keinen Redakteur- oder Administrator-Benutzer anlegen

Das ist beabsichtigt. Die Standardrichtlinie von Benutzerregistrierung ist „Nur Rollen mit geringem Privileg“ und macht keine Ausnahmen, auch nicht für dich. Wechsel vorübergehend zu „Keine Einschränkung“, leg den Benutzer an und geh dann zurück. Mit „Keine Registrierung (exklusiv)“ kann niemand Benutzer anlegen. Prüf auch die Standardrolle in Einstellungen > Allgemein von WordPress: Ist sie eine verbotene Rolle, werden Registrierungen abgelehnt.

Verbindung zum Panel

Die Verbindung zum Panel wird nicht angezeigt

Der Status steht im Kasten „Status der Panel-Verbindung:“ oben im Reiter Remote-Einstellungen. Fehlt der Kasten, waren die Felder unvollständig: Nötig sind Customer Code, API-Schlüssel und URL des Panels. Nach „Speichern und Verbindung prüfen“ erscheint kein eigenes Banner.

• „URL des Panels nicht sicher: https nötig …“: Die Adresse muss mit https beginnen. Das Plugin verweigert sogar das Speichern einer http-URL.
• „Authentifizierung vom Panel abgelehnt: customer_code oder API-Schlüssel falsch.“: Prüf die beiden Werte erneut.
• „Panel nicht erreichbar: …“: Problem mit Netzwerk, DNS oder Zertifikat.
• „Antwort des Panels ungültig (kein JSON).“: Die Adresse zeigt nicht auf das richtige Panel.

Antwortet das Panel nicht, läuft der lokale Schutz weiter, und die wartenden Daten werden beim nächsten Durchlauf gesendet. Das Plugin funktioniert auch ohne Panel.

Die Aktivitäten kommen nicht am Panel an

Sieh im Reiter Aktivitätsprotokoll die Diagnosetabelle und die Zeile „wartend auf Versand an das Panel“. Klick auf Jetzt versuchen zu senden: Das Ergebnis steht in der Diagnose. Die Zeilenobergrenze, standardmäßig 500, löscht die ältesten, auch wenn sie nicht zugestellt wurden.

Debug-Log, Integrität und Header

Das Debug-Log schaltet sich nicht ein

Es gibt zwei mögliche Meldungen. „der Upload-Ordner ist nicht beschreibbar“: Richte die Rechte von uploads ein. „die Dateien seines Ordners sind vom Internet aus erreichbar“: wahrscheinlich ein Server ohne .htaccess, wie nginx. Blockier den Zugriff auf den Ordner csdn-debug-* in der Serverkonfiguration und versuch es erneut. Hat das Log wegen der Obergrenze von 200 MB gestoppt, lad die Dateien herunter oder lösch sie und schalt es erneut ein.

Die Integrität meldet „die Plugin-Dateien stimmen nicht überein“

Hast du eine Plugin-Datei von Hand geändert, ist das normal. Andernfalls behandle die Website als potenziell kompromittiert: Installiere das Plugin aus einer zuverlässigen Kopie neu und prüf den Rest. Sagt die Meldung, es gebe keine Referenz, aktiviere das Plugin erneut, um eine neue Momentaufnahme zu erstellen.

HSTS schaltet sich nicht ein oder nicht aus

Um es zu aktivieren, musst du die Einstellungen des Plugins über https öffnen, sonst erscheint „HSTS wurde NICHT aktiviert“. Speicher immer von einer https-Seite aus. Das Ausschalten des Kästchens stoppt den Versand des Headers, aber Browser, die ihn schon erhalten haben, erinnern sich lange daran.

Wenn du die Antwort nicht findest

Reicht die Fehlerbehebung CSDN nicht aus, schalt das Debug-Log ein, reproduzier das Problem und lies den Eintrag. Öffne dann eine Diskussion im Support-Forum des Plugins: Dort erhältst du Hilfe und siehst schon gemeldete Probleme. Füg keine Serverpfade oder sensiblen Daten ein.

Vorheriges Kapitel: Debug-Log: PHP-Fehler in einer eigenen Datei. Nächstes Kapitel: Deaktivierung, Deinstallation und personenbezogene Daten. Für das Verzeichnis: CSDN Handbuch.

The post Fehlerbehebung CSDN: Fehler 500, Sperrungen und FAQ first appeared on Matteo Cisilino.

Wo du es findest

Geh zu Einstellungen > Cisilino Site Defense Network (Punkt 1 im Bild) und öffne den Reiter Debug-Log (Punkt 2). Es gibt drei Abschnitte:

• Punkt 3: „Debug-Log der Website“, mit Status und Einschalten.
• Punkt 4: „Gesammelte Dateien“.
• Punkt 5: „Letzte Einträge“.

Wozu das Debug-Log WordPress dient

Es ist nützlich, wenn die Website eine leere Seite oder einen kritischen Fehler zeigt, wenn nach einem Update etwas kaputtgeht, oder wenn dein Hosting dich wp-config.php nicht ändern oder die Server-Logs nicht lesen lässt. Die Konstanten WP_DEBUG und WP_DEBUG_LOG werden vor dem Laden der Plugins definiert, ein Plugin kann sie also nicht einschalten. Dieses Log nutzt einen eigenen PHP-Fehlerhandler, der beim Laden des Plugins eingehängt wird.

Dieses Log kommt dazu, es ersetzt nichts. Die Fehler kommen weiter dort an, wo sie vorher ankamen, also in debug.log und im Server-Log. Es sendet nichts an das Panel.

Wie man es benutzt

1. Öffne den Reiter Debug-Log.
2. Wähl Bleibt an für: 1 Stunde, 24 Stunden (Standard) oder 7 Tage.
3. Wähl Maximale Dateigröße.
4. Klick auf Debug-Log einschalten. Du liest „Debug-Log eingeschaltet. Es schaltet sich von selbst bei Ablauf der gewählten Zeit aus; die Dateien bleiben.“.
5. Reproduzier das Problem auf der Website.
6. Geh zurück zum Reiter. Lies „Letzte Einträge“ oder lad die Datei aus dem Abschnitt „Gesammelte Dateien“ herunter.
7. Wenn du fertig bist, klick auf Debug-Log ausschalten, oder warte den Ablauf ab. Du siehst „Debug-Log ausgeschaltet. Die gesammelten Dateien stehen weiter unten.“.

Der „Status:“ sagt dir, ob das Log „an, schaltet sich am tt.mm.jjjj hh:mm aus“, „aus (abgelaufen am …)“ oder „aus“ ist. Bei eingeschaltetem Log kannst du die Größe mit Größe speichern ändern.

Gesammelte Dateien

Die Tabelle listet Name, Größe und die Schaltflächen Herunterladen und Löschen. Darunter findest du Alle Dateien löschen. Vor dem Löschen fragt das Plugin: „Diese Datei löschen? Der Vorgang lässt sich nicht widerrufen.“. Für Alle Dateien löschen lautet der Text „Alle Dateien des Debug-Logs löschen? Der Vorgang lässt sich nicht widerrufen.“. Gibt es nichts, liest du „Keine Datei: das Log war nie an oder hat noch nichts erfasst.“.

Letzte Einträge

Der Kasten zeigt die 200 neuesten Einträge, vom neuesten beginnend. Das Menü Alle Stufen erlaubt dir, nach Fatal error, Parse error, Recoverable error, Warning, Notice oder Deprecated zu filtern. Klick dann auf Filtern. Für alles andere lad die Dateien herunter. Findet der Filter nichts, liest du „Kein Eintrag mit diesem Filter.“.

Ein Eintrag hat diese Form:

[2026-10-29 10:15:03 UTC] Warning: Nachricht in /pfad/datei.php:12 | GET /seite

• Die Uhrzeit ist in UTC, anders als die Uhrzeit der Website, die du im Aktivitätsprotokoll siehst.
• Nach dem senkrechten Strich findest du Methode und Pfad der Anfrage, ohne Query-String. Von der Kommandozeile oder einem Cron aus siehst du „cli/cron“.
• Eine mehrzeilige Meldung, wie ein Stack-Trace, bleibt ein einziger Eintrag mit eingerückten Folgezeilen.
• Die Zeilen „Info: Debug-Log aktiviert (Benutzer N)“ und „Info: Debug-Log deaktiviert (Benutzer N)“ haben keine Stufe: Bei einem Filter erscheinen sie nicht.

Standardwerte und Grenzen

• Dauer des Debug-Log WordPress: 1 Stunde, 24 Stunden oder 7 Tage. Ein anderer Wert wird zu 24 Stunden.
• Größe pro Datei: 1, 5, 10, 25 oder 50 MB. Standard ist 5 MB. Die gewählte Größe wird gespeichert, wenn du auf Debug-Log einschalten oder Größe speichern klickst. Achtung: Debug-Log ausschalten bringt die Größe zurück auf 5 MB, weil dieses Modul kein Größenmenü enthält.
• Gesamtobergrenze: 200 MB, .log– und .zip-Dateien zusammengerechnet.
• Jede Nachricht wird auf 4000 Zeichen gekürzt.
• Es erfasst nur PHP-Fehler: keine langsamen Abfragen, JavaScript-Fehler oder HTTP-Anfragen.

Beispiele

• Kritischer Fehler nach einem Plugin-Update: Schalte für 1 Stunde ein, lad die Seite neu, filtere „Fatal error“. Der Eintrag zeigt Datei und Zeile, zum Beispiel /…/plugins/xyz/datei.php:210 | GET /shop/.
• Vereinzelte Warnungen: 24 Stunden, Filter Warning oder Deprecated. Wurde die Datei rotiert, lad das Zip herunter.
• Langsame Website ohne klaren Grund: 7 Tage mit 25-MB-Dateien, dann such nach wiederkehrenden Notice und Warning.

Halt das Debug-Log WordPress nur so lange an, wie nötig: Meist reicht 1 Stunde.

Achtung: Die Dateien des Debug-Logs enthalten Serverpfade und Datenfragmente. Teile sie nicht öffentlich. Sie bleiben auf der Festplatte, auch nach dem Ausschalten und nach der Deinstallation des Plugins, die die Optionen, aber nicht die Dateien löscht. Entferne sie selbst, wenn du fertig bist. Die Gesamtobergrenze liegt bei 200 MB.

Achtung: Auf nginx-Servern kann das Einschalten abgelehnt werden, solange der Server den Ordner csdn-debug-* nicht blockiert. Die Meldung lautet: „Debug-Log nicht eingeschaltet: Die Dateien seines Ordners sind vom Internet aus erreichbar (wahrscheinlich ein Server ohne .htaccess-Unterstützung, wie nginx). Die Logs können Pfade und Daten enthalten: Blockiere den Zugriff auf den Ordner csdn-debug-* in der Serverkonfiguration und versuch es erneut.“. Verwaltest du den Server nicht selbst, frag die zuständige Person.

Achtung: Das Log sieht keine mit @ unterdrückten Fehler und keine, die vor dem Laden des Plugins entstehen. Zum Beispiel sieht es keine Fehler von wp-config.php. Das Debug-Log WordPress des Plugins ersetzt die Server-Logs nicht.

Was im Hintergrund passiert

Das Debug-Log WordPress speichert die Dateien in einem Ordner wp-content/uploads/csdn-debug-, gefolgt von 16 zufälligen Zeichen. Darin liegen eine index.php, eine .htaccess, die den Zugriff verweigert, und die aktuell genutzte Datei csdn-debug.log. Beim Einschalten schreibt das Plugin eine Testdatei und versucht, sie per HTTP zu lesen. Antwortet sie, verweigert es das Einschalten des Logs.

Übersteigt die aktuell genutzte Datei die gewählte Größe, wird sie geschlossen, in .zip komprimiert, und eine neue startet. Kein Eintrag geht verloren. Die ursprüngliche .log-Datei wird erst gelöscht, nachdem das Zip geprüft wurde. Scheitert die Komprimierung, bleibt die .log-Datei. Die „Letzten Einträge“ werden nur aus der aktuell genutzten Datei gelesen, nach einer Rotation stehen die alten also in den Zip-Dateien.

Vor dem Rotieren prüft das Plugin die Obergrenze von 200 MB. Ist sie erreicht, stoppt das Log, um nichts zu überschreiben. Es erscheint der gelbe Hinweis: „Das Log wurde angehalten, weil die Dateien die Platzgrenze (200 MB) erreicht haben: Um Daten nicht zu überschreiben, schreibt es nicht mehr. Lad Dateien herunter oder lösch sie, dann schalt es erneut ein.“. Um weiterzumachen, lösch die Dateien und schalt es erneut ein.

Beim Ablauf schaltet sich das Log von selbst aus, aber die Dateien bleiben. Das Plugin kürzt oder löscht sie nie: Das tust nur du, mit Löschen oder Alle Dateien löschen. Bei fatalen Fehlern wird der Eintrag am Ende der Anfrage geschrieben.

Wenn das Debug-Log WordPress nicht funktioniert

• „Debug-Log nicht eingeschaltet: der Upload-Ordner ist nicht beschreibbar.“: Prüf die Rechte des Ordners wp-content/uploads.
• Das Log schreibt nicht: Schlägt das Schreiben fehl, meldet das Plugin es mit einem Eintrag „Debug-Log der Website: …“ in den „Letzten Versuchen“ des Reiters Aktivitätsprotokoll.
• Das Log steht wegen der Obergrenze: Lad herunter, was du brauchst, lösch die Dateien und schalt es erneut ein.

Die allgemeine Anleitung zum Handbuch erklärt, wo dieser Reiter einzuordnen ist. Um die Konstanten von WordPress besser zu verstehen, sieh dir die offizielle Anleitung zum Debuggen von WordPress an: Sie erklärt WP_DEBUG und WP_DEBUG_LOG, die dieses Plugin nicht ersetzen kann.

Vorheriges Kapitel: Aktivitätsprotokoll. Nächstes Kapitel: Fehlerbehebung und häufige Fragen.

The post Debug-Log WordPress: PHP-Fehler in einer eigenen Datei first appeared on Matteo Cisilino.

Wo du es findest

Geh im Backend zu Einstellungen > Cisilino Site Defense Network (Punkt 1 im Bild). Öffne den Reiter Aktivitätsprotokoll (Punkt 2). Von oben nach unten findest du diese Abschnitte:

• Punkt 3: „Einstellungen des Aktivitätsprotokolls“.
• Punkt 4: die Statuszeile über dem Formular, mit den Zeilenzählern.
• Punkt 5: „Diagnose des Versands an das Panel“.
• Punkt 6: „Erfasste Aktivitäten“, die Tabelle mit den Filtern.
• Punkt 7: „Lokales Protokoll leeren“.

Wozu das Aktivitätsprotokoll WordPress dient

Es hilft dir, Fragen zu beantworten wie „Wer hat dieses Plugin deaktiviert?“ oder „Von welcher IP ist dieser Benutzer eingeloggt?“. Jedes Ereignis ist eine Zeile in der Datenbanktabelle der Website.

Verwechsle es nicht mit dem Zähler fehlgeschlagener Logins pro IP, der über die Sperrungen entscheidet. Es sind zwei getrennte Daten, mit unterschiedlichen Aufbewahrungsregeln. Der fehlgeschlagene Login-Versuch erscheint aber auch hier, eine Zeile pro Versuch.

Für die lange Historie und ernsthafte Suchen lohnt sich das Panel. Das lokale Protokoll funktioniert auch ohne Panel. Die Verbindung richtest du in Remote-Einstellungen ein.

Wie man es benutzt

1. Öffne den Reiter und sieh die Zeile „Zeilen im lokalen Protokoll: N — wartend auf Versand an das Panel: M“.
2. Wähl im Formular die unten beschriebenen Einstellungen.
3. Klick auf Protokolleinstellungen speichern. Es erscheint „Einstellungen des Aktivitätsprotokolls gespeichert.“.
4. Um die Ereignisse zu lesen, geh zu „Erfasste Aktivitäten“. Wähl eine Gruppe aus dem Menü Alle Gruppen, oder schreib ins Feld Benutzer, Objekt oder IP, dann klick auf Filtern.

Die Einstellungen des Formulars

• „Aktivitäten auf dieser Website protokollieren“: Schaltest du es aus, werden keine neuen Zeilen geschrieben. Die alten bleiben.
• „Lokale Aufbewahrung (Tage)“: von 0 bis 3650. Mit 0 wird nichts wegen des Alters gelöscht.
• „Obergrenze erhaltener Zeilen“: von 0 bis 1.000.000. Mit 0 gibt es keine Obergrenze.
• „Aktivitäten an das Panel senden“: erfordert die Verbindung in den Remote-Einstellungen.
• „Sofortige Zustellung“: Der Versand startet am Ende der Anfrage, ohne den Besucher warten zu lassen. Schaltest du es aus, erfolgt der Versand nur mit der Synchronisierung alle 15 Minuten.
• „Was protokolliert wird“: ein Kästchen für jede der 18 Ereignisgruppen.

Die Ereignisgruppen

Die Gruppen haben diese Beschriftungen, identisch in den Kästchen von „Was protokolliert wird“ und im Menü Alle Gruppen: Logins (Login, Logout, fehlgeschlagene Versuche); Benutzer (Erstellung, Profiländerung, Rollen, Löschung); Inhalte (Beiträge, Seiten, eigene Inhaltstypen); Kategorien und Schlagwörter; Kommentare; Medien (Anhänge); Plugins (Aktivierung, Deaktivierung, Installation, Aktualisierung); Themes (Themenwechsel, Aktualisierung, Anpassung); WordPress-Aktualisierungen; WordPress-Einstellungen; Navigationsmenüs; Widgets; Datei-Editor für Themes/Plugins aus wp-admin; Inhalts-Export; Datei-Uploads (einschließlich jener außerhalb der Mediathek); Integrität der Plugin-Dateien; Plugin-Einstellungen (einschließlich der dieses Plugins); Lebenszyklus des Plugins (Deaktivierung, Deinstallation, Leeren des Protokolls).

Für WordPress-Einstellungen wird nur eine Auswahl der wichtigsten Optionen erfasst, zum Beispiel blogname, siteurl, admin_email, default_role und active_plugins. Bei anderen Plugins werden nur die mit register_setting() deklarierten oder von options.php gespeicherten Einstellungen gesehen. Der Datei-Editor erfasst den Versuch, nicht das Ergebnis.

Wie man die Tabelle liest

Die Spalten sind Wann, Benutzer, IP, Gruppe, Aktion, Detail und Gesendet. Die Zeilen sind 50 pro Seite, die neuesten zuerst. Nutz Zurück und Weiter, um dich zu bewegen. Gibt es nichts, liest du „Keine Aktivität erfasst (mit diesen Filtern).“.

Gruppe und Aktion erscheinen mit dem rohen Namen, zum Beispiel plugins und deactivated. Wer nicht angemeldet ist, erscheint als „(nicht angemeldet)“. In der Spalte Gesendet findest du das Bestätigungsdatum des Panels, oder „—“, wenn die Zeile noch in der Warteschlange ist. Das Feld mit technischen Details ist hier nicht sichtbar: Du liest es auf dem Panel.

Ein Beispiel für eine Zeile im Aktivitätsprotokoll WordPress: 12.10.2026 09:14:02, Benutzer mario (administrator), IP 203.0.113.5, Gruppe plugins, Aktion deactivated.

Beispiele zum Lesen

• Gruppe „Logins (Login, Logout, fehlgeschlagene Versuche)“ und eine verdächtige IP: Eine Reihe von failed, gefolgt von einem success, kann heißen, dass jemand das Passwort erraten hat.
• Eine Zeile users mit Aktion role_changed und einem unerwarteten Benutzer: Prüf, ob es eine Rechteausweitung ist.
• Eine Zeile der Gruppe Uploads mit einem Blockadehinweis: Jemand hat versucht, eine gefährliche Datei hochzuladen.

Standardwerte des Aktivitätsprotokolls WordPress

• Protokoll eingeschaltet, Versand an das Panel eingeschaltet, sofortige Zustellung eingeschaltet, alle Gruppen aktiv.
• Aufbewahrung: 30 Tage. Die altersbedingte Löschung erfolgt einmal täglich.
• Zeilenobergrenze: 500. Die Prüfung greift bei jeweils 100 Einfügungen, die Tabelle kann sie also um etwa 100 Zeilen überschreiten.
• Speicherst du ohne eine Gruppe anzukreuzen, bleibt das Protokoll an, schreibt aber nichts.
• Es erfasst keine normalen Besuche und exportiert keine Daten.

Achtung: Ein fehlgeschlagener Login speichert den eingegebenen Benutzernamen. Schreibt jemand das Passwort ins Benutzernamenfeld, bleibt dieser Text im Protokoll, das an das Panel gehen kann. Das Plugin filtert ihn nicht. Behalte das im Kopf, wenn du das Protokoll teilst oder einsiehst.

Achtung: Die Zeilenobergrenze (Standard 500) löscht die ältesten Zeilen auch, wenn sie noch nicht an das Panel gesendet wurden. Die Obergrenze hat Vorrang vor der Zustellgarantie. Auf Websites mit viel nicht angemeldetem Verkehr (fehlgeschlagene Logins, Kommentare, Datei-Einsendungen) können 500 Zeilen schnell erreicht sein. Brauchst du die vollständige Historie, erhöh die Obergrenze, bedenk aber, dass du mit 0 das Platzlimit auf der Festplatte entfernst.

Achtung: „Aktivitätsprotokoll leeren“ ist lokal unwiderruflich. Es fragt vorher: „Das gesamte lokale Aktivitätsprotokoll leeren? Der Vorgang lässt sich nicht rückgängig machen.“.

Was nicht gespeichert wird

Passwörter im Klartext werden niemals erfasst. Bei einer Profiländerung wird nur der Hinweis gespeichert, dass das Passwort geändert wurde. Das Feld „API-Schlüssel“ des Plugins wird als *** gezeigt. Optionen anderer Plugins, deren Name Wörter wie key, secret, token, password, auth, salt, nonce, license oder credential enthält, haben den Wert durch „*** (Wert nicht erfasst)“ ersetzt. Die Werte der Optionen werden auf 200 Zeichen gekürzt.

Diagnose des Versands an das Panel

Der Abschnitt bei Punkt 5 ist nützlich, wenn die Aktivitäten nicht am Panel ankommen. Ein fehlgeschlagener Versand zeigt keine sichtbaren Fehler: Die Zeilen bleiben in der Warteschlange und versuchen es erneut. Das einzige Symptom ist der Zähler „wartend“, der nicht sinkt.

Die Tabelle zeigt unter anderem „Verbindung zum Panel“, „Aktivitätsprotokoll“, „Versand an das Panel“, „Sofortige Zustellung“, „Zeilen in der Warteschlange“, „Ziel von error_log()“ und „Letzter Sendeversuch“. Problematische Werte sind rot. Zeigt der letzte Versuch weniger angenommene als gesendete Zeilen, erscheint „Vom Panel abgelehnte Zeilen“: Diese Zeilen werden nicht erneut versucht.

Es gibt drei Schaltflächen:

• Jetzt versuchen zu senden: macht sofort einen Testversand. Das Ergebnis steht in der Tabelle.
• Ausführliches Protokoll aktivieren (danach Ausführliches Protokoll deaktivieren): erfasst auch erfolgreiche Versände.
• Diagnoseprotokoll leeren: löscht nur die Liste „Letzte Versuche“, die höchstens 25 Einträge hält. Erscheint nur, wenn es Einträge gibt.

Was im Hintergrund passiert

Am Ende der Anfrage schließt das Plugin die Antwort an den Besucher, wenn der Server es erlaubt, und sendet die Zeilen an das Panel in Stapeln von höchstens 200, von den ältesten beginnend. Eine Zeile gilt erst als zugestellt, wenn das Panel ihren Empfang bestätigt. Eine Synchronisierung alle 15 Minuten dient als Sicherheitsnetz.

Die altersbedingte Aufbewahrung löscht die alten Zeilen einmal täglich. Ist der Versand an und das Panel konfiguriert, löscht sie nur bereits bestätigte. Andernfalls löscht sie nur nach Alter.

Das Leeren versucht zuerst, den Rückstand zu senden, und löscht dann alles. Es erfasst das Leerungsereignis, das zur ersten Zeile des neuen Protokolls wird. Es sendet keinen Löschbefehl an das Panel: Die schon gesendete Historie bleibt dort. Nach dem Leeren liest du „Lokales Aktivitätsprotokoll geleert. Die schon an das Panel gesendete Historie wurde nicht berührt.“. Gab es nie zugestellte Zeilen, sagt dir ein fettgedruckter Hinweis, wie viele verloren gegangen sind.

Wenn das Aktivitätsprotokoll WordPress nicht sendet

• Der Zähler „wartend“ sinkt nicht: Öffne die Diagnose, sieh den letzten Versuch und den HTTP-Code, klick dann auf „Jetzt versuchen zu senden“.
• Roter Kasten, dass das Panel nicht bestätigt: Das Panel ist vielleicht nicht aktuell. Die Zeilen bleiben in der Warteschlange, nichts geht verloren.
• Verbindung „NICHT konfiguriert“: Ohne Customer Code, API-Schlüssel und URL wird nichts gesendet. Geh zurück zu Remote-Einstellungen.

Für eine umfassendere Anleitung zu guten Protokollierungspraktiken lies die OWASP-Anleitung zum Logging: Sie erklärt, was es sich zu protokollieren lohnt und was zu vermeiden ist.

Zurück zu Kapitel 1, dem Inhaltsverzeichnis des Handbuchs. Vorheriges Kapitel: Rate Limiting. Nächstes Kapitel: Debug-Log.

The post Aktivitätsprotokoll WordPress: Anleitung zum Reiter von CSDN first appeared on Matteo Cisilino.

Wo du es findest

Geh zu Einstellungen und wähl Cisilino Site Defense Network (Punkt 1 im Bild). Öffne den Reiter „Rate Limiting“ (Punkt 2). Zum Speichern brauchst du die Berechtigung manage_options; bei Multisite manage_network_options.

Es gibt vier Abschnitte. Punkt 3 ist „Wie es konkret funktioniert: was gezählt wird“. Punkt 4 ist „1. Autoren: zu häufige Veröffentlichungen“. Punkt 5 ist „2. Besucher: Kommentare und Kontaktformulare“. Punkt 6 ist „Derzeit gesperrte Benutzer“. Die Zeitwerte sind alle in Sekunden.

Wozu es dient

Die Grenze für Autoren stoppt ein Konto, das in Serie veröffentlicht, bevor es die Website mit Inhalten überflutet. Die Grenze für Besucher bremst, wer Kommentare und Formulare überschwemmt. Der Code kennt auch eine dritte Grenze, die Pflicht-E-Mail. Du findest sie im Reiter „Benutzerregistrierung“, beschrieben im vorherigen Kapitel.

Wie man es benutzt

Was gezählt wird (Punkt 3)

Der Infokasten erklärt die Regeln. Bei Autoren greift die Kontrolle, wenn WordPress einen Beitrag oder eine Seite speichert. Das Plugin zählt, wie viele Beiträge und Seiten dieses Autors in den letzten T Sekunden erstellt oder veröffentlicht wurden. Sind es mehr als N, wird der Autor gesperrt. Das Speichern, das die Schwelle überschreitet, geht durch: Die Sperrung blockiert die nachfolgenden.

Plugins und Themes zählen nicht, ebenso wenig Logins, Änderungen an älteren Inhalten als das Zeitfenster, automatische Entwürfe, Revisionen, der Papierkorb, Medien, Kommentare und andere Inhaltstypen. Temporäre Umgebungen, wie die Testumgebung des Plugin Check, werden ignoriert.

Achtung: Das Beispiel in diesem Kasten nennt noch N=3. Das ist ein alter Text. Der tatsächliche Standardwert ist 150 Inhalte in 5 Minuten, seit Version 1.0.13.

Autoren (Punkt 4)

1. Kreuz „Rate Limit aktiv“ an, um die Veröffentlichungen der Autoren zu begrenzen.
2. Entscheide, ob du „E-Mail-Alarm“ behalten willst: Du erhältst eine Mail bei der Sperrung eines Autors.
3. Stell „N: erlaubte Inhalte“ ein, von 1 bis 1000. Standard 150.
4. Stell „T: Zeitfenster (Sekunden)“ ein, von 10 bis 86400. Standard 300, das sind 5 Minuten.
5. Stell „S: Sperrung (Sekunden)“ ein, von 60 bis 2592000. Standard 3600, das ist 1 Stunde.
6. Klick auf Rate-Limiting-Einstellungen speichern.

Die Mail geht an die Administrator-Adresse von Einstellungen > Allgemein. Sie enthält den Benutzer, die Inhalte im Zeitfenster, den Ablauf und eine Liste von bis zu 20 aktuellen Inhalten zur Kontrolle. Die Sperrung ändert diese Inhalte nicht.

Besucher (Punkt 5)

1. Kreuz „Rate Limit aktiv“ an, um die Einsendungen von Gästen zu begrenzen.
2. Der „E-Mail-Alarm“ ist standardmäßig aus. Auf einer exponierten Website kann er viele Mails erzeugen. Er geht an dieselbe Administrator-Adresse von Einstellungen > Allgemein, einmal pro Sperrung.
3. „N: erlaubte Einsendungen“, von 1 bis 100. Standard 2.
4. „T: Zeitfenster (Sekunden)“, von 5 bis 3600. Standard 60.
5. „S: IP-Sperrung (Sekunden)“, von 60 bis 2592000. Standard 3600.

Die Grenze betrifft nur nicht eingeloggte Besucher. Sie zählt die Einsendungen pro IP und pro Typ, Kommentare oder Formulare. Eine Sperrung bei Kommentaren blockiert keine Formulare. Die abgedeckten Kontaktformulare sind die von Contact Form 7. Der abgelehnte Kommentar zeigt „Zu viele Einsendungen“ mit Fehler 429.

Liegt ein Wert außerhalb der Grenzen, bringt das Plugin ihn auf den nächsten erlaubten. Das Speichern zeigt „Rate-Limiting-Einstellungen gespeichert. Werte außerhalb der erlaubten Grenzen wurden auf den nächsten erlaubten Wert gebracht.“

Rate Limiting WordPress: Sperrungen und Blockaden

Ein gesperrter Autor behält seine Rolle und kann den Rest des Panels nutzen. Er verliert aber die Berechtigung, Beiträge und Seiten zu erstellen und zu veröffentlichen. „Beitrag hinzufügen“ und die Seiteneinträge verschwinden, und öffnet er diese Bildschirme, erhält er „Zugriff verweigert“. Im Dashboard erscheint ein Hinweis, der sich nicht schließen lässt.

Achtung: Die Sperrung der Autoren trifft auch Administratoren. Ein gesperrter Administrator verliert die Erstellung und Veröffentlichung, kann aber trotzdem die Einstellungen öffnen und die Sperrung selbst aufheben. Es gibt keine Ausnahmeliste für Benutzer, Rollen oder IPs: Die IP-Whitelist des Reiters Allgemein befreit nicht vom Rate Limiting.

Achtung: Die Blockade der Besucher ist pro IP. Mehrere Personen hinter derselben IP, wie ein Büro, können zusammen blockiert werden. In dem Fall erhöh N. Das Plugin liest nur die Verbindungsadresse (REMOTE_ADDR) und nicht die Header von Proxy oder CDN: Hinter einem Reverse Proxy oder einer CDN können alle Besucher mit derselben IP erscheinen und sich gegenseitig blockieren.

Wie du eine Sperrung aufhebst

Du hast zwei Wege.

1. Warten. Die Sperrung endet von selbst nach S Sekunden.
2. Im Abschnitt bei Punkt 6, „Derzeit gesperrte Benutzer“, klick auf Sperrung aufheben in der Zeile des Benutzers. Du siehst „Sperrung aufgehoben: der Benutzer kann wieder Inhalte erstellen und veröffentlichen.“ Ist die Tabelle leer, liest du „Kein gesperrter Benutzer.“

Die Tabelle zeigt höchstens 100 Benutzer. Die Dashboard-Hinweise haben die Links „Sperrung aufheben“ und „Prüfen und aufheben“, die zum selben Reiter führen.

Das Ausschalten von „Rate Limit aktiv“ hebt eine laufende Sperrung nicht auf. Um sie zu entfernen, musst du sie aufheben oder den Ablauf abwarten.

Was im Hintergrund passiert

Die Sperrung ist eine beim Benutzer gespeicherte Information, mit Ablaufdatum. Bei Gästen wird jede Einsendung 24 Stunden lang in einer Plugin-Tabelle erfasst und dann im Zeitfenster gezählt. Kommen zwei Anfragen gleichzeitig an, kann eine mehr durchrutschen. Sperrungen und Blockaden landen im Aktivitätsprotokoll, wenn es aktiv ist und die Gruppen Benutzer und Kommentare aktiviert sind.

Achtung: Ein legitimer Import vieler Inhalte kann die Grenze für Autoren auslösen. Schalt vor einer Migration die Grenze aus oder erhöh N.

Beispiele für Rate Limiting WordPress

• Blog mit einem einzigen Autor: Du kannst N auf 10 oder 20 senken, mit T=300. So erfasst du ein kompromittiertes Konto früher. Das sind Testwerte, keine Regel des Plugins.
• Redaktion, die Seiten dupliziert oder importiert: Behalt 150/300 oder mehr.
• Büros mit geteilter IP: Erhöh die erlaubten Einsendungen der Besucher auf 3 oder 5.

Nützliche Umrechnungen: 300 Sekunden sind 5 Minuten, 3600 sind 1 Stunde, 86400 sind 1 Tag. Für mehr zum allgemeinen Thema lies die OWASP-Anleitung Blocking Brute Force Attacks, die erklärt, warum man wiederholte Versuche begrenzt.

Vorheriges: Benutzerregistrierung: wer Konten anlegen darf. Nächstes: Aktivitätsprotokoll: was auf der Website passiert ist. Für das allgemeine Verzeichnis geh zu Kapitel 1 des Handbuchs.

The post Rate Limiting WordPress: Grenzen für Autoren und Besucher first appeared on Matteo Cisilino.

Wo du es findest

Öffne im Menü von WordPress Einstellungen und dann Cisilino Site Defense Network (Punkt 1 im Bild). Wähl den Reiter „Benutzerregistrierung“ (Punkt 2). Zum Speichern brauchst du die Berechtigung manage_options; bei Multisite manage_network_options.

Es gibt drei Abschnitte. Punkt 3 ist „Registrierungsrichtlinie“. Punkt 4 ist „Erlaubte Rollen (nur Stufe „Rollen mit geringem Privileg“)“. Punkt 5 ist „Pflicht-E-Mail“.

Wozu es dient

Die Richtlinie gilt für jeden Weg der Kontoerstellung: das wp-admin-Panel, die REST API, XML-RPC, WP-CLI und jedes Plugin oder Theme, das die WordPress-Funktionen zur Benutzererstellung nutzt. Die Prüfung erfolgt in PHP, ohne die Datei .htaccess zu berühren.

Wie man es benutzt

Registrierungsrichtlinie (Punkt 3)

Wähl genau eine von drei Stufen. Sie addieren sich nicht.

• „Keine Einschränkung (deaktiviert)“: Das Modul ist aus, und WordPress verhält sich wie immer.
• „Nur Rollen mit geringem Privileg (nie Administrator/Redakteur/Autor)“: Das ist die Standardstufe. Es gelten die erlaubten Rollen aus Punkt 4.
• „Keine Registrierung (exklusiv)“: Kein neuer Benutzer kann angelegt werden.

Erlaubte Rollen (Punkt 4)

Gilt nur für die Stufe der Rollen mit geringem Privileg. Du kannst subscriber (standardmäßig angekreuzt), contributor und customer (nützlich mit WooCommerce) ankreuzen. Die Kästchen administrator, editor, author und shop_manager sind immer deaktiviert, mit der Beschriftung „nie erlaubt“.

Pflicht-E-Mail (Punkt 5)

Das Kästchen „Keine Benutzer ohne gültige E-Mail-Adresse anlegen“ ist standardmäßig aktiv. Es verhindert die Erstellung von Benutzern ohne gültige E-Mail, über jeden Weg. Es berührt keine bereits bestehenden Benutzer. Diese Einstellung wird zusammen mit denen des Rate Limiting gespeichert, aber hier verwaltet.

Klick am Ende auf Registrierungsrichtlinie speichern. Du siehst „Registrierungsrichtlinie für Benutzer gespeichert.“ Das Speichern landet im Aktivitätsprotokoll, mit der Beschriftung „Benutzerregistrierung“.

Benutzerregistrierung WordPress: Standardwerte und Grenzen

• Die Standardrichtlinie ist „Nur Rollen mit geringem Privileg“, aktiv auch wenn du nie etwas gespeichert hast.
• Die erlaubte Rolle am Anfang ist nur subscriber.
• Verbotene Rollen werden immer verworfen, auch wenn jemand versucht, sie von Hand zu senden.
• Die Rollenliste ist fest: Sie zeigt nicht die eigenen Rollen deiner Website.
• Es gibt keine Listen von E-Mail-Domains, kein Captcha und keine Anti-Spam-Kontrollen bei Registrierungen.

Achtung: Mit „Keine Registrierung (exklusiv)“ kann niemand Benutzer anlegen, auch nicht der Administrator. Der Eintrag „Neuen Benutzer hinzufügen“ verschwindet aus dem Menü, und user-new.php von Hand zu öffnen ergibt einen 403-Fehler. Nimmst du bei der Stufe der Rollen mit geringem Privileg das Häkchen bei allen Rollen weg, bleibt die Liste leer, und kein Benutzer ist erlaubt. Hier bleiben aber der Menüeintrag und die Seite sichtbar: Der 403-Fehler kommt erst, wenn du versuchst, den Benutzer anzulegen.

Mit der Standardstufe kannst du keinen Redakteur oder Autor anlegen, auch nicht als Administrator. Das Plugin sieht keine Ausnahmen für bereits eingeloggte Personen vor. Um einen Benutzer mit hoher Rolle anzulegen, wechsel vorübergehend zu „Keine Einschränkung“, leg den Benutzer an und geh dann zurück.

Prüfe auch die „Standardrolle für neue Benutzer“ unter Einstellungen > Allgemein von WordPress. Ist sie eine verbotene Rolle, wie Redakteur, wird jede Registrierung ohne explizite Rolle abgelehnt.

Was im Hintergrund passiert

Die Hauptprüfung wirkt auf den Filter pre_insert_user_data, nur bei der Erstellung eines Benutzers. Änderungen an bestehenden Benutzern passieren immer. Ein abgelehnter Versuch zeigt den Titel „Registrierung nicht erlaubt“ mit Fehler 403. Auf der REST API erhältst du einen JSON-Fehler 403 statt der Seite.

Bei jeder aktiven Richtlinie entfernt das Plugin die XML-RPC-Methode wp.newUser. Mit der exklusiven Richtlinie zwingt es auch die WordPress-Option „Jeder kann sich registrieren“ auf falsch. Mit der Stufe der niedrigen Rollen bleibt diese Option so, wie du sie gewählt hast.

Es gibt auch ein Sicherheitsnetz nach der Erstellung. Entsteht ein Konto trotzdem und verstößt gegen die Richtlinie, entzieht das Plugin ihm sofort die Rolle und schreibt ein Ereignis ins Aktivitätsprotokoll. Das Konto wird nicht gelöscht, damit du es prüfen kannst.

Achtung: Ein kompromittiertes Plugin oder Theme, das mit einem INSERT direkt in die Benutzertabelle der Datenbank schreibt, läuft durch keinen Filter. Kein PHP-Plugin kann das stoppen. Die durch diesen Reiter geschützte Benutzerregistrierung WordPress ist eine starke Barriere, aber keine absolute.

Beispiele

• Vitrinen-Website ohne öffentliche Benutzer: Wähl „Keine Registrierung (exklusiv)“.
• Website mit Abonnenten oder Kommentaren: Lass die Standardstufe mit subscriber.
• Shop mit WooCommerce: Füge customer hinzu.
• Du musst einen Mitarbeiter mit hoher Rolle hinzufügen: Nutz „Keine Einschränkung“ nur für die nötige Zeit.

Wenn etwas nicht funktioniert

Wird eine Anmeldung mit der Meldung zur nicht erlaubten Rolle abgelehnt, prüf die Standardrolle von WordPress und die angekreuzten Rollen bei Punkt 4. Das Aktivitätsprotokoll sagt dir, ob einem Konto vom Sicherheitsnetz die Rolle entzogen wurde. Um die Rollen besser zu verstehen, lies die Seite Rollen und Berechtigungen in der WordPress-Dokumentation. Sie listet auf, was jede Rolle darf.

Vorheriges: Paranoic Hardening: Sicherheitsheader und Administratorsitzung. Nächstes: Rate Limiting: Grenzen für Autoren und Besucher. Für das allgemeine Verzeichnis geh zu Kapitel 1 des Handbuchs.

The post Benutzerregistrierung WordPress: Richtlinie und erlaubte Rollen first appeared on Matteo Cisilino.

Wo du es findest

Geh im Seitenmenü von WordPress zu Einstellungen und wähl Cisilino Site Defense Network (Punkt 1 im Bild). Öffne den Reiter „ Paranoic Hardening“ (Punkt 2). Zum Speichern brauchst du die Berechtigung manage_options; bei Multisite manage_network_options.

Der Reiter hat vier Abschnitte. Bei Punkt 3 findest du „Paranoic Hardening — HTTP-Sicherheitsheader“. Bei Punkt 4 steht „HTTP Strict Transport Security (HSTS)“. Punkt 5 ist „Sicherheitsheader prüfen“. Punkt 6 ist „Autologout inaktiver Administratoren“.

Wozu es dient

Header sind Anweisungen, die die Website mit jeder Seite an den Browser sendet. Das Plugin sendet sie über den WordPress-Hook send_headers, ohne die Datei .htaccess zu berühren. Du riskierst also keinen 500-Fehler, und sie funktionieren auch ohne mod_headers.

Die Header betreffen nur die öffentliche Website. Sie werden nie im Verwaltungsbereich gesendet. Das Plugin bietet keine Content-Security-Policy und sendet kein X-XSS-Protection.

Wie du Paranoic Hardening benutzt

HTTP-Sicherheitsheader (Punkt 3)

• X-Content-Type-Options sendet nosniff. Der Browser „errät“ den Dateityp nicht mehr. Das Risiko ist praktisch null.
• X-Frame-Options sendet SAMEORIGIN. Die Website lässt sich nicht mehr in einen <iframe> einer anderen Domain einbetten. Zeigt eine Partner-Website deine Seiten, hört das auf.
• Referrer-Policy sendet strict-origin-when-cross-origin. Zu anderen Domains reist nur die Domain, nicht der Pfad. Statistikdienste Dritter, die den vollständigen Referrer wollen, erhalten ihn nicht.

Kreuz die Kästchen an, die du brauchst, und klick auf Paranoic Hardening speichern. Du siehst den Hinweis „Einstellungen von Paranoic Hardening gespeichert und angewendet.“ Nicht angekreuzte Kästchen werden als ausgeschaltet gespeichert.

HSTS (Punkt 4)

HSTS sagt dem Browser, immer https mit deiner Domain zu nutzen. Es gibt drei Kästchen: „HSTS aktivieren“, „includeSubDomains“ und „Preload“. Der gesendete Header hat max-age=31536000, das ist ein Jahr. Der Wert ist fest und lässt sich nicht ändern.

Das Plugin lehnt die Aktivierung ab, wenn die Seite nicht über https geöffnet wurde. In dem Fall speichert es den Rest und zeigt einen roten Hinweis: „Einstellungen gespeichert, aber HSTS wurde NICHT aktiviert: diese Anfrage kam nicht über https. Öffne das Panel über https und versuch es erneut.“ Ist die Seite über http, sind die drei Kästchen zudem deaktiviert.

Schaltest du „HSTS aktivieren“ aus, werden beim Speichern auch „includeSubDomains“ und „Preload“ zurückgesetzt. Aktivierst du HSTS erneut, musst du sie erneut ankreuzen.

Sicherheitsheader prüfen (Punkt 5)

Klick auf Jetzt prüfen. Das Plugin stellt eine echte Anfrage an die Startseite und prüft, welche Header wirklich ankommen. Das Ergebnis erscheint im Kasten, mit dem Datum des letzten Tests.

• Grün: „Alle erwarteten Header sind in der echten Antwort der Website vorhanden.“
• Rot: die aktiven Header, die nicht angekommen sind. Es kann ein Proxy, eine CDN oder ein anderes Plugin sein, das sie entfernt. HSTS gilt auch als fehlend, wenn die Adresse der Startseite http ist und nicht zu https führt, weil das Plugin es nur bei https-Anfragen sendet.
• Blau: „Kein aktiver Header zu prüfen: aktiviere oben mindestens eine Option und speichere.“
• Rot mit „Prüfanfrage fehlgeschlagen“: Die Anfrage war nicht erfolgreich.

Der Test prüft das Vorhandensein des Headers, nicht seinen Wert. Er startet nicht von selbst: Du musst ihn selbst klicken.

Autologout der Administratoren (Punkt 6)

Dieser Abschnitt von Paranoic Hardening hat seine eigene Schaltfläche, Autologout der Administratoren speichern. Kreuz „Aktivieren“ an, um inaktive Administratoren abzumelden. Stell dann das „Inaktivitäts-Timeout (Sekunden)“ ein. Blockiert der Browser localStorage (zum Beispiel im privaten Modus), greift die Prüfung nie, und du wirst nicht abgemeldet.

Der Standardwert ist 900, das sind 15 Minuten. Das Minimum ist 60, das Maximum 86400. Schreibst du eine Zahl außerhalb der Grenzen, bringt das Plugin sie auf den nächsten erlaubten Wert. Zum Beispiel wird 30 zu 60. Der Hinweis bleibt grün, lies also die Zahl im Feld nach dem Speichern erneut.

Abgemeldet werden nur Benutzer mit der Berechtigung manage_options. Redakteure und Autoren werden nicht berührt. Die Inaktivität wird im Browser gemessen: Maus, Tastatur, Scrollen und Berührung zählen. Die Sitzung schließt wie mit „Abmelden“, und nicht gespeicherte Änderungen in einem offenen Formular gehen verloren.

Empfohlene Aktivierungsreihenfolge

1. Öffne das Panel über https.
2. Aktiviere X-Content-Type-Options, speichere und klick auf „Jetzt prüfen“.
3. Aktiviere Referrer-Policy, speichere und prüfe.
4. Prüfe, dass keine Website deine einbettet, dann aktiviere X-Frame-Options, speichere und prüfe.
5. Aktiviere Autologout mit einem großzügigen Timeout, zum Beispiel 1800. Verringere es erst nach einigen Tagen.
6. Erwäge zuletzt HSTS, ohne includeSubDomains und ohne Preload.

Aktiviere eine Option nach der anderen. Geht etwas kaputt, weißt du sofort, welche es war.

Das Risiko von HSTS, includeSubDomains und Preload

Achtung: HSTS lässt sich nicht von der Website aus rückgängig machen. Nimmst du das Häkchen weg, hört das Plugin auf, den Header zu senden, aber Browser, die ihn schon erhalten haben, erinnern sich bis zum Ablauf. Das Plugin sendet nie max-age=0, hat also kein „Abbrechen“. Das sagt auch das Banner des Reiters: Die Wirkung kann Wochen oder Monate sichtbar bleiben.

Mit aktivem HSTS lehnt der Browser jede nicht-https-Verbindung zur Domain ab. Läuft das Zertifikat ab oder bricht es, zeigt der Browser nicht mehr einmal den Hinweis „trotzdem fortfahren“. Die Website bleibt für diesen Browser unerreichbar.

• includeSubDomains weitet die Regel auf alle Subdomains aus. Eine einzige Subdomain ohne gültiges https, auch eine Test- oder zukünftige, wird für jeden unerreichbar, der die Website schon besucht hat. Aktiviere es nur, wenn alle Subdomains https sind und bleiben.
• Preload fügt dem Header nur das Flag preload hinzu. Allein trägt es die Website nicht ein: Die Übermittlung an die Browser-Liste erfolgt von Hand auf hstspreload.org. Die Liste steckt in den Browsern, und das Entfernen dauert Wochen. Betrachte Preload als endgültige Entscheidung.

Speichere immer von der https-Version des Panels aus. Deaktivierte Kästchen werden vom Browser nicht gesendet: Speicherst du von einer http-Seite aus, schalten sich HSTS und seine Unteroptionen aus.

Was im Hintergrund passiert

Die Einstellungen von Paranoic Hardening sind WordPress-Optionen, keine Serverregeln. Der Autologout druckt ein Skript nur in den Verwaltungsseiten. Das Skript speichert die letzte Aktivität im localStorage des Browsers und prüft alle 5 Sekunden das Timeout. Beim Ablauf bittet es admin-ajax.php, die Abmeldung auszuführen, und bringt dich zur Login-Seite. Das Speichern landet im Aktivitätsprotokoll nur, wenn du etwas geändert hast.

Wenn etwas nicht funktioniert

• Der Kasten ist nach „Jetzt prüfen“ rot: Ein Proxy, eine CDN oder ein anderes Plugin entfernt die Header. Prüf ihre Konfiguration.
• Eine Partner-Website zeigt deine Seiten nicht mehr: Nimm das Häkchen bei X-Frame-Options weg und speichere.
• Du schaffst es nicht, HSTS zu aktivieren: Öffne das Panel erneut mit der https-Adresse.
• Um die Header von Hand zu prüfen, kannst du die Entwicklertools des Browsers oder curl -I auf die https-Adresse der Website nutzen.

Um besser zu verstehen, wie HSTS funktioniert, lies die Seite Strict-Transport-Security bei MDN. Sie erklärt max-age, includeSubDomains und preload präzise.

Vorheriges Kapitel: Reiter Test: prüfen, ob die Schutzmaßnahmen funktionieren. Nächstes Kapitel: Benutzerregistrierung: wer Konten anlegen darf. Für das allgemeine Verzeichnis geh zu Kapitel 1 des Handbuchs.

The post Paranoic Hardening: HTTP-Header, HSTS und Autologout first appeared on Matteo Cisilino.

Wo du den Sicherheitstest WordPress findest

Öffne Einstellungen > Cisilino Site Defense Network (Punkt 1 im Bild). Klicke auf den Reiter Test (Punkt 2). Du findest zwei Kästen:

• Punkt 3: „Prüfung der PHP-Ausführungsblockade in uploads“.
• Punkt 4: „Integrität der Plugin-Dateien“.

Nach jeder Schaltfläche führt dich die Website zum Reiter Allgemein zurück, mit einem Hinweis oben. Das Ergebnis steht aber im Reiter Test. Öffne ihn erneut, um es zu lesen.

Prüfung der PHP-Ausführungsblockade in uploads

Dieser Kasten prüft die Regel „PHP-Ausführung in wp-content/uploads blockieren“ aus dem Reiter Hardening / IDS, beschrieben im Kapitel Hardening / IDS. Der Text erklärt, dass es der einzige Weg ist, zu wissen, ob die Regel auf dieser Website wirklich wirksam ist. Ein deaktiviertes AllowOverride oder eine spezifischere Server-Blockade könnten sie nutzlos machen, ohne das zu melden.

Wie man es benutzt

1. Aktiviere im Reiter Hardening / IDS die Regel und klicke auf „Hardening-Regeln speichern“.
2. Öffne den Reiter Test.
3. Klicke im Kasten „Prüfung der PHP-Ausführungsblockade in uploads“ auf „Jetzt prüfen“.
4. Kehr zum Reiter Test zurück und lies das Ergebnis, mit der Zeile „Letzter Test:“ und dem Datum.

Ist die Regel nicht aktiv und gespeichert, ist die Schaltfläche deaktiviert. Der Kasten zeigt: „Aktiviere und speichere die Regel „PHP-Ausführung in wp-content/uploads blockieren“ im Reiter Hardening / IDS, bevor du den Test ausführen kannst.“.

Was der Test macht

Das Plugin schreibt in uploads eine kleine Test-.php-Datei. Es ruft sie per HTTP ab, mit einem Limit von 10 Sekunden. Danach löscht es sie sofort, in jedem Fall. Die Datei enthält nur eine Kontrollausgabe.

Wie man das Ergebnis liest

• Grün: „Blockade wirksam: Die Anfrage an die Testdatei erhielt N.“. Die Zahl ist 403 oder 404.
• Rot: „ACHTUNG: Die PHP-Testdatei wurde AUSGEFÜHRT (Antwort N).“ Die Regel blockiert nichts. Die Meldung schlägt vor, zu prüfen, ob AllowOverride .htaccess in diesem Ordner erlaubt und ob keine spezifischere <Directory>-Blockade existiert.
• Gelb: „Ergebnis unklar (Antwort N, Inhalt nicht erkannt): manuell mit einer direkten Anfrage an die Website prüfen.“.
• Blau: „Regel deaktiviert: aktiviere und speichere sie, bevor du den Test ausführst.“.
• Rot, für Fehler: „Uploads-Ordner konnte nicht bestimmt werden.“, „Testdatei konnte nicht in uploads geschrieben werden (Rechte?): Test nicht ausgeführt.“ oder „Prüfanfrage fehlgeschlagen“, mit dem Grund.

Achtung: Kann sich die Website nicht selbst erreichen, zum Beispiel wegen einer Firewall, eines HTTP-Passworts oder eines lokalen DNS, ergibt der Test einen Fehler oder ein unklares Ergebnis. Ein 404 zählt als Blockade, kann aber auch andere Gründe haben. Der Test prüft nur den Standardordner uploads. Für wenige Sekunden existiert eine .php-Datei in uploads: Funktioniert die Blockade nicht, kann sie ausgeführt werden, enthält aber nur eine Ausgabe.

Integrität der Plugin-Dateien

Das ist der zweite Teil des Sicherheitstest WordPress. Der zweite Kasten vergleicht die MD5-Hashes der .php-Dateien des Plugins mit den erwarteten. Er sucht geänderte, fehlende oder hinzugefügte Dateien. Die Prüfung startet von selbst einmal täglich. Die Schaltfläche „Jetzt prüfen“ führt sie sofort aus.

Der Kasten nennt eine feste Grenze: Wer schon Schreibzugriff auf die Dateien hat, kann auch die Hashes neu schreiben oder die Prüfung ausschalten. Es ist ein Detektor für Manipulationen, keine Barriere.

Wie man es benutzt

1. Öffne den Reiter Test.
2. Klicke im Kasten „Integrität der Plugin-Dateien“ auf „Jetzt prüfen“.
3. Lies den Hinweis: „Integritätsprüfung durchgeführt: das Ergebnis steht im Kasten „Integrität der Plugin-Dateien“.“.
4. Öffne den Reiter Test erneut und lies den Kasten.

Wie man das Ergebnis liest

Grün: „Alle N geprüften Dateien stimmen überein. Letzte Prüfung: Datum.“. Ist die Referenz eine Momentaufnahme, fügt der Kasten hinzu, dass er spätere Änderungen erkennt, nicht ein bei der Installation schon kompromittiertes Plugin. Rot: „ACHTUNG: Die Plugin-Dateien stimmen nicht mit den erwarteten überein.“, mit den Listen „Geändert“, „Fehlend“ und „Unerwartet“. Gelb: „Keine Referenz verfügbar“. In diesem Fall aktiviere das Plugin erneut.

Die manuelle Schaltfläche schreibt nicht ins Aktivitätsprotokoll. Das tut nur die geplante Prüfung, und nur wenn sie ein Problem findet oder wenn die Dateien nach einem Alarm wieder in Ordnung sind. Für die Details lies das Kapitel Überwachung der Uploads und Integritätsprüfung.

Achtung: Hast du eine Plugin-Datei von Hand geändert, ist der rote Alarm normal. Hast du das nicht getan, behandle die Website als potenziell kompromittiert: Installiere das Plugin aus einer zuverlässigen Kopie neu und prüfe den Rest der Installation.

Wenn etwas nicht funktioniert

Wiederhole den Sicherheitstest WordPress nach jeder Korrektur. Ergibt der PHP-Test Rot, schützt die Regel nicht. Frag dein Hosting, ob .htaccess aktiviert ist. Liest der Server .htaccess nicht, zum Beispiel bei nginx, hat die Regel keine Wirkung. Wiederhole den Test nach jeder Korrektur. Ein 403 ist die Antwort, die du sehen willst: Die MDN-Seite zum Statuscode 403 erklärt, was das bedeutet.

Vorheriges Kapitel: Überwachung der Uploads und Integritätsprüfung. Nächstes Kapitel: Paranoic Hardening: Sicherheitsheader und Administratorsitzung. Für das Kapitelverzeichnis geh zur Einführung des Handbuchs zurück.

The post Sicherheitstest WordPress: der Reiter Test von CSDN first appeared on Matteo Cisilino.

Wo du es findest

Achtung auf die Stelle: Das Formular steht nicht im Reiter „Hardening / IDS“. Öffne Einstellungen > Cisilino Site Defense Network (Punkt 1), bleib im Reiter Allgemein (Punkt 2) und scroll bis ganz nach unten. Nach der Whitelist findest du den Abschnitt „Überwachung der Datei-Uploads“ (Punkt 3). Die Integritätsprüfung liest du dagegen im Reiter Test, erklärt im Kapitel Reiter Test.

Wozu die Upload-Überwachung WordPress dient

Der Abschnitt sagt: „Zeichnet die auf der Website hochgeladenen Dateien auf, auch jene, die nicht über die Mediathek laufen: Plugin-Formulare, admin-ajax-Endpunkte, beliebige Uploads eines Themes.“ Von dort dringt die meiste Webshell ein. Ein Protokoll, das nur die Mediathek betrachtet, sieht sie nicht.

Wie man es benutzt

1. Öffne den Reiter Allgemein und scroll zu „Überwachung der Datei-Uploads“.
2. Kontrolliere die Zeile „Überwachung“: „Datei-Uploads protokollieren“.
3. Kontrolliere die Zeile „Blockade ausführbarer Dateien“: „Uploads mit ausführbarer Erweiterung ablehnen (.php, .phtml, .phar, .sh, .htaccess…)“.
4. Klicke auf „Upload-Überwachung speichern“.
5. Lies den Hinweis: „Einstellungen der Upload-Überwachung gespeichert.“.

Datei-Uploads protokollieren

Diese Option ist standardmäßig aktiv. Die Ereignisse landen in der Gruppe „Datei-Uploads“ des Aktivitätsprotokolls. Bei einer Anfrage ohne Datei ist der Aufwand null. Das Plugin notiert jede Anfrage, die eine Datei enthält, mit dem Feld und der Adresse, die sie empfangen hat. Die Aktionen, die du im Protokoll siehst, sind:

• „Datei in einer POST-Anfrage empfangen“.
• „Datei hochgeladen“.
• „ACHTUNG: potenziell ausführbare Datei hochgeladen“.
• „Upload BLOCKIERT“.

Das lokale Protokoll hält höchstens 500 Zeilen, falls du die Obergrenze in den Einstellungen des Aktivitätsprotokolls nicht änderst. Wie man es liest, erklärt das Kapitel Aktivitätsprotokoll.

Blockade ausführbarer Dateien

Diese Option ist standardmäßig ausgeschaltet. Sie funktioniert nur, wenn auch „Datei-Uploads protokollieren“ aktiv ist: Bei ausgeschalteter Überwachung tut die Blockade nichts, auch wenn das Kästchen angekreuzt ist. Schaltest du sie ein, lehnt WordPress die Datei mit der Meldung ab: „Dateityp auf dieser Website nicht erlaubt (Cisilino Site Defense Network: Upload ausführbarer Dateien blockiert).“ Die Prüfung erkennt auch doppelte Erweiterungen, wie bild.php.jpg.

Als gefährlich gelten die Erweiterungen: php, php3, php4, php5, php7, php8, phtml, phps, phar, pht, shtml, cgi, pl, py, rb, sh, bash, htaccess, htpasswd, jsp, asp, aspx, exe, so, dll, ini, svg und svgz.

Achtung: Die Liste blockiert auch .svg, also lassen sich Logos im SVG-Format nicht mehr hochladen. Sie blockiert auch .ini, .py, .exe und .dll, die in Anhängen und Paketen vorkommen. Das Plugin betrachtet alle Teile nach dem ersten Punkt. Ein Name wie archiv.pl.zip wird deshalb abgelehnt. Die Blockade gilt nur für von WordPress verwaltete Uploads (Filter wp_handle_upload_prefilter). Ein Plugin, das die Datei selbst speichert, wird protokolliert („Datei in einer POST-Anfrage empfangen“), aber nicht gestoppt. Wer direkt auf die Festplatte schreibt, ohne eine Anfrage mit Datei, hinterlässt in diesem Protokoll keine Spur.

Die Integritätsprüfung

Anders als bei der Upload-Überwachung WordPress betrachtest du hier nicht neue Uploads, sondern bereits vorhandene Dateien. Das Plugin vergleicht die MD5-Hashes seiner .php-Dateien mit den erwarteten. Es sucht geänderte, fehlende oder hinzugefügte Dateien. Es schließt die Ordner tests und dist aus. Dateien, die kein PHP sind, werden nicht geprüft.

Die Prüfung läuft einmal täglich, über das Planungssystem von WordPress. Hat die Website wenige Besuche, kann sie sich verschieben. Die Referenz ist die Datei checksums.json im Plugin-Ordner, falls vorhanden. Andernfalls nutzt das Plugin eine bei der Aktivierung und bei jedem Versionswechsel erstellte Momentaufnahme der Dateien.

Wie man das Ergebnis liest

Du findest es im Reiter Test, im Kasten „Integrität der Plugin-Dateien“, wo auch die Schaltfläche „Jetzt prüfen“ ist, um die Prüfung sofort zu starten. Es gibt vier Fälle:

• „Noch keine Prüfung durchgeführt.“, wenn sie nie gestartet ist.
• Grüner Kasten: „Alle N geprüften Dateien stimmen überein. Letzte Prüfung: Datum.“.
• Gelber Kasten: „Keine Referenz verfügbar: Prüfung nicht möglich. Aktiviere das Plugin erneut, um eine neue Datei-Momentaufnahme zu erstellen.“.
• Roter Kasten: „ACHTUNG: Die Plugin-Dateien stimmen nicht mit den erwarteten überein.“, mit drei Listen: „Geändert“, „Fehlend“, „Unerwartet“.

In der Liste erscheinen höchstens 15 Namen. Siehst du Rot und hast die Dateien nicht selbst angefasst, sagt dir das Plugin, die Website als potenziell kompromittiert zu behandeln. Installiere das Plugin aus einer zuverlässigen Kopie neu und prüfe den Rest der Installation.

Ist die Referenz die Momentaufnahme, schreibt der grüne Kasten das. Dieser Vergleich findet spätere Änderungen, nicht ein bei der Installation schon kompromittiertes Plugin.

Achtung: Die Integrität ist ein Detektor, keine Barriere. Wer schon auf die Dateien schreiben kann, kann auch die Hashes neu schreiben oder die Prüfung ausschalten. Von Hand gemachte Änderungen oder ein halb abgeschlossener Upload erzeugen einen roten Alarm.

Was im Hintergrund passiert

Die Upload-Überwachung WordPress und die Integrität nutzen dasselbe Protokoll. Die tägliche Prüfung schreibt nur in zwei Fällen ins Aktivitätsprotokoll: wenn sie ein Problem findet und wenn nach einem Problem wieder alles in Ordnung ist. Läuft alles gut, schreibt sie nichts. Das Protokoll wird dann an das Panel gesendet, damit eine Kopie des Alarms außerhalb deines Servers liegt.

Wenn etwas nicht funktioniert

Die Upload-Überwachung WordPress bleibt auch mit ausgeschalteter Blockade nützlich. Hört ein legitimes Plugin auf, Dateien hochzuladen, schalte „Blockade ausführbarer Dateien“ aus und versuch es erneut. Um zu verstehen, welche Uploads auf der Website ankommen, lass die Überwachung aktiv und sieh ins Protokoll. Für die Regeln zu Dateien in uploads sieh auch das Kapitel Hardening / IDS.

Das Risiko, das hier verringert werden soll, beschreibt OWASP: Lies die Seite zum Upload ohne Einschränkungen, nützlich um zu verstehen, warum Uploads eine Schwachstelle sind.

Vorheriges Kapitel: Hardening / IDS: die Regeln für .htaccess. Nächstes Kapitel: Reiter Test: prüfen, ob die Schutzmaßnahmen funktionieren. Verzeichnis: Einführung des Handbuchs.

The post Upload-Überwachung WordPress und Integritätsprüfung first appeared on Matteo Cisilino.

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.

The post WordPress Hardening: die Regeln für .htaccess first appeared on Matteo Cisilino.