Kompletní průvodce implementací Netfilteru a Suricaty v Linuxu

Informatec Digital » Zdroje » Kompletní průvodce implementací Netfilteru a Suricaty v Linuxu

Pokud pracujete se sítěmi na GNU/Linuxu ( nejlepší linuxové distribuce z hlediska zabezpečení a soukromí ) a zajímá vás, jak jít nad rámec typického statického firewallu, pravděpodobně vás zajímá, jak zkombinovat Netfilter, NFQUEUE a Suricata a vytvořit tak skutečně flexibilní IDS/IPS, aniž byste museli utratit majlant za proprietární hardware. To je přesně oblast, kterou se v tomto článku budeme zabývat, a to propojením nízkoúrovňových prvků (jádro, fronty, C) s nástroji vysoké úrovně (Suricata, pravidla, MySQL, Memcached, pfSense).

Základní myšlenka je velmi silná: využít faktu, že jádro (viz návod na optimalizaci linuxového jádra ) může zařazovat pakety do uživatelského prostoru a nechat vlastní program rozhodnout, co s nimi má dělat. To lze využít pro filtrování provozu (pokročilý firewall, IPS), dynamické směrování nebo integraci obchodní logiky (databáze, mezipaměti, detekce útoků na webové aplikace, VoIP atd.). A pokud k tomu přidáme Suricatu jako víceprocesový engine IDS/IPS, máme velmi robustní kombinaci pro prostředí od laboratoří až po datová centra s vysokým provozem.

NFQUEUE a Netfilter: povýšení firewallu do uživatelského prostoru

V typickém systému GNU/Linux se pravidla Netfilter/iptables (nebo nftables) obvykle používají jako statické zásady, které se nacházejí výhradně v prostoru jádra . Frontendy a zařízení (včetně mnoha řešení založených na Netfilteru nebo BSD Packet Filteru) ukládají konfiguraci do textových, XML nebo SQLite souborů a když se něco změní, pravidla regenerují a znovu načtou. To je flexibilní, ale logika zůstává jakýmsi snímkem firewallu s drobnými dynamickými úpravami (limity připojení za sekundu, conntrack, porovnávání zemí, vrstva 7, pokud je k dispozici, atd.).

NFQUEUE navrhuje zásadní změnu: místo toho, aby konečné rozhodnutí vždy činilo jádro, můžeme toto rozhodnutí delegovat na uživatelský proces . Jádro zařadí paket do číslované fronty a aplikace používající knihovnu libnetfilter_queue jej načte, analyzuje a vrátí verdikt: přijmout, zahodit nebo dokonce označit pro směrování podle pravidel. Je to jako mít programovatelného „soudce“ napsaného v jazyce C, Pythonu nebo Perlu na firewallu.

Krása spočívá v tom, že náš program dokáže doslova cokoli chceme: dotazovat se na /dev/urandom, databázi, webovou službu, distribuovanou mezipaměť nebo sofistikovaný algoritmus, než odpoví jádru. Z architektonického hlediska firewall přestává být jednoduchou sadou statických pravidel a stává se kanálem, kde Netfilter, fronty a uživatelské aplikace zapadají do sebe jako dílky skládačky.

NFQUEUE se skládá ze dvou částí: cíle NFQUEUE v iptables , který odesílá pakety do specifické fronty, a uživatelské knihovny libnetfilter_queue , která umožňuje tyto pakety číst a vydávat verdikt. Nejedná se o jednoduchý sniffer jako tcpdump: zde máme možnost přímo rozhodnout o cestě, kterou se paket vydá.

Základní konfigurace iptables pomocí NFQUEUE

Z pohledu iptables je použití NFQUEUE poměrně přímočaré: do řetězce, který vás zajímá, přidáte pravidlo, které do fronty odešle pakety splňující určitá kritéria (zdrojová/cílová IP adresa, porty, stavy, další moduly, jako je GeoIP nebo layer7, pokud jsou k dispozici, atd.).

Například pokud chceme do NFQUEUE odeslat všechny pingy, které dorazí na samotný hostitel:

iptables -I INPUT -p icmp -j NFQUEUE

Toto odesílá příchozí ICMP pakety do fronty 0 (pokud není uvedeno jinak). Mohli bychom specifikovat další frontu s parametrem jako `--queue-num 3` . Při vypisování pravidel s čítači (`iptables -L -n -v -x`) uvidíme, že se čítače zvyšují, což značí, že pakety jsou zařazovány do fronty . Důležitý detail: pokud jsou ve frontě pakety a žádný uživatelský proces je nenačte a nezpracuje, výchozím chováním je jejich odmítnutí, takže selhání aplikace má za následek blokování provozu.

Programování proti libnetfilter_queue: „hello world“ v jazyce C

Pro připojení k frontě z uživatelského prostoru se používá knihovna libnetfilter_queue (která se zase spoléhá na libnfnetlink). V distribucích jako Debian jednoduše nainstalujte vývojářské balíčky:

apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc

Kostra minimálního programu, který vždy přijímá pakety, se skládá z několika velmi jasných kroků: otevření knihovny, odpojení všech existujících obslužných rutin, navázání na protokol AF_INET, vytvoření fronty s funkcí zpětného volání, definování režimu kopírování a vstup do smyčky příjmu . Zpětné volání se provede pro každý paket ve frontě, extrahuje ID a vrátí verdikt.

V praxi je postup zhruba tento: `nfq_open` pro získání handle, `nfq_unbind_pf` pro jeho vyčištění, `nfq_bind_pf` pro spojení s AF_INET, `nfq_create_queue` pro registraci callbacku ve frontě 0, `nfq_set_mode` pro indikaci, zda chceme metadata nebo celý paket, smyčka s `recv()` nad deskriptorem a `nfq_handle_packet` pro zpracování každého paketu . Po ukončení je fronta zničena pomocí `nfq_destroy_queue` a handle je uzavřen pomocí `nfq_close`.

Tento typ „hello world“ umožňuje čisté měření dopadu NFQUEUE. Pokud zkompilujeme příklad něčím jako:

gcc -o nftest code.c -lnfnetlink -lnetfilter_queue

A pokud zařadíme provoz z iperf do fronty (například TCP port 5001 v INPUT a OUTPUT), uvidíme, že kód, který jednoduše přijímá pakety, sotva ovlivňuje výkon v gigabitové síti . Je tu však klíčový detail: výpis informací ve zpětném volání (printf, fflush atd.) výrazně snižuje propustnost, jak je vidět při porovnání iperf s laděním obrazovky a bez něj.

Pokročilé možnosti NFQUEUE: bypass, balance a fail-open

NFQUEUE obsahuje několik zajímavých voleb iptables, které upravují výchozí chování front a které by měly být známy před vstupem do produkčního nebo vysoce výkonného prostředí, protože ovlivňují způsob zpracování selhání uživatelských aplikací nebo zaplňování front.

Příkaz `--queue-bypass` umožňuje zajistit, aby v případě, že žádný proces neposlouchá frontu, pakety nebyly zahozeny, ale místo toho byly přeposlány na další krok v řetězci iptables. To může být užitečné, pokud chcete, aby se systém „otevřel při selhání“, když uživatelská služba není k dispozici, i když z bezpečnostního hlediska je to dvousečná zbraň.

Volba `--queue-balance` umožňuje distribuovat pakety do určitého rozsahu front (například od 0 do 3) a poté nechat z každé fronty odebírat pakety více nezávislých procesů nebo vláken . Kód Netfilteru zajišťuje, že pakety ze stejného toku vždy skončí ve stejné frontě, což výrazně zjednodušuje udržování konzistence v rozhodovací logice.

Existuje také režim `--fail-open` , který řídí, co se stane, když se fronta zaplní, protože uživatelský proces běží příliš pomalu. Jeho povolení způsobí, že jádro bude přijímat pakety přímo, místo aby je zahazovalo, čímž se zabrání masivnímu narušení provozu. Opět to může být bezpečnostní problém, protože pokud chceme činit rozhodnutí případ od případu, ztráta rozhodovacích paketů znamená nesplnění tohoto cíle.

Pro sledování dění s frontami Netfilter zpřístupňuje informace v pseudo-fs /proc/net/netfilter/nfnetlink_queue , které lze snadno dotazovat ze skriptů nebo monitorovacích nástrojů.

Integrace obchodní logiky: testování s Memcached a MySQL

Jakmile je proces „hello world“ pod kontrolou, dalším přirozeným krokem je obohacení zpětného volání o volání externích systémů . Typický experiment zahrnuje rozhodování, zda přijmout nebo odmítnout paket na základě toho, zda se zdrojová IP adresa objevuje v nějakém backendu, jako je databáze MySQL nebo mezipaměť Memcached.

V případě Memcached se démon nainstaluje (apt-get install memcached) a do klíče, například authorized , se načte IP adresa, která nás zajímá. To lze provést jednoduchými příkazy echo a netcat a poté příkazem get ověřit, zda je hodnota správně uložena. Odtud program NFQUEUE kromě získání ID paketu přijme celý paket pomocí NFQNL_COPY_PACKET , extrahuje IP hlavičku (struct iphdr) a pomocí inet_ntop převede zdrojovou adresu na řetězec.

Aby se předešlo ztrátě času při otevírání spojení s každým paketem, je spojení Memcached inicializováno pouze jednou v hlavní metodě (memcached_create, memcached_server_list_append, memcached_server_push) a obslužná rutina je uložena v globálních proměnných. Při zpětném volání je volána metoda memcached_get s požadovaným klíčem, zdrojová IP adresa je porovnána s načtenou hodnotou a pokud se shodují, je vrácena hodnota NF_ACCEPT; v opačném případě je vrácena hodnota NF_DROP. Pokud klíč neexistuje nebo dojde k chybě, je paket zahozen v rámci konzervativní politiky.

Pomocí iperf tato strategie snižuje propustnost na přibližně 140 Mbit/s v gigabitové síti a je pozorováno, že ve frontě začínají docházet ke ztrátám (což je indikováno například symboly v samotném kódu). Jinými slovy, pouhé volání služby mezipaměti na paket již představuje značné náklady, i když při optimalizaci zůstává životaschopné i pro střední objemy provozu.

U MySQL je přístup podobný, ale složitější: nainstaluje se serverová a klientská knihovna, vytvoří se databáze (například nfqueue) s jednoduchou tabulkou s názvem authorized(ip varchar(50)) a vloží se povolená IP adresa. V programu se při spuštění spustí `mysql_init` a `mysql_real_connect` a ve zpětném volání se vytvoří dotaz typu `select * from authorized where ip like 'xxxx'`. Pokud se dotaz úspěšně provede a je nalezen řádek, balíček je přijat; jinak je zahozen.

S povoleným ukládáním dotazů do mezipaměti MySQL dosahují testy rychlosti okolo 188 Mbit/s , která klesá na 103 Mbit/s, když je ukládání dotazů do mezipaměti zakázáno. Tato čísla, i když zdaleka nejsou gigabity, ukazují, že i s nejméně elegantním přístupem (jednovláknový, bez optimalizace) lze zvládnout slušné objemy provozu pomocí rozhodnutí řízených databází nebo ukládáním do mezipaměti.

Výkon, multithreading a využití CPU

Testy s iperf, Memcached a MySQL jasně ukazují, že výkonnostní strop není dán ani tak samotným NFQUEUE, jako spíše logikou, kterou přidáváme do uživatelského prostoru , a způsobem, jakým ji implementujeme. Spustitelný soubor, který vrací pouze NF_ACCEPT, dosahuje téměř gigabitového výkonu bez větší námahy; jakmile zavedeme I/O nebo síťová volání, propustnost klesne a CPU počítače NFQUEUE, démona Memcached nebo MySQL je tlačeno na hranici svých možností.

Z architektonického hlediska to má dva důsledky. Na jedné straně to potvrzuje, že delegování rozhodnutí o firewallu na uživatelské aplikace u významných objemů provozu je naprosto proveditelné , za předpokladu, že se vezmou v úvahu skutečné náklady na každé volání. Na druhé straně to ukazuje, že pro dosažení maximálních možností platformy je nutné zvážit multithreading nebo multiprocessing . NFQUEUE umožňuje distribuci provozu do více front; mohli bychom spustit několik kopií naší aplikace, z nichž každá naslouchá jiné frontě, a využít více jader bez potíží s pthready nebo masivními forky.

Další zřejmou optimalizací by bylo omezit provoz procházející přes NFQUEUE . V testech byl celý tok iperf zařazen do fronty, ale v reálném scénáři bychom mohli zařadit do fronty pouze pakety se stavem NEW, povolit průchod paketům ESTABLISHED/RELATED a rezervovat drahou logiku pro přihlášení nebo podezřelé vzorce.

V konečném důsledku je klíčové využití CPU a návrh vláken: pokud uživatelský proces selže, fronta se zaplní a my se musíme uchýlit k věcem, jako je otevírání při selhání nebo přijímání odstraňování, čímž ztrácíme část jemné kontroly, o kterou tento přístup usiluje.

Dynamické směrování s brandingem Netfilter

NFQUEUE se neomezuje pouze na příkazy „přijmout“ nebo „vyhodit“. Lze jej také použít k aplikaci příznaků Netfilter (fwmark) na pakety a jejich kombinaci s pravidlem ip a iproute2 k vytvoření vysoce flexibilních, téměř lehkých schémat politického směrování ve stylu VRF.

Postup by v zásadě vypadal takto: definovat několik směrovacích tabulek v souboru /etc/iproute2/rt_tables , například slow a fast; přiřadit každé tabulce jinou výchozí trasu (jednu přes optické vlákno a druhou přes omezenější spojení); pomocí pravidla ip specifikovat, že pakety s fwmark 1 jdou do tabulky fast, pakety s fwmark 2 do slow atd.; a nakonec pomocí NFQUEUE označit pakety před vrácením verdiktu.

Pro nastavení verdiktu z callbacku se používá `nfq_set_verdict2` , což je podobné `nfq_set_verdict`, ale umožňuje nastavit hodnotu verdiktu, kterou pak `ip rule` uvidí. Kombinací toho všeho můžete vytvořit IP router, který rozhoduje, kam směrovat, na základě libovolných kritérií: od absurdních věcí, jako je sudá/lichá velikost paketu, až po externí vstupy, jako jsou algoritmy pro predikci provozu, události na sociálních sítích nebo signály z monitorovacích systémů.

Výsledkem je systém, ve kterém jádro pokračuje v přeposílání paketů obvyklou rychlostí, ale přesná cesta, kterou každý tok projde, je delegována na externí software , který může v reálném čase změnit názor, aniž by se dotýkal statických pravidel.

NFQUEUE a Suricata: Vysokoúrovňový IPS v GNU/Linuxu

Všechny výše uvedené lze naprogramovat ručně v jazyce C, ale pokud jde o detekci narušení a hloubkovou inspekci paketů, rozumnou možností je obvykle spoléhat se na vyspělý engine IDS/IPS . A právě zde přichází na řadu Suricata, která se zrodila právě jako víceprocesová alternativa k Snortu, s IPS funkcemi od samého začátku a silným zaměřením na využití mnoha dnes dostupných jader CPU.

Suricata je napsána od nuly a distribuována pod licencí GPLv2 ; Open Information Security Foundation (OISF) spravuje jak samotný engine, tak i poměrně komplexní ekosystém pravidel a dokumentace. Na rozdíl od Snortu 2.x, který zdědil jednovláknové jádro a byl na něj nainstalován patch, byla Suricata navržena tak, aby rozdělila pracovní zátěž mezi více vláken: zachycení, dekódování, detekci a výstup s různými strategiemi sdílení zátěže.

Na funkční úrovni poskytuje Suricata nativní podporu pro IPv6, inspekci vrstvy 7 (velmi pokročilý HTTP přes knihovnu HTP), rozpoznávání protokolů nezávislé na portech , rekonstrukci toku a velmi výkonný systém proměnných relace (flowbits) pro korelaci různých fází útoku rozprostřeného přes několik TCP spojení.

Další silnou stránkou je kompatibilita s pravidly Snort a schopnost používat sady signatur Sourcefire VRT i Emerging Threats (bezplatná verze ET Open a komerční verze ET Pro). Navíc exportuje události ve velmi užitečných formátech (fast.log, JSON v eve.json) pro integraci se systémy SIEM, ELK, Splunk a dalšími.

Suricata jako IPS v Linuxu: režimy snímání a NFQUEUE

V systémech GNU/Linux může Suricata fungovat v různých režimech v závislosti na způsobu zachycování provozu: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … Každý z nich má své výhody a požadavky. Na úrovni čistého IPS jsou dva nejdůležitější NFQUEUE a AF_PACKET.

V režimu NFQ (NFQUEUE) je postup podobný jako dříve: sada pravidel iptables odesílá pakety do fronty; Suricata běžící v uživatelském prostoru z této fronty čte, kontroluje obsah podle svých pravidel a vrací jádru verdikt: NF_ACCEPT, NF_DROP nebo NF_REPEAT. Třetí lze použít k opětovnému vložení paketu do stejné tabulky iptables po použití dalších značek nebo úprav.

Tento režim je velmi flexibilní a snadno implementovatelný ve stávajících infrastrukturách , protože vyžaduje úpravu pravidel pouze v konkrétních bodech (například FORWARD, INPUT, OUTPUT) a ponechání všeho ostatního tak, jak je. Nákladem je přidaná režie spojená s předáváním paketů nahoru a dolů přes NFQUEUE, s výše zmíněným dopadem, pokud je objem velmi vysoký nebo jsou pravidla náročná na zdroje.

V režimu AF_PACKET pracuje Suricata blíže k síťovému rozhraní a kopíruje pakety přes sockety AF_PACKET. Jedná se o mnohem rychlejší přístup s nulovou kopií , ale vyžaduje, aby systém fungoval jako brána se dvěma rozhraními a aby blokování provozu probíhalo na úrovni přesměrování mezi síťovými kartami: paket, který má být blokován, jednoduše není předáván ze vstupního rozhraní do výstupního rozhraní.

V obou režimech lze Suricatu kombinovat s Netfilterem, ale NFQUEUE se hodí obzvláště dobře v situacích, kdy chceme znovu použít veškerou logiku iptables (zásady, rozsahy, předchozí pravidla) a do Suricaty posílat pouze provoz, který chceme podrobněji prozkoumat.

Základní instalace Suricaty ze zdrojového kódu

Pro ty, kteří dávají přednost kompilaci Suricaty namísto použití balíčků, proces na distribucích typu Debian/Ubuntu zahrnuje nejprve instalaci kompilačních závislostí (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev atd.), stažení tarballu z oficiálních webových stránek a spuštění klasického příkazu ./configure, make, make install.

Během fáze konfigurace skript označí, které podpůrné funkce byly povoleny: AF_PACKET ano/ne, PF_RING, NFQUEUE ano/ne, NFLOG, IPFW, podpora pro libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP atd. Je důležité ověřit, zda je NFQUEUE povoleno, pokud chceme v tomto režimu pracovat , a zda byla nalezena knihovna pro zachycení, která nás zajímá.

Po instalaci binárního souboru můžete spustit příkaz `make install-conf` pro nasazení výchozí konfigurace do `/etc/suricata` a příkaz `make install-rules` pro stažení a umístění sady pravidel pro vznikající hrozby do `/etc/suricata/rules`. Tyto sady lze poté aktualizovat pomocí nástrojů jako `suricata-update`.

Na systémech Red Hat/CentOS je logika podobná, pro závislosti (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel atd.) se používá yum nebo dnf a následná kompilace se stejnými kroky. Z důvodu výkonu je také vhodné zakázat LRO/GRO v rozhraní pro zachycení pomocí ethtoolu, protože tyto funkce pro odlehčení zátěže mohou ovlivnit viditelnost balíčků na úrovni IDS.

Konfigurace Suricaty: YAML, proměnné a vlákna

Hlavní konfigurace Suricaty se nachází v souboru /etc/suricata/suricata.yaml . Jedná se o poměrně čitelný a hojně komentovaný soubor YAML, kde je definováno vše od cest k protokolům a sad pravidel až po cílové zásady operačního systému a parametry vláken.

Jedním ze základních polí je `default-log-dir` , které určuje, kam budou uloženy soubory protokolu (standardně `/var/log/suricata`). V sekci `vars` se nacházejí proměnné jako `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` a `SSH_PORTS`, které slouží v pravidlech jako zkratky. `HOME_NET` je obvykle konfigurováno s rozsahem lokální sítě, kterou chceme chránit, zatímco `EXTERNAL_NET` je obvykle definováno jako `!HOME_NET`.

Další důležitou součástí je host-os-policy , která sděluje Suricatě, který operační systém má používat určité rozsahy IP adres. To jí umožňuje upravit způsob, jakým znovu sestavuje TCP nebo interpretuje určité chování síťového stacku , což ztěžuje obcházení protokolů na základě rozdílů mezi stacky (Windows vs. Linux atd.). Konkrétní rozsahy lze přiřadit kategoriím, jako jsou Windows, Linux, BSD, Vista, Windows 2003 atd.

Pokud jde o vláknování, sekce vláknování umožňuje jemně doladit afinitu CPU a počet detekčních vláken. Ve výchozím nastavení je `set-cpu-affinity` obvykle zakázáno, což umožňuje systémovému plánovači distribuovat vlákna mezi jádra. Parametr `detect-thread-ratio` udává, kolik detekčních vláken je vytvořeno na jedno dostupné jádro; s `detect-thread-ratio: 1.5` na 8jádrovém počítači Suricata vygeneruje 12 detekčních vláken plus vlákna pro zachycení a správu.

Celý tento model se pak odráží ve výstupu při spuštění démona: viditelné je vlákno pro zachycení (například pcap) a několik vláken pro detekci, kromě správců toku a správců statistik. Tato víceprocesová architektura umožňuje Suricatě mnohem lépe škálovat než jednovláknové enginy při práci s linkami o rychlosti 10/40 Gbit/s.

Aktualizace pravidel a podpisů v Suricata

Suricata se spoléhá na sady pravidel k detekci vzorců útoků, anomálního chování a zneužití protokolů. Kromě přijímání pravidel ve formátu Snort je nejběžnějším ekosystémem ekosystém Emerging Threats: ET Open (zdarma) a ET Pro (komerční), s pravidly zaměřenými na aktuální hrozby.

Mnoho moderních distribucí obsahuje nástroj `suricata-update` , který zjednodušuje správu pravidel: aktualizuje zdroje, povoluje nebo zakazuje konkrétní poskytovatele a stahuje nejnovější verze sad podpisů. Typický pracovní postup by byl nainstalovat `suricata-update` (například přes pip), spustit první `suricata-update` pro stažení ET Open, vypsat zdroje pomocí `suricata-update list-sources`, povolit další zdroje, jako například `ptresearch/attackdetection`, `oisf/trafficid` nebo `sslbl/ssl-fp-blacklist`, a znovu spustit `suricata-update` pro regeneraci souboru s pravidly.

Soubor suricata.yaml je upraven tak, aby ukazoval na správnou cestu k pravidlům, a odtud Suricata začne vyvolávat upozornění, která budou zaznamenávána do souborů fast.log (rychlý, čitelný text) a eve.json (strukturovaný JSON s velmi úplnými informacemi) . Tento druhý formát je obzvláště užitečný pro zobrazování informací v dashboardech, korelačních systémech nebo vlastních skriptech.

Kromě podpisů obsahuje Suricata dekodéry a parsery pro více protokolů , což jí umožňuje menší závislost na portech: dokáže identifikovat HTTP provoz, i když prochází nestandardními porty, detekovat SSH, TLS, DNS atd. přes různé porty a úrovně zapouzdření (včetně smíšených tunelů IPv4/IPv6).

Praktické využití: od detekce webových exploitů až po automatické blokování

Jedním z nejžádanějších případů použití v hostingových prostředích nebo datových centrech je detekce pokusů o zneužití zranitelností ve webových aplikacích (např. WordPress a jeho pluginy) v reálném čase a automatická reakce, obvykle blokováním nebo zařazením zdrojové IP adresy na černou listinu ve firewallu.

Suricata, poháněná aktualizovanými pravidly, je schopna rozpoznávat specifické vzory útoků proti URL, parametrům, HTTP datům a dokonce i sekvencím požadavků, které odpovídají známým exploitům. IDS může fungovat v pasivním režimu a přijímat provoz prostřednictvím zrcadlení z portu přepínače (SPAN), ale aby fungoval jako IPS a blokoval útoky, musí být integrován s rovinou pro přesměrování.

Existují dva běžné přístupy: nastavení IDS jako online mostu, takže provoz fyzicky prochází strojem (pomocí iptables, AF_PACKET nebo PF, v závislosti na platformě), nebo ponechání topologie tak, jak je, ale kombinace zrcadlení s akcemi na centrálním firewallu prostřednictvím API, skriptů nebo NFQUEUE . První přístup minimalizuje latenci mezi detekcí a blokováním za cenu přidání dalšího prvku „uprostřed“ sítě; druhý nabízí větší flexibilitu a odolnost, ale zavádí větší složitost orchestrace.

Pro systém detekce narušení (IDS) je naprosto proveditelné odhalit pokus o zneužití zranitelného pluginu WordPressu a poté, buď přímo, nebo prostřednictvím přidružené komponenty, přidat IP adresu útočníka na blacklist iptables. Toho lze dosáhnout pomocí JSON výstupu Suricaty a skriptů, které volají iptables/nftables , nebo delegováním části logiky na NFQUEUE, kde samotný engine nebo přidružený proces provádí rozhodnutí za chodu, aniž by čekal na aktualizaci externího seznamu.

To vám umožňuje zaměřit se na hrozby, na kterých skutečně záleží (exploity, pokusy o eskalaci, velmi agresivní skenování), a ignorovat nebo jednoduše zaznamenávat šum na pozadí, jako jsou základní skenování portů, které v mnoha kontextech samo o sobě není znepokojivé.

Suricata na Pfsense: opensource firewall s integrovaným IDS/IPS

Ne každý si může nebo chce dovolit proprietární špičkový firewall, jako je ten v Palo Alto. V mnoha prostředích je atraktivnější nastavit open-source řešení s pfSense a Suricata , které pokrývá jak pokročilé potřeby firewallů (multi-WAN, VLAN, VPN, NAT atd.), tak i IDS/IPS.

Pfsense, založený na FreeBSD a Packet Filteru, funguje obzvláště dobře s virtualizovanými prostředími (Proxmox, KVM atd.), s výjimkou doporučení používat v KVM strojích karty E1000 místo Virtio, pokud se chcete vyhnout problémům s výkonem a pádům při zátěži, pokud nepoužijete doporučení Netgate (zakázat odlehčení kontrolního součtu hardwaru v Systém > Upřesnit > Sítě a restartovat s vědomím, že to při velmi vysoké zátěži nemusí stačit).

Minimální hardwarové požadavky pro laboratoř se Suricatou na Pfsense mohou být skromné ​​(1 CPU 500 MHz, 1 GB RAM, 4 GB disk), ale pro seriózní použití se doporučují alespoň 2 CPU, 4 GB RAM a 16 GB úložiště , přičemž nesmíme zapomenout na několik síťových rozhraní (jedno pro WAN, druhé pro LAN, více, pokud chcete více WAN nebo složité VLAN).

Instalace samotného pfSense je velmi rychlá: nabootujete z ISO, přijmete licenci, zvolíte instalaci, vyberete jazyk a rozložení klávesnice, necháte automatické rozdělení disku (Auto UFS, pokud budete používat celý disk) a během několika minut je systém připraven k prvnímu spuštění. Konzole nabízí menu pro přiřazení rozhraní, restart, spuštění shellu atd.

V laboratoři, například ve VirtualBoxu, je běžné dočasně vypnout firewall Pfsense z konzole pomocí pfctl -d, aby bylo možné přistupovat k webovému rozhraní přes WAN (uživatelské jméno admin, heslo pfsense) a dokončit úvodní průvodce: obecná data, NTP servery, konfigurace WAN (v laboratoři obvykle postačí DHCP), LAN, změna hesla administrátora a aplikace konfigurace.

Jakmile je přístup stabilizován, můžete v bráně firewall sítě WAN vytvořit pravidlo, které povolí HTTPS z libovolného zdroje na IP adresu pfsense, a přidat popisné oddělovače pro vizuální uspořádání pravidel (například „Přístup k bráně firewall“). Je také vhodné zakázat možnost blokování privátních sítí v síti WAN, pokud se nacházíte v testovacím prostředí s adresami RFC1918, abyste se vyhnuli neustálému používání příkazu `pfctl -d`.

Instalace Suricaty na pfSense a přehled

S nainstalovanou a spuštěnou základnou pfSense je instalace Suricaty stejně jednoduchá jako přechod do Systém > Správce balíčků > Dostupné balíčky , vyhledání Suricaty a instalace balíčku. Proces stáhne několik souborů a může chvíli trvat v závislosti na vašem hardwaru, ale je plně podporován prostřednictvím webového rozhraní.

Po instalaci se na kartě Služby zobrazí položka Suricata, kde můžete konfigurovat instance podle rozhraní (WAN, LAN, VLAN atd.), vybrat, které sady pravidel se mají použít, aktivovat režim IDS nebo IPS a upravit parametry výkonu a protokolování. Nabídka možností je rozsáhlá (dostatečná na celé články o konfiguraci), ale výhodou je, že mnoho úkolů, které v Linuxu vyžadují ruční úpravu YAML, se zde řeší pomocí formulářů a zaškrtávacích políček.

Důležitá poznámka: I když v laboratorním prostředí může být lákavé otevřít administraci pfSense přímo na internet, v produkčním prostředí je zásadní omezit přístup na statické IP adresy, používat VPN pro vzdálenou správu a za každou cenu se vyhnout ponechání webové konzole odkryté . pfSense je velmi flexibilní, ale je třeba s ním také zacházet jako s klíčovým prvkem, kterým je.

S povolenou Suricatou na pfSense získáte prostředí, kde provoz prochází přes pfSense kvůli firewallu a NATu a Suricata jej kontroluje podle svých pravidel a může jej blokovat v režimu IPS . Tato kombinace, spravovaná z jednoho webového rozhraní, výrazně zjednodušuje nasazení ochrany DPI v malých a středních sítích.

V mnoha nasazeních je to doplněno propojením Pfsense/Suricata se systémem SIEM nebo centralizovanou platformou protokolování, což využívá strukturované výstupní formáty ke korelaci událostí a detekci širších kampaní.

Monitorování událostí a příklady protokolů v Suricata

Jakmile je Suricata spuštěna, události se zaznamenávají do cesty definované parametrem default-log-dir, obvykle /var/log/suricata . Soubor fast.log používá kompaktní textový formát s časovými razítky, ID pravidel, klasifikacemi a prioritou, vhodný pro rychlou kontrolu z terminálu (tail -f).

Například při setkání s provozem s nesprávnými kontrolními součty TCP se mohou zobrazit řádky podobné těmto: časová razítka s datem a časem, následovaná identifikátorem pravidla (např. 1:2200074:1), zprávou „SURICATA TCPv4 invalid checksum“ (neplatný kontrolní součet SURICATA TCPv4), klasifikací, prioritou a párem IP/port zdroj-cíl. Tyto typy upozornění umožňují rychlou identifikaci problémů s integritou paketů nebo pokusů o vyhnutí se kontrole.

Soubor eve.json obsahuje stejné události ve formátu JSON s poli jako timestamp, event_type, src_ip, dest_ip, src_port, dest_port, proto a podsouborem upozornění s parametry action, gid, signature_id, rev, signature, category a severity. Tento formát lze snadno ingestovat pomocí Logstash, Fluentd, Filebeat nebo jakéhokoli jiného agenta protokolování , což umožňuje mnohem bohatší analýzu než pouhé použití prostého textu.

Při nasazení Suricaty na vícejádrový server (např. 8 jader) je komprese vláken snadno patrná v nástrojích jako htop v režimu vláken, kde se zobrazuje jedno nebo více zachycovacích vláken (pcap, AF_PACKET nebo NFQ) a velký počet detekčních vláken rozložených mezi jádry. Úprava poměru detekčních vláken a afinity CPU může významně ovlivnit propustnost a latenci, když se objem provozu blíží limitům platformy.

Před nasazením do produkčního prostředí je vhodné věnovat nějaký čas doladění aktivovaných sad pravidel , abyste se vyhnuli záplavě falešně pozitivních výsledků, které by mohly blokovat legitimní provoz nebo zahlcovat protokoly. Suricata-update umožňuje deaktivovat celé kategorie nebo jednotlivá pravidla a najít tak rozumnou rovnováhu mezi citlivostí a použitelností.

Speciální aplikace: VoIP, audio analýza a kreativní NFQUEUE

Kromě klasických použití (ochrana webových služeb, detekce malwaru, analýza DDoS) umožňuje duo Netfilter+NFQUEUE poměrně kreativní řešení v oblastech, jako je VoIP. Je například možné nastavit filtr anti-SPIT (spam přes IP telefonii) nebo systém pro cenzuru vulgarismů v RTP streamech.

Myšlenka by byla: identifikovat RTP provoz podle portů nebo rozpoznávání protokolu a odeslat jej do NFQUEUE; z uživatelské aplikace rekonstruovat RTP stream pomocí knihovny jako librtp , extrahovat zvuk ve formátu WAV a předat ho enginu pro rozpoznávání klíčových slov (wordspotting), jako je například knihovna pro syntézu nebo rozpoznávání nabízená třetí stranou.

Na základě detekovaných slov by se proces NFQUEUE mohl rozhodnout, zda povolit, zablokovat nebo dokonce změnit přehrávání vložením pípnutí do streamu, ačkoli to vyžaduje velmi jemné ovládání RTCP, sekvencí paketů a časování – téměř přístup „man-in-the-middle“. Není to triviální, ale teoreticky je to bez problémů dosažitelné využitím stejného systému front a verdiktů.

Je pravda, že část z toho by se dala provést jednoduchým snifferem, který by poskytoval data externímu procesoru a následně by reagoval na SIP signalizaci nebo prostřednictvím SBC (Asterisk, Kamailio atd.). Rozdíl oproti použití NFQUEUE spočívá v tom, že akce na tok RTP může být okamžitá a přímá , bez nutnosti koordinovat více komponent nebo čekat na dokončení hovoru signalizační vrstvou.

Tyto scénáře jasně ilustrují potenciál kombinace GNU/Linux + Netfilter + Suricata + knihoven třetích stran: nejde jen o blokování portů a IP adres, ale o orchestraci komplexních rozhodnutí o provozu v reálném čase s využitím ekosystému 100% svobodného softwaru.

Při pohledu na celou cestu, od malého programu v jazyce C, který vždy přijímá pakety, až po víceprocesové nasazení Suricata integrované s NFQUEUE, Pfsense, databázemi a mezipaměťmi, lze ocenit flexibilitu, kterou tento technologický stack nabízí pro budování všeho od jednoduchých dynamických firewallů až po architektury IDS/IPS v datových centrech, se skutečně hloubkovými možnostmi inspekce a automatizovanou reakcí na stále složitější útoky.