Shelltrap ist in der internen Teststufe auf Panomity-Produktionshosts. Das hier hat diese Stufe bisher zutage gefördert — die unschmeichelhaften Einträge eingeschlossen, denn die sind die lesenswerten.
Versionsnummern folgen MAJOR.MINOR.PATCH. Alles unterhalb von 1.0.0 ist ein interner
Testbuild: Er läuft auf unseren eigenen Hosts unter Produktionslast, ist nicht herunterladbar und
von keiner Kundenzusage gedeckt. Er steht hier, weil ein Scanner, der auf einer echten Maschine nie
falsch lag, schlicht nie auf einer war.
Release 1.0 trägt den vollen Umfang: alle Plattformstufen, die Panel-UI mit Rollen, den
FTP-Enqueuer, Full- und Lite-Profile mit Messung, die vollständige CyberPanel-Plattformmatrix in der
CI, DSGVO-Aufbewahrung und den Reparaturpfad nach einem Panel-Upgrade.
neu Kostenloser Test: 14 Tage Report-only mit Kundenkonto und bestätigter E-Mail; 30 Tage mit vollem Umfang außer automatischer Quarantäne, sobald eine Zahlungsart hinterlegt ist. Ein Test je Server und Kunde, täglich online erneuert; nach dem Test stoppen Scans und Feeds, Funde bleiben sichtbar.
geändert Ressourcenschonende Standardwerte: begrenzte Rekonsiliation (20 Dateien/s, 16 MiB/s), die nach einem Neustart am letzten gesunden Zeitstempel weitermacht statt alles neu zu scannen, Scan-Cache für unveränderte saubere Dateien, standardmäßig zwei Scan-Worker, CPU-Quote 100 % und Speichergrenzen in der Service-Unit, Session- und Logdateien vom Echtzeit-Scan ausgenommen. Eine Vollinventur läuft nur beim ersten Start oder auf Anforderung (shelltrap scan –all).
behoben Feed-Generationen werden root-eigen gebaut; der Referenzhost scannt nach Neustarts nicht mehr sein gesamtes Inventar neu.
neu cPanel/WHM-Hosts (Beta): Plattform-Autoerkennung, Site-Index aus den cPanel-Userdata (Haupt-, Addon-, Sub- und Parked-Domains, suspendierte Accounts), Generic-Modus mit statischen Sites, optionales EasyApache-4-PHP-FPM-Upload-Gate (shelltrap uploadgate install –platform cpanel, standardmäßig aus). Noch kein WHM-Plugin; CLI, API, Alerts und signierte Feeds wie bei CyberPanel.
neu Automatisierte Fehlalarm-Prüfung: Meldungen registrierter Kunden an falsepositive@shelltrap.com
werden erneut gescannt, von einem Modell auf Panomity-GPU-Hardware bewertet und bei Bestätigung per SHA-256 in der nächsten signierten Feed-Generation freigegeben; Antworten kommen von sentinel@shelltrap.com
.
geändert Hash-Allow-Einträge (herstellerverifizierte Dateien wie WordPress-Core) haben jetzt Vorrang vor YARA-Treffern; ClamAV-Signaturen und bösartige Hash-Einträge gewinnen weiterhin. Bisher dämpfte ein Allow-Eintrag nur die Heuristik.
geändert Benachrichtigungen kommen von sentinel@shelltrap.com
; Fund-Mails verlinken auf die Regelseiten von shelltrap.com.
0.2.5interne Teststufe
Feed-Selbstheilung und CyberPanel-Plugin auf Django 4
behoben Feed-Update und Health scheitern nicht mehr mit ‘store: not found’, wenn die aktive Generation keinen Store-Eintrag hat; der Eintrag wird aus dem verifizierten Manifest neu aufgebaut.
behoben CyberPanel-Plugin-Paket auf aktuellen Panels (Django 4): Integrationsprüfung akzeptiert die path()-Route und den menu-item-Sidebar-Block, das Repair wiederholt den lscpd-Neustart und protokolliert den Grund eines Rollbacks.
0.2.4interne Teststufe
Feed-Updates ohne Verklemmung, Echtzeit-Ausschlüsse, Benachrichtigungs-Hygiene, Fund-Dedupe
behoben Eine Feed-Aktivierung blockiert weder laufende Scans noch den Health-Endpunkt: Reload quiesciert jeden Worker einzeln mit 55-Sekunden-Grenze, POST /v1/feeds/update antwortet asynchron (202/409), feeds status und feeds update –wait zeigen die Phasen.
neu Echtzeit-Ausschlüsse: [watch] exclude (Default /home/vmail/**, /Maildir/, /.cache/) und scan.exclude je Domain, Account und global wirken ohne Neustart; Mailboxen gelten nicht mehr als Kundendateien.
geändert Benachrichtigungen enthalten keine Indikator-Strings; höchstens eine Mail je Site und Dateihash pro Stunde und 30 Einzelmails pro Stunde insgesamt, der Rest landet im Digest. Wiederholte Funde derselben Datei werden zusammengefasst (Vorkommen, zuletzt gesehen), nie in aufgelöste Funde.
geändert Das Feed-Build-Gate verlangt PHP-Dateikontext und mindestens zwei Indikatoren je Panomity-Regel; die Backtick-Regel trifft keine Dokumentationskommentare mehr.
neu Lizenzaktivierung mit offline prüfbaren Ed25519-Token (shelltrap license activate); ohne Lizenz scannt der Daemon nicht und erhält keine Signaturfeeds.
neu Signierter Vendor-Feed mit 163 YARA-Regeln (Panomity, MIT; kuratierte Neo23x0-Regeln, DRL-1.1) und SHA-256-Allowlisten für WordPress-Core 5.8 bis 6.9.
geändert Allow-Treffer überstimmen die Heuristik; dokumentierte Bibliotheksdateien bleiben unter suspicious; Scheduler-Aging verhindert das Verhungern von Reconcile-Jobs nach Neustarts.
geändert Health nennt jede Degraded-Ursache; gestrippte Release-Binaries; Aktivierungs-Korpus im Paket.
geändert Bekannt: Ein Feed-Update unter Dauerlast kann den Daemon blockieren; Behebung im nächsten Release.
0.1.10interne Teststufe
Paketierung: Beispiel-Drop-ins an kanonischer Stelle
behoben Minimierte Ubuntu-Images entfernen /usr/share/doc/* über eine dpkg-path-exclude und damit auch die mitgelieferten systemd-Drop-in-Beispiele. Sie liegen jetzt zusätzlich unter /usr/share/shelltrap/systemd/.
geändert Die Plattformmatrix prüft den kanonischen Drop-in-Pfad auf jedem Image.
0.1.9interne Teststufe
Absturz beim Benachrichtigen und heuristische Fehlalarme
behoben Ohne [notify]-Abschnitt erreichte ein typisierter Nil-Zeiger den Broker als nicht-nil Interface; die erste suspicious-Meldung stürzte den Daemon in eine Restart-Schleife. cmd/shelltrapd filtert typisierte Nils, der Digest-Notifier ist nil-sicher.
geändert Entropie oder eine einzelne lange Zeile allein ergeben nie mehr suspicious; eine Bilddatei braucht ein explizites PHP-Tag mit Code, bevor sie überhaupt bewertet wird.
0.1.8interne Teststufe
Nur signierte Regelgenerationen werden geladen
Sicherheit Der Daemon lädt eine Signaturgeneration nur noch, wenn sie mit einem gepinnten Ed25519-Schlüssel signiert ist. Unsignierte oder ungepinnte Generationen werden fail-closed abgelehnt.
neu tools/feedbuild baut eine lokale Generation aus Quellen plus Provenienz-CSV, damit auch ohne Vendor-Feed die vollständige Regelpipeline läuft.
0.1.7interne Teststufe
systemd-Unit streicht CAP_SETUID nicht mehr
behoben Ein explizites User=root zusammen mit NoNewPrivileges=yes ließ systemd CAP_SETUID aus dem effektiven Set streichen; der Worker-Start scheiterte mit operation not permitted. Die Unit setzt kein User=/Group= mehr, ein Paketierungstest prüft das.
0.1.6interne Teststufe
Zweiter Beobachtungsbuild auf dem Referenzhost
bekanntes Problem Auf Hosts, deren Unit User=root mit NoNewPrivileges=yes kombinierte, konnte der Worker-Start in einer Restart-Schleife hängen. Behoben in 0.1.7.
0.1.1 – 0.1.4interne Teststufe
Alles, was der erste Host unter Produktionslast zeigte
behoben Veraltete fanotify-Handles planten Rekonsiliationen des Dateisystem-Wurzelverzeichnisses.
behoben JPEGs wurden über <?-Bytes und Entropie als Skripte bewertet.
behoben degraded-Ergebnisse und limitbedingte unscanned-Ergebnisse erzeugten je Datei ein Finding und sprengten den Account-Cap.
behoben Die Audit-Ketten aus JSONL-Log und Store konnten divergieren und den Start blockieren.
behoben SQLite fand unter ProtectSystem=strict kein Temp-Verzeichnis.
behoben clamd lehnte per FILDES übergebene Deskriptoren aus der systemd-Mount-Sandbox ab (AppArmor); der Worker fällt jetzt automatisch auf INSTREAM zurück.
0.1.0interne Teststufe
Erster interner Testbuild
neu Parserfreier Root-Broker, Tier-A-fanotify-Watcher mit Rekonsiliation, Scanner-Worker mit ClamAV, YARA 4 und Hash-Sets, erklärbare Heuristik, crash-sichere Quarantäne-Transaktion mit Restore, Ignore-Listen, Scheduler, JSON-fähige CLI, Mail-Benachrichtigung, signierte Feed-Generationen, Paket-Lebenszyklus, Health-Metriken, PHP-Upload-Adapter und das Policy-Modell je Domain.
Hinweis Auf den Testhosts ausschließlich Report-only: keine automatische Quarantäne, keine Aktivierung des PHP-Adapters, jederzeit rückbaubar.
Wie die Teststufen-Einträge zu lesen sind
Jede dieser Korrekturen entstand daraus, den Scanner im Report-only-Modus gegen echte Kundendaten
auf einem laufenden CyberPanel-Host zu betreiben: 328 Accounts, 1,1 TB, Ubuntu 24.04 mit
OpenLiteSpeed. Nur diese Umgebung erzeugt Fehler wie „clamd lehnt Deskriptoren aus einer
systemd-Mount-Sandbox wegen eines AppArmor-Profils ab" oder „JPEGs werden als Skripte bewertet, weil
sie die zwei Bytes <? enthalten".
Die Regel, nach der wir arbeiten: Was für einen Betreiber sichtbar war, gehört in diese Liste.