- NFQUEUE leidžia „Netfilter“ deleguoti filtravimo ir žymėjimo sprendimus vartotojo erdvės procesams, įgalinant dinamines IP ugniasienes ir maršrutizatorius.
- „Suricata“ teikia daugiaprocesį IDS/IPS variklį, palaikantį NFQUEUE, AF_PACKET ir taisykles, suderinamas su „Snort“ ir kylančiomis grėsmėmis.
- NFQUEUE integravimas su „Suricata“, duomenų bazėmis, „Memcached“ arba „Pfsense“ leidžia kurti pažangius saugumo ir maršrutizavimo sprendimus naudojant nemokamą programinę įrangą.
- Našumas labai priklauso nuo gijų dizaino ir vartotojo erdvės logikos, todėl labai svarbu optimizuoti ir atidžiai pasirinkti tikrinamą srautą.
Jei dirbate su tinklais GNU/Linux ( geriausi Linux distribucijos saugumui ir privatumui užtikrinti ) ir norite peržengti įprastos statinės užkardos ribas, tikriausiai smalsu, kaip sujungti „Netfilter“, „NFQUEUE“ ir „Suricata“, kad būtų sukurtas tikrai lankstus IDS/IPS, neišleidžiant daug pinigų patentuotai įrangai. Būtent šią sritį ir nagrinėsime šiame straipsnyje, derindami žemo lygio elementus (branduolį, eiles, C) su aukšto lygio įrankiais („Suricata“, taisyklėmis, „MySQL“, „Memcached“, „pfSense“).
Pagrindinė idėja yra labai galinga: išnaudoti tai, kad branduolys (žr. kaip optimizuoti „Linux“ branduolį ) gali suskirstyti paketus į vartotojo erdvę ir leisti pasirinktinei programai nuspręsti, ką su jais daryti. Tai galima naudoti srauto filtravimui (pažangi užkarda, IPS), dinaminiam maršrutizavimui arba verslo logikos integravimui (duomenų bazėms, talpykloms, žiniatinklio programų atakų aptikimui, VoIP ir kt.). O jei pridėsime „Suricata“ kaip daugiaprocesį IDS/IPS variklį, turėsime labai patikimą derinį aplinkoms – nuo laboratorijų iki didelio srauto duomenų centrų.
NFQUEUE ir „Netfilter“: ugniasienės perkėlimas į vartotojo erdvę
Tipinėje GNU/Linux sistemoje „Netfilter“/„iptables“ (arba „nftables“) taisyklės paprastai naudojamos kaip statinės politikos, kurios yra visiškai branduolio erdvėje . Priekinės dalys ir įrenginiai (įskaitant daugelį sprendimų, pagrįstų „Netfilter“ arba BSD paketų filtru) saugo konfigūraciją teksto, XML arba SQLite failuose, o kai kas nors pasikeičia, jie iš naujo įkelia ir perkrauna taisykles. Tai lankstu, tačiau logika išlieka savotiška užkardos momentinė kopija su nedideliais dinaminiais pakeitimais (prisijungimų per sekundę apribojimai, prisijungimų stebėjimas, šalių atitikimas, 7 sluoksnis, jei yra, ir kt.).
NFQUEUE siūlo iš esmės keičiantį sprendimą: užuot visada priėmus galutinį sprendimą branduoliui, galime deleguoti šį sprendimą vartotojo procesui . Branduolys sunumeruoja paketą į eilę, o programa, naudodama libnetfilter_queue biblioteką, jį nuskaito, analizuoja ir pateikia verdiktą: priima, atmeta arba netgi pažymi maršrutizavimui pagal politiką. Tai tarsi programuojamas „teisėjas“, parašytas C, Python arba Perl kalbomis, ant užkardos.
Šios sistemos grožis yra tas, kad mūsų programa gali tiesiogine prasme daryti viską, ko norime: atlikti užklausą /dev/urandom, duomenų bazei, žiniatinklio paslaugai, paskirstytai talpyklai arba sudėtingam algoritmui prieš atsakydama į branduolį. Architektūrine prasme užkarda nustoja būti paprastu statinių taisyklių rinkiniu ir tampa konvejeriu, kuriame „Netfilter“, eilės ir vartotojo programos dera tarpusavyje kaip dėlionės dalys.
NFQUEUE sudaro dvi dalys: NFQUEUE taikinys iptables faile , kuris siunčia paketus į konkrečią eilę, ir libnetfilter_queue vartotojo biblioteka , kuri leidžia nuskaityti šiuos paketus ir pateikti verdiktą. Tai nėra paprastas snifferis kaip tcpdump: čia galime tiesiogiai nuspręsti, kuriuo keliu paketas keliaus.
Pagrindinė „iptables“ konfigūracija naudojant NFQUEUE
„iptables“ požiūriu, NFQUEUE naudojimas yra gana paprastas: prie jus dominančios grandinės pridedate taisyklę, kad į eilę būtų siunčiami paketai, atitinkantys tam tikrus kriterijus (šaltinio / paskirties IP, prievadai, būsenos, papildomi moduliai, pvz., „GeoIP“ arba „layer7“, jei yra ir kt.).
Pavyzdžiui, jei norime nusiųsti į NFQUEUE visus ping'us, kurie pasiekia patį kompiuterį:
iptables -I INPUT -p icmp -j NFQUEUE
Tai siunčia gaunamus ICMP paketus į 0 eilę (jei nenurodyta kitaip). Galėtume nurodyti kitą eilę, pvz., `--queue-num 3` . Pateikiant taisykles su skaitikliais (`iptables -L -n -v -x`), matysime, kad skaitikliai didėja, o tai rodo, kad paketai yra įtraukiami į eilę . Svarbi detalė: jei eilėje yra paketų ir joks vartotojo procesas jų negauna ir neapdoroja, numatytasis elgesys yra juos atmesti, todėl programos gedimas, pagal numatytuosius nustatymus, blokuoja srautą.
Programavimas naudojant „libnetfilter_queue“: „labas pasauli“ C kalba
Norint prisijungti prie eilės iš vartotojo erdvės, naudojama libnetfilter_queue biblioteka (kuri savo ruožtu remiasi libnfnetlink). Tokiuose distribuciniuose paketuose kaip „Debian“ tiesiog įdiekite kūrimo paketus:
apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc
Minimalistinės programos, kuri visada priima paketus, skeletas susideda iš kelių labai aiškių žingsnių: atidaryti biblioteką, atsieti visus esamus tvarkytuvus, susisieti su AF_INET protokolu, sukurti eilę su grįžtamojo ryšio funkcija, apibrėžti kopijavimo režimą ir pereiti į priėmimo ciklą . Atgalinis iškvietimas vykdomas kiekvienam eilėje esančiam paketui, išgaunant ID ir grąžinant verdiktą.
Praktiškai srautas yra maždaug toks: `nfq_open` – norint gauti rankenėlę, `nfq_unbind_pf` – jai išvalyti, `nfq_bind_pf` – susieti su AF_INET, `nfq_create_queue` – registruoti grįžtamąjį iškvietimą 0 eilėje, `nfq_set_mode` – nurodyti, ar norime metaduomenų, ar viso paketo, ciklas su `recv()` virš deskriptoriaus ir `nfq_handle_packet` – apdoroti kiekvieną paketą . Išeinant, eilė sunaikinama su `nfq_destroy_queue`, o rankenėlė uždaroma su `nfq_close`.
Šis „labas pasauli“ tipas leidžia aiškiai išmatuoti NFQUEUE poveikį. Jei pavyzdį kompiliuotume su kažkuo panašiu į:
gcc -o nftest kodas.c -lnfnetlink -lnetfilter_queue
O jei sudarysime eilę srautui iš „iperf“ (pavyzdžiui, TCP 5001 prievado INPUT ir OUTPUT), pamatysime, kad kodas, kuris tiesiog priima paketus, beveik neturi įtakos našumui gigabito tinkle . Tačiau yra viena svarbi detalė: informacijos spausdinimas grįžtamajame iškvietime (printf, fflush ir kt.) gerokai sumažina pralaidumą, kaip matyti lyginant „iperf“ su ekrano derinimu ir be jo.
Išplėstinės NFQUEUE parinktys: apėjimas, balansavimas ir atidarymas gedimo atveju
NFQUEUE apima keletą įdomių „iptables“ parinkčių, kurios keičia numatytąjį eilių elgesį ir apie kurias reikėtų žinoti prieš įeinant į gamybinę arba didelio našumo aplinką, nes jos turi įtakos tam, kaip tvarkomi vartotojo programos gedimai arba eilių užpildymas.
Komanda `--queue-bypass` leidžia užtikrinti, kad jei joks procesas neklauso eilės, paketai nebūtų išmetami, o persiunčiami į kitą „iptables“ grandinės etapą. Tai gali būti naudinga, jei norite, kad sistema „atidarytų klaidą“, kai vartotojo paslauga nepasiekiama, nors saugumo požiūriu tai yra dviašmenis kardas.
Pasirinkus `--queue-balance`, paketus galima paskirstyti po eilių diapazoną (pavyzdžiui, nuo 0 iki 3) ir turėti kelis nepriklausomus procesus arba gijas, kurios naudotų duomenis iš kiekvienos eilės . „Netfilter“ kodas užtikrina, kad paketai iš to paties srauto visada atsidurtų toje pačioje eilėje, o tai labai supaprastina sprendimų logikos nuoseklumo palaikymą.
Taip pat yra `--fail-open` režimas , kuris kontroliuoja, kas nutinka, kai eilė užsipildo dėl per lėto vartotojo proceso veikimo. Jį įjungus, branduolys tiesiogiai priima paketus, o ne juos atmeta, taip išvengiant didelių srauto sutrikimų. Vėlgi, tai gali būti saugumo problema, nes jei norime priimti sprendimus kiekvienu atveju atskirai, sprendimų paketų praradimas reiškia, kad šis tikslas nebus pasiektas.
Norėdamas stebėti eilių veiklą, „Netfilter“ pateikia informaciją pseudofaile „ /proc/net/netfilter/nfnetlink_queue“ , kurią galima lengvai gauti iš scenarijų arba stebėjimo įrankių.
Verslo logikos integravimas: testavimas naudojant „Memcached“ ir „MySQL“
Kai „labas pasauli“ procesas jau kontroliuojamas, kitas natūralus žingsnis yra praturtinti grįžtamąjį iškvietimą iškvietimais į išorines sistemas . Tipiškas eksperimentas apima sprendimą, ar priimti, ar atmesti paketą, remiantis tuo, ar šaltinio IP adresas yra kuriame nors serveryje, pvz., „MySQL“ duomenų bazėje arba „Memcached“ talpykloje.
„Memcached“ atveju diegiamas demonas („apt-get install memcached“) ir įkeliamas raktas, pavyzdžiui, „authorized“ , su mus dominančiu IP adresu. Tai galime padaryti naudodami paprastą „echo“ ir „netcat“, o tada patikrinti naudodami „get“ komandą, ar reikšmė teisingai išsaugota. Tada NFQUEUE programa, be paketo ID gavimo, gauna visą paketą naudodama NFQNL_COPY_PACKET , išskleidžia IP antraštę („struct iphdr“) ir konvertuoja šaltinio adresą į eilutę naudodama „inet_ntop“.
Kad negaištų laiko užmezgant ryšius su kiekvienu paketu, „Memcached“ ryšys inicijuojamas tik vieną kartą pagrindiniame metode („memcached_create“, „memcached_server_list_append“, „memcached_server_push“), o tvarkyklė saugoma globaliuose kintamuosiuose. Atgalinio iškvietimo metu „memcached_get“ iškviečiamas su norimu raktu, šaltinio IP adresas palyginamas su gauta reikšme ir, jei jie sutampa, grąžinama NF_ACCEPT; kitu atveju grąžinama NF_DROP. Jei rakto nėra arba įvyksta klaida, paketas išmetamas pagal konservatyvią politiką.
Naudojant „iperf“, ši strategija gigabito tinkle sumažina pralaidumą iki maždaug 140 Mbit/s ir pastebima, kad eilėje pradedami nuostoliai (tai rodo, pavyzdžiui, simboliai pačiame kode). Kitaip tariant, vien iškvietus talpyklos paslaugą kiekvienam paketui, išlaidos jau yra didelės, nors optimizuota ji išlieka tinkama ir esant vidutiniam srautui.
Su MySQL metodas panašus, bet sudėtingesnis: įdiegiama serverio ir kliento biblioteka, sukuriama duomenų bazė (pavyzdžiui, nfqueue) su paprasta lentele, vadinama authorized(ip varchar(50)), ir įterpiamas leidžiamas IP adresas. Programoje paleidimo metu vykdomi `mysql_init` ir `mysql_real_connect` , o grįžtamojo ryšio metu sukuriama užklausa, pvz., `select * from authorized where ip like 'xxxx'`. Jei užklausa sėkmingai vykdoma ir randama eilutė, paketas priimamas; kitu atveju jis atmetamas.
Įjungus „MySQL“ užklausų kaupimą talpykloje, testų metu gaunamas apie 188 Mbit/s greitis , kuris sumažėja iki 103 Mbit/s , kai užklausų kaupimas talpykloje išjungtas. Šie skaičiai, nors ir toli gražu ne gigabitai, rodo, kad net ir taikant mažiausiai elegantišką metodą (viengijas, be optimizavimo) , priimtini srauto kiekiai gali būti valdomi naudojant duomenų bazėmis arba talpykloje pagrįstus sprendimus.
Našumas, daugiasriegiškumas ir procesoriaus naudojimas
Testai su „iperf“, „Memcached“ ir „MySQL“ aiškiai rodo, kad našumo ribas lemia ne tiek pati NFQUEUE, kiek logika, kurią pridedame vartotojo erdvėje , ir jos įgyvendinimo būdas. Vykdomasis failas, kuris grąžina tik NF_ACCEPT, pasiekia beveik gigabitą be didelių pastangų; vos tik įvedame įvesties/išvesties arba tinklo iškvietimus, pralaidumas sumažėja, o NFQUEUE mašinos, „Memcached“ demono arba „MySQL“ procesoriaus apkrovos yra išstumiamos iki savo ribų.
Architektūriniu požiūriu tai turi dvi pasekmes. Viena vertus, tai patvirtina, kad užkardos sprendimų priėmimas vartotojų programoms esant dideliems srauto kiekiams yra visiškai įmanomas , jei atsižvelgiama į kiekvieno iškvietimo faktines išlaidas. Kita vertus, tai parodo, kad norint išnaudoti maksimalias platformos galimybes, reikia apsvarstyti daugiasriegį arba daugiaprocesinį apdorojimą . NFQUEUE leidžia paskirstyti srautą keliose eilėse; galėtume paleisti kelias savo programos kopijas, kurių kiekviena klausytųsi skirtingos eilės, ir išnaudoti kelis branduolius be pthreadų ar didelių išsišakojimų vargo.
Kitas akivaizdus optimizavimas būtų apriboti srautą, praeinantį per NFQUEUE . Testų metu visas „iperf“ srautas buvo įtrauktas į eilę, tačiau realiame pasaulyje galėtume įtraukti tik paketus su NEW būsena, leisti praeiti ESTABLISHED/RELATED paketams ir rezervuoti brangią logiką prisijungimams ar įtartiniems šablonams.
Galiausiai, pagrindiniai veiksniai yra procesoriaus naudojimas ir gijų dizainas: jei vartotojo procesas neatitinka reikalavimų, eilė užsipildo ir turime griebtis tokių dalykų kaip atidarymas gedimo atveju arba priėmimo atsisakymas, prarandant dalį tikslaus valdymo, kurio siekia šis metodas.
Dinaminis maršrutizavimas su „Netfilter“ prekės ženklu
NFQUEUE neapsiriboja vien tiesiog „accept“ arba „throw“ žodžiais. Jis taip pat gali būti naudojamas norint pritaikyti „Netfilter“ (fwmark) vėliavėles paketams ir sujungti jas su „ip rule“ ir „iproute2“, siekiant sukurti labai lanksčias, beveik lengvas VRF stiliaus politinio maršrutizavimo schemas.
Apskritai procedūra būtų tokia: /etc/iproute2/rt_tables faile apibrėžti kelias maršrutizavimo lenteles , pavyzdžiui, „lėtą“ ir „greitą“; kiekvienai lentelei priskirti skirtingą numatytąjį maršrutą (vieną per šviesolaidį, o kitą – per labiau ribotą ryšį); naudoti ip taisyklę, nurodant, kad paketai su „fwmark 1“ eitų į „greitojo“ lentelę, o su „fwmark 2“ – į „lėto“ lentelę ir t. t.; ir galiausiai naudoti NFQUEUE, kad paketai būtų atitinkamai pažymėti prieš grąžinant verdiktą.
Norint nustatyti verdiktą iš grįžtamojo ryšio, naudojama funkcija `nfq_set_verdict2` , kuri yra panaši į `nfq_set_verdict`, bet leidžia nustatyti verdikto reikšmę, kurią matys `ip rule`. Apjungus visa tai, galima sukurti IP maršrutizatorių, kuris nusprendžia, kur nukreipti, remdamasis savavališkais kriterijais: nuo absurdiškų dalykų, tokių kaip lyginis/nelyginis paketo dydis, iki išorinių įvesties duomenų, tokių kaip srauto prognozavimo algoritmai, socialinės žiniasklaidos įvykiai arba signalai iš stebėjimo sistemų.
Rezultatas – sistema, kurioje branduolys toliau persiunčia paketus įprastu greičiu, tačiau tikslus kiekvieno srauto kelias deleguojamas išorinei programinei įrangai , kuri gali persigalvoti realiuoju laiku, nepaliesdama statinių taisyklių.
NFQUEUE ir Suricata: aukšto lygio IPS GNU/Linux aplinkoje
Visa tai galima programuoti rankiniu būdu C kalba, tačiau kai kalbama apie įsilaužimų aptikimą ir giluminį paketų patikrinimą, protingiausias pasirinkimas paprastai yra pasikliauti brandžiu IDS/IPS varikliu . Čia praverčia „Suricata“, kuri gimė būtent kaip daugiaprocesė „Snort“ alternatyva, nuo pat pradžių turinti IPS galimybes ir didelį dėmesį skirianti daugelio šiandien prieinamų procesoriaus branduolių išnaudojimui.
„Suricata“ yra parašyta nuo nulio ir platinama pagal GPLv2 licenciją ; Atvirosios informacijos saugumo fondas (OISF) prižiūri ir variklį, ir gana išsamią taisyklių bei dokumentacijos ekosistemą. Skirtingai nuo „Snort 2.x“, kuri paveldėjo vieno gijos branduolį ir buvo į jį įdiegta, „Suricata“ buvo sukurta taip, kad darbo krūvis būtų padalintas tarp kelių gijų: fiksavimo, dekodavimo, aptikimo ir išvesties, naudojant skirtingas apkrovos paskirstymo strategijas.
Funkciniu lygmeniu „Suricata“ teikia vietinę IPv6 palaikymą, 7 lygmens patikrą (labai pažangų HTTP per HTP biblioteką), protokolų atpažinimą nepriklausomai nuo prievadų , srauto rekonstrukciją ir labai galingą sesijos kintamųjų (srauto bitų) sistemą, skirtą skirtingiems atakos, išplitusios per kelis TCP ryšius, etapams koreliuoti.
Papildomas privalumas yra suderinamumas su „Snort“ taisyklėmis ir galimybė naudoti tiek „Sourcefire VRT“, tiek kylančių grėsmių parašų rinkinius (nemokamą „ET Open“ ir komercinę „ET Pro“ versijas). Be to, įvykiai eksportuojami labai naudingais formatais („fast.log“, JSON faile „eve.json“), kad būtų galima integruoti su SIEM, ELK, „Splunk“ ir kitomis sistemomis.
„Suricata“ kaip IPS sistemoje „Linux“: fiksavimo režimai ir NFQUEUE
GNU/Linux sistemose „Suricata“ gali veikti skirtingais režimais, priklausomai nuo to, kaip perimamas srautas: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, „Napatech“ ... Kiekvienas turi savo privalumų ir reikalavimų. Grynuoju IPS lygmeniu du svarbiausi yra NFQUEUE ir AF_PACKET.
NFQ (NFQUEUE) režime srautas panašus į anksčiau aprašytą: „iptables“ taisyklių rinkinys siunčia paketus į eilę; „Suricata“, veikianti vartotojo erdvėje, nuskaito iš tos eilės, patikrina turinį pagal savo taisykles ir grąžina branduoliui verdiktą: NF_ACCEPT, NF_DROP arba NF_REPEAT. Trečiąjį režimą galima naudoti norint iš naujo įterpti paketą į tą pačią „iptables“ lentelę, pritaikius papildomus žymėjimus ar modifikacijas.
Šis režimas yra labai lankstus ir lengvai įdiegiamas esamose infrastruktūrose , nes taisykles reikia modifikuoti tik konkrečiuose taškuose (pavyzdžiui, FORWARD, INPUT, OUTPUT), o visa kita palikti taip, kaip yra. Kaina yra papildomos išlaidos, susijusios su paketų perdavimu aukštyn ir žemyn per NFQUEUE, turinčios minėtą poveikį, jei apimtis yra labai didelė arba taisyklės reikalauja daug išteklių.
AF_PACKET režimu „Suricata“ veikia arčiau tinklo sąsajos, kopijuodama paketus per AF_PACKET lizdus. Tai daug greitesnis nulinės kopijavimo metodas , tačiau jam reikia, kad sistema veiktų kaip šliuzas su dviem sąsajomis ir kad srauto blokavimas būtų atliekamas persiuntimo lygmeniu tarp tinklo plokščių: blokuojamas paketas tiesiog neperduodamas iš įvesties sąsajos į išvesties sąsają.
Abiem režimais „Suricata“ galima derinti su „Netfilter“, tačiau NFQUEUE ypač gerai tinka tais atvejais, kai norime pakartotinai panaudoti visą „iptables“ logiką (politikas, diapazonus, ankstesnes taisykles) ir siųsti „Suricata“ tik tą srautą, kurį norime išsamiai patikrinti.
Pagrindinis „Suricata“ diegimas iš šaltinio kodo
Tiems, kurie mieliau kompiliuoja „Suricata“, o ne naudoja paketus, „Debian“ / „Ubuntu“ tipo distribucijų procesas pirmiausia apima kompiliavimo priklausomybių („build-essential“, „libpcre“, „libpcap-dev“, „libnet-dev“, „libyaml-dev“, „zlib“, „libcap-ng-dev“, „libjansson-dev“ ir kt.) įdiegimą, „tarball“ atsisiuntimą iš oficialios svetainės ir klasikinės komandos „./configure, make, make install“ paleidimą.
Konfigūravimo etape scenarijus nurodys, kurios palaikymo funkcijos buvo įjungtos: AF_PACKET taip/ne, PF_RING, NFQUEUE taip/ne, NFLOG, IPFW, libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP ir kt. palaikymas. Svarbu patikrinti, ar NFQUEUE įjungtas, jei norime dirbti šiuo režimu , ir ar mus dominanti fiksavimo biblioteka yra surasta.
Įdiegę dvejetainį failą, galite paleisti komandą „make install-conf“ , kad diegtumėte numatytąją konfigūraciją faile „/etc/suricata“, ir komandą „make install-rules“ , kad atsisiųstumėte ir įdėtumėte kylančių grėsmių taisyklių rinkinį į failą „/etc/suricata/rules“. Šiuos rinkinius galima atnaujinti naudojant tokius įrankius kaip „suricata-update“.
„Red Hat“ / „CentOS“ sistemose logika panaši: priklausomybėms (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel ir kt.) naudojama „yum“ arba „dnf“, o tada kompiliuojama tais pačiais veiksmais. Dėl našumo taip pat patartina išjungti LRO/GRO fiksavimo sąsajoje naudojant „ethtool“, nes šios perkėlimo funkcijos gali turėti įtakos paketų matomumui IDS lygmeniu.
„Suricata“ konfigūracija: YAML, kintamieji ir sriegimas
Pagrindinė „Suricata“ konfigūracija yra faile /etc/suricata/suricata.yaml . Tai gana lengvai skaitomas ir gausiai komentuojamas YAML failas, kuriame apibrėžta viskas – nuo žurnalų kelių ir taisyklių rinkinių iki tikslinės operacinės sistemos politikų ir gijų parametrų.
Vienas iš pagrindinių laukų yra „default-log-dir`“ , kuris nurodo, kur bus saugomi žurnalų failai (pagal numatytuosius nustatymus tai yra „/var/log/suricata`). Sekcijoje „vars“ yra tokie kintamieji kaip „HOME_NET“, „EXTERNAL_NET“, „HTTP_PORTS`“, „SHELLCODE_PORTS` ir „SSH_PORTS`“, kurie taisyklėse naudojami kaip santrumpos. „HOME_NET“ paprastai konfigūruojamas su vietinio tinklo diapazonu, kurį norime apsaugoti, o „EXTERNAL_NET“ paprastai apibrėžiamas kaip „!HOME_NET“.
Kita svarbi dalis yra „ host-os-policy“ , kuri nurodo „Suricata“, kuri operacinė sistema turėtų vykdyti tam tikrus IP diapazonus. Tai leidžia jai koreguoti TCP surinkimo būdą arba tam tikrų tinklo steko elgsenos interpretavimą , todėl sunkiau apeiti protokolus, pagrįstus stekų skirtumais („Windows“ ir „Linux“ ir kt.). Konkrečius diapazonus galima priskirti tokioms kategorijoms kaip „Windows“, „Linux“, BSD, „Vista“, „Windows 2003“ ir kt.
Kalbant apie gijų valdymą, gijų valdymo skyrius leidžia tiksliai reguliuoti procesoriaus afinitetą ir aptikimo gijų skaičių. Pagal numatytuosius nustatymus `set-cpu-affinity` paprastai yra išjungtas, todėl sistemos planuoklė gali paskirstyti gijas tarp branduolių. Parametras `detect-thread-ratio` nurodo, kiek aptikimo gijų sukuriama kiekvienam prieinamam branduoliui; kai `detect-thread-ratio: 1.5` 8 branduolių kompiuteryje, „Suricata“ sugeneruos 12 aptikimo gijų, taip pat fiksavimo ir valdymo gijas.
Visas šis modelis atsispindi išvestyje, kai paleidžiamas demonas: matomas fiksavimo gijos (pvz., „pcap“) ir kelios detektoriaus gijos, be to, srautų ir statistikos tvarkyklės. Ši daugiaprocesė architektūra leidžia „Suricata“ daug geriau prisitaikyti prie 10/40 Gbit/s jungčių, palyginti su vieno gijos varikliais.
Taisyklės ir parašų atnaujinimai Suricatoje
„Suricata“ naudoja taisyklių rinkinius atakų modeliams, anomaliam elgesiui ir protokolo netinkamam naudojimui aptikti. Be taisyklių priėmimo „Snort“ formatu , labiausiai paplitusi ekosistema yra kylančių grėsmių ekosistema: „ET Open“ (nemokama) ir „ET Pro“ (komercinė), kurios taisyklės orientuotos į dabartines grėsmes.
Daugelyje šiuolaikinių distribucijų yra įrankis „suricata-update“ , kuris supaprastina taisyklių valdymą: jis atnaujina šaltinius, įjungia arba išjungia konkrečius teikėjus ir atsisiunčia naujausias parašų rinkinių versijas. Įprastas darbo eiga būtų įdiegti „suricata-update“ (pavyzdžiui, per pip), paleisti pirmąjį „suricata-update“, kad atsisiųstumėte ET Open, išvardyti šaltinius naudojant „suricata-update list-sources“, įjungti papildomus šaltinius, tokius kaip „ptresearch/attackdetection“, „oisf/trafficid“ arba „sslbl/ssl-fp-blacklist“ ir dar kartą paleisti „suricata-update“, kad iš naujo sukurtų taisyklių failą.
Failas „suricata.yaml“ pakoreguojamas taip, kad nukreiptų į teisingą taisyklių kelią, ir nuo to laiko „Suricata“ pradės generuoti įspėjimų įvykius, kurie bus registruojami „fast.log“ (greitas, skaitomas tekstas) ir „eve.json“ (struktūrizuotas JSON su labai išsamia informacija) failuose . Pastarasis formatas ypač naudingas teikiant informaciją ataskaitų suvestinėms, koreliacijos sistemoms ar pasirinktiniams scenarijams.
Be parašų, „Suricata“ integruoja kelių protokolų dekoderius ir analizatorius , todėl ji yra mažiau priklausoma nuo prievadų: ji gali identifikuoti HTTP srautą, net jei jis eina per nestandartinius prievadus, aptikti SSH, TLS, DNS ir kt. per skirtingus prievadus ir inkapsuliacijos lygius (įskaitant mišrius IPv4/IPv6 tunelius).
Praktinis pritaikymas: nuo interneto spragų aptikimo iki automatinio blokavimo
Vienas iš labiausiai pageidaujamų naudojimo atvejų prieglobos aplinkose ar duomenų centruose yra realiuoju laiku aptikti bandymus išnaudoti žiniatinklio programų (pvz., „WordPress“ ir jos papildinių) pažeidžiamumus ir automatiškai į juos reaguoti, dažniausiai blokuojant arba įtraukiant šaltinio IP adresą į juodąjį sąrašą užkardoje.
„Suricata“, veikianti pagal atnaujintas taisykles, gali atpažinti konkrečius atakų modelius, nukreiptus prieš URL, parametrus, HTTP naudingąją apkrovą ir net užklausų sekas, kurios atitinka žinomus pažeidžiamumus. IDS gali veikti pasyviu režimu, gaudama srautą per veidrodinį atspindį iš komutatoriaus prievado (SPAN), tačiau norint veikti kaip IPS ir blokuoti atakas, ji turi būti integruota su persiuntimo plokštuma.
Yra du įprasti metodai: nustatyti IDS kaip internetinį tiltą, kad srautas fiziškai praeitų per įrenginį (naudojant „iptables“, „AF_PACKET“ arba „PF“, priklausomai nuo platformos), arba palikti topologiją tokią, kokia yra, bet derinti veidrodinį atspindėjimą su veiksmais centrinėje užkardoje per API, scenarijus arba NFQUEUE . Pirmasis metodas sumažina delsą tarp aptikimo ir blokavimo, tačiau prideda dar vieną elementą „tinklo viduryje“; antrasis metodas suteikia didesnį lankstumą ir atsparumą, tačiau padidina orkestravimo sudėtingumą.
Įsilaužimų aptikimo sistemai (IDS) visiškai įmanoma aptikti bandymą išnaudoti pažeidžiamą „WordPress“ įskiepį ir tada, tiesiogiai arba per susijusį komponentą, įtraukti užpuoliko IP adresą į „iptables“ juodąjį sąrašą. Tai galima padaryti naudojant „Suricata“ JSON išvestį ir scenarijus, kurie iškviečia „iptables“ / „nftables“ , arba deleguojant dalį logikos NFQUEUE, kur pats variklis arba susijęs procesas priima sprendimą operatyviai, nelaukdamas, kol bus atnaujintas išorinis sąrašas.
Tai leidžia sutelkti dėmesį į išties svarbias grėsmes (išnaudojimus, bandymus eskaluoti, labai agresyvius nuskaitymus), ignoruojant arba tiesiog registruojant foninį triukšmą, pvz., pagrindinį prievadų nuskaitymą, kuris daugeliu atvejų pats savaime nekelia nerimą.
„Suricata“ „Pfsense“ platformoje: atvirojo kodo užkarda su integruota IDS/IPS sistema
Ne visi gali arba nori sau leisti tokią patentuotą aukštos klasės užkardą kaip „Palo Alto“. Daugelyje aplinkų patraukliau sukurti atvirojo kodo sprendimą su „pfSense“ ir „Suricata“ , kurie apima tiek pažangius užkardos poreikius (keli WAN, VLAN, VPN, NAT ir kt.), tiek IDS/IPS.
„Pfsense“, sukurta „FreeBSD“ ir „Packet Filter“ pagrindu, ypač gerai veikia su virtualizuotomis aplinkomis („Proxmox“, KVM ir kt.), išskyrus tai, kad KVM mašinose rekomenduojama naudoti E1000 plokštes vietoj „Virtio“, jei norite išvengti našumo problemų ir gedimų esant apkrovoms, nebent taikote „Netgate“ rekomendacijas (išjungiate aparatinės įrangos kontrolinės sumos perkėlimą „System“ > „Advanced“ > „Networking“ ir paleidžiate kompiuterį iš naujo, žinant, kad esant labai didelėms apkrovoms to gali nepakakti).
Minimalūs laboratorijos su „Suricata“ „Pfsense“ aplinkoje aparatinės įrangos reikalavimai gali būti nedideli (1 500 MHz procesorius, 1 GB RAM, 4 GB disko), tačiau rimtam naudojimui rekomenduojami bent 2 procesoriai, 4 GB RAM ir 16 GB atminties , nepamirštant turėti kelias tinklo sąsajas (vieną WAN, kitą LAN, daugiau, jei norite kelių WAN arba sudėtingų VLAN).
„pfSense“ diegimas yra labai greitas: paleidžiate sistemą iš ISO, sutinkate su licencijos sąlygomis, pasirenkate diegimą, pasirenkate kalbą ir klaviatūros išdėstymą, paliekate automatinį skaidymą (automatinis UFS, jei ketinate naudoti visą diską) ir po kelių minučių sistema yra paruošta pirmajam paleidimui. Konsolėje yra meniu sąsajoms priskirti, paleisti iš naujo, paleisti apvalkalą ir kt.
Laboratorijoje, pavyzdžiui, „VirtualBox“, įprasta laikinai išjungti „Pfsense“ užkardą iš konsolės naudojant komandą pfctl -d, kad būtų galima pasiekti žiniatinklio sąsają per WAN (vartotojo vardas admin, slaptažodis pfsense) ir užbaigti pradinį vedlį: bendrieji duomenys, NTP serveriai, WAN konfigūracija (laboratorijoje paprastai pakanka DHCP), LAN, administratoriaus slaptažodžio keitimas ir konfigūracijos taikymas.
Kai prieiga bus stabilizuota, WAN užkardoje galite sukurti taisyklę, kuri leidžia HTTPS iš bet kurio šaltinio į „pfsense“ IP adresą, pridėdami aprašomuosius skirtukus, kad taisyklės būtų vizualiai sutvarkytos (pvz., „Prieiga prie užkardos“). Taip pat patartina išjungti parinktį blokuoti privačius tinklus WAN tinkle, jei esate bandymų aplinkoje su RFC1918 adresais, kad nereikėtų nuolat naudoti `pfctl -d`.
„Suricata“ diegimas „pfSense“ sistemoje ir apžvalga
Įdiegus ir paleidus „pfSense“ bazę, „Suricata“ įdiegti labai paprasta: tereikia nueiti į Sistema > Paketų tvarkyklė > Galimi paketai , ieškoti „Suricata“ ir įdiegti paketą. Proceso metu atsisiunčiami keli failai ir gali užtrukti, priklausomai nuo jūsų aparatinės įrangos, tačiau visa pagalba teikiama per žiniatinklio sąsają.
Įdiegus, skirtuke „Paslaugos“ atsiranda „Suricata“ įrašas, kuriame galite konfigūruoti instancijas pagal sąsają (WAN, LAN, VLAN ir kt.), pasirinkti, kuriuos taisyklių rinkinius naudoti, aktyvuoti IDS arba IPS režimą ir koreguoti našumo bei registravimo parametrus. Parinkčių pasirinkimas platus (užtenka ištisų straipsnių apie konfigūravimą), tačiau privalumas yra tas, kad daugelis užduočių, kurioms „Linux“ sistemoje reikia rankinio YAML redagavimo, čia atliekamos naudojant formas ir žymimuosius langelius.
Svarbi pastaba: nors laboratorijos aplinkoje gali kilti pagunda atverti „pfSense“ administravimą tiesiai prie interneto, gamybinėje aplinkoje labai svarbu apriboti prieigą prie statinių IP adresų, naudoti VPN nuotoliniam valdymui ir bet kokia kaina vengti palikti žiniatinklio konsolę atvirą . „pfSense“ yra labai lanksti, tačiau ją taip pat reikia laikyti svarbiausiu elementu.
Įjungus „Suricata“ „pfSense“ sistemoje, sukuriama aplinka, kurioje srautas praeina per „pfSense“ ugniasienės ir NAT tikslais, o „Suricata“ jį tikrina pagal savo taisykles ir gali blokuoti IPS režimu . Šis derinys, valdomas iš vienos žiniatinklio sąsajos, labai supaprastina DPI apsaugos diegimą mažuose ir vidutinio dydžio tinkluose.
Daugelyje diegimų tai papildo „Pfsense“ / „Suricata“ prijungimas prie SIEM arba centralizuotos žurnalų platformos, pasinaudojant struktūrizuotais išvesties formatais įvykiams koreliuoti ir platesnėms kampanijoms aptikti.
Įvykių stebėjimas ir pavyzdžių žurnalai Suricatoje
Kai „Suricata“ veikia, įvykiai registruojami kelyje, kurį apibrėžia „default-log-dir“, paprastai /var/log/suricata . „fast.log“ failas naudoja kompaktišką teksto formatą su laiko žymomis, taisyklių ID, klasifikacijomis ir prioritetu, tinkamą greitai peržiūrai iš terminalo („tail -f“).
Pavyzdžiui, aptikę srautą su neteisingomis TCP kontrolinėmis sumomis, galime matyti tokias eilutes: laiko žymos su data ir laiku, po kurių nurodomas taisyklės identifikatorius (pvz., 1:2200074:1), pranešimas „SURICATA TCPv4 negaliojanti kontrolinė suma“, klasifikacija, prioritetas ir šaltinio bei paskirties IP/prievado pora. Šio tipo įspėjimai leidžia greitai nustatyti paketų vientisumo problemas arba bandymus apeiti.
Faile „eve.json“ yra tie patys įvykiai JSON formatu, su tokiais laukais kaip laiko žyma, įvykio tipas, src_ip, dest_ip, src_port, dest_port, proto ir įspėjimo subfailu su veiksmu, gid, parašo ID, peržiūra, parašu, kategorija ir svarba. Šį formatą galima lengvai apdoroti naudojant „Logstash“, „Fluentd“, „Filebeat“ ar bet kurį kitą žurnalų agentą , todėl galima gauti daug išsamesnę analizę nei naudojant paprastą tekstą.
Diegiant „Suricata“ daugiabranduoliame serveryje (pvz., 8 branduolių), gijų glaudinimas lengvai pastebimas tokiuose įrankiuose kaip „htop“ gijų režimu, rodant vieną ar daugiau fiksavimo gijų („pcap“, „AF_PACKET“ arba „NFQ“) ir daugybę aptikimo gijų, paskirstytų po branduolius. Aptikimo gijų santykio ir procesoriaus afiniteto koregavimas gali smarkiai paveikti pralaidumą ir delsą, kai srauto apimtis artėja prie platformos ribų.
Prieš diegiant gamybinėje aplinkoje, patartina skirti šiek tiek laiko tikslinant, kurie taisyklių rinkiniai aktyvuojami , kad būtų išvengta klaidingai teigiamų rezultatų antplūdžio, kuris galėtų blokuoti teisėtą srautą arba užgriozdinti žurnalus. „Suricata-update“ leidžia išjungti ištisas kategorijas arba atskiras taisykles, kad būtų rastas tinkamas jautrumo ir patogumo naudoti balansas.
Specialios taikymo sritys: VoIP, garso analizė ir kūrybinis NFQUEUE
Be klasikinių naudojimo būdų (žiniatinklio paslaugų apsauga, kenkėjiškų programų aptikimas, DDoS analizė), „Netfilter“ ir „NFQUEUE“ duetas leidžia taikyti gana kūrybiškus sprendimus tokiose srityse kaip VoIP. Pavyzdžiui, galima nustatyti anti-SPIT (šlamšto per IP telefoniją) filtrą arba sistemą, skirtą cenzūruoti keiksmažodžius RTP srautuose.
Idėja būtų tokia: identifikuoti RTP srautą pagal prievadus arba protokolo atpažinimą ir nusiųsti jį į NFQUEUE; iš vartotojo programos rekonstruoti RTP srautą naudojant tokią biblioteką kaip librtp , išgauti garsą WAV formatu ir perduoti jį raktinių žodžių atpažinimo varikliui (žodžių atpažinimui), pvz., trečiosios šalies siūlomai sintezės ar atpažinimo bibliotekai.
Remdamasis aptiktais žodžiais, NFQUEUE procesas gali nuspręsti leisti, blokuoti ar net pakeisti atkūrimą, įterpdamas pyptelėjimą į srautą, nors pastarajam tikslui reikalingas labai tikslus RTCP, paketų sekų ir laiko valdymas – beveik „žmogus tarp jų“ metodas. Tai nėra trivialu, bet teoriškai tai puikiai įmanoma naudojant tą pačią eilių ir verdiktų sistemą.
Tiesa, kad dalį to būtų galima atlikti paprastu duomenų snaiperiu, kuris perduoda duomenis išoriniam procesoriui, o tada veikia pagal SIP signalizaciją arba per SBC („Asterisk“, „Kamailio“ ir kt.). Skirtumas naudojant NFQUEUE yra tas, kad veiksmas RTP sraute gali būti atliekamas nedelsiant ir tiesiogiai , nereikalaujant koordinuoti kelių komponentų ar laukti, kol signalizacijos sluoksnis užbaigs skambutį.
Šie scenarijai aiškiai iliustruoja GNU/Linux + „Netfilter“ + „Suricata“ + trečiųjų šalių bibliotekų derinio potencialą: tai ne tik prievadų ir IP adresų blokavimas, bet ir sudėtingų srauto sprendimų priėmimas realiuoju laiku naudojant 100 % nemokamos programinės įrangos ekosistemą.
Žvelgiant į visą procesą – nuo mažos C programos, kuri visada priima paketus, iki daugiaprocesio „Suricata“ diegimo, integruoto su NFQUEUE, „Pfsense“, duomenų bazėmis ir talpyklomis, galima įvertinti šio technologijų rinkinio lankstumą kuriant viską – nuo paprastų dinaminių užkardų iki duomenų centro masto IDS/IPS architektūrų, turinčių realias giluminio tikrinimo galimybes ir automatizuotą reagavimą į vis sudėtingesnes atakas.