CloudLinux Site Isolation: Større sikkerhed end CageFS ved delt hosting

Webstedsisolering CloudLinux adskiller de enkelte hjemmesider inden for en konto mere strengt end CageFS og udfylder dermed de huller, der ofte opstår ved multi-site-installationer på shared hosting. Jeg viser forskellene, den øgede sikkerhed i hverdagen og konkrete trin til, hvordan du kan udnytte denne funktion på en fornuftig måde.

Centrale punkter

• Finkornet isolering: Adskillelse på domæneniveau forhindrer, at der oprettes sidekonti inden for en konto.
• Adskilte processer: Egne PHP-kontekster pr. websted gør lateral bevægelse vanskeligere.
• Ren Cron-binding: Job er knyttet til document-rooten for det pågældende domæne.
• Flerlagsbeskyttelse: CageFS isolerer konti, mens Site Isolation adskiller hjemmesider inden for den samme konto.
• Planlæggelige ressourcer: LVE-grænser holder belastningstoppe i skak og sikrer hurtige reaktionstider.

CageFS vs. Site Isolation: En sammenligning af arkitekturerne

Med CageFS kan en brugerkonto kun se sine egne filer, rensede systempatier og ingen fremmede processer, hvilket i høj grad begrænser målrettet spionage. Den Webstedsisolering går mere i dybden og skaber et separat overblik over filer og processer inden for den samme konto for hvert domæne eller underdomæne. På den måde mister en kompromitteret installation den direkte adgang til tilstødende projekter, selvom de ligger under det samme login, hvilket i høj grad vanskeliggør sideværts bevægelser. Den, der ønsker at få et teknisk overblik, kan finde det via CageFS-filsystem hurtigt den rigtige sammenligningsstandard. Set ud fra et sikkerheds- og driftsmæssigt perspektiv får adskillelsen på domæneniveau dermed en afgørende Rolle.

Hvorfor det ekstra niveau er vigtigt

Mange bureauer samler flere WordPress‑Websteder i én stor konto, da det gør administrationen og afregningen nemmere. Uden adskillelse på domæneniveau kan en forældet instans imidlertid få adgang til konfigurationsfiler eller stier fra tilstødende projekter, hvilket øger risikoen betydeligt. Det er netop her, at Webstedsisolering og holder angrebsområdet strengt inden for den pågældende dokumentrod. På den måde minimerer jeg afsidesskader, hvis et enkelt projekt svigter, eller et plugin viser en sårbarhed. Denne mere præcise afgrænsning giver mig tid til at styrke de berørte websteder, uden at tilstødende projekter tager skade.

Hverdagen som administrator: Adskillelse pr. domæne, egne PHP-kontekster

Jeg aktiverer Isolering målrettet pr. domæne eller underdomæne og indkapsler dermed særligt risikofyldte CMS-instanser mere stramt. PHP-handlere, FPM-puljer og ini-indstillinger kører adskilt, hvilket forhindrer kompromitteret kode i at aflæse processer fra andre websteder. Cron-jobs knytter jeg automatisk til den respektive dokumentrod, så scripts ikke indirekte får adgang til fremmede mapper. Ved skift afslutter CloudLinux gamle processer fra det berørte domæne på en ordnet måde og genstarter dem i den isolerede kontekst, hvorved forespørgsler straks løber gennem den nye barriere. Denne proces holder afbrydelser korte og lader de øvrige projekter i kontoen være uberørte, hvilket gør driften mærkbart mere sikker gør.

Samspil: CageFS, symlink-beskyttelse og LVE

CageFS Der er stadig den beskyttende barriere, der adskiller konti fra hinanden, mens Site Isolation adskiller projekter inden for en konto fra hinanden. Symlink-beskyttelse og kerne-mekanismer udelukker typiske smutveje via symbolske links eller sti-baserede tricks. Disse lag griber ind i hinanden og gør det svært for angribere at bevæge sig fra et sårbart websted til det næste. Jeg drager dobbelt fordel heraf: På den ene side mindskes angrebsfladen, på den anden side afgrænses vedligeholdelsesarbejdet tydeligt. Således fungerer sikkerhedsmodellen som et afstemt Flersystem i stedet for en enkelt foranstaltning.

Angrebsscenarier: Sådan fungerer isoleringen i praksis

Møder, der er forældede Plug-ins På skrivbare stier ender webshells hurtigt i filsystemet og udspionerer konfigurationer, medmindre der er noget, der adskiller dem. Gennem Site Isolation forbliver adgangen bundet til domænets rod, hvilket forhindrer springet til nabosiden og bremser stjålne adgangsoplysninger. I agenturkonti med mange kundeprojekter stopper adskillelsen desuden bagdøre, der ellers ville fungere som springbræt. Jeg begrænser også fejlkonfigurationer, såsom alt for generøse backup-scripts, fordi det tilladte stiområde er snævrere og klar er defineret. Dermed flyttes skaden fra „på tværs af kontoen“ til „lokalt på webstedet“, hvilket forenkler reaktionstiden og den tekniske efterforskning.

Ydeevne og pålidelighed: Ressourcerne er klart adskilt

Mange betragter CloudLinux primært som Beskyttelse, men adskillelsen har konkrete effekter på responstider og planlægbarheden. LVE-grænser for CPU, RAM, IO og processer forhindrer, at enkelte servere opbruger alle ressourcer og bremser naboserverne. På den måde kan jeg håndtere belastningsspidser pr. projekt uden at slække på sikkerheden eller udsætte resten af serveren for risiko. I kombination med cgroup v2 fordeler jeg ressourcerne på en overskuelig måde og får et mere gennemsigtigt overblik over flaskehalse. Denne opsætning giver mig forudsigelige præstationsværdier, især ved høj frekvens CMS-installationer.

Implementering i detaljer: Trin for trin og sikkerhedskontrol

I praksis har det vist sig at være en god idé at følge en klar rækkefølge, så overgangene forløber problemfrit, og der ikke opstår bivirkninger. Jeg gør således:

• Gennemgang af projekter: Hvert domæne/underdomæne tildeles en entydig dokumentrod uden fælles skrivestier.
• Sikkerhedskopier og testmiljø: Inden aktivering tager jeg sikkerhedskopier af filer og databaser og tester isoleringen i en testkopi.
• Aktivér isolering pr. domæne: Afhængigt af kontrolpanelet flytter jeg webstedet over til sin egen PHP-FPM-pool og adskiller ini-værdierne.
• Oprette nye cron-jobs: Jeg kører cron-jobs fra den respektive dokumentrod og bruger kun projektspecifikke stier.
• Vedligeholdelse af symbolske links: Jeg fjerner symbolske links mellem projekter eller erstatter dem med skrivebeskyttede artefakter, hvis det virkelig er nødvendigt.
• Kontroller »Graceful Restart«: Efter omskiftningen kontrollerer jeg, at de gamle processer er afsluttet, og at de nye er startet korrekt.
• Smoke-tests: Jeg tester login, caching, filoverførsler, webhooks og CLI-opgaver (f.eks. wp-cli) i hver enkelt isoleret kontekst.

Det er vigtigt, at jeg holder skrivbare stier (uploads, cache, sessioner, tmp) strengt adskilt for hvert enkelt websted. Fælles „assets“-mapper er praktiske, men modvirker isolering og gør det sværere at foretage forensisk analyse.

Rettigheds- og sti-koncept: Sådan holdes siderne klart adskilt

En mere detaljeret opdeling bygger på klare filrettigheder og ensartede stier. Jeg følger følgende principper:

• Document-Root som grænse: Applikationer må udelukkende skrive inden for deres rodsti.
• Minimale rettigheder: Mapper 750/755, filer 640/644 – særlige rettigheder kun, hvor det er teknisk nødvendigt.
• Sikr konfigurationsfilerne: Tildel wp-config.php og lignende filer restriktive rettigheder og flyt dem, hvis muligt, ud af webrooten (inden for webstedets kontekst).
• Midlertidige stier pr. websted: Egne tmp- og session-mapper pr. domæne, placeret i den respektive kontekst.
• Ingen fælles „vendor“: Jeg undgår konsekvent at dele Composer-»vendor«-træer på tværs af flere projekter.

Derudover holder jeg ini-indstillingerne på hvert enkelt websted stramme: Jeg indstiller open_basedir, upload_tmp_dir og disable_functions projekt-specifikt i stedet for at gå på kompromis på globalt plan.

WordPress, TYPO3 m.fl.: Projektspecifikke bemærkninger

Med CMS-stacks bliver fordelene hurtigt tydelige, når jeg tager højde for et par detaljer:

• WordPress: Skift Cron til ægte system-cron, så opgaver kører i webstedets kontekst; brug wp-cli separat for hvert domæne.
• Multisite/netværk: Jeg undgår filbaserede krydshenvisninger mellem undersider; medieoffloading eller dedikerede buckets er mere pålidelige.
• TYPO3/Drupal: Adskil skrivebaner (var, public/fileadmin, sites/default/files) strengt fra hinanden, og vedligehold konfigurations-includes for hvert projekt.
• Cache/OPcache: Brug en separat FPM-pool med egen OPcache-hukommelse for hvert websted, så »varme« cacher ikke ophæver hinandens effekt.
• Implementeringer: Opret build-artefakter (Composer, Node) for hvert projekt; undgå fælles build-mapper.

Især i forbindelse med stærkt modulære projekter („headless“, flere frontends) planlægger jeg bevidst grænserne: hvert frontend placeres i sin egen, isolerede kontekst med klare grænseflader.

Overvågning og forensik: Synlighed pr. websted

Isoleringen gør det lettere for mig at udføre fejlfinding, når jeg fører logfiler og nøgletal for hvert domæne:

• Fejl- og adgangslogfiler pr. websted: Sådan kan 4xx/5xx-spidsbelastninger entydigt knyttes til et projekt.
• PHP-FPM-Slowlogs: Identificer langsomme scripts specifikt for en given side uden støj fra andre instanser.
• LVE-metrikker: Overvåg CPU, IO, EP (Entry Processes), NPROC og hukommelse pr. site; opdage overskridelser af grænseværdier i god tid.
• Alarmering: Indstil tærskelværdier pr. projekt (f.eks. mange 503/508 på kort tid) for at kunne reagere målrettet.
• Artefaktsamling: Ved hændelser sikrer jeg kun den berørte site-root – det fremskynder analyserne og reducerer dataskygger.

Da grænserne er klare, kan jeg hurtigere identificere beviser og indikatorer (Indicators of Compromise) og iværksætte målrettede modforanstaltninger.

Ydelsesoptimering pr. websted: Finjustering af puljer og begrænsninger

Adskilte puljer handler ikke kun om sikkerhed, men er også et redskab til finjustering. Jeg tilpasser dem efter det enkelte projekt:

• pm-tilstand: Dynamisk eller on-demand afhængigt af trafikprofilen; afbøde spidsbelastninger med moderat reserve.
• max_children: Bind antallet af samtidige anmodninger og webstedets hukommelsesbudget i stedet for globale standardværdier.
• OPcache-størrelse: Tag højde for webstedets »warm set«; for små cacher medfører fragmentering og »cold starts«.
• Timeouts: Juster connect/read-timeouts for upstream-tjenester (API'er, databaser) pr. site for at undgå, at systemet går i stå.
• Static‑Offloading: Lever statiske ressourcer konsekvent (f.eks. via webserver-cachen) for at aflaste PHP-puljerne.

Alt i alt skaber det en løsning, der afbøder spidsbelastninger på de enkelte lokationer uden at påvirke naboerne. Det gør responstiderne pålidelige og forudsigelige.

Begrænsninger, bivirkninger og fejlfinding

Isolationen flytter ansvaret – det er tilsigtet, men kræver opmærksomhed:

• Delte ressourcer: Centrale upload- eller backup-mapper, der dækker flere websteder, fungerer bevidst ikke længere uden en særlig konfiguration.
• Ældre scripts: Ældre deploy- eller vedligeholdelsesscripts, der forudsætter absolutte kontostier, tilpasser jeg til webstedets rodmappe.
• Import/eksport: Værktøjer med adgang på tværs af websteder skal udskiftes eller drives strengt pr. domæne.
• Fejlmeddelelser: 503/504 tyder ofte på, at puljen er opbrugt, eller at der er en fastlåst opstrømsproces; 508 angiver, at webstedet har nået LVE-grænsen.
• Rollbacks: Jeg har separate sikkerhedskopier klar for hvert websted og tester gendannelser uden bivirkninger.

Når projekter bevidst skal dele data, planlægger jeg veldefinerede, læse-baserede grænseflader i stedet for direkte filadgang via stier.

Tjekliste før aktivering

• Har hvert domæne/underdomæne en entydig dokumentrod uden skriveadgang udefra?
• Er Cron-jobs, CLI-værktøjer og deploy-scripts blevet omstillet til site-stier?
• Er skrivebaner (uploads, cache, tmp, sessions) adskilt for hvert enkelt websted?
• Er FPM-pools, ini-værdier og OPcache-størrelser defineret for hvert websted?
• Findes der funktionskontrollerede sikkerhedskopier for hvert projekt, inklusive databasen?
• Er symlinks og inkluderinger mellem websteder blevet fjernet eller begrænset til skrivebeskyttede tilfælde?
• Findes der målinger og alarmer pr. site for fejlprocenter og ressourcer?

Med denne liste mindsker jeg uventede situationer ved overgangen og sikrer, at isoleringen virker fra første dag.

Praktiske anbefalinger til bureauer og projektansvarlige

Jeg spørger udtrykkeligt hos internetudbyderen om Webstedsisolering og CageFS, fordi disse funktioner sikrer reel adskillelse i delte miljøer. Jeg behandler hvert websted som en separat instans med sin egen kodesti, sine egne adgangsoplysninger og sin egen implementering, i stedet for at vedligeholde blandede strukturer. Jeg sørger for, at opdateringer til kernen, temaer og plugins sker med korte mellemrum, så kendte sårbarheder ikke får lov at forblive uafhjulpet. Jeg tildeler adgangsrettigheder strengt efter opgaver og adskiller logins, når forskellige personer har adgang til forskellige projekter. For at gå mere i dybden hjælper det mig ofte at kigge på Isolering pr. anlæg, for at kunne planlægge og implementere sin egen stack på en fornuftig måde.

Valg af hostingpakke: Sådan genkender du kvalitetskendetegn

Jeg stirrer ikke på Hukommelse og trafik, men tjek sikkerhedsfunktioner og isoleringskoncepter helt fra starten. Udbydere med CloudLinux, CageFS og Site Isolation leverer mærkbar merværdi til multi-site-konti. Den, der kun satser på enkle chroot-mekanismer, efterlader bagdøre åbne, hvilket kan være risikabelt i blandede projekter. Det er desuden vigtigt med klare ressourcebudgetter, så man kan planlægge ydeevne og responstider. E-handel, virksomhedswebsteder og professionelle blogs drager særlig fordel heraf, da nedbrud og bivirkninger kan blive dyre, og Omdømme omkostninger.

Implementering: Aktivering og »graceful restarts«

I praksis aktiverer jeg Isolering der, hvor projekter er selvstændige eller indebærer en øget risiko, f.eks. ved mange udvidelser. Efter skiftet afslutter CloudLinux domænets gamle PHP-processer på en ordnet måde og starter dem i den nye kontekst, hvilket sikrer, at forespørgsler fortsætter uden problemer. Egne FPM-puljer pr. websted gør det nemmere at finjustere hukommelsesgrænser, opcache og max_children uden bivirkninger. Jeg tildeler cron-poster til det pågældende domæne, så planlagte scripts ikke berører fremmede stier. Sammen udgør disse trin en opsætning, der er nem at vedligeholde og mærkbart reducerer nedetiden sænker.

Sammenligning i tabelform: CageFS og Site Isolation i oversigt

Følgende sammenligning viser Forskelle mellem CageFS og Site Isolation ud fra typiske administrator-spørgsmål. Jeg fokuserer på synlighed, procesisolering, håndtering af cron-opgaver, ressourcer og typiske anvendelsesscenarier. Denne sammenligning hjælper mig med at strukturere beslutninger og prioriteter for nye konti. Hvis man driver mange uafhængige sites i én konto, får man større udbytte af den mere detaljerede adskillelse. Enkeltkonti med kun én installation fungerer godt med begge mekanismer, men Site Isolation skaber yderligere Sikkerhed for vækst.

Aspekt	CageFS (kontoniveau)	Webstedsisolering (på domæneniveau)
Synlighed	Visning af egne kontodokumenter alene	Oversigt opdelt efter domæne/underdomæne
Processer	Fælles processer pr. konto	Egne PHP-kontekster og FPM-puljer pr. websted
Cron-opgaver	Kan gælde for hele kontoen	Knyttet til webstedets Document-Root
Sidelæns bevægelse	Det er muligt at skifte mellem siderne	Utroskab er stærkt begrænset
Operationelt scenarie	Tydelig adskillelse af konti	Multi-site-konti med klare afgrænsninger

Resumé: Domæneniveauet som sikkerhedsværktøj

CloudLinux Site Isolation udvider den velkendte kontoindkapsling via CageFS med en adskillelse pr. domæne, hvilket mærkbart øger sikkerheden for multi-site-konti. På den måde begrænser jeg angreb og fejlkonfigurationer til det enkelte site og forhindrer, at et sårbart projekt påvirker naboprojekterne negativt. Adskilte PHP-kontekster, bundne cron-jobs og symlink-beskyttelse udgør en afstemt sikkerhedslinje, der samtidig gør driften mere planlægbar. I kombination med LVE og cgroup v2 får jeg klare ressourcebudgetter og holder belastningsspidser pr. projekt under kontrol. Enhver, der seriøst benytter shared hosting, bør aktivt indregne Site Isolation – det ekstra lag reducerer risikoen, forkorter nedetider og styrker Pålidelighed hele miljøer.