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. |
| nftables SMTP-Egress-Block | Customer-PHP kann nicht direkt zu fremden SMTP-Servern verbinden — Spam-Schutz. Nur authentifizierte Submission via 587. |
| ModSecurity / OWASP CRS | WAF vor Nginx — generische SQLi/XSS/RCE-Filter. |
| 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). |
Geplant (Phase 2, noch nicht aktiv)¶
| Schicht | Status |
|---|---|
| AppArmor-Profile pro Customer | Profile-Generator vorhanden, müssen noch in enforce Mode gesetzt werden |
| systemd Slices pro Customer | Geplant — Resource-Quotas für CPU, RAM, IO, Tasks pro Customer |
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¶
- Navigieren Sie zu Einstellungen > Sicherheit (oder Einstellungen > Passwort)
- Klicken Sie auf 2FA einrichten
- Scannen Sie den QR-Code mit einer Authenticator-App:
- Google Authenticator
- Authy
- Microsoft Authenticator
- FreeOTP
- Geben Sie den angezeigten 6-stelligen Code ein
- 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¶
- Navigieren Sie zu Einstellungen > Sicherheit
- Klicken Sie auf 2FA deaktivieren
- Geben Sie Ihr aktuelles Passwort zur Bestätigung ein
- Klicken Sie auf Deaktivieren
Login mit 2FA¶
- Geben Sie E-Mail und Passwort ein
- Geben Sie den 6-stelligen Code aus Ihrer Authenticator-App ein
- 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¶
- Navigieren Sie zu Einstellungen > Sicherheit
- 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 |
- 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¶
IPs, die nie gesperrt werden:
- Navigieren Sie zu Einstellungen > Sicherheit > Login-Schutz
- Tragen Sie vertrauenswürdige IP-Adressen ein
- 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.
Passwort-Richtlinie¶
Die Passwort-Richtlinie gilt für alle Benutzer (Admin, Reseller, Kunden):
| Einstellung | Standard | Beschreibung |
|---|---|---|
| Mindestlänge | 8 | Minimale Zeichenanzahl |
| Großbuchstaben | Ja | Mindestens ein Großbuchstabe |
| Kleinbuchstaben | Ja | Mindestens ein Kleinbuchstabe |
| Ziffern | Ja | Mindestens eine Ziffer |
| Sonderzeichen | Ja | Mindestens ein Sonderzeichen |
Konfiguration¶
- Navigieren Sie zu Einstellungen > Sicherheit > Passwort-Richtlinie
- Passen Sie die gewünschten Regeln an
- 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¶
- Navigieren Sie zu Audit-Log
- 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).