Fassung 26.10.27.9

Neu

Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.
Die Mailstatistik einer Maildomain und eines Nodes hat einen Abschnitt Spamfilter: wie viele eingehende Mails sauber, vertagt, als Spam markiert und abgelehnt wurden, wie oft jemand Spam selbst in den Junk-Ordner gelegt oder erwünschte Post herausgeholt hat, die Quoten Spam erkannt und Fehlalarme mit einer Empfehlung zur Schwelle und die Verteilung der Punkte mit den Schwellen des Nodes. Als Spam bewertete oder abgelehnte versendete Mail steht als Warnung darunter. Gezählt wird ab dem Update.
Die Liste Sendungen zeigt bei jeder Mail, die Rspamd bewertet hat, ihre Punkte.
Der Bereich Sicherheitslücken prüft auch die Bibliotheken, die eine Software mitbringt: jedes Jar von WildFly, vendor/ von phpMyAdmin und Roundcube, den Inhalt von Composer und WP-CLI und die Go-Module von Programmen aus einer fremden Paketquelle wie CrowdSec. Ein Befund heißt dann etwa io.undertow:undertow-core (wildfly-36.0.1.Final) und sagt, woher der Fix kommt. Ein WildFly 36.0.1 bringt zum Stand dieses Updates rund 90 behebbare Lücken mit, ein wp-cli 2.12.0 ein Composer 2.2.25 mit mehreren hohen.
Für Node.js zählt zusätzlich jede Sicherheitsfassung, die nodejs.org für den installierten Major führt — auch eine, die nur OpenSSL, undici oder npm erneuert und dafür keine CVE der Security-WG hat.
Unter Einstellungen › Sicherheitslücken stehen drei neue Quellen: Node.js Releases (nodejs.org), OSV Maven und OSV Go. Die Control Plane lädt dafür zusätzlich von nodejs.org; eine leere Adresse schaltet eine Quelle ab.
WildFly wird überwacht: fällt er aus oder antwortet er drei Minuten lang nicht, startet Kastra ihn neu — bei einem Hänger nach einem Thread-Dump ins Journal. Zu jedem Ausfall steht unter Laufzeiten › WildFly, wann er war und woran es lag, etwa Speichermangel, ein Absturz der JVM oder ein von außen gesendetes Signal. Nach fünf Neustarts in 30 Minuten gibt Kastra beim nächsten Ausfall auf, hält WildFly an und meldet die neue Alarmart WILDFLY_DOWN mit allen Ursachen. Starten im Panel setzt die Zählung zurück.
Eine Domain lässt sich im neuen Bereich Umzug in eine andere Subscription verschieben — zu einem anderen Kunden oder auf einen anderen Node. Sie zieht mit allen Subdomains, Datenbanken, Cronjobs, FTP-Zugängen, Mail und DNS um; eine Domain, die dieselbe Datenbank nutzt, zieht mit. Die Vorprüfung zeigt die ganze Gruppe mit dem Grund je Domain und prüft beim Wechsel des Nodes, ob dort läuft, was die Gruppe braucht (PHP-Fassung und Erweiterungen, Apache, Node.js, Podman, WAF, Objekt-Cache, Composer, MariaDB, Mail, FTP) und ob er den Sicherungsspeicher der Quelle erreicht, über den die Daten gehen. Gespeicherte Pfade in Cronjobs, Compose-Dateien, Zusatzkonfiguration und PHP-Einstellungen werden umgeschrieben; Dateien der Anwendung, die das alte Verzeichnis nennen, meldet die Vorprüfung. Nur für Administratoren.
Zieht eine Domain, die auf WildFly zeigt, auf einen anderen Node, zieht WildFly mit — samt Anwendungen, Konfiguration und jeder anderen Domain, die ebenfalls darauf zeigt, auch aus fremden Subscriptions. Die Vorprüfung nennt das in einem eigenen Block und verlangt eine Bestätigung; auf dem Ziel darf noch kein WildFly laufen.
Ein gescheiterter Domain-Umzug auf einen anderen Node lässt sich zurücknehmen; Quelle freigeben entfernt danach die alten Daten. Beides steht auch im Bereich Umzug der Subscriptions.
Eine Subdomain kann allein umziehen: im Bereich Umzug einer Subdomain gibt es die Wahl Nur … herauslösen. Sie zieht samt ihren eigenen Subdomains in die Ziel-Subscription — auch auf einen anderen Node — und ist dort eine eigene Domain. Ihr Ordner behält seinen Pfad unter dem Ordner der Subscription (…/example.com/shop.example.com); zieht die Hauptdomain später nach, kommt sie in denselben Ordner dazu. Die Hauptdomain und ihre übrigen Subdomains bleiben, wo sie sind, und liefern während des Umzugs weiter aus. Die DNS-Einträge bleiben in der Zone der Hauptdomain, beim Wechsel des Nodes werden dort nur ihre Adressen umgestellt. Teilt die Hauptdomain eine Datenbank mit der Subdomain, weist die Vorprüfung das Herauslösen ab, statt die ganze Domain umzuziehen.

Geändert

Welche DNS-Zone zu einer Domain gehört, sucht Kastra über den Namen: die eigene, sonst die Zone mit dem längsten Namen darüber. Dadurch finden auch Subdomains zweiter Stufe (a.shop.example.com) die Zone ihrer Hauptdomain — ihre Adressen werden nachgeführt und im Befund geprüft. Zone entfernen nennt in der Bestätigung Domains anderer Subscriptions, deren Adressen in der Zone stehen.
Ein im Panel angehaltener WildFly bleibt für Kastra angehalten; wer ihn auf dem Node mit systemctl stop anhält, findet ihn dagegen eine Minute später wieder laufend. Ein WildFly, der vor dem Update als angehalten gemeldet war, gilt danach als im Panel angehalten.
Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
Das Webmail richtet Kastra mit Roundcube 1.7.5 statt 1.7.3 ein. Die Fassung schließt die Sicherheitslücken in league/commonmark, die Sicherheitslücken am Node meldet, und die Lücken, die Roundcube 1.7.4 und 1.7.5 selbst beheben. Ein vorhandener Node bekommt sie, wenn unter Komponenten beim Webmail erneut Einrichten gewählt wird; Datenbank und Einstellungen bleiben dabei erhalten.
Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.
Die WildFly-Verwaltungskonsole öffnet sich auf Port 8447 desselben Namens wie das Panel, etwa https://panel.example:8447/console/index.html. Bisher lief sie unter der Adresse des Panels, und ein Skript der Konsole hätte das Panel mit der Sitzung des angemeldeten Administrators bedienen können. Die Firewall von Kastra gibt Port 8447 auf dem Node des Panels frei, unter denselben Regeln wie SSH und das Panel; eine Firewall oder ein eigener Proxy davor muss ihn ebenfalls durchlassen, sonst bleibt der Rahmen leer. Ein bestehender Panel-Vhost bekommt den neuen Server-Block beim Update, die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsolenport liegen.
Wer unter Einstellungen › Aktualisierung Repository, Versionsauskunft oder Signaturschlüssel ändert, gibt dazu den Code aus der App oder das aktuelle Passwort an; ein Konto nur mit Passkey braucht eine Anmeldung, die keine zehn Minuten zurückliegt. Beide Adressen müssen http:// oder https:// ohne Leerzeichen, Anmeldedaten, Abfrage oder Anker sein, der Schlüssel ein öffentlicher PGP-Schlüssel. Bisher genügte die Sitzung, und die Adresse ging ungeprüft in die apt-Quelle jedes Nodes.
Eine Anmeldung mit falschem Einmalcode, an einem gesperrten oder an einem deaktivierten Konto bekommt dieselbe Meldung wie eine mit falschem Passwort: Benutzername, Passwort oder Einmalcode ist falsch. Der Hinweis darunter nennt die Sperre nach fünf Fehlversuchen als möglichen Grund. Bisher verrieten eigene Meldungen, dass es das Konto gibt, in welchem Zustand es ist oder dass das Passwort stimmte.
Von einer Adresse lassen sich höchstens 60 Passkey-Anmeldungen je Minute beginnen; darüber kommt eine Meldung, die Anmeldung mit Passwort bleibt möglich. Die Mengengrenze der ACME-Delegation zählt IPv6-Adressen je /64 statt je Adresse.
Je Subscription sind höchstens vier Web-Terminals gleichzeitig offen, je Node 32, und je Node höchstens 64 Live-Protokolle. Darüber nennt das Panel die Grenze, statt ein weiteres zu öffnen.
Die privaten Schlüssel der Zertifikate liegen verschlüsselt in der Datenbank, sobald KASTRA_SECRET_KEY gesetzt ist; vorhandene werden beim ersten Start nach dem Update umgestellt.
/actuator ist außer /actuator/health nur noch für angemeldete Administratoren erreichbar. Steht die Verbundadresse KASTRA_CLUSTER_BASE_URL nicht auf https://, meldet die Control Plane das beim Start als Fehler.
Ein stillgelegter Node wird sofort getrennt. Bisher redete sein Agent weiter, bis er sich von selbst neu verband.
Bei einem unerwarteten Fehler sehen nur Administratoren die Ursache im Feld Detail; alle anderen bekommen die Correlation-ID, unter der sie im Protokoll steht.

Behoben

Der Bereich FTP einer Subscription oder Domain zeigt auf einem Node, auf dem FTP ausgeschaltet ist, keine Fehlerkarte „kein FTP-Dienst eingerichtet“ mehr; das Protokoll bleibt dort einfach leer.
Wird die JVM von WildFly hart beendet (kill -9), startet WildFly wieder. Bisher blieb er in diesem Fall aus, und im Serverprotokoll stand nichts dazu.
Ein frisch eingeschalteter Mailserver nimmt Mail von außen an. Bisher horchte Postfix nach dem Einschalten weiter nur auf 127.0.0.1:25, weil der Rollout es nur neu geladen statt neu gestartet hat, und unter Komponenten blieb „horchen auf Port 25 aber nur auf 127.0.0.1“ stehen. Ein Node, der so hängen geblieben ist, kommt mit dem nächsten Rollout nach dem Update von selbst in Ordnung; Postfix startet dabei einmal neu.
Das Lebensende von PHP, Node.js und der Distribution wird wieder geladen. Lag auf einem Node WildFly, scheiterte der ganze Abruf von endoflife.date, weil es dort kein Produkt WildFly gibt.
Unter Einstellungen › Sicherheitslücken steht eine Quelle, die kein Node braucht, als nicht benötigt statt noch nie abgerufen — etwa php.net, solange kein Node PHP aus sury hat. Die Seite Sicherheitslücken zeigte eine nie abgerufene Quelle bisher als aktuell.
Die Schwachstellendaten werden jede Nacht abgerufen. Nach einem Abruf von Hand am Nachmittag fiel bisher die folgende Nacht aus.
Alarme per Mail oder Webhook kommen wieder an. Bisher blieben sie oft unzugestellt und standen unter Einstellungen › Alarmierung dauerhaft als wartend — betroffen war jede Alarmart außer der Probemeldung, etwa Node nicht erreichbar oder Verwaltete Dateien verändert.
Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
Ein Repository, an dem kein GitHub-Konto hängt — etwa nach einem Domain-Umzug —, lässt sich über Bearbeiten wieder mit einem Konto verbinden. Bisher bot der Dialog die Auswahl nur beim Hinzufügen an, und der Hinweis „wähle es am Repository aus“ führte ins Leere; es blieb nur, den Eintrag zu entfernen und neu anzulegen.
Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.
Die Control Plane läuft auf Spring Boot 4.1 (Spring Framework 7, Tomcat 11, Hibernate 7). Damit sind 24 bekannte Lücken in ihren Bibliotheken geschlossen, darunter drei kritische in Tomcat und zwei in BouncyCastle; für die bisherige Spring-Linie gibt es keine freien Sicherheitsupdates mehr. Am Betrieb ändert sich nichts: Einstellungen, Umgebungsvariablen und die Antworten der Schnittstelle bleiben gleich.
Auf Ubuntu-Nodes werden die Pakete der Distribution gegen die Sicherheitsdaten von Canonical abgeglichen, und phpMyAdmin, Roundcube, Composer und WP-CLI gegen OSV. Bisher standen sie trotz geladener Daten als nicht erfasst da — es lagen „noch keine Schwachstellendaten vor“.
Die nginx-Zusatzkonfiguration einer Domain prüft jetzt jede Anweisung einer Zeile, nicht nur das erste Wort. Eine zweite Anweisung hinter einem Semikolon — etwa expires 1h; proxy_pass … oder ein über Klammern eingeschleuster location-Block mit alias /etc/ — wird mit der ganzen Zeile verworfen und steht unter den Hinweisen des Rollouts. access_log ist nur noch zum Abschalten (off) erlaubt. Bisher kam alles hinter dem ersten Wort ungeprüft durch.
Eine Weiterleitung, ein Catch-All-Ziel und der Name eines Versandzugangs nehmen nur noch eine Adresse der eigenen Maildomain an; ein erlaubter Absender ebenso. Bisher ließ sich darüber die Post einer fremden Maildomain auf demselben Node umleiten oder unter ihrem Namen versenden. Ein Versandzugang bekommt nur noch dann eine DKIM-Signatur, wenn die Domain seiner Anmeldung zur Domain im Absender passt.
Der Datenbankabzug einer Sicherung folgt im Heimatverzeichnis keinem symbolischen Verweis mehr. Bisher hätte ein Verweis ~/.kastra-sicherung auf ein Systemverzeichnis dieses beim nächsten Sicherungslauf übereignen oder überschreiben können.
Das Aufgabenprotokoll zeigt einem Kunden nicht mehr den Rollout-Diff des ganzen Nodes. Bisher stand im Feld der abgeschlossenen Aufgabe die geänderte Konfiguration aller Kunden des Nodes samt Mail-Passwortdatei und privaten Schlüsseln; Administratoren sehen ihn weiterhin.
Einen neuen Passkey hinzufügen, TOTP (neu) einrichten und ein API-Token anlegen verlangen jetzt denselben zweiten Nachweis wie das Widerrufen eines Passkeys — einen Code aus der Authenticator-App, das aktuelle Passwort oder eine frische Anmeldung. Bisher genügte dafür die Sitzung, und ein fremder Zugriff auf eine angemeldete Sitzung konnte sich damit dauerhaft einnisten.
Die Sperre nach fünf Fehlversuchen trifft nur noch die Passwortanmeldung. Ein Konto ohne Passwortanmeldung zählt keine Fehlversuche mehr, und eine bestehende Sperre hält Passkey und Wiederherstellungscode nicht länger auf. Bisher ließ sich ein Konto, das nur per Passkey erreichbar ist, mit fünf Anfragen aussperren.
Meldet sich ein Node mit einem anderen Zertifikat als dem, das bei seiner Anmeldung ausgestellt wurde, wird er abgewiesen. Damit verliert ein ausgetauschter oder abgegebener Rechner seinen Zugang, sobald sich an seiner Stelle ein neuer anmeldet.
Eine Subdomain einer fremden Domain lässt sich nicht mehr als eigene Hauptdomain anlegen. Bisher hätte ein Kunde so eine Domain samt eigener DNS-Zone und Zertifikat unter einem fremden Namen beanspruchen können.
Ein Virenscan und ein Rückspieltest halten keine Datenbankverbindung mehr über ihre ganze Laufzeit. Bisher konnten mehrere gleichzeitig gestartete Läufe die Control Plane ausbremsen.
Grundbausteine der Control Plane sind auf aktuelle, abgesicherte Fassungen gehoben: Spring Boot 3.5.16, gRPC 1.76 (darin Netty mit den Fixes gegen CVE-2025-24970 und CVE-2025-55163 — ein Absturz des gesamten Dienstes über ein präpariertes TLS- bzw. HTTP/2-Paket) und die JWT-Bibliothek 10.0.2 (CVE-2025-53864, ein Lahmlegen über ein verschachteltes Sitzungscookie).
READONLY-Konten können kein Web-Terminal mehr öffnen; das war Schreibzugriff und widersprach der Rolle.
Ein Kunde kann die Übernahme eines Postfachs nur noch von einem öffentlichen IMAP-Server auf Port 143 oder 993 anstoßen. Bisher ließ sich damit das interne Netz des Nodes abtasten.
Die Statusseite zeigt einem Kunden das Gesamtbild, aber nicht mehr die einzelnen Vorfälle anderer Kunden samt Node-Namen.
Ein Sicherungsziel lässt sich nur noch auswählen, wenn es auf dem Node der Subscription liegt. Bisher hätte ein Kunde das Ziel eines fremden Nodes anhängen können.
Ein SFTP-Unterverzeichnis, das über einen symbolischen Verweis aus dem Heimatverzeichnis führt, wird abgewiesen statt eingehängt.
Fällige Sicherungen und Suchläufe nach Schadsoftware laufen jetzt nebenläufig an und halten einander nicht mehr auf. Bisher konnte ein langer Lauf dazu führen, dass eine Regel, die kurz danach fällig war, in dieser Nacht gar nicht lief — ohne Meldung.
Die Aufbewahrungsfrist des Audit-Logs wirkt. Bisher verhinderte ein Schutz gegen Änderungen auch das Löschen alter Einträge, und das Audit-Log wuchs trotz eingestellter Frist unbegrenzt.
Mail lässt sich nicht mehr für eine gleichnamige Maildomain eines anderen Kunden ein- oder ausschalten.
Den Node einer Maildomain und einer DNS-Zone sowie Art und Herkunft einer Zone wählt nur noch ein Administrator; ein Kunde bekommt den vorgesehenen Node.
Ein Rückspieltest schreibt nicht mehr durch einen symbolischen Verweis im Heimatverzeichnis an eine fremde Stelle.
Drift-Berichte eines Nodes werden gedeckelt gespeichert (höchstens 1000 Zeilen je Bericht, Diff gekürzt), statt die Datenbank bei dauerhafter Abweichung zu füllen.
Ein Node schreibt nur noch in sein eigenes Update-Protokoll, nicht mehr in das eines anderen.
Gleichzeitige Anmeldeversuche können die Control Plane nicht mehr über den Speicher der Passwortprüfung lahmlegen (höchstens vier gleichzeitige Prüfungen, der Rest wartet kurz).
Eine Container-Angabe mit einem Bind-Mount in der langen Form außerhalb des Subscription-Verzeichnisses oder mit einem auf 0.0.0.0 veröffentlichten Port wird jetzt ebenfalls abgewiesen.
Der Panel-Vhost nennt die nginx-Fassung nicht mehr (server_tokens off), beschränkt die TLS-1.2-Verschlüsselung auf Verfahren mit Vorwärtsgeheimnis (ssl_ciphers), erlaubt per connect-src nur noch Verbindungen zum Panel selbst, sperrt vendor/ unter phpMyAdmin und nimmt unter /api/ höchstens 64 MB an, ohne sie vor der Anmeldung auf die Platte zu puffern. Ein bestehender Vhost bekommt das beim Update nachgetragen; die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-pruefbericht liegen.
Ein Einmalcode aus der Authenticator-App lässt sich auch bei zwei gleichzeitigen Anmeldungen nur einmal verwenden.
Verbindet sich ein Node neu, während seine alte Verbindung noch abgebaut wird, bleibt er verbunden. Bisher scheiterten seine laufenden Aufgaben dann mit Node nicht erreichbar, und er stand bis zum nächsten Herzschlag als getrennt da.
Alarme per Mail oder Webhook werden auf eigenen Fäden zugestellt. Ein langsamer Mailserver oder Webhook hält keinen Rollout und keine Datenbankverbindung mehr auf.
Ein Hostname, der kein gültiger Rechnername ist, wird beim Anmelden eines Nodes abgewiesen. Bisher ging er ungeprüft ins Zertifikat und in die Betreffzeile von Alarmmails.
Ein Anmelde-Token mit Hostnamen gilt nur noch für genau diesen Namen: ein Rechner, der sich unter einem anderen meldet, wird abgewiesen, und das Token bleibt gültig. Bisher meldete sich damit jeder Rechner unter jedem freien Namen an. Der Befehl unter Nodes › Node aufnehmen nennt dafür den Hostnamen aus dem Token mit.
kastractl node token gibt den Befehl für den Node samt Fingerabdruck der CA aus, und als Adresse den Panel-Namen. Bisher fehlte der Fingerabdruck, und der Agent wies den Befehl ab; die Adresse war der Rechnername des Panel-Hosts, auf den das Zertifikat der Control Plane nicht lauten muss.
Ein neues FTP-Passwort wird in einem Feld unter dem Zugang eingegeben. Bisher fragte ein Browser-Dialog danach, der es im Klartext zeigte.
Passwortfelder für Postfächer, Sicherungsziele, Alarmkanäle und Datenbanken füllt der Browser nicht mehr mit dem gespeicherten Panel-Passwort.
Wechselt man die Domain, verschwinden die einmaligen Zugangsdaten einer gerade angelegten ACME-Delegation. Bisher standen sie unter der nächsten Domain weiter da.
Auf einem Panel, das vor dem 31. August 2026 eingerichtet wurde, öffnet sich die WildFly-Verwaltungskonsole. Seinem Vhost fehlte die Regel für die Konsole, und kein Update trug sie nach; seit die Konsole auf Port 8447 liegt, meldete der Rahmen nur noch, der Server habe die Verbindung abgelehnt. Das Update trägt Regel und Port jetzt nach, die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsole liegen.
Auf einem Panel, das vor dem 1. September 2026 eingerichtet wurde, tragen die Oberfläche und ihre Dateien dieselben Sicherheitskopfzeilen wie auf einer neuen Anlage: Content-Security-Policy, X-Frame-Options, HSTS, nosniff und Referrer-Policy. Bisher kam das Panel dort ohne sie beim Browser an und ließ sich von jeder fremden Seite einrahmen. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-kopfzeilen liegen.
Auf einem Panel, das seit dem 1. September 2026 eingerichtet wurde, verbot die Sicherheitsregel des Panels phpMyAdmin das Skript, mit dem es seine Seiten in Gang setzt. phpMyAdmin bekommt jetzt eine eigene Regel, die das zulässt und es weiterhin vor fremden Rahmen schützt. Kartenkacheln für GIS-Daten lädt phpMyAdmin nicht von außen nach. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-phpmyadmin liegen.

Eingriffe am Node

W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

nft — auf dem Node, der das Panel trägt, lässt die Verwaltungsregel neben 22 und 8443 auch Port 8447 zu (WildFly-Konsole), mit derselben Drosselung bzw. denselben Admin-Netzen.
wildfly-unit — /etc/systemd/system/kastra-wildfly.service trägt Restart=always statt Restart=on-failure, StartLimitIntervalSec=1800, StartLimitBurst=6 und WorkingDirectory=-/opt/wildfly/standalone. Der Agent zieht eine bestehende Unit nach seinem Start einmal nach; ein laufender WildFly wird dabei nicht neu gestartet, die Werte gelten ab dem nächsten Start.
fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
logrotate — php-slow.log wird mit php-error.log gedreht.
mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen und jede Korrektur ins Mailprotokoll schreiben; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.