CageFS i den dagliga driften av webbhotell: Isolering av filsystem mellan kundkonton

Varför webbhotellskonton behöver isolering

Vid delad hosting driver flera kunder sina webbplatser på samma server. Om ett skript i konto A utsätts för intrång kan det försöka samla in information om miljön och få tillgång till filer på andra konton. Detta kan omfatta konfigurationsfiler med inloggningsuppgifter eller personuppgifter. Separationen mellan kontona är avsedd att försvåra sådana åtkomstförsök, trots att infrastrukturen delas.

Dessa är Synlighet och åtkomsträttigheter Olika frågor. Ett katalognamn kan vara synligt även om åtkomst till dess innehåll nekas på grund av filbehörigheter. Omvänt räcker inte en begränsad visning i sig som ersättning för noggrant inställda behörigheter: Det som är tillgängligt inom miljön måste fortfarande skyddas på lämpligt sätt.

CageFS utökar behörigheterna med en användarspecifik filsystemsmiljö. En process i den avsedda kontexten får inte automatiskt samma inblick i värddatorn som en administratör. Detta syftar till att ett skript från konto A inte utan vidare ska kunna utforska andra kontons kataloger. Vilka områden som faktiskt är synliga beror på konfigurationen.

För operatörerna innebär detta en ytterligare Separationsskikt, ingen garanti mot eventuella konsekvenser för andra kunder. Fel i delade tjänster, alltför omfattande behörigheter eller en ofullständig tjänsteintegration kan påverka skyddseffekten. Därför måste isoleringen kontrolleras där kundprogrammen faktiskt körs, och inte enbart utifrån en inställning i administrationsgränssnittet.

För webbhotellskunder är denna distinktion också viktig: Att en egen applikation inte ser någon extern katalog beskriver i första hand endast dess specifika körningskontext. Det bevisar varken konfigurationen av alla tjänster eller skyddet av alla andra konton. Leverantören förblir ansvarig för den övergripande konfigurationen och kontrollen.

Hur CageFS utformar filsystemets vy

CageFS ger användarna en egen vy av filsystemet. Grunden är Skelett: en mall med filer och kataloger som tillhandahålls för respektive miljö. Nödvändiga delar införlivas; även användarens egen hemkatalog integreras i dennes miljö. Den synliga katalogträdet är alltså inte bara en oförändrad kopia av värdmiljöns vy.

Integreringen kan illustreras med hjälp av ett verktyg: En administratör installerar ett program på värddatorn, men en kundprocess kan inte hitta det i sin miljö. Detta innebär inte automatiskt ett installationsfel. Programmet kan finnas på värddatorn utan att vara tillgängligt i Skeleton eller via de integreringar som är avsedda för kunden.

Omvänt utökar varje ytterligare fil som tillhandahålls den miljö som en process kan se. Detsamma gäller för en inbunden katalog. Systemadministratörer måste därför väga funktionsbehovet mot den extra synligheten: En applikation kan behöva ett visst verktyg och dess beroenden, men inte nödvändigtvis en hel katalog på värddatorn.

Die Monteringskonfiguration avgör vilka delar av filsystemet som visas i miljön. Den avgör dock inte ensam om en process får läsa, ändra eller köra en synlig fil. För detta spelar bland annat ägarskap och behörigheter fortfarande en roll. En synlig sökväg är alltså inte detsamma som tillåten skrivbehörighet.

Den egna hemkatalogen är särskilt viktig i det dagliga arbetet med webbhotell: där finns vanligtvis filerna för det aktuella kontot. Integreringen möjliggör åtkomst inom det avsedda sammanhanget, medan resten av vyn begränsas. Huruvida en specifik applikation når alla nödvändiga filer beror dock på dess konfiguration och de faktiskt tillgängliga sökvägarna.

CageFS, LVE och gemensamma risker

CageFS och LVE löser olika problem. CageFS utformar en användares filsystemvy och körningskontext; LVE används för att övervaka och begränsa resurser såsom CPU, minne samt in- och utdata. En process med begränsad åtkomst till filsystemet kan fortfarande kräva resurser. Omvänt förhindrar en resursbegränsning i sig inte åtkomst till felaktigt delade filer.

En kontrollpanel för webbhotell fyller ytterligare en funktion: den hanterar bland annat konton och kan integrera CloudLinux-komponenter. Enbart installationen av en kontrollpanel innebär dock inte att varje webbprocess, varje shell och varje schemalagd uppgift körs i den avsedda CageFS-kontexten. Operatörer måste kontrollera vilken integration som passar just deras plattform.

CageFS är inte en separat virtuell maskin för varje konto. Kontona använder fortfarande en gemensam kärna och kan vara beroende av gemensamt drivna tjänster. En sårbarhet eller felkonfiguration i dessa gemensamma komponenter ingår därför fortfarande i hotbilden. Filsystemisoleringen begränsar en del av den synliga miljön, men ersätter inte säkerhetsåtgärderna och underhållet av värddatorn.

Även inom ett korrekt isolerat konto kvarstår risker. En sårbar applikation kan till exempel avslöja sina egna data; stulna inloggningsuppgifter kan ge en angripare åtkomst inom ramen för det berörda kontot. CageFS korrigerar varken osäker applikationskod eller alltför generösa behörigheter för filer som är tillgängliga inom detta konto.

För att säkerhetsstrategin ska vara robust måste därför de olika lagren passa ihop: konton och tjänster måste integreras korrekt, filbehörigheter måste kontrolleras, resursbegränsningar måste väljas på rätt sätt och applikationer måste hållas uppdaterade. Vilken skyddseffekt detta ger beror på den faktiska konfigurationen och de tjänster som drivs. Namnet på en enskild komponent ersätter inte denna kontroll.

Betrakta konton och webbplatser separat

Två kundkonton på samma server är något annat än två webbplatser inom ett och samma konto. CageFS tillhandahåller en användarspecifik miljö och begränsar därmed ett kontos åtkomst till filsystemet. Detta innebär dock inte att varje webbplats inom detta konto får en egen filsystemgräns.

Om en byrå driver flera projekt under samma webbhotellskonto kan deras applikationer, beroende på körningskontext och behörigheter, få åtkomst till filer från andra projekt. Om en angripare tar sig in på en webbplats via ett sårbart plugin måste man därför kontrollera vilka konfigurationsfiler och inloggningsuppgifter som är tillgängliga under detta konto. Att det finns en åtskillnad mot ett andra kundkonto ger inte svar på denna fråga.

För en finare Uppdelning av webbplatsen CloudLinux dokumenterar med CloudLinux Isolates en ytterligare domänbaserad isolering av filsystemet. Huruvida den kan användas beror på den konkreta produkttillgängligheten, versionen och panelintegrationen. Kontrollera dessa förutsättningar för din egen hosting-stack, istället för att enbart utgå från CageFS-aktiveringen för att dra slutsatsen att domänerna är åtskilda.

Även domänspecifika LVE-gränser är en separat funktion med egna krav. En ytterligare gräns för filsystemet innebär därför inte automatiskt att CPU eller minne begränsas separat för varje domän. Artikeln om CloudLinux-webbplatsisolering förtydligar skillnaden mellan kontonivå och webbplatsnivå; kraven för den använda produktvarianten är fortfarande avgörande för konfigurationen.

Inför planeringen är det värt att först göra en inventering: Vilka webbplatser delar ett konto, vilka filer måste de dela och vilka inloggningsuppgifter ska hållas åtskilda? Utifrån detta kan man avgöra om separata konton eller en tillgänglig domänbaserad isolering passar driftsmodellen. Båda alternativen kräver en granskning av de faktiska användningsvägarna.

Kontrollera Pilot- och CageFS-status

Innan du startar ett pilotprojekt ska du som operatör kontrollera att den använda operativsystemvarianten stöds, att de nödvändiga paketen och licensen finns tillgängliga och att kontrollpanelen är korrekt integrerad. Att en kontrollpanel dokumenteras som stödd innebär inte att alla funktioner fungerar på samma sätt i varje kombination. Notera även vilka applikationer och verktyg de valda testkontona kräver.

Börja med uttryckligen godkända testkonton och ett överskådligt urval av typiska applikationer. Kontrollera deras hemkataloger, nödvändiga program och relevanta körvägar innan du lägger till fler konton. För införandet kan du använda läget där CageFS i princip är inaktiverat och enskilda konton aktiveras; alternativt finns det ett läge där CageFS är aktiverat som standard med undantag.

Följande läsbefallningar är avsedda för behöriga administratörer på ett system där CageFS är installerat. TESTBENUTZER ersätt med ett befintligt konto som har godkänts för testet. Vilka behörigheter som krävs och det konkreta resultatet beror på systemet; kommandona ändrar inte någon konfiguration.

/usr/sbin/cagefsctl --cagefs-status
/usr/sbin/cagefsctl --display-user-mode
/usr/sbin/cagefsctl --user-status TESTBENUTZER

Det första kommandot visar den globala CageFS-statusen, det andra visar Driftsläge. Den tredje frågar efter statusen för det valda kontot. Läge och kontostatus ska betraktas tillsammans: Ett läge som i princip är aktiverat kan ha undantag, medan enskilda konton uttryckligen inkluderas i det andra läget.

Ett positivt statusresultat är inte i sig ett bevis på att varje tjänst faktiskt körs i det avsedda sammanhanget. Dokumentera därför separat vad administrationssystemet rapporterar och vilka körvägar som har kontrollerats med testkontot. Först därefter kan man avgöra om pilotprojektet kan utvidgas till ytterligare konton och vilka undantag som är nödvändiga ur driftssynpunkt.

Jämförelse av skyddsstrategier

Strategierna skiljer sig främst åt när det gäller vilka gränser de sätter och vem som förvaltar dem. Tabellen klassificerar deras skyddsmål; uppgifterna om driftskostnaderna är kvalitativa planeringsriktlinjer, inte uppmätta värden. Konkreta krav beror på respektive plattform och dess konfiguration.

Filbehörigheter och begränsad åtkomst är inte utbytbara begrepp: även en synlig sökväg behöver inte vara läsbar, och en tillgängliggjord sökväg måste skyddas på lämpligt sätt. CageFS kompletterar dessa behörigheter med en specialutformad miljö. LVE å sin sida hanterar resursförbrukningen; för att de ska kunna användas tillsammans måste båda lagren konfigureras på rätt sätt.

En egen virtuell maskin förskjuter administrationsgränsen jämfört med en användarspecifik miljö: Gästsystemet måste underhållas av användaren själv och förblir beroende av virtualiseringsplattformen. En separat server förändrar den delade infrastrukturen ytterligare. Vilken variant som är lämplig beror på hotbilden, de behövs behörigheterna och de tillgängliga driftsresurserna.

En generell säkerhetsrankning skulle därför vara missvisande. För att jämföra andra mekanismer och deras respektive användningsområden är översikten över Processisolering inom webbhotell. Det avgörande är sedan den konkreta granskningen: Vilken gräns ska förhindra vilken åtkomst, vilka tjänster överskrider den och vem övervakar konfigurationen?

Kontrollerad testning av exekveringsvägar

Att ett konto är aktiverat innebär inte nödvändigtvis att alla tillhörande processer faktiskt startas i CageFS. Det avgörande är den respektive Exekveringsväg: SSH-inloggning, webbserver och schemalagda uppgifter kan använda olika integrationer. Administratörer måste därför för varje relevant tjänst kontrollera hur den kopplar processer till kontot och dess miljö.

För en kontrollerad testning skapar operatören ett auktoriserat testkonto och använder uteslutande egna, uttryckligen godkända testfiler. En fil inom den avsedda miljön kan visa om den förväntade åtkomsten fungerar; en separat förberedd fil utanför den avsedda vyn används för att kontrollera avgränsningen. Externa kundkataloger är inte lämpligt testmaterial för detta ändamål.

Kontrollera först via SSH vilken miljö testkontot faktiskt tilldelas och om de avsedda testfilerna är tillgängliga som förväntat. Upprepa kontrollen med en webbapplikation som har konfigurerats för detta ändamål och en schemalagd uppgift. Resultaten kan variera om tjänsterna är integrerade på ett annat sätt eller körs under ett annat användarkonto.

Dokumentera tjänst, konto, sökväg och resultat för varje försök. En nekad åtkomst bekräftar endast den observerade gränsen i just detta sammanhang; den bevisar varken att alla tjänster är korrekt isolerade eller att hela värddatorn är säker. Omvänt bör en oväntat lyckad åtkomst undersökas innan ytterligare konton tas i drift.

Som webbhotellskund kan du kontrollera din egen körningskontext och delade filer. Globala CageFS-inställningar, andra konton och integrationen av alla tjänster kan du normalt sett inte verifiera på egen hand. Dessa frågor faller under operatörens ansvar; om du upptäcker något onormalt ska du beskriva den berörda tjänsten och den exakta sökvägen för operatören.

Saknade verktyg och underhåll av Skeleton

Om ett verktyg är installerat på värddatorn men inte går att hitta i kundkontot, kontrollera först körningskontexten. Ett anrop via SSH behöver inte använda samma miljö som en webbapplikation eller ett schemalagt uppdrag. Kontrollera därefter sökvägen och det specifika felmeddelandet innan du antar att ett paket saknas.

Därefter undersöker operatören Skelett och monteringskonfigurationen. Skeletonet avgör vilka filer och kataloger som ska göras tillgängliga i CageFS. Ett program kan därför finnas på värddatorn men ändå saknas i den användarspecifika miljön; även nödvändiga bibliotek och andra beroenden måste beaktas vid tillgängliggörandet.

Den praktiska lösningen är inte att i förebyggande syfte inkludera stora värdkataloger. Det skulle kunna leda till att fler filer blir synliga än vad som är nödvändigt för uppgiften. Administratören bör istället, med hjälp av tillverkarens dokumentation, välja ut de programfiler och beroenden som behövs och därefter kontrollera i den avsedda tjänstkontexten om verktyget fungerar.

Till Underhåll av Skeleton Det är också viktigt att ta hänsyn till ändringar i systempaket och i kontrollpanelen. CloudLinux dokumenterar en periodisk uppdatering; efter vissa ändringar kan en tvingad uppdatering vara nödvändig. Den kan även bli nödvändig efter en ombyggnad av Apache. Detta innebär dock inte att samma manuella kommando måste köras efter varje uppdatering.

Planera uppdateringen så att den passar den plattform som används och kontrollera därefter de berörda applikationerna och verktygen. Om en applikation tidigare fungerade men slutar fungera efter en ändring, kan tidpunkten för paketändringen, den berörda tjänsten och det exakta felmeddelandet hjälpa till att avgränsa problemet. På så sätt kan man skilja mellan ett distributionsproblem och ett fel i applikationen.

Säker drift och välgrundade beslut

När det gäller beslutet om driftsättning är det inte bara avgörande om CageFS i princip är tillgängligt. Operatören måste veta vilka konton och tjänster som ska skyddas, vilka program som krävs för detta och vem som ansvarar för integration och underhåll. Den begränsade åtkomsten till filsystemet kompletterar andra säkerhetsåtgärder; den ersätter varken säkra applikationer eller skyddet av inloggningsuppgifter.

Följande förtjänar särskild uppmärksamhet gemensamma utrymmen och ytterligare monteringsalternativ. CloudLinux beskriver för /dev/shm en gemensam integrering och en möjlighet till isolering per användare. Vilken variant som faktiskt gäller måste kontrolleras utifrån den konkreta konfigurationen. Ytterligare monteringar bör endast tillhandahålla det som applikationerna behöver, eftersom de kan utvidga den synliga miljön.

Även ett fel vid inloggning i CageFS är säkerhetsrelevant. Från och med CageFS 7.2.0-1 dokumenterar CloudLinux ett alternativ som gör det möjligt att förhindra att processer körs vid ett sådant fel. Kontrollera den installerade versionen och den faktiska inställningen, istället för att dra slutsatser om hur alternativet fungerar i ett specifikt webbhotellutbud enbart utifrån att det finns.

Ändringar av Skeleton, Mounts eller kontotilldelning ska göras i ett samordnat Underhållsrutiner. Ta hänsyn till eventuella ommonteringar, berörda applikationer och ett underhållsfönster; dokumentera dessutom hur ändringen kan återställas om problem uppstår. Därefter bör de relevanta körvägarna och nödvändiga verktygen kontrolleras på nytt med de avsedda testkontona.

För kunderna är den avgörande frågan vilken avgränsning leverantören faktiskt tillämpar och hur denne kontrollerar den. Operatörerna måste däremot väga skyddsbehovet mot den löpande arbetsinsatsen: En alltför generöst tillhandahållen miljö kan försvaga avgränsningen, medan en alltför begränsad miljö kan påverka nödvändiga applikationer negativt. Båda kräver en medveten konfiguration och regelbundna kontroller.