Ako sme si minule ukázali, signatúry využívajú premenné HOME_NET, EXTERNAL_NET a práve pre správne fungovanie týchto signatúr je nevyhnutné správne nakonfigurovať tieto parametre. (vyskytujú sa tam navyše parametre HTTP_SERVERS, SQL_SERVERS, DNS_SERVERS. Tieto sú potrebné k činnosti preprocesorov ktoré pre dané hosty upravujú citlivosť reakcií na portscany a podobne).
Dalším krokom je konfigurácia, lepšie povedané výber preprocesorov ktoré by sme radi využívali. Existujú preprocesory spracúvajúce fragmentované pakety, preprocesor spracujúci streamy, ktorý dokáže pozbierať pakety do zadanej veľkosti a potom ich naraz pošle na spracovanie, čím podporuje detekciu v stavovom kontexte, rpc dekódovač, Back Orrifice dekódovač, portscan detektor a mnoho dalších pričom takmer v každej verzii sa objavujú nové a nové. Ak by mal niekto záujem venovať sa im bližšie, vo vzorovom konfiguračnom súbore sú tieto celkom príjemne okomentované.
Posledným z krokov konfigurácie IDS je voľba spôsobu akým nás bude náš IDS upozorňovať že v našej sieti sa niečo nekalé deje. Máme na výber z nasledujúcich možností: výstup do syslogu, logovanie paketov vo formáte tcpdump, výstup smerom do databázy (podporovaných je viacero databáz), výstup ako do xml súboru, upozornenia cez SNMP trapy. Je iba na Vás, ktorú možnosť si vyberiete. Osobne používam výstup do súboru, nad ktorým sa následne spúšťa parser logov. V tejto sekcii sa nachádza aj časť v ktorej si podľa názvu súborov môžete vybrať na čo má Váš IDS dávať pozor. Keďže v súčastnosti je pravidiel dosť veľa (počet sa pohybuje okolo čísla 1500), je vhodné vybrať si z týchto hlavne tie ktoré nám prinesú najviac úžitku. Ak v našej sieti nemáme MS IIS servery, asi nebudeme potrebovať web-iis.rules , aj keď naopak ak máme dostatočne veľký výpočtový výkon a nás to zaujíma, prečo nesledovať že či sa k nám nevysielajú aj útoky na IIS servery. (poviem Vám, takých Code Redov príde počas dňa ešte stále dosť veľa :-))
Setkal jste se s ňákyma emigrantama?
Setkal.
Mluvili jste s nima?
Mluvil.
A o čem jste si povídali?
Celkem o xxxxx, soudruhu Bláho.
Čo sa týka výkonu IDS servera. Podľa informácií z konferencií, výkon bežného PC (PII, 128MB RAM) je postačujúci pre činnosť IDS bez dropovania paketov do rýchlosti linky T1. Samozrejme pri vyšších rýchlostiach záleží na mnohých veciach ako rýchlosť diskových operácií, množstvo pravidiel.
A teraz poďme k nášmu praktickému príkladu. Pri tomto príklade budem predpokladať, že našu vnútornú sieť chráni firewall postavený na linuxe (na konkrétnu distribúciu sa viazať nebudeme) a my by sme radi vedieť, že či nejakí „bad guys“ neútočia na náš server a to či už s úspechom alebo bez úspechu. Náš firewall má dve rozhrania, ethernety. Jedným je pripojený do vnútornej firemnej siete a druhým k routeru ktorý sprostredkuváva pripojenie do Internetu.
Adresný plán:
vnútorné rozhranie: eth0 192.168.1.1
vonkajšie rozhranie: eth1 195.168.1.1
Snort budeme spúštať zo štartovacieho skriptu, umiestneného medzi ostatnými štartovacimi skriptami v našej distribúcii a snort spustíme s takýmito parametrami:
/usr/local/snort/bin/snort -I -i eth0 -de -A fast -c /usr/local/snort/etc/snort.conf -l /var/log/snort/eth0/ -b -p -S HOME_NET=192.168.1.1/32
Pre druhé rozhranie spustíme ďalší proces snortu s parametrami prispôsobenými danému rozhraniu t.j.:
/usr/local/snort/bin/snort -I -i eth1 -de -A fast -c /usr/local/snort/etc/snort.conf -l /var/log/snort/eth1/ -b -p -S HOME_NET=195.168.1.1/32
Tieto parametre podľa manuálu znamenajú toto:
Parametrom -I povieme snortu aby do logov pridával aj meno interface ku ktorému daný útok patrí, parameter -i prezentuje na ktorom rozhraní budeme sledovať prevádzku, -d znamená že pri dumpovaní podozrivého paketu budeme dumpovať aj aplikačné dáta, -e znamená že dumpované dáta rozšírime o hlavičku druhej vrstvy (v našom prípade hlavičky protokolu Ethernet), -A parameter špecifikuje formát zápisu do alert logu, teda v našom prípade budeme používať fast formu zápisu do logov čo znamená, že budeme zaznamenávať tiestamp, správu, IP adresu a port. Parametrom -c udávame ktorý súbor sa má použiť ako konfiguračný a -l do ktorého adresára budeme logovať. Z dôvodu prehľadnosti je výhodné každému procesu špecifikovať vlastný adresár na logovanie. Parameter -b udáva že pakety budeme dumpovať v tcpdump tvare. Manuál v tomto mieste vraví že s týmto parametrom snort dokáže dumpovať aj pakety zo 100 Mbit/s siete. (samozrejme záleží od mnohých iných vecí ale autori tvrdia že pri problémoch hľadajte chybu mimo snortu :-)) -p vraví že pri činnosti nebudeme prepínať sieťovú kartu do promiskuitného módu. Za parametrom -S môžete špecifikovať hodnoty všetkých premenných z konfiguračného súboru. V tomto prípade, keďže budeme používať ten istý konfiguračný súbor, potrebujeme týmto parametrom zadefinovať iba HOME_NET.
Keďže náš firewall má dve rozhrania, spustíme snort na obidvoch. Snort bežiaci na vnútornom rozhraní nám pomôže pri detekcii trójskych koní nachádzajúcich sa v našej vnútornej sieti, útokov na náš fireewall z vnútornej siete (podľa štatistík je takýchto útokov až 60&nsp;% !) a podobne.
A teraz je na nás aby sme sledovali alert.log. Toto môžeme robiť ručne alebo si môžeme na to pozvať pomocníka menom SnortSnarf.
SnortSnarf je perlovský skript ktorý spracuje výstup z nášho IDS do podoby html stránok, rozumne člených podľa typu útoku, podľa zdroja alebo cieľa útoku. Je už len na nás aby sme mu dopravili logy a on sa už o zvyšok postará. SnortSnarf je možné nájsť na tejto adrese.
Reakcie na útoky
Táto otázka je veľmi dôležitá aj keď existuje viacero prístupov ako reagovať na útoky. Priamo v distibúcii snortu sa v sekcii Contrib nachádza skript Guardian, ktorý v prípade použitia sleduje alert log, každý riadok ktorý doň pribudne spracuje a na základe zdrojovej IP adresy útoku pridá do paketového filtra pravidlo pre blokovanie prevádzky so zdrojovou adresou z ktorej prišiel útok. osobne však týmto prístupom veľmi nadšený nie som. Problém je v tom, že snort štandardne obsahuje mnoho pravidiel s klasifikáciou info do ktorej patria napr. ICMP redirect net, a ďalšie napr. ICMP pakety a bolo by teda dosť nerozvážne blokovať aj zdroje tekýchto alertov. Riešením je buď výber IBA skutočne nebezpečných pravidiel, čo znamená revíziu pravidiel alebo použiť iný, viac sofistikovaný blokovací mechanizmus ktorý by napríklad využíval priamo klasifikáciu nebezpečnosti útokov obsiahnutú v každom snort pravidle. Bohužiaľ, podobný sofistikovaný skript som zatiaľ na Internete neobjavil, ale verím, že aj medzi čitateľmi tohoto článku je veľa šikovných programátorov pre ktorých bude toto výzvou a pokúsia sa s tým potrápiť.:-)
Samozrejme stále je lepšie aspoň vedieť čo sa v sieti deje a čo najpromptnejšie reagovať, ako zostať v blaženej nevedomosti a namýšľať si že je všetko v poriadku.
A čo dodať na záver? Verím že týmto článkom sa mi podarilo pritiahnuť správcov sietí a systémov k použitiu IDS v ich sieti a tak aspoň trochu prispieť k vyššej bezpečnosti v prostredí Internetu.
