Izolace webů na sdíleném hostingu: Jak zabránit šíření útoku mezi zákazníky

Napadený plugin, odcizené heslo nebo chyba v aplikaci mohou útočníkovi otevřít cestu do webu. Na sdíleném hostingu ale záleží také na tom, kam se dostane dál. Správně nastavená izolace odděluje zákaznické účty, omezuje přístup k jejich datům a pomáhá udržet incident v hranicích napadeného prostředí. Co by měla zahrnovat a na co se ptát poskytovatele?

Jak se může útok přesunout na další web

Útok obvykle začíná u jednoho konkrétního webu. Vstupní cestou může být zranitelný plugin, neaktualizovaný redakční systém nebo odcizené přístupové údaje. Pokud útočník získá možnost spouštět na serveru vlastní kód, rozsah jeho možností závisí také na tom, pod jakým systémovým uživatelem aplikace běží a k čemu má tento uživatel přístup.

Představme si například dva e-shopy různých zákazníků na stejném serveru. Útočník zneužije chybu v rozšíření prvního e-shopu a nahraje do něj škodlivý skript. Ten může sloužit jako takzvaný webshell, tedy nástroj pro zadávání příkazů a práci se soubory prostřednictvím webového rozhraní. Útočník se následně může pokusit překročit hranice napadeného webu.

Při nedostatečném oddělení účtů může útok pokračovat několika způsoby:

• Čtením cizích konfigurací – konfigurační soubory aplikací často obsahují přihlašovací údaje k databázi nebo klíče k externím službám. Pokud je napadený proces smí přečíst, může útočník získat přístup k dalším datům.
• Úpravou souborů jiného webu – jestliže má proces také právo zápisu do cizích adresářů, může útočník změnit obsah stránky, vložit škodlivý kód nebo vytvořit další cestu pro pozdější přístup.
• Zneužitím společných přístupových údajů – pokud několik projektů používá stejného databázového uživatele s přístupem ke všem jejich databázím, získání jednoho hesla může ohrozit více webů.
• Přístupem k nezabezpečeným zálohám – záloha může obsahovat celý web i jeho databázi. Pokud je dostupná z napadeného účtu, může útočník získat citlivé informace, aniž by potřeboval přístup k běžícímu druhému webu.

K takovému přesunu přitom nemusí být nutná další zranitelnost v sousední aplikaci. Slabým místem mohou být samotná oprávnění na serveru. Pokud proces prvního webu smí otevřít konfiguraci druhého, útočník pouze využije přístup, který mu prostředí už umožňuje.

Podobné riziko vzniká také u více webů provozovaných pod jedním zákaznickým účtem. Starý testovací WordPress může představovat vstupní cestu k důležitému firemnímu webu, pokud oba projekty běží pod stejným uživatelem a mají vzájemně dostupné soubory. Rozdílné domény ani samostatné složky takové oddělení samy o sobě nezajišťují.

Sdílený hosting však automaticky neznamená, že napadení jednoho webu ohrozí všechny ostatní. Správně nastavená izolace má zajistit, aby útočník zůstal omezen na prostředí napadeného účtu nebo webu. Pokus o čtení cizí konfigurace či změnu cizích souborů potom skončí odmítnutím přístupu.

Samostatná doména ještě neznamená samostatné prostředí

Doména a virtuální host určují, který web server zobrazí. Samy o sobě ale neurčují, ke kterým souborům smí jeho aplikace přistupovat. Dvě různé adresy mohou obsluhovat procesy se stejnou systémovou identitou a podobnými oprávněními.

Při posuzování hostingu je proto potřeba rozlišovat:

•     Oddělení zákazníků – napadený účet nesmí číst ani měnit neveřejná data jiného zákazníka.
•     Oddělení webů jednoho zákazníka – více projektů pod společným účtem nemusí být navzájem izolovaných.
•     Oddělení výkonu – nadměrná spotřeba prostředků jednoho účtu má mít omezený dopad na ostatní.

Praktický důsledek je důležitý například pro agentury. Pokud pod jedním účtem provozují několik klientských webů, izolace tohoto účtu od ostatních zákazníků ještě neřeší vztahy mezi vlastními projekty.

Při výběru webhostingu CZECHIA.COM si proto ověřte, jak jsou oddělené zákaznické účty a zda se ochrana vztahuje také na jednotlivé weby uvnitř jednoho účtu. Pokud potřebujete vlastní serverové prostředí, můžete zvolit Cloud Server od ZonerCloudu. Také na něm je však nutné nastavit oddělení projektů, souborová oprávnění a databázové přístupy podle potřeb jednotlivých webů.

Základem jsou identity procesů a oprávnění souborů

Aplikace by měla běžet pod systémovým uživatelem s oprávněními odpovídajícími konkrétnímu účtu. U PHP lze využít například oddělené PHP-FPM pooly, tedy skupiny procesů obsluhujících příslušné weby. Dokumentace PHP umožňuje pro pool nastavit uživatele, skupinu i přístupová práva komunikačního socketu.

Samotný pool ale není zárukou izolace. Pokud dva pooly používají stejného uživatele nebo mají jejich uživatelé příliš široká oprávnění, přístup k cizím datům může zůstat otevřený. Z konfigurace PHP-FPM tedy vyplývá, že je nutné hodnotit také skutečnou identitu procesů a oprávnění, nikoli pouze počet poolů.

Správce by měl ověřit zejména:

•   zda jsou neveřejné konfigurace a zálohy dostupné jen oprávněným procesům;
•   zda aplikace může zapisovat pouze do potřebných umístění;
•   zda přístup nezpřístupňují společné skupiny nebo dodatečná pravidla ACL;
•   zda jsou chráněné také dočasné soubory a session data.

Univerzální nastavení oprávnění pro všechny hostingy neexistuje. Musí odpovídat způsobu, jakým server spouští aplikace a obsluhuje jejich soubory.

Omezený pohled na souborový systém

Další vrstva ochrany může aplikaci zpřístupnit pouze vybranou část serverového prostředí. Web pak pracuje se soubory, které potřebuje pro svůj provoz, zatímco neveřejná data ostatních projektů mu zůstávají nedostupná.

Pokud provozujete více webů například na Cloud Serveru od ZonerCloudu, je potřeba takové oddělení zahrnout do konfigurace serveru. Samotné pořízení VPS vzájemnou izolaci webů nezajišťuje. Záleží také na nastavení systémových uživatelů, přístupových práv a prostředí, ve kterém aplikace běží.

To je podstatné, protože web nemusí spouštět kód jen při návštěvě stránky. Stejná pravidla musí platit i pro plánované úlohy nebo příkazy spuštěné přes terminál. Nechráněná cesta by mohla zamýšlené oddělení oslabit.

U PHP se často zmiňuje direktiva open_basedir, která omezuje přístup PHP k určeným cestám. Je užitečnou doplňkovou vrstvou, ale její vlastní dokumentace upozorňuje, že nejde o úplné bezpečnostní řešení. Neměla by proto nahrazovat izolaci vynucovanou operačním systémem.

Oddělit je potřeba také databáze

Souborová izolace řeší jen část problému. Web obvykle používá také databázi, jejíž přihlašovací údaje má uložené v konfiguraci.

Každý nezávislý projekt by proto měl mít vlastní databázové přihlašovací údaje a oprávnění omezená na potřebnou databázi. MySQL umožňuje přidělovat práva na úrovni databází i jednotlivých objektů. Samotné vytvoření dvou databází nepomůže, pokud jeden společný uživatel smí pracovat s oběma.

Uživatel aplikace zároveň nepotřebuje spravovat celý databázový server. Konkrétní oprávnění však musí respektovat provoz aplikace, včetně instalace rozšíření a změn databázové struktury při aktualizacích. Cílem je nejmenší potřebný rozsah přístupu, který současně umožní řádnou údržbu.

Limity výkonu chrání dostupnost

Napadený web může poškodit okolí i bez přístupu k cizím souborům. Pokud spotřebovává příliš mnoho procesorového času, paměti nebo diskových operací, může zhoršit dostupnost ostatních projektů.

Technologie LVE v CloudLinuxu umožňuje omezovat prostředky jednotlivých účtů, například CPU, paměť, diskové I/O a počet procesů. Tyto limity pomáhají omezit dopady přetížení.

Omezení výkonu však není náhradou za oddělení dat. Účet může mít přísný limit spotřeby prostředků, a přesto nevhodně nastavená přístupová práva. Provozovatel tak musí řešit dvě odlišné otázky. Co aplikace smí dělat a kolik prostředků při tom smí spotřebovat.

Kontejner není automatická záruka bezpečnosti

Další možností jsou kontejnery, které využívají mechanismy operačního systému pro oddělení procesů a dalších částí prostředí. Web Dockerdocs ale upozorňuje také na rizika konfigurace, oprávnění a zranitelností jádra.

Důležité jsou například připojené adresáře, dostupnost správy kontejnerů a síťové propojení. Pokud aplikace dostane přístup ke společným citlivým datům, samotné spuštění v kontejneru tento přístup neodstraní.

Při výběru služby má proto větší hodnotu vysvětlení konkrétních hranic než obecné tvrzení, že hosting používá kontejnery.

Na co se zeptat poskytovatele

Zákazník obvykle nemůže zkontrolovat celou konfiguraci serveru. Může ale požadovat srozumitelný popis ochrany:

• Běží aplikace jednotlivých zákazníků pod odlišnými systémovými identitami?
• Jak je omezen přístup k souborům, konfiguracím a dočasným datům jiných účtů?
• Platí izolace také pro SSH a plánované úlohy?
• Jsou oddělené i jednotlivé weby v rámci mého účtu?
• Jaká databázová oprávnění dostává aplikace?
• Jaké limity prostředků platí a co se stane při jejich překročení?
• Jak poskytovatel postupuje při napadení webu a jak lze obnovit data?

Správce vlastní infrastruktury by měl deklarované hranice ověřovat na testovacích účtech s neškodnými testovacími soubory. Kontrola má zahrnovat PHP, terminál i plánované úlohy. Rozhodující je skutečně odmítnutý neoprávněný přístup.

Bezpečnost začíná oddělením a pokračuje správou

Ani dobře oddělené prostředí nezabrání každé chybě uvnitř samotného webu. Průběžné aktualizace, ochrana přístupových údajů a ověřené zálohy proto zůstávají součástí běžné správy. Při napadení je navíc potřeba odstranit původní příčinu, aby se útok po obnově neopakoval.

Při výběru infrastruktury můžete podle potřeb projektu sáhnout po webhostingu CZECHIA.COM nebo zvolit Cloud Server od ZonerCloudu, pokud potřebujete větší kontrolu nad serverovým prostředím. V obou případech si ověřte způsob izolace, rozdělení odpovědnosti za správu a možnosti obnovy dat.

Dobře nastavený hosting počítá s tím, že jeden web může být napaden. Odděluje proto přístupy k souborům a databázím a omezuje spotřebu prostředků. Chyba jednoho projektu pak nemusí přerůst v incident, který zasáhne další zákazníky.