Správa linuxového serveru: Detekce rootkitů a zotavení

V minulém díle jsem probral základní otázky týkající se rootkitů, včetně obecných pravidel zabezpečení, jak minimalizovat riziko průniku útočníka do systému. Představil jsem také vzdálené logování a ukázal, jak jej nastavit. V tomto díle představím detektory rootkitů a obecné rady, jak postupovat po případném průniku.

Detektory rootkitů

Detektory rootkitů jsou nástroje určené k vyhledávání jednak známých rootkitů, ale také jejich typických příznaků – mohou tedy (ale také nemusí) detekovat i dosud neobjevený a nepopsaný typ rootkitu. Je ovšem také třeba mít na paměti, že v případě kompromitace systému nelze věřit vůbec ničemu, včetně nainstalovaných detektorů rootkitů. Není tedy vhodné předpokládat, že pokud detektor neohlásí průnik, znamená to s jistotou, že v systému opravdu žádný rootkit není.

Na stranu druhou, pokud detektor ohlásí nějaký problém, neznamená to nutně, že ke kompromitaci systému skutečně došlo. Samy detektory jsou bohužel velmi známé tím, že generují falešné poplachy. Kupříkladu, na jednom z mých serverů tvrdí chkrootkit toto:

Checking `bindshell'...  INFECTED (PORTS:  465)

Hádáte správně, na portu 465 mi běží Postfix (číslo portu odpovídá SSL variantě protokolu SMTP). Jelikož stejný port využívá i bindshellchkrootkit považuje tento otevřený port za známku infekce, a generuje v tomto případě falešný poplach.

Každý poplach, který detektory nahlásí, je vhodné prověřit, a teprve na základě vlastního úsudku (v kombinaci s použitím vyhledávače) rozhodnout, jedná-li se o planý poplach nebo o reálný průnik.

chkrootkit

Jedním z detektorů rootkitů je chkrootkit. Nainstalujte jej obvyklým způsobem z repozitáře své distribuce, v Debianu a jeho derivátech to zařídí příkaz:

aptitude install chkrootkit

K provedení kontroly postačí pustit samotný nástroj bez parametrů:

chkrootkit

Bude následovat výpis výsledků kontroly, velmi pravděpodobně i s nějakým poplachem. Výpis analyzujte a prověřte. Doporučuji si projít informace o falešných varováních v /usr/share/doc/chkrootkit/README.FALSE-POSITIVES. Až se s nástrojem a jeho výpisy seznámíte, můžete si u opakovaných spouštění ušetřit čas využitím tichého režimu, který hlásí pouze nalezené problémy:

chkrootkit -q

Spolu s tímto nástrojem je nainstalován i skript, který zajišťuje jeho spuštění cronem (/etc/cron.daily/chkrootkit). Ten ovšem ve výchozím nastavení není aktivní. Abyste jej aktivovali, musíte upravit jeho konfigurační soubor (/etc/chkrootkit.conf). Jelikož je opravdu maličký, dovolím si ho sem umístit celý i s výchozími volbami:

RUN_DAILY="false"
RUN_DAILY_OPTS="-q"
DIFF_MODE="false"

Aby se skript spouštěl a kontroloval přítomnost rootkitů každý den, je třeba proměnnou RUN_DAILY nastavit na hodnotu true. Jelikož je veliká šance, že narazíte na nějaký falešný poplach, doporučuji prozkoumat i volbu DIFF_MODE, která po korektním (dodatečném) nastavení zajistí, že výsledek již provedené kontroly bude vždy porovnán s aktuálním stavem a chkrootkit vás bude informovat pouze o změnách vůči uloženému stavu.

Chcete-li této možnosti využít, nastavte nejprve proměnnou DIFF_MODE na hodnotu true. Poté skript ručně spusťte:

/etc/cron.daily/chkrootkit

V mém případě obsahuje výstup následující:

ERROR: No file /var/log/chkrootkit/log.expected
This file should contain expected output from chkrootkit

Today's run produced the following output:
--- [ BEGIN: cat /var/log/chkrootkit/log.today  ] ---

/usr/lib/pymodules/python2.5/.path /usr/lib/pymodules/python2.6/.path /lib/init/rw/.ramfs

INFECTED (PORTS:  465)
--- [ END: cat /var/log/chkrootkit/log.today ] ---

To create this file containing all output from today's run, do (as root)
# cp -a /var/log/chkrootkit/log.today /var/log/chkrootkit/log.expected
# (note that unedited output is in /var/log/chkrootkit/log.today.raw)

Ve výpisu si můžete všimnout poplachů jednak v podobě výše zmíněného otevřeného portu 465 a jednak v podobě několika „podezřelých“ souborů. V mém případě jsem dospěl k závěru, že se ve všech případech jedná o poplachy falešné (vám ovšem důrazně doporučuji každý poplach prozkoumat a učinit vlastní závěr). Abyste svůj aktuální stav uložili, je třeba jej zkopírovat do souboru /var/log/chkrootkit/log.expected, tak, jak naznačuje samotný výpis, tedy:

cp -a /var/log/chkrootkit/log.today /var/log/chkrootkit/log.expected

Od této chvíle bude chkrootkit při denní kontrole brát v úvahu pouze odchylky od tohoto uloženého stavu.

rkhunter

Druhým detektorem, který představím, je rkhunter. Tento nástroj se zdá být o něco komplexnějším, obsahuje aktualizovatelnou databázi známých hrozeb a vytváří si vlastní databázi kontrolních součtů kritických souborů, se kterou porovnává aktuální stav.

Instalaci lze vyřešit podobně jako v případě nástroje chkrootkit:

aptitude install rkhunter

Prověření systému provedete následujícím příkazem:

rkhunter -c

Objevíte-li během prověřování nějaké varování, více informací se dozvíte z logu, který se standardně ukládá do /var/log/rkhunter.log. Opět připomínám vhodnost prověření každého poplachu, byť některé z nich mohou být falešné. Stejně jako v případě nástroje chkrootkit, doporučuji si projít informace o falešných varováních v /usr/share/doc/rkhunter/README.Debian.gz. Momentálně existuje falešný poplach na Debianu Squeeze v podobě rootkitu „Xzibit“ z důvodu existence řetězce „hdparm“ v souboru /etc/init.d/hdparm. Pokud víte, že je to určitě i váš případ, můžete tomuto varování zamezit úpravou konfiguračního souboru /etc/rkhunter.conf, konkrétně přidáním výše zmíněného init skriptu do whitelistu (proměnná RTKT_FILE_WHITELIST).

Nástroj rkhunter obsahuje široké možnosti konfigurace, doporučuji si výše zmíněný konfigurační soubor projít a upravit podle svých představ. Mezi jednu z důležitých voleb patří ALLOW_SSH_ROOT_USER, která by měla být nastavena stejně jako příslušná hodnota v nastavení SSH démona. Rkhunter pak varuje, pokud se hodnota změní. Některé testy jsou v případě Debianu implicitně vypnuty. Naleznete je i spolu s popisem u volby DISABLE_TESTS. Můžete také definovat vlastní hashovací nástroj (výchozí je sha1sum), a to ve volbě HASH_FUNC.

Zmínil jsem, že rkhunter obsahuje aktualizovatelnou databázi známých hrozeb. Aktualizaci můžete provést ručně příkazem:

rkhunter --update

V Debianu se tato databáze aktualizuje automaticky každý týden (viz /etc/cron.weekly/rkhunter). Databázi hashí kritických souborů lze aktualizovat pouze ručně, ideálně pouze jste-li si jisti, že všechny ohlášené změny jsou v pořádku. Aktualizaci můžete provést následujícím příkazem:

rkhunter --propupd

Stejně jako nástroj chkrootkit má i rkhunter skript pro spouštění cronem v /etc/cron.daily/rkhunter. Jeho nastavení naleznete v souboru /etc/default/rkhunter. Ve výchozím stavu je denní kontrola se zasíláním e-mailů zapnuta.

Na závěr dodám, že rkhunter upozorňuje i na staré (a zranitelné) verze některých démonů a nástrojů. Zde je potřeba mít na paměti, že software v repozitářích distribuce se sice záplatuje, ale verze zůstávají stejné. V tomto případě tedy stará verze nevadí.

Zotavení po průniku

Obecnou radou, jak si počínat při zjištění průniku, je nepanikařit a nedělat unáhlená rozhodnutí. Pokud již útočník do vašeho systému pronikl, existuje velká pravděpodobnost, že již provedl, co provést chtěl, tj. škoda byla napáchána, tudíž rychlé protiopatření (např. odstavení serveru) jí už nezabrání. Pokud server odstavíte hned nebo až třeba za hodinu, tedy nehraje takovou roli. V podnikovém prostředí často existují předem dané postupy, jak si s takovou situací poradit, koho kontaktovat a jak postupovat. Nebývá na škodu mít takový scénář připraven i v případě menších či osobních serverů.

Kritické je zjistit, kudy útočník do systému pronikl. Pokud to nezjistíte, můžete ho v systému za čas opět najít. Kompromitovanému systému a veškerému softwaru na něm je vhodné nevěřit. Nelze než doporučit kompletní reinstalaci systému, neboť nikdy nebudete mít jistotu, že jste zachytili vše. Před tím je ovšem vhodné udělat zálohu kompromitovaného systému i všech dat k pozdější analýze (či jako důkaz pro případné soudní řízení).

Zotavení napadeného systému je třeba přizpůsobit situaci. Máte-li soukromý server, na kterém veskrze nic důležitého neběží, můžete si dovolit jej odstavit i na delší čas. Jedná-li se ovšem o server, na kterém stojí vaše podnikání nebo přežití vaší firmy, je třeba postupovat opatrně a s rozmyslem.