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
PŘEDPLATNÉ
ČLÁNKY DO MAILU