Úvod

Ačkoli první typy systémů pro detekci narušení sítě sahají až do počátku 80. let, koncept IDS odstartoval, když Martin Roesch vytvořil svůj svobodný a open source systém IDS SNORT. Díky jeho odlehčené konstrukci a flexibilním možnostem nasazení se uživatelská základna systému SNORT v následujících letech rychle rozrůstala (v současnosti až na 400 000 uživatelů).

V roce 2001 založil Martin Roesch společnost Sourcefire (v roce 2013 ji koupila společnost Cisco) pro komerční produkt IDS založený na SNORT. Původní bezplatná a open-source verze SNORT však zůstala k dispozici a stále se hojně používá v sítích po celém světě. Mezitím se v oblasti open source IDS prosadili někteří konkurenti, zejména Suricata IDS.

Jaké jsou mezi nimi hlavní rozdíly a co můžeme v budoucnu očekávat od SNORTu?

Pravidla

Řešení IDS je tak dobré, jak dobrá jsou dostupná pravidla, která může aplikovat na sledovaný provoz. Snort měl vždy velkou podporu komunity, což vedlo k vytvoření rozsáhlého souboru pravidel, který je pravidelně aktualizován. Syntaxe pravidel je poměrně jednoduchá a struktura programu umožňuje každému nasadit vlastní pravidla do svého IDS nebo je sdílet s komunitou.

Některé komerční subjekty vyvíjejí také pravidla SNORT, která lze zakoupit za měsíční nebo roční poplatek. Příkladem mohou být pravidla SO/VRT společnosti Talos (po měsíci jsou uvolněna zdarma) a CrowdStrikes Threat Intelligence Services.

Suricata může používat stejná pravidla jako SNORT. Mnohá, ale ne všechna pravidla VRT stále fungují. Suricata má vlastní sadu pravidel, která je zpočátku uvolněna pro platící předplatitele, ale po 30 až 60 dnech je k dispozici volně: Suricata je k dispozici v režimu Suricata: Emerging Threats (vznikající hrozby). Tato pravidla Suricata ve větší míře využívají další funkce, které Suricata nabízí, jako je detekce port-agnostických protokolů a automatická detekce a extrakce souborů.

Detekce aplikací

Od počátku existence Snortu se říká, že Snort není „application-aware“. Jednoduše se dívá na provoz, který odpovídá jeho pravidlům, a v případě shody provede akci (upozornění, zahození atd.). Předběžné procesory pomáhají tím, že provoz formují do formátu použitelného pro pravidla: například provádějí dekompresi a dekódování, ale nebylo potřeba, aby Snort rozuměl tomu, jaká aplikace data generuje.

Požadavky podniků se však postupem času měnily, a aby se Snort přizpůsobil trhu, uvedl v roce 2014 ve své verzi 2.9.7 na trh OpenAppID. OpenAppID umožňuje detekci aplikací prostřednictvím tzv. detektorů 7. vrstvy. Ačkoli existence známé aplikace nemusí vždy znamenat přímý bezpečnostní incident (například používání služby Dropbox), umožňuje lépe porozumět tomu, co v síti existuje. Nejenže lze najít dříve neznámé aplikace, ale jejich provoz lze také zahodit nebo na něj upozornit propojením identifikátoru AppID s tradičním pravidlem SNORT IDS/IPS.

Suricata v této oblasti pracuje poněkud odlišně. Podporuje pravidla detekce aplikační vrstvy a dokáže například identifikovat provoz HTTP nebo SSH na nestandardních portech na základě protokolů. Na tyto detekce pak také použije nastavení protokolu specifické pro daný protokol.

V této oblasti skutečně neexistuje lepší nebo horší produkt, záleží na tom, co firma hledá a který systém nejlépe vyplní mezery v detekci. Protože jsou oba plně open-source, je nastavení testovacího prostředí relativně rychlé a levné.

Multithreading

Jednou z hlavních výhod Suricata je, že bylo vyvinuto mnohem později než Snort. To znamená, že má na palubě mnohem více funkcí, které jsou v dnešní době prakticky nepostradatelné. Jednou z těchto funkcí je podpora multithreadingu.

Nárůst síťového provozu v průběhu let úzce souvisí s nároky na zpracování dat na zařízení IDS (měřeno v paketech za sekundu). Suricata naštěstí podporuje vícevláknové zpracování hned po vybalení z krabice. Snort však multithreading nepodporuje. Bez ohledu na to, kolik jader procesor obsahuje, bude Snort využívat pouze jedno jádro nebo vlákno.

Existuje poměrně komplikované řešení: spuštění více jednovláknových instancí SNORTu, které se všechny napájejí do stejného protokolu. Přidané režijní náklady na správu tohoto procesu (AutoFP) a vysoké náklady na hardware však znamenají, že se toto nastavení v produkčních prostředích vyskytuje jen zřídka. SNORT3 bude vícevláknový provoz podporovat, ale zatím je ve fázi Alpha a běží jako Snort++. Samozřejmě se nedoporučuje používat produkt ve fázi Alpha v produkčním prostředí. Vícevláknovost je nepochybně pádným argumentem, proč uvažovat o Suricatu místo Snortu.

Vytahování souborů

Suricata podporuje vytahování souborů. Jedná se o neuvěřitelně užitečnou funkci, která umožňuje automatickou extrakci vybraných souborů po spuštění pravidla obsahujícího volbu „filestore“. Je například možné extrahovat všechny soubory .pdf nebo všechny jednopixelové soubory .png a uložit je do předem nakonfigurované složky pro další ruční analýzu, vyhledávání na VirusTotal nebo dokonce automatický sandboxing.

Alternativy

Ačkoli jsou Snort a Suricata jistě nejoblíbenějšími open-source systémy detekce narušení, existují některé alternativy. Již dříve zmíněná aktualizovaná verze SNORT3 vypadá velmi slibně díky podpoře multithreadingu, identifikaci služeb a přímočařejšímu jazyku pravidel. Ten je ve vývoji již řadu let. Stádium Alpha však sahá až do roku 2014 a datum vydání produkční verze zatím nebylo stanoveno.

Existují také alternativy k tradičním řešením IDS/IPS, které však někdy mohou fungovat poněkud odlišně. Například Bro Network Security Monitor (nyní známý jako Zeek) je spíše systémem detekce anomálií. Tam, kde Snort a Suricata pracují s tradičními signaturami IDS, Bro/Zeek využívá k analýze provozu skripty.

Významnou výhodou Bro/Zeek je, že tyto skripty umožňují také vysoce automatizované pracovní postupy mezi různými systémy, což je přístup, který umožňuje rozhodovat mnohem podrobněji než staré akce typu pass or drop. Jeho konfigurace však může být poměrně složitá.

Závěr

Existuje několik dobrých open-source možností IDS. Vzhledem k jejich odlišnostem však ne všechna řešení budou fungovat v každém prostředí. Výběr nejlepších produktů by měl vycházet z toho, jaké další, potenciálně se překrývající, bezpečnostní produkty jsou již zavedeny, jaký typ provozu prochází sítí, jaké je množství provozu a jaké dovednosti má k dispozici personál IT.

.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.