Per-Site CageFS: Neue Sicherheitsarchitektur für Shared Hosting

Per-Site CageFS trennt einzelne Websites innerhalb eines Shared-Hosting-Accounts strikt voneinander und begrenzt so das Risiko seitlicher Bewegungen nach einem Einbruch. Ich erläutere die neue Sicherheitsarchitektur, zeige praktische Einsatzszenarien und erkläre, wie du damit mehrere Projekte in einem Account sicher führst.

Zentrale Punkte

• Website-Isolierung: Zusätzliche Trennung innerhalb eines Accounts senkt seitliche Risiken.
• CloudLinux: Erweiterung des CageFS-Konzepts auf Domain-Ebene.
• WordPress: Mehrere Instanzen sicher nebeneinander betreiben.
• Ressourcen: Limits für CPU/RAM/I/O ergänzen die Dateisicht-Trennung.
• Praxis: Aktivierung pro Domain und klare Rechte-/Pfad-Strategie.

Was „Per-Site CageFS“ konkret leistet

Die Erweiterung isoliert einzelne Domains innerhalb eines bestehenden Nutzer-CageFS, damit jede Website nur ihre eigenen Dateien und Prozesse sieht. Damit verhindere ich, dass ein kompromittiertes Projekt Konfigurationsdateien, Uploads oder Schlüssel anderer Sites im selben Account berührt. Laut CloudLinux Blog (Beta-Ankündigung) erweitert Per-Site CageFS die Isolation zwischen Websites innerhalb desselben Benutzerkontos und reduziert so das Risiko seitlicher Bewegungen. Für mich liegt der Nutzen klar auf der Hand: Ich segmentiere Agentur-Accounts, Multisite-Setups und Testumgebungen sauber, ohne die Hosting-Struktur zu zerreißen. Einen schnellen Überblick zum Prinzip von CageFS liefert dieser Hintergrund zu CageFS-Dateisystem, auf dem die Per-Site-Isolierung aufsetzt.

Warum Account-Isolierung allein nicht reicht

Ein Account bündelt oft mehrere Projekte – etwa zwei Shops, drei Blogs und ein Staging. Greift ein Exploit ein schwaches Plugin an, kann ein Angreifer ohne zusätzliche Segmentierung auf Nachbarverzeichnisse schielen und dort weitere Payloads platzieren. Genau hier dreht Per-Site CageFS die Sicht auf Dateisystem und Prozesse so zu, dass jede Website wie in einer eigenen Jail arbeitet. Besonders bei getrennten WordPress-Instanzen mit gemeinsamem PHP-User entsteht sonst ein Fenster für Eskalationen, das ich mit der Domain-Isolierung schließe. Das mindert Folgeschäden, vereinfacht Forensik und macht Wiederherstellungen schneller planbar.

So funktioniert die Website-Isolierung technisch

CloudLinux kapselt über CageFS ein virtuelles, per-User Dateisystem; die Per-Site-Schicht erweitert das um Domain-Grenzen. Jede aktivierte Domain erhält einen getrennten Sichtbereich innerhalb des Benutzer-CageFS, inklusive restriktiver Pfade, eigener Temp-Verzeichnisse und abgeschotteter Skriptausführung. Dadurch verschwinden fremde wp-config.php, Upload-Ordner oder Schlüsseldateien aus der Sicht der angegriffenen Website. Cronjobs, PHP und ggf. SSH-Befehle greifen auf die gleichen Systembibliotheken zu, sehen jedoch nur die zugewiesenen Teilmengen des Dateisystems. Laut Dokumentation lässt sich die Trennung pro Domain schalten, was mir feingranulare Steuerung für Live-, Staging- und Test-Instanzen gibt.

Vergleich: Account-Isolation, Per-Site CageFS und Container

Um die Wahl strukturiert zu treffen, vergleiche ich drei gängige Modelle nach Isolationstiefe, Aufwand und Kompatibilität. Account-Isolation löst Mandantentrennung zwischen Kunden, lässt aber interne Seitengrenzen offen. Per-Site CageFS schließt diese Lücke auf Dateisystem- und Prozesssicht. Container schaffen harte Grenzen, verlangen jedoch oft mehr Pflege und Anpassungen. Eine fundierte Einordnung der Prozessisolation liefert dieser Vergleich von Chroot, CageFS und Jails.

Ansatz	Trennung zwischen Accounts	Trennung zwischen Websites im Account	Kompatibilität (PHP/CGI/SSH/Cron)	Betriebsaufwand
Account-Isolation (klassisch)	Hoch	Niedrig	Sehr gut	Niedrig
Per-Site CageFS	Hoch	Mittel bis hoch	Sehr gut	Niedrig bis mittel
Container pro Site	Sehr hoch	Sehr hoch	Gut bis sehr gut	Mittel bis hoch

In Shared-Hosting-Umgebungen liefert Per-Site CageFS eine starke Mischung aus feiner Trennung und geringer Umstellung, weil Skripte im Regelfall unverändert laufen. Ich sichere damit die häufigste Schwachstelle: mehrere eigenständige Websites unter einem einzigen Benutzerkonto.

Praxis: Mehrere WordPress-Instanzen sicher betreiben

Ich trenne jede WordPress-Instanz mit aktivierter Domain-Isolation und setze pro Site eigene PHP-FPM-Pools, damit Logs, opcache und Limits sauber zuordenbar bleiben. Außerdem lege ich für jede Site eigene SALTs/KEYS in der wp-config.php fest und verhindere über Dateirechte und open_basedir-Äquivalente jede Quersicht. Uploads lege ich strikt innerhalb des jeweiligen Document-Roots ab und untersage globale Shared-Upload-Verzeichnisse. Während Deployments halte ich temporäre Pfade site-intern und reinige Build-Artefakte sofort, damit keine unnötigen Angriffsflächen verbleiben. Für Composer- oder NPM-Caches nutze ich site-lokale Verzeichnisse, damit keine Quereffekte entstehen.

Leistung und Ressourcensteuerung im Zusammenspiel

Per-Site CageFS adressiert die Dateisicht; die Performance sichere ich über Limits für CPU, RAM, I/O und Prozesse auf Account- oder Pool-Ebene ab. So verhindere ich, dass eine Site durch fehlerhafte Plugins zu viel Last erzeugt und den gesamten Account ausbremst. In vielen Setups steckt das in LVE- oder ähnlichen Kontingenten, die ich pro Pool oder Account fein einstelle. Ich verknüpfe das mit Request-Drosselung in Webserver oder WAF, damit Traffic-Spitzen geordnet ablaufen. Diese Kombination aus Isolierung und Kontingenten steigert Servicesicherheit und berechenbare Lastverteilung.

Schutzkette: Was Per-Site CageFS nicht ersetzt

Die Isolierung verhindert Quersichten, doch ich halte Updates, Härtung von PHP und strikte Passwörter weiterhin konsequent durch. Auch MFA für Admin-Logins, minimale Dateirechte und Upload-Filter bleiben Pflicht. Eine WAF, Rate-Limits und kontinuierliches Logging decken zusätzliche Pfade ab, die reine Dateisicht-Trennung nicht kontrolliert. Ich prüfe außerdem regelmäßig Cronjobs und Integrationstokens, die Angreifer oft vergessen vorfinden. Mehr zum Zusammenspiel von Mandantentrennung und Härtung zeigt dieser Leitfaden zu Shared-Hosting-Sicherheit, der die Denkrichtung unterstreicht.

Einrichtung und typische Stolpersteine

Ich aktiviere die Domain-Isolation gezielt pro Website und teste anschließend SSH-, Cron- und PHP-Zugriffe unter realen Bedingungen. Absolute Pfade in Deploymentskripten oder Plugins können Probleme verursachen, daher setze ich auf relative Pfade oder Variablen. Symlinks zwischen Projekten meide ich, weil sie das Trennungsprinzip aufweichen; benötigte Libraries ziehe ich lieber je Site ins Repo. Für Backups definiere ich getrennte Archive und sichere Logs je Domain, damit Wiederherstellung und Forensik sauber bleiben. Bei Rechten hat sich 640 für Dateien und 750 für Ordner bewährt, plus Eigentümer passend zum jeweiligen PHP-Pool.

Kosten-Nutzen-Abwägung für Agenturen und Freelancer

Ich rechne den Sicherheitsgewinn gegen Administrationszeit und potenzielle Ausfallkosten, die ein Quervorfall erzeugen würde, auf Euro-Basis. Schon wenige Stunden Incident-Response kosten oft deutlich mehr als ein kleiner monatlicher Aufpreis für bessere Isolation. Für Agentur-Accounts mit mehreren Kundenprojekten reduziert die Segmentierung spürbar das Haftungs- und Reputationsrisiko. Auch Backup- und Restore-Prozesse laufen geordneter, weil ich zielgenau einzelne Sites wiederherstelle. Insgesamt zahlt Per-Site CageFS auf eine verlässlichere Betriebsführung mit planbaren Abläufen ein.

Checkliste: Wann Per-Site CageFS Pflicht wird

Ich aktiviere die Domain-Isolierung, sobald mehrere Installationen in einem Account laufen und unterschiedliche Update-Zyklen besitzen. Ebenfalls wichtig: getrennte Projektteams oder externe Admin-Zugänge, die das Risiko unbeabsichtigter Eingriffe erhöhen. Hohe Upload-Volumina, Dateikonverter oder Bildverarbeitung rechtfertigen die Trennung zusätzlich, weil hier oft Einfallstore entstehen. Unterschiedliche Compliance-Anforderungen (z. B. Mandanten, Märkte, Datenschutz) sprechen ebenfalls für feinere Segmente. Wer Staging, Testing und Live parallel betreibt, profitiert von sauber getrennten Fehlerdomänen und einer klaren Forensik.

Voraussetzungen und Kompatibilität in der Praxis

Bevor ich Per-Site CageFS produktiv setze, prüfe ich die Laufzeitumgebung: eingesetzter PHP-Handler (etwa PHP-FPM, lsapi), aktiver Webserver, verfügbare Panel-Integration und die Art, wie Cronjobs und SSH-Sessions gemanagt werden. In typischen Shared-Umgebungen laufen Applikationen ohne Codeänderungen weiter. Ich stelle sicher, dass pro Domain ein eigener Document-Root existiert, die Pfade eindeutig sind (z. B. /home/user/sites/projekt-a/public) und dass pro Site ein dedizierter PHP-FPM-Pool greift. Für Cronjobs nutze ich je Domain eigene Crontabs oder – wo das Panel das bündelt – klare Prefixes und Logpfade, damit Jobs innerhalb ihrer Jails arbeiten.

Datenbanken, Caches und Sessions sauber trennen

Die Dateisicht ist nur ein Teil. Ich ziehe die Trennung bis zur Datenbank und zu den Caches durch. Pro Website lege ich eine eigene Datenbank und einen eigenen DB-User mit minimalen Rechten an. Für Object- oder Page-Caches (z. B. Redis, Memcached) verwende ich je Site getrennte Instanzen oder zumindest Schlüssel-Präfixe und dedizierte Datenbanken/Namespaces. PHP-Sessions landen in site-eigenen Pfaden; ich setze den session.save_path je FPM-Pool separat. Wenn ich eine zentrale Queue oder ein Suchbackend nutze, trenne ich Indexe und Topics je Site. Dieses Prinzip „Trennung bis zur letzten Meile“ verhindert, dass sich Vorfälle über Nebensysteme ausbreiten.

CI/CD und Deployments unter Isolation

In Build-Pipelines mache ich Isolierung zum Standard: Pro Site existiert ein eigener Deploy-Job, der nur auf das Site-Verzeichnis zugreift. Artefakte entpacke ich innerhalb des Domain-Roots, führe danach owner/group-Fixes aus und invalidiere ausschließlich die betroffenen Caches. WP-CLI-Befehle laufen im jeweiligen CageFS-Kontext, sodass sie keine Fremdprojekte berühren. Environment-Variablen halte ich je Site getrennt, Secrets verbleiben in site-eigenen Konfigurationsdateien oder im Panel-Secret-Store. Für Zero-Downtime nutze ich atomic symlink-switches innerhalb der Domain-Grenzen (z. B. current/releases), achte aber darauf, dass Symlinks nicht auf Nachbarprojekte zeigen. Post-Deploy-Checks (Health, 404/500-Scan, Rechteprüfung) gehören pro Site zum Pflichtprogramm.

Monitoring, Logging und Forensik

Ich trenne Logs konsequent: access/error-Logs je Domain, eigene PHP- und Cron-Logs samt Rotationen und Retention. Im Incident-Fall kann ich so die Timeline einer einzelnen Site rekonstruieren, ohne den ganzen Account zu durchforsten. Ergänzend setze ich auf Dateiintegritätsprüfungen (Prüfsummen von Kernverzeichnissen), verteilte Audit-Logs für Admin-Aktionen und einfache Canary-Dateien, die Manipulationen früh zeigen. Für Alarme genügen oft schon Schwellwerte: plötzliche Anstiege bei 500ern, ungewöhnliche Upload-Größen, stark wachsende Inode-Belegungen oder exzessive PHP-Worker-Starts. Diese Signale verbinde ich mit klaren Runbooks: Site sperren, Backups prüfen, Artefakte sichern, Wiederanlauf im isolierten Scope.

WordPress-Sonderfälle: Multisite, MU-Plugins und Upload-Flüsse

Bei WordPress Multisite wäge ich ab: Eine Multisite-Installation profitiert weniger von Per-Site CageFS, da mehrere Sites bewusst eine Codebasis und Struktur teilen. Wenn ich strengere Grenzen brauche (unabhängige Teams, getrennte Caches, klare Forensik), setze ich lieber einzelne Instanzen auf und isoliere sie. MU-Plugins, Drop-ins oder globale Must-Use-Libraries verteile ich nur site-intern und vermeide Shared-Ordner. Medien-Workflows (CDN, Bildoptimierung, Konverter) laufen innerhalb des Domain-Jails; Uploads von einer Site in Verzeichnisse einer anderen schließe ich aus. Wenn ein Team Asset-Pipelines teilen möchte, repliziere ich diese je Site oder kapsle sie als Paket, das ins jeweilige Repo eingebunden wird.

Migrationspfad: Vom Monolithen zum segmentierten Account

Viele Accounts starten mit einem großen public_html und wachsen historisch. Ich gehe in fünf Schritten vor: 1) Inventarisieren: Welche Sites, Domains, Cronjobs, DBs, Secrets? 2) Pfad-Layout festlegen: je Site eigener Root, Temp, Logs, Backups. 3) PHP-FPM-Pools je Domain definieren und Limits setzen. 4) Dateien verschieben, Rechte anpassen, absolute Pfade und Includes bereinigen. 5) Per-Site CageFS aktivieren, Tests unter Last fahren, Monitoring aufschalten. Währenddessen halte ich eine Rollback-Strategie bereit (Snapshots, getrennte Backups). Nach dem Cutover überprüfe ich, ob Tools wie WP-CLI, Composer, Bildprozesse und Cronjobs im korrekten Scope laufen und passe ggf. Pfadvariablen an.

Fehlerbilder und Troubleshooting

• 403/404 nach Aktivierung: Meist verweisen Rewrite-Regeln oder Includes auf Pfade außerhalb des Domain-Roots. Ich korrigiere Pfade auf relative Varianten oder nutze Variablen.
• Composer/NPM bricht: Globale Caches sind nicht sichtbar. Ich setze site-lokale Cache-Verzeichnisse und passe HOME/TMP-Variablen im Deploy an.
• WP-CLI findet wp-config.php nicht: Ausführung nicht im Domain-Root. Ich setze das Arbeitsverzeichnis korrekt oder übergebe den Pfad explizit.
• Cronjobs still: Cron-User oder Pfade nicht je Domain hinterlegt. Ich kontrolliere env-Variablen, Binärpfade und Logziele innerhalb der Site-Jail.
• Uploads fehlschlagen: session.save_path oder tmp_dir zeigt ins falsche Verzeichnis. Ich weise site-lokale Temp-Pfade je FPM-Pool zu.
• Shared-Library fehlt: Symlink auf Nachbarprojekt ist blockiert. Ich repliziere die Library in jede Site oder baue sie als Paket ins Deployment ein.

Governance und Zugriffsmodell

Selbst wenn technisch alles getrennt ist, bleibt das Thema Zugänge. Ich vergebe je Site dedizierte SSH-/SFTP-Zugänge oder beschränke Panel-Zugriffe auf die jeweilige Domain. Entwickler- und Agenturteams erhalten nur die Keys und Berechtigungen, die sie wirklich brauchen. Für Notfälle halte ich einen Break-Glass-Prozess bereit (temporär erweiterte Rechte, vollständiges Logging, nachgelagerte Entziehung). In Audits dokumentiere ich pro Site: Pfade, Pools, Limits, Verantwortliche, RBAC-Zuweisungen und Backups. So bleibt die Segmentierung nicht nur technisch, sondern auch organisatorisch belastbar.

Kurz zusammengefasst

Per-Site CageFS ergänzt die bestehende Nutzertrennung um eine Website-Ebene und senkt damit effektiv das Risiko lateraler Bewegungen. Ich halte das für einen praxisnahen Schritt, weil viele Accounts mehrere unabhängige Projekte vereinen. Die Kombination aus Dateisicht-Trennung und Ressourcenlimits bringt Ordnung in Performance, Sicherheit und Betrieb. Wer mehrere WordPress- oder Shop-Instanzen hostet, gewinnt Zeit bei Fehlersuche, Backups und Wiederanläufen nach Vorfällen. Mit klaren Rechten, Updates, MFA und Logging entsteht eine tragfähige Sicherheitskette, die Shared Hosting deutlich belastbarer macht.