Security Advisor¶

Der Security Advisor prüft die Sicherheitskonfiguration jedes angebundenen Servers sowie panelweite Einstellungen und fasst die Ergebnisse in einem Score zusammen. Jede Prüfung liefert eine Bewertung (Bestanden, Warnung oder Kritisch) und – wo sicher möglich – einen Ein-Klick-Fix.

Die Seite finden Sie im Admin-Bereich unter Security Advisor.

Score-Übersicht¶

Oben zeigt eine Ringgrafik das Verhältnis bestandener zu geprüften Checks (z. B. 12/15).

Score	Farbe	Bedeutung
≥ 80 % bestanden	Grün	Gute Grundhärtung
50–79 % bestanden	Gelb	Verbesserungen empfohlen
< 50 % bestanden	Rot	Dringender Handlungsbedarf

Die einzelnen Prüfungen werden darunter als Karten angezeigt und automatisch sortiert: Kritisch zuerst, dann Warnungen, dann bestandene Checks. Bei Multi-Server-Setups trägt jede Karte den Namen des betroffenen Servers.

Live-Abfrage

Die Daten werden bei jedem Aufruf frisch von jedem aktiven Server abgefragt (nicht gecacht). Über Aktualisieren oben rechts können Sie die Prüfung erneut auslösen.

Panel-Prüfungen¶

Diese Checks betreffen das Panel selbst, unabhängig vom Server.

Prüfung	Bestanden wenn	Fix
Passwort-Mindestlänge	Mindestlänge ≥ 12 Zeichen (sonst Warnung)	Setzt die Mindestlänge auf 12
Brute-Force-Schutz	Login-Schutz aktiv (Max. Versuche und Sperrzeit gesetzt), sonst Kritisch	Aktiviert den Schutz (5 Versuche, 15 Min. Sperre)

Beide Fixes ändern die entsprechenden Panel-Einstellungen direkt. Die Feinjustierung nehmen Sie unter Einstellungen > Sicherheit vor.

Server-Prüfungen¶

Diese Checks werden vom Agent auf jedem aktiven Server ausgeführt.

SSH¶

Prüfung	Bestanden	Warnung	Kritisch
Root-Login (`PermitRootLogin`)	`no`	`prohibit-password` / `forced-commands-only`	`yes`
Passwort-Authentifizierung	`no` (nur Schlüssel)	`yes`	–
SSH-Port	Nicht-Standard-Port	Port 22	–

Firewall & Brute-Force¶

Prüfung	Bestanden	Kritisch / Warnung
nftables-Firewall	Dienst aktiv	Kritisch, wenn inaktiv
fail2ban	Dienst aktiv	Kritisch, wenn nicht läuft
fail2ban SSH-Jail (`sshd`)	Jail aktiv	Warnung, wenn nicht aktiv

System & PHP¶

Prüfung	Bestanden	Warnung / Kritisch
Unattended Upgrades	Automatische Sicherheitsupdates aktiv	Warnung, wenn deaktiviert
PHP-Version	Keine EOL-Version installiert	Kritisch, wenn PHP < 8.1 gefunden wird

Automatische Fixes¶

Karten mit dem Status Warnung oder Kritisch bieten einen Beheben-Button. Folgende Server-Fixes sind hinterlegt:

Check	Was der Fix tut
`ssh_root_login`	Setzt `PermitRootLogin no` (Drop-in `/etc/ssh/sshd_config.d/enconf.conf`), reload sshd
`ssh_password_auth`	Setzt `PasswordAuthentication no`, reload sshd
`firewall_active`	`systemctl enable --now nftables`
`fail2ban_active`	`systemctl enable --now fail2ban`
`fail2ban_ssh_jail`	Legt `sshd`-Jail an und startet fail2ban neu
`unattended_upgrades`	Installiert und aktiviert `unattended-upgrades`

SSH-Fixes brauchen eine Bestätigung

Vor jedem SSH-Fix erscheint eine Rückfrage. Der Agent hat zusätzlich fest verdrahtete Schutzmechanismen, damit Sie sich nicht aussperren:

Root-Login deaktivieren wird abgelehnt, solange kein anderer Benutzer einen authorized_keys-Eintrag hat.
Passwort-Auth deaktivieren wird abgelehnt, solange kein Benutzer einen SSH-Key hinterlegt hat.
SSH-Port wird nie automatisch geändert – das müssen Sie manuell und mit angepasster Firewall/Konsole tun.

In diesen Fällen bleibt der Check unverändert und Sie erhalten eine erklärende Meldung.

AppArmor-Status¶

Ist AppArmor auf mindestens einem Server verfügbar, erscheint eine eigene AppArmor-Karte mit einer Zusammenfassung über alle Server:

Kennzahl	Bedeutung
Server	Server mit verfügbarem AppArmor / Gesamtzahl
Profile	Anzahl geladener `enconf-<user>`-Profile
Complain	Profile im Complain-Mode
Enforce	Profile im Enforce-Mode

Darunter listet die Karte jeden Server einzeln auf (geladene Profile gesamt, davon enforce/complain, davon enconf-Profile) mit einem Umschalter Complain ↔ Enforce.

Complain-Mode ist der Auslieferungszustand

enconf erzeugt für jedes Kunden-PHP-FPM ein eigenes AppArmor-Profil (enconf-<user>) und lädt es im Complain-Mode. In diesem Modus wird nichts blockiert – Regelverstöße werden lediglich nach syslog protokolliert. Das ist die aktive Absicherung und dient dazu, echtes Kundenverhalten zu beobachten, bevor blockiert wird.

Enforce-Mode ist eine bewusste Entscheidung (Phase 2)

Der Umschalter kann die Profile eines Servers auf Enforce stellen – dann werden Verstöße tatsächlich blockiert. Aktivieren Sie das erst, wenn Sie über die Complain-Logs genügend Daten gesammelt haben, um False-Positives auszuschließen. Andernfalls können legitime Kunden-PHP-Aufrufe brechen.

Schlägt das Laden im Enforce-Mode fehl, fällt der Server automatisch auf Complain zurück; die Karte zeigt dann einen entsprechenden Hinweis.

CRA-Compliance¶

Der Security Advisor hat einen zweiten Tab CRA-Compliance. Er bewertet die laufenden Sicherheits-Prüfungen gegen die Anforderungen des Cyber Resilience Act (Verordnung (EU) 2024/2847, Anhang I) und macht daraus einen Readiness-Nachweis.

Anforderungs-Katalog — jede CRA-Anforderung (Zugriffsschutz, Angriffsfläche, DoS-Widerstand, Sicherheitsupdates, Support-Zeitraum/EOL, Ausnutzungs-Minderung) wird mit den Advisor-Checks belegt, die sie stützen — inkl. Verweis auf die Anhang-I-Fundstelle.
Readiness-Score — Prozentsatz der erfüllten von den bewertbaren Anforderungen.
EOL-Prüfung — PHP- und Debian-Versionen werden gegen ihr Support-Ende geprüft (End-of-Life = Sicherheitslücke im Sinne des CRA-Support-Zeitraums). Jede installierte PHP-Version wird erfasst — auch zusätzlich installierte alte Versionen.
Komponenten-Inventur — Web (nginx), FTP (ProFTPD), Mail (Postfix/Dovecot/rspamd), Datenbank (MariaDB) und DNS (PowerDNS) werden namentlich mit Version im Nachweis aufgeführt. Diese Dienste stammen aus den Debian-Paketquellen und erhalten Sicherheits-Backports über den gesamten OS-Lebenszyklus — die Versionsnummer ist daher kein EOL-Signal, entscheidend sind OS-Support (OS-EOL) und automatische Updates.
Security-Ring verifiziert — der Update-Check bestätigt nicht nur, dass unattended-upgrades läuft, sondern dass die Debian-Security-Suite (<codename>-security) als Quelle konfiguriert ist, im Origins-Pattern steht und der periodische Trigger (APT::Periodic::Unattended-Upgrade "1") aktiv ist. Nur dann fließen Security-Fixes wirklich.
Pro-Dienst-Härtung — dedizierte Checks über die Inventur hinaus: Mail-Transport-TLS (Postfix), MariaDB nicht öffentlich erreichbar, ProFTPD-chroot (DefaultRoot ~), sowie fail2ban-Jails für Mail und FTP (nicht nur SSH).
Informative Checks — nginx (HTTPS-Abdeckung: wie viele Vhosts ein TLS-Zertifikat haben) und PowerDNS (DNSSEC-Abdeckung: wie viele Zonen signiert sind). Bewusst informativ statt rote Ampel, weil TLS pro Vhost und DNSSEC pro Zone optional sein können.

Ehrliche Einordnung: CRA vs. NIS2

Der CRA verpflichtet Hersteller von Produkten mit digitalen Elementen — ein Hosting-/Managed-Dienst ist selbst kein CRA-Produkt. CRA-relevant ist daher (a) enconf als Produkt (Pflicht seines Herstellers) und (b) dieses Dashboard als Umgebungs-Nachweis für Kunden, die selbst Produkte herstellen. Für den Betrieb eines Hosting-/DNS-Dienstes greifen primär die NIS2-Pflichten (Art. 21 Risikomanagement-Maßnahmen). Die hier geprüften technischen Maßnahmen (Patch-Management, Kryptografie, Zugriffskontrolle, Härtung) decken beide Rahmen weitgehend mit ab — das Dashboard liefert Nachweise, keine rechtliche Konformität.

Nachweis-Export — Button Nachweis exportieren erzeugt ein zeitgestempeltes, in sich geschlossenes Dokument (HTML oder JSON) mit Panel-Version, Score und je Anforderung dem Status samt Belegen. Ideal für Kunden-Nachfragen, Cyber-Versicherungs-Fragebögen oder Ausschreibungen.

Ehrliche Einordnung

Das Cockpit unterstützt die technischen CRA-Anforderungen durch laufende Überwachung und Nachweis-Dokumentation — es ersetzt keine rechtliche Konformität oder Zertifizierung. Konformitätsbewertung, CE-Kennzeichnung und Meldepflichten bleiben Herstellerpflicht. Dieser Hinweis steht auch in jedem exportierten Dokument.

Einordnung: Was aktiv ist, was Phase 2 ist¶

Der Advisor spiegelt den realen Härtungsstand wider und übertreibt nicht:

Aktiv und ausgerollt: eigener Linux-User pro Website, Webroot 0710, PHP-FPM-Pool pro Website, open_basedir, disable_functions, Per-Customer /tmp, MariaDB-Grants pro Kunde, root-only Panel-Secrets, ProFTPD-chroot, nftables SMTP-Egress-Block, fail2ban, systemd-Slices pro Kunde und AppArmor-Profile im Complain-Mode.
Phase 2 (nicht als Standard aktiv): AppArmor-Enforce-Mode pro Server (über den Umschalter opt-in), tiergestufte systemd-Slice-Limits.
Architektonisch nicht isolierbar: geteilter Kernel, eine MariaDB-Instanz, gemeinsames PHP-Binary, eine Postfix/Dovecot/PowerDNS-Instanz – das gilt für jedes Single-Kernel-Panel und ist nur mit Updates zu mitigieren.

Die vollständige Aufstellung finden Sie unter Sicherheit.