- Az NFQUEUE lehetővé teszi a Netfilter számára, hogy a szűrési és jelölési döntéseket felhasználói térbeli folyamatokra delegálja, lehetővé téve a dinamikus IP-tűzfalak és útválasztók használatát.
- A Suricata egy többfolyamatos IDS/IPS motort biztosít, amely támogatja az NFQUEUE, az AF_PACKET és a Snort, valamint az Emerging Threats kompatibilis szabályokat.
- Az NFQUEUE Suricata, adatbázisok, Memcached vagy Pfsense integrálása lehetővé teszi fejlett biztonsági és útválasztási megoldások kiépítését ingyenes szoftverekkel.
- A teljesítmény nagymértékben függ a száltervezéstől és a felhasználói tér logikájától, ezért kulcsfontosságú a vizsgálandó forgalom optimalizálása és gondos kiválasztása.
Ha GNU/Linux ( a legjobb Linux disztribúciók biztonság és adatvédelem szempontjából ) hálózatokkal dolgozol , és szeretnél túllépni a tipikus statikus tűzfalon, akkor valószínűleg kíváncsi vagy arra, hogyan kombinálhatod a Netfiltert, az NFQUEUE-t és a Suricata-t egy valóban rugalmas IDS/IPS létrehozásához anélkül, hogy vagyonokat költenél saját hardverre. Pontosan ezt a területet fogjuk feltárni ebben a cikkben, az alacsony szintű elemek (kernel, queues, C) és a magas szintű eszközök (Suricata, szabályok, MySQL, Memcached, pfSense) ötvözésével.
Az alapötlet nagyon erőteljes: kihasználni azt a tényt, hogy a kernel (lásd, hogyan optimalizálható a Linux kernel ) képes csomagokat sorba állítani a felhasználói térben, és hagyni, hogy egy egyéni program döntsön velük. Ez felhasználható forgalomszűrésre (fejlett tűzfal, IPS), dinamikus útválasztásra vagy üzleti logika integrálására (adatbázisok, gyorsítótárak, webes alkalmazástámadás-észlelés, VoIP stb.). És ha ehhez hozzáadjuk a Suricata-t, mint többfolyamatos IDS/IPS motort, akkor egy nagyon robusztus kombinációt kapunk a laboratóriumoktól a nagy forgalmú adatközpontokig terjedő környezetekhez.
NFQUEUE és Netfilter: a tűzfal felhasználói térbe emelése
Egy tipikus GNU/Linux rendszerben a Netfilter/iptables (vagy nftables) szabályokat általában statikus szabályzatként használják, amelyek teljes egészében a kernel térben helyezkednek el . A frontendek és az eszközök (beleértve a Netfilteren vagy a BSD Packet Filterén alapuló számos megoldást) szöveges, XML vagy SQLite fájlokban tárolják a konfigurációt, és amikor valami megváltozik, újragenerálják és újratöltik a szabályokat. Ez rugalmas, de a logika a tűzfal egyfajta pillanatképe marad kisebb dinamikus módosításokkal (másodpercenkénti kapcsolatok számának korlátozása, conntrack, országegyeztetés, 7. réteg, ha elérhető, stb.).
Az NFQUEUE egy forradalmi újítást javasol: ahelyett, hogy mindig a kernel hozza meg a végső döntést, ezt a döntést delegálhatjuk egy felhasználói folyamatra . A kernel egy számozott sorban állítja sorba a csomagot, és egy, a libnetfilter_queue könyvtárat használó alkalmazás visszakeresi, elemzi, és visszaad egy ítéletet: elfogadja, elveti, vagy akár megjelöli a szabályzat szerinti útvonalválasztáshoz. Ez olyan, mintha egy programozható "bíró" lenne a tűzfal tetején, C, Python vagy Perl nyelven írva.
Ennek a szépsége abban rejlik, hogy a programunk szó szerint bármit megtehet, amit csak akarunk: lekérdezheti a /dev/urandom könyvtárat, egy adatbázist, egy webszolgáltatást, egy elosztott gyorsítótárat vagy egy kifinomult algoritmust, mielőtt válaszolna a kernelnek. Architekturális szempontból a tűzfal megszűnik statikus szabályok egyszerű halmaza lenni, és egy olyan folyamattá válik, ahol a Netfilter, a várólisták és a felhasználói alkalmazások egy kirakós darabjaiként illeszkednek egymáshoz.
Az NFQUEUE két részből áll: az iptables NFQUEUE célfüggvényéből , amely a csomagokat egy adott várólistára küldi, és a libnetfilter_queue felhasználói könyvtárból , amely lehetővé teszi a csomagok beolvasását és egy ítélet kiadását. Ez nem egy egyszerű szimatoló kereső, mint a tcpdump: itt közvetlenül eldönthetjük, hogy a csomag milyen útvonalat kövessen.
Az iptables alapvető konfigurációja NFQUEUE segítségével
Az iptables szempontjából az NFQUEUE használata meglehetősen egyszerű: hozzáadsz egy szabályt a kívánt lánchoz, amely a bizonyos kritériumoknak (forrás/cél IP, portok, állapotok, extra modulok, például GeoIP vagy layer7, ha elérhető, stb.) megfelelő csomagokat küldi a várólistára.
Például, ha az NFQUEUE-nak szeretnénk elküldeni az összes ping-et, ami magára a gazdagépre érkezik:
iptables -I INPUT -p icmp -j NFQUEUE
Ez a funkció a bejövő ICMP csomagokat a 0. várólistába küldi (hacsak másképp nincs megadva). Megadhatunk egy másik várólistát is, például a `--queue-num 3` paraméterrel . Amikor a számlálókkal listázzuk a szabályokat (`iptables -L -n -v -x`), a számlálók száma növekedni fog, ami azt jelzi, hogy a csomagok sorba vannak állítva . Fontos részlet: ha vannak csomagok a sorban, és egyetlen felhasználói folyamat sem kéri le és nem dolgozza fel azokat, akkor az alapértelmezett viselkedés az elutasításuk, így egy alkalmazáshiba szándékosan a forgalom blokkolását eredményezi.
Programozás a libnetfilter_queue ellen: a „hello world” C nyelven
A felhasználói területről a sorhoz való csatlakozáshoz a libnetfilter_queue könyvtárat használjuk (ami viszont a libnfnetlink-re támaszkodik). A Debianhoz hasonló disztribúciókon egyszerűen telepítsük a fejlesztői csomagokat:
apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc
Egy minimális, csomagokat mindig elfogadó program váza néhány nagyon egyértelmű lépésből áll: megnyitjuk a függvénykönyvtárat, leválasztjuk a meglévő kezelőket, csatlakozunk az AF_INET protokollhoz, létrehozzuk a várólistát egy visszahívó függvénnyel, definiáljuk a másolási módot, és belépünk egy fogadó ciklusba . A visszahívás minden várólistán lévő csomagra végrehajtódik, kinyeri az azonosítót és visszaadja az eredményt.
A gyakorlatban a folyamat nagyjából így néz ki: `nfq_open` a handle lekéréséhez, `nfq_unbind_pf` a törléséhez, `nfq_bind_pf` az AF_INET-hez való társításhoz, `nfq_create_queue` a visszahívás regisztrálásához a 0. várólistában, `nfq_set_mode` annak jelzésére, hogy a metaadatokat vagy a teljes csomagot szeretnénk-e, egy ciklus a `recv()`-vel a leíró felett, és `nfq_handle_packet` az egyes csomagok feldolgozásához . Kilépéskor a sort az `nfq_destroy_queue`-val megsemmisítjük, a handle-t pedig az `nfq_close`-szal lezárjuk.
Ez a fajta „hello world” lehetővé teszi az NFQUEUE hatásának egyértelmű mérését. Ha a példát valami ilyesmivel fordítjuk le:
gcc -o nftest kód.c -lnfnetlink -lnetfilter_queue
És ha egy iperf-ből érkező forgalmat sorba állítjuk (például az INPUT és OUTPUT TCP 5001-es portját), látni fogjuk, hogy a csomagokat egyszerűen elfogadó kód alig befolyásolja a teljesítményt egy gigabites hálózaton . Van azonban egy fontos részlet: az információk kinyomtatása a visszahívásban (printf, fflush stb.) jelentősen rontja az átviteli sebességet, amint az a képernyő-hibakereséssel és anélkül végzett iperf összehasonlításakor is látható.
Speciális NFQUEUE opciók: bypass, kiegyenlítés és hibajelzéses nyitás
Az NFQUEUE számos érdekes iptables opciót tartalmaz, amelyek módosítják a várólisták alapértelmezett viselkedését, és amelyeket érdemes ismerni egy éles vagy nagy teljesítményű környezetbe való belépés előtt, mivel ezek befolyásolják a felhasználói alkalmazások hibáinak vagy a várólista feltöltődésének kezelését.
A `--queue-bypass` parancs lehetővé teszi, hogy ha egyetlen folyamat sem figyeli a várólistát, a csomagok ne dobódjanak el, hanem továbbítódjanak az iptables lánc következő ugrására. Ez akkor lehet hasznos, ha azt szeretnéd, hogy a rendszer "megnyitáskor hibát jelezzen", amikor a felhasználói szolgáltatás nem érhető el, bár biztonsági szempontból ez egy kétélű fegyver.
A `--queue-balance` opció lehetővé teszi a csomagok elosztását egy sor várakozási sor között (például 0-tól 3-ig), majd több független folyamat vagy szál felhasználását az egyes várakozási sorokból . A Netfilter kódja biztosítja, hogy az ugyanabból a folyamatból származó csomagok mindig ugyanabba a várakozási sorba kerüljenek, ami nagyban leegyszerűsíti a döntési logika konzisztenciájának fenntartását.
Létezik még a `--fail-open` mód is , amely azt szabályozza, hogy mi történjen, ha a sor megtelik, mert a felhasználói folyamat túl lassan fut. Engedélyezése azt eredményezi, hogy a kernel közvetlenül fogadja a csomagokat ahelyett, hogy eldobná őket, megakadályozva ezzel a hatalmas forgalmi fennakadásokat. Ez ismét biztonsági kérdés lehet, mert ha eseti alapon akarunk döntéseket hozni, a döntési csomagok elvesztése azt jelenti, hogy nem érjük el ezt a célt.
A sorokkal kapcsolatos események monitorozásához a Netfilter információkat tesz elérhetővé a /proc/net/netfilter/nfnetlink_queue pszeudo-fs fájlban , amely könnyen lekérdezhető szkriptekből vagy monitorozó eszközökből.
Üzleti logika integrálása: tesztelés Memcacheddel és MySQL-lel
Miután a „hello world” folyamat irányítása alá került, a következő természetes lépés a visszahívás bővítése külső rendszerek felé irányuló hívásokkal . Egy tipikus kísérlet során eldöntjük, hogy elfogadunk-e vagy elutasítunk-e egy csomagot az alapján, hogy a forrás IP-cím megjelenik-e valamilyen háttérrendszerben, például egy MySQL adatbázisban vagy egy Memcached gyorsítótárban.
A Memcached esetében a démon telepítésre kerül (apt-get install memcached), és egy kulcs, például az authorized , betöltődik a minket érdeklő IP-címmel. Ezt egy egyszerű echo és netcat paranccsal tehetjük meg, majd egy get paranccsal ellenőrizhetjük, hogy az érték helyesen van-e tárolva. Innen az NFQUEUE program a csomagazonosító lekérése mellett az NFQNL_COPY_PACKET segítségével fogadja a teljes csomagot , kinyeri az IP-fejlécet (struct iphdr), és az inet_ntop segítségével karakterlánccá alakítja a forráscímet.
Annak érdekében, hogy ne kelljen időt pazarolni a kapcsolatok megnyitására minden egyes csomaggal, a Memcached kapcsolat csak egyszer inicializálódik a fő metódusban (memcached_create, memcached_server_list_append, memcached_server_push), és a kezelő globális változókban tárolódik. A visszahívás során a memcached_get metódust hívja meg a kívánt kulccsal, a forrás IP-címet összehasonlítja a lekért értékkel, és ha egyeznek, akkor NF_ACCEPT értéket ad vissza; egyébként NF_DROP értéket ad vissza. Ha a kulcs nem létezik, vagy hiba van, a csomag konzervatív irányelvként eldobásra kerül.
Az iperf használatával ez a stratégia körülbelül 140 Mbit/s-ra csökkenti az átviteli sebességet egy gigabites hálózaton , és megfigyelhető, hogy a sorban veszteségek kezdenek jelentkezni (amit például a kódon belüli szimbólumok jeleznek). Más szóval, a gyorsítótár-szolgáltatás csomagonkénti hívása már önmagában is jelentős költséggel jár, bár közepes forgalmi volumen esetén optimalizálva továbbra is életképes.
A MySQL esetében a megközelítés hasonló, de összetettebb: telepítik a szerver és a kliens könyvtárat, létrehoznak egy adatbázist (például nfqueue) egy egyszerű, authorized(ip varchar(50)) nevű táblával, és beillesztik az engedélyezett IP-címet. A programban a `mysql_init` és a `mysql_real_connect` futnak indításkor, a visszahívás során pedig egy `select * from authorized where ip like 'xxxx'` típusú lekérdezést konstruálnak. Ha a lekérdezés sikeresen végrehajtódik és talál egy sort, a csomag elfogadásra kerül; ellenkező esetben eldobásra kerül.
Engedélyezett MySQL lekérdezések gyorsítótárazásával a tesztek körülbelül 188 Mbit/s-ot eredményeznek, ami 103 Mbit/s -ra csökken, ha a lekérdezések gyorsítótárazása le van tiltva. Ezek az adatok, bár messze nem gigabitesek, azt mutatják, hogy még a legkevésbé elegáns megközelítéssel (egyszálú, optimalizálás nélkül) is tiszteletre méltó forgalommennyiség kezelhető adatbázis-vezérelt vagy gyorsítótárazáson alapuló döntésekkel.
Teljesítmény, többszálú működés és CPU-használat
Az iperf, Memcached és MySQL tesztek egyértelműen azt mutatják, hogy a teljesítménykorlátot nem annyira maga az NFQUEUE határozza meg, mint inkább a felhasználói térben hozzáadott logika és annak megvalósítási módja. Egy olyan futtatható fájl, amely csak NF_ACCEPT értéket ad vissza, majdnem egy gigabitet ér el könnyedén; amint bevezetjük az I/O vagy hálózati hívásokat, az átviteli sebesség visszaesik, és az NFQUEUE gép, a Memcached démon vagy a MySQL CPU-ja a határaira feszül.
Architekturális szempontból ennek két következménye van. Egyrészt megerősíti, hogy a tűzfallal kapcsolatos döntések felhasználói alkalmazásokhoz való delegálása jelentős forgalom esetén tökéletesen megvalósítható , feltéve, hogy figyelembe vesszük az egyes hívások tényleges költségeit. Másrészt azt mutatja, hogy a platform maximális képességeinek eléréséhez figyelembe kell venni a többszálú működést vagy a többfeldolgozást . Az NFQUEUE lehetővé teszi a forgalom elosztását több várakozási sor között; elindíthatnánk az alkalmazásunk több példányát, amelyek mindegyike egy másik várakozási sort figyel, és több magot is kihasználhatnánk a pthreadek vagy a hatalmas elágazások gondjai nélkül.
Egy másik kézenfekvő optimalizálás az lenne, hogy korlátozzuk, melyik forgalom haladhat át az NFQUEUE-n . A tesztekben a teljes iperf folyamat sorba volt állítva, de egy valós helyzetben csak az NEW állapotú csomagokat állíthattuk sorba, engedélyezhettük a LÉTREHOZOTT/KAPCSOLÓDÓ csomagok áthaladását, és a költséges logikát bejelentkezésekre vagy gyanús mintákra tarthattuk fenn.
Végső soron a CPU-használat és a száltervezés kulcsfontosságú: ha a felhasználói folyamat nem megfelelő, a sor megtelik, és olyan dolgokhoz kell folyamodnunk, mint a hiba utáni megnyitás vagy az elfogadás utáni eldobások, elveszítve ezzel a megközelítés által megcélzott finom kontroll egy részét.
Dinamikus útválasztás Netfilter márkajelzéssel
Az NFQUEUE nem korlátozódik az „elfogadás” vagy a „dobás” egyszerű kimondására. Használható Netfilter (fwmark) jelzők csomagokra való alkalmazására is, és ezek kombinálására az ip szabállyal és az iproute2-vel, így rendkívül rugalmas, szinte pehelykönnyű, VRF-stílusú politikai útválasztási sémákat hozhatunk létre.
Az eljárás nagy vonalakban a következő lenne: definiáljunk több irányítótáblát az /etc/iproute2/rt_tables fájlban , például egy slow és egy fast táblát; rendeljünk minden táblához egy eltérő alapértelmezett útvonalat (egyet optikai szálon, egy másikat egy korlátozottabb kapcsolaton keresztül); használjuk az ip szabályt annak megadására, hogy az 1-es fwmark értékű csomagok a fast táblába, a 2-es fwmark értékűek a slow táblába stb. kerüljenek; és végül az NFQUEUE használatával jelöljük meg a csomagokat megfelelően, mielőtt visszaadnánk az eredményt.
A visszahívásból származó verdikt beállításához az `nfq_set_verdict2` függvényt használjuk , ami hasonló az `nfq_set_verdict`-hez, de lehetővé teszi egy verdiktérték beállítását, amelyet az `ip rule` ezután látni fog. Mindezek kombinálásával egy olyan IP-útválasztót építhetünk, amely tetszőleges kritériumok alapján dönti el, hová irányítson: az olyan abszurd dolgoktól, mint a páros/páratlan csomagméret, a külső bemenetekig, mint a forgalom-előrejelző algoritmusok, a közösségi média események vagy a megfigyelőrendszerekből származó jelek.
Az eredmény egy olyan rendszer, amelyben a kernel továbbra is a szokásos sebességgel továbbítja a csomagokat, de az egyes folyamatok pontos útvonalát külső szoftvernek delegálja, amely valós időben meggondolhatja magát a statikus szabályok megváltoztatása nélkül.
NFQUEUE és Suricata: Magas szintű IPS GNU/Linuxban
A fentiek mindegyike kézzel programozható C nyelven, de behatolásérzékelés és mély csomagvizsgálat esetén az ésszerű megoldás általában egy kiforrott IDS/IPS motorra hagyatkozni . Itt jön képbe a Suricata, amely pontosan a Snort többfolyamatos alternatívájaként született, kezdettől fogva IPS-képességekkel, és nagy hangsúlyt fektet a ma elérhető számos CPU-mag kihasználására.
A Suricata a nulláról íródott és GPLv2 licenc alatt kerül terjesztésre ; az Open Information Security Foundation (OISF) tartja fenn mind a motort, mind a szabályok és dokumentáció meglehetősen átfogó ökoszisztémáját. A Snort 2.x-szel ellentétben, amely egy egyszálú magot örökölt, és arra lett frissítve, a Suricata úgy lett kialakítva, hogy a munkaterhelést több szál között ossza meg: rögzítés, dekódolás, észlelés és kimenet, különböző terhelésmegosztási stratégiákkal.
Funkcionális szinten a Suricata natív IPv6-támogatást, 7. rétegbeli vizsgálatot (nagyon fejlett HTTP HTP könyvtáron keresztül), portoktól független protokollfelismerést , folyamatrekonstrukciót és egy nagyon hatékony munkamenet-változók (folyamatbitek) rendszerét biztosítja a több TCP-kapcsolaton átívelő támadás különböző szakaszainak korrelálására.
További erőssége a Snort szabályokkal való kompatibilitás , valamint a Sourcefire VRT és az Emerging Threats szignatúrakészletek (az ingyenes ET Open és a kereskedelmi ET Pro verziók) használatának képessége. Továbbá nagyon hasznos formátumokban exportálja az eseményeket (fast.log, JSON az eve.json fájlban) a SIEM-ekkel, ELK-val, Splunk-kal és más rendszerekkel való integrációhoz.
Suricata, mint IPS Linuxban: rögzítési módok és NFQUEUE
GNU/Linux rendszeren a Suricata különböző módokban működhet attól függően, hogy hogyan fogja el a forgalmat: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … Mindegyiknek megvannak a maga előnyei és követelményei. A tiszta IPS szintjén a két legfontosabb az NFQUEUE és az AF_PACKET.
NFQ (NFQUEUE) módban a folyamat hasonló a korábban leírtakhoz: egy iptables szabálykészlet csomagokat küld egy várakozási sorba; a felhasználói tárhelyen futó Suricata beolvassa a sorból az adatokat, a szabályoknak megfelelően megvizsgálja a tartalmat, és egy eredményt ad vissza a kernelnek: NF_ACCEPT, NF_DROP vagy NF_REPEAT. A harmadik móddal további jelek vagy módosítások alkalmazása után a csomag újra beilleszthető ugyanabba az iptables táblába.
Ez a mód nagyon rugalmas és könnyen megvalósítható a meglévő infrastruktúrákban , mivel csak bizonyos pontokon (például FORWARD, INPUT, OUTPUT) kell módosítani a szabályokat, és minden mást a jelenlegi állapotában kell hagyni. A költség a csomagok NFQUEUE-n keresztüli fel- és lefelé továbbításának többletterhelése, a fent említett hatással, ha a mennyiség nagyon nagy, vagy a szabályok erőforrás-igényesek.
AF_PACKET módban a Suricata közelebb működik a hálózati interfészhez, és az AF_PACKET socketeken keresztül másolja a csomagokat. Ez egy sokkal gyorsabb, másolásmentes megközelítés , de megköveteli, hogy a rendszer két interfésszel rendelkező átjáróként működjön, és a forgalom blokkolása a hálózati kártyák közötti továbbítási szinten történjen: a blokkolandó csomag egyszerűen nem kerül át a bemeneti interfészről a kimeneti interfészre.
Mindkét módban a Suricata kombinálható a Netfilterrel, de az NFQUEUE különösen jól illeszkedik azokhoz a forgatókönyvekhez, ahol újra szeretnénk használni az összes iptables logikát (szabályzatok, tartományok, korábbi szabályok), és csak azt a forgalmat küldjük a Suricata-nak, amelyet mélyrehatóan meg akarunk vizsgálni.
A Suricata alapvető telepítése forráskódból
Azok számára, akik a Suricata fordítását részesítik előnyben a csomagok használata helyett, a Debian/Ubuntu típusú disztribúciókon a folyamat először a fordítási függőségek (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev stb.) telepítését, a tarball letöltését a hivatalos weboldalról, és a klasszikus ./configure, make, make install futtatását jelenti.
A konfigurációs fázisban a szkript jelzi, hogy mely támogatási funkciók vannak engedélyezve: AF_PACKET igen/nem, PF_RING, NFQUEUE igen/nem, NFLOG, IPFW, libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP stb. támogatása. Fontos ellenőrizni, hogy az NFQUEUE engedélyezve van-e, ha ebben a módban szeretnénk dolgozni , és hogy a minket érdeklő rögzítési könyvtár meg van-e találva.
A bináris fájl telepítése után a `make install-conf` paranccsal alapértelmezett konfigurációt telepíthetsz a `/etc/suricata` fájlba, a `make install-rules` paranccsal pedig letöltheted és elhelyezheted a feltörekvő fenyegetésekre vonatkozó szabályokat a `/etc/suricata/rules` fájlban. Ezek a szabályok ezután frissíthetők olyan eszközökkel, mint a `suricata-update`.
Red Hat/CentOS rendszereken a logika hasonló, a yum vagy a dnf függvényeket használjuk a függőségekhez (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel stb.), majd ugyanazokkal a lépésekkel fordítjuk. Teljesítménybeli okokból az LRO/GRO letiltása is ajánlott a rögzítési felületen az ethtool használatával, mivel ezek az áthelyezési függvények befolyásolhatják a csomagok láthatóságát IDS szinten.
Suricata konfiguráció: YAML, változók és szálkezelés
A Suricata fő konfigurációja az /etc/suricata/suricata.yaml fájlban található . Ez egy meglehetősen olvasható és sok kommenttel ellátott YAML fájl, ahol minden definiálva van, a naplózási elérési utakon és szabálykészleteken át a cél operációs rendszer házirendjeiig és a szálkezelési paraméterekig.
Az egyik alapvető mező a `default-log-dir` , amely meghatározza, hogy a naplófájlok hol tárolódnak (alapértelmezés szerint `/var/log/suricata`). A `vars` szakasz alatt olyan változók találhatók, mint a `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` és `SSH_PORTS`, amelyek rövidítésként szolgálnak a szabályokban. A `HOME_NET` általában a védeni kívánt helyi hálózati tartománnyal van konfigurálva, míg az `EXTERNAL_NET` jellemzően `!HOME_NET`-ként van definiálva.
Egy másik fontos rész a host-os-policy , amely megmondja a Suricata számára, hogy melyik operációs rendszernek kell bizonyos IP-tartományokat futtatnia. Ez lehetővé teszi számára, hogy beállítsa, hogyan állítja újra a TCP-t, vagy hogyan értelmezi bizonyos hálózati veremviselkedéseket , megnehezítve a protokollok megkerülését a veremközök közötti különbségek (Windows vs. Linux stb.) alapján. Az egyes tartományok hozzárendelhetők olyan kategóriákhoz, mint a Windows, Linux, BSD, Vista, Windows 2003 stb.
A szálkezelést illetően a szálkezelési szakasz lehetővé teszi a CPU affinitás és az észlelési szálak számának finomhangolását. Alapértelmezés szerint a `set-cpu-affinity` általában le van tiltva, ami lehetővé teszi a rendszerütemező számára a szálak elosztását a magok között. A `detect-thread-ratio` paraméter azt jelzi, hogy hány észlelési szál jön létre az elérhető magonként; a `detect-thread-ratio: 1.5` paraméterrel egy 8 magos gépen a Suricata 12 észlelési szálat generál, plusz rögzítési és felügyeleti szálakat.
Ez a teljes modell ezután tükröződik a kimenetben, amikor a démon elindul: egy rögzítőszál (például pcap) és több detektorszál látható, a folyamatkezelők és a statisztikai kezelők mellett. Ez a többfolyamatos architektúra teszi lehetővé a Suricata számára, hogy sokkal jobban skálázódjon, mint az egyszálú motorok, amikor 10/40 Gbit/s sebességű kapcsolatok esetén.
Szabályok és aláírásfrissítések Suricatában
A Suricata szabálykészletekre támaszkodik a támadási minták, a rendellenes viselkedés és a protokoll helytelen használatának észlelésére. A Snort formátumú szabályok elfogadása mellett a leggyakoribb ökoszisztéma az Emerging Threats: ET Open (ingyenes) és ET Pro (kereskedelmi), amelyek szabályai az aktuális fenyegetésekre irányulnak.
Sok modern disztribúció tartalmazza a `suricata-update` eszközt , amely leegyszerűsíti a szabályok kezelését: frissíti a forrásokat, engedélyezi vagy letiltja az adott szolgáltatókat, és letölti az aláíráskészletek legújabb verzióit. Egy tipikus munkafolyamat a következő lenne: telepíteni a `suricata-update` eszközt (például pip-en keresztül), futtatni az első `suricata-update` eszközt az ET Open letöltéséhez, listázni a forrásokat a `suricata-update list-sources` paranccsal, engedélyezni további forrásokat, például a `ptresearch/attackdetection`, `oisf/trafficid` vagy `sslbl/ssl-fp-blacklist` eszközt, majd újra futtatni a `suricata-update` eszközt a szabályfájl újragenerálásához.
A suricata.yaml fájl úgy van beállítva, hogy a megfelelő szabályok elérési útjára mutasson, és onnantól kezdve a Suricata riasztási eseményeket kezd generálni, amelyeket a fast.log (gyors, olvasható szöveg) és az eve.json (strukturált JSON nagyon teljes információkkal) fájlokban naplóz . Ez utóbbi formátum különösen hasznos irányítópultok, korrelációs rendszerek vagy egyéni szkriptek betáplálásához.
Az aláírások mellett a Suricata dekódereket és elemzőket is tartalmaz több protokollhoz , így kevésbé függ a portoktól: képes azonosítani a HTTP forgalmat akkor is, ha az nem szabványos portokon halad át, képes érzékelni az SSH, TLS, DNS stb. forgalmat különböző portokon és beágyazási szinteken (beleértve a vegyes IPv4/IPv6 alagutakat is).
Gyakorlati alkalmazás: a webes támadások felderítésétől az automatikus blokkolásig
Az egyik legkeresettebb felhasználási eset a tárhelykörnyezetekben vagy adatközpontokban a webes alkalmazások (pl. WordPress és bővítményei) sebezhetőségeinek kihasználására irányuló valós idejű kísérletek észlelése és automatikus reagálása, általában a forrás IP-cím blokkolásával vagy feketelistára helyezésével a tűzfalon.
A frissített szabályok által működtetett Suricata képes felismerni az URL-ek, paraméterek, HTTP-payloadok , sőt az ismert támadási szekvenciáknak megfelelő kéréssorozatok elleni specifikus támadási mintákat is. Az IDS passzív módban is működhet, tükrözésen keresztül fogadva a forgalmat egy kapcsolóportról (SPAN), de ahhoz, hogy IPS-ként működjön és blokkolja a támadásokat, integrálni kell a továbbító síkkal.
Két gyakori megközelítés létezik: az IDS online hídként való beállítása, így a forgalom fizikailag áthalad a gépen (iptables, AF_PACKET vagy PF használatával, a platformtól függően), vagy a topológia meghagyása a jelenlegi állapotában, de a tükrözést kombináljuk a központi tűzfalon API-n, szkripteken vagy NFQUEUE-n keresztül végrehajtott műveletekkel . Az első megközelítés minimalizálja az észlelés és a blokkolás közötti késleltetést, de egy újabb elemet kell hozzáadni a hálózat "közepére"; a második nagyobb rugalmasságot és ellenálló képességet kínál, de bonyolultabbá teszi a vezénylést.
Egy behatolásérzékelő rendszer (IDS) számára teljesen megvalósítható, hogy észlelje a sebezhető WordPress bővítmények kihasználására tett kísérleteket, majd közvetlenül vagy egy kapcsolódó komponensen keresztül hozzáadja a támadó IP-címét egy iptables feketelistához. Ez megtehető a Suricata JSON kimenetén és az iptables/nftables függvényt meghívó szkripteken keresztül , vagy a logika egy részének NFQUEUE-ra delegálásával, ahol maga a motor vagy egy kapcsolódó folyamat hozza meg a döntést menet közben, anélkül, hogy egy külső lista frissítésére várna.
Ez lehetővé teszi, hogy a valóban fontos fenyegetésekre (exploitok, eszkalációs kísérletek, nagyon agresszív vizsgálatok) koncentráljon, és figyelmen kívül hagyja vagy egyszerűen naplózza a háttérzajt, például az alapvető portvizsgálatokat, amelyek sok esetben önmagukban nem aggasztóak.
Suricata a Pfsense-en: nyílt forráskódú tűzfal integrált IDS/IPS-sel
Nem mindenki engedheti meg magának, vagy nem mindenki akar megengedni magának egy saját fejlesztésű, csúcskategóriás tűzfalat, mint a Palo Alto. Sok környezetben vonzóbb egy nyílt forráskódú megoldás létrehozása a pfSense és a Suricata segítségével , amely lefedi mind a fejlett tűzfaligényeket (multi-WAN, VLAN, VPN, NAT stb.), mind az IDS/IPS-t.
A FreeBSD-n és a Packet Filteren alapuló Pfsense különösen jól működik virtualizált környezetekkel (Proxmox, KVM stb.), azzal a kivétellel, hogy a KVM gépekben a teljesítményproblémák és a terhelés alatti összeomlások elkerülése érdekében a Virtio helyett E1000 kártyák használata ajánlott , kivéve, ha a Netgate ajánlásait alkalmazzuk (letiltjuk a hardveres ellenőrzőösszeg-terhelést a Rendszer > Speciális > Hálózatkezelés menüpontban, és újraindítjuk a gépet, tudván, hogy ez nagyon nagy terhelések esetén nem biztos, hogy elég lesz).
Egy Suricata és Pfsense programot futtató labor minimális hardverkövetelményei szerények lehetnek (1 db 500 MHz-es CPU, 1 GB RAM, 4 GB lemezterület), de komolyabb használathoz legalább 2 CPU, 4 GB RAM és 16 GB tárhely ajánlott , nem megfeledkezve arról sem, hogy több hálózati interfész is legyen (egy a WAN-hoz, egy a LAN-hoz, több, ha több WAN-t vagy összetett VLAN-t szeretnél).
Maga a pfSense telepítése nagyon gyors: az ISO-ról indítod a rendszert, elfogadod a licencszerződést, kiválasztod a telepítést, kiválasztod a nyelvet és a billentyűzetkiosztást, a particionálást automatikusra állítod (Auto UFS, ha a teljes lemezt használod), és néhány perc múlva a rendszer készen áll az első indításra. A konzolon egy menü található az interfészek hozzárendeléséhez, az újraindításhoz, a shell elindításához stb.
A laborban, például a VirtualBoxban, gyakori, hogy ideiglenesen letiltjuk a Pfsense tűzfalat a konzolról a pfctl -d paranccsal , hogy a WAN-on keresztül (admin felhasználónév, pfsense jelszó) elérhessük a webes felületet, és befejezhessük a kezdeti varázslót: általános adatok, NTP-kiszolgálók, WAN-konfiguráció (a laborban általában elegendő a DHCP), LAN, az adminisztrátori jelszó módosítása és a konfiguráció alkalmazása.
Miután a hozzáférés stabilizálódott, létrehozhatsz egy szabályt a WAN tűzfalon, amely engedélyezi a HTTPS-t bármilyen forrásból a pfsense IP-címre, leíró elválasztókat adva hozzá a szabályok vizuális rendszerezéséhez (például "Tűzfal hozzáférés"). Azt is tanácsos letiltani a WAN-on lévő privát hálózatok blokkolásának lehetőségét, ha tesztkörnyezetben vagy RFC1918 címekkel, hogy elkerüld a `pfctl -d` folyamatos használatát.
Suricata telepítése a pfSense-en és áttekintése
A pfSense alap futtatásával a Suricata telepítése olyan egyszerű, mint a Rendszer > Csomagkezelő > Elérhető csomagok menüpontban megkeresni a Suricata csomagot, és telepíteni a csomagot. A folyamat több fájlt tölt le, és a hardvertől függően eltarthat egy ideig, de a webes felületen keresztül teljes körűen támogatott.
A telepítés után egy Suricata bejegyzés jelenik meg a Szolgáltatások lapon, ahol interfészenként (WAN, LAN, VLAN stb.) konfigurálhatja a példányokat, kiválaszthatja a használandó szabálykészleteket, aktiválhatja az IDS vagy IPS módot , valamint beállíthatja a teljesítmény- és naplózási paramétereket. A lehetőségek tárháza széles (elegendő egy teljes cikk elolvasásához csak a konfigurációról), de az előnye, hogy sok olyan feladatot, amely Linuxon manuális YAML-szerkesztést igényel, itt űrlapok és jelölőnégyzetek segítségével kezel.
Fontos megjegyzés: Bár csábító lehet a pfSense adminisztrációját közvetlenül az internetre megnyitni egy laboratóriumi környezetben, éles környezetben kulcsfontosságú a statikus IP-címekre való hozzáférés korlátozása, VPN-ek használata a távoli felügyelethez, és a webes konzol mindenáron való elérhetőségének elkerülése . A pfSense nagyon rugalmas, de kritikus elemként is kell kezelni.
Ha a Suricata engedélyezve van a pfSense-en, olyan környezetet kap, ahol a forgalom a pfSense-en halad át tűzfal és NAT miatt, és a Suricata a szabályai szerint ellenőrzi azt, és IPS módban blokkolhatja . Ez a kombináció, amely egyetlen webes felületről kezelhető, jelentősen leegyszerűsíti a DPI-védelem telepítését kis és közepes méretű hálózatokban.
Sok telepítésben ezt kiegészíti a Pfsense/Suricata SIEM-hez vagy központosított naplózási platformhoz való csatlakoztatása, kihasználva a strukturált kimeneti formátumokat az események korrelálására és a szélesebb körű kampányok észlelésére.
Eseményfigyelés és példanaplók Suricata-ban
Amint a Suricata fut, az események a default-log-dir által meghatározott elérési útra, általában a /var/log/suricata mappába kerülnek naplózásra . A fast.log fájl egy kompakt szöveges formátumot használ, időbélyegekkel, szabályazonosítókkal, osztályozásokkal és prioritással, amely alkalmas a terminálból történő gyors ellenőrzésre (tail -f).
Például, ha helytelen TCP ellenőrzőösszegű forgalommal találkozunk, az alábbi sorokhoz hasonló sorokat láthatunk: időbélyegek dátummal és idővel, majd a szabályazonosító (pl. 1:2200074:1), a „SURICATA TCPv4 érvénytelen ellenőrzőösszeg” üzenet, az osztályozás, a prioritás, valamint a forrás-cél IP/port pár. Az ilyen típusú riasztások lehetővé teszik a csomagintegritási problémák vagy az elkerülési kísérletek gyors azonosítását.
Az eve.json fájl ugyanazokat az eseményeket tartalmazza JSON formátumban, olyan mezőkkel, mint a timestamp, event_type, src_ip, dest_ip, src_port, dest_port, proto, valamint egy riasztási alfájl, amely tartalmazza az action, gid, signature_id, rev, signature, category és severity értékeket. Ez a formátum könnyen betölthető a Logstash, Fluentd, Filebeat vagy bármely más naplózóügynökkel , ami sokkal gazdagabb elemzést tesz lehetővé, mint az egyszerű szöveg használata.
Amikor a Suricata-t többmagos szerveren (pl. 8 magos) telepítjük, a száltömörítés könnyen látható olyan eszközökben, mint a htop szál módban, egy vagy több rögzítési szálat (pcap, AF_PACKET vagy NFQ) és nagyszámú, a magok között elosztott észlelési szálat jelenítve meg. Az észlelési szál arányának és a CPU affinitásának módosítása jelentősen befolyásolhatja az átviteli sebességet és a késleltetést, amikor a forgalom mennyisége megközelíti a platform korlátait.
Mielőtt éles környezetben telepítené, célszerű időt szánni annak finomhangolására, hogy mely szabálykészletek legyenek aktiválva , hogy elkerüljük a téves riasztások áradatát, amelyek blokkolhatják a jogos forgalmat vagy eltorzíthatják a naplókat. A Suricata-update lehetővé teszi teljes kategóriák vagy egyes szabályok letiltását, hogy ésszerű egyensúlyt találjunk az érzékenység és a használhatóság között.
Speciális alkalmazások: VoIP, audioanalitika és kreatív NFQUEUE
A klasszikus felhasználási módokon (webszolgáltatás-védelem, kártevő-észlelés, DDoS-elemzés) túl a Netfilter+NFQUEUE páros meglehetősen kreatív megoldásokat kínál olyan területeken, mint a VoIP. Például lehetőség van egy SPIT-szűrő (spam over IP telephony) vagy egy RTP-folyamokban található káromkodások cenzúrázására szolgáló rendszer beállítására.
Az ötlet a következő lenne: az RTP forgalom azonosítása portok vagy protokollfelismerés alapján, és annak elküldése az NFQUEUE-nak; a felhasználói alkalmazásból az RTP adatfolyam rekonstruálása egy librtp-hez hasonló könyvtár segítségével , a hanganyag WAV formátumban történő kinyerése és továbbítása egy kulcsszó-felismerő motornak (wordspotting), például egy harmadik fél által kínált szintézisnek vagy felismerő könyvtárnak.
A detektált szavak alapján az NFQUEUE folyamat dönthet úgy, hogy engedélyezi, blokkolja, vagy akár módosítja a lejátszást egy sípoló hang beillesztésével a folyamba, bár ez utóbbi az RTCP, a csomagsorozatok és az időzítések nagyon finomhangolt vezérlését igényli – szinte egy „közvetítő” megközelítést. Ez nem triviális, de elméletileg tökéletesen megvalósítható ugyanazon sor- és ítéletrendszer kihasználásával.
Igaz, hogy ennek egy részét egy egyszerű szippantóval el lehetne végezni, amely adatokat továbbítana egy külső processzornak, majd a SIP jelzésre reagálna, vagy egy SBC-n (Asterisk, Kamailio stb.) keresztül. Az NFQUEUE használatának különbsége az, hogy az RTP folyamaton végrehajtott művelet azonnali és közvetlen lehet , anélkül, hogy több komponenst kellene koordinálni, vagy meg kellene várni, amíg a jelzőréteg befejezi a hívást.
Ezek a forgatókönyvek világosan illusztrálják a GNU/Linux + Netfilter + Suricata + harmadik féltől származó könyvtárak kombinációjában rejlő lehetőségeket: nem csak a portok és IP-címek blokkolásáról van szó, hanem az összetett forgalmi döntések valós idejű megszervezéséről egy 100%-ban szabad szoftveres ökoszisztéma használatával.
Ha a teljes folyamatot tekintjük, a mindig csomagokat fogadó kis C programtól kezdve a többfolyamatos Suricata telepítésig, amely integrálva van az NFQUEUE-val, a Pfsense-szel, az adatbázisokkal és a gyorsítótárakkal, értékelni tudjuk azt a rugalmasságot, amelyet ez a technológiai csomag kínál, hogy bármit felépíthessen az egyszerű dinamikus tűzfalaktól az adatközpont-szintű IDS/IPS architektúrákig, valódi mélyreható ellenőrzési képességekkel és az egyre összetettebb támadásokra adott automatizált válaszokkal.