- NFQUEUE võimaldab Netfilteril delegeerida filtreerimis- ja märgistamisotsused kasutajaruumi protsessidele, võimaldades dünaamiliste IP-tulemüüride ja ruuterite kasutamist.
- Suricata pakub mitmeprotsessilist IDS/IPS mootorit, mis toetab NFQUEUE-d, AF_PACKET-i ja reegleid, mis ühilduvad Snorti ja tekkivate ohtudega.
- NFQUEUE integreerimine Suricata, andmebaaside, Memcachedi või Pfsense'iga võimaldab teil luua täiustatud turva- ja marsruutimislahendusi tasuta tarkvara abil.
- Jõudlus sõltub suuresti lõimede disainist ja kasutajaruumi loogikast, mistõttu on oluline optimeerida ja hoolikalt valida kontrollitav liiklus.
Kui töötate GNU/Linuxil ( parimad Linuxi distributsioonid turvalisuse ja privaatsuse tagamiseks ) põhinevate võrkudega ja olete huvitatud tavapärasest staatilisest tulemüürist kaugemale minemisest, olete ilmselt uudishimulik, kuidas ühendada Netfilter, NFQUEUE ja Suricata, et luua tõeliselt paindlik IDS/IPS ilma varandust kulutamata patenteeritud riistvarale. Just seda valdkonda me selles artiklis uurimegi, ühendades madala taseme elemendid (kernel, järjekorrad, C) kõrgetasemeliste tööriistadega (Suricata, reeglid, MySQL, Memcached, pfSense).
Põhiidee on väga võimas: ära kasutada asjaolu, et kernel (vt. kuidas Linuxi kerneli optimeerida ) saab pakette kasutajaruumi järjekorda panna ja lasta kohandatud programmil otsustada, mida nendega teha. Seda saab kasutada liikluse filtreerimiseks (täiustatud tulemüür, IPS), dünaamiliseks marsruutimiseks või äriloogika integreerimiseks (andmebaasid, vahemälud, veebirakenduste rünnakute tuvastamine, VoIP jne). Ja kui lisada Suricata mitmeprotsessilise IDS/IPS mootorina, on meil väga tugev kombinatsioon keskkondade jaoks, alates laboritest kuni suure liiklusega andmekeskusteni.
NFQUEUE ja Netfilter: tulemüüri tõstmine kasutajaruumi
Tüüpilises GNU/Linuxi süsteemis kasutatakse Netfilteri/iptables'i (või nftables'i) reegleid tavaliselt staatiliste poliitikatena, mis asuvad täielikult kerneli ruumis . Frontend ja seadmed (sealhulgas paljud Netfilteril või BSD pakettfiltril põhinevad lahendused) salvestavad konfiguratsiooni teksti-, XML- või SQLite-failidesse ning kui midagi muutub, genereerivad ja laadivad nad reeglid uuesti. See on paindlik, kuid loogika jääb omamoodi tulemüüri hetktõmmiseks väikeste dünaamiliste muudatustega (ühenduste arvu piirangud sekundis, ühenduse jälgimine, riikide sobitamine, 7. kiht, kui see on saadaval jne).
NFQUEUE pakub välja mängumuutva funktsiooni: selle asemel, et kernel alati lõpliku otsuse langetaks, saame selle otsuse delegeerida kasutajaprotsessile . Kernel paneb paketi nummerdatud järjekorda ja libnetfilter_queue teeki kasutav rakendus otsib selle üles, analüüsib seda ja tagastab otsuse: kas aktsepteerida, hüljata või isegi märkida see poliitika marsruutimiseks. See on nagu programmeeritav "kohtunik", mis on kirjutatud C, Pythoni või Perli keeles tulemüüri peale.
Selle ilu seisneb selles, et meie programm saab sõna otseses mõttes teha kõike, mida me tahame: päringuid teha /dev/urandom'ile, andmebaasile, veebiteenusele, hajusvahemälule või keerukale algoritmile enne kernelile vastamist. Arhitektuurilisest küljest lakkab tulemüür olemast lihtne staatiliste reeglite kogum ja muutub torujuhtmeks, kus Netfilter, järjekorrad ja kasutajarakendused sobivad kokku nagu pusletükid.
NFQUEUE koosneb kahest osast: NFQUEUE sihtmärgist iptables'is , mis saadab paketid kindlasse järjekorda, ja libnetfilter_queue kasutajateegist , mis võimaldab teil neid pakette lugeda ja otsuse langetada. See ei ole lihtne nuusutaja nagu tcpdump: siin on meil võimalus otse otsustada paketi teekonna üle.
IpTablesi põhikonfiguratsioon NFQUEUE abil
IpTablesi vaatenurgast on NFQUEUE kasutamine üsna lihtne: lisad ahelale, mida soovid kasutada, reegli, mis saadab järjekorda pakette, mis vastavad teatud kriteeriumidele (lähte-/sihtkoha IP, pordid, olekud, lisamoodulid nagu GeoIP või layer7, kui need on saadaval jne).
Näiteks kui tahame saata NFQUEUE-le kõik pingid, mis hostile endale saabuvad:
iptables -I INPUT -p icmp -j NFQUEUE
See saadab sissetulevad ICMP paketid järjekorda 0 (kui pole teisiti täpsustatud). Võiksime määrata teise järjekorra millegi sarnasega nagu `--queue-num 3` . Reeglite loetlemisel loenduritega (`iptables -L -n -v -x`) näeme loendurite suurenemist, mis näitab, et pakette pannakse järjekorda . Oluline detail: kui järjekorras on pakette ja ükski kasutajaprotsess neid ei laadi ega töötle, siis vaikimisi keelatakse need, seega rakenduse tõrge põhjustab juba loodud liikluse blokeerimise.
Programmeerimine libnetfilter_queue vastu: „Tere maailm“ C-keeles
Kasutajaruumist järjekorda liitumiseks kasutatakse teeki libnetfilter_queue (mis omakorda tugineb libnfnetlinkile). Selliste distributsioonide nagu Debian puhul installige lihtsalt arenduspaketid:
apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc
Minimaalse programmi, mis alati pakette vastu võtab, skelett koosneb mõnest väga selgest sammust: avage teeki, eemaldage olemasolevad käitlejad, siduge AF_INET protokolliga, looge järjekord tagasihelistusfunktsiooniga, defineerige kopeerimisrežiim ja sisenege vastuvõtutsüklisse . Tagasihelistus teostatakse iga järjekorras oleva paketi jaoks, ekstraheerides ID ja tagastades otsuse.
Praktikas näeb voog välja umbes selline: `nfq_open` käepideme saamiseks, `nfq_unbind_pf` selle puhastamiseks, `nfq_bind_pf` seostamiseks AF_INET-iga, `nfq_create_queue` tagasihelistamise registreerimiseks järjekorras 0, `nfq_set_mode` näitamiseks, kas soovime metaandmeid või tervet paketti, tsükkel `recv()`-ga deskriptori kohal ja `nfq_handle_packet` iga paketi töötlemiseks . Väljumisel hävitatakse järjekord `nfq_destroy_queue`-ga ja käepide suletakse `nfq_close`-ga.
Selline "tere maailm" võimaldab NFQUEUE mõju selgelt mõõta. Kui me näite kompileerime millegi sellisega nagu:
gcc -o nftest kood.c -lnfnetlink -lnetfilter_queue
Ja kui me paneme iperfist tuleva liikluse järjekorda (näiteks TCP port 5001 INPUT ja OUTPUT väljadel), näeme, et kood, mis lihtsalt pakette aktsepteerib, mõjutab gigabiti võrgus jõudlust vaevu . Siiski on üks oluline detail: teabe printimine tagasihelistuses (printf, fflush jne) vähendab oluliselt läbilaskevõimet, nagu on näha iperfi võrdlemisel ekraani silumisega ja ilma selleta.
Täiustatud NFQUEUE valikud: möödaviik, tasakaal ja avamisviga
NFQUEUE sisaldab mitmeid huvitavaid iptables'i valikuid, mis muudavad järjekordade vaikekäitumist ja mida tuleks teada enne tootmis- või suure jõudlusega keskkonda sisenemist, kuna need mõjutavad kasutajarakenduste tõrgete või järjekordade täitmise käsitlemist.
Käsk `--queue-bypass` võimaldab tagada, et kui ükski protsess järjekorda ei kuula, siis pakette ei kaotata, vaid need edastatakse iptables'i ahela järgmisele hüppele. See võib olla kasulik, kui soovite, et süsteem "avaneks ebaõnnestunult", kui kasutajateenus pole saadaval, kuigi turvalisuse seisukohast on see kahe teraga mõõk.
Valik `--queue-balance` võimaldab jaotada pakette erinevate järjekordade vahel (näiteks 0 kuni 3) ja seejärel kasutada iga järjekorda mitmel sõltumatul protsessil või lõimel . Netfilteri kood tagab, et sama voo paketid satuvad alati samasse järjekorda, mis lihtsustab oluliselt otsustusloogika järjepidevuse säilitamist.
Samuti on olemas režiim `--fail-open` , mis kontrollib, mis juhtub siis, kui järjekord täitub kasutajaprotsessi liiga aeglase töö tõttu. Selle lubamine paneb kerneli pakette otse vastu võtma, selle asemel et neid ära visata, hoides ära ulatuslikke liiklushäireid. Jällegi võib see olla turvaprobleem, sest kui tahame otsuseid teha iga juhtumi puhul eraldi, tähendab otsustuspakettide kaotamine selle eesmärgi mittetäitmist.
Järjekordadega toimuva jälgimiseks avaldab Netfilter teavet pseudo-fs-is /proc/net/netfilter/nfnetlink_queue , mida saab skriptide või jälgimisvahendite abil hõlpsalt pärida.
Äriloogika integreerimine: testimine Memcachedi ja MySQL-iga
Kui „tere maailm“ protsess on kontrolli all, on järgmine loomulik samm rikastada tagasihelistamist kõnedega välistele süsteemidele . Tüüpiline eksperiment hõlmab paketi vastuvõtmise või tagasilükkamise otsustamist selle põhjal, kas allika IP-aadress ilmub mõnes taustsüsteemis, näiteks MySQL-i andmebaasis või Memcached-vahemälus.
Memcachedi puhul installitakse deemon (apt-get install memcached) ja laaditakse võti, näiteks authorized , koos meid huvitava IP-aadressiga. Seda saab teha lihtsa echo ja netcat abil ning seejärel kontrollida get käsuga, kas väärtus on õigesti salvestatud. Sealt edasi võtab NFQUEUE programm lisaks paketi ID hankimisele vastu kogu paketi, kasutades NFQNL_COPY_PACKET , eraldab IP-päise (struct iphdr) ja teisendab lähteaadressi stringiks inet_ntop abil.
Et vältida iga paketiga ühenduste avamisele aja raiskamist, initsialiseeritakse Memcached-ühendus ainult üks kord põhimeetodis (memcached_create, memcached_server_list_append, memcached_server_push) ja käitleja salvestatakse globaalsetesse muutujatesse. Tagasihelistamise käigus kutsutakse memcached_get soovitud võtmega, allika IP-aadressi võrreldakse hangitud väärtusega ja kui need ühtivad, tagastatakse NF_ACCEPT; vastasel juhul tagastatakse NF_DROP. Kui võtit pole olemas või on tegemist veaga, siis pakett konservatiivse poliitika kohaselt eemaldatakse.
iperf-strateegiat kasutades vähendab see strateegia läbilaskevõimet gigabitisel võrgul ligikaudu 140 Mbit/s-ni ning on täheldatud, et järjekorras hakkavad tekkima kadud (mida näitavad näiteks sümbolid koodis endas). Teisisõnu, juba ainuüksi vahemäluteenuse kutsumine iga paketi kohta toob kaasa märkimisväärse kulu, kuigi optimeerimise korral on see keskmise liiklusmahu korral endiselt teostatav.
MySQL-i puhul on lähenemine sarnane, kuid keerukam: installitakse serveri ja kliendi teek, luuakse andmebaas (näiteks nfqueue) lihtsa tabeliga nimega authorized(ip varchar(50)) ja sisestatakse lubatud IP-aadress. Programmis käivitatakse `mysql_init` ja `mysql_real_connect` ning tagasihelistusfunktsioonis luuakse päring, näiteks `select * from authorized where ip like 'xxxx'`. Kui päring käivitub edukalt ja rida leitakse, aktsepteeritakse pakett; vastasel juhul see visatakse ära.
Kui MySQL-i päringute vahemällu salvestamine on lubatud, annavad testid umbes 188 Mbit/s , mis langeb 103 Mbit/s-ni, kui päringute vahemällu salvestamine on keelatud. Need arvud, mis pole kaugeltki gigabittides, näitavad, et isegi kõige vähem elegantse lähenemisviisiga (ühelõimeline, ilma optimeerimiseta) saab andmebaasipõhiste või vahemällu salvestamise põhiste otsuste abil hallata arvestatavaid liiklusmahtusid.
Jõudlus, mitmekeermelisus ja protsessori kasutus
Testid iperfi, Memcachedi ja MySQL-iga näitavad selgelt, et jõudluse ülempiiri ei sea mitte niivõrd NFQUEUE ise, kuivõrd kasutajaruumi lisatav loogika ja selle rakendamise viis. Käivitatav fail, mis tagastab ainult NF_ACCEPT väärtuse, saavutab peaaegu gigabiti ilma suurema vaevata; niipea kui lisame I/O või võrgukõned, langeb läbilaskevõime ja NFQUEUE masina, Memcachedi deemoni või MySQL-i protsessori koormus on viidud oma piirini.
Arhitektuurilisest vaatenurgast on sellel kaks tagajärge. Ühelt poolt kinnitab see, et tulemüüri otsuste delegeerimine kasutajarakendustele märkimisväärse liiklusmahu korral on täiesti teostatav , eeldusel, et iga kõne tegelikke kulusid võetakse arvesse. Teisest küljest näitab see, et platvormi maksimaalsete võimaluste saavutamiseks tuleb kaaluda mitmekeermelist või mitmeprotsessorilist lähenemist . NFQUEUE võimaldab liiklust jaotada mitme järjekorra vahel; me saaksime käivitada mitu rakenduse koopiat, millest igaüks kuulab erinevat järjekorda, ja kasutada mitut südamikku ilma p-lõimede või massiivsete hargnemiste vaevata.
Teine ilmne optimeerimine oleks piirata NFQUEUE-d läbiva liikluse hulka . Testides oli kogu iperf-voog järjekorras, kuid reaalses stsenaariumis saaksime järjekorda panna ainult UUE olekuga pakette, lubada läbida loodud/seotud pakette ja reserveerida kalli loogika sisselogimiste või kahtlaste mustrite jaoks.
Lõppkokkuvõttes on protsessori kasutus ja lõimede disain võtmetähtsusega: kui kasutajaprotsess jääb vajaka, täitub järjekord ja peame kasutama selliseid asju nagu tõrkeavamine või tellimuste tühistamine, kaotades osa peenest kontrollist, mida see lähenemisviis taotleb.
Dünaamiline marsruutimine Netfilteri kaubamärgiga
NFQUEUE ei piirdu pelgalt "accept" või "throw" ütlemisega. Seda saab kasutada ka Netfilteri (fwmark) lippude rakendamiseks pakettidele ning nende kombineerimiseks ip-reegli ja iproute2-ga, et luua väga paindlikke ja peaaegu kergekaalulisi VRF-stiilis poliitilise marsruutimise skeeme.
Laias laastus oleks protseduur järgmine: defineerige failis /etc/iproute2/rt_tables mitu marsruutimistabelit , näiteks aeglane ja kiire; määrake igale tabelile erinev vaikemarsruut (üks fiibervõrgu kaudu ja teine piiratuma lingi kaudu); kasutage ip-reeglit, et määrata, et fwmark 1-ga paketid lähevad kiiresse tabelisse, fwmark 2-ga paketid aeglasesse tabelisse jne; ja lõpuks kasutage NFQUEUE-d, et märgistada paketid enne otsuse tagastamist vastavalt.
Tagasihelistusmeetmest otsuse määramiseks kasutatakse funktsiooni `nfq_set_verdict2` , mis on sarnane funktsiooniga `nfq_set_verdict`, aga võimaldab määrata otsuse väärtuse, mida `ip rule` seejärel näeb. Kõike seda kombineerides saab luua IP-ruuteri, mis otsustab, kuhu suunata, suvaliste kriteeriumide alusel: alates absurdsetest asjadest nagu paaris-/paaritu paketi suurus kuni väliste sisenditeni, nagu liikluse ennustamise algoritmid, sotsiaalmeedia sündmused või jälgimissüsteemide signaalid.
Tulemuseks on süsteem, kus tuum jätkab pakettide edastamist tavapärase kiirusega, kuid iga voo täpne tee delegeeritakse välisele tarkvarale , mis saab reaalajas meelt muuta ilma staatilisi reegleid muutmata.
NFQUEUE ja Suricata: kõrgetasemeline IPS GNU/Linuxis
Kõike eelnevat saab käsitsi C-keeles programmeerida, aga sissetungimise tuvastamise ja süvapaketikontrolli puhul on mõistlikum valik tavaliselt loota küpsele IDS/IPS-mootorile . Siin tulebki mängu Suricata, mis sündis just Snorti mitmeprotsessilise alternatiivina, pakkudes algusest peale IPS-võimalusi ja keskendudes tugevalt tänapäeval saadaolevate paljude protsessori tuumade ärakasutamisele.
Suricata on kirjutatud nullist ja levitatakse GPLv2 litsentsi alusel ; Open Information Security Foundation (OISF) haldab nii mootorit kui ka üsna ulatuslikku reeglite ja dokumentatsiooni ökosüsteemi. Erinevalt Snort 2.x-st, mis päris ühelõimelise tuuma ja sellele lisati paika, oli Suricata loodud jagama töökoormust mitme lõime vahel: püüdmine, dekodeerimine, tuvastamine ja väljund, kasutades erinevaid koormuse jagamise strateegiaid.
Funktsionaalsel tasandil pakub Suricata natiivset tuge IPv6-le, 7. kihi kontrollile (väga täiustatud HTTP HTP teeki kaudu), portidest sõltumatule protokollituvastusele , voo rekonstrueerimisele ja väga võimsale seansimuutujate (voobittide) süsteemile, et korreleerida rünnaku erinevaid etappe mitme TCP-ühenduse vahel.
Täiendavaks tugevuseks on selle ühilduvus Snorti reeglitega ja võime kasutada nii Sourcefire VRT kui ka Emerging Threats signatuurikomplekte (tasuta ET Open ja kommerts ET Pro versioonid). Lisaks ekspordib see sündmusi väga kasulikes vormingutes (fast.log, JSON eve.json-failis) integreerimiseks SIEM-ide, ELK, Splunki ja teiste süsteemidega.
Suricata IPS-ina Linuxis: püüdmisrežiimid ja NFQUEUE
GNU/Linuxis saab Suricata töötada erinevates režiimides, olenevalt sellest, kuidas liiklust pealt kuulatakse: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech ... Igal neist on oma eelised ja nõuded. Puhtal IPS-i tasandil on kaks kõige olulisemat NFQUEUE ja AF_PACKET.
NFQ (NFQUEUE) režiimis on voog sarnane eelnevalt kirjeldatule: iptables'i reeglite komplekt saadab paketid järjekorda; kasutajaruumis töötav Suricata loeb sellest järjekorrast, kontrollib sisu vastavalt oma reeglitele ja tagastab kernelile otsuse: NF_ACCEPT, NF_DROP või NF_REPEAT. Kolmandat saab kasutada paketi uuesti samasse iptables'i tabelisse lisamiseks pärast täiendavate märkide või muudatuste rakendamist.
See režiim on väga paindlik ja olemasolevates infrastruktuurides hõlpsasti rakendatav , kuna see nõuab reeglite muutmist ainult kindlates punktides (näiteks FORWARD, INPUT, OUTPUT) ja kõik muu muutmata jätmist. Maksumus seisneb pakettide NFQUEUE kaudu üles ja alla saatmise lisakuludes, millel on eelpool mainitud mõju, kui maht on väga suur või reeglid on ressursimahukad.
AF_PACKET režiimis töötab Suricata võrguliidesele lähemal, kopeerides pakette AF_PACKET soklite kaudu. See on palju kiirem koopiateta lähenemine , kuid see nõuab süsteemi toimimist kahe liidesega väravana ja liikluse blokeerimist võrgukaartide vahelisel edasisuunamise tasemel: blokeeritavat paketti lihtsalt ei edastata sisendliideselt väljundliidesele.
Mõlemas režiimis saab Suricatat kombineerida Netfilteriga, kuid NFQUEUE sobib eriti hästi stsenaariumidesse, kus soovime taaskasutada kogu iptables'i loogikat (poliitikad, vahemikud, eelmised reeglid) ja saata Suricatale ainult liiklust, mida soovime põhjalikult uurida.
Suricata põhiline paigaldamine lähtekoodist
Neile, kes eelistavad Suricata kompileerimist pakettide asemel, hõlmab Debiani/Ubuntu-tüüpi distributsioonide protsess esmalt kompileerimissõltuvuste (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev jne) installimist, ametlikult veebisaidilt tarballi allalaadimist ja klassikalise ./configure, make, make install käivitamist.
Konfigureerimisetapis näitab skript, millised tugifunktsioonid on lubatud: AF_PACKET jah/ei, PF_RING, NFQUEUE jah/ei, NFLOG, IPFW, tugi libnss-ile, libjanssonile, Prelude'ile, PCRE JIT-ile, Lua-le, GeoIP-le jne. Selles režiimis töötamiseks on oluline veenduda, et NFQUEUE on lubatud ja et meid huvitav püüdmisteek on leitud.
Pärast binaarfaili installimist saate käivitada käsu `make install-conf` , et juurutada vaikekonfiguratsioon kausta `/etc/suricata`, ja käsu `make install-rules` , et alla laadida ja paigutada kausta `/etc/suricata/rules` tekkivate ohtude reeglite komplekt. Neid komplekte saab seejärel värskendada selliste tööriistadega nagu `suricata-update`.
Red Hat/CentOS süsteemides on loogika sarnane, kasutades sõltuvuste (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel jne) jaoks käsku yum või dnf ja seejärel kompileerides samade sammudega. Jõudluse huvides on soovitatav keelata ka LRO/GRO püüdmisliideses ethtooli abil, kuna need mahalaadimisfunktsioonid võivad mõjutada pakettide nähtavust IDS-i tasandil.
Suricata konfiguratsioon: YAML, muutujad ja lõimestamine
Suricata peamine konfiguratsioon asub failis /etc/suricata/suricata.yaml . See on üsna loetav ja rohkelt kommenteeritud YAML-fail, kus on määratletud kõik alates logiteedest ja reeglistikest kuni sihtoperatsioonisüsteemi poliitikate ja lõimeparameetriteni.
Üks põhiväljadest on `default-log-dir` , mis määrab logifailide salvestamise koha (vaikimisi `/var/log/suricata`). `vars` jaotise all on muutujad nagu `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` ja `SSH_PORTS`, mis toimivad reeglites lühenditena. `HOME_NET` konfigureeritakse tavaliselt kohaliku võrgu vahemikuga, mida soovitakse kaitsta, samas kui `EXTERNAL_NET` on tavaliselt defineeritud kui `!HOME_NET`.
Teine oluline osa on host-os-policy , mis ütleb Suricatale, milline operatsioonisüsteem peaks teatud IP-vahemikke käitama. See võimaldab tal kohandada TCP uuesti kokkupanekut või teatud võrgupinu käitumist , muutes protokollidest kõrvalehoidmise pinude erinevuste (Windows vs Linux jne) põhjal raskemaks. Konkreetseid vahemikke saab määrata kategooriatele nagu Windows, Linux, BSD, Vista, Windows 2003 jne.
Mis puutub lõimedesse, siis lõimede jaotis võimaldab teil täpsustada protsessori afiinsust ja tuvastuslõimede arvu. Vaikimisi on `set-cpu-affinity` tavaliselt keelatud, mis võimaldab süsteemi ajastajal jaotada lõime tuumade vahel. Parameeter `detect-thread-ratio` näitab, mitu tuvastuslõime luuakse iga saadaoleva tuuma kohta; kui `detect-thread-ratio: 1.5` on 8-tuumalises masinas, genereerib Suricata 12 tuvastuslõime, lisaks püüdmis- ja halduslõimesid.
Kogu see mudel kajastub seejärel deemoni käivitamisel väljundis: lisaks voohalduritele ja statistikahalduritele on nähtav püüdmislõim (näiteks pcap) ja mitu detektorlõimi. See mitmeprotsessiline arhitektuur võimaldab Suricatal 10/40 Gbit/s linkide puhul palju paremini skaleeruda kui ühelõimelistel mootoritel.
Reeglid ja allkirjade uuendused Suricatas
Suricata tugineb rünnakumustrite, anomaalse käitumise ja protokolli väärkasutuse tuvastamiseks reeglistikele. Lisaks Snort-vormingus reeglite aktsepteerimisele on kõige levinum ökosüsteem Emerging Threats: ET Open (tasuta) ja ET Pro (kommertsversioon), mille reeglid on suunatud praegustele ohtudele.
Paljud tänapäevased distributsioonid sisaldavad tööriista `suricata-update` , mis lihtsustab reeglite haldamist: see uuendab allikaid, lubab või keelab teatud pakkujaid ja laadib alla signatuurikomplektide uusimad versioonid. Tüüpiline töövoog oleks `suricata-update` installimine (näiteks pip-i kaudu), esimese `suricata-update` käivitamine ET Openi allalaadimiseks, allikate loetlemine käsuga `suricata-update list-sources`, täiendavate allikate (nt `ptresearch/attackdetection`, `oisf/trafficid` või `sslbl/ssl-fp-blacklist`) lubamine ja `suricata-update` uuesti käivitamine reeglite faili taastamiseks.
Faili suricata.yaml kohandatakse nii, et see osutaks õigele reeglite teele, ja sealt edasi hakkab Suricata genereerima häireteateid, mis logitakse failidesse fast.log (kiire, loetav tekst) ja eve.json (struktureeritud JSON väga täieliku teabega) . Viimane vorming on eriti kasulik armatuurlaudade, korrelatsioonisüsteemide või kohandatud skriptide jaoks.
Lisaks signatuuridele sisaldab Suricata mitme protokolli dekoodreid ja parsereid , mis vähendab selle sõltuvust portidest: see suudab tuvastada HTTP-liiklust isegi siis, kui see läbib mittestandardseid porte, tuvastada SSH, TLS, DNS jne erinevate portide ja kapseldustasemete (sh segatud IPv4/IPv6 tunnelite) kaudu.
Praktiline kasutus: veebirünnakute tuvastamisest automaatse blokeerimiseni
Üks ihaldatumaid kasutusjuhtumeid majutuskeskkondades või andmekeskustes on reaalajas tuvastada katseid veebirakenduste (nt WordPress ja selle pluginad) haavatavuste ärakasutamiseks ja automaatselt reageerida, tavaliselt allika IP blokeerimise või tulemüüri musta nimekirja lisamise teel.
Suricata, mida toidavad uuendatud reeglid, suudab ära tunda spetsiifilisi rünnakumustreid URL-ide, parameetrite, HTTP-koormuste ja isegi päringute järjestuste vastu, mis vastavad teadaolevatele rünnakutele. IDS saab töötada passiivses režiimis, võttes liiklust vastu kommutaatori pordi (SPAN) peegeldamise kaudu, kuid IPS-ina toimimiseks ja rünnakute blokeerimiseks tuleb see integreerida edasisuunamistasandiga.
On kaks levinud lähenemisviisi: IDS-i seadistamine võrgusillana , nii et liiklus läbib füüsiliselt masinat (kasutades iptables'i, AF_PACKET'i või PF-i, olenevalt platvormist) või topoloogia jätmine samaks, kuid peegeldamise kombineerimine toimingutega keskse tulemüüri kaudu API, skriptide või NFQUEUE kaudu . Esimene lähenemisviis minimeerib tuvastamise ja blokeerimise vahelist latentsust, lisades võrgu "keskele" veel ühe elemendi; teine pakub suuremat paindlikkust ja vastupidavust, kuid toob orkestreerimisse rohkem keerukust.
On täiesti teostatav, et sissetungimise tuvastamise süsteem (IDS) tuvastab katse kasutada haavatavat WordPressi pluginat ja seejärel, kas otse või seotud komponendi kaudu, lisab ründaja IP-aadressi iptables'i musta nimekirja. Seda saab teha Suricata JSON-väljundi ja iptables/nftables'i kutsuvate skriptide kaudu või delegeerides osa loogikast NFQUEUE-le, kus mootor ise või seotud protsess teeb otsuse lennult, ootamata välise nimekirja värskendamist.
See võimaldab teil keskenduda ohtudele, mis on tõeliselt olulised (ärakasutamised, eskaleerimiskatsed, väga agressiivsed skaneeringud), ignoreerides või lihtsalt logides taustamüra, näiteks põhilisi portide skaneeringuid, mis paljudes kontekstides iseenesest murettekitavad ei ole.
Suricata Pfsense'is: avatud lähtekoodiga tulemüür integreeritud IDS/IPS-iga
Mitte igaüks ei saa ega taha endale lubada sellist patenteeritud tipptasemel tulemüüri nagu Palo Alto. Paljudes keskkondades on atraktiivsem luua avatud lähtekoodiga lahendus pfSense'i ja Suricata abil , mis katab nii täiustatud tulemüüri vajadused (multi-WAN, VLAN, VPN, NAT jne) kui ka IDS/IPS.
FreeBSD-l ja Packet Filter'il põhinev Pfsense töötab eriti hästi virtualiseeritud keskkondades (Proxmox, KVM jne), erandiks on see, et KVM-masinates on jõudlusprobleemide ja koormuse all tekkivate krahhide vältimiseks soovitatav Virtio asemel kasutada E1000 kaarte, välja arvatud juhul, kui rakendate Netgate'i soovitusi (keelate riistvara kontrollsumma mahalaadimise menüüs System > Advanced > Networking ja taaskäivitate arvuti, teades, et väga suurte koormuste korral ei pruugi sellest piisata).
Suricataga Pfsense'is töötava labori minimaalsed riistvaranõuded võivad olla tagasihoidlikud (1 protsessor 500 MHz, 1 GB muutmälu, 4 GB ketast), kuid tõsiseks kasutamiseks on soovitatav vähemalt 2 protsessorit, 4 GB muutmälu ja 16 GB salvestusruumi , unustamata seejuures mitme võrguliidese olemasolu (üks WAN-i, teine LAN-i jaoks ja rohkem, kui soovite mitut WAN-i või keerukat VLAN-i).
pfSense'i installimine ise on väga kiire: käivitate ISO-lt, nõustute litsentsitingimustega, valite installimise, valite keele ja klaviatuuripaigutuse, jätate partitsioonimise automaatseks (automaatne UFS, kui kavatsete kasutada kogu ketast) ja mõne minuti pärast on süsteem esimeseks käivitamiseks valmis. Konsool pakub menüüd liideste määramiseks, taaskäivitamiseks, shelli käivitamiseks jne.
Laboris, näiteks VirtualBoxis, on tavaline, et Pfsense'i tulemüür konsoolist ajutiselt keelatakse käsuga pfctl -d, et pääseda ligi veebiliidesele WAN-i kaudu (kasutajanimi admin, parool pfsense) ja läbida esialgne viisard: üldandmed, NTP-serverid, WAN-i konfiguratsioon (laboris piisab tavaliselt DHCP-st), LAN, administraatori parooli muutmine ja konfiguratsiooni rakendamine.
Kui juurdepääs on stabiliseerunud, saate luua WAN-tulemüüris reegli, mis lubab HTTPS-i mis tahes allikast pfSense'i IP-aadressile, lisades reeglite visuaalseks korraldamiseks kirjeldavaid eraldajaid (näiteks "Tulemüüri juurdepääs"). Samuti on soovitatav keelata WAN-võrgu privaatvõrkude blokeerimise valik, kui olete testkeskkonnas RFC1918 aadressidega, et vältida pidevat `pfctl -d` kasutamist.
Suricata installimine pfSense'i ja ülevaade
Kui pfSense'i baas on käivitatud, on Suricata installimine sama lihtne kui minna Süsteem > Paketihaldur > Saadaval olevad paketid , otsida Suricata ja installida pakett. Protsess laadib alla mitu faili ja võib teie riistvarast olenevalt võtta aega, kuid seda abistatakse täielikult veebiliidese kaudu.
Pärast installimist ilmub vahekaardile Teenused Suricata kirje, kus saate konfigureerida eksemplare liidese (WAN, LAN, VLAN jne) järgi, valida, milliseid reeglistikke kasutada, aktiveerida IDS-i või IPS-režiimi ning reguleerida jõudlus- ja logimisparameetreid. Valikute valik on ulatuslik (piisab tervete artiklite kirjutamiseks ainult konfigureerimise kohta), kuid eeliseks on see, et paljusid ülesandeid, mis Linuxis nõuavad YAML-i käsitsi redigeerimist, käsitletakse siin vormide ja märkeruutude abil.
Oluline märkus: Kuigi laborikeskkonnas võib tunduda ahvatlev avada pfSense'i administratsioon otse internetiga, on tootmiskeskkonnas ülioluline piirata juurdepääsu staatiliste IP-aadressidega, kasutada kaughalduseks VPN-e ja vältida veebikonsooli iga hinna eest paljastatuna jätmist . pfSense on väga paindlik, kuid seda tuleb käsitleda ka kriitilise elemendina, mis see on.
Kui Suricata on pfSense'is lubatud, saate keskkonna, kus liiklus läbib tulemüüri ja NAT-i jaoks pfSense'i ning Suricata kontrollib seda oma reeglite kohaselt ja saab selle IPS-režiimis blokeerida . See ühest veebiliidesest hallatav kombinatsioon lihtsustab oluliselt DPI-kaitse juurutamist väikestes ja keskmise suurusega võrkudes.
Paljudes juurutustes täiendab seda Pfsense/Suricata ühendus SIEM-i või tsentraliseeritud logiplatvormiga, kasutades ära struktureeritud väljundvorminguid sündmuste korreleerimiseks ja laiemate kampaaniate tuvastamiseks.
Sündmuste jälgimine ja näidislogid Suricatas
Kui Suricata töötab, logitakse sündmused vaikimisi logikataloogi määratud teele, tavaliselt /var/log/suricata . Fast.log-fail kasutab kompaktset tekstivormingut, mis sisaldab ajatempli, reegli ID-sid, klassifikatsioone ja prioriteeti, mis sobib kiireks kontrollimiseks terminalist (tail -f).
Näiteks valede TCP kontrollsummadega liikluse korral võime näha selliseid ridu: ajatemplid kuupäeva ja kellaajaga, millele järgneb reegli identifikaator (nt 1:2200074:1), teade "SURICATA TCPv4 kehtetu kontrollsumma", klassifikatsioon, prioriteet ja lähte-sihtkoha IP/pordi paar. Sellised hoiatused võimaldavad kiiresti tuvastada pakettide terviklikkuse probleeme või varguskatseid.
Fail eve.json sisaldab samu sündmusi JSON-vormingus, millel on sellised väljad nagu timestamp, event_type, src_ip, dest_ip, src_port, dest_port, proto ning hoiatuse alamfail koos action, gid, signature_id, rev, signature, category ja severity väljadega. Seda vormingut saab hõlpsasti kasutada Logstash, Fluentd, Filebeat või mis tahes muu logiagent , mis võimaldab palju rikkalikumat analüüsi kui lihtsalt lihtteksti kasutamine.
Suricata juurutamisel mitmetuumalisele serverile (nt 8 tuumaga) on lõimede tihendamine tööriistades nagu htop lõimerežiimis kergesti nähtav, kuvades ühte või mitut püüdmislõime (pcap, AF_PACKET või NFQ) ja suurt hulka tuvastuslõimesid, mis on jaotatud tuumade vahel. Tuvastuslõimede suhte ja protsessori afiinsuse reguleerimine võib oluliselt mõjutada läbilaskevõimet ja latentsust, kui liikluse maht läheneb platvormi piiridele.
Enne tootmiskeskkonda juurutamist on soovitatav kulutada aega reeglite aktiveerimise täpsustamisele , et vältida valepositiivsete tulemuste tulva, mis võib blokeerida legitiimset liiklust või logisid risustada. Suricata-update võimaldab teil keelata terveid kategooriaid või üksikuid reegleid, et leida mõistlik tasakaal tundlikkuse ja kasutatavuse vahel.
Spetsiaalsed rakendused: VoIP, helianalüüs ja loominguline NFQUEUE
Lisaks klassikalistele kasutusviisidele (veebiteenuste kaitse, pahavara tuvastamine, DDoS-i analüüs) pakub Netfilter+NFQUEUE duo üsna loomingulisi lahendusi sellistes valdkondades nagu VoIP. Näiteks on võimalik seadistada SPIT-vastane (spam over IP telephone) filter või süsteem RTP-voogudes roppuste tsenseerimiseks .
Idee oleks järgmine: tuvastada RTP-liiklus portide või protokollituvastuse abil ja saata see NFQUEUE-sse; kasutajarakendusest rekonstrueerida RTP-voog teeki (nt librtp) abil , eraldada heli WAV-vormingus ja edastada see märksõnade tuvastamise mootorile (sõnade tuvastamine), näiteks kolmanda osapoole pakutavale sünteesi- või tuvastamise teeki.
Tuvastatud sõnade põhjal võib NFQUEUE protsess otsustada taasesituse lubamise, blokeerimise või isegi muutmise, lisades voogu piiksu , kuigi viimane nõuab RTCP, pakettide järjestuste ja ajastuse väga peenhäälestatud juhtimist – peaaegu nagu mees-vahepealne lähenemine. See pole triviaalne, kuid teoreetiliselt on see täiesti saavutatav, kasutades sama järjekorra ja otsustussüsteemi.
On tõsi, et osa sellest saaks teha lihtsa nuusutaja abil, mis edastab andmed välisele protsessorile ja seejärel reageerib SIP-signaalile või SBC (Asterisk, Kamailio jne) kaudu. NFQUEUE kasutamise erinevus seisneb selles, et RTP-voo toiming saab olla kohene ja otsene , ilma et oleks vaja koordineerida mitut komponenti või oodata, kuni signaalimiskiht kõne lõpetab.
Need stsenaariumid illustreerivad selgelt GNU/Linuxi + Netfilteri + Suricata + kolmandate osapoolte teekide kombinatsiooni potentsiaali: asi pole ainult portide ja IP-aadresside blokeerimises, vaid keerukate liiklusotsuste tegemises reaalajas, kasutades 100% vaba tarkvara ökosüsteemi.
Vaadates kogu teekonda alates väikesest C-programmist, mis alati pakette vastu võtab, kuni mitmeprotsessilise Suricata juurutuseni, mis on integreeritud NFQUEUE, Pfsense'i, andmebaaside ja vahemäludega, on võimalik hinnata selle tehnoloogiapaketi paindlikkust kõige loomiseks alates lihtsatest dünaamilistest tulemüüridest kuni andmekeskuse mastaabis IDS/IPS arhitektuurideni, millel on tõelised süvakontrolli võimalused ja automaatne reageerimine üha keerukamatele rünnakutele.