Sicherheit

enconf bietet mehrere Sicherheitsschichten zum Schutz des Panels und der gehosteten Websites.

---

Kunden-Isolation (Defense in Depth)

enconf isoliert jeden Kunden auf mehreren unabhängigen Schichten. Wichtig zu wissen: 100% Isolation auf einem Single-Kernel-System ist physikalisch nicht möglich — das geht nur mit Containern oder VMs. Was wir bauen ist Defense in Depth: jede Schicht muss für einen erfolgreichen Cross-Tenant-Angriff einzeln umgangen werden.

Aktiv und automatisch ausgerollt

Schicht	Was sie schützt
Eigener Linux-User pro Kunde	Standard-Unix-DAC. Dateien gehören dem Customer, sind nicht für andere lesbar.
Webroot-Mode 0710 user:www-data	Owner darf alles, Nginx (www-data) darf traversieren, alle anderen Customer haben kein Zugriff — können nicht mal in das Verzeichnis cd-en.
PHP-FPM Pool pro Kunde	Eigener User/Group — PHP läuft mit Customer-Identität, kein shared www-data-Prozess.
open_basedir	PHP-Requests können nur in <docroot>:<tmpDir>:/usr/share/php:/var/cache/php lesen/schreiben.
disable_functions	exec, passthru, shell_exec, system, popen, proc_open, dl, alle pcntl_* deaktiviert — kein Shell-Zugriff via PHP.
Per-Customer /tmp/<user> mode 0700	Eigener Pfad für session.save_path, upload_tmp_dir, sys_temp_dir. Kein Cross-Tenant Session/Upload-Leak via shared /tmp oder /var/lib/php/sessions/.
MariaDB-Grants pro Kunde	GRANT … ON customer_db.* strikt — kein User mit globalen Rechten. Cross-DB-Queries blockiert.
Panel-Secrets 0600 root:root	JWT_SECRET, DB_PASSWORD, AGENT_TOKEN sind für Customer-PHP-Pools nicht lesbar.
ProFTPD DefaultRoot ~	FTP/SFTP-User chrooted in eigenes Home — kann nicht zu anderen Customern oder System-Pfaden navigieren.
Nginx Upload-Path-Block	.php in Upload-Verzeichnissen wird nicht ausgeführt — schließt das häufigste WordPress-Hack-Pattern.
HTTPS-Catch-all (inkl. HTTP/3)	Ein Name, den kein Vhost bedient, bekommt ein neutrales, selbstsigniertes Zertifikat und eine 404-Antwort — nie das Zertifikat eines Kunden. Das gilt auch für HTTP/3 (QUIC); dort lieferte der Server früher das Zertifikat des ersten Kunden in der Konfiguration aus.
nftables SMTP-Egress-Block	Customer-PHP kann nicht direkt zu fremden SMTP-Servern verbinden — Spam-Schutz. Nur authentifizierte Submission via 587.
FFI deaktiviert	ffi.enable=0 — schließt den FFI::cdef→libc-Umweg um disable_functions.
AppArmor-Profil pro Kunde	Eigenes Profil je PHP-FPM; pro Server zwischen Complain- und Enforce-Modus umschaltbar, mit Auto-Rückfall bei False-Positive-Häufung.
systemd-Slice pro Kunde	MemoryMax / CPUQuota / TasksMax / IO — greift für neue und bestehende Sites.
Kernel-Härtung (sysctl)	kptr_restrict, dmesg_restrict, ptrace_scope, unprivileged_bpf_disabled u. a.
fail2ban	Brute-Force-Schutz für SSH, FTP, Mail, Panel-Login.
Per-Customer Nginx Logs	Logs unter /var/www/customers/<user>/logs/ getrennt — kein Cross-Tenant Log-Reading.
Hardening-Migration beim Agent-Start	Bestehende Sites werden bei Updates automatisch auf den aktuellen Hardening-Stand gebracht (idempotent).

Nachweisbarkeit (aktiv)

Schicht	Status
Pro-Kunde-Sicherheits-Score	Jeder Kunde sieht im Dashboard live, welche Isolationsschichten je Website wirklich aktiv sind.
Security Advisor	Serverweite Audit-Checkliste, SBOM, Live-CVE-Feed, Nachweise & Export.
SIEM-Log-Forwarding	Sicherheits-Logs flottenweit über TLS an einen Collector.

Ausführlich: siehe Sicherheitsarchitektur-Whitepaper.

Geplant (Phase 2)

Schicht	Status
AppArmor Enforce flottenweit	Enforce-Toggle pro Server ist gebaut; der breite Rollout wartet auf ausreichend Complain-Beobachtungsdaten.
Echte Kernel-Isolation als Default	Rootless Container (gVisor) opt-in verfügbar; als Standard für untrusted Workloads noch nicht gesetzt.

Was grundsätzlich nicht isoliert ist

Diese Punkte betreffen jedes Single-Kernel-Single-MariaDB-System (auch Plesk, cPanel, CyberPanel) und sind nicht durch Panel-Layer behebbar:

• Linux-Kernel — alle Customer teilen einen Kernel. Mitigation: Kernel-Updates zeitnah einspielen.
• MariaDB-Prozess — eine Instanz für alle. Mitigation: Updates.
• PHP-Binary — alle Pools mit derselben PHP-Version teilen den Binary-Code.
• Postfix/Dovecot/PowerDNS — eine Instanz für alle Domains.

---

Zwei-Faktor-Authentifizierung (2FA)

2FA schützt den Panel-Zugang durch einen zusätzlichen Authentifizierungsfaktor neben dem Passwort.

2FA aktivieren

1. Navigieren Sie zu Einstellungen > Sicherheit (oder Einstellungen > Passwort)
2. Klicken Sie auf 2FA einrichten
3. Scannen Sie den QR-Code mit einer Authenticator-App:
4. Google Authenticator
5. Authy
6. Microsoft Authenticator
7. FreeOTP
8. Geben Sie den angezeigten 6-stelligen Code ein
9. Klicken Sie auf Bestätigen

Backup-Codes

Notieren Sie sich den geheimen Schlüssel (Secret), der unter dem QR-Code angezeigt wird. Damit können Sie den Zugang wiederherstellen, falls Sie das Gerät verlieren.

2FA deaktivieren

1. Navigieren Sie zu Einstellungen > Sicherheit
2. Klicken Sie auf 2FA deaktivieren
3. Geben Sie Ihr aktuelles Passwort zur Bestätigung ein
4. Klicken Sie auf Deaktivieren

Login mit 2FA

1. Geben Sie E-Mail und Passwort ein
2. Geben Sie den 6-stelligen Code aus Ihrer Authenticator-App ein
3. Klicken Sie auf Anmelden

TOTP-Protokoll

WebPanel verwendet das TOTP-Protokoll (Time-based One-Time Password), das von allen gängigen Authenticator-Apps unterstützt wird.

---

2FA-Richtlinie erzwingen

Als Administrator können Sie festlegen, dass bestimmte Benutzergruppen zwingend 2FA einrichten müssen.

Konfiguration

1. Navigieren Sie zu Einstellungen > Sicherheit
2. Wählen Sie unter 2FA erzwingen die gewünschte Richtlinie:

Option	Beschreibung
Deaktiviert	2FA ist optional für alle Benutzer
Admins	Admins müssen 2FA einrichten
Admins & Reseller	Admins und Reseller müssen 2FA einrichten
Alle Benutzer	Alle Benutzer (inkl. Kunden) müssen 2FA einrichten

1. Klicken Sie auf Speichern

Verhalten für betroffene Benutzer

Benutzer, die der Richtlinie unterliegen und noch keine 2FA eingerichtet haben:

• Sehen beim Login einen gelben Warnbanner im Panel
• Können das Panel weiterhin verwenden
• Werden aufgefordert, 2FA unter Einstellungen einzurichten

Empfehlung

Aktivieren Sie die Richtlinie mindestens für Admins, um Panel-Zugänge mit erhöhten Rechten zu schützen.

---

Brute-Force-Schutz

Der integrierte Brute-Force-Schutz sperrt IP-Adressen nach zu vielen fehlgeschlagenen Login-Versuchen.

Konfiguration

Navigieren Sie zu Einstellungen > Sicherheit > Login-Schutz:

Einstellung	Standard	Beschreibung
Aktiviert	Ja	Brute-Force-Schutz ein/ausschalten
Max. Fehlversuche	5	Anzahl erlaubter Versuche
Sperrzeit (Minuten)	15	Dauer der Sperre

IP-Whitelist des Login-Schutzes

IPs, die nie gesperrt werden:

1. Navigieren Sie zu Einstellungen > Sicherheit > Login-Schutz
2. Tragen Sie vertrauenswürdige IP-Adressen ein
3. Diese IPs werden auch nach Fehlversuchen nicht gesperrt

Eigene IP whitelisten

Tragen Sie Ihre eigene statische IP-Adresse in die Whitelist ein, um sich nicht versehentlich auszusperren.

Nicht zu verwechseln mit der IP-Zugriffsbeschränkung

Diese Liste steuert nur, wer nach Fehlversuchen nicht gesperrt wird. Sie öffnet oder schließt keinen Zugang. Die Funktion, die den Panel-Zugang auf bestimmte Adressen beschränkt, ist eine andere — siehe unten. Beide heißen in der deutschen Oberfläche „IP-Whitelist".

---

IP-Zugriffsbeschränkung (Panel-Zugang)

Beschränkt den Zugang zum Admin-Panel auf ausgewählte IP-Adressen. Anders als die Whitelist des Login-Schutzes ist dies eine Zugangssperre: Was nicht auf der Liste steht, kommt nicht herein.

1. Navigieren Sie zu Einstellungen > Sicherheit
2. Aktivieren Sie IP-Whitelist aktiviert
3. Tragen Sie unter Erlaubte IP-Adressen eine Adresse pro Zeile ein

Erlaubt sind einzelne Adressen und Bereiche in CIDR-Schreibweise, IPv4 wie IPv6:

203.0.113.5
198.51.100.0/24
2001:db8::1
2001:db8::/64

Was die Beschränkung umfasst

Sie gilt für alle administrativen Anfragen und wird vor der Anmeldung geprüft. Steht Ihre Adresse nicht auf der Liste, scheitert damit nicht nur das Speichern von Einstellungen, sondern auch das Laden der Seiten: Das Dashboard zeigt überall Null, Einstellungsseiten wirken leer, und die Zugriffsbeschränkung selbst erscheint als deaktiviert. Es sind keine Daten verloren — das Panel lehnt lediglich jede Anfrage ab, auch die, die den Zustand anzeigen würde.

Die richtige Adresse eintragen

Das Formular zeigt Ihnen die Adresse an, die der Server bei Ihnen tatsächlich sieht. Nehmen Sie diese, nicht die aus einem Dienst wie „Wie ist meine IP". Beide beantworten unterschiedliche Fragen und weichen regelmäßig voneinander ab — etwa wenn Ihr Browser das Panel über IPv6 erreicht, die Abfrage aber über IPv4 lief, oder wenn ein Router oder Anbieter-Proxy dazwischenliegt.

Speichern wird abgelehnt, wenn Sie sich aussperren würden

Seit Version 2.9.83 prüft das Panel beim Speichern, ob Ihre eigene Adresse in der Liste enthalten ist. Fehlt sie, wird nicht gespeichert und die Meldung nennt die Adresse, die stattdessen einzutragen wäre. Ein versehentliches Aussperren über die Oberfläche ist damit nicht mehr möglich.

Zugriff vom Server selbst bleibt immer offen

Anfragen von 127.0.0.1 und ::1 sind grundsätzlich erlaubt, unabhängig von der Liste. Das ist der Rettungsweg, falls die Beschränkung doch einmal zu eng gerät — etwa weil sich Ihre Adresse geändert hat.

Aussperrung rückgängig machen

Melden Sie sich per SSH als root auf dem Server an. Welche Adresse das Panel tatsächlich sieht, steht im Protokoll:

journalctl -u enconf-api | grep "IP whitelist: access denied" | tail -5

Beschränkung abschalten:

DB=$(grep -oP '^DB_NAME=\K.*' /etc/enconf/api.env | tr -d '"')
sudo -u postgres psql -d "$DB" \
  -c "UPDATE panel_settings SET value='false' WHERE key='panel_ip_whitelist_enabled';"
systemctl restart enconf-api

Danach ist das Panel wieder vollständig erreichbar und alle Einstellungen sind unverändert vorhanden.

Änderungen greifen nicht sofort

Die Liste wird bis zu 60 Sekunden zwischengespeichert. Ohne Neustart des Dienstes kann eine Änderung also kurz nachwirken.

---

Passwort-Richtlinie

Die Passwort-Richtlinie gilt für alle Benutzer (Admin, Reseller, Kunden):

Einstellung	Standard	Beschreibung
Mindestlänge	12	Minimale Zeichenanzahl
Großbuchstaben	Nein	Mindestens ein Großbuchstabe
Kleinbuchstaben	Nein	Mindestens ein Kleinbuchstabe
Ziffern	Nein	Mindestens eine Ziffer
Sonderzeichen	Nein	Mindestens ein Sonderzeichen

Warum keine Zeichenklassen erzwungen werden

Die Voreinstellung folgt NIST 800-63B: Länge schützt besser als erzwungene Zeichenklassen. Eine lange Passphrase wie korrekt-pferd-batterie-heftklammer ist stärker als ein kurzes P4ssw!rt — würde aber von einer Sonderzeichen-Pflicht abgelehnt.

Sie können die Zeichenklassen jederzeit einschalten, wenn eine Vorgabe in Ihrem Haus es verlangt. Bedenken Sie dabei, dass Sie damit auch starke Passphrasen ausschließen.

Konfiguration

1. Navigieren Sie zu Einstellungen > Sicherheit > Passwort-Richtlinie
2. Passen Sie die gewünschten Regeln an
3. Klicken Sie auf Speichern

---

Audit-Log

Das Audit-Log protokolliert alle sicherheitsrelevanten Aktionen im Panel.

Protokollierte Ereignisse

Ereignis	Beschreibung
Login	Erfolgreiche und fehlgeschlagene Anmeldungen
Logout	Abmeldungen
Passwort-Änderung	Passwort-Änderungen aller Benutzer
2FA-Änderung	Aktivierung/Deaktivierung von 2FA
Impersonation	Admin meldet sich als Kunde/Reseller an
Kunde erstellt/gelöscht	Kundenverwaltungs-Aktionen
Abonnement erstellt/gelöscht	Abonnement-Aktionen
Einstellungen geändert	Änderungen an Panel-Einstellungen
API-Schlüssel erstellt/gelöscht	API-Schlüssel-Verwaltung
Firewall-Regel geändert	Firewall-Änderungen

Audit-Log anzeigen

1. Navigieren Sie zu Audit-Log
2. Die Tabelle zeigt alle protokollierten Ereignisse:

Spalte	Beschreibung
Zeitpunkt	Datum und Uhrzeit
Benutzer	Ausführender Benutzer
Aktion	Art der Aktion
Details	Zusätzliche Informationen
IP-Adresse	Quell-IP des Benutzers

Filter

• Zeitraum — Filtern nach Datum
• Benutzer — Filtern nach Benutzer
• Aktion — Filtern nach Aktionstyp

---

Security Advisor

Der Security Advisor prüft die Sicherheitskonfiguration und gibt Empfehlungen:

Geprüfte Bereiche

Bereich	Prüfung
Firewall	Ist die Firewall aktiv?
fail2ban	Ist fail2ban aktiv und konfiguriert?
2FA	Ist 2FA für den Admin aktiviert?
SSL	Haben alle Domains gültige SSL-Zertifikate?
Passwort-Richtlinie	Ist die Richtlinie ausreichend stark?
PHP-Versionen	Werden veraltete PHP-Versionen verwendet?
Updates	Sind System-Updates verfügbar?
SSH	SSH-Konfiguration sicher?
open_basedir	Bei allen Webseiten konfiguriert?
disable_functions	Gefährliche Funktionen deaktiviert?

Bewertungen

Jede Prüfung erhält eine Bewertung:

• Bestanden (Grün) — Sicher konfiguriert
• Warnung (Gelb) — Verbesserung empfohlen
• Kritisch (Rot) — Sofortige Maßnahme erforderlich

---

Kunden-Isolation

Jeder Hosting-Account ist vollständig isoliert:

Linux-Ebene

• Eigener Linux-Benutzer pro Abonnement
• PHP-FPM-Pool läuft unter dem Benutzer des Kunden
• open_basedir beschränkt PHP auf das Kundenverzeichnis
• disable_functions deaktiviert gefährliche PHP-Funktionen
• Ressourcenbegrenzung für CPU, RAM und Prozesse

Netzwerk-Ebene

• nftables blockiert ausgehende SMTP-Verbindungen von Kunden-Prozessen
• Kunden können keine E-Mails direkt senden (nur über den Mailserver)

Webserver-Ebene

• Nginx blockiert PHP-Ausführung in Upload-Verzeichnissen
• Jede Webseite hat eine eigene Vhost-Konfiguration
• Zugriffsbeschränkungen pro Verzeichnis möglich

---

SSH-Härtung

Empfohlene SSH-Einstellungen (in /etc/ssh/sshd_config):

Einstellung	Empfehlung	Beschreibung
PermitRootLogin	no	Root-Login deaktivieren
PasswordAuthentication	no	Nur Schlüssel-basierte Anmeldung
Port	Nicht-Standard	SSH auf einem anderen Port als 22
MaxAuthTries	3	Max. Anmeldeversuche
AllowUsers	Spezifisch	Nur bestimmte Benutzer erlauben

Zugang sicherstellen

Stellen Sie vor Änderungen an der SSH-Konfiguration sicher, dass Sie alternative Zugangswege haben (z. B. Konsole beim Hosting-Provider).

---

Anmelde-Anomalie-Erkennung

Zusätzlich zur IP-basierten Brute-Force-Sperre (fail2ban + Konto-Lockout nach zu vielen Fehlversuchen) überwacht das Panel Anmeldemuster und warnt bei zwei verdächtigen Signalen:

• Anmeldung aus unbekanntem Netz: Meldet sich ein Admin- oder Reseller-Konto aus einem Netz an (IPv4 /24, IPv6 /48), aus dem es noch nie angemeldet war, wird eine Benachrichtigung ausgelöst. Der allererste Login eines Kontos gilt als Referenz und löst bewusst keine Warnung aus.
• Verteilter Anmelde-Angriff: Wird ein einzelnes Konto innerhalb von 30 Minuten von mehreren IPs mit vielen Fehlversuchen attackiert, meldet das Panel dies — auch dann, wenn keine einzelne IP die Sperr-Schwelle erreicht (der „low-and-slow"-Angriff, den die per-IP-Sperre nicht fängt).

Beide Signale sind reine Benachrichtigungen (keine automatische Sperre) und ab Werk aktiv. Abschalten über die Panel-Einstellung login_anomaly_enabled=false; die Schwelle für den verteilten Angriff über login_anomaly_account_threshold (Standard 15).

Administrator-Zugang wiederherstellen

Wer sich aus dem Panel ausgesperrt hat — Passwort vergessen, die Anmeldeadresse beim Ändern vertippt, oder der Verdacht, dass jemand anderes das Konto übernommen hat —, stellt den Zugang auf dem Server wieder her. Dafür gibt es ein Kommandozeilenwerkzeug, das nur als root läuft (per SSH, mit sudo) und deshalb weder Passwort noch Sitzung braucht:

sudo enconfctl admin list                                   # Admin-Konten, Anmeldeadresse, 2FA
sudo enconfctl admin reset-password <adresse> [-p <passwort>]
sudo enconfctl admin set-email <alte-adresse> <neue-adresse> [--sync-admin-email]

• reset-password setzt ein neues Passwort (ohne -p wird eines erzeugt und angezeigt) und beendet alle bestehenden Sitzungen dieses Kontos. Das Werkzeug umgeht bewusst die Passwort-Richtlinie.
• set-email ändert die Anmeldeadresse. Es prüft wie das Panel, dass keine andere Adresse gleich lautet (Groß-/Kleinschreibung zählt dabei nicht), und lässt 2FA, Passwort und Sitzungen unverändert. Die Kontaktadresse des Betreibers (admin_email, auch Let's-Encrypt- und MTA-STS-Kontakt) folgt der Anmeldeadresse nur, wenn beide vorher übereinstimmten oder admin_email leer war; weicht sie ab, bleibt sie unverändert und das Werkzeug nennt den Befehl mit --sync-admin-email, falls sie mitwandern soll.

Verdacht auf Übernahme (z. B. nach der Mitteilung „Ihre Anmeldeadresse wurde geändert", die Sie nicht selbst ausgelöst haben): zuerst set-email auf Ihre Adresse, dann reset-password, danach unter Sicherheit → Sitzungen unbekannte Sitzungen widerrufen und 2FA prüfen. „Passwort vergessen" im Panel hilft in diesem Fall nicht: der Link geht an die gespeicherte Anmeldeadresse, also an die neue.

Wiederholte falsche Passworteingaben beim Ändern von Passwort, Anmeldeadresse oder 2FA sperren die Prüfung für das Konto (Standard: 5 Fehlversuche in 15 Minuten, dieselben Grenzen wie bei der Anmeldung, siehe Brute-Force-Schutz). Die Sperre gilt dann auch für die richtige Eingabe, bis die Zeit abgelaufen ist.