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.
Über „Denials ansehen" pro Server öffnet sich eine Liste der zuletzt vom Kernel gemeldeten AppArmor-Blockierungen (Zeitpunkt, Profil, Operation, betroffener Pfad). Diese Liste ist die Datenbasis, um vor dem Umschalten auf Enforce False-Positives zu erkennen — sie zeigt genau, was ein Profil im Complain-Mode blockieren würde.
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.
Schwachstellen- & Support-Sichtbarkeit (CVE, EOL, SBOM)¶
Unterhalb der Server-Checks zeigt die Seite eine Reihe eigenständiger Karten, die unabhängig von jedem Compliance-Rahmen nützlich sind — jeder Kunde profitiert von "läuft hier etwas mit einer bekannten Schwachstelle oder ausgelaufenem Support":
- EOL-Prüfung — PHP- und Debian-Versionen werden gegen ihr Support-Ende geprüft. 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 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.
- PHP im CVE-Feed & PHP-Support-Karte — PHP wird im CVE-Feed erfasst (als Debian-Source-Paket). Zusätzlich zeigt eine eigene PHP-Support-Karte pro installierter PHP-Version, ob sie EOL oder hinter dem neuesten Patch ihres Zweigs ist (Quelle: endoflife.date) — die verlässliche Antwort auch für Versionen, die der OS-CVE-Feed nicht trackt.
- SBOM-CVE-Karte — gleicht die SBOM (CycloneDX) live gegen OSV.dev ab und listet betroffene Komponenten samt Fix-Version.
- Container-CVEs-Karte — bei aktivierter Docker-Extension scannt eine Karte jedes bereitgestellte Container-Image mit Grype neu und listet die kritisch/behebbar/hoch/mittel-Zähler je Website. Ohne die Extension wird sie vollständig ausgeblendet. Sie scannt außerdem alle 12 h neu und benachrichtigt, wenn die Zahl kritischer CVEs steigt.
- security.txt-Generator — veröffentlicht eine RFC-9116-konforme
security.txt(Kontakt, Richtlinie, Ablaufdatum) unter/.well-known/security.txtauf einer gewählten Domain — guter Standard für jede Website, unabhängig von jedem Compliance-Rahmen. - Security-Ring verifiziert — der Update-Check bestätigt nicht nur, dass
unattended-upgradeslä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.
Nachweise & Export¶
Ganz unten auf der Seite gibt es einen eigenen Abschnitt Nachweise & Export — bewusst kein Compliance-Dashboard mehr, sondern gezielt für die eine Kundengruppe gedacht, für die er wirklich relevant ist.
Für wen ist das relevant?
Der Cyber Resilience Act (CRA) verpflichtet Hersteller von Produkten mit digitalen Elementen — nicht die Nutzer eines gehosteten Panels. Wer enconf bei sich betreibt, ist Nutzer, nicht Hersteller von enconf; die CRA-Herstellerpflichten für enconf selbst liegen beim Panel-Hersteller. Relevant ist dieser Abschnitt daher fast ausschließlich für Kunden, die selbst ein Produkt mit digitalen Elementen herstellen und in Verkehr bringen (z. B. eigene Software, die auf dieser Infrastruktur läuft) und dafür Nachweise über ihre Lieferkette brauchen. Für den reinen Betrieb eines Hosting-/DNS-Dienstes greifen primär die NIS2-Pflichten (Art. 21) — und selbst die nur, wenn der Betreiber als wichtige/wesentliche Einrichtung eingestuft ist. Für die meisten Kunden ist dieser Abschnitt schlicht nicht einschlägig.
Enthält:
- Incident-Register — eigene, kundenseitige Dokumentation von Sicherheitsvorfällen.
- Evidence-Snapshots — zeitgestempelte Momentaufnahmen des technischen Zustands für einen Audit-Trail über Zeit.
- Nachweis-Export — Button Nachweis exportieren erzeugt ein zeitgestempeltes, in sich geschlossenes Dokument (HTML oder JSON) mit Panel-Version und dem Status jeder Anhang-I-Anforderung samt Belegen, plus separater SBOM-Export (CycloneDX). Ideal für Kunden-Nachfragen, Cyber-Versicherungs-Fragebögen oder Ausschreibungen — wenn der Kunde selbst Hersteller ist.
Ehrliche Einordnung
Dieser Abschnitt unterstützt technische Nachweisführung durch laufende Überwachung und Dokumentation — er ersetzt keine rechtliche Konformität oder Zertifizierung. Konformitätsbewertung, CE-Kennzeichnung und Meldepflichten bleiben Herstellerpflicht des jeweiligen Produkt-Herstellers. 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.