Řešení 1:
Jak zmínil @Some Guy, musíte o tom přemýšlet z historické perspektivy.
Historická perspektiva byla taková, že jeden kus hardwaru byl asi tucet různých služeb pod jedním operačním systémem. Pokud byla ohrožena jedna služba, bylo ohroženo vše na tomto hardwaru.
S virtualizací je to mnohem menší problém. I když není nemožné uniknout z VM, zdaleka to není triviální. Je jistě obtížnější vymanit se z VM než pro proces běžící s právy roota, aby se vymanil z chrootu. Moje vazebné servery tedy běží na vlastním virtuálním počítači. V takovém případě pro chroot opravdu nemá smysl, protože poškození je omezeno už jen tím, že se jedná o VM.
Chroot je velmi slabý pokus o vytvoření něčeho jako VM. Chrootům lze uniknout jakýmkoliv procesem s právy root. Chroot není určen a nefunguje jako bezpečnostní mechanismus. Chroot s vězením BSD nebo LXC vám poskytuje virtualizaci na úrovni operačního systému a poskytuje funkce zabezpečení. Ale v dnešní době, kdy je tak snadné roztočit nový VM celého stroje, nemusí stát za námahu nastavovat nebo se učit, jak k tomuto účelu používat virtualizační nástroje na úrovni OS.
Dřívější verze bind neztratily oprávnění. Na Unixu může pouze root účet otevřít porty pod 1024 a Bind, jak všichni víme, potřebuje poslouchat na udp/53 a tcp/53. Vzhledem k tomu, že Bind začíná jako root a nezruší oprávnění, jakýkoli kompromis by znamenal, že by mohl být kompromitován celý systém. Téměř jakýkoli software v dnešní době začne otevírat své zásuvky a dělat jakékoli další věci, které vyžadují oprávnění root, a poté změní uživatele, kterého provozuje, na neprivilegovaný účet. Jakmile jsou oprávnění zrušena, dopad kompromitace je na hostitelský systém mnohem nižší.
Řešení 2:
Ostatní odpovědi jsou docela dobré, ale nezmiňují koncept zabezpečení ve vrstvách. Každá vrstva zabezpečení, kterou přidáte do svého systému, je další vrstvou, kterou musí protivník překonat. Umístění BIND do chrootu přidá další překážku.
Řekněme, že v BIND existuje zneužitelná zranitelnost a někdo je schopen spustit libovolný kód. Pokud jsou v chrootu, musí se z toho vymanit, než se dostanou k čemukoli jinému v systému. Jak již bylo zmíněno, pro přerušení chrootu jsou vyžadována oprávnění root. BIND neběží jako root a v chrootu má být k dispozici minimum nástrojů, což dále omezuje možnosti a v podstatě ponechává pouze systémová volání. Pokud nedojde k žádnému systémovému volání k eskalaci oprávnění, pak se protivník zasekne při pohledu na vaše záznamy DNS.
Výše uvedená situace je poněkud nepravděpodobná, jak zmiňuje SomeGuy, BIND má v dnešní době poměrně málo zranitelností a většinou se omezují na scénáře typu DoS spíše než na vzdálené spouštění. To znamená, že běh v chrootu je výchozí konfigurací na několika operačních systémech, takže je nepravděpodobné, že byste z vaší strany vynaložili nějaké úsilí k udržení stále mírně zvýšeného zabezpečení.
Řešení 3:
preambule
Stále slyším lidi opakovat mylné představy z celého internetu. Proto se pokusím poskytnout nějaké vysvětlení
nejprve; kolik náhodných objevů bylo, které prostě... kvůli příčině a následku , byl nakonec použit pro něco jiného než zamýšlený účel?
co bylo a co je Chroot vězení
Chroot byl původně navržen pro změnu kořenového adresáře pro proces nebo uživatele (skvělé pro kompilaci softwaru z neznámých zdrojů). to poskytlo zabezpečení k základnímu systému, stejně jako zařízení pro rychlé testovací lůžko, včetně snadného čištění. od té doby uběhly roky a jeho koncept a předpokládané použití se jistě také změnily.
chroot byl použit efektivně , a je přímo v kódové základně pro několik programy a knihovny (tj. openSSHd, apache2 + mod_security2/mod_chroot, dovecot, sendmail, openVPN, pam_chroot, a mnoho dalšího ). předpoklad, že všechny tyto běžné aplikace implementovaly chybná bezpečnostní řešení, prostě není pravda
chroot je řešení virtualizace souborového systému:nic míň, nic víc. Předpoklad, že se můžete snadno vymanit z chrootu, také není pravdivý... pokud dodržujete pokyny pro spouštění procesů v chrootovém vězení.
několik kroků k zabezpečení vašeho chroot jail
tj. NE spouštět procesy jako ROOT. to by mohlo otevřít kořenový eskalační vektor (což platí také uvnitř nebo vně chrootu). nespouštějte proces uvnitř chroot pomocí stejného uživatele jako jiný proces mimo chroot. oddělte každý proces a uživatele do jeho vlastního Chrootu, abyste omezili útočné plochy a zajistili soukromí. připojte pouze nezbytné soubory, knihovny a zařízení. a konečně, chroot NENÍ náhradou za zabezpečení základního systému. zabezpečit celý systém.
další důležitá poznámka: spousta lidí si myslí, že OpenVZ je Broken, nebo že se to nerovná plné virtualizaci systému. dělají tento předpoklad, protože se v podstatě jedná o Chroot s procesní tabulkou, která byla sterilizována. s bezpečnostními opatřeními na hardwaru a zařízeních. nejvíce které můžete implementovat do chrootu.
ne každý administrátor má úroveň znalostí potřebnou k zabezpečení všech nezbytných parametrů jádra na dedikovaném serveru nebo v plné virtualizaci systému. to znamená, že nasazení OpenVZ znamená, že vaši zákazníci budou mít mnohem menší prostor pro útoky, aby se pokusili pokrýt a zabezpečit před nasazením svých aplikací. dobrý hostitel odvede dobrou práci, když zajistí tyto parametry, a to je zase lepší nejen pro všechny v Node nebo v datovém centru, ale pro internet jako celek...
jak bylo uvedeno, chroot poskytuje virtualizaci souborového systému. musíte zajistit, že neexistují žádné spustitelné soubory setuid, nezabezpečené aplikace, knihovny, visící symbolické odkazy bez vlastníka atd. pokud by útočník MOHLA kompromitovat vazbu, musel by prohledat virtuální souborový systém, zda by něco přeteklo vyrovnávací paměti, hrát si s deskriptory souborů nebo nějakým jiným způsobem kompromitovat něco, co se nachází uvnitř chroo- unikání z vězení, obvykle prostřednictvím eskalace privilegií nebo vložení jeho nebo její zátěže do základního systému.
Pokud k tomu dojde, je to obvykle výsledek špatné aktualizace, zneužití zero day nebo idiomatické lidské chyby .
proč se stále používá chroot, na rozdíl od úplné virtualizace systému
zvažte tento scénář:používáte virtuální privátní server s hostitelským uzlem běžícím OpenVZ. prostě nemůžete spustit cokoliv, co funguje na úrovni jádra. to také znamená, že nemůžete použít virtualizaci operačního systému k oddělení procesů a poskytnout dodatečné zabezpečení. tedy MUSÍTE pro tento účel použijte chroot.
navíc je chroot udržitelný na jakémkoli systému, bez ohledu na dostupné zdroje. jednoduše řečeno, má nejmenší režii ze všech typů virtualizace. to znamená, že je stále důležité na mnoha low end boxech.
zvažte jiný scénář:máte Apache spuštěný ve virtualizovaném prostředí. chcete oddělit každého uživatele. poskytnutí virtualizovaného souborového systému prostřednictvím doplňku chroot na apache (mod_chroot, mod_security atd.) by bylo nejlepší možností, jak zajistit maximální soukromí mezi koncovými uživateli. to také pomáhá předcházet shromažďování informací a nabízí další vrstvu zabezpečení.
jednoduše řečeno, je důležité implementovat zabezpečení dovrstvy . Chroot může být jedním z nich. ne každý a každý systém má ten luxus mít přístup k jádru, proto chroot STÁLE slouží účelu. existuje celá řada aplikací, ve kterých je úplná virtuaizace systému v podstatě přehnaná.
Odpověď na vaši otázku
CentOS nijak zvlášť nepoužívám, ale vím, že Bind nyní před operacemi upouští od svých oprávnění. Předpokládal bych však, že bind je chrootovaný kvůli jeho historii útočných vektorů a potenciálním zranitelnostem.
také... dává větší smysl automaticky chrootovat tuto aplikaci, než ne, protože ne KAŽDÝ má přístup k úplné virtualizaci na úrovni systému/operačního systému. to zase a teoreticky pomáhá zajistit zabezpečení uživatelské základny CentOS:
poskytovatelé operačního systému prostě nechodí kolem, za předpokladu, že všichni používají stejný systém. tímto způsobem mohou pomoci poskytnout další vrstvu zabezpečení jako celku...
existuje důvod, proč to tolik aplikací používá a proč to váš operační systém ve výchozím nastavení samozřejmě dělá:protože se používá jako bezpečnostní prvek a FUNGUJE. s pečlivou přípravou, jak již bylo uvedeno, je to další překážka, kterou musí potenciální útočník překonat – většinou omezuje poškození pouze na chroot vězení.
Řešení 4:
To je částečně způsobeno historickými důvody, kdy starší verze Bind měly závažné a časté bezpečnostní chyby. Ve skutečnosti jsem toto téma nesledoval, ale vsadil bych se, že se to od těch špatných časů výrazně zlepšilo.
Druhý důvod, ten praktičtější, je jen ten, že je obvykle nasazen v roli s připojením k internetu, a jako takový je otevřený většímu počtu útoků, zkoumání a obecné neplechu.
Proto, jak je často základním pravidlem v bezpečnostních záležitostech:lepší bezpečí než lítost, zvláště proto, že úsilí o chrootování je relativně malé.