shelltrap.com
en de

Changelog

Changelog

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.

Erstes lizenziertes Release: Lizenz-Gate, signierte Feeds, WordPress-Core-Allowlisten

  • 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.

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.

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.

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.

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.

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.

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.

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.