- NFQUEUE omogućava Netfilteru da delegira odluke o filtriranju i označavanju procesima u korisničkom prostoru, omogućavajući dinamičke IP zaštitne zidove i rutere.
- Suricata pruža višeprocesni IDS/IPS mehanizam s podrškom za NFQUEUE, AF_PACKET i pravila kompatibilna sa Snort-om i Emerging Threats-om.
- Integracija NFQUEUE-a sa Suricatom, bazama podataka, Memcachedom ili Pfsenseom omogućava vam izgradnju naprednih sigurnosnih i rutirajućih rješenja pomoću besplatnog softvera.
- Performanse uveliko zavise od dizajna niti i logike korisničkog prostora, što čini ključnim optimizaciju i pažljiv odabir prometa koji će se pregledati.
Ako radite s mrežama na GNU/Linuxu ( najbolje Linux distribucije za sigurnost i privatnost ) i zainteresirani ste za prevazilaženje tipičnog statičkog firewalla, vjerovatno vas zanima kako kombinirati Netfilter, NFQUEUE i Suricatu kako biste izgradili zaista fleksibilan IDS/IPS bez trošenja bogatstva na vlasnički hardver. Upravo je to područje koje ćemo istražiti u ovom članku, kombinirajući elemente niskog nivoa (kernel, redovi čekanja, C) s alatima visokog nivoa (Suricata, pravila, MySQL, Memcached, pfSense).
Osnovna ideja je vrlo moćna: iskoristiti činjenicu da kernel (pogledajte kako optimizirati Linux kernel ) može smještati pakete u korisnički prostor i pustiti prilagođeni program da odluči šta će s njima raditi. Ovo se može koristiti za filtriranje prometa (napredni zaštitni zid, IPS), dinamičko usmjeravanje ili integraciju poslovne logike (baze podataka, keš memorije, otkrivanje napada na web aplikacije, VoIP, itd.). A ako dodamo Suricatu kao višeprocesni IDS/IPS mehanizam, imamo vrlo robusnu kombinaciju za okruženja u rasponu od laboratorija do podatkovnih centara s visokim prometom.
NFQUEUE i Netfilter: podizanje zaštitnog zida na nivo korisničkog prostora
U tipičnom GNU/Linux sistemu, pravila Netfilter/iptables (ili nftables) se obično koriste kao statičke politike koje se u potpunosti nalaze u prostoru kernela . Frontendovi i uređaji (uključujući mnoga rješenja zasnovana na Netfilteru ili BSD-ovom Packet Filteru) pohranjuju konfiguraciju u tekstualne, XML ili SQLite datoteke, a kada se nešto promijeni, regeneriraju i ponovo učitavaju pravila. Ovo je fleksibilno, ali logika ostaje neka vrsta snimka zaštitnog zida (firewall) s manjim dinamičkim podešavanjima (ograničenja broja veza po sekundi, praćenje kontakata, usklađivanje država, sloj 7 ako je dostupan, itd.).
Ono što NFQUEUE predlaže je revolucionarno: umjesto da kernel uvijek donosi konačnu odluku, tu odluku možemo delegirati korisničkom procesu . Kernel stavlja paket u numerirani red čekanja, a aplikacija koja koristi biblioteku libnetfilter_queue ga preuzima, analizira i vraća presudu: prihvatiti, odbaciti ili čak označiti za usmjeravanje prema pravilima. To je kao da imate programabilnog "sudiju" napisanog u C-u, Pythonu ili Perlu na vrhu zaštitnog zida (firewall-a).
Ljepota ovoga je u tome što naš program doslovno može uraditi šta god želimo: upitati /dev/urandom, bazu podataka, web servis, distribuirani keš ili sofisticirani algoritam prije nego što odgovori kernelu. U arhitektonskom smislu, zaštitni zid prestaje biti jednostavan skup statičnih pravila i postaje cjevovod gdje se Netfilter, redovi čekanja i korisničke aplikacije uklapaju kao dijelovi slagalice.
NFQUEUE se sastoji od dva dijela: NFQUEUE cilja u iptables-u , koji šalje pakete u određeni red čekanja, i libnetfilter_queue korisničke biblioteke , koja vam omogućava čitanje tih paketa i izdavanje odluke. To nije jednostavno sniffer kao tcpdump: ovdje imamo mogućnost direktnog odlučivanja o putanji kojom će paket ići.
Osnovna konfiguracija iptablesa pomoću NFQUEUE-a
Sa stanovišta iptables-a, korištenje NFQUEUE-a je prilično jednostavno: dodajete pravilo lancu koji vas zanima kako biste u red poslali pakete koji ispunjavaju određene kriterije (izvorna/odredišna IP adresa, portovi, stanja, dodatni moduli kao što su GeoIP ili layer7 ako su dostupni, itd.).
Na primjer, ako želimo poslati NFQUEUE-u sve pingove koji stignu na sam host:
iptables -I INPUT -p icmp -j NFQUEUE
Ovo šalje dolazne ICMP pakete u red 0 (osim ako nije drugačije navedeno). Mogli bismo specificirati drugi red sa nečim poput `--queue-num 3` . Prilikom navođenja pravila s brojačima (`iptables -L -n -v -x`), vidjet ćemo da se brojači povećavaju, što ukazuje na to da se paketi stavljaju u red . Važan detalj: ako u redu postoje paketi i nijedan korisnički proces ih ne preuzima i ne obrađuje, zadano ponašanje je da ih odbije, tako da kvar aplikacije, po svojoj prirodi, rezultira blokiranjem prometa.
Programiranje protiv libnetfilter_queue: "zdravo svijete" u C-u
Za pridruživanje redu čekanja iz korisničkog prostora koristi se biblioteka libnetfilter_queue (koja se pak oslanja na libnfnetlink). Na distribucijama poput Debiana, jednostavno instalirajte razvojne pakete:
apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc
Kostur minimalnog programa koji uvijek prihvata pakete sastoji se od nekoliko vrlo jasnih koraka: otvaranje biblioteke, odvezivanje svih postojećih rukovatelja, povezivanje s AF_INET protokolom, kreiranje reda s funkcijom povratnog poziva, definiranje načina kopiranja i ulazak u petlju primanja . Povratni poziv se izvršava za svaki paket u redu čekanja, izdvajajući ID i vraćajući presudu.
U praksi, tok je otprilike ovakav: `nfq_open` za dobijanje handle-a, `nfq_unbind_pf` za čišćenje, `nfq_bind_pf` za povezivanje sa AF_INET-om, `nfq_create_queue` za registraciju povratnog poziva u redu 0, `nfq_set_mode` za označavanje da li želimo metapodatke ili cijeli paket, petlja sa `recv()` preko deskriptora i `nfq_handle_packet` za obradu svakog paketa . Po izlasku, red se uništava sa `nfq_destroy_queue`, a handle se zatvara sa `nfq_close`.
Ova vrsta "zdravo svijete" omogućava čisto mjerenje utjecaja NFQUEUE. Ako primjer kompajliramo nečim poput:
gcc -o nftest kod.c -lnfnetlink -lnetfilter_queue
A ako promet iz iperfa stavimo u red čekanja (na primjer, TCP port 5001 u INPUT i OUTPUT), vidjet ćemo da kod koji jednostavno prihvata pakete jedva utječe na performanse na gigabitnoj mreži . Međutim, postoji ključni detalj: ispis informacija u povratnom pozivu (printf, fflush, itd.) značajno smanjuje propusnost, kao što se može vidjeti pri usporedbi iperfa sa i bez otklanjanja grešaka na ekranu.
Napredne NFQUEUE opcije: premošćivanje, balansiranje i otvaranje u slučaju kvara
NFQUEUE uključuje nekoliko zanimljivih iptables opcija koje mijenjaju zadano ponašanje redova čekanja i koje bi trebale biti poznate prije ulaska u produkcijsko ili visokoperformansno okruženje, jer utječu na način na koji se obrađuje neuspjeh korisničke aplikacije ili popunjavanje reda čekanja.
Komanda `--queue-bypass` vam omogućava da osigurate da, ako nijedan proces ne osluškuje red čekanja, paketi se ne odbacuju, već se prosljeđuju na sljedeći skok u iptables lancu. Ovo može biti korisno ako želite da se sistem "otvori u slučaju greške" kada korisnička usluga nije dostupna, iako je sa sigurnosne perspektive to mač sa dvije oštrice.
Opcija `--queue-balance` vam omogućava da distribuirate pakete u raspon redova čekanja (na primjer, od 0 do 3), a zatim imate više nezavisnih procesa ili niti koje koriste podatke iz svakog reda . Netfilterov kod osigurava da paketi iz istog toka uvijek završe u istom redu čekanja, što znatno pojednostavljuje održavanje konzistentnosti u logici odlučivanja.
Tu je i mod `--fail-open` , koji kontrolira šta se događa kada se red čekanja napuni jer korisnički proces radi previše sporo. Njegovo omogućavanje uzrokuje da kernel direktno prihvata pakete umjesto da ih odbacuje, sprječavajući masovne poremećaje u prometu. Opet, ovo može biti sigurnosni problem, jer ako želimo donositi odluke od slučaja do slučaja, gubitak paketa odluka znači neuspjeh u ispunjavanju tog cilja.
Da bi pratio šta se dešava sa redovima čekanja, Netfilter izlaže informacije u pseudo-fs datoteci /proc/net/netfilter/nfnetlink_queue , koja se može lako dobiti iz skripti ili alata za praćenje.
Integracija poslovne logike: testiranje s Memcachedom i MySQL-om
Kada je proces "zdravo svijete" pod kontrolom, sljedeći prirodan korak je obogaćivanje povratnog poziva pozivima prema vanjskim sistemima . Tipičan eksperiment uključuje odlučivanje o tome hoće li se paket prihvatiti ili odbaciti na osnovu toga da li se izvorna IP adresa pojavljuje u bilo kojem backendu, kao što je MySQL baza podataka ili Memcached keš.
U slučaju Memcacheda, daemon se instalira (apt-get install memcached) i ključ, na primjer authorized , se učitava sa IP adresom koja nas zanima. To možemo učiniti jednostavnim naredbama echo i netcat, a zatim provjeriti naredbom get da li je vrijednost ispravno pohranjena. Odatle, program NFQUEUE, pored dobijanja ID-a paketa, prima cijeli paket koristeći NFQNL_COPY_PACKET , izdvaja IP zaglavlje (struct iphdr) i pretvara izvornu adresu u niz znakova sa inet_ntop.
Da bi se izbjeglo gubljenje vremena na otvaranje veza sa svakim paketom, Memcached veza se inicijalizira samo jednom u glavnoj metodi (memcached_create, memcached_server_list_append, memcached_server_push), a rukovatelj se pohranjuje u globalne varijable. U povratnom pozivu, memcached_get se poziva sa željenim ključem, izvorna IP adresa se uspoređuje sa dohvaćenom vrijednošću i ako se podudaraju, vraća se NF_ACCEPT; u suprotnom, vraća se NF_DROP. Ako ključ ne postoji ili postoji greška, paket se odbacuje prema konzervativnoj politici.
Korištenjem iperfa, ova strategija smanjuje propusnost na približno 140 Mbit/s na gigabitnoj mreži , te se primjećuje da red čekanja počinje doživljavati gubitke (što je naznačeno, na primjer, simbolima unutar samog koda). Drugim riječima, samo pozivanje keš servisa po paketu već predstavlja značajan trošak, iako ostaje održivo za srednje količine prometa ako se optimizira.
Sa MySQL-om, pristup je sličan, ali složeniji: instaliraju se serverska i klijentska biblioteka, kreira se baza podataka (na primjer, nfqueue) sa jednostavnom tabelom pod nazivom authorized(ip varchar(50)) i ubacuje se dozvoljena IP adresa. U programu se pri pokretanju izvršavaju `mysql_init` i `mysql_real_connect` , a u povratnom pozivu se konstruiše upit poput `select * from authorized where ip like 'xxxx'`. Ako se upit uspješno izvrši i pronađe se red, paket se prihvata; u suprotnom, odbacuje se.
Sa omogućenim keširanjem upita u MySQL-u, testovi daju oko 188 Mbit/s , što pada na 103 Mbit/s kada je keširanje upita onemogućeno. Ove brojke, iako daleko od gigabita, pokazuju da se čak i sa najmanje elegantnim pristupom (jednonitni, bez optimizacije) , pristojne količine prometa mogu obraditi korištenjem odluka vođenih bazom podataka ili zasnovanih na keširanju.
Performanse, višenitnost i korištenje CPU-a
Testovi s iperf-om, Memcached-om i MySQL-om jasno pokazuju da ograničenje performansi nije toliko nametnuto samim NFQUEUE-om koliko logikom koju dodajemo u korisničkom prostoru i načinom na koji je implementiramo. Izvršna datoteka koja vraća samo NF_ACCEPT postiže gotovo gigabit bez ikakvog napora; čim uvedemo I/O ili mrežne pozive, propusnost pada, a CPU NFQUEUE mašine, Memcached daemona ili MySQL-a je gurnut do svojih granica.
Sa arhitektonskog stanovišta, ovo ima dvije implikacije. S jedne strane, potvrđuje da je delegiranje odluka o zaštitnom zidu (firewall) na korisničke aplikacije za značajne količine prometa sasvim održivo , pod uslovom da se uzmu u obzir stvarni troškovi svakog poziva. S druge strane, pokazuje da se za približavanje maksimalnim mogućnostima platforme mora razmotriti višenitnost (multithreading) ili višeprocesiranje (multiprocessing) . NFQUEUE omogućava distribuciju prometa u više redova čekanja; mogli bismo pokrenuti nekoliko kopija naše aplikacije, od kojih svaka sluša drugi red čekanja, i iskoristiti više jezgara bez muke s pthreadovima (probnim nizovima) ili masivnim forkovima (forkovima).
Druga očigledna optimizacija bi bila ograničavanje prometa koji prolazi kroz NFQUEUE . U testovima je cijeli iperf tok bio stavljen u red čekanja, ali u stvarnom scenariju, mogli bismo staviti u red samo pakete sa NOVIM stanjem, dozvoliti prolaz ESTABLISHED/RELATED paketima i rezervirati skupu logiku za prijave ili sumnjive obrasce.
U konačnici, korištenje CPU-a i dizajn niti su ključni: ako korisnički proces ne uspije, red čekanja se popuni i moramo pribjeći stvarima poput otvaranja u slučaju kvara ili prihvatanja odbacivanja, gubeći dio fine kontrole koju ovaj pristup teži postići.
Dinamičko rutiranje s Netfilter brendiranjem
NFQUEUE nije ograničen samo na izgovaranje "prihvati" ili "baci". Također se može koristiti za primjenu Netfilter (fwmark) zastavica na pakete i njihovo kombinovanje sa ip pravilom i iproute2 za kreiranje veoma fleksibilnih, gotovo laganih VRF-stilskih političkih shema rutiranja.
Postupak, općenito govoreći, bi bio sljedeći: definirati nekoliko tabela usmjeravanja u /etc/iproute2/rt_tables , na primjer sporu i brzu; dodijeliti svakoj tabeli različitu zadanu rutu (jednu preko optičkog vlakna, a drugu preko ograničenije veze); koristiti ip pravilo da se odredi da paketi sa fwmark 1 idu u brzu tabelu, oni sa fwmark 2 u sporu, itd.; i na kraju, koristiti NFQUEUE da se paketi odgovarajuće označe prije vraćanja presude.
Za postavljanje presudu iz povratnog poziva koristi se `nfq_set_verdict2` , što je slično `nfq_set_verdict`, ali vam omogućava da postavite vrijednost presudu koju će `ip rule` zatim vidjeti. Kombinujući sve ovo, možete izgraditi IP ruter koji odlučuje gdje će usmjeravati na osnovu proizvoljnih kriterija: od apsurdnih stvari poput parne/neparne veličine paketa do vanjskih ulaza kao što su algoritmi za predviđanje prometa, događaji na društvenim mrežama ili signali iz sistema za praćenje.
Rezultat je sistem u kojem kernel nastavlja prosljeđivati pakete uobičajenom brzinom, ali tačna putanja kojom svaki tok ide je delegirana vanjskom softveru koji može promijeniti mišljenje u stvarnom vremenu bez dodirivanja statičkih pravila.
NFQUEUE i Suricata: IPS visokog nivoa u GNU/Linuxu
Sve navedeno se može ručno programirati u C-u, ali kada je u pitanju detekcija upada i dubinska inspekcija paketa, razumna opcija je obično oslanjanje na zreli IDS/IPS mehanizam . Tu nastupa Suricata, koja je nastala upravo kao višeprocesna alternativa Snortu, s IPS mogućnostima od samog početka i snažnim fokusom na iskorištavanje mnogih CPU jezgara dostupnih danas.
Suricata je napisana od nule i distribuira se pod GPLv2 licencom ; Open Information Security Foundation (OISF) održava i mehanizam i prilično sveobuhvatan ekosistem pravila i dokumentacije. Za razliku od Snorta 2.x, koji je naslijedio jednonitnu jezgru i na nju je bio nadograđen, Suricata je dizajnirana da podijeli radno opterećenje na više niti: snimanje, dekodiranje, detekciju i izlaz, s različitim strategijama dijeljenja opterećenja.
Na funkcionalnom nivou, Suricata pruža izvornu podršku za IPv6, inspekciju sloja 7 (vrlo napredni HTTP putem HTP biblioteke), prepoznavanje protokola nezavisno od portova , rekonstrukciju toka i vrlo moćan sistem varijabli sesije (flowbits) za korelaciju različitih faza napada koji se šire preko nekoliko TCP veza.
Dodatna snaga je njegova kompatibilnost sa Snort pravilima i mogućnost korištenja i Sourcefire VRT i Emerging Threats setova potpisa (besplatna ET Open i komercijalna ET Pro verzija). Nadalje, izvozi događaje u vrlo korisnim formatima (fast.log, JSON u eve.json) za integraciju sa SIEM-ovima, ELK-om, Splunk-om i drugim sistemima.
Suricata kao IPS u Linuxu: načini snimanja i NFQUEUE
Na GNU/Linuxu, Suricata može raditi u različitim režimima, ovisno o tome kako se promet presreće: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … Svaki ima svoje prednosti i zahtjeve. Na čistom IPS nivou, dva najvažnija su NFQUEUE i AF_PACKET.
U NFQ (NFQUEUE) modu , tok je sličan onome opisanom ranije: skup iptables pravila šalje pakete u red čekanja; Suricata, koja se izvršava u korisničkom prostoru, čita iz tog reda, pregledava sadržaj prema svojim pravilima i vraća presudu kernelu: NF_ACCEPT, NF_DROP ili NF_REPEAT. Treći se može koristiti za ponovno ubacivanje paketa u istu iptables tabelu nakon primjene dodatnih oznaka ili modifikacija.
Ovaj način rada je vrlo fleksibilan i jednostavan za implementaciju u postojećim infrastrukturama , jer zahtijeva samo modifikaciju pravila na određenim tačkama (na primjer, FORWARD, INPUT, OUTPUT) i ostavlja sve ostalo kako jeste. Trošak predstavlja dodatni trošak propuštanja paketa gore-dolje kroz NFQUEUE, sa prethodno spomenutim utjecajem ako je volumen vrlo velik ili su pravila zahtjevna za resursima.
U AF_PACKET modu , Suricata radi bliže mrežnom interfejsu, kopirajući pakete preko AF_PACKET socketa. Ovo je mnogo brži pristup bez kopiranja , ali zahtijeva da sistem funkcioniše kao gateway sa dva interfejsa i da se blokiranje saobraćaja vrši na nivou prosljeđivanja između mrežnih kartica: paket koji treba blokirati se jednostavno ne prenosi sa ulaznog na izlazni interfejs.
U oba načina rada, Suricata se može kombinirati s Netfilterom, ali NFQUEUE se posebno dobro uklapa u scenarije gdje želimo ponovno koristiti svu logiku iptablesa (pravila, raspone, prethodna pravila) i slati Suricati samo promet koji nas zanima za detaljnu inspekciju.
Osnovna instalacija Suricate iz izvornog koda
Za one koji preferiraju kompajliranje Suricate umjesto korištenja paketa, proces na Debian/Ubuntu distribucijama uključuje prvo instaliranje kompajlnih zavisnosti (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev, itd.), preuzimanje tarballa sa službene web stranice i pokretanje klasične ./configure, make, make install.
Tokom faze konfiguracije, skripta će naznačiti koje su funkcije podrške omogućene: AF_PACKET da/ne, PF_RING, NFQUEUE da/ne, NFLOG, IPFW, podrška za libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP, itd. Važno je provjeriti da li je NFQUEUE omogućen ako želimo raditi u tom režimu i da li je biblioteka za snimanje koja nas zanima locirana.
Nakon instaliranja binarne datoteke, možete pokrenuti `make install-conf` da biste implementirali zadanu konfiguraciju u `/etc/suricata` i `make install-rules` da biste preuzeli i smjestili skup pravila o novim prijetnjama u `/etc/suricata/rules`. Ovi skupovi se zatim mogu ažurirati pomoću alata poput `suricata-update`.
Na Red Hat/CentOS sistemima, logika je slična, korištenje yum ili dnf za zavisnosti (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel, itd.) i zatim kompajliranje s istim koracima. Iz razloga performansi, također je preporučljivo onemogućiti LRO/GRO u interfejsu za snimanje pomoću ethtool-a, jer ove funkcije rasterećenja mogu utjecati na vidljivost paketa na nivou IDS-a.
Konfiguracija Suricate: YAML, varijable i niti
Glavna konfiguracija Suricate nalazi se u /etc/suricata/suricata.yaml . To je prilično čitljiva i obilno komentirana YAML datoteka, gdje je definirano sve, od putanja logova i skupova pravila do politika ciljnog operativnog sistema i parametara niti.
Jedno od osnovnih polja je `default-log-dir` , koje određuje gdje će se log datoteke pohranjivati (podrazumevano, `/var/log/suricata`). U odjeljku `vars` nalaze se varijable kao što su `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` i `SSH_PORTS`, koje služe kao skraćenice u pravilima. `HOME_NET` se obično konfiguriše sa lokalnim mrežnim rasponom koji želimo zaštititi, dok se `EXTERNAL_NET` obično definiše kao `!HOME_NET`.
Još jedan važan dio je host-os-policy , koja govori Suricati koji operativni sistem treba da koristi određene IP raspone. To mu omogućava da prilagodi način na koji ponovo sastavlja TCP ili interpretira određena ponašanja mrežnog steka , što otežava izbjegavanje protokola na osnovu razlika između stekova (Windows vs. Linux, itd.). Određeni rasponi mogu se dodijeliti kategorijama kao što su Windows, Linux, BSD, Vista, Windows 2003, itd.
Što se tiče niti, odjeljak za niti vam omogućava fino podešavanje afiniteta CPU-a i broja niti za detekciju. Podrazumevano, `set-cpu-affinity` je obično onemogućen, što omogućava sistemskom planeru da distribuira niti po jezgrama. Parametar `detect-thread-ratio` označava koliko niti za detekciju se kreira po dostupnoj jezgri; sa `detect-thread-ratio: 1.5` na mašini sa 8 jezgara, Suricata će generisati 12 niti za detekciju, plus niti za snimanje i upravljanje.
Cijeli ovaj model se zatim odražava u izlazu kada se daemon pokrene: vidljivi su nit za snimanje (na primjer, pcap) i više niti za detekciju, pored upravitelja protoka i upravitelja statistike. Ova višeprocesna arhitektura omogućava Suricati da se mnogo bolje skalira od jednonitnih mehanizama kada se suoči sa vezama od 10/40 Gbit/s.
Ažuriranja pravila i potpisa u Suricati
Suricata se oslanja na skupove pravila za otkrivanje obrazaca napada, anomalnog ponašanja i zloupotrebe protokola. Pored prihvatanja pravila u Snort formatu , najčešći ekosistem je onaj Emerging Threats: ET Open (besplatno) i ET Pro (komercijalno), s pravilima usmjerenim na trenutne prijetnje.
Mnoge moderne distribucije uključuju alat `suricata-update` , koji pojednostavljuje upravljanje pravilima: ažurira izvore, omogućava ili onemogućava određene provajdere i preuzima najnovije verzije skupova potpisa. Tipičan tijek rada bi bio instalirati `suricata-update` (na primjer, putem pipa), pokrenuti prvi `suricata-update` za preuzimanje ET Open-a, navesti izvore pomoću `suricata-update list-sources`, omogućiti dodatne izvore kao što su `ptresearch/attackdetection`, `oisf/trafficid` ili `sslbl/ssl-fp-blacklist` i ponovo pokrenuti `suricata-update` za regeneraciju datoteke s pravilima.
Datoteka suricata.yaml se prilagođava tako da ukazuje na ispravnu putanju pravila, a odatle će Suricata početi podizati događaje upozorenja koji će se evidentirati u fast.log (brz, čitljiv tekst) i eve.json (strukturirani JSON sa vrlo potpunim informacijama) . Ovaj posljednji format je posebno koristan za unošenje podataka u kontrolne ploče, sisteme korelacije ili prilagođene skripte.
Pored potpisa, Suricata uključuje dekodere i parsere za više protokola , što joj omogućava da bude manje ovisna o portovima: može identificirati HTTP promet čak i ako prolazi kroz nestandardne portove, detektirati SSH, TLS, DNS itd. preko različitih portova i nivoa enkapsulacije (uključujući mješovite IPv4/IPv6 tunele).
Praktična upotreba: od otkrivanja web exploita do automatskog blokiranja
Jedan od najpoželjnijih slučajeva upotrebe u hosting okruženjima ili podatkovnim centrima je otkrivanje u stvarnom vremenu pokušaja iskorištavanja ranjivosti u web aplikacijama (npr. WordPress i njegovi dodaci) i automatsko reagiranje, obično blokiranjem ili stavljanjem izvorne IP adrese na crnu listu u zaštitnom zidu (firewall).
Suricata, pokretana ažuriranim pravilima, sposobna je prepoznati specifične obrasce napada na URL-ove, parametre, HTTP podatke , pa čak i sekvence zahtjeva koje odgovaraju poznatim exploitima. IDS može raditi u pasivnom režimu, primajući promet putem zrcaljenja sa switch porta (SPAN), ali da bi djelovao kao IPS i blokirao napade, mora biti integriran s ravni prosljeđivanja.
Postoje dva uobičajena pristupa: postavljanje IDS-a kao online mosta, tako da promet fizički prolazi kroz mašinu (korištenjem iptables, AF_PACKET ili PF, ovisno o platformi), ili ostavljanje topologije kakva jeste, ali kombiniranje zrcaljenja s akcijama na centralnom zaštitnom zidu putem API-ja, skripti ili NFQUEUE . Prvi pristup minimizira latenciju između detekcije i blokiranja, po cijenu dodavanja još jednog elementa "u sredini" mreže; drugi nudi veću fleksibilnost i otpornost, ali uvodi veću složenost u orkestraciju.
Sasvim je izvodljivo da sistem za detekciju upada (IDS) otkrije pokušaj iskorištavanja ranjivog WordPress dodatka, a zatim, direktno ili putem povezane komponente, doda IP adresu napadača na crnu listu iptables-a. To se može učiniti putem Suricata-inog JSON izlaza i skripti koje pozivaju iptables/nftables , ili delegiranjem dijela logike na NFQUEUE, gdje sam mehanizam ili povezani proces donosi odluku u hodu bez čekanja da se ažurira eksterna lista.
Ovo vam omogućava da se fokusirate na prijetnje koje su zaista važne (eksploatacije, pokušaji eskalacije, vrlo agresivna skeniranja), ignorirajući ili jednostavno evidentirajući pozadinsku buku poput osnovnih skeniranja portova koja, u mnogim kontekstima, sama po sebi nisu zabrinjavajuća.
Suricata na Pfsenseu: opensource firewall sa integrisanim IDS/IPS-om
Ne mogu ili ne žele svi priuštiti vlasnički vrhunski firewall poput Palo Alta. U mnogim okruženjima, atraktivnije je postaviti rješenje otvorenog koda s pfSense i Suricata , koje pokriva i napredne potrebe firewalla (multi-WAN, VLAN, VPN, NAT, itd.) i IDS/IPS.
Pfsense, baziran na FreeBSD-u i Packet Filteru, posebno dobro radi s virtualiziranim okruženjima (Proxmox, KVM, itd.), s izuzetkom što se preporučuje korištenje E1000 kartica umjesto Virtio u KVM mašinama ako želite izbjeći probleme s performansama i padove sistema pod opterećenjem, osim ako ne primijenite Netgateove preporuke (onemogućite rasterećenje hardverske kontrolne sume u Sistem > Napredno > Umrežavanje i ponovo pokrenite sistem, znajući da to možda neće biti dovoljno kod vrlo velikih opterećenja).
Minimalni hardverski zahtjevi za laboratoriju sa Suricatom na Pfsenseu mogu biti skromni (1 CPU 500 MHz, 1 GB RAM-a, 4 GB diska), ali za ozbiljnu upotrebu preporučuju se najmanje 2 CPU-a, 4 GB RAM-a i 16 GB prostora za pohranu , ne zaboravljajući imati nekoliko mrežnih interfejsa (jedan za WAN, drugi za LAN, više ako želite više WAN-ova ili složene VLAN-ove).
Instalacija samog pfSense-a je vrlo brza: pokrećete sistem iz ISO datoteke, prihvatate licencu, birate instalaciju, birate jezik i raspored tastature, ostavljate particioniranje uključeno automatski (Auto UFS ako ćete koristiti cijeli disk) i za nekoliko minuta sistem je spreman za prvo pokretanje. Konzola nudi meni za dodjeljivanje interfejsa, ponovno pokretanje, pokretanje ljuske itd.
U laboratoriji, na primjer u VirtualBoxu, uobičajeno je privremeno isključiti Pfsense firewall iz konzole pomoću pfctl -d kako bi se pristupilo web sučelju putem WAN-a (korisničko ime admin, lozinka pfsense) i dovršio početni čarobnjak: opći podaci, NTP serveri, WAN konfiguracija (DHCP je obično dovoljan u laboratoriji), LAN, promjena administratorske lozinke i primjena konfiguracije.
Nakon što se pristup stabilizira, možete kreirati pravilo u WAN firewallu koje dozvoljava HTTPS iz bilo kojeg izvora na pfsense IP adresu, dodajući opisne separatore za vizualnu organizaciju pravila (na primjer, "Pristup firewallu"). Također je preporučljivo onemogućiti opciju blokiranja privatnih mreža na WAN-u ako ste u testnom okruženju s RFC1918 adresama, kako biste izbjegli stalnu upotrebu `pfctl -d`.
Instalacija Suricate na pfSense-u i pregled
Sa pokrenutom i pokrenutom pfSense bazom, instaliranje Suricate je jednostavno kao odlazak na Sistem > Upravitelj paketa > Dostupni paketi , traženje Suricate i instaliranje paketa. Proces preuzima nekoliko datoteka i može potrajati neko vrijeme ovisno o vašem hardveru, ali je u potpunosti potpomognut putem web sučelja.
Nakon instalacije, u kartici Usluge se pojavljuje Suricata unos, gdje možete konfigurirati instance prema interfejsu (WAN, LAN, VLAN, itd.), odabrati koje skupove pravila koristiti, aktivirati IDS ili IPS način rada i prilagoditi parametre performansi i evidentiranja. Raspon opcija je opsežan (dovoljan za cijele članke samo o konfiguraciji), ali prednost je što se mnogi zadaci koji u Linuxu zahtijevaju ručno uređivanje YAML-a ovdje rješavaju pomoću obrazaca i potvrdnih okvira.
Važna napomena: Iako bi u laboratorijskom okruženju moglo biti primamljivo otvoriti pfSense administraciju direktno na internet, u produkciji je ključno ograničiti pristup statičkim IP adresama, koristiti VPN-ove za udaljeno upravljanje i po svaku cijenu izbjegavati ostavljanje web konzole izloženom . pfSense je vrlo fleksibilan, ali se također mora tretirati kao ključni element kakav jeste.
Sa omogućenim Suricata-om na pfSense-u, dobijate okruženje u kojem saobraćaj prolazi kroz pfSense za zaštitni zid i NAT, a Suricata ga pregledava prema svojim pravilima i može ga blokirati u IPS režimu . Ova kombinacija, kojom se upravlja iz jednog web interfejsa, uveliko pojednostavljuje implementaciju DPI zaštite u malim i srednjim mrežama.
U mnogim implementacijama, ovo je dopunjeno povezivanjem Pfsense/Suricata sistema sa SIEM-om ili centralizovanom platformom za evidentiranje, koristeći prednosti strukturiranih izlaznih formata za povezivanje događaja i otkrivanje širih kampanja.
Praćenje događaja i primjeri zapisnika u Suricati
Nakon što se Suricata pokrene, događaji se zapisuju u putanju definiranu parametrom default-log-dir, obično /var/log/suricata . Datoteka fast.log koristi kompaktni tekstualni format s vremenskim oznakama, ID-ovima pravila, klasifikacijama i prioritetom, pogodan za brzu inspekciju iz terminala (tail -f).
Na primjer, kada naiđemo na promet s netačnim TCP kontrolnim sumama, možemo vidjeti ovakve redove: vremenske oznake s datumom i vremenom, nakon čega slijedi identifikator pravila (npr. 1:2200074:1), poruka "SURICATA TCPv4 nevažeća kontrolna suma", klasifikacija, prioritet i par IP/port izvora i odredišta. Ove vrste upozorenja omogućavaju brzu identifikaciju problema s integritetom paketa ili pokušaja izbjegavanja.
Datoteka eve.json sadrži iste događaje u JSON formatu, s poljima kao što su timestamp, event_type, src_ip, dest_ip, src_port, dest_port, proto i poddatotekom upozorenja s akcijama, gid-om, signature_id-om, rev-om, potpisom, kategorijom i ozbiljnošću. Ovaj format se može lako unijeti pomoću Logstash-a, Fluentd-a, Filebeat-a ili bilo kojeg drugog agenta za evidenciju , što omogućava mnogo bogatiju analitiku od jednostavnog korištenja običnog teksta.
Prilikom implementacije Suricate na višejezgrenom serveru (npr. 8 jezgri), kompresija niti je lako uočljiva u alatima poput htop-a u načinu rada niti, prikazujući jednu ili više niti za snimanje (pcap, AF_PACKET ili NFQ) i veliki broj niti za detekciju raspoređenih po jezgrama. Podešavanje omjera niti za detekciju i afiniteta CPU-a može značajno utjecati na propusnost i latenciju kada se obim prometa približi ograničenjima platforme.
Prije implementacije u produkciju, preporučljivo je provesti neko vrijeme fino podešavajući koji se skupovi pravila aktiviraju kako biste izbjegli poplavu lažno pozitivnih rezultata koji bi mogli blokirati legitimni promet ili zatrpati zapisnike. Suricata-update vam omogućava da onemogućite cijele kategorije ili pojedinačna pravila kako biste pronašli razumnu ravnotežu između osjetljivosti i upotrebljivosti.
Specijalne primjene: VoIP, audio analitika i kreativni NFQUEUE
Pored klasičnih upotreba (zaštita web servisa, detekcija zlonamjernog softvera, DDoS analiza), Netfilter+NFQUEUE dvojac omogućava prilično kreativna rješenja u oblastima kao što je VoIP. Na primjer, moguće je postaviti anti-SPIT (spam preko IP telefonije) filter ili sistem za cenzurisanje psovki u RTP streamovima.
Ideja bi bila: identificirati RTP promet putem portova ili prepoznavanja protokola i poslati ga u NFQUEUE; iz korisničke aplikacije rekonstruirati RTP stream koristeći biblioteku poput librtp , izdvojiti audio u WAV formatu i proslijediti ga mehanizmu za prepoznavanje ključnih riječi (wordspotting), kao što je biblioteka za sintezu ili prepoznavanje koju nudi treća strana.
Na osnovu detektovanih riječi, NFQUEUE proces bi mogao odlučiti da dozvoli, blokira ili čak izmijeni reprodukciju umetanjem zvučnog signala u stream, iako ovo drugo zahtijeva vrlo finu kontrolu RTCP-a, sekvenci paketa i tajminga - gotovo pristup "čovjek u sredini". Nije trivijalno, ali teoretski je savršeno ostvarivo korištenjem istog sistema redova čekanja i presuda.
Istina je da se dio ovoga može uraditi jednostavnim snifferom koji šalje podatke vanjskom procesoru, a zatim djeluje na osnovu SIP signalizacije ili putem SBC-a (Asterisk, Kamailio, itd.). Razlika kod korištenja NFQUEUE-a je u tome što djelovanje na RTP tok može biti trenutno i direktno , bez potrebe za koordinacijom više komponenti ili čekanjem da signalni sloj završi poziv.
Ovi scenariji jasno ilustruju potencijal kombinacije GNU/Linux + Netfilter + Suricata + biblioteka trećih strana: ne radi se samo o blokiranju portova i IP adresa, već o orkestriranju složenih odluka o prometu u stvarnom vremenu korištenjem ekosistema 100% slobodnog softvera.
Posmatrajući cijeli proces, od malog C programa koji uvijek prihvata pakete do višeprocesnog Suricata implementacije integriranog s NFQUEUE, Pfsense, bazama podataka i keš memorijama, može se cijeniti fleksibilnost koju ovaj tehnološki paket nudi za izgradnju svega, od jednostavnih dinamičkih zaštitnih zidova do IDS/IPS arhitektura na nivou podatkovnih centara, sa stvarnim mogućnostima dubinske inspekcije i automatiziranim odgovorom na sve složenije napade.