Správa linuxového serveru: Bezpečnost a monitorování systému

Minulý díl se věnoval útokům na servery, jejich charakteru, cílům a motivům. Tento díl se bude věnovat metodám, postupům a nástrojům, které můžete použít k zabezpečení serveru a jeho monitorování.

Optimální zabezpečení serveru

Na úvod opět zdůrazním, že bezpečnostní opatření jsou kompromisem mezi vynaloženými prostředky a dosažením požadované úrovně zabezpečení. Jinými slovy, opatření je třeba volit s ohledem na to, co chcete chránit, před čím a jaké máte dostupné prostředky. Optimální zabezpečení serveru je tedy takové, které si zvolíte s ohledem na situaci.

Jedním z důležitých předpokladů pro bezpečnost serveru je rozumět systému jako takovému, dále službám, které na serveru provozujete, stejně jako všem bezpečnostním opatřením, které se rozhodnete nasadit. Nasazovat něco, o čem netušíte, jak to vlastně funguje, představuje potenciální riziko. Dostupnost nejrůznějších návodů pro konfiguraci té či oné služby je v tomto případě částečně kontraproduktivní, protože vás nevede k tomu, abyste nejprve nahlédli do oficiální dokumentace.

Ideální je, pokud máte možnost server nakonfigurovat od začátku, tj. pokud dostanete čistý server, na který je třeba systém teprve nainstalovat. V takovém případě doporučuji začít s minimální možnou instalací a instalovat pouze to, co potřebujete. Pokud se dostanete k fungujícímu serveru, proberte jako první krok všechny služby, a ty, které nepotřebujete, ze systému odstraňte.

Ochrana systému

Prvním předpokladem pro bezpečný systém je jeho pravidelná aktualizace. V případě Debianu můžete použít nástroje jako apticron či apt-listchanges, které vás informují o dostupných aktualizacích, jakmile se objeví, a vy pak můžete systém včas aktualizovat. Samozřejmě je možné zajistit i automatickou aktualizaci, ale bývá dobré aktualizace provádět spíše ručně (v některých případech mohou vyžadovat interakci, což automatický skript nezajistí). V souvislosti s tímto tématem připomínám článek Jak aktualizovat server(y).

Ochrana proti síťovým útokům

Síťové útoky směřující na server je možné detekovat pomocí nástrojů, které se schovávají pod zkratkou IDS (Intrusion Detection System). Tyto nástroje buď pasivně naslouchají na síti a hledají typické znaky útoků (např. snort), nebo si sami zaberou porty služeb, které nejsou v systému nainstalované, a monitorují přístupy na tyto porty (nástroj portsentry). Tyto nástroje nicméně umí provádět nejenom pasivní monitorování, ale také aktivní, tzn. umí reagovat na události (a třeba zablokovat IP adresu, která provádí port scan). V souvislosti s tím je třeba poukázat na možné otevření okna pro DoS útok, budete-li používat automatizovanou obranu - vždy zvažte, co se stane, pokud útočník bude na server útočit, ale s falešnou zdrojovou IP adresou. Upozorňuji, že nastavení těchto nástrojů může být poměrně komplikované i pro pokročilejšího správce, např. konfigurace vlastních pravidel pro snort.

Ochrana souborů

Pokud se útočník dostane do systému a třeba získá oprávnění uživatele root, bude se nejspíše snažit upravit klíčové nástroje (Shell, ls, ps, jádro apod.). V takovém případě se hodí nástroje pro ověřování integrity souborů, tedy nástroje jako Tripwire, stealth, aide apod., které umožňují vytvářet databázi zabezpečených kontrolních součtů vybraných souborů, a ty pak ověřovat. K zabezpečení se obvykle používá asymetrického šifrování. V případě použití těchto nástrojů je třeba dbát na správný postup a na možnosti útočníka (útočník může kompromitovat i samotný nástroj, popřípadě jeho databázi).

Ochrana vůči rootkitům

Rootkit je typický nástroj útočníka, který získá oprávnění uživatele root - je to sada nástrojů sloužící jednak k zajištění pohodlného vzdáleného přístupu ke kompromitovanému systému, ale také k ukrytí své přítomnosti. Některé typické znaky rootkitů mohou odhalit nástroje jako chkrootkit nebo rkhunter. Opět zde však platí to, co bylo řečeno výše - v případě kompromitovaného systému je třeba počítat i s tím, že útočník kompromituje i samotný nástroj pro jeho odhalení.

Zálohování

Nepředpokládám, že vám musím připomínat, že je třeba provádět pravidelné zálohy. Zmíním snad jen problematiku zálohování systému jako takového. Data obvykle zálohuje skoro každý správce, tam problém nebývá. Systém jako takový už ovšem není zálohován tak často, přitom konfigurace systému i služeb bývá poměrně náročná a při případné ztrátě dat bez dostupnosti záloh systému je třeba ji provést celou znovu od začátku. Proto nebývá od věci zálohovat i systém jako takový. Samozřejmě není třeba zálohovat systém celý včetně všech souborů, zálohovat stačí pouze to podstatné, tzn. adresář /etc s konfigurací systému, dále pak seznam nainstalovaných balíčků a nakonec všechna data. Co se dat týče, nezapomeňte zálohovat opravdu všechna data, např. pokud používáte awstats, pak určitě zálohujte i samotné soubory se statistikami, které se nacházejí ve /var/lib/awstats (některá podobná umístění a data je snadné přehlédnout).

Pokud budete zálohovat Debian nebo na něm založenou distribuci, budete asi chtít zálohovat spíše seznam explicitně nainstalovaných balíčků než seznam všech nainstalovaných balíčků. Pokud používáte nástroj Aptitude, pak víte, že tento nástroj si zapamatuje, co bylo nainstalováno jen jako závislost, a pokud pak odinstalujete původní balíček, Aptitude vám nabídne k odstranění i ty balíčky, které byly nainstalovány jako závislosti. To je velice užitečná funkce z hlediska údržby systému (zejména, pokud na serveru občas experimentujete). Pokud byste zálohovali seznam všech balíčků, zahrnuli byste do toho i ony závislosti a po obnově systému (nebo při jeho migraci jinam) by váš Aptitude tuto svou funkci ztratil. Naštěstí není problém nechat si vypsat explicitně nainstalované balíčky:

aptitude -F %p search "?and(?installed,?not(?automatic))" > pkglist.txt

A posléze je nainstalovat do nového systému:

xargs aptitude --schedule-only install < pkglist.txt
aptitude install

Monitorování systému a služeb

Každý server je třeba monitorovat, tzn. pročítat logy, sledovat různé údaje a jejich změny v čase, abyste včas odhalili případné problémy. Zásadní je sledování logů. To můžete dělat ručně, ale bývá dobré si je nechat zasílat zpracované mailem. Za tímto účelem existují nástroje jako logwatch či logcheck, řízené cronem, které vám jednou za určitou dobu zašlou e-mail se všemi podstatnými událostmi, popřípadě zkonstruují výtah, který se čte o poznání lépe (to zajišťuje třeba logwatch). Tyto nástroje je možné poměrně precizně řídit a filtrovat irelevantní informace, nebo naopak rozšiřovat množství sdělovaných informací.

Sledovat základní údaje jako obsazení paměti, zátěž systému, průchodnost fronty poštovního serveru apod., vám umožní třeba munin ve spolupráci s munin-node. Výstupem je HTML stránka s grafy, které se generují z naměřených hodnot. Z nich můžete vyčíst zdroj nějakých potíží, popřípadě naplánovat, co je třeba na serveru upravit (více operační paměti atd.). Bývá dobré nenechávat výstup nástroje munindostupný z webu alespoň bez nějakého ověření, neboť může obsahovat informace, které mohou být teoreticky využity útočníkem (i když zrovna neobsahuje vyloženě citlivé údaje).

K monitorování teplot můžete použít nástroj lm-sensors, k monitorování teplot pevného disku pak hddtemp. K monitorování zdraví pevných disků můžete použít balíček smartmontools, kterému jsem se již v tomto seriálu věnoval, a to dokonce ve třech dílech. K monitorování softwarového RAIDu můžete použít přímomdadm démona.

Nebývá na škodu ani monitorovat jednotlivé služby, zdali odpovídají, jsou přístupné a dá se s nimi navázat spojení. Toto umožňuje třeba monit či xymon (dříve Hobbit). Nástroj monit umí i reagovat na nedostupnost služeb, zatížení systému nebo obsazení paměti ze strany určité služby, a to upozorněním, restartem či zastavením služby. O všech událostech pak samozřejmě informuje mailem. Takto je možné sledovat nejenom služby samotné, ale i vzdálené servery.

Tím bych tento díl ukončil. Příště se budu věnovat zabezpečení služeb jako takových a zabezpečení sítě, ve které se váš server nachází.