Shelltrap auf cPanel: was heute funktioniert, was Beta ist

Shelltrap ist für CyberPanel gebaut worden, aus einem naheliegenden und etwas provinziellen Grund: Das ist es, was wir selbst betreiben. Die Lücke, die wir geschlossen haben, war unsere eigene. Die Maschinerie darunter aber — ein fanotify-Wächter, ein parserfreier Root-Broker, ein Worker ohne Rechte, signierte Regelgenerationen, eine Quarantäne-Transaktion, die einen Absturz übersteht — war nie CyberPanel-spezifisch. Spezifisch war genau eine dünne Schicht: der Teil, der die Frage beantwortet, welche Verzeichnisse auf dieser Maschine welchem Kunden gehören.

Release 0.3.0 fügt eine zweite Antwort auf diese Frage hinzu und damit die cPanel/WHM-Unterstützung auf AlmaLinux 8 und 9 sowie Ubuntu 22.04 und 24.04. Sie trägt das Etikett Beta, und in diesem Artikel geht es darum, was dieses Etikett bedeutet — und was nicht.

Was identisch ist

Wer die Produktseite gelesen hat, hat den cPanel-Build bereits gelesen. Es gibt keine abgespeckte Ausgabe und keine eigene Artikelnummer. Auf einem cPanel-Host bekommen Sie:

• Erkennung in Echtzeit über fanotify — jeden Schreibvorgang, jedes Verschieben, Anlegen, Löschen und jede Attributänderung unterhalb der Kundenverzeichnisse, mit gezähltem Warteschlangenüberlauf, der mit einem begrenzten Abgleichlauf beantwortet und nicht verschluckt wird.
• Dieselbe Rechtetrennung. Der Root-Broker hält die fanotify-Gruppen und keinen Parser; der Worker hält die Parser, läuft als eigener Benutzer in eigenem Mount- und PID-Namespace mit seccomp, Landlock, rlimits und cgroup-Grenzen — und ganz ohne Netz.
• Jede Engine. ClamAV über den clamd-Socket im Full-Profil, YARA 4.5 je Regelgeneration vorkompiliert, Hash-Sets mit Known-Good-Allowlist und eine Heuristik, die mehrere unabhängige Signale braucht, bevor sie etwas sagt.
• Die fünf Verdikte, einschließlich unscanned und degraded, die nie stillschweigend als clean gezählt werden.
• Quarantäne als Transaktion, mit einem Restore, das Eigentümer, Modus, Zeiten, ACLs, erweiterte Attribute und den SELinux-Kontext zurückbringt und nie eine vorhandene Datei überschreibt.
• Policies je Domain, mit der Vererbung global → Account → Domain, die Sie sich mit shelltrap policy effective anzeigen lassen.
• Signierte Feed-Generationen mit Provenienz je Regel, Korpus-Gate und automatischem Rollback bei einem Quarantäne-Sturm.
• Eine Lizenz je Server, zum selben Preis, mit demselben Aktivierungsbefehl.
• Dieselbe Datenhaltung. Dateien verlassen die Maschine nie. Es gibt zwei Verbindungen nach außen: die Lizenzprüfung und den signierten Feed-Download, beide enden in Deutschland.

Was neu ist: die Plattformschicht

Beim Start ermittelt der Daemon, auf welchem Panel er sitzt; gesagt werden muss es ihm nicht. Auf einem cPanel-Host baut er seinen Document-Root-Index aus den cPanel-Userdata und deckt dabei die vier Formen ab, die ein Account annehmen kann:

Dieser Index macht aus einem Kernel-Ereignis einen Satz, mit dem ein Mensch etwas anfangen kann. Ein rohes fanotify-Ereignis sagt, dass sich auf einem Mount eine Datei geändert hat; der Index macht daraus: diese Datei, in dieser Domain, im Eigentum dieses Accounts, unter dieser Policy. Zugeordnet wird über das längste passende Document-Root-Präfix, und Dateien außerhalb jedes Document-Roots — E-Mail, Backups, das Home-Verzeichnis — fallen unter die Account-Policy, statt aus dem Blick zu geraten.

Prüfen Sie ihn, bevor Sie sich darauf verlassen:

shelltrapd --config /etc/shelltrap/shelltrap.toml --check
shelltrap status

status gibt die Zahl der indexierten Sites aus. Passt sie nicht zu dem, was WHM Ihnen anzeigt, ist das ein Fehler, der eine E-Mail wert ist, und keine Umgehung.

Was bewusst anders ist

Zwei Dinge, und beide stehen auf dem Etikett statt im Kleingedruckten.

Es gibt kein WHM-Plugin

Auf CyberPanel gibt das Plugin Administratoren, Resellern und Kunden ein Dashboard, Funde mit ihren Signalen, Quarantäne und Restore, Policies je Domain und den Feed-Status — mit dem Rollenmodell, das das Panel ohnehin durchsetzt. Auf cPanel gibt es davon im Browser noch nichts.

Was es stattdessen gibt, ist die Schnittstelle, die das Plugin selbst benutzt: die CLI über einen lokalen Unix-Socket und die lokale HTTP-API dahinter. Nichts ist damit unerreichbar — Funde, Signale, Quarantäne, Restore, Policies, Ignore-Regeln, Feed-Generationen, Audit, Jobs und Health sind alle da:

shelltrap health
shelltrap findings list --json
shelltrap findings show <finding-id>
shelltrap quarantine list
shelltrap policy effective <site-id>

Ein WHM-Plugin steht auf der Roadmap. Es hat kein Datum, und wir erfinden auch keines; im Changelog taucht es auf, sobald es echt ist.

Das PHP-Upload-Gate ist optional und standardmäßig aus

Auf einem LiteSpeed-Host ist das synchrone Gate vor PHP eines der nützlichsten Dinge, die Shelltrap tut: Ein bösartiger Upload bekommt HTTP 403 und eine gelöschte Temp-Datei, bevor die Anwendung ihn überhaupt sieht.

Auf cPanel mit EasyApache 4 und PHP-FPM steht derselbe Adapter zur Verfügung, ist aber standardmäßig aus, und ihn einzuschalten ist eine bewusste Entscheidung je Host. Bleibt er aus, sind diese Dateien nicht unbeobachtet — der Echtzeit-Wächter sieht sie einen Moment nach dem Schreiben statt synchron vor dem Abschluss des Requests. Das ist ein echter Unterschied, und er steht im Fund, statt beschönigt zu werden: Ein Scanner, der still von Verhinderung auf Erkennung zurückfällt und weiter „Schutz" sagt, ist genau das, wovon dieses Produkt das Gegenteil sein will.

Was „Beta" hier heißt

Nicht „neu und aufregend". Etwas Engeres:

Die cPanel-Plattformunterstützung ist gegen das cPanel-Dateiformat implementiert und mit Fixtures getestet. Langzeitbetrieb auf produktiven cPanel-Hosts hat sie noch nicht hinter sich.

Zwei Folgerungen, die man aussprechen sollte.

Das Risiko sitzt in einer Schicht. Engines, Verdikt-Modell, Quarantäne-Transaktion, Feed-Prüfung und Lizenzierung haben Betriebshistorie. Die Site-Ermittlung auf cPanel hat sie nicht. Wenn etwas überrascht, schaut man dort zuerst — und der Fehlermodus dieser Schicht lautet „eine Domain fehlt im Index" und nicht „eine Kundendatei wurde gelöscht".

Report-only ist keine Formalie. So betreiben wir Neues auf unseren eigenen Produktionshosts, und auf einer cPanel-Maschine sollte diese Phase länger dauern als beim CyberPanel-Build:

shelltrap policy set global signature.action=report hash.action=report \
  heuristics.action=report upload.enabled=false

Alles aufzeichnen, nichts bewegen, jede malicious-Meldung von Hand prüfen, die eigene Fehlalarmquote aufschreiben — und erst danach Aktionen einschalten, Domain für Domain. Liegt ein Fund daneben, ist die Meldung automatisiert und in der Regel binnen einer Stunde beantwortet.

Warum überhaupt, wenn cxs doch nur „nicht mehr verkauft" wird

Weil am Tag, an dem der Verkauf endet, nichts kaputtgeht — und genau das ist die Falle. Der ConfigServer eXploit Scanner wird nicht mehr verkauft (geprüft am 4. September 2026). Ein nicht mehr gepflegter Scanner wird nicht rot; er meldet weiter clean, mit stetig weniger Recht dazu, während sein Signatur-Feed hinter dem zurückbleibt, was diesen Monat hochgeladen wird. Der Verfall bleibt unsichtbar, bis jemand anderes die Shell für Sie findet.

Das übrige ConfigServer-Umfeld ist nicht verschwunden — cPanel führt CSF seit dem 25. Februar 2026 als eigenen Fork weiter —, aber der Exploit-Scanner ist ein eigenes Produkt und eine eigene Lücke. Die kommerzielle Alternative, die den meisten cPanel-Betreibern angeboten wird, ist Imunify360, mit 12 bis 45 USD im Monat je nach Benutzerzahl (geprüft am 4. September 2026). Shelltrap kostet 14,90 EUR im Monat oder 149,00 EUR im Jahr inklusive deutscher Umsatzsteuer, je Server, ohne Domains und Accounts zu zählen — und, für alle, denen das wichtig ist, mit einem Scan, der auf der Maschine stattfindet und sonst nirgends.

Dass er mehr erkennt, sagen wir Ihnen nicht. Diese Zahl kann niemand verteidigen, wir eingeschlossen.

Der Einstieg

Fünf Schritte, bis auf die Paketliste keine anderen als auf CyberPanel:

1. Das Kernpaket über die Download-Seite mit Ihrem Lizenzschlüssel holen. Ein Paket shelltrap-cyberpanel gibt es auf einem cPanel-Host nicht.
2. shelltrap license activate STL-…
3. Den Daemon die Plattform erkennen lassen und die Zahl der Sites mit shelltrap status prüfen.
4. Den ersten Scan im Report-only-Modus fahren und lesen, was er sagt.
5. sentinel@shelltrap.com in die Allowlist aufnehmen — von dort kommen die Fundmeldungen.

Die ausführliche Fassung mit Profilentscheidung und systemd-Drop-ins steht in Installation und Erstinbetriebnahme , die produktseitige Zusammenfassung auf Shelltrap für cPanel .