Der Absender verwendet einen allgemeinen Namen. Auf den ersten Blick nichts Verdächtiges. Der Betreff ist harmlos: „Zimmerverfügbarkeit vom 10. bis 12. November“. Der Text ist in recht natürlichem Deutsch geschrieben. Er hat ein paar kleine Unstimmigkeiten, die ein Muttersprachler bemerken würde, aber nichts, das sofort Alarm schlägt. Der Absender schreibt, er wolle buchen. Er bittet um Bestätigung der Verfügbarkeit. Dann fügt er ein Detail hinzu, das harmlos wirkt: Er behauptet, eine Kopie seines Reisepasses angehängt zu haben, „um die Buchung zu erleichtern“. Dazu kommt ein kleines zeitliches Detail: Er sei ab dem 9. unterwegs und hätte deshalb gern schon vorher alles bestätigt.

Dieser Satz, „ich bin unterwegs“, ist ein präziser psychologischer Hebel. Es ist keine aggressive Dringlichkeit. Es wird kein Geld sofort gefordert. Er schafft nur einen plausiblen Grund, sich zu beeilen, zu antworten, bevor man zu lange nachdenkt. Ich habe den Screenshot dieser E-Mail gesehen, mit dem aus Sicherheitsgründen unkenntlich gemachten Link. Ich finde ihn ein fast lehrbuchmäßiges Beispiel dafür, wie ein wirksamer Versuch von Phishing im Gastgewerbe aufgebaut wird: freundlich, glaubwürdig, mit einer Prise kalkulierter Dringlichkeit.

Wie Phishing im Gastgewerbe in zwei Schritten funktioniert

Der Mechanismus hat zwei klar getrennte Phasen. Es lohnt sich, beide zu verstehen, denn von außen wirken sie banal, funktionieren aber trotzdem. Die erste Phase ist die E-Mail. Sie enthält einen verkürzten Link, der über einen Redirector läuft: einen Dienst, der das eigentliche Ziel hinter einer kurzen Adresse verbirgt. Klickt man darauf, sieht man nicht sofort, wo man eigentlich landet. Das ist schon die erste kleine, aber wirksame Täuschung.

Die zweite Phase ist die Zielseite. Es handelt sich um einen Bildschirm, der sich als Bestätigungs- oder Zahlungsvorgang ausgibt. Grafisch erinnert er an eine echte Plattform, manchmal gut genug, um selbst erfahrene Branchenkenner zu täuschen. Dort entsteht der eigentliche Schaden. Der Betreiber der Unterkunft, überzeugt, die Verfügbarkeit prüfen oder die Buchung bestätigen zu müssen, gibt seine eigenen Zugangsdaten ein. Das können die Daten des Extranets von Booking oder Airbnb sein. Oder die des eigenen E-Mail-Postfachs, oder des Verwaltungspanels der Website. Von diesem Moment an liegen die Zugangsdaten bereits in den Händen des Absenders. Der Rest passiert, aus Sicht des Betroffenen, erst später, wenn es zu spät ist, um etwas zurückzudrehen.

Warum Strukturbetreiber ein bequemes Ziel sind

Wer in einer Unterkunft arbeitet, erhält jede Woche Dutzende ähnlicher Anfragen. E-Mails von Gästen, Fragen zur Verfügbarkeit, Anfragen zur Last-Minute-Bestätigung. Es ist ein ständiger Strom, oft in Eile bearbeitet, zwischen einem Check-in und dem nächsten. Eine zusätzliche Nachricht, höflich und plausibel, fügt sich gut in diesen Strom ein. Sie fällt nicht auf. Die Schwachstelle ist nicht die Technik des Betreibers. Es ist seine begrenzte Zeit und die Gewohnheit, schnell auf jemanden zu antworten, der wie ein echter Gast wirkt. Deshalb funktioniert Phishing im Gastgewerbe so gut: Es zielt nicht auf ein IT-System, sondern auf eine beschäftigte Person.

Die Red Flags, die man erkennen sollte

Es gibt konkrete Signale. Keines allein beweist einen Betrug, aber zusammen erzählen sie eine klare Geschichte. Der Kontakt kommt per direkter E-Mail, nicht über den offiziellen Kanal der Plattform. Booking und Airbnb haben interne Nachrichtensysteme, und ein echter Gast nutzt sie fast immer. Der Link ist verkürzt oder maskiert, sodass man beim Lesen der Adresse nicht erkennt, wohin er führt. Die Nachricht bittet darum, die Verfügbarkeit „zu prüfen“, indem man auf einen Link klickt. Eigentlich sollte der Betreiber einfach im eigenen Panel nachsehen und die Adresse wie immer von Hand eingeben. Der Ton ist freundlich, fast fürsorglich. Die Dringlichkeit ist dosiert: Sie macht keine Angst, drängt aber trotzdem dazu, schnell zu handeln, bevor man zu lange nachdenkt.

Warum ich das unter „Zwischen Stuhl und Tastatur“ eingeordnet habe

Ich habe diese Kategorie auf der Website eigens für Fälle wie diesen eröffnet. „Zwischen Stuhl und Tastatur“ ist ein Scherz, den alle kennen, die in der IT-Sicherheit arbeiten. Er bezeichnet genau die Stelle, an der der Schaden fast immer entsteht: die Person vor dem Bildschirm, nicht die Software. Die Buchungsplattform trägt in diesem konkreten Fall keine Schuld. Das Problem ist kein Bug von Booking oder Airbnb. Es ist der Moment, in dem ein Mensch, vielleicht in Eile, auf einen Link klickt, den er nicht hätte anklicken sollen. Das zu verstehen hilft, sich besser zu schützen. Ein Antivirenprogramm allein reicht nicht. Es braucht die Gewohnheit, jedes Mal eine Sekunde innezuhalten, bevor man klickt.

Wenn die Zugangsdaten trotzdem in falsche Hände geraten, sollte man prüfen, ob man sie sofort ändert, überall, wo sie verwendet werden. Ich habe darüber geschrieben, als ich von der Rotation der Datenbank-Zugangsdaten nach einem Sicherheitsvorfall erzählt habe. Der technische Kontext ist anders, aber das Prinzip bleibt dasselbe.

Was man tun kann, um die eigene Unterkunft zu schützen

Die erste Regel ist einfach, muss aber oft wiederholt werden: niemals Zugangsdaten eingeben, indem man einem per E-Mail erhaltenen Link folgt, auch wenn es dringend erscheint. Schreibt jemand, er wolle buchen, prüft man das im eigenen Panel. Man gibt die Adresse von Hand ein, statt einem Link eines Unbekannten zu folgen. Die zweite Regel betrifft die Zwei-Faktor-Authentifizierung. Sie sollte auf jedem wichtigen Konto aktiviert werden: Extranet der Plattform, E-Mail-Postfach, Website-Panel. Selbst wenn die Zugangsdaten gestohlen werden, blockiert ein zweiter Faktor den Zugriff in den meisten Fällen trotzdem. Die dritte Regel ist die Meldung. Jede verdächtige Nachricht sollte der Plattform gemeldet werden, die diese Daten nutzt, um weitere ähnliche Versuche zu blockieren. Es ist kein Zufall, dass der Umgang mit solchen Fällen einer der Gründe für die europäische Untersuchung ist. Das Problem von Phishing im Gastgewerbe betrifft auch die Plattformen, nicht nur die einzelnen Betreiber.

Wer die weitere Entwicklung verfolgen möchte, kann die Rekonstruktion der italienischen Nachrichtenagentur AGI zur Untersuchung der Kommission gegen Booking.com lesen. Sie fasst gut zusammen, was passiert. Und warum es auch kleine Unterkünfte betrifft, nicht nur die großen Ketten.

Wenn du schon geklickt oder Daten eingegeben hast

Ist es bereits passiert, sollte man schnell handeln. Ändere sofort das Passwort des betroffenen Kontos. Ändere es auch überall, wo dasselbe Passwort wiederverwendet wurde: Das ist ein häufiger Fehler, und wer Zugangsdaten stiehlt, weiß das gut. Aktiviere die Zwei-Faktor-Authentifizierung, falls noch nicht geschehen. Prüfe den Anmeldeverlauf des Kontos. Suche nach Sitzungen oder Geräten, die du nicht erkennst. Informiere die Plattform, die eigene Verfahren für kompromittierte Konten hat. Hattest du der E-Mail echte Dokumente angehängt, behalte sie im Auge: Ein gestohlenes Ausweisdokument kann auch anderswo missbraucht werden, nicht nur für weitere Betrugsfälle im Gastgewerbe.

Der Fall, den ich gesehen habe, hat keinen Schaden angerichtet. Wer ihn erhalten hat, hat einen Moment vor dem Klicken gezögert und es mir gemeldet. Das hat gereicht. Technik hilft, Spamfilter helfen, aber am Ende macht immer die Person den Unterschied, die entscheidet, ob sie klickt oder nicht. Das Problem von Phishing im Gastgewerbe liegt fast immer zwischen Stuhl und Tastatur.

The post Phishing im Gastgewerbe: So erkenne ich die Betrugsmail first appeared on Matteo Cisilino.

Wann hört Rotation auf, optional zu sein?

Ein paar Szenarien bringen das Thema regelmäßig genug zur Sprache, dass ich einen Rotationsplan dafür bereithalte. Ich improvisiere lieber keinen unter Druck.

Ein Plugin oder CMS auf einer gehosteten Website wird kompromittiert. Über einen echten Fall auf dieser Art von Server habe ich hier geschrieben: PHP2Shell: So habe ich meine Server bis zum Patch geschützt, eine PHP-Schwachstelle, die einem Angreifer erlaubte, eine Webshell abzulegen, bevor es einen Patch gab. Sobald eine Webshell unter einem Hosting-Benutzer läuft, kann sie oft die eigene config.inc.php dieser Website lesen. Auf einer gemeinsam genutzten ISPConfig-Box liegt diese Datei direkt neben den Zugangsdaten für die eigene Datenbank des Kontrollpanels. Nicht nur das eine Zugangsdatum, hinter dem der Angreifer eigentlich her war.

Eine Konfigurationsdatei landet irgendwo, wo sie nicht hingehört. Ein Backup-Archiv, das in einem öffentlichen Ordner liegen bleibt. Ein Repository, das mit einer versehentlichen Datei gepusht wird. Ein Log, das lesbarer ist, als es sein sollte. config.inc.php und mysql_clientdb.conf haben an keinem dieser Orte etwas zu suchen. Fehler passieren trotzdem, auch mir.

Ein Systemadministrator verlässt das Team. Wie einvernehmlich der Abschied auch war, gemeinsam genutzte Datenbank-Zugangsdaten, die diese Person einmal hatte, sind Zugangsdaten, denen ich nicht mehr vollständig vertraue. Vertrauen wird nicht automatisch übertragen, wenn jemand zur Tür hinausgeht.

Ein vermuteter Einbruch, selbst ein unbestätigter. Dieser Fall lässt sich am schwersten jemandem erklären, der noch nie einen Server unter Angriffsverdacht betrieben hat. Man wartet nicht auf einen Beweis, bevor man handelt. Man geht von einer Kompromittierung aus und rotiert. Eine unnötige Rotation kostet einen Nachmittag. Eine ausgelassene, nach einem echten Einbruch, kann jede Website kosten, die der Server hostet.

Warum ISPConfig-Zugangsdaten rotieren von Hand so fehleranfällig ist

Als ich die Datenbank-Zugangsdaten von ISPConfig zum ersten Mal von Hand rotiert habe, habe ich unterschätzt, wie viele Dateien betroffen sind. Sie müssen alle zusammen geändert werden, sonst geht ein paar Stunden später irgendwo leise etwas kaputt.

Es gibt config.inc.php auf der Server-Seite und eine zweite Kopie auf der Interface-Seite. Beide müssen dieselben neuen Werte bekommen. Es gibt mysql_clientdb.conf, das ISPConfig ausliest, um die eigene Datenbank jeder gehosteten Website zu verwalten, nicht nur seine eigene Haushaltsführung. Dovecot, Pure-FTPd und Postfix führen jeweils eine eigene Kopie einiger dieser Zugangsdaten. Mail und FTP können still aufhören, sich zu authentifizieren, wenn man den Datenbank-Benutzer aktualisiert und dabei nur eine dieser drei Dienste vergisst.

Dann gibt es die Master/Slave-Topologie, die einige meiner Setups verwenden. Ein Slave-Knoten authentifiziert sich über das Netzwerk an der Datenbank seines Masters, mit einem separaten Passwort. Dieses Passwort muss auf dem Master selbst rotiert werden, nicht nur lokal. Bringt man die Reihenfolge durcheinander, kann sich ein Slave vom eigenen Master aussperren, von dem er eigentlich replizieren soll.

Konzeptionell ist nichts davon schwierig. Es sind nur viele Dateien. Mehrere Dienste, die in sinnvoller Reihenfolge neu gestartet werden müssen. Fast keine Toleranz für einen Tippfehler, besonders wenn man das unter Druck macht, gleich nachdem man etwas gefunden hat, das man nicht finden wollte. Genau diese Kombination ist der Grund, warum sich ISPConfig-Zugangsdaten rotieren von Hand immer riskanter anfühlte, als die Aufgabe selbst sein sollte. Deshalb habe ich reset_DB_password.sh geschrieben, nachdem ich das Problem mehr als einmal selbst durchgemacht hatte.

Was reset_DB_password.sh tatsächlich macht

reset_DB_password.sh erkennt, ob der Knoten Standalone, Master oder Slave ist. Dann führt es nur die Phasen aus, die diese Rolle benötigt. Genau so, wie man ISPConfig-Zugangsdaten rotieren sollte: in der richtigen Reihenfolge, für die richtige Rolle.

Phase A rotiert das lokale MySQL-Root-Passwort. Das ist das Passwort, mit dem ISPConfig selbst die Datenbank jeder gehosteten Website verwaltet. Das Skript aktualisiert mysql_clientdb.conf entsprechend dem neuen Wert.

Phase B rotiert das Passwort des ispconfig-Kontrollbenutzers. Sie aktualisiert config.inc.php sowohl auf der Server- als auch auf der Interface-Seite. Danach aktualisiert sie die passenden Zugangsdaten in Dovecot, Pure-FTPd und Postfix, damit Mail und FTP weiter authentifizieren, ohne einen separaten manuellen Durchgang durch drei weitere Konfigurationsdateien.

Phase C läuft nur auf einem Slave. Sie verbindet sich remote mit der Datenbank des Masters. Dort rotiert sie das Passwort des Slave-Benutzers und aktualisiert anschließend lokal dbmaster_password, damit die Replikation weiter korrekt gegen den neuen Wert authentifiziert.

Nach Phase B bietet das Skript an, Dovecot, Pure-FTPd und Postfix für einen neu zu starten. Ich sage fast immer Ja. Wenn man ISPConfig-Zugangsdaten rotiert und dabei einen Mail-Dienst mit dem alten Passwort weiterlaufen lässt, ist man nicht fertig, man ist nur still kaputt. Der Neustart im gleichen Durchlauf, direkt nachdem sich die Konfigurationsdateien geändert haben, hält das Ganze in einem kurzen Wartungsfenster statt in drei separaten, die man später entdeckt.

Backups, bevor sich irgendetwas ändert

Bevor es auch nur eine Datei anfasst, erstellt das Skript eine vollständige rsync-Kopie von /usr/local/ispconfig/ in einem zeitgestempelten Ordner. Es versucht außerdem einen nicht blockierenden mysqldump der Datenbanken mysql und dbispconfig. Nicht blockierend mit Absicht: Ich schließe lieber eine Rotation der Datenbank-Zugangsdaten ab, als auf einen Dump zu warten, der aus irgendeinem unzusammenhängenden Grund hängen bleibt. Jede Konfigurationsdatei, die bearbeitet wird, bekommt erst ihre eigene .bak-Kopie, bevor auch nur eine Zeichenkette darin ersetzt wird.

Nichts davon ersetzt eine unabhängige Backup-Strategie. Ich mache weiterhin ein separates Snapshot oder ein vollständiges Backup, bevor ich das auf einem Server ausführe, der wirklich wichtig ist. Der eigene Disclaimer des Skripts sagt dasselbe, nur direkter, als ich es gerade getan habe.

Erst der Trockenlauf, jedes Mal

Jede Phase fragt nach Bestätigung, bevor irgendetwas geändert wird. –dry-run simuliert einen kompletten Durchlauf, ohne eine einzige Datei zu berühren. Ich benutze dry-run zuerst auf jedem Server, jedes Mal. Auch auf solchen, auf denen ich schon einmal Zugangsdaten rotiert habe und die ich zu kennen glaube. –skip-local-root überspringt Phase A, für den Fall, dass nur das Passwort des Kontrollbenutzers rotiert werden muss. –role=master oder –role=slave überschreibt die automatische Erkennung, für den seltenen Fall, dass sie die Topologie eines Servers nicht selbst korrekt erkennt.

Die erzeugten Passwörter sind 32 Zeichen lang, nur Buchstaben und Ziffern. Lang genug, um Raten zu widerstehen. Einfach genug, dass die Parser von MySQL und PHP niemals über ein vereinzeltes Sonderzeichen in einer Verbindungszeichenfolge stolpern. Ich habe das Skript auf ISPConfig 3.3.1p1 getestet. Gegen ältere oder neuere Zweige habe ich es nicht laufen lassen. Ich würde dort kein identisches Verhalten annehmen, ohne es selbst vorher zu prüfen.

Die Rolle eines Knotens ist nicht immer auf den ersten Blick offensichtlich, besonders auf einem Server, den man geerbt und nicht selbst aufgebaut hat. Deshalb gibt es –role, und deshalb lohnt es sich, die Ausgabe des Trockenlaufs beim ersten Mal Zeile für Zeile zu lesen, nicht nur zu überfliegen. Ich bestätige lieber zwei Minuten lang, dass ein Slave wirklich ein Slave ist, als es mitten in der Rotation auf die harte Tour herauszufinden.

Was ich dir sagen würde, bevor du es ausführst

Hinweis: Das Skript wird wie es ist, zu Informationszwecken bereitgestellt. Die Nutzung erfolgt ausschließlich auf eigenes Risiko: Ich übernehme keine Verantwortung für Datenverlust, Ausfallzeiten oder Fehler, die durch falsche Anwendung, Veränderung des Codes oder einen anderen Kontext als den, in dem ich es selbst einsetze, entstehen. Erstelle immer ein unabhängiges Backup oder einen VM-Snapshot, bevor du es in Produktion ausführst, unabhängig davon, was der eigene Backup-Schritt des Skripts bereits für dich erfasst.

Es ist freie Software. Du darfst sie weiterverbreiten und verändern, mit Nennung meines Namens als ursprünglichen Autor. Der Quellcode von reset_DB_password.sh, und der Rest der ispconfig-fast-tools-Sammlung, liegt auf GitHub unter github.com/matteocisilino/ispconfig-fast-tools.

ISPConfig-Zugangsdaten rotieren ist eine Gewohnheit, kein Aufräumjob

Datenbank-Zugangsdaten nach einem bestätigten Einbruch zu rotieren, ist einfach kompetente Reaktion auf einen Sicherheitsvorfall. Die meisten Administratoren würden es tun, ohne dass man es ihnen zweimal sagen muss. Die schwerere Gewohnheit ist, es auch nach einem bloß vermuteten Einbruch zu tun, bevor jemand Beweise hat. Das ist die einzige Version des Plans, die den Schaden tatsächlich begrenzt, solange er noch begrenzbar ist. Ein Skript, das die richtigen Phasen für die Rolle eines Servers ausführt, zuerst eigene Backups erstellt und mich den ganzen Vorgang per Trockenlauf prüfen lässt, bevor irgendetwas Reales berührt wird. Das macht die Gewohnheit praktisch an einem Dienstagabend, statt theoretisch in einem Blogartikel.

ISPConfig, MySQL, PHP, Dovecot, Pure-FTPd, Postfix und die anderen genannten Namen sind Marken ihrer jeweiligen Inhaber. Sie werden hier nur zur Identifikation der Produkte verwendet.

The post Datenbank-Zugangsdaten-Rotation nach einem ISPConfig-Sicherheitsvorfall first appeared on Matteo Cisilino.

Was ist MPTCP, und warum betrifft es auch dich, wenn du es nicht nutzt

Multipath TCP (MPTCP) ist der Standard RFC 8684. Er erweitert das klassische TCP, damit eine einzelne Verbindung gleichzeitig über mehrere Netzwerkpfade laufen kann. Ein Smartphone kann WiFi und Mobilfunk im selben Moment nutzen, für dieselbe Verbindung. Ein Server mit mehreren Schnittstellen kann dasselbe tun, für Redundanz oder um Bandbreite zu summieren. Apple nutzt es produktiv schon seit iOS 7, im Jahr 2013, für Siri: das ist der bekannteste reale Anwendungsfall. Manche Mobilfunkanbieter, zum Beispiel in Südkorea, setzen es für WiFi/LTE-Bonding ein. Mehrere Rechenzentren nutzen es für Multihoming zwischen verschiedenen Uplinks. Im Linux-Mainline-Kernel ist es seit Version 5.6 enthalten.

Der Punkt, der mich die Augenbraue hochziehen ließ, ist ein anderer. Seit Version 1.24 verlangen in Go geschriebene Programme standardmäßig MPTCP für lauschende Sockets. Das Go Security Team hat das am 29. Oktober bestätigt. Gleichzeitig hat es eine unangenehme Warnung ausgesprochen: Der Bug, von dem wir heute sprechen, ist nicht MPTCP-spezifisch. Ein System ohne aktive MPTCP-Listener kann trotzdem ähnlichen Angriffen ausgesetzt sein. Der verwundbare Code liegt im generischen TCP-IPv4-Pfad, nicht in einem optionalen Modul. Man kann MPTCP pro Programm deaktivieren, mit der Variable GODEBUG=multipathtcp=0 zur Laufzeit. Doch das Go Security Team bezeichnet diese Abmilderung als „brüchig“: Ein einziger verbleibender MPTCP-Listener reicht aus, um sie zunichtezumachen. Niemand hat bewiesen, dass jeder funktionierende Exploit tatsächlich von MPTCP abhängt. Deshalb bleibt der MPTCP-Code eine Angriffsfläche, auch wenn du ihn in deinem Stack nie bewusst aktivierst: Es reicht, dass er in den Kernel compiliert und erreichbar ist.

Das MPTCP-Projekt selbst erklärt auf seiner eigenen Seite, dass die wichtigsten aktuellen Linux-Distributionen den Kernel standardmäßig mit MPTCP-Unterstützung compiliert ausliefern (CONFIG_MPTCP=y). Es nennt ausdrücklich Debian, Ubuntu, RHEL und Fedora. Das ist eine Aussage des Projekts selbst, keine unabhängige Überprüfung Distribution für Distribution, aber das Konzept bleibt gültig: Die Unterstützung ist auf Kernel-Ebene aktiviert, nicht „opt-in“ auf Betriebssystemebene. Nur die Aushandlung pro einzelner Verbindung bleibt Aufgabe der Anwendung.

Die Schwachstelle im Linux-Kernel CVE-2026-98432 im Überblick

Das CVE-Team des Linux-Kernels hat CVE-2026-98432 am 15. Oktober 2026 veröffentlicht. Der Upstream-Fix war bereits zehn Tage zuvor angewendet worden, am 5. Oktober. Es kommt häufig vor, dass die Veröffentlichung dem Commit mit einer gewissen Verzögerung folgt. Der CVSS-Score von 9,8 (kritisch) kam erst am 24. Oktober, neun Tage nach der Veröffentlichung der CVE.

Das Problem liegt in der Behandlung des TCP-Handshakes für IPv4, genauer in der Funktion tcp_v4_syn_recv_sock(). Wenn eine Verbindung erstellt wird, werden die IP-Optionen des SYN-Pakets vom wartenden Request-Socket an den neuen Socket übergeben. Zum Beispiel Record Route oder Timestamp, falls der Client sie in einem eigens konstruierten SYN einfügt. Das Problem ist, dass sie per Referenz übergeben werden, nicht per Kopie, und ohne das Lock des Listeners. Laut der technischen Analyse des Patches heißen die betroffenen Strukturen inet_opt und ireq_opt. Eine zweite CPU kann diesen Puffer mit kfree() freigeben, aufgerufen von inet_sock_destruct() oder von tcp_v4_reqsk_destructor(). Währenddessen liest eine erste CPU ihn noch in ip_options_build(), um das SYNACK zu bauen. Es ist ein klassisches Use-after-free, verursacht durch eine Race Condition. Der entsprechende IPv6-Pfad, tcp_v6_syn_recv_sock(), kopiert die Optionen statt sie per Referenz zu übergeben: Er ist von der Haupt-Race nicht betroffen. Es gibt auch einen zweiten Angriffsweg, über die Migration von Request-Sockets: net.ipv4.tcp_migrate_req=1 oder ein eBPF-Programm mit BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Beide sind standardmäßig deaktiviert.

Der Bug ist remote ausnutzbar und erfordert laut Einschätzung des Kernel-Teams weder Authentifizierung noch Benutzerinteraktion. Er ist seit Kernel-Version 4.4 vorhanden. Der Fix stammt von Eric Dumazet, gemeldet von Xinyang Ge von Anthropic. Er verschiebt die Freigabe des Speichers auf die Zeit nach einer RCU-Grace-Period, mit kfree_rcu(): So kann keine CPU mehr einen bereits freigegebenen Puffer lesen. Die korrigierten stabilen Versionen sind 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und die Mainline ab 7.3-rc7.

Widersprüchliche CVSS-Scores: Nicht alle Hersteller sind sich einig

Hier wird die Geschichte komplizierter. Das Kernel-CVE-Team und Ubuntu bewerten die Angriffskomplexität als niedrig und vergeben 9,8 (kritisch). Oracle und SUSE vergeben dagegen 8,1 (wichtig): derselbe CVSS-Vektor, aber hohe Angriffskomplexität. Red Hat hat merkwürdigerweise zwei Bewertungen, die nicht übereinstimmen. Die öffentliche CVE-Seite zeigt „Moderate, 5.9“. Die maschinenlesbare Advisory-Datei, aktualisiert am 29. Oktober, zeigt dagegen „Important, 8.1“, mit hoher Auswirkung auf Vertraulichkeit und Integrität. Am selben Tag hat der interne Bugtracker von Red Hat die Schwere von medium auf high angehoben. Amazon vergibt seinerseits 7,0. Zum Zeitpunkt, an dem ich das schreibe, hat die NVD noch keinen eigenen Score veröffentlicht.

Das sollte man ehrlich sagen. Diese interne Unstimmigkeit bei Red Hat ist kein Detail, das ich selbst hergeleitet habe: Sie wird so vom Originalartikel von The Hacker News berichtet, meiner Hauptquelle für diese Daten. Es ist nicht das erste Mal, dass ein Hersteller für denselben Bug zwei unterschiedliche Zahlen auf unterschiedlichen Kanälen veröffentlicht. Aber hier sagt der Sprung von „moderat“ zu „wichtig“ am selben Tag viel aus. Auch für diejenigen, die den Code schreiben, ist es schwierig, die tatsächliche Ausnutzbarkeit einer Race Condition im Kernel mit Sicherheit einzuschätzen.

Patch-Status: Debian schon korrigiert, andere noch nicht

Das ist der Punkt, der mich am direktesten betrifft: Die Hosting-Umgebungen, die ich verwalte, laufen auf Debian Stable. Und hier sprechen die Fakten klar, ohne dass man etwas betonen müsste: Debian hat diese Schwachstelle im Linux-Kernel bereits korrigiert, sowohl auf trixie als auch auf bookworm. Debian trixie (stable) wurde am 16. Oktober 2026 korrigiert, mit dem Paket linux 6.12.113-1, Advisory DSA-6568-1. Debian 12 (bookworm) wurde in zwei Schritten korrigiert: am 17. und am 22. Oktober 2026, mit linux 6.1.190-1 (Advisory DLA-4841-1) und linux-6.12 6.12.113-1~deb12u1 (Advisory DLA-4850-1). In seiner eigenen Tracking-Tabelle listet Debian für diese CVE keinen eigenen CVSS-Score auf. Es markiert nur den Fix-Status für jedes Release: Das ist die Information, die wirklich zählt, für alle, die entscheiden müssen, ob sie einen Server neu starten.

Es hilft, das mit dem Status anderer weit verbreiteter Distributionen zu vergleichen, um der Sache Gewicht zu geben. Am 30. Oktober hat Red Hat den Status für RHEL 8, 9, 10 und OpenShift 4 aktualisiert. Zuvor war es „fix deferred“ (markiert am 29. Oktober), jetzt ist es „affected“. Kein Veröffentlichungsdatum wurde mitgeteilt. Ubuntu gilt auf allen unterstützten Versionen (22.04, 24.04, 26.04, 26.10) noch als „in Bearbeitung“, ohne Datum. Ubuntu 16.04, 18.04 und 20.04 gelten als verwundbar, ohne dass überhaupt ein Fix aufgelistet ist. SUSE Linux Enterprise Server, von SP4 bis SP7 plus 16.0, befindet sich in derselben Lage. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 und Amazon Linux 2023 sind dagegen schon korrigiert. RHEL 7 ist nicht betroffen: Der verwundbare Codepfad wurde auf dieser Release nie ausgeliefert.

Ich sage das nicht, um Ubuntu oder RHEL schlechtzumachen. Es bleiben seriöse Distributionen mit robusten Sicherheitsprozessen. Ich sage es, weil bei diesem einzelnen Bug, in diesem Zeitfenster, die Fakten so sind: Wer sich auf Hosting mit Debian Stable verlässt, hat den Fix schon installiert. Auf anderen, stark genutzten Distributionen bleibt der Server dagegen für einen unbestimmten Zeitraum exponiert. Das ist ein konkreter, nachprüfbarer Vorteil, wenn man sich die Daten ansieht. Es ist keine Meinung über das Debian-Projekt im Allgemeinen.

Der (berichtete, nicht unabhängig verifizierte) Exploit von Anthropic

Der ungewöhnlichste Teil dieser Geschichte betrifft Anthropic, das Unternehmen, das den Bug als erstes über Xinyang Ge gemeldet hat. Laut Branchenberichten hat eines seiner internen KI-Modelle, nicht öffentlich veröffentlicht, selbstständig einen funktionierenden Root-Exploit gebaut. Ausgehend nur vom Patch und vom Report als Prompt. Der zweistufige Angriff würde so funktionieren. In der ersten Phase lässt die Race den Angreifer zusätzliche Bytes aus der Antwort des Kernels empfangen. Von dort gewinnt er eine Kernel-Adresse, um KASLR auszuhebeln. In der zweiten Phase würde derselbe Bug einen Buffer-Overflow verursachen. Er überschreibt einen Callback-Pointer mit der Adresse eines Payloads, den der Angreifer bereits im Kernel-Speicher platziert hat. Wenn der Kernel diesen Pointer aufruft, führt das Payload einen beliebigen Shell-Befehl als Root aus. Eine verlorene Race würde nur diesen einzelnen Verbindungsversuch scheitern lassen, ohne das System abstürzen zu lassen: Wiederholte Versuche wären also möglich. Im von Anthropic beschriebenen Test: 48 Minuten, um die Kernel-Adresse zu stehlen, weitere 5 Minuten bis zur Befehlsausführung.

Red Hat sagt, dass ein entfernter Angreifer, der einen exponierten TCP-Dienst erreicht, die Race generell auslösen kann. Der von Anthropic beschriebene Root-Exploit hätte jedoch gezielt Server mit einem aktiven Multipath-TCP-Listener angegriffen. Der Beitrag von Anthropic klärt nicht, ob ein Server ohne MPTCP genauso ausnutzbar ist. Weder der CVE-Eintrag noch der Upstream-Fix erwähnen MPTCP an irgendeiner Stelle. Es ist die Fachpresse, keine Primärquelle, die diesen Zusammenhang berichtet: Ich schreibe das deshalb mit der Skepsis, die es verdient, nicht als zu hundert Prozent gesicherte Tatsache. Anthropic hat weder den Exploit-Code veröffentlicht, noch die genaue verwendete Kernel-Version, noch die Konfiguration des Zielservers. Ein anderes Unternehmen, Innora, hat eine Root-Cause-Analyse veröffentlicht, mit einer QEMU-Reproduktionsumgebung. Es hat erklärt, kurzfristig keinen bewaffneten Exploit zu veröffentlichen. Derzeit gibt es keine Beweise für eine tatsächliche Ausnutzung durch Hersteller oder CERTs. Der Bug ist nicht im CISA-KEV-Katalog, laut der von CIRCL Luxemburg aktualisierten Kopie vom 28. Oktober.

Was jetzt auf deinen Servern zu tun ist

Kein Hersteller hat einen offiziell sanktionierten Workaround für diese Schwachstelle im Linux-Kernel veröffentlicht. Red Hat sagt ausdrücklich, dass keine der bisher kursierenden Maßnahmen seinem Standard an Deployment-Einfachheit und Stabilität entspricht. Die primäre Abmilderung bleibt, den korrigierten Kernel einzuspielen und neu zu starten, sobald der Patch für deine Distribution verfügbar ist. Auf Debian ist er das schon. Auf RHEL und Ubuntu noch nicht, zum Zeitpunkt, an dem ich das schreibe.

Als Verteidigung in der Tiefe, nicht als endgültige Lösung, ergeben einige Maßnahmen Sinn. Prüfen, dass net.ipv4.tcp_migrate_req auf 0 gesetzt ist. Kontrollieren, dass keine eBPF-Programme mit BPF_SK_REUSEPORT_SELECT_OR_MIGRATE geladen sind. Eine Filterung eingehender IPv4-Pakete mit Record-Route- oder Timestamp-Optionen erwägen. Abstürze überwachen, die ip_options_build, ip_build_and_send_pkt oder skb_under_panic zitieren. Ein Inventar eventuell exponierter MPTCP-Listener erstellen und vermeiden, sie ohne Grund erreichbar zu lassen. Wenn du auch Schutz gegen häufigere Angriffe auf Anwendungsebene verwaltest, findest du unter wie ich meine Server bis zum Patch für PHP2Shell abgesichert habe denselben Ansatz. Er lautet: abmildern, was möglich ist, während man auf den endgültigen Fix wartet, ohne Schutz zu versprechen, den es nicht gibt.

Für alle, die mich fragen, ob sie sofort aktualisieren sollen: Wenn du Debian Stable nutzt, ist der korrigierte Kernel schon in den Security-Repositories. Das Update ist einfach, und das Zeitfenster der Exposition ist schon geschlossen. Wenn du andere Distributionen nutzt, gibt es heute noch keinen Patch zu installieren. Es lohnt sich, die Advisories deines Herstellers in den nächsten Tagen genau zu verfolgen: Die Lage ändert sich schnell.

Quellen: The Hacker News, Debian Security Tracker und der Fix-Commit. Debian, Red Hat, Ubuntu und die anderen genannten Namen sind Marken ihrer jeweiligen Eigentümer.

The post Linux-Kernel-Schwachstelle: ein Use-after-free im TCP IPv4 first appeared on Matteo Cisilino.

Warum ich das E-Mail-Protokoll in WordPress vor den Server-Logs kontrolliere

Der typische Fall ist immer derselbe. Ein Kontaktformular, das „nicht ankommt“. Ein Kunde, der die Passwort-Reset-E-Mail nicht erhält. Eine Bestellung ohne Bestätigung. Ohne ein Protokoll zur Hand ist die erste Vermutung der Spam-Ordner. Dann die Logs des SMTP-Servers. Dann vielleicht die Firewall. Mit FluentSMTP überspringe ich diese Schritte. Ich sehe sofort, ob WordPress wirklich versucht hat, diese E-Mail zu versenden. An wen, wann, mit welcher Antwort vom Versandserver.

FluentSMTP protokolliert jeden Aufruf von wp_mail(). Nicht nur die E-Mails von Drittanbieter-Plugins, auch die vom Core selbst: Benachrichtigungen über neue Benutzer, Update-Erinnerungen, Fehlerhinweise. Für jeden Versand zeigt das Protokoll Absender, Empfänger, Betreff, vollständige Header, Nachrichtentext. Und die Antwort des SMTP-Providers oder der verwendeten API. Ist eine E-Mail fehlgeschlagen, steht diese Serverantwort genau dort. Ich muss sie nicht raten.

Was wirklich im Versandprotokoll steht

Das Plugin unterstützt Dutzende Connectoren: Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. Auch Google Workspace und Microsoft 365 über OAuth, neben dem klassischen generischen SMTP. Auf den Websites, die ich betreue, nutze ich fast immer authentifiziertes SMTP mit der Domain des Kunden. Manchmal eine dedizierte API, wenn das E-Mail-Volumen wächst. In beiden Fällen bleibt das Protokoll gleich. Jede Zeile hat einen Status, versendet oder fehlgeschlagen. Es gibt eine Schaltfläche, um den Inhalt anzusehen oder die Nachricht erneut zu senden, ohne dass der Nutzer die Aktion wiederholen muss, die sie ausgelöst hat.

Der erneute Versand ist die Funktion, die ich am häufigsten nutze. Ein Formular, das zweimal ausgefüllt wurde, weil „es nicht ankam“, wird zu einem Klick im Protokoll. Keine neue Meldung an den Kunden. Für wiederholte Fehlschläge habe ich Benachrichtigungen über Telegram aktiviert. Sobald eine Verbindung nicht mehr funktioniert, weiß ich es, bevor mir jemand schreibt. Statt es aus einem Support-Ticket zu erfahren.

Das Protokoll betrifft nicht nur Benachrichtigungen direkt an mich oder den Kunden, der die Seite verwaltet. Dort landet jede ausgehende E-Mail, die die Website an Dritte schickt: die Bestellbestätigung, die ein Online-Shop an den Endkunden sendet, die Zahlungsquittung, die Versandbenachrichtigung. Kommt diese Bestätigung nicht an, zeigt das E-Mail-Protokoll in WordPress das genauso wie eine interne Benachrichtigung, mit derselben Schaltfläche, um sie an den richtigen Empfänger neu zu senden, ohne dass er den Kauf wiederholen muss.

Wie ich FluentSMTP auf den Websites konfiguriere, die ich betreue

Nach dem Verbinden des passenden Connectors ändere ich die Aufbewahrungsdauer des Protokolls. Standardmäßig bleibt es lange aktiv. Ich stelle sie auf 30 bis 60 Tage, je nach Traffic der Website. Das reicht, um einem spät gemeldeten Problem nachzugehen. Ohne die Datenbank mit Zeilen zu füllen, die ich nie ansehen werde. Danach aktiviere ich mindestens einen Benachrichtigungskanal für Fehlschläge, Telegram oder Slack, je nach Kunde. Das Protokoll allein warnt niemanden, es muss geöffnet werden, um gelesen zu werden.

Auf Websites mit Kontaktformular nutze ich zusätzlich Cisilino Site Defense Network zum Blockieren von Bots. Weniger eingehender Spam bedeutet weniger E-Mails aus den Formularen. Das Protokoll bleibt übersichtlicher, mit weniger Rauschen, das ich beim Suchen der richtigen Nachricht ausblenden muss.

Die SMTP-Zugangsdaten bleiben nicht im Klartext in der Datenbank

Ein Detail, das ich immer prüfe, bevor ich eine Verbindung speichere: wo die Zugangsdaten landen. FluentSMTP verschlüsselt sie standardmäßig mit den SALT-Schlüsseln von WordPress, denselben, die schon in wp-config.php für die Sicherheit der Sitzungen stehen. Man kann die Verschlüsselung deaktivieren, aber das Plugin selbst rät davon ab. Auf den Websites, die ich betreue, bevorzuge ich eine andere Option: das API- oder SMTP-Passwort direkt in wp-config.php speichern, außerhalb der Datenbank, mit Konstanten, die definiert sind, bevor das Plugin sie liest. So legt auch ein Datenbank-Dump oder ein unbefugter Zugriff aufs Panel den Schlüssel des Versandproviders nicht offen. Es ist dasselbe Prinzip, das ich auch sonst anwende: weniger Geheimnisse in der Datenbank, umso besser.

Mehrere Verbindungen gleichzeitig, nicht nur eine nach der anderen

FluentSMTP erlaubt es, mehrere Verbindungen gleichzeitig einzurichten, nicht nur eine nach der anderen. Auf einer Website lege ich die Standardverbindung fest und füge eine zweite als Reserve hinzu: Antwortet der erste Provider nicht, wechselt der Versand automatisch zur Reserveverbindung, ohne dass ich eingreifen muss. Die Wahl der Verbindung hängt von der Absenderadresse ab: Jede Verbindung hat ihr eigenes „Von“, der Rest läuft über die Standardverbindung, mit der Reserve nur bereit, falls die Standardverbindung wirklich ausfällt (ein Fehler des Providers, keine E-Mail, die im Spam landet). Das ist einer der Gründe, warum ich das einem einzelnen SMTP ohne Alternative vorziehe: Haben SendGrid oder Amazon SES ein paar Stunden lang ein Problem, versendet die Website trotzdem weiter, und das E-Mail-Protokoll in WordPress zeigt es sofort. Alles in der kostenlosen Version enthalten, ohne eine kostenpflichtige Pro-Version: Man bezahlt nur den gewählten Versandprovider, nicht das Plugin.

Ein täglicher Gesundheitscheck, nicht nur wenn etwas kaputt ist

Neben dem Protokoll Zeile für Zeile führt FluentSMTP jeden Tag automatisch einen Gesundheitscheck der Verbindung durch. Antwortet der Provider nicht mehr, kommt die Warnung, bevor ein Kunde mir schreibt „die Website versendet keine E-Mails mehr“. Dasselbe Panel zeigt eine Grafik mit den täglichen Gesamtzahlen erfolgreicher und fehlgeschlagener Versände: nützlich, um auf einen Blick zu erkennen, ob ein Rückgang normal ist oder das Symptom für etwas, das gerade kaputtgeht, ohne jedes Mal das Protokoll Zeile für Zeile öffnen zu müssen. Es gibt auch eine periodische Zusammenfassung per E-Mail, mit den Zahlen der Woche: kein Fehlerhinweis, sondern ein Bulletin, das ich kurz überfliege, um zu wissen, ob das Versandvolumen im Rahmen liegt.

Wer wie ich mehrere Websites von der Kommandozeile aus verwaltet, findet in FluentSMTP auch WP-CLI-Befehle: einen Versandtest, einen Gesundheitscheck der Verbindung, Statistiken und das Aufräumen alter Protokolleinträge. Ich nutze sie in denselben Skripten, die schon auf den Servern für andere Wartungsaufgaben laufen, ohne das Panel jeder Website einzeln öffnen zu müssen.

Was das E-Mail-Protokoll in WordPress nicht leisten kann

Es ist keine Wunderlösung. Die Aufbewahrung richtet sich nach Tagen, nicht nach einer Höchstzahl an Zeilen. Auf einer Website mit viel transaktionalem Traffic kann die Protokolltabelle schnell wachsen. Es lohnt sich, sie im Blick zu behalten oder eine kürzere Aufbewahrungsdauer einzustellen. Fehlerbenachrichtigungen kommen nur über die konfigurierten Chat-Kanäle, nicht per E-Mail. Macht Sinn: Eine E-Mail, die vor einer fehlgeschlagenen E-Mail warnt, kann selbst fehlschlagen. Aber das sollte man wissen, bevor man sich darauf verlässt.

Schließlich zeigt das Protokoll, was auf Seiten von WordPress und auf Seiten des Providers passiert ist. Es garantiert nicht die Zustellung im Postfach des Empfängers. Ist eine E-Mail als versendet markiert, landet aber im Spam, ist das ein Problem des Domain-Rufs oder der SPF/DKIM-Konfiguration. Nichts, was ein Protokoll allein lösen kann. Trotzdem bleibt es die erste Stelle, an der ich nachsehe, bevor ich irgendetwas anderes prüfe.

Das Plugin ist kostenlos und Open Source. Die offizielle Seite auf wordpress.org, ohne Funktionen, die hinter einer Pro-Version blockiert sind. Wer auch nur eine Website mit Kontaktformular betreut, für den lohnt es sich, es nur für das E-Mail-Protokoll in WordPress zu installieren. Löst es das erste „ich habe die E-Mail nicht bekommen“ in einer Minute statt in einer halben Stunde, hat es sich bereits ausgezahlt.

The post E-Mail-Protokoll in WordPress: warum ich es mit FluentSMTP kontrolliere first appeared on Matteo Cisilino.

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.