CloudLinux Site Isolation: Mehr Sicherheit als CageFS im Shared Hosting

Site Isolation von CloudLinux trennt einzelne Websites innerhalb eines Accounts strikter als CageFS und schließt damit Lücken, die bei Multi‑Site‑Installationen im Shared Hosting häufig auftreten. Ich zeige die Unterschiede, den Sicherheitsgewinn im Alltag und konkrete Schritte, wie du dieses Feature sinnvoll einsetzt.

Zentrale Punkte

• Feingranulare Isolation: Trennung auf Domain‑Ebene verhindert Seitensprünge innerhalb eines Accounts.
• Getrennte Prozesse: Eigene PHP‑Kontexte je Site erschweren lateral movement.
• Saubere Cron-Bindung: Jobs sind an den Document‑Root der jeweiligen Domain gebunden.
• Mehrschichtschutz: CageFS isoliert Accounts, Site Isolation trennt Websites im Account.
• Planbare Ressourcen: LVE‑Limits halten Lastspitzen im Zaum und sichern Reaktionszeiten.

CageFS vs. Site Isolation: Architektur im Vergleich

Mit CageFS sieht ein Account nur seine eigenen Dateien, bereinigte Systempfade und keine fremden Prozesse, was gezieltes Ausspähen stark einschränkt. Die Site Isolation setzt tiefer an und schafft pro Domain oder Subdomain eine eigene Sicht auf Dateien und Prozesse innerhalb desselben Accounts. So verliert eine kompromittierte Installation den direkten Zugriff auf Nachbar‑Projekte, selbst wenn sie unter demselben Login liegen, was seitliche Bewegungen massiv erschwert. Wer sich technisch einordnen will, findet über das CageFS‑Dateisystem schnell den richtigen Vergleichsmaßstab. Aus Sicht von Sicherheit und Betrieb gewinnt damit die Trennung auf Domain‑Ebene eine entscheidende Rolle.

Warum die zusätzliche Ebene zählt

Viele Agenturen bündeln mehrere WordPress‑Sites in einem großen Account, weil Verwaltung und Abrechnung damit einfacher werden. Ohne Trennung auf Domain‑Ebene kann eine veraltete Instanz jedoch Konfigurationsdateien oder Pfade von Nachbar‑Projekten einsehen, was das Risiko deutlich erhöht. Genau hier packt Site Isolation an und hält den Angriffsraum strikt innerhalb des jeweiligen Document‑Roots. Ich minimiere damit Querschläger, wenn ein einzelnes Projekt schwächelt oder ein Plug‑in eine offene Flanke zeigt. Diese feinere Abgrenzung verschafft mir Zeit, um betroffene Sites zu härten, ohne dass danebenliegende Projekte Schaden nehmen.

Admin-Alltag: Trennung je Domain, eigene PHP-Kontexte

Ich aktiviere Isolation gezielt pro Domain oder Subdomain und kapsle damit besonders risikoreiche CMS‑Instanzen enger ein. PHP‑Handler, FPM‑Pools und ini‑Einstellungen laufen getrennt, was kompromittierten Code daran hindert, Prozesse anderer Sites mitzulesen. Cron‑Jobs binde ich automatisch an den jeweiligen Document‑Root, sodass Skripte nicht über Bande in fremde Verzeichnisse greifen. Beim Umschalten beendet CloudLinux alte Prozesse der betroffenen Domain geordnet und startet sie im isolierten Kontext neu, wodurch Anfragen sofort durch die neue Schranke laufen. Dieser Ablauf hält Unterbrechungen kurz und lässt die übrigen Projekte im Account unberührt, was den Betrieb spürbar sicherer macht.

Zusammenspiel: CageFS, Symlink-Schutz und LVE

CageFS bleibt die Hülle, welche Accounts voneinander trennt, während die Site Isolation Projekte innerhalb eines Accounts voneinander abkoppelt. Symlink‑Schutz und Kernel‑Mechanismen schließen typische Abkürzungen über symbolische Links oder pfadbasierte Tricks aus. Diese Schichten greifen ineinander und machen es Angreifern schwer, sich von einer schwachen Site zur nächsten zu hangeln. Ich profitiere dabei doppelt: Einerseits sinkt die Angriffsfläche, andererseits werden Wartungsarbeiten klar begrenzt. So wirkt das Sicherheitsmodell wie ein abgestimmtes Mehrfachsystem statt einer einzelnen Maßnahme.

Angriffsszenarien: So wirkt die Isolierung in der Praxis

Treffen veraltete Plug‑ins auf schreibbare Pfade, landen Webshells schnell im Dateisystem und spähen Konfigurationen aus, sofern nichts trennt. Durch Site Isolation bleibt der Zugriff an den Domain‑Root gebunden, was den Sprung zur Nachbar‑Site verhindert und gestohlene Zugangsdaten ausbremst. In Agentur‑Accounts mit vielen Kundenprojekten stoppt die Trennung zudem Backdoors, die sonst zum Sprungbrett würden. Auch Fehlkonfigurationen wie allzu großzügige Backup‑Skripte begrenze ich, weil der erlaubte Pfadraum enger und klar definiert ist. So verschiebt sich der Schaden von „Account‑weit“ hin zu „Site‑lokal“, was Reaktionszeit und Forensik vereinfacht.

Leistung und Verlässlichkeit: Ressourcen sauber getrennt

Viele sehen CloudLinux primär als Schutz, doch die Trennung bringt handfeste Effekte auf Reaktionszeiten und Planbarkeit. LVE‑Limits für CPU, RAM, IO und Prozesse verhindern, dass einzelne Sites alles aufzehren und Nachbarn ausbremsen. Lastspitzen fange ich so pro Projekt ab, ohne Sicherheit zu lockern oder den Rest des Servers zu gefährden. In Kombination mit cgroup v2 verteile ich Ressourcen nachvollziehbar und halte Engpässe transparenter im Blick. Dieses Set‑up liefert mir kalkulierbare Performancewerte, gerade bei hochfrequenten CMS‑Installationen.

Implementierung im Detail: Schrittfolge und Absicherungs-Checks

In der Praxis bewährt sich eine klare Reihenfolge, damit Umschaltungen reibungslos laufen und keine Seiteneffekte auftreten. Ich gehe so vor:

• Projekte sichten: Jede Domain/Subdomain erhält einen eindeutigen Document‑Root ohne gemeinsame Schreibpfade.
• Backups und Staging: Vor der Aktivierung sichere ich Files und Datenbanken und teste die Isolation in einer Staging‑Kopie.
• Isolation pro Domain aktivieren: Je nach Panel stelle ich die Site auf einen eigenen PHP‑FPM‑Pool um und trenne ini‑Werte.
• Cron‑Jobs neu binden: Crons starte ich aus dem jeweiligen Document‑Root und verwende nur projektspezifische Pfade.
• Symlink‑Pflege: Ich entferne Querverlinkungen zwischen Projekten oder ersetze sie durch reine Lese‑Artefakte, wenn wirklich nötig.
• Graceful Restart prüfen: Nach dem Umschalten verifiziere ich, dass alte Prozesse beendet und neue sauber gestartet wurden.
• Smoke‑Tests: Ich checke Login, Caching, Datei‑Uploads, Webhooks und CLI‑Tasks (z. B. wp‑cli) in jedem isolierten Kontext.

Wichtig ist, dass ich schreibende Pfade (Uploads, Cache, Sessions, tmp) strikt pro Site halte. Geteilte „assets“‑Ordner sind bequem, konterkarieren aber Isolation und erschweren Forensik.

Rechte- und Pfadkonzept: So bleiben Sites sauber getrennt

Die feinere Trennung lebt von klaren Dateirechten und konsistenten Pfaden. Ich setze auf folgende Grundsätze:

• Document‑Root als Grenze: Applikationen dürfen ausschließlich innerhalb ihres Root‑Pfads schreiben.
• Minimalrechte: Verzeichnisse 750/755, Dateien 640/644 – Sonderrechte nur, wo technisch erforderlich.
• Konfigurationsdateien härten: wp-config.php & Co. mit restriktiven Rechten versehen und, wenn möglich, aus dem Webroot herausziehen (innerhalb des Site‑Kontexts).
• Temporärpfade je Site: Eigene tmp‑ und session‑Verzeichnisse je Domain, im jeweiligen Kontext liegend.
• Kein Shared‑Vendor: geteilte Composer‑„vendor“‑Bäume über mehrere Projekte hinweg vermeide ich konsequent.

Darüber hinaus halte ich ini‑Einstellungen pro Site eng: open_basedir, upload_tmp_dir und disable_functions setze ich projektspezifisch, statt globale Kompromisse zu fahren.

WordPress, TYPO3 & Co.: Projektspezifische Hinweise

Bei CMS‑Stacks zeigen sich die Vorteile schnell, wenn ich ein paar Details beachte:

• WordPress: Cron auf echten System‑Cron umstellen, damit Jobs im Site‑Kontext laufen; wp‑cli getrennt je Domain verwenden.
• Multisite/Network: Ich vermeide file‑basierte Querverweise zwischen Subsites; Medien‑Offloading oder dedizierte Buckets sind robuster.
• TYPO3/Drupal: Schreibpfade (var, public/fileadmin, sites/default/files) strikt trennen und Konfigurations‑Includes pro Projekt pflegen.
• Cache/OPcache: Je Site separaten FPM‑Pool mit eigenem OPcache‑Speicher nutzen, damit Warm‑Caches sich nicht gegenseitig aushebeln.
• Deployments: Build‑Artefakte (Composer, Node) pro Projekt erzeugen; gemeinsame Build‑Verzeichnisse vermeiden.

Besonders bei stark modularen Projekten („headless“, mehrere Frontends) plane ich die Grenzen bewusst: jedes Frontend in einen eigenen, isolierten Kontext mit klaren Schnittstellen.

Überwachung und Forensik: Sichtbarkeit je Site

Die Isolation erleichtert mir das Troubleshooting, wenn ich Logs und Kennzahlen pro Domain führe:

• Fehler‑ und Access‑Logs pro Site: So korrelieren 4xx/5xx‑Spitzen eindeutig mit einem Projekt.
• PHP‑FPM‑Slowlogs: Langsame Skripte site‑spezifisch identifizieren, ohne Rauschen anderer Instanzen.
• LVE‑Metriken: CPU, IO, EP (Entry Processes), NPROC und Memory je Site beobachten; Limit‑Hits früh erkennen.
• Alarmierung: Schwellwerte pro Projekt setzen (z. B. viele 503/508 in kurzer Zeit), um gezielt zu reagieren.
• Artefakt‑Sammlung: Bei Vorfällen sichere ich nur den betroffenen Site‑Root – das beschleunigt Analysen und reduziert Datenschatten.

Weil die Grenzen klar sind, kann ich Beweise und Indikatoren (Indicators of Compromise) schneller zuordnen und Gegenmaßnahmen gezielter einleiten.

Performance-Tuning je Site: Pools und Limits fein abstimmen

Getrennte Pools sind nicht nur Sicherheit, sondern auch Tuning‑Hebel. Ich passe je Projekt an:

• pm‑Modus: Dynamisch oder ondemand je nach Traffic‑Profil; Burst‑Lasten mit moderater Reserve abfedern.
• max_children: An gleichzeitige Requests und Memory‑Budget der Site binden, statt globaler Einheitswerte.
• OPcache‑Größe: Warm‑Set der Site berücksichtigen; zu kleine Caches verursachen Fragmentierung und Kaltstarts.
• Timeouts: connect/read‑Timeouts von Upstream‑Diensten (APIs, DB) pro Site justieren, um Hänger zu vermeiden.
• Static‑Offloading: Statische Assets konsequent ausliefern (z. B. Webserver‑Cache), damit PHP‑Pools entlastet werden.

In Summe entsteht ein Set‑up, das Spitzen pro Site abfedert, ohne Nachbarn zu beeinflussen. Das macht Reaktionszeiten verlässlich und planbar.

Grenzen, Nebenwirkungen und Troubleshooting

Die Isolation verschiebt Verantwortlichkeiten – das ist gewollt, verlangt aber Achtsamkeit:

• Geteilte Ressourcen: Zentrale Upload‑ oder Backup‑Verzeichnisse über mehrere Sites funktionieren bewusst nicht mehr ohne Sonderkonfiguration.
• Legacy‑Skripte: Ältere Deploy‑ oder Wartungsskripte, die absolute Account‑Pfade annehmen, passen ich auf den Site‑Root an.
• Importer/Exporter: Tools mit Zugriff über Site‑Grenzen sind zu ersetzen oder strikt je Domain zu betreiben.
• Fehlerbilder: 503/504 deuten oft auf Pool‑Erschöpfung oder Upstream‑Hänger; 508 signalisiert LVE‑Limit‑Hits der Site.
• Rollbacks: Ich halte pro Site eigenständige Backups bereit und teste Wiederherstellungen ohne Seiteneffekte.

Wo Projekte bewusst Daten teilen sollen, plane ich wohldefinierte, lesende Schnittstellen statt direkter Dateizugriffe über Pfade.

Checkliste vor der Aktivierung

• Hat jede Domain/Subdomain einen eindeutigen Document‑Root ohne Schreibzugriff von außen?
• Sind Cron‑Jobs, CLI‑Tools und Deploy‑Skripte auf Site‑Pfade umgestellt?
• Sind Schreibpfade (Uploads, Cache, tmp, Sessions) je Site separiert?
• Sind FPM‑Pools, ini‑Werte und OPcache‑Größen pro Site definiert?
• Existieren funktionsgeprüfte Backups je Projekt inklusive Datenbank?
• Sind Symlinks und Inkludes zwischen Sites entfernt oder auf reine Lesefälle reduziert?
• Gibt es Metriken und Alarme pro Site für Fehlerquoten und Ressourcen?

Mit dieser Liste reduziere ich Überraschungen beim Umschalten und sorge dafür, dass Isolation vom ersten Tag an Wirkung zeigt.

Praxisempfehlungen für Agenturen und Projekteigner

Ich frage beim Provider explizit nach Site Isolation und CageFS, weil diese Features in Shared‑Umgebungen echte Abgrenzung liefern. Jede Website behandle ich als eigene Instanz mit separatem Code‑Pfad, Credentials und Deployment, statt Mischbäume zu pflegen. Updates für Kern, Themes und Plug‑ins halte ich eng getaktet, damit bekannte Lücken gar nicht erst offen bleiben. Zugriffsrechte vergebe ich strikt nach Aufgaben und trenne Logins, wenn verschiedene Personen auf unterschiedliche Projekte zugreifen. Für den Tiefergang hilft mir oft ein Blick auf Per‑Site‑Isolation, um den eigenen Stack sinnvoll zu planen und umzusetzen.

Auswahl des Hosting-Pakets: Qualitätsmerkmale erkennen

Ich starre nicht auf Speicherplatz und Traffic, sondern prüfe Sicherheitsfeatures und Trennungskonzepte gleich am Anfang. Anbieter mit CloudLinux, CageFS und Site Isolation liefern spürbare Mehrwerte für Multi‑Site‑Accounts. Wer nur auf einfache chroot‑Mechanismen setzt, lässt Hintertüren offen, die bei gemischten Projekten riskant werden. Wichtig sind zudem klare Ressourcenbudgets, damit planbare Leistung und Reaktionszeiten möglich bleiben. E‑Commerce, Unternehmensseiten und professionelle Blogs gewinnen besonders, weil Ausfälle und Seiteneffekte teuer werden können und Reputation kosten.

Implementierung: Aktivierung und Graceful Restarts

In der Praxis aktiviere ich Isolation dort, wo Projekte eigenständig sind oder ein erhöhtes Risiko tragen, etwa bei vielen Erweiterungen. Nach dem Umschalten beendet CloudLinux die alten PHP‑Prozesse der Domain geordnet und startet sie im neuen Kontext, wodurch Anfragen sauber weiterlaufen. Eigene FPM‑Pools pro Site erleichtern das Tuning von Memory‑Limits, opcache und max_children ohne Nebeneffekte. Cron‑Einträge weise ich der jeweiligen Domain zu, damit geplante Skripte keine fremden Pfade berühren. Diese Schritte ergeben zusammen ein Set‑up, das sich gut warten lässt und Ausfallzeiten spürbar senkt.

Tabellarischer Vergleich: CageFS und Site Isolation im Überblick

Der folgende Vergleich zeigt die Unterschiede zwischen CageFS und Site Isolation entlang typischer Admin‑Fragen. Ich fokussiere auf Sichtbarkeit, Prozesskapselung, Cron‑Handhabung, Ressourcen und typische Anwendungsfälle. Diese Gegenüberstellung hilft mir, Entscheidung und Prioritäten für neue Accounts zu strukturieren. Wer viele unabhängige Sites in einem Konto betreibt, profitiert stärker von der feineren Trennung. Einzelaccounts mit nur einer Installation fahren mit beiden Mechanismen gut, doch Site Isolation schafft zusätzliche Sicherheit für Wachstum.

Aspekt	CageFS (Account‑Ebene)	Site Isolation (Domain‑Ebene)
Sichtbarkeit	Sicht nur auf eigene Account‑Dateien	Sicht je Domain/Subdomain getrennt
Prozesse	Gemeinsame Prozesse je Account	Eigene PHP‑Kontexte und FPM‑Pools je Site
Cron‑Jobs	Können Account‑weit greifen	An Document‑Root der Site gebunden
Lateral movement	Seitensprung zwischen Sites möglich	Seitensprung stark eingeschränkt
Einsatzszenario	Saubere Account‑Trennung	Multi‑Site‑Accounts mit klarer Abgrenzung

Zusammenfassung: Domain-Ebene als Sicherheitshebel

CloudLinux Site Isolation erweitert die bekannte Account‑Kapselung durch CageFS um eine Trennung pro Domain, was Multi‑Site‑Accounts spürbar absichert. Ich halte damit Angriffe und Fehlkonfigurationen site‑lokal und verhindere, dass ein schwaches Projekt Nachbarn in Mitleidenschaft zieht. Getrennte PHP‑Kontexte, gebundene Cron‑Jobs und Symlink‑Schutz bilden eine abgestimmte Sicherheitslinie, die den Betrieb zugleich planbarer macht. In Kombination mit LVE und cgroup v2 erhalte ich klare Ressourcenbudgets und behalte Lastspitzen pro Projekt im Griff. Wer Shared‑Hosting ernsthaft nutzt, sollte Site Isolation aktiv einplanen – die zusätzliche Schicht reduziert Risiko, verkürzt Ausfälle und stärkt die Verlässlichkeit ganzer Umgebungen.