Správa linuxového serveru: Bezpečnost linuxového serveru
Jakým způsobem zabezpečit linuxový server? Jaké jsou cesty, kterými se útočník může probourat na server? Jakou strategii zvolit při zabezpečení linuxového serveru? Na tyto otázky vám pomůže odpovědět tento a následující díl seriálu.
Navážu na předchozí díl, který se zabýval čistě teorií bezpečnosti, a rozvedu tyto koncepty trošku více do praxe. Nejprve by bylo dobré rozdělit bezpečnost na jednotlivé oblasti, které je třeba zajistit. V případě linuxového serveru přichází v úvahu server jako takový, systém a služby, dostupnost a bezpečnost dat.
Bezpečností serveru je myšlena fyzická bezpečnost, tedy místo, kde je server uložen, kdo má k němu přístup, jak je úložiště serveru zabezpečeno proti vniknutí nežádoucích osob atd. Jelikož v dnešní době začínají být velmi populární virtuální servery, je třeba brát ohled i na tyto typy serverů a jejich úskalí. K serveru má přístup obvykle poskytovatel dané služby, přičemž není vždy jasné, jaké poměry v rámci správy daného serveru panují - kde jsou vaše data, jsou-li zálohována, co se děje se záložními médii, jakým způsobem jsou na nich likvidována data před jejich vyřazením, pokud vůbec, atd.
Kromě toho, fyzický server provozující virtualizaci (hypervizor) používá více uživatelů. Ačkoliv virtualizační technologie poskytují mechanismy k velmi dobré izolaci jednotlivých virtuálních strojů, bezpečnostní díry se najdou všude a nelze vyloučit možnost, že se útočníkovi podaří z napadeného virtuálního stroje probourat do systému hypervizoru, pod kterým vše běží.
K této oblasti nemám příliš mnoho komentářů, spíše jen řadu otázek, na které si musíte sami najít odpověď. Ostatně, bezpečnost je vždy kompromisem mezi časem a prostředky, které do jejího zajištění vložíte, a mezi úrovní bezpečnosti, kterou prostřednictvím této investice dosáhnete. Jinými slovy: v případě osobního serveru, na kterém běží vaše osobní webové stránky, popřípadě nějaký SCM hosting se zdrojovými kódy vašich FOSS projektů, je asi zbytečné investovat do vlastního serveru ve vlastním datacentru a s vlastní ostrahou. A naopak: pokud realizujete prostřednictvím svých serverů své podnikání, a server obsahuje třeba osobní údaje vašich klientů, pak by vám rozhodně nemělo být jedno, v jakém prostředí a v jakých poměrech se server nachází.
Bezpečnost systému a služeb je bezpečnost týkající se náhodných či cílených útoků, ale i omylů uživatele či správce. Kupříkladu, pokud má uživatel přístup k Shellu a zadá obávané rm -rf /* (pro jistotu dodávám, že tento příkaz maže celý adresářový strom, a proto byste jej rozhodně neměli spouštět, a už vůbec ne s právy roota!), neměl by ohrozit ani systém, ale ani data jiného uživatele. Toto téma je poměrně rozsáhlé, a proto mu bude vyčleněn celý příští díl seriálu.
Jak už jsem nakousl v minulém díle, bezpečnost by neměla končit pouze u bezpečnosti serveru, systému, služeb a dat, ale měla by zohlednit i dostupnost. Pokud bude server delší dobu mimo provoz, pak sice bude v bezpečí proti vzdáleným útočníkům, ale jeho nedostupnost bude přesto působit problém, dokonce možná stejně závažný problém, jako kdyby byl napaden.
Velká část dostupnosti je spojena se samotným hardwarem. Asi tím nejlevnějším řešením je kromě záložního zdroje (UPS), který bude server schopen napájet, i když dojde k výpadku napájení, také nějaká forma RAIDu s redundancí, která zajistí, že výpadek disku nenaruší dostupnost, a dá vám možnost potenciální krizi zažehnat v zárodku. Připomínám, že této tématice se věnovaly tři z mých článků, a siceRAID teoreticky a Softwarový RAID prakticky (první díl, druhý díl). Ostatní možnosti zvýšení dostupnosti zahrnují kvalitnější (a o dost dražší) hardware s redundancí třeba na úrovni zdrojů napájení, připojení k síti, I/O modulů či modulů pro vzdálenou správu serveru (management modulů).
Dalším stupněm mohou být řešení s vysokou dostupností (high availibility), zahrnující obvykle více než jeden server a redundanci na úrovni služeb (vypadne jeden server, požadavky se budou předávat druhému) atd. V této oblasti je mnoho možností, které jsou ovšem vyváženy vysokou cenou, a kromě toho jsou také mimo zaměření tohoto seriálu.
U fyzických serverů nezapomeňte na propojení serveru se záložním zdrojem, aby se váš systém v případě kritického stavu baterie sám bezpečně vypnul.
Bezpečnost zahrnuje jak bezpečnost dat vůči zcizení či zneužití nějakým útočníkem, tak bezpečnost dat vůči jejich ztrátě. Se zajištěním bezpečnosti dat vůči zcizení souvisí bezpečnost služeb a systému (útočník, který pronikne do systému, se dostane i k datům, které může zneužít). Stejně tak souvisí s bezpečností serveru (útočník by neměl mít možnost získat fyzický přístup k serveru a třeba si odnést pevný disk). Pokud používáte virtuální server a nemáte pod kontrolou hypervizor, musíte počítat i s únikem dat touto cestou (poskytovatel si může vaše data odnést, nebo hodí pevný disk se starými zálohami do popelnice, kde bude někým objeven atd.).
S bezpečností dat vůči zcizení/zneužití vám může pomoci diskové šifrování. V souvislosti s tím připomínám, že tématice šifrování v GNU/Linuxu jsem se věnoval v třídílném miniseriálu Šifrování s dm-crypt/LUKS (první díl, druhý díl a třetí díl). Připomínám také, že šifrování je vám samozřejmě k ničemu, pokud máte k dispozici virtuální server, jehož hypervizor má útočník pod kontrolou. V takovém případě má přímý přístup k paměti vašeho virtuálního stroje, může si z ní vytáhnout šifrovací klíče a data dešifrovat. Pokud máte k dispozici fyzický server, a útočník k němu získá přístup, když server běží, je vám šifrování opět k ničemu (tzv. cold boot attack, klíč lze získat díky tomu, že data se po výpadku napájení z operační paměti neztratí hned, ale až za nějakou dobu - při podchlazení modulů i za delší dobu). Pro bezpečnost dat je tedy klíčové mít zajištěnu fyzickou bezpečnost serveru, ale také bezpečnost systému a běžících služeb (pokud se útočník probourá třeba přes děravou službu a dostane se k Shellu, získá přístup k datům "zevnitř" systému, kterému jsou data samozřejmě přístupná v nešifrované podobě).
Pokud data nešifrujete, musíte si dávat pozor na uniklé pevné disky, ať již funkční či porouchané - vyhazovat disky do popelnice bez jejich důkladného výmazu není dobrý nápad, dávat je do bazaru je ještě horší, ale stejně tak není úplně ideální vrátit disk výrobci a uplatnit reklamaci (nevíte, kdo dostane disk do ruky, a jak vážná závada to je, tj. v jakém stavu jsou data na porouchaném disku). Výrobci serverů obvykle umožňují za určitý poplatek, aby si majitelé serverů porouchané disky ponechali, takže se nemusí vrátit výrobci na výměnu za nové. Zvažte také, že ačkoliv není možné obnovit všechna data z jednoho disku v diskovém poli (není-li to RAID 1), stále je možné dostat se ke kouskům dat (u RAIDů s prokládáním jako RAID 0, 5 a 6 se data zapisují po blocích, které mají určitou velikost). Dodám, že k důkladnému výmazu dat z pevného disku vám poslouží nástroj shred. Výmaz ovšem nelze provést, pokud se disk porouchá - v takovém případě sice může dojít k částečné likvidaci dat, ale také může odejít pouze kus elektroniky, zatímco data na plotnách zůstanou (i to je třeba důvodem, proč je rozumné citlivá data šifrovat).
Mít data v bezpečí před zcizením či zneužitím je samozřejmě důležité, ale neméně důležité je mít data v bezpečí před jejich ztrátou. Z tohoto důvodu je nutné data zálohovat. K tomuto účelu existuje v GNU/Linuxu nepřeberné množství nástrojů, od těch nejobyčejnějších nástrojů jako rsync, ssh, tar, dd apod., až po speciální zálohovací nástroje jako například rdiff-backup, duplicity atd.
Co, jak často, jakým způsobem a kam zálohovat, to si musíte určit sami (kromě dat se může hodit zálohovat i systém jako takový - ne celý, pouze jeho klíčová data, tj. adresář /etc s konfigurací, dále pak seznam nainstalovaných balíčků atd.). Co se týká cíle zálohování, bývá dobré zálohovat co nejdále od serveru (nejlépe na jiný server). Zálohovat můžete ale i současně na více úložišť, třeba na externí disk či diskové pole, a také na jiný server. Zálohy mají obvykle dvě podoby - plná a inkrementální (rozdílová). Plná záloha vytvoří kompletní obraz zálohovaných dat (komprimovaný či nekomprimovaný), zatímco u rozdílové se zaznamenají pouze rozdíly mezi současným stavem dat a poslední plnou či rozdílovou zálohou. Plné zálohy bývá dobré provádět tak jednou měsíčně, nebo jednou za delší období, rozdílové zálohy pak denně.
U zálohování je klíčové pravidelně ověřovat stav a funkčnost záloh (nejlépe tak, že se pokusíte něco obnovit)! Není nic horšího, než když vám server selže, vy přijdete o data na něm, a když se podíváte na zálohy, zjistíte, že data z nich nejde obnovit, neboť vám mezi tím došlo místo a vy máte k dispozici data třeba půl roku stará (nebo vůbec žádná, protože zálohovací médium selhalo). I to je jeden z důvodů, proč je dobré zálohovat na více míst než jen na jedno.
Při zálohování musíte dbát také na konzistenci dat. Pokud nějaký proces či uživatel s daty manipuluje, a vy zrovna budete provádět zálohu, získáte nekonzistentní data, která po obnově budou v podobném (nebo ještě horším) stavu, jako kdyby uprostřed práce vypnuli proud (a váš server nebyl na UPS). To se týká zejména databází, u kterých je třeba zálohovat data prostřednictvím databázového systému, rozhodně ne tak, že necháte databázi běžet a zazálohujete její datové soubory, když do nich databázový systém zrovna zapisuje. Možnosti jsou dvě - můžete zálohovat prostřednictvím zálohované služby, umožňuje-li získat konzistentní data, tzn. u databází můžete zálohovat pomocí databázového systému (mysqldump, pg_dump čipg_dumpall atd.). U služeb, které neumožňují konzistentní zálohování za běhu, vám nezbude než službu pozastavit, zazálohovat a znovu spustit (nebo službu provozovat v clusteru s replikací a zálohovat sekundární uzel po jeho odstavení atd.). Určitě si u jednotlivých služeb projděte dokumentaci, zejména pak u zálohování databází. Něco málo k tomuto tématu máte k dispozici v odkazech pod článkem.