Zpět  

Jak nasadit systém detekce průniků

Článek vznikl pro časopis Computer World, vyšel v čísle 4/2004


IDS je systém, který detekuje narušení, případně pokusy o narušení bezpečnosti počítačových systémů. V následujícím textu se nebudeme zabývat IDS systémy, které zajišťují pouze bezpečnost hostitelů, na kterých jsou spuštěny, ale těmi, které monitorují provoz celého segmentu sítě a upozorní pracovníka odpovědného za bezpečnost na případný incident.

Systémy zajišťující pouze bezpečnost hostitelů, na kterých jsou spuštěny, fungují někdy až na úrovni jádra systému. Představují velmi účinnou metodou, jak zabránit útoku, případně minimalizovat jeho následky. Patří mezi ně například Tripwire, Medusa DS-9, PAX a další. Jejich konfigurace není jednoduchá, nicméně se vyplatí, protože podstatně zlepšují možnosti kontroly přístupu k jednotlivým částem systému a jeho jádra. Výrazně rovněž zvyšují bezpečnost aplikací, které na systému běží. Je ovšem třeba mít celkem přesnou představu o systémových zdrojích, které jednotlivé aplikace potřebují.

Zařízení IDS, která monitorují provoz celého segmentu sítě, pracují v zásadě na dvou principech, přičemž drtivá většina z nich oba kombinuje. Jedná se o:

• Network grep – metoda funguje podobně jako příkaz grep na většině unixových systémů – vyhledává tedy definované vzorky v síťovém provozu. Tato metoda se dá s úspěchem použít při detekci narušení, která nevyžadují rekonstrukci datového toku – příkladem může být například známý červ SQLP1434.A (Slammer.A), jenž je celý obsažen v jednom paketu.
• Stream analysis – z praktického hlediska se jedná o stejný princip jako u network grep, před analýzou se ale provádí rekonstrukce celé výměny dat. Systém je tedy schopen detekovat útoky, které vyžadují datovou výměnu, případně jsou rozděleny do více paketů právě pro snížení pravděpodobnosti detekce.

Jak již bylo uvedeno, většiina síťových IDS systémů obě uvedené metody kombinuje, čímž dosahuje výkonové optimalizace a vyšší průchodnosti.

Správně nasazený systém IDS je nedílnou součástí bezpečnostního perimetru, který v předstihu upozorňuje administrátora na některé bezpečnostní události, které jsou nebo mohou být reálnou hrozbou pro organizaci.

IDS systém monitorující síť je velmi mocným nástrojem a je třeba jej nasadit a používat v rozumné míře. Existují totiž určitá technická a legislativní omezení, která se těchto systémů týkají. Z hlediska legislativy se bude jednat zejména o předpisy zabývající se ochranou osobních údajů a důvěrných informací. Technická omezení spočívají především v objemu monitorovaných dat a ve schopnosti tato data zpracovat. Například monitorování přepínaného segmentu sítě o rychlosti 100 Mb/s je náročné nejen na hardware – je totiž třeba rovněž zvážit, na jaké mimořádné události a v jakém počtu je schopen tým zabývající se bezpečností IT v organizaci reagovat.

Většina nasazených sond bohužel nekončí tam, kde je potřeba dohlédnout na komunikaci a na její obsah, ale tam, kde generují velké množství událostí – je totiž nutno obhájit investici před managementem. Administrátor je v krátkém čase zahlcen velkým množstvím událostí, přestává reagovat a veškerý efekt nového nástroje se vytrácí. IDS se tak místo nedílné součásti bezpečnostní infrastruktury stává jen další bednou v serverovně.

Výše popsaný příklad by se dal nazvat instalací IDS. My se budeme dále zabývat nasazením IDS. Rozdíl mezi instalací a nasazením je v tomto případě zřejmý: Na rozdíl od instalace se při nasazení prostě použije hlava – všechny kroky budou řádně promyšlené.

Jedná se o otázku vskutku nerudovskou. Jak a jaké sítě monitorovat? Vzhledem k pravděpodobně omezenému rozpočtu nelze monitorovat všechno. Na výše uvedenou otázku neexistuje jednoduchá odpověď, nicméně lze říci, že je vhodné začít od nejkritičtějších aplikací – od těch, které jsou pro organizaci nejdůležitější – a postupně zvyšovat počty monitorovaných segmentů tak, abychom "nepřepálili" obsluhu. Další možností je začít od těch nejexponovanějších, což budou pravděpodobně služby poskytované veřejnosti přes internet.

Přesné umístění monitorovacího portu IDS sondy závisí na mnoha okolnostech, zejména však na segmentaci sítě, jejím typu, rychlosti, zatížení a dalších faktorech. Obecně vzato: Pokud bychom chtěli monitorovat například vnitřní síť, protože je v ní připojen důležitý server, měli bychom sondu připojit přímo do segmentu, ve kterém se server nachází. V případě přepínaných sítí bychom se měli rozhodnout mezi zrcadlením portů, použitím network tapu, nebo použitím balanceru – to umožní jedné IDS sondě sledovat více sítí a naopak. Okolností, které ovlivní naše rozhodnutí o umístění sondy, je tedy celá řada, a je nanejvýš důležité, aby bylo konečné rozhodnutí o umístění a připojení sondy velmi dobře uváženo.

Na tuto otázku existuje jednoduchá odpověď zmíněná již v úvodu: Monitorovat, detekovat, upozornit obsluhu. Bohužel správným umístěním sondy a její instalací nasazení IDS zdaleka nekončí – je třeba sondě říci, co a jak má sledovat, kdy a co má komu hlásit.

Je třeba eliminovat falešné poplachy, které stojí peníze organizace a většinou i spánek bezpečnostních pracovníků. Po zhruba měsíci pokusů a ladění politiky IDS bychom měli mít systém, který je schopen upozornit na to, že někdo loupe perníček...

Výše zmíněné postupy si nyní ukažme na praktickém příkladu nasazení IDS Snort. Jde o open source projekt šířený pod licencí GNU GPL nebo GNU GPL2. Jedná se o síťový sniffer napsaný nad knihovnou libpcap, který umožňuje upozornit administrátora několika různými způsoby na bezpečnostní nebo síťový problém.

Nejde o software, který by si činil ambice stát se plnohodnotnou náhradou za profesionální sondy jako je například ISS RealSecure, ale lze jej velmi dobře použít k monitorování menších sítí s tím, že finanční ředitel je ušetřen infarktu.

Na domovské stránce projektu (www.snort.org) lze nalézt zdrojový kód a binární balíčky RPM pro různé distribuce Linuxu. Zároveň jej lze nalézt v ports collection FreeBSD, portage Gentoo Linuxu, grimoárech SourceMage a v dalších systémech. Zajímavé je, že Snort je integrován i do některých malých firewallových distribucí, jakou je například IPCop.

Snort může pracovat ve třech základních režimech, které lze doladit mnoha přepínači z příkazové řádky:

• Sniffer: přenáší na standardní výstup pakety, které vidí na síťových rozhraních.
• Logger: ukládá pakety na disk
• NIDS: na základě politiky definované v konfiguračním souboru rozhodne, co se s paketem udělá a jaká bude další reakce.

Nás samozřejmě nyní zajímá režim posledně jmenovaný a je třeba uvést několik poznámek k organizaci konfiguračních souborů a adresářové struktuře Snortu.

Implicitně se všechny soubory produktu vyskytují v adresáři /etc/snort a logy se ukládají do adresáře /var/log/snort.

Konfiguračních souborů je mnoho, ale v zásadě je lze rozdělit do 3 skupin:

• hlavní konfigurační soubory
• soubory s pravidly pro IDS
• vlastní konfigurační soubory

Hlavní konfigurační soubor snort.conf obsahuje základní nastavení IDS a dělí se na 4 části, které obsahují:

1. základní definice, které Snort informují o topologii kontrolované sítě a o základních aplikačních serverech
2. jemnější nastavení snortu – jaké moduly pro dekódování provozu použít, kolik jim alokovat paměti a které protokoly dekódovat. Pokud nemáte nervy na ladění těchto parametrů, měli byste si vystačit s implicitním nastavením
3. prioritizace alertů a zdroje informací pro reference k jednotlivým chybám (implicitně v souborech classification.config a reference.config)
4. které skupiny pravidel se použijí při vlastní detekci (implicitně v souborech *rules)

Tajemství přehledného členění konfiguračních souborů spočívá v direktivě include, která se chová stejně jako její jmenovkyně v programovacím jazyce C, tedy tak, že při zpracování preprocesorem vloží místo sebe soubor, jenž má uveden jako parametr. Ve výsledku tak při spuštění snortu dojde k interpretaci všech těchto direktiv a snort zpracuje jeden velký konfigurační soubor.

Toto přehledné uspořádání konfiguračních souborů umožňuje velmi pohodlné členění vlastní politiky do sad pravidel (rulesets) podle zaměření na jednotlivé protokoly či aplikace. Prostým zakomentováním řádku obsahujícího direktivu zakážeme použití všech pravidel rulesetu pro protokol POP2. Naopak pokud potřebujeme jemně vyladit pravidla daného rulesetu, stačí si jednoduše otevřít soubor a zakomentovat pravidla, která chceme deaktivovat.

Zbývá se zmínit o vlastních pravidlech, která můžeme uspořádat stejně přehledně, jako tomu je u pravidel implicitních. Neměli bychom je vkládat do stávajících souborů – je pro ně totiž připraven prázdný soubor local.rules. Tento soubor můžeme dále členit.

Kompletní popis pravidel by vyžadoval rozsáhlý prostor, ukažme si tedy alespoň jedno vybrané, které je obsaženo v implicitním rulesetu icmp.rules (celý text příkazu je na jediném řádku):

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP Large ICMP Packet"; dsize: >800; reference:arachnids,246; classtype:bad-unknown; sid:499; rev:3;)

Pravidlo detekuje paket icmp echo request s podezřele velkým datovým segmentem. Různé aplikace vytvářejí tyto pakety o různých délkách a s různým obsahem, nicméně délka datového segmentu větší než 128 bytů je podezřelá a může ukazovat například na DoS útok nebo komunikaci útočníka s již napadeným serverem. Co znamenají jednotlivé části:

• Klíčové slovo alert říká, že pravidlo vygeneruje alert zvolenou metodou a paket zaloguje.
• Dále je specifikován protokol ICMP – v současné době je Snort schopen provádět analýzu protokolů IP, ICMP, UDP a TCP.
• Text až k levé kulaté závorce specifikuje zdroj a cíl (včetně portu, pokud to má smysl) paketu. V tomto případě musí ping přijít z externí sítě.
• V závorce je popsáno vlastní pravidlo, jednotlivé hodnoty jsou od sebe odděleny středníkem a jsou ve formátu <název_pole>:<hodnota>;

• msg – hlášení pro alert a log, též název signatury
• dsize – zmíněná velikost datového segmentu paketu
• reference – kde lze nalézt informace o dané signatuře, více v konfiguračním souboru reference.config.
• class-type označuje klasifikaci události, v tomto případě neznámý, ovšem potenciálně velmi nebezpečný druh provozu.

Toto krátké pravidlo samozřejmě neobsahuje všechny možné položky, které jsou ve Snortu k dispozici. Pravidla se mohou stát komplexnějšími, lze jimi aktivovat jiná pravidla. (Například pokud sonda detekuje buffer overflow, může aktivovat pravidlo, které zaloguje dalších několik desítek paketů této komunikace. Jejich obsah, pokud se jedná o pokus o průnik, bude hodnotnou četbou pro analytika zabývajícího se incidentem).

Nyní je tedy zřejmé, jak přibližně Snort funguje a jak ho nastavit, nicméně pro úspěšné nasazení IDS je třeba rozmyslet si ještě několik věcí, které jsou stejně důležité jako vlastní instalace a vyladění politiky:

• kam a v jakém formátu budeme logovat?
• jak data zpracujeme?
• jak uděláme ty hezké grafy a tabulky, abychom šéfa uklidnili, protože my si už 3 týdny hrajeme s něčím, čemu on absolutně nerozumí?

Odpověď na první otázku závisí hodně na tom, jak budeme sondu používat a kolik jich vlastně budeme mít. Jedna sonda monitorující síť s 10 počítači a 64 kilobitovou linkou do internetu si vystačí s textovým logováním a s alerty posílanými e-mailem. Oproti tomu bezpečnostní pracovník větší organizace pravděpodobně bude potřebovat cosi rychlejšího a organizovanějšího.

Organizovanost je Snort schopen zajistit, protože umožňuje logovat do několika SQL databází. Co se týče rychlosti, zde pomůže například projekt Barnyard, který slouží jako jakási proxy nebo buffer mezi rychlým Snortem, který ve špičkách může vychrlit mnoho dat, a pomalejším zápisem do textového souboru nebo databáze. Více sond samozřejmě může logovat do jedné centrální databáze.

Otázka zpracování dat je dosti náročnou záležitostí a v případě menší nebo střední organizace nepříliš závislé na internetu je nutno položit základní otázku: "Co je tak důležité, abych se nechal v noci vzbudit?" V případě organizací větších, nebo závislých na internetu je tato odpověď předem známa a pohybuje se mezi "Skoro všechno" a "Všechno". Je ovšem třeba určit rozumnou hranici, kdy systém upozorní na problém. Čímž se dostáváme zpět k první části, kdy jsme uvedli, že obsluhu není možno burcovat neustále, jinak otupí a její reakce nebudou při skutečné krizi takové, jaké bychom očekávali.

Poslední otázkou, pro některé uživatele pravděpodobně nejožehavější, je: Jak dosáhnout kvalitního reportingu? Pokud je IDS nasazován v rámci nějakého projektu posílení bezpečnostního perimetru, bude pravděpodobně nezbytné vytvářet tabulky a grafy, které by měly alespoň trochu vypovídat o činnosti IDS. Projekt Snort tyto problémy neřeší přímo, nicméně okolo projektu vznikla řada iniciativ, které se zaměřují na různé problémy. Jedním z těchto projektů je ACID (Analysis Console for Intrusion Databases).

ACID je analyzátor logů nejen ze Snortu, ale i z dalších bezpečnostních aplikací. Přes webové rozhraní umožňuje hledání a seskupování událostí. Jednou z jeho lepších vlastností je i generování statistik a grafů podle času, sondy, priority a dalších kriterií.

Snort je produkt, který může najít své místo v téměř každé instituci, ať už jako záloha komerčního IDS, pomocné IDS, či jako hlavní IDS systém malého či středního podniku. Jak již bylo řečeno výše, Snort je šířen pod licencí GNU GPL nebo GNU GPL2. Tyto licence byly vytvořeny pro projekt GNU, jehož hlavním organizátorem a sponzorem je Free Software Foundation. Free v tomto případě ovšem neznamená zadarmo, jedná se filozofii tzv. svobodného software, která je popsána na webových stránkách projektu GNU a v kostce spočívá ve svobodě software používat, modifikovat a dále distribuovat, za předpokladu, že další distribucí nedojde k omezení těchto svobod.

Diskusí na téma licencování, open source vs. closed source, GNU versus proprietární licence lze nalézt na internetu nepřeberně. Důležité pro projekt Snort je v tomto případě to, že je podporován jako zdroj dat pro většinu komerčních dohledových centrál a mnohé komerční firmy též přispívají signaturami, takže se celý projekt velmi slibně rozvíjí a investice času do jeho probádání rozhodně není ztrátová.

-p6-