> Zpět  


Stopařův průvodce po průšvihu


Možná se vám už přihodilo něco podobného: Je krásné nedělní odpoledne, vy si užíváte pracovního volna a najednou přijde textová zpráva od chytrého IDS týkající se napadení vašeho serveru.

Vaše IDS se dožaduje pozornosti a textová zpráva jasně říká, že se jedná o útok, který je založen na půl roku staré chybě a Vaše servery jsou všechny patchovány - cíl útoku jste osobně zkontrolovali před třemi týdny při pravidelné profylaxi. Během hodiny následuje hysterický telefonát během kterého se dozvíte, že před týdnem proběhla reinstalace serveru a administrátor ještě nenainstaloval všechny patche. Útok byl pravděpodobně úspěšný. Co teď?

Základem bezpečnostní politika

Je naprosto nezbytné být připraven na eventualitu možného bezpečnostního průšvihu - sebelepší monitoring, analýzy a patchování Vás nemusí uchránit od bezpečnostního problému, který může mít nepříjemné následky. Takže si musíte rozmyslet, co pro vás představuje riziko a jaké jsou možné důsledky. Nejčastějšími oblastmi jsou obchodní ztráty, ztráta dobrého jména, důvěry, popřípadě ztráta důležitých a/nebo tajných informací. Je větším problémem ztráta dat, nebo jejich neoprávněná modifikace? Kdo a odkud může škodit? Anonymní uživatelé na Internetu nebo partneři na extranetu? Zaměstnanci z vnitřní sítě? Možností je mnoho, nicméně byste měli být schopni na základě alespoň přibližných odhadů stanovit možné scénáře a připravit si vhodné nástroje a postupy pro případ nejhoršího. Tyto postupy byste měli formalizovat a zahrnout je do celkové bezpečnostní politiky společnosti.

Předpokládejme, že máte zajištěný perimetr sítě, provedli jste základní segmentaci vnitřní sítě a jste schopni kontrolovat přesně definované datové toky tak, abyste minimalizovali riziko. Měli byste tam, kde je to možné zajistit kontrolní součty důležitých souborů - na to se hodí například Tripwire, zapnout audit a očesat všechny systémy od software a služeb, které nepotřebujete. Zálohujte a hlavně prověřte, že vaše procedury pro obnovení ze zálohy fungují tak, jak mají.

Také si musíte dobře rozmyslet, jak budete na případný problém reagovat. Předpokládejme, že máte vnitřní pravidla pro zaměstnance. Jak se ale zachováte v případě, že viníkem incidentu bude důležitý obchodní partner, zákazník, či dokonce konkurence? Máte několik možností:

  • ignorovat incident
  • bránit se proti dalším útokům technickými prostředky
  • zabránit dalším útokům tak, že identifikujete útočníka a právní oddělení to vyřeší za Vás žalobou nebo trestním oznámením

Většinou budete při výběru vhodného postupu ovlivněni těmito faktory:

  • dopad na obchodní činnost společnosti. Má smysl pokoušet se identifikovat útočníka, který znectil webový server, jenž používá pět lidí dvakrát do roka? A co primární vstupní portál pro všechny zákazníky?
  • právní předpisy - musíte si dávat pozor, zda při své reakci neporušíte právní předpisy. Asi není nejlepší odpovědí na drobný incident odpovědět brutálním protiútokem, který útočníkovi smaže všechna data.
  • korporátní politika většinou diktuje celou bezpečnostní filozofii - musíte vědět, zda se vůbec máte snažit se na něco připravit. Pokud společnost nemá zájem o ochranu své infrastruktury a dat, budete mít pravděpodobně velký problém vysvětlit nadřízeným, že opravdu potřebujete peníze na zařízení, lidi a jejich vzdělávání, abyste byli schopni reagovat na problémy.
  • technické možnosti a schopnosti Vašeho týmu jsou ovlivněny výše zmíněnou korporátní politikou a bezpečnostní politikou společnosti. Tento dokument by Vás měl opravňovat k provádění činností jako je například monitoring komunikace a jejího obsahu, komunikace s externími společnostmi při řešení incidentu, analýza disku na počítačích přidělených zaměstnancům a podobně.
Formální bezpečnostní politika Vám umožní v případě incidentu nepřemýšlet nad tím, co můžete a co ne. Prostě se podíváte do papírů a víte to. Ušetří Vám to mnoho času, který můžete místo shánění šéfa a diskusi o vhodné akci věnovat vlastní reakci na incident.

Analyzujeme incident, co je k tomu třeba?

Pro analýzu incidentu je vhodné mít k dispozici dostatečně výkonný stroj a spoustu dalších věcí, které budou vyhrazeny právě pro reakci na incident. Stručný výčet vlastností vašeho nástroje pomsty:
  • rychlý procesor
  • hodně paměti
  • velké IDE disky
  • velké SCSI disky
  • několik rychlých síťových karet
  • DVD vypalovačka
  • pásková mechanika, ZIP, Jazz
Budete také potřebovat nějaké díly a příslušenství:
  • napájecí kabely, popřípadě "psa"
  • SCSI, IDE kabely
  • minimálně dva huby a dostatek síťových kabelů
  • média: CD. DVD, ZIP, pásky
  • samolepky a popisovače
  • nářadí (nebo alespoň Victorinox Cybertool)
  • manuály ke všemu
  • tiskárnu a papíry
  • UPS
Příslušenství nepodceňujte - hledání šroubováku, prázdného CD nebo přemýšlení nad správným nastavením jumperů na kartě v kritické situaci je zbytečné, když můžete sáhnout do kufru nebo se podívat do manuálu.

Také budete potřebovat nějaký software. Pro zjednodušení budeme předpokládat, že máte nainstalován nějaký unix, který implicitně obsahuje všechny základní nástroje pro postupy popsané níže. Velmi se Vám bude hodit vmware, což je emulátor platformy x86. Asi si budete muset koupit licenci na Windows (za předpokladu, že existuje možnost nutnosti analyzovat, co se stalo na serveru s tímto operačním systémem). Rozhodně si připravte médium s vlastními programy, kterým můžete důvěřovat. Jen matka příroda ví, co Vás čeká. Určitě se bude hodit find, netstat, strings, dd, ps, vi, netcat, ssh a mnohé další. Je-li to možné linkujte staticky a stripujte. Není-li možno kompilovat staticky, nezapomeňte použít vlastní knihovny.

Co dělat po bezpečnostním incedentu?

Předpokládejme, že jste v rámci možností připraveni. V případě, že nastane problém, měli byste se nejprve snažit zajistit co nejvíce informací z následujícího výčtu:
  • kdo, kdy a komu hlásil incident
  • co a kdy se stalo
  • jak a kdy se na to přišlo
  • možné dopady
  • o jaká zařízení se jedná:
    • hardware, OS, software
    • jak moc kritická data tam jsou nebo byla
    • IP adresa, typ síťového připojení
    • kde se stroj nachází
    • kontakt na administrátora systému a aplikací
    • v jakém stavu je zařízení
  • detaily o nežádoucí činnosti
    • je vetřelec stále aktivní?
    • máme jeho zdrojovou adresu?
    • DoS útok nebo jiný vandalismus?
    • útočník zvenčí nebo zevnitř?
  • co kdo udělal?
    • viděl někdo logy?
    • byl počítač vypnut nebo odpojen od sítě?
    • změny na okolní infrastruktuře? (firewally, ACL na routerech atp.)
    • komu všemu kdo volal?
  • od koho se dají získat další informace
  • komu smíte/nesmíte poskytovat informace
  • topologie okolních sítí
  • možnost monitoringu provozu
  • dostupnost logů z okolních zařízení: firewally, routery, IDS a podobně
  • jakékoliv další relevantní informace

Co s „nemocným“ serverem?

Dorazili jste k serveru a je třeba se rozhodnout, co dál. Mějte na paměti, že existuje spousta dat, která nenávratně ztratíte jestliže postižený server vypnete a odnesete si ho do své kanceláře. Jedná se zejména o obsah paměti, stav síťových spojení, běžící procesy, přihlášené uživatele, aktivní moduly jádra a podobně. Tato data se získávají velmi obtížně, protože při jejich extrakci je většinou změníte.

Než systém vypnete, odpojíte od sítě snažte se zjistit co nejvíce, zejména následující data Vám pomohou:

  • kdo je přihlášen
  • aktivní sokety a procesy, které je používají
  • jaké procesy běží
  • dump paměti
  • aktivní moduly jádra
Nezapomeňte, že je třeba dokumentovat, co jste dělali, stáhněte si historii shellu. Oblíbeným trikem je smazání tohoto souboru a vytvoření symbolického linku na /dev/null. Nezapomeňte, že získáváním těchto informací je zároveň měníte - například při dumpu paměti systém alokuje část paměti vašemu dumpu. Rozhodně se snažte (pokud to jde) přesměrovat výstup dumpu přes síť.

Přemýšlejte, co dalšího můžete chtít, než se pustíte do dalších akcí. Na základě závažnosti incidentu budete možná nuceni provést duplikaci disku pro další analýzu. Buď si koupíte speciální software a nebo použijete opět unixový příkaz dd. Doporučuji v takovém případě použít unixový stroj, nebo LiveCD distribuci, ze které nabootujete a z Windows se rázem stane unix - nezapomeňte ovšem připojit všechny disky pouze pro čtení. Používejte MD5 checksumy, popřípadě PGP, abyste byli schopni prokázat, co jste kdy dělali.

Zkontrolujte a poznamenejte si si nastavení BIOSu a můžete odevzdat stroj do péče administrátora, který se může pustit do obnovy stroje.

Nezapomeňte všechny Vaše kroky pečlivě dokumentovat, nikdy nevíte, koho bude zajímat, co jste dělali a proč.

Útočník skrytý v informacích

Nyní máte velké množství dat, která je třeba projít a najít střípky informací, které mohou vést k identifikaci útočníka. Co budete hledat záleží zejména na povaze incidentu. Z té byste měli být schopni odvodit, co a proč Vás zajímá a jak to najít. Musíte mít detailní znalosti operačního systému a aplikace - pokud je nemáte, je vhodné si přizvat odborníka. Vhodným odborníkem může být například administrátor systému. Je třeba ovšem vědět, zda mu můžete věřit - jednou jsme řešili bezpečnostní incident, kde byl hlavním viníkem právě administrátor.

Analýza obsahu disku a paměti většinou obnáší hledání určitých řetězců - URL, mailové adresy, popřípadě dalších řetězců v závislosti na typu incidentu. Další typ hledání se často nazývá "search and extract" - jedná se speciální hledání použitelné například při hledání některých typů souborů. Například obrázek typu PNG (Portable Network Graphics) začíná hodnotami 0x89 0x50 0x4e 0x0d 0x0a 0x1a 0x0a. V případě, že hledáte soubory PNG, které mohly být smazány, ale nemusely být nutně přepsány, můžete se pokusit hledat výše zmíněnou posloupnost hodnot. Zjistíte-li, že jste se díky chybě v konfiguraci sendmailu stali například distributorem dětského porna, můžete se pokusit vyhledat všechny JPEG soubory. Zde je to ještě jednodušší, protože tento formát (a mnohé další) obsahuje v hlavičce svoji délku - stačí tedy najít hlavičku a extrahovat příslušný objem dat. Nezapomeňte také na analýzu volného diskového prostoru - tedy toho, na kterém nebyla žádná partition - i tam můžete najít zajímavé věci.

V případě, že chcete pracovat s diskem na logické úrovni - tedy připojit jej a kontrolovat adresáře a soubory, měli byste jej připojit pouze pro čtení. Pokud to není možné - například chcete pracovat pod Windows s FAT32 image, můžete se pokusit připojit jej pouze pro čtení pod unixem a exportovat jej přes SMB, kde jej připojíte jako síťový disk.

Incident? Nevíme, ale myslíme si...

Pravděpodobně mnohem častější případ, než je analýza kompromitovaného systému, je právě reakce na podněty, kdy nikdo neví, jestli se něco stalo, ale děje se něco, k čemu se nikdo nezná, popřípadě se systémy nechovají zcela podle specifikací. Vaším úkolem je v takovém případě pokusit se identifikovat nestandardní projevy, určit jejich příčinu a pokud se jedná o bezpečnostní incident patřičně zareagovat.

Drtivá většina této práce se týká síťových komunikací, jejich zachycení a interpretace. Existují velmi dobré produkty, které je možno použít pro zachycení a analýzu síťového provozu. Jedná se například o tcpdump nebo ethereal. Zde je dobré rozumět protokolům z rodiny IP (popřípadě jiným, pokud je používáte) - například zaměstnanec může k vynášení informací použít skrytý komunikační kanál - například ICMP nebo HTTP covert channeling. Takový provoz ovšem neodpovídá RFC a měli byste být schopni jej vhodným postupem identifikovat. Vhodné je použít například IDS snort - napíšete si signaturu, která identifikuje hledaný řetězec a na případný alert spustíte tcpdump a budete odchytávat komunikaci stanice.

Závěrem

V tomto krátkém úvodu nebylo možno pokrýt všechny aspekty reakcí na bezpečnostní incidenty, zbývá mnoho oblastí jako jsou směrovače, aplikace, databáze a další, které lze zmínit pouze v tomto krátkém závěru. Podrobnější popis analýz a dalších kroků je specifický pro každou platformu - jinak se budete chovat na Windows 2000 a jinak na unixovém systému. Zejména z hlediska práce na "živém" stroji, a to vzhledem k tomu, že filozofie obou systémů je velmi odlišná. Na Internetu lze nalézt překvapivě velké množství dokumentů zabývajících se do hloubky reakcemi na bezpečnostní incident. V obecné rovině lze přispět třemi dobrými radami:
  • přemýšlejte
  • dokumentujte
  • nepropadejte panice



Zdroje:
http://www.wotsit.org - vynikající zdroj pro podrobné popisy velkého množství formátů dat
http://distrowatch.org - zde si můžete vybrat, jaký systém použijete pro svoji pracovní stanici, stejně tak si můžete vybrat LiveCD unixovou distribuci
http://www.tcpdump.org - domovská stránka projektu tcpdump
http://www.ethereal.com - domovská stránka projektu Ethereal


-p6-
obrazek