CloudLinux Site Isolation: meer veiligheid dan CageFS bij shared hosting

Site-isolatie CloudLinux scheidt afzonderlijke websites binnen één account strikter dan CageFS en vult daarmee de hiaten op die vaak voorkomen bij multi-site-installaties in shared hosting. Ik laat je de verschillen zien, de veiligheidsvoordelen in de dagelijkse praktijk en concrete stappen om deze functie op een zinvolle manier te gebruiken.

Centrale punten

• Fijnkorrelige isolatie: Scheiding op domeinniveau voorkomt dat er binnen één account naar andere domeinen wordt overgeschakeld.
• Afzonderlijke processen: Aparte PHP-contexten per site bemoeilijken laterale verplaatsing.
• Nette Cron-koppeling: Jobs zijn gekoppeld aan de documentroot van het betreffende domein.
• Meerlaagse bescherming: CageFS isoleert accounts, Site Isolation scheidt websites binnen een account.
• Planbare middelen: LVE-limieten houden piekbelastingen onder controle en waarborgen reactietijden.

CageFS versus Site Isolation: een vergelijking van de architectuur

Met CageFS Een account ziet alleen zijn eigen bestanden, opgeschoonde systeempaden en geen processen van anderen, wat gerichte spionage sterk beperkt. De Site-isolatie gaat dieper in op de materie en biedt per domein of subdomein een apart overzicht van bestanden en processen binnen hetzelfde account. Zo verliest een gehackte installatie de directe toegang tot aangrenzende projecten, zelfs als deze onder dezelfde inloggegevens vallen, wat zijdelingse bewegingen aanzienlijk bemoeilijkt. Wie zich technisch wil verdiepen, vindt via de CageFS-bestandssysteem snel de juiste maatstaf. Vanuit het oogpunt van veiligheid en bedrijfsvoering wint de scheiding op domeinniveau daarmee een doorslaggevend Rol.

Waarom dat extra niveau belangrijk is

Veel bureaus bundelen meerdere WordPress‑Sites in één groot account, omdat dit het beheer en de facturering vereenvoudigt. Zonder scheiding op domeinniveau kan een verouderde instantie echter configuratiebestanden of paden van aangrenzende projecten inzien, wat het risico aanzienlijk vergroot. Precies hier komt Site-isolatie en beperkt de aanvalsruimte strikt tot de betreffende documentroot. Zo minimaliseer ik de kans op neveneffecten wanneer een afzonderlijk project zwakheden vertoont of een plug-in een kwetsbare plek laat zien. Deze nauwkeurigere afbakening geeft me de tijd om de getroffen sites te beveiligen, zonder dat aangrenzende projecten schade oplopen.

Dagelijkse taken van de beheerder: scheiding per domein, eigen PHP-contexten

Ik activeer Isolatie gericht per domein of subdomein, waardoor bijzonder risicovolle CMS-instanties strakker worden ingekapseld. PHP-handlers, FPM-pools en ini-instellingen draaien gescheiden, waardoor gecompromitteerde code geen toegang krijgt tot processen van andere sites. Cron-taken koppel ik automatisch aan de betreffende documentroot, zodat scripts niet via omwegen toegang krijgen tot vreemde mappen. Bij het omschakelen beëindigt CloudLinux oude processen van het betreffende domein op een geordende manier en start deze opnieuw op in de geïsoleerde context, waardoor verzoeken onmiddellijk door de nieuwe barrière lopen. Dit proces houdt onderbrekingen kort en laat de overige projecten in het account onaangetast, wat de werking merkbaar veiliger doet.

Samenwerking: CageFS, symlink-beveiliging en LVE

CageFS blijft de afscherming die accounts van elkaar scheidt, terwijl Site Isolation projecten binnen één account van elkaar afkoppelt. Symlink-beveiliging en kernelmechanismen sluiten typische achterdeurtjes via symbolische links of op paden gebaseerde trucs uit. Deze lagen vullen elkaar aan en maken het aanvallers moeilijk om zich van de ene kwetsbare site naar de andere te verplaatsen. Ik profiteer hiervan op twee manieren: enerzijds wordt het aanvalsoppervlak verkleind, anderzijds worden onderhoudswerkzaamheden duidelijk afgebakend. Zo werkt het beveiligingsmodel als een op elkaar afgestemd Meervoudig systeem in plaats van één enkele maatregel.

Aanvalsscenario’s: zo werkt de isolatie in de praktijk

Verouderde bijeenkomsten Plug-ins Op schrijfbare paden komen webshells al snel in het bestandssysteem terecht en spioneren ze configuraties uit, tenzij er een scheiding is. Door Site Isolation blijft de toegang beperkt tot de domeinroot, wat de sprong naar de naburige site voorkomt en het misbruik van gestolen inloggegevens afremt. In bureauaccounts met veel klantprojecten voorkomt deze scheiding bovendien achterdeurtjes die anders als springplank zouden dienen. Ook beperk ik verkeerde configuraties, zoals te ruimhartige back-upscripts, omdat de toegestane padruimte beperkter is en duidelijk is gedefinieerd. Zo verschuift de schade van „accountbreed“ naar „site-specifiek“, wat de reactietijd verkort en het forensisch onderzoek vereenvoudigt.

Prestaties en betrouwbaarheid: middelen duidelijk gescheiden

Velen zien CloudLinux in de eerste plaats als Bescherming, maar de scheiding heeft tastbare gevolgen voor de reactietijden en de planbaarheid. LVE-limieten voor CPU, RAM, IO en processen voorkomen dat afzonderlijke sites alle middelen opgebruiken en hun buren vertragen. Zo vang ik pieken in de belasting per project op, zonder de beveiliging te verzwakken of de rest van de server in gevaar te brengen. In combinatie met cgroep v2 Zo verdeel ik middelen op een traceerbare manier en houd ik knelpunten beter in de gaten. Deze opzet levert mij voorspelbare prestatiecijfers op, vooral bij hoge frequenties CMS-installaties.

Implementatie in detail: stappenreeks en controles ter waarborging van de veiligheid

In de praktijk blijkt een duidelijke volgorde zeer nuttig te zijn, zodat het omschakelen soepel verloopt en er geen neveneffecten optreden. Ik ga als volgt te werk:

• Projecten bekijken: elk domein/subdomein krijgt een unieke documentroot zonder gedeelde schrijfpaden.
• Back-ups en staging: Voordat ik de wijzigingen activeer, maak ik een back-up van bestanden en databases en test ik de isolatie in een staging-kopie.
• Isolatie per domein inschakelen: afhankelijk van het paneel zet ik de site over naar een eigen PHP-FPM-pool en scheid ik de ini-waarden.
• Cron-taken opnieuw koppelen: ik start cron-taken vanuit de betreffende documentroot en gebruik uitsluitend projectspecifieke paden.
• Beheer van symbolische koppelingen: ik verwijder kruiskoppelingen tussen projecten of vervang ze door alleen-lezen artefacten, indien dat echt nodig is.
• Controleer of de herstart soepel is verlopen: na het omschakelen controleer ik of de oude processen zijn beëindigd en de nieuwe netjes zijn gestart.
• Smoke-tests: ik controleer het inloggen, caching, het uploaden van bestanden, webhooks en CLI-taken (bijv. wp-cli) in elke afzonderlijke context.

Het is belangrijk dat ik schrijfmappen (uploads, cache, sessies, tmp) strikt per site gescheiden houd. Gedeelde „assets“-mappen zijn handig, maar staan isolatie in de weg en bemoeilijken forensisch onderzoek.

Rechten- en padconcept: zo blijven sites duidelijk gescheiden

Een fijnmazigere indeling is afhankelijk van duidelijke bestandsrechten en consistente paden. Ik hanteer de volgende uitgangspunten:

• Document-Root als grens: applicaties mogen uitsluitend binnen hun rootpad schrijven.
• Minimale rechten: mappen 750/755, bestanden 640/644 – speciale rechten alleen waar dit technisch noodzakelijk is.
• Configuratiebestanden beveiligen: wp-config.php en dergelijke voorzien van restrictieve rechten en, indien mogelijk, uit de webroot verwijderen (binnen de context van de site).
• Tijdelijke paden per site: aparte tmp- en session-mappen per domein, die zich in de betreffende context bevinden.
• Geen gedeelde vendor: ik vermijd consequent gedeelde Composer-„vendor“-bomen die in meerdere projecten worden gebruikt.

Daarnaast houd ik de ini-instellingen per site strak: ik stel open_basedir, upload_tmp_dir en disable_functions per project in, in plaats van globale compromissen te sluiten.

WordPress, TYPO3 & Co.: projectspecifieke aanwijzingen

Bij CMS-stacks worden de voordelen al snel duidelijk als ik rekening houd met een paar details:

• WordPress: Cron omzetten naar de echte systeem-cron, zodat taken in de context van de site worden uitgevoerd; wp-cli per domein afzonderlijk gebruiken.
• Multisite/netwerk: Ik vermijd op bestanden gebaseerde kruisverwijzingen tussen subsites; het uitbesteden van media of speciale buckets zijn betrouwbaarder.
• TYPO3/Drupal: Schrijfpaden (var, public/fileadmin, sites/default/files) strikt scheiden en configuratie-includes per project bijhouden.
• Cache/OPcache: Gebruik voor elke site een aparte FPM-pool met een eigen OPcache-geheugen, zodat warme caches elkaar niet tenietdoen.
• Implementaties: bouwartefacten (Composer, Node) per project genereren; gemeenschappelijke bouwmappen vermijden.

Vooral bij sterk modulaire projecten („headless“, meerdere frontends) stel ik bewust grenzen vast: elke frontend krijgt een eigen, geïsoleerde context met duidelijke interfaces.

Monitoring en forensisch onderzoek: zichtbaarheid per locatie

De scheiding maakt het oplossen van problemen voor mij gemakkelijker als ik logs en statistieken per domein bijhoud:

• Fout- en toegangslogboeken per site: zo kunnen pieken in 4xx/5xx-codes duidelijk aan een project worden gekoppeld.
• PHP-FPM-slowlogs: trage scripts per site identificeren, zonder ruis van andere instanties.
• LVE-statistieken: CPU, IO, EP (Entry Processes), NPROC en geheugen per site monitoren; overschrijdingen van limieten vroegtijdig herkennen.
• Alarmering: stel drempelwaarden per project in (bijv. veel 503/508-fouten in korte tijd) om gericht te kunnen reageren.
• Verzameling van artefacten: Bij incidenten zet ik alleen de betreffende site-root opzij – dat versnelt de analyse en beperkt de gegevensschaduw.

Omdat de grenzen duidelijk zijn, kan ik bewijsmateriaal en indicatoren (Indicators of Compromise) sneller toewijzen en gerichtere tegenmaatregelen nemen.

Prestatie-optimalisatie per site: pools en limieten nauwkeurig afstemmen

Afzonderlijke pools zijn niet alleen een veiligheidsmaatregel, maar ook een manier om de prestaties te optimaliseren. Ik pas ze per project aan:

• pm-modus: dynamisch of on-demand, afhankelijk van het verkeersprofiel; piekbelastingen opvangen met een bescheiden reserve.
• max_children: het aantal gelijktijdige verzoeken en het geheugenbudget van de site vastleggen, in plaats van algemene standaardwaarden.
• Grootte van de OPcache: houd rekening met de ‘warm set’ van de site; te kleine caches leiden tot fragmentatie en koude starts.
• Time-outs: pas de connect-/read-time-outs van upstream-diensten (API's, DB) per site aan om vastlopers te voorkomen.
• Static-offloading: statische assets consequent leveren (bijv. via de webservercache), zodat de PHP-pools worden ontlast.

Al met al ontstaat er een opstelling die pieken per locatie opvangt zonder de buren te beïnvloeden. Dat zorgt ervoor dat de reactietijden betrouwbaar en voorspelbaar zijn.

Beperkingen, bijwerkingen en probleemoplossing

Door de isolatie verschuiven verantwoordelijkheden – dat is de bedoeling, maar het vereist wel aandacht:

• Gedeelde bronnen: centrale upload- of back-upmappen die over meerdere sites lopen, werken bewust niet meer zonder speciale configuratie.
• Legacy-scripts: Oudere implementatie- of onderhoudsscripts die absolute accountpaden gebruiken, pas ik aan de root van de site aan.
• Importer/Exporter: Tools die over de grenzen van de site heen toegankelijk zijn, moeten worden vervangen of strikt per domein worden beheerd.
• Foutmeldingen: 503/504 duiden vaak op een lege pool of een vastgelopen upstream; 508 geeft aan dat de LVE-limiet van de site is bereikt.
• Rollbacks: ik zorg per site voor afzonderlijke back-ups en test herstelprocedures zonder neveneffecten.

Wanneer projecten bewust gegevens moeten delen, ontwerp ik duidelijk gedefinieerde, alleen-lezen interfaces in plaats van directe toegang tot bestanden via paden.

Checklist vóór de activering

• Heeft elk domein/subdomein een unieke documentroot zonder schrijftoegang van buitenaf?
• Zijn cron-taken, CLI-tools en deploy-scripts aangepast naar site-paden?
• Zijn de schrijfpaden (uploads, cache, tmp, sessies) per site gescheiden?
• Zijn FPM-pools, ini-waarden en OPcache-groottes per site gedefinieerd?
• Zijn er per project op werking geteste back-ups, inclusief de database?
• Zijn symlinks en includes tussen sites verwijderd of beperkt tot alleen-lezen?
• Zijn er per site statistieken en waarschuwingen beschikbaar voor foutpercentages en resources?

Met deze lijst voorkom ik verrassingen bij de omschakeling en zorg ik ervoor dat de isolatie vanaf de eerste dag effect sorteert.

Praktijkaanbevelingen voor bureaus en projecteigenaren

Ik vraag dit expliciet na bij de provider Site-isolatie en CageFS, omdat deze functies in gedeelde omgevingen echte afscheiding bieden. Ik behandel elke website als een afzonderlijke instantie met een eigen codepad, inloggegevens en implementatie, in plaats van gemengde structuren te onderhouden. Ik houd updates voor de kern, thema’s en plug-ins strak gesynchroniseerd, zodat bekende kwetsbaarheden niet onbehandeld blijven. Toegangsrechten wijs ik strikt toe op basis van taken en ik scheid logins wanneer verschillende personen toegang hebben tot verschillende projecten. Voor een dieper inzicht helpt het me vaak om een blik te werpen op Per-site-isolatie, om de eigen stack op een zinvolle manier te plannen en te implementeren.

Een hostingpakket kiezen: kwaliteitskenmerken herkennen

Ik staar niet naar Opslagruimte en verkeer, maar controleer vanaf het begin ook de beveiligingsfuncties en isolatieconcepten. Aanbieders met CloudLinux, CageFS en Site Isolation bieden merkbare meerwaarde voor accounts met meerdere sites. Wie alleen vertrouwt op eenvoudige chroot-mechanismen, laat achterdeurtjes open die bij gemengde projecten risico’s met zich meebrengen. Daarnaast zijn duidelijke resourcebudgetten belangrijk, zodat planbare prestaties en responstijden mogelijk blijven. E-commerce, bedrijfswebsites en professionele blogs hebben hier bijzonder veel baat bij, omdat storingen en neveneffecten duur kunnen uitvallen en Reputatie kosten.

Implementatie: activering en graceful restarts

In de praktijk activeer ik Isolatie waar projecten zelfstandig zijn of een verhoogd risico met zich meebrengen, bijvoorbeeld bij veel uitbreidingen. Na het omschakelen beëindigt CloudLinux de oude PHP-processen van het domein op een geordende manier en start deze opnieuw op in de nieuwe context, waardoor verzoeken soepel blijven verlopen. Eigen FPM-pools per site vergemakkelijken het afstemmen van geheugenlimieten, opcache en max_children zonder neveneffecten. Ik wijs cron-vermeldingen toe aan het betreffende domein, zodat geplande scripts geen externe paden raken. Deze stappen zorgen samen voor een opstelling die goed te onderhouden is en downtime merkbaar verlaagt.

Vergelijking in tabelvorm: CageFS en Site Isolation in één oogopslag

De volgende vergelijking toont de Verschillen een vergelijking tussen CageFS en Site Isolation aan de hand van typische beheerdersvragen. Ik richt me op zichtbaarheid, procesisolatie, het beheer van cron-taken, resources en typische gebruikssituaties. Deze vergelijking helpt me om beslissingen en prioriteiten voor nieuwe accounts te structureren. Wie veel onafhankelijke sites in één account beheert, profiteert meer van de fijnere scheiding. Afzonderlijke accounts met slechts één installatie werken goed met beide mechanismen, maar Site Isolation biedt extra Beveiliging voor groei.

Aspect	CageFS (op accountniveau)	Site-isolatie (domeinniveau)
Zichtbaarheid	Alleen inzage in de bestanden van je eigen account	Overzicht per domein/subdomein afzonderlijk
Processen	Gedeelde processen per account	Eigen PHP-contexten en FPM-pools per site
Cron-taken	Kunnen voor het hele account gelden	Gekoppeld aan de documentroot van de site
Zijdelingse beweging	Overschakelen tussen websites mogelijk	Vreemdgaan is sterk aan banden gelegd
Operationeel scenario	Duidelijke scheiding van accounts	Multi-site-accounts met een duidelijke afbakening

Samenvatting: het domeinniveau als hefboom voor de beveiliging

CloudLinux Site Isolation breidt de bekende account-isolatie via CageFS uit met een scheiding per domein, wat multi-site-accounts merkbaar beter beveiligt. Zo houd ik aanvallen en verkeerde configuraties beperkt tot één site en voorkom ik dat een kwetsbaar project nadelige gevolgen heeft voor naburige sites. Gescheiden PHP-contexten, gekoppelde cron-taken en symlink-beveiliging vormen een afgestemde beveiligingslinie die de bedrijfsvoering tegelijkertijd beter planbaar maakt. In combinatie met LVE en cgroup v2 krijg ik duidelijke resourcebudgetten en houd ik piekbelastingen per project onder controle. Wie serieus gebruikmaakt van shared hosting, zou site-isolatie actief moeten inplannen – deze extra beveiligingslaag vermindert risico’s, verkort uitval en versterkt de Betrouwbaarheid hele omgevingen.