Hoppa till innehåll 
CageFS per webbplats separerar enskilda webbplatser inom ett delat webbhotellskonto strikt från varandra och begränsar därmed risken för sidleds spridning efter ett intrång. Jag redogör för den nya säkerhetsarkitekturen, visar praktiska användningsscenarier och förklarar hur du med hjälp av den kan driva flera projekt säkert inom ett och samma konto.
Centrala punkter
- Webbplatsisolering: Ytterligare uppdelning inom ett konto minskar sidorisker.
- CloudLinux: Utvidgning av CageFS-konceptet till domännivå.
- WordPress: Driva flera instanser säkert parallellt.
- Resurser: Begränsningar för CPU/RAM/I/O kompletterar uppdelningen av filvyer.
- Övning: Aktivering per domän och en tydlig strategi för behörigheter och sökvägar.
Vad „Per-Site CageFS“ konkret kan göra
Utvidgningen isolerar enskilda Domäner inom ett befintligt användar-CageFS, så att varje webbplats endast ser sina egna filer och processer. På så sätt förhindrar jag att ett komprometterat projekt kommer åt konfigurationsfiler, uppladdningar eller nycklar från andra webbplatser i samma konto. Enligt CloudLinux Blogg (beta-tillkännagivande): Per-Site CageFS utökar isoleringen mellan webbplatser inom samma användarkonto och minskar därmed risken för sidledsrörelser. För mig är fördelarna uppenbara: jag kan tydligt segmentera byråkonton, multisite-installationer och testmiljöer utan att störa hostingstrukturen. Denna bakgrundsinformation ger en snabb översikt över principen bakom CageFS: CageFS-filsystemet, som utgör grunden för isoleringen per webbplats.
Varför det inte räcker med enbart kontoisolering
Ett konto samlar ofta flera Projekt – ungefär två webbutiker, tre bloggar och en staging-miljö. Om en exploit angriper ett sårbart plugin kan en angripare, utan ytterligare segmentering, få tillgång till angränsande kataloger och placera ytterligare payloads där. Det är just här som Per-Site CageFS avskärmar åtkomsten till filsystemet och processerna så att varje webbplats fungerar som om den befann sig i en egen Fängelse fungerar. Särskilt vid separata WordPress-instanser med gemensam PHP-användare uppstår annars en risk för eskaleringar, som jag eliminerar genom domänisolering. Detta minskar följdskador, förenklar felsökningen och gör det enklare att planera återställningar.
Så här fungerar webbplatsisolering rent tekniskt
CloudLinux skapar med hjälp av CageFS en virtuell, användarspecifik filsystem; Per-Site-lagret utökar detta till att omfatta domängränser. Varje aktiverad domän tilldelas ett separat visningsområde inom användarens CageFS, inklusive begränsade sökvägar, egna temporära kataloger och isolerad skriptexekvering. Därigenom försvinner främmande wp-config.php-filer, uppladdningsmappar eller nyckelfiler ur den angripna webbplatsens synfält. Cron-jobb, PHP och eventuellt SSH-kommandon använder samma systembibliotek, men ser endast de tilldelade Delmängder i filsystemet. Enligt dokumentationen går det att aktivera eller inaktivera separationen per domän, vilket ger mig möjlighet till detaljerad styrning av live-, staging- och testinstanser.
Jämförelse: Kontoisolering, CageFS per webbplats och containrar
För att kunna fatta ett väl genomtänkt beslut jämför jag tre vanliga Modeller utifrån isoleringsdjup, arbetsinsats och kompatibilitet. Kontoisolering löser problemet med separering mellan kunder, men lämnar interna gränser öppna. CageFS per webbplats täcker denna lucka ur filsystem- och processperspektiv. Containrar skapar hårda gränser, men kräver ofta mer underhåll och anpassningar. En välgrundad klassificering av processisolering tillhandahålls av denna Jämförelse mellan chroot, CageFS och jails.
| Tillvägagångssätt | Åtskillnad mellan konton | Åtskillnad mellan webbplatser i kontot | Kompatibilitet (PHP/CGI/SSH/Cron) | Rörelsens kostnader |
|---|---|---|---|---|
| Kontoisolering (klassisk) | Hög | Låg | Mycket bra | Låg |
| CageFS per webbplats | Hög | Medelhög till hög | Mycket bra | Låg till medelhög |
| Containrar per anläggning | Mycket hög | Mycket hög | Bra till mycket bra | Medelhög till hög |
I miljöer med delad hosting erbjuder Per-Site CageFS en kraftfull kombination av finjusterad Separation och med minimala anpassningar, eftersom skripten i regel körs utan ändringar. På så sätt säkerställer jag den vanligaste sårbarheten: flera fristående webbplatser under ett enda användarkonto.
I praktiken: Att driva flera WordPress-instanser på ett säkert sätt
Jag separerar varje WordPress-instans där Domänisolering och skapar separata PHP-FPM-pooler för varje webbplats, så att loggar, opcache och begränsningar kan tilldelas korrekt. Dessutom anger jag separata SALT-värden och nycklar för varje webbplats i wp-config.php och förhindrar all korsreferens genom filbehörigheter och motsvarigheter till open_basedir. Uppladdningar placerar jag strikt inom respektive dokumentrot och förbjuder globala delade uppladdningskataloger. Under distributioner håller jag tillfälliga sökvägar inom webbplatsen och rensar bort byggartefakter omedelbart så att inga onödiga angreppsyta kvarstår. För Composer- eller NPM-cacher använder jag webbplatslokala Kataloger, så att inga korsreaktioner uppstår.
Prestanda och resursstyrning i samspel
Per-Site CageFS hanterar filvyn; den Prestanda Jag säkerställer detta genom att sätta gränser för CPU, RAM, I/O och processer på konto- eller poolnivå. På så sätt förhindrar jag att en webbplats orsakar för stor belastning på grund av felaktiga plugins och bromsar upp hela kontot. I många konfigurationer ingår detta i LVE- eller liknande kvoter, som jag finjusterar per pool eller konto. Jag kombinerar detta med begäranbegränsning i webbservern eller WAF, så att trafiktoppar hanteras på ett ordnat sätt. Denna kombination av isolering och kvoter ökar tjänsternas säkerhet och förutsägbarhet Lastfördelning.
Skyddskedja: Vad Per-Site CageFS inte ersätter
Isoleringen förhindrar genomskådning, men jag håller uppdateringar, Härdning av PHP och strikta lösenord tillämpas fortfarande konsekvent. Även MFA för administratörsinloggningar, minimala filbehörigheter och uppladdningsfilter är fortfarande obligatoriska. En WAF, hastighetsbegränsningar och kontinuerlig loggning täcker ytterligare vägar som ren filåtkomstseparering inte kontrollerar. Jag kontrollerar dessutom regelbundet cron-jobb och integrationstoken, som angripare ofta glömmer bort att ta bort. Mer information om samspelet mellan kundseparering och säkerhetshärdning finns i denna guide till Säkerhet vid delad hosting, som understryker denna tankegång.
Uppbyggnad och vanliga hinder
Jag aktiverar domänisoleringen selektivt för varje Webbplats och testar därefter SSH-, Cron- och PHP-åtkomst under verkliga förhållanden. Absoluta sökvägar i distributionsskript eller plugins kan orsaka problem, därför använder jag relativa sökvägar eller variabler. Jag undviker symboliska länkar mellan projekt eftersom de urholkar separationsprincipen; istället lägger jag hellre in nödvändiga bibliotek i repositoriet för varje webbplats. För säkerhetskopior definierar jag separata arkiv och säkerhetskopierar loggar per domän, så att återställning och forensisk analys förblir överskådliga. När det gäller behörigheter har 640 för filer och 750 för mappar visat sig fungera bra, plus Ägare som passar respektive PHP-pool.
Kostnads-nyttoanalys för byråer och frilansare
Jag väger säkerhetsvinsten mot den administrativa tidsåtgången och de potentiella kostnaderna för driftstopp som en avvikande händelse skulle medföra, och kommer fram till följande Euro-Grund. Redan några timmars incidenthantering kostar ofta betydligt mer än en liten månatlig tilläggskostnad för bättre isolering. För byråkonton med flera kundprojekt minskar segmenteringen märkbart ansvars- och anseenderisken. Även säkerhetskopierings- och återställningsprocesser löper smidigare, eftersom jag kan återställa enskilda webbplatser med precision. Sammantaget bidrar CageFS per webbplats till en mer tillförlitlig Operativ ledning med förutsägbara arbetsflöden.
Checklista: När CageFS per anläggning blir obligatoriskt
Jag aktiverar domänisoleringen så snart flera Installationer körs i ett och samma konto och har olika uppdateringscykler. Lika viktigt: separata projektteam eller externa administratörskonton, vilket ökar risken för oavsiktliga ingrepp. Stora uppladdningsvolymer, filkonverterare eller bildbehandling motiverar dessutom en uppdelning, eftersom det ofta är här som säkerhetsluckor uppstår. Olika efterlevnadskrav (t.ex. kunder, marknader, dataskydd) talar också för mer detaljerade segment. Den som driver staging, testning och live-drift parallellt drar nytta av tydligt åtskilda feldomäner och en klar Kriminalteknik.
Krav och kompatibilitet i praktiken
Innan jag tar Per-Site CageFS i drift kontrollerar jag körmiljön: vilken PHP-hanterare som används (till exempel PHP-FPM, lsapi), vilken webbserver som är aktiv, om panelintegration finns tillgänglig samt hur cron-jobb och SSH-sessioner hanteras. I typiska delade miljöer fortsätter applikationerna att fungera utan kodändringar. Jag ser till att det finns en egen dokumentrot per domän, att sökvägarna är entydiga (t.ex. /home/user/sites/projekt-a/public) och att en dedikerad PHP-FPM-pool används per webbplats. För cron-jobb använder jag separata crontabs per domän eller – där kontrollpanelen sammanför dem – tydliga prefix och loggvägar, så att jobben inom sina Fängelser arbete.
Att tydligt skilja mellan databaser, cacheminnen och sessioner
Filvyn är bara en del av helheten. Jag drar gränsen ända till databasen och cacheminnena. För varje webbplats skapar jag en egen databas och en egen databasanvändare med minimala behörigheter. För objekt- eller sidcacher (t.ex. Redis, Memcached) använder jag separata instanser per webbplats eller åtminstone nyckelprefix och dedikerade databaser/namnrymder. PHP-sessioner hamnar i webbplatsspecifika sökvägar; jag ställer in session.save_path separat för varje FPM-pool. Om jag använder en central kö eller ett sökbackend separerar jag index och ämnen per webbplats. Denna princip om „separering ända till sista ledet“ förhindrar att incidenter sprider sig till andra system.
CI/CD och driftsättningar under isolering
I byggpipelines gör jag isolering till standard: För varje webbplats finns ett eget distributionsjobb som endast har åtkomst till webbplatsens katalog. Jag packar upp artefakterna inom domänroten, utför därefter ägar-/gruppkorrigeringar och ogiltigförklarar endast de cacher som berörs. WP-CLI-kommandon körs i respektive CageFS-kontext, så att de inte påverkar andra projekt. Miljövariabler håller jag separata för varje webbplats, medan hemligheter förblir i webbplatsens egna konfigurationsfiler eller i panelens hemlighetslagring. För att undvika driftstopp använder jag atomära symlänk-växlingar inom domänens gränser (t.ex. current/releases), men ser till att symlänkarna inte pekar på angränsande projekt. Kontroller efter driftsättning (hälsokontroll, 404/500-skanning, behörighetskontroll) är obligatoriska för varje webbplats.
Övervakning, loggning och forensisk analys
Jag separerar loggarna konsekvent: åtkomst- och felloggar per domän, separata PHP- och Cron-loggar inklusive rotation och lagringstid. Vid en incident kan jag på så sätt rekonstruera tidslinjen för en enskild webbplats utan att behöva gå igenom hela kontot. Som komplement använder jag filintegritetskontroller (kontrollsummor för kärnkataloger), distribuerade revisionsloggar för administratörsåtgärder och enkla Canary-filer som tidigt upptäcker manipulationer. För larm räcker det ofta med tröskelvärden: plötsliga ökningar av 500-fel, ovanliga uppladdningsstorlekar, kraftigt växande inod-beläggningar eller överdrivna startar av PHP-arbetare. Dessa signaler kopplar jag till tydliga handlingsplaner: spärra webbplatsen, kontrollera säkerhetskopior, säkerhetskopiera artefakter, återstart i isolerad miljö.
Särskilda fall i WordPress: Multisite, MU-plugins och uppladdningsflöden
När det gäller WordPress Multisite väger jag för- och nackdelar: En Multisite-installation drar mindre nytta av CageFS per webbplats, eftersom flera webbplatser medvetet delar samma kodbas och struktur. Om jag behöver strängare gränser (oberoende team, separata cacher, tydlig spårbarhet) föredrar jag att sätta upp enskilda instanser och isolera dem. MU-plugins, drop-ins eller globala Must-Use-bibliotek distribuerar jag endast internt på webbplatsen och undviker delade mappar. Mediearbetsflöden (CDN, bildoptimering, konverterare) körs inom domänens ”cage”; jag utesluter uppladdningar från en webbplats till kataloger på en annan. Om ett team vill dela tillgångspipelines replikerar jag dessa per webbplats eller kapslar in dem som ett paket som integreras i respektive repo.
Migrationsväg: Från monolitisk till segmenterad kontoarkitektur
Många konton börjar med en stor public_html-mapp och växer med tiden. Jag går tillväga i fem steg: 1) Inventering: Vilka webbplatser, domäner, cron-jobb, databaser och hemligheter finns? 2) Fastställa sökvägslayout: separat rotmapp, temp-mapp, loggmapp och säkerhetskopieringsmapp för varje webbplats. 3) Definiera PHP-FPM-pooler per domän och ställa in gränsvärden. 4) Flytta filer, justera behörigheter, rensa upp absoluta sökvägar och inkluderingar. 5) Aktivera CageFS per webbplats, köra belastningstester, sätta igång övervakning. Under tiden har jag en återställningsstrategi redo (snapshots, separata säkerhetskopior). Efter övergången kontrollerar jag om verktyg som WP-CLI, Composer, bildbehandlingsprocesser och cron-jobb körs inom rätt omfattning och justerar vid behov sökvägsvariablerna.
Felbilder och felsökning
- 403/404 efter aktivering: Oftast pekar omskrivningsregler eller inkluderingar på sökvägar utanför domänens rotkatalog. Jag korrigerar sökvägarna till relativa varianter eller använder variabler.
- Composer/NPM kraschar: Globala cacheminnen syns inte. Jag skapar webbplatsspecifika cachekataloger och justerar HOME/TMP-variablerna vid driftsättningen.
- WP-CLI hittar inte wp-config.php: körs inte i domänens rotkatalog. Jag anger arbetskatalogen korrekt eller anger sökvägen uttryckligen.
- Cron-jobb: Cron-användare eller sökvägar har inte angetts per domän. Jag kontrollerar miljövariabler, binära sökvägar och loggmål inom webbplatsens isolerade miljö.
- Uppladdningar misslyckas: session.save_path eller tmp_dir pekar på fel katalog. Jag tilldelar webbplatsspecifika temporära sökvägar för varje FPM-pool.
- Delad bibliotek saknas: Symlänken till det angränsande projektet är blockerad. Jag replikerar biblioteket till varje webbplats eller integrerar det som ett paket i distributionen.
Styrning och åtkomstmodell
Även om allt är tekniskt åtskilt kvarstår frågan om åtkomst. Jag tilldelar dedikerade SSH-/SFTP-åtkomster per webbplats eller begränsar åtkomsten till kontrollpanelen till respektive domän. Utvecklare och byråteam får endast de nycklar och behörigheter som de verkligen behöver. För nödfall har jag en ”break-glass”-process redo (tillfälligt utökade behörigheter, fullständig loggning, efterföljande återkallande). Vid revisioner dokumenterar jag per webbplats: sökvägar, pooler, gränsvärden, ansvariga, RBAC-tilldelningar och säkerhetskopior. På så sätt förblir segmenteringen inte bara tekniskt, utan även organisatoriskt robust.
Kortfattat sammanfattat
Per-Site CageFS kompletterar den befintliga användarseparationen med en Webbplats-nivå och minskar därmed effektivt risken för laterala rörelser. Jag anser att detta är ett praktiskt steg, eftersom många konton sammanför flera oberoende projekt. Kombinationen av separata filvyer och resursbegränsningar skapar ordning i prestanda, säkerhet och drift. Den som hostar flera WordPress- eller webbutiksinstanser sparar tid vid felsökning, säkerhetskopiering och återställning efter incidenter. Med tydliga behörigheter, uppdateringar, MFA och loggning skapas en hållbar Säkerhetskedja, vilket gör delad hosting betydligt mer stabil.
