Warum Webshell-Erkennung auf den Server gehört, nicht ins CMS

Es gibt eine unredliche Fassung dieses Arguments: Plugin-Scanner taugen nichts, kaufen Sie einen Server-Scanner. Eine fachkundige Leserin zerlegt sie in einem Absatz.

Das eigentliche Argument ist enger und deutlich schwerer zu entkräften. Ein Scanner, der als PHP-Prozess innerhalb der Website eines Kunden läuft, teilt das Schicksal dieses Prozesses. Wenn die Site kompromittiert ist, ist alles darin kompromittiert – auch das, was gerade scannt. Das ist eine strukturelle Eigenschaft, kein Qualitätsurteil, und sie gilt unabhängig davon, wie gut der Scanner ist.

Alles Folgende stammt aus fremder Vorfallsarbeit, der Dokumentation der Hersteller selbst, Kernel-Manpages, MITRE, einem NSA-Repository und dem BSI.

Dokumentierte Fälle, in denen der Scanner selbst erreicht wurde

Drei unabhängige Vorfallsberichte von Sucuri aus vier Jahren beschreiben Schadsoftware, die gezielt WordPress-Sicherheits-Plugins angreift.

2020 – der Plugin-Killer. Eine Schleife in wp-load.php deaktiviert fünfzehn namentlich genannte Sicherheits-Plugins, darunter wordfence, sucuri-scanner, wp-cerber und ninjafirewall. Da wp-load.php bei jedem Seitenaufruf läuft, wird ein reaktiviertes Plugin bei der nächsten Anfrage wieder abgeschaltet. Sucuris Fazit: „Malware like this clearly demonstrates why it is so important to have a defense in depth security system that is not dependent solely on a plugin." (Sucuri, 10. September 2020 .)

2022 – der Quelltext des Scanners wird gepatcht. Ein Angreifer veränderte wordfence.php und lib/wordfenceScanner.php und entfernte gezielt die Warntexte „This file appears to be installed or modified by hacker to perform malicious activity" und „File appears to be malicious or unsafe"; zusätzlich wurde site_transient_update_plugin manipuliert, damit die Administration nicht sah, dass das Plugin veraltet war. Drei Backdoors blieben verborgen, eine davon in wp-includes/Requests/Transport/ – einem Core-Verzeichnis, das nur ein Integritätsabgleich der Core-Dateien aufdeckt (Sucuri, Ben Martin, 20. Oktober 2022 ).

Sucuris Empfehlung am Ende dieses Beitrags ist die klarste Formulierung des Prinzips, die wir gefunden haben – und sie kommt von einem Unternehmen mit einem Konkurrenzprodukt:

It would be helpful to have a file integrity monitoring service that resides mostly outside of the environment itself, like our server side scanning solution.

2024 – Verzeichnis umbenennen, Oberfläche fälschen. Ein gefälschtes Plugin „renames the WordFence plugin directory to ‘wordfence1’ thereby disabling the plugin entirely", legt den Administrator license_admin2 an und – das ist das Detail, das am meisten sitzt –

It searches for options ‘Scan theme files’ and ‘Scan plugin files’ and changes their style to make them look enabled (without changing the actual option).

(Sucuri, Ben Martin, 5. Juli 2024 .) Die Einstellungsseite zeigt den Scan weiterhin als aktiviert an. Beachten Sie, was der Angriff dafür brauchte: ein rename(), eine einzige Dateisystemoperation, die jedem Prozess unter der Site-Kennung offensteht. Ein Exploit gegen den Scanner selbst war nicht nötig.

Zur Fairness ausdrücklich: Wordfence ist ein gutes Produkt, und nichts davon sagt etwas anderes. Die drei Fälle zeigen, dass eine Schutzmaßnahme innerhalb des Mandanten für denjenigen erreichbar ist, der den Mandanten kompromittiert – das gilt für jeden Scanner, der in der Site läuft.

Die Grenzen, die der Hersteller selbst dokumentiert, und die Latenzlücke

Wordfence beschreibt die Rahmenbedingungen offen. Der Scan ist „a PHP application", und die Troubleshooting-Seite erklärt, was das auf Shared Hosting bedeutet:

Some hosts limit memory across multiple processes or may have CPU usage limits over a period of time. These limits are not always obvious since they may not cause error messages in your PHP error logs, and may make the scan appear to just stop working.

Dieselbe Seite nennt Laufzeitgrenzen und „Killer-Daemons", die lang laufende Prozesse beenden; die Dokumentation der Scan-Optionen hält fest, dass der Standardumfang nur das WordPress-Wurzelverzeichnis umfasst und dass eine Ausweitung die Änderung ist, die auf knapp bemessenen Hosts am ehesten zum Abbruch führt.

Daraus folgt der sauberste Zahlenvergleich, den es hier gibt. Beide Werte sind dokumentierte Standardeinstellungen der jeweiligen Hersteller, keine Schätzungen.

Die Formulierung von Wordfence ist eindeutig – „a quick scan runs every day, and a full scan runs every 72 hours" in der kostenlosen Variante –, und dieselbe Seite empfiehlt bei knappen Ressourcen einen wöchentlichen Rhythmus.

Halten Sie dagegen den von Patchstack gemessenen gewichteten Median von fünf Stunden bis zur ersten Ausnutzung (Patchstack 2026 ). In der kostenlosen Variante ist das ungünstigste Zeitfenster zwischen dem Schreiben einer Webshell und dem nächsten Vollscan länger als die mediane Zeit bis zur massenhaften Ausnutzung einer Schwachstelle. Zwischen beiden Intervallen liegen rund vier Größenordnungen.

Verkehrsfilterung schließt die Lücke ebenfalls nicht: In den Tests von Patchstack blockierten die WAFs von Hosting-Anbietern 12 Prozent der WordPress-spezifischen Angriffe, in einem breiteren Test 26 Prozent. Das belegt, dass Prävention auf einer einzelnen Filterebene unzuverlässig ist – es ist kein Argument dafür, dass Hoster schlecht arbeiten.

Risiken zwischen Accounts werden unterhalb der Anwendung beantwortet

Auf Shared Hosting sind die gewünschte Isolation und die entstehende Blindheit dieselbe Eigenschaft aus zwei Blickrichtungen.

CloudLinux beschreibt CageFS als „a virtualized file system and a set of tools to contain each user in its own ‘cage’" und führt als Vorteil auf, ein Benutzer „will not see any other users, and would have no way to detect presence of other users & their user names on the server" (CloudLinux-OS-Komponenten ).

Lesen Sie das als Negativraum. Was CageFS verhindern soll, ist genau das, was ein Scanner innerhalb eines gekäfigten Accounts nicht sehen kann. Für den Mandanten ist das die richtige Antwort – und zugleich der Grund, warum ein Scanner je Mandant nicht die Erkennungsschicht des Hosts sein kann. Das folgt aus dem Isolationsentwurf, es ist kein Eingeständnis eines Herstellers.

Der Symlink-Race macht es deutlicher. CloudLinux’ SecureLinks „Prevents apache from serving files not owned by user, stopping symlink attacks against php config files" – und der dokumentierte Standard ist aus. Die dokumentierten Gegenmaßnahmen von cPanel für dieselbe Angriffsklasse sind KernelCare-Patchsätze, CageFS, SecureLinks und als letztes Mittel der Bluehost-Patch.

Alle diese Maßnahmen sitzen auf Kernel- oder Webserverebene. Keine davon steht einem Plugin zur Verfügung. Für diese Angriffsklasse ist die Anwendungsebene nicht nur schwächer – sie ist gar nicht beteiligt. Reinfektionen haben dieselbe Form: Sucuri dokumentiert, dass die Bereinigung einer Site nicht genügt, solange eine Nachbar-Site im selben Account oder auf demselben Server die Backdoor trägt, die sie erneut infiziert (Cross-Contamination ).

Was die neutralen Instanzen tatsächlich sagen

MITRE ATT&CK führt Webshells als T1505.003 , eine Persistenztechnik: „Adversaries may backdoor web servers with web shells to establish persistent access to systems." Die Linux-Detection-Analytik AN1109 lautet:

File creation of unauthorized script (e.g., .php, .sh) in /var/www/html followed by execution of unexpected system utilities (e.g., curl, bash, nc) by apache/nginx

MITRE benennt damit das Anlegen einer Datei im Webverzeichnis als primäres Erkennungssignal – ein Argument für die Überwachung von Schreibvorgängen, formuliert von einer neutralen Stelle und nicht von einem Scanner-Anbieter. Der ehrliche Vorbehalt: Die Analytik kombiniert das Anlegen der Datei mit anschließender auffälliger Prozessausführung; die Erkennung von Schreibvorgängen allein ist die Hälfte davon. Die genannten Gegenmaßnahmen sind unspektakulär und billig: Funktionen wie PHPs eval() deaktivieren, die für Webshells missbraucht werden (M1042), und Rechte so beschränken, dass nur berechtigte Konten das Webverzeichnis ändern können (M1018). Zusammen mit T1190, Exploit Public-Facing Application ergibt sich die vollständige Kette – verwundbares Plugin, dann Webshell-Persistenz – mit je einer neutralen Quelle.

Das Begleit-Repository der NSA zu ihrer Webshell-Handreichung von 2020 hält wörtlich fest:

The most effective method of discovering most web shells is to compare files on a production web server with a known-good version of that application, typically a fresh install of the application where available updates have been applied.

(nsacyber/Mitigating-Web-Shells .) Zur Zuordnung: Sowohl das gemeinsame Informationsblatt von NSA und ASD als PDF als auch die CISA-Meldeseite lieferten unserem Abrufwerkzeug HTTP 403. Diese Zitate stammen daher aus dem GitHub-Repository, das wir gelesen haben, nicht aus dem PDF. Beschrieben ist ein Abgleich gegen einen bekannten Gutzustand, nicht Signaturscanning; unsere Aussage lautet nur, dass eine nationale Sicherheitsbehörde die Prüfung auf Dateisystemebene als wirksamste Methode benennt – eine Maßnahme auf Hostebene, nicht auf Anwendungsebene.

Dasselbe Repository ist bemerkenswert offen im Umgang mit Heuristik und schreibt über die erweiterten YARA-Regeln, sie „are likely to produce a significant number of false positive results". Das begründet einen gestuften Aufbau – zuerst günstige, treffsichere Signaturen, danach teure Heuristik – und wer null Fehlalarme bei Verschleierungsheuristik verspricht, widerspricht der NSA. Das Repository liefert außerdem Integritätsregeln, die Änderungen an Webverzeichnissen blockieren, mit dem Hinweis, Regeln vor dem Erzwingen anzupassen: das Argument für einen Rollout, der erst beobachtet und später durchsetzt.

Das BSI formuliert es am klarsten von allen. IT-Grundschutz APP.3.2.A3, eine Basis-Anforderung der aktuellen Edition 2023, lautet:

Alle mithilfe des Webservers veröffentlichten Dateien MÜSSEN vorher auf Schadprogramme geprüft werden.

(BSI IT-Grundschutz-Kompendium 2023, APP.3.2 .) Das ist Upload-Prüfung, auf Basisebene verbindlich. Jede Zuordnung zwischen dieser Anforderung und einem konkreten Produkt ist unsere Lesart, keine BSI-Zertifizierung.

fanotify und inotify, in den Worten des Kernels

Zunächst: Das ist keine exotische Wahl. Die Konfigurationsdokumentation von Imunify360 beschreibt das eigene Echtzeit-Scanning als „fanotify as the primary monitoring mechanism (kernel 3.10+) with legacy inotify fallback" (Imunify360-Konfigurationsreferenz ). Der Marktführer nutzt denselben Mechanismus.

Die Manpage fanotify(7) beschreibt die Schnittstelle als „provides notification and interception of filesystem events", mit drei Vorteilen:

the ability to monitor all of the objects in a mounted filesystem, the ability to make access permission decisions, and the possibility to read or modify files before access by other applications.

Zwei davon zählen hier. Permission-Events – FAN_ACCESS_PERM, FAN_OPEN_PERM, FAN_OPEN_EXEC_PERM – sind „requests to the receiving application to decide whether permission for a file access shall be granted", und eine Ablehnung lässt den auslösenden Aufruf EPERM erhalten. Ein Scanner auf Plugin-Ebene kann nur bemerken; ein Permission-Event-Listener kann verweigern. Und die Abdeckung eines ganzen Baums ist in den Worten des Kernels race-frei: Die Überwachung von Mounts „offers the capability to monitor a whole directory tree in a race-free manner."

Die Manpage inotify(7) hält dagegen fest: „Inotify monitoring of directories is not recursive: to monitor subdirectories under a directory, additional watches must be created" – also ein Watch je Verzeichnis über Tausende Kundenverzeichnisse hinweg, unter einer Obergrenze je Benutzer in /proc/sys/fs/inotify/max_user_watches. Dokumentiert sind außerdem ein inhärentes Zeitfenster beim Setzen eines Watches und eine Warteschlange, die mit IN_Q_OVERFLOW überlaufen kann. Zur Präzision bei einer oft überzogenen Behauptung: Die Manpage sagt nicht, dass inotify eine Operation nicht verhindern könne. Sie beschreibt eine reine Benachrichtigungsschnittstelle ohne Antwortmechanismus. Das ist die zutreffende Formulierung, und sie genügt.

Die Vorbehalte, die wir trotzdem veröffentlichen, weil sie real sind. Die fanotify-Manpage hält fest, dass die Schnittstelle „does not catch remote events that occur on network filesystems", dass sie „does not report file accesses and modifications that may occur because of mmap(2), msync(2), and munmap(2)" und dass „the event queue can overflow. In this case, events are lost." Echtzeitüberwachung muss daher mit einem periodischen Vollscan kombiniert werden; eine reine Echtzeitzusage ist nicht haltbar. Create-, Delete- und Move-Ereignisse kamen mit Linux 5.1 hinzu – eine harte Kernel-Untergrenze für Erkennung beim Schreiben.

Ein weiterer Absatz dort prägt die Architektur mehr als jede Funktionsliste:

When an event is generated, no check is made to see whether the user ID of the receiving process has authorization to read or write the file before passing a file descriptor for that file. This poses a security risk, when the CAP_SYS_ADMIN capability is set for programs executed by unprivileged users.

Ein Prozess mit CAP_SYS_ADMIN, der Deskriptoren auf beliebige Kundendateien erhält, ist eine große und attraktive Vertrauensgrenze.

Wie eine gekapselte Scanner-Architektur aussieht

Shelltrap als durchgerechnetes Beispiel, weil wir diese Architektur sachlich beschreiben können, statt sie zu vermuten.

Der privilegierte Teil enthält keine Parser. Der Root-Broker ist ein statisch gelinktes Go-Binary ohne cgo, ohne YARA, ohne ClamAV-Code und ohne Archiv-, Office- oder ELF-Parsing. Er hält die fanotify-Gruppen, normalisiert Ereignisse, öffnet Dateien sicher (openat2 mit RESOLVE_NO_SYMLINKS, wo der Kernel es unterstützt, sonst ein komponentenweiser openat-Walk mit O_NOFOLLOW), übergibt Scan-Aufträge an Worker, führt Quarantäne-Transaktionen aus und bedient die lokale API – und nimmt von Oberfläche und CLI ausschließlich opake Objekt-IDs entgegen, nie freie Pfade.

Der parsende Teil hat keine Privilegien. Der Scanner-Worker läuft unter eigenem Systembenutzer, ohne Netzwerk, in eigenem Mount- und PID-Namespace, mit seccomp, rlimits und cgroup-Grenzen, und erhält vom Broker einen nur lesbaren Deskriptor über SCM_RIGHTS. Die Pipeline ist bewusst gestuft: Typerkennung über Magic Bytes zur Priorisierung, dann ClamAV über den clamd-Socket, dann YARA 4.5 mit je Feed-Generation vorkompilierten Regeln, dann Hash-Sets samt Known-Good-Allowlist und erst danach Heuristik – Verschleierungsmerkmale, PHP in Upload-Verzeichnissen, Handler-Tricks in .htaccess und .user.ini, Symlinks aus dem Home hinaus. Ein Heuristiktreffer verlangt mehrere unabhängige Signale, die einzeln sichtbar bewertet werden. Diese Trennung existiert wegen des oben zitierten CAP_SYS_ADMIN-Absatzes, nicht trotz ihm.

Unsicherheit ist ein eigenes Verdikt. Die Zustände sind clean, suspicious, malicious, unscanned und degraded. Dateien, die wegen Größe, Typ oder Budget übersprungen werden, gelten als unscanned mit Begründung und nie stillschweigend als sauber; fehlt clamd, lautet der Zustand degraded. FAN_Q_OVERFLOW-Ereignisse werden gezählt, alarmiert und lösen einen begrenzten Rekonziliationsscan aus.

Das Upload-Gate schließt das Fenster vor der ersten Ausführung. Ein schlanker PHP-Adapter über auto_prepend_file wird nur bei nicht leerem $_FILES aktiv, übergibt die temporären Deskriptoren über einen Unix-Socket an den Broker und wartet höchstens zwei Sekunden; bei einem Malicious-Verdikt antwortet er mit 403 und löscht die temporäre Datei. Fail-open ist Standard, Fail-closed je Domain konfigurierbar. Die bekannte Grenze wird dokumentiert statt verschwiegen: auto_prepend_file lässt sich per .user.ini überschreiben – was selbst eines der Heuristiksignale ist, mit dem fanotify-Watcher dahinter als Auffangnetz.

Erkennung degradiert sichtbar. Fähigkeiten werden zur Laufzeit geprüft statt aus einer Kernelversion abgeleitet, und Hosts landen in Stufen – bis hinunter zu einer Stufe, auf der das Produkt gar keine Echtzeiterkennung zusagt. „Das können wir hier nicht" ist eine nützlichere Antwort als eine Oberfläche, die „sauber" meldet.

Was das für CyberPanel-Betreiber bedeutet

1. Behalten Sie den Plugin-Scanner, aber nicht als maßgebliche Maßnahme. Für die Site-Inhaberin ist er nützlich. Er ist nicht die Schicht, die eine Kompromittierung der Site überlebt, und drei Sucuri-Untersuchungen zeigen Angreifer, die ihn direkt angehen.
2. Vergleichen Sie Intervalle, keine Funktionslisten. Stellen Sie jedem Anbieter zwei Fragen: Was löst einen Scan aus, und wie groß ist die ungünstigste Verzögerung zwischen dem Schreiben einer Datei und dem ersten Blick darauf? Fünfzehn Sekunden und 72 Stunden sind beides dokumentierte Standardwerte dieses Markts.
3. Fragen Sie, was beim Überlauf der Ereigniswarteschlange passiert. Wer darauf keine Antwort hat, hat entweder die Manpage nicht gelesen oder verschweigt den ohnehin nötigen periodischen Vollscan.
4. Prüfen Sie die Vertrauensgrenze. Wer YARA-, Archiv- und Office-Parsing in einem Prozess mit CAP_SYS_ADMIN ausführt, ist einen Parser-Fehler vom Vorfall entfernt. Fragen Sie, wo die Parser laufen.
5. Klären Sie die Anforderung vor dem Produkt. Wer nach Deutschland verkauft, wird an APP.3.2.A3 gemessen, und dort geht es um die Prüfung von Dateien vor der Veröffentlichung – nicht um eine Marke. Wie diese Dateien aussehen, steht in Die WordPress-Webshell-Welle 2024–2026 ; den Migrationsfall behandelt CXS ist Geschichte .

Die Installationsdokumentation beschreibt, was Shelltrap auf Ihrem Host prüft, bevor es irgendetwas zusagt – einschließlich der Stufe, in der Ihr Server landet. Die Konditionen stehen auf der Preisseite .