Rozšíření funkčnosti IDS sníží počet varování

Dvě nové funkce zdarma dostupného systému detekce průniků Snort se snaží o omezení falešných poplachů. Falešné ...


Dvě nové funkce zdarma dostupného systému detekce průniků Snort se snaží o
omezení falešných poplachů.
Falešné poplachy a práce s velkými objemy sebraných dat jsou dvěma
nejotravnějšími aspekty používání systémů detekce průniku (IDS, Intrusion
Detection System). Proto se výrobci velmi snaží přinést vylepšení, která tyto
problémy buď zcela odstraní, nebo alespoň zmírní. Také nová verze IDS Snort,
kterou nyní používáme, situaci značně zlepšila.
V současnosti v naší síti máme více než 15 IDS senzorů a jen na správu IDS
infrastruktury potřebujeme zaměstnance na plný pracovní úvazek. Ten má mimo
jiné na starosti i kontrolu nepřetržité záplavy varovných hlášení, která jsou
senzory generována. Přestože jsme systém nakonfigurovali tak, aby byla varování
odesílána do našeho softwaru pro správu bezpečnostních informací (SIM, Security
Information Management) od firmy netForensics, zajišťujícího korelaci událostí
a jejich analýzu, první linií obrany zůstávají stále přímo data ze senzorů.
SIM na zaslané události aplikuje korelační metody, sloužící k přesnějšímu
zpracování zpráv a vytváření dalších varovných hlášení, ale vlastní základní
varování přece jen generují senzory. Činí tak pomocí analýzy síťového provozu a
porovnáním vzorků činností se stovkami pravidel, která jsme nastavili
prostřednictvím konfiguračních souborů IDS Snort. V případě zjištění podezřelé
aktivity, tedy aktivity nějak postižené danými pravidly, je zasláno varující
upozornění.
Problémem však je, že pravidla pro senzory je třeba neustále dolaďovat s
ohledem na nepřetržitě se měnící prostředí. A jednou z nejobtížnějších stránek
správy IDS infrastruktury je vyladění pravidel tak, aby byly omezeny falešné
poplachy.
V naší firmě se například odehrává řada aktivit týkajících se webu. Dokonce i
při běžných tocích dat vytvářejí IDS senzory mnohá varování ta se týkají
činností, jež vypadají podezřele, ale ve skutečnosti jsou zcela neškodné. V
takovém případě máme dvě možnosti: buď nastavit senzory tak, aby podobná
hlášení nepodávaly (což v praxi znamená prosté zakomentování příslušného
pravidla), nebo se smířit s tím, že bude třeba obětovat místo na disku pro
ukládání každého výskytu podobné události, šířku přenosového pásma i čas
obsluhy.

Vylepšení IDS
Nejnovější verze Snortu obsahuje dvě funkce pro omezení falešných varování
thresholding a suppresion. Věřím, že tato vylepšení podpoří další nasazení IDS
v naší firmě a usnadní správu současných instalací.
Vzhledem k velkému množství falešných pozitivních reakcí nuceně bráníme našim
IDS senzorům ve zpracování mnoha typů událostí. Řada varování vzniká například
tehdy, pokud se uživatel nebo program pokouší přistupovat k souboru robots.txt
na našich webových serverech. Tento soubor slouží k informování vyhledávacích
enginů o tom, ke kterým oblastem našich webových stránek by neměly přistupovat.
Naše webové servery obsahují důvěrné či citlivé informace, které určitě
nechceme mít indexovány na Yahoo nebo Googlu.
O přečtení souboru robots.txt se snaží mnoho aplikací a webových prohlížečů je
to součástí jejich běžných funkcí. Ale o přečtení jejich obsahu se snaží i
mnoho hackerů pěkně to zapadá do jejich strategie posbírat o svém cíli co
nejvíce informací.
Jsme proto v obtížné situaci. Vypnutí pravidel generujících odpovídající
varování snižuje počet falešných poplachů. Ale výsledkem je také vytvoření
nového špatně kontrolovaného prostoru, neboť již nejsme schopni odhalit
jakékoliv zákeřné aktivity v této oblasti. Právě kvůli jejich zachycení byla
zmíněná pravidla navržena. Nechat však tato pravidla zapnutá znamená stovky
falešných poplachů každou hodinu, přičemž každý z nich je třeba uložit a
analyzovat.
Thresholding, funkce běžná u komerčních IDS produktů, se správou a odhalením
falešných poplachů výrazně pomáhá. Dovoluje totiž senzorům dohlížet na počet
pokusů o přístup k souboru a vytvoří varovné hlášení až tehdy, pokud počet
překročil určitou hranici. Správce IDS tak může stále sledovat daný typ
události, není však zaplaven falešnými poplachy. Podobných typů událostí,
spadajících do výše uvedené kategorie, jsou desítky. Dosud jsme měli příslušná
pravidla vypnutá. Nyní je můžeme opět zapnout, a cítit se tak bezpečněji.

Potlačení událostí
Potlačení událostí funguje na jiném principu. Brání vytváření varování v
případě podezřelých aktivit, které nepřicházejí od předpokládaných útočníků,
ale z míst označených jako bezpečná. Prostě se potlačí daná událost, pokud je
spuštěna uživatelem nebo zařízením z určité skupiny síťových adres.
Pro příklad není třeba chodit daleko: Naše síť je neustále pod palbou SNMP
událostí vytvářených uživateli a aplikacemi z oddělení správy sítě. Tito
uživatelé využívají SNMP k odstraňování problémů a monitorování síťových
zařízení a serverů, hackeři však SNMP využívají k DoS (Denial-of-Service)
útokům nebo ke sledování sítě.
Naštěstí je řídící středisko LAN na oddělené síti. Proto lze místo úplné
eliminace spouštěcího mechanismu příslušného pravidla nebo nastavení omezení
vytvořit jiné pravidlo, jež zamezuje vytváření varování týkajících se SNMP,
pokud aktivity souvisejí s počítačem, jehož IP adresa patří správcům sítě.
Kdo chce uvedenou funkci využívat, měl by si uvědomit, že pravidla pro
potlačení (suppression) jsou zpracovávána dříve, než pravidla pro omezení
(thresholding). Obě funkce tedy lze kombinovat.

Lepší správa
Když se nám nyní podařilo omezit objem varování, můžeme se soustředit na
efektivnější odezvu v případě incidentů. O všechny události se stará tým pro
bezpečnost IT, ale chtěli bychom, aby na příslušné události byli schopni
zareagovat také analytici z oddělení správy sítě.
Dosud bylo jejich náležité proškolení obtížné. Ale při potenciálním snížení
falešných pozitivních reakcí a přesnějším vytváření varování by snad podobný
přístup mohl fungovat. Mohlo by se tak podařit omezit noční telefonáty mým
zaměstnancům, a ti by mohli nerušeně spát a přitom vědět, že je naše
infrastruktura v dobrých rukách.
Řešíte podobné problémy jako Mathias Thurman? Podělte se o svoje zkušenosti s
námi i se čtenáři Computerworldu. Můžete psát na adresu bezpecnost@idg.cz.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.