Jak nasadit systém detekce průniků

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 nichž 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 metodu, 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í.



Zaostřeno na síť

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šina síťových IDS systémů obě zmíněné metody

kombinuje, čímž dosahuje výkonové optimalizace a vyšší průchodnosti.



Správné nasazení

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é.



Kam s ním?

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 patrně

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 jejím umístění a připojení

velmi dobře uváženo.



Co s ním?

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…



Snort

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.



Režimy práce

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.



Konfigurace

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.



Pravidla

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 bajtů 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)

classtype (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.)



Okolo Snortu

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

64kilobitovou 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.



Grafy

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 něj vznikla řada

iniciativ, které se zaměřují na různé problémy. Jednou z nich 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 kritérií.



Na závěr

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 nebo

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 o filozofii tzv. svobodného softwaru, 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á.

Autor je konzultantem společnosti Actinet Informační systémy

4 0068 / pen



Vybrané zdroje na webu

www.snort.org domovská stránka projektu Snort

acidlab.sourceforge.net ACID Analysis Console for Intrusion Databases

jeremy.chartier.free.fr/snortalog log analyzer pro Snort a další bezpečnostní

aplikace (například FireWall-1)

www.gnu.org/licenses/licenses.html přehled a vysvětlení GNU licencí

www.gnu.org/home.cs.html stránky projektu GNU