Pilnīgs ceļvedis Netfilter un Suricata ieviešanai operētājsistēmā Linux

Informatec Digital » Resursi » Pilnīgs ceļvedis Netfilter un Suricata ieviešanai operētājsistēmā Linux

Ja strādājat ar tīkliem GNU/Linux vidē ( labākās Linux distribūcijas drošībai un privātumam ) un vēlaties paplašināt tipiskā statiskā ugunsmūra robežas, jūs droši vien interesē, kā apvienot Netfilter, NFQUEUE un Suricata, lai izveidotu patiesi elastīgu IDS/IPS, netērējot milzu naudu patentētai aparatūrai. Tieši šo jomu mēs aplūkosim šajā rakstā, apvienojot zema līmeņa elementus (kodolu, rindas, C) ar augsta līmeņa rīkiem (Suricata, rules, MySQL, Memcached, pfSense).

Pamatideja ir ļoti spēcīga: izmantot faktu, ka kodols (skatiet, kā optimizēt Linux kodolu ) var sakārtot paketes lietotāja telpā un ļaut pielāgotai programmai izlemt, ko ar tām darīt. To var izmantot datplūsmas filtrēšanai (uzlabots ugunsmūris, IPS), dinamiskajai maršrutēšanai vai biznesa loģikas integrēšanai (datubāzes, kešatmiņas, tīmekļa lietojumprogrammu uzbrukumu noteikšana, VoIP utt.). Un, ja pievienojam Suricata kā daudzprocesu IDS/IPS dzinēju, mums ir ļoti stabila kombinācija vidēm, sākot no laboratorijām līdz datu centriem ar lielu datplūsmu.

NFQUEUE un Netfilter: ugunsmūra līmeņa paaugstināšana lietotāja telpā

Tipiskā GNU/Linux sistēmā Netfilter/iptables (vai nftables) noteikumi parasti tiek izmantoti kā statiskas politikas, kas pilnībā atrodas kodola telpā . Priekšējās daļas un ierīces (tostarp daudzi risinājumi, kuru pamatā ir Netfilter vai BSD pakešu filtrs) konfigurāciju saglabā teksta, XML vai SQLite failos, un, kad kaut kas mainās, tie atkārtoti ielādē un atkārtoti ielādē noteikumus. Tas ir elastīgi, taču loģika joprojām ir sava veida ugunsmūra momentuzņēmums ar nelielām dinamiskām izmaiņām (savienojumu skaita ierobežojumi sekundē, savienojumu izsekošana, valstu saskaņošana, 7. slānis, ja pieejams utt.).

NFQUEUE piedāvā revolucionāru risinājumu: tā vietā, lai kodols vienmēr pieņemtu galīgo lēmumu, mēs varam deleģēt šo lēmumu lietotāja procesam . Kodols ievieto paketi numurētā rindā, un lietojumprogramma, kas izmanto libnetfilter_queue bibliotēku, to izgūst, analizē un atgriež spriedumu: pieņemt, atmest vai pat atzīmēt politikas maršrutēšanai. Tas ir līdzīgi kā ar programmējamu "tiesnesi", kas rakstīts C, Python vai Perl valodā, virs ugunsmūra.

Šīs iespējas skaistums slēpjas apstāklī, ka mūsu programma burtiski var darīt visu, ko mēs vēlamies: vaicāt /dev/urandom, datubāzi, tīmekļa pakalpojumu, izkliedētu kešatmiņu vai sarežģītu algoritmu, pirms reaģē uz kodolu. Arhitektūras ziņā ugunsmūris pārstāj būt vienkāršs statisku noteikumu kopums un kļūst par cauruļvadu, kurā Netfilter, rindas un lietotāju lietojumprogrammas sader kopā kā puzles gabaliņi.

NFQUEUE sastāv no divām daļām: NFQUEUE mērķa programmā iptables , kas nosūta paketes uz noteiktu rindu, un libnetfilter_queue lietotāja bibliotēkas , kas ļauj lasīt šīs paketes un sniegt spriedumu. Tas nav vienkāršs snifers kā tcpdump: šeit mums ir iespēja tieši izlemt par ceļu, pa kuru pakete pārvietojas.

Iptables pamata konfigurācija ar NFQUEUE

No iptables viedokļa NFQUEUE izmantošana ir diezgan vienkārša: jūs pievienojat noteikumu ķēdei, kas jūs interesē, lai nosūtītu uz rindu paketes, kas atbilst noteiktiem kritērijiem (avota/mērķa IP adrese, porti, stāvokļi, papildu moduļi, piemēram, GeoIP vai layer7, ja pieejami utt.).

Piemēram, ja mēs vēlamies nosūtīt uz NFQUEUE visus pingus, kas nonāk pašā resursdatorā:

iptables -I INPUT -p icmp -j NFQUEUE

Tas nosūta ienākošās ICMP paketes uz rindu 0 (ja vien nav norādīts citādi). Mēs varētu norādīt citu rindu ar kaut ko līdzīgu `--queue-num 3` . Uzskaitot noteikumus ar skaitītājiem (`iptables -L -n -v -x`), mēs redzēsim, ka skaitītāji palielinās, norādot, ka paketes tiek ievietotas rindā . Svarīga detaļa: ja rindā ir paketes un neviens lietotāja process tās neizgūst un neapstrādā, noklusējuma darbība ir to noraidīšana, tāpēc lietojumprogrammas kļūme pēc būtības izraisa datplūsmas bloķēšanu.

Programmēšana pret libnetfilter_queue: “sveika pasaule” C valodā

Lai pievienotos rindai no lietotāja telpas, tiek izmantota libnetfilter_queue bibliotēka (kas savukārt balstās uz libnfnetlink). Tādās distribūcijās kā Debian vienkārši instalējiet izstrādes pakotnes:

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

Minimālisma programmas, kas vienmēr pieņem paketes, skelets sastāv no dažiem ļoti skaidriem soļiem: bibliotēkas atvēršana, visu esošo apstrādātāju atsaistīšana, piesaiste AF_INET protokolam, rindas izveide ar atzvanīšanas funkciju, kopēšanas režīma definēšana un saņemšanas cilpas aktivizēšana . Atzvanīšana tiek izpildīta katram rindā ievietotajam paketam, iegūstot ID un atgriežot verdiktu.

Praksē plūsma ir apmēram šāda: `nfq_open`, lai iegūtu turi, `nfq_unbind_pf`, lai to iztīrītu, `nfq_bind_pf`, lai to saistītu ar AF_INET, `nfq_create_queue`, lai reģistrētu atzvanīšanas pieprasījumu 0. rindā, `nfq_set_mode`, lai norādītu, vai vēlamies metadatus vai visu paketi, cikls ar `recv()` pār deskriptoru un `nfq_handle_packet`, lai apstrādātu katru paketi . Pēc izejas rinda tiek iznīcināta ar `nfq_destroy_queue`, un turis tiek aizvērts ar `nfq_close`.

Šāda veida "sveika pasaule" ļauj skaidri izmērīt NFQUEUE ietekmi. Ja mēs kompilējam piemēru ar kaut ko līdzīgu:

gcc -o nftest kods.c -lnfnetlink -lnetfilter_queue

Un, ja mēs rindā ievietojam datplūsmu no iperf (piemēram, TCP ports 5001 INPUT un OUTPUT), mēs redzēsim, ka kods, kas vienkārši pieņem paketes, tik tikko ietekmē veiktspēju gigabita tīklā . Tomēr ir viena svarīga detaļa: informācijas drukāšana atzvanīšanas lodziņā (printf, fflush utt.) ievērojami samazina caurlaidspēju, kā redzams, salīdzinot iperf ar un bez ekrāna atkļūdošanas.

Paplašinātas NFQUEUE opcijas: apvedceļš, balansēšana un atteices atvēršana

NFQUEUE ietver vairākas interesantas iptables opcijas, kas maina rindu noklusējuma darbību un kas jāzina pirms ieiešanas ražošanas vai augstas veiktspējas vidē, jo tās ietekmē to, kā tiek apstrādātas lietotāja lietojumprogrammu kļūmes vai rindas aizpildīšana.

Komanda `--queue-bypass` ļauj nodrošināt, ka, ja neviens process neklausās rindā, paketes netiek atmestas, bet gan pārsūtītas uz nākamo lēkumu iptables ķēdē. Tas var būt noderīgi, ja vēlaties, lai sistēma "atvērtos avārijas gadījumā", kad lietotāja pakalpojums nav pieejams, lai gan no drošības viedokļa tas ir divvirzienu zobens.

Opcija `--queue-balance` ļauj sadalīt paketes vairākās rindās (piemēram, no 0 līdz 3) un pēc tam izmantot vairākus neatkarīgus procesus vai pavedienus, kas patērē datus no katras rindas . Netfilter kods nodrošina, ka vienas plūsmas paketes vienmēr nonāk vienā rindā, kas ievērojami vienkāršo lēmumu loģikas konsekvences saglabāšanu.

Pastāv arī `--fail-open` režīms , kas kontrolē, kas notiek, ja rinda piepildās lietotāja procesa pārāk lēnas darbības dēļ. Ja tas tiek iespējots, kodols pieņem paketes tieši, nevis tās nomet, tādējādi novēršot masveida datplūsmas traucējumus. Atkal tas var būt drošības jautājums, jo, ja vēlamies pieņemt lēmumus katrā gadījumā atsevišķi, lēmumu pakešu zaudēšana nozīmē šī mērķa nesasniegšanu.

Lai uzraudzītu, kas notiek ar rindām, Netfilter atklāj informāciju pseido-fs failā /proc/net/netfilter/nfnetlink_queue , ko var viegli iegūt no skriptiem vai uzraudzības rīkiem.

Biznesa loģikas integrēšana: testēšana ar Memcached un MySQL

Kad "sveika pasaule" process ir kontrolēts, nākamais dabiskais solis ir bagātināt atzvanu ar zvaniem uz ārējām sistēmām . Tipisks eksperiments ietver lēmuma pieņemšanu par paketes pieņemšanu vai noraidīšanu, pamatojoties uz to, vai avota IP adrese parādās kādā aizmugursistēmā, piemēram, MySQL datubāzē vai Memcached kešatmiņā.

Memcached gadījumā dēmons tiek instalēts (apt-get install memcached), un atslēga, piemēram, authorized , tiek ielādēta ar mūs interesējošo IP adresi. To var izdarīt ar vienkāršu echo un netcat komandu, un pēc tam ar get komandu pārbaudīt, vai vērtība ir pareizi saglabāta. Pēc tam NFQUEUE programma papildus paketes ID iegūšanai saņem visu paketi, izmantojot NFQNL_COPY_PACKET , izvelk IP galveni (struct iphdr) un pārveido avota adresi virknē ar inet_ntop.

Lai netērētu laiku savienojumu atvēršanai ar katru paketi, Memcached savienojums tiek inicializēts tikai vienu reizi galvenajā metodē (memcached_create, memcached_server_list_append, memcached_server_push), un apstrādātājs tiek glabāts globālajos mainīgajos. Atzvanīšanas procesā memcached_get tiek izsaukta ar vēlamo atslēgu, avota IP adrese tiek salīdzināta ar izgūto vērtību, un, ja tās sakrīt, tiek atgriezts NF_ACCEPT; pretējā gadījumā tiek atgriezts NF_DROP. Ja atslēga neeksistē vai ir kļūda, pakete tiek atmesta saskaņā ar konservatīvu politiku.

Izmantojot iperf, šī stratēģija samazina caurlaidspēju līdz aptuveni 140 Mbit/s gigabitu tīklā , un ir novērots, ka rindā sāk rasties zudumi (ko norāda, piemēram, simboli pašā kodā). Citiem vārdiem sakot, vienkārša kešatmiņas pakalpojuma izsaukšana par katru paketi jau rada ievērojamas izmaksas, lai gan optimizācijas gadījumā tā joprojām ir dzīvotspējīga vidēja datplūsmas apjoma gadījumā.

Ar MySQL pieeja ir līdzīga, bet sarežģītāka: tiek instalēta servera un klienta bibliotēka, tiek izveidota datubāze (piemēram, nfqueue) ar vienkāršu tabulu ar nosaukumu authorized(ip varchar(50)), un tiek ievietota atļautā IP adrese. Programmā startēšanas laikā tiek palaisti `mysql_init` un `mysql_real_connect` , un atzvanīšanas laikā tiek veidots vaicājums, piemēram, `select * from authorized where ip like 'xxxx'`. Ja vaicājums tiek veiksmīgi izpildīts un tiek atrasta rinda, pakotne tiek pieņemta; pretējā gadījumā tā tiek atmesta.

Ar iespējotu MySQL vaicājumu kešatmiņu testi dod aptuveni 188 Mbit/s , kas samazinās līdz 103 Mbit/s , ja vaicājumu kešatmiņa ir atspējota. Šie skaitļi, lai gan tālu no gigabitiem, parāda, ka pat ar vismazāk eleganto pieeju (vienpavedienu, bez optimizācijas) ievērojamus datplūsmas apjomus var apstrādāt, izmantojot uz datubāzi balstītus vai kešatmiņā balstītus lēmumus.

Veiktspēja, vairākpavedienu apstrāde un centrālā procesora noslodze

Testi ar iperf, Memcached un MySQL skaidri parāda, ka veiktspējas griestus nenosaka tik daudz pats NFQUEUE, cik loģika, ko pievienojam lietotāja telpā , un tas, kā mēs to ieviešam. Izpildfails, kas atgriež tikai NF_ACCEPT, sasniedz gandrīz gigabitu bez jebkādām problēmām; tiklīdz mēs ieviešam I/O vai tīkla izsaukumus, caurlaidspēja samazinās un NFQUEUE datora, Memcached dēmona vai MySQL centrālā procesora noslodze tiek sasniegta.

No arhitektūras viedokļa tam ir divas sekas. No vienas puses, tas apstiprina, ka ugunsmūra lēmumu deleģēšana lietotāju lietojumprogrammām ievērojama datplūsmas apjoma gadījumā ir pilnīgi dzīvotspējīga , ja tiek ņemtas vērā katra zvana faktiskās izmaksas. No otras puses, tas parāda, ka, lai tuvotos platformas maksimālajām iespējām, jāapsver vairāku pavedienu apstrāde vai vairāku procesu apstrāde . NFQUEUE ļauj sadalīt datplūsmu vairākās rindās; mēs varētu palaist vairākas mūsu lietotnes kopijas, katra klausoties citā rindā, un izmantot vairākus kodolus bez pthreads vai masīvu atzarojumu radītām problēmām.

Vēl viena acīmredzama optimizācija būtu ierobežot to, kura datplūsma iet caur NFQUEUE . Testos visa iperf plūsma tika ievietota rindā, bet reālās pasaules scenārijā mēs varētu ievietot rindā tikai paketes ar NEW stāvokli, ļaut iziet ESTABLISHED/RELATED paketēm un rezervēt dārgo loģiku pieteikšanās reizēm vai aizdomīgiem modeļiem.

Galu galā galvenais ir centrālā procesora izmantošana un pavedienu dizains: ja lietotāja process neizdodas, rinda piepildās, un mums ir jāizmanto tādas lietas kā atteices atvēršana vai pieņemšana, zaudējot daļu no smalkās kontroles, ko šī pieeja tiecas panākt.

Dinamiska maršrutēšana ar Netfilter zīmolu

NFQUEUE neaprobežojas tikai ar vienkāršu "accept" vai "throw" komandu. To var izmantot arī, lai paketēm piemērotu Netfilter (fwmark) karodziņus un apvienotu tos ar ip rule un iproute2, lai izveidotu ļoti elastīgas, gandrīz vieglas VRF stila politiskās maršrutēšanas shēmas.

Procedūra, vispārīgi runājot, būtu šāda: definēt vairākas maršrutēšanas tabulas failā /etc/iproute2/rt_tables , piemēram, lēno un ātro; piešķirt katrai tabulai atšķirīgu noklusējuma maršrutu (vienu pa optisko šķiedru un otru pa ierobežotāku saiti); izmantot ip noteikumu, lai norādītu, ka paketes ar fwmark 1 nonāk ātrajā tabulā, tās, kurām fwmark 2 ir vērtība, - lēnajā tabulā utt.; un visbeidzot izmantot NFQUEUE, lai atbilstoši atzīmētu paketes pirms verdikta atgriešanas.

Lai iestatītu verdiktu no atzvanīšanas, tiek izmantots `nfq_set_verdict2` , kas ir līdzīgs `nfq_set_verdict`, bet ļauj iestatīt sprieduma vērtību, ko pēc tam redzēs `ip rule`. Apvienojot visu šo, var izveidot IP maršrutētāju, kas izlemj, kur maršrutēt, pamatojoties uz patvaļīgiem kritērijiem: sākot no absurdām lietām, piemēram, pāra/nepāra pakešu lieluma, līdz ārējiem ievades datiem, piemēram, datplūsmas prognozēšanas algoritmiem, sociālo mediju notikumiem vai signāliem no uzraudzības sistēmām.

Rezultāts ir sistēma, kurā kodols turpina pārsūtīt paketes ar ierasto ātrumu, bet precīzs ceļš, pa kuru katra plūsma iet, tiek deleģēts ārējai programmatūrai , kas var mainīt savas domas reāllaikā, nepieskaroties statiskajiem noteikumiem.

NFQUEUE un Suricata: augsta līmeņa IPS GNU/Linux vidē

Visu iepriekš minēto var programmēt manuāli C valodā, taču, runājot par ielaušanās atklāšanu un dziļu pakešu pārbaudi, saprātīgākais risinājums parasti ir paļauties uz nobriedušu IDS/IPS dzinēju . Šeit noder Suricata, kas radās tieši kā daudzprocesu alternatīva Snort, ar IPS iespējām jau no paša sākuma un lielu uzsvaru liekot uz daudzo mūsdienās pieejamo CPU kodolu izmantošanu.

Suricata ir rakstīta no nulles un izplatīta saskaņā ar GPLv2 licenci ; Atvērtās informācijas drošības fonds (OISF) uztur gan dzinēju, gan diezgan visaptverošu noteikumu un dokumentācijas ekosistēmu. Atšķirībā no Snort 2.x, kas mantoja viena pavediena kodolu un tika tam pievienots, Suricata tika izstrādāta, lai sadalītu darba slodzi vairākos pavedienos: uztveršana, dekodēšana, noteikšana un izvade, izmantojot dažādas slodzes sadales stratēģijas.

Funkcionālā līmenī Suricata nodrošina vietējo atbalstu IPv6, 7. slāņa pārbaudei (ļoti uzlabota HTTP, izmantojot HTP bibliotēku), protokolu atpazīšanai neatkarīgi no portiem , plūsmas rekonstrukcijai un ļoti jaudīgai sesijas mainīgo (plūsmas bitu) sistēmai, lai korelētu dažādus uzbrukuma posmus, kas izplatīti vairākos TCP savienojumos.

Papildu priekšrocība ir saderība ar Snort noteikumiem un spēja izmantot gan Sourcefire VRT, gan Emerging Threats parakstu kopas (bezmaksas ET Open un komerciālās ET Pro versijas). Turklāt tā eksportē notikumus ļoti noderīgos formātos (fast.log, JSON eve.json formātā) integrācijai ar SIEM, ELK, Splunk un citām sistēmām.

Suricata kā IPS operētājsistēmā Linux: uztveršanas režīmi un NFQUEUE

GNU/Linux vidē Suricata var darboties dažādos režīmos atkarībā no tā, kā tiek pārtverta datplūsma: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … Katram no tiem ir savas priekšrocības un prasības. Tīrā IPS līmenī divi vissvarīgākie ir NFQUEUE un AF_PACKET.

NFQ (NFQUEUE) režīmā plūsma ir līdzīga iepriekš aprakstītajai: iptables noteikumu kopa nosūta paketes uz rindu; Suricata, darbojoties lietotāja telpā, nolasa no šīs rindas, pārbauda saturu atbilstoši saviem noteikumiem un atgriež kodolam spriedumu: NF_ACCEPT, NF_DROP vai NF_REPEAT. Trešo var izmantot, lai atkārtoti ievietotu paketi tajā pašā iptables tabulā pēc papildu atzīmju vai modifikāciju piemērošanas.

Šis režīms ir ļoti elastīgs un viegli ieviešams esošajās infrastruktūrās , jo tas prasa modificēt noteikumus tikai konkrētos punktos (piemēram, FORWARD, INPUT, OUTPUT) un atstāt visu pārējo kā ir. Izmaksas ir papildu izmaksas, kas saistītas ar pakešu pārsūtīšanu uz augšu un uz leju, izmantojot NFQUEUE, ar iepriekšminēto ietekmi, ja apjoms ir ļoti liels vai noteikumi ir resursietilpīgi.

AF_PACKET režīmā Suricata darbojas tuvāk tīkla saskarnei, kopējot paketes caur AF_PACKET ligzdām. Šī ir daudz ātrāka nulles kopēšanas pieeja , taču tai ir nepieciešams, lai sistēma darbotos kā vārteja ar divām saskarnēm un lai datplūsmas bloķēšana tiktu veikta pārsūtīšanas līmenī starp tīkla kartēm: bloķējamā pakete vienkārši netiek nodota no ievades saskarnes uz izvades saskarni.

Abos režīmos Suricata var kombinēt ar Netfilter, taču NFQUEUE īpaši labi iederas scenārijos, kuros vēlamies atkārtoti izmantot visu iptables loģiku (politikas, diapazonus, iepriekšējos noteikumus) un nosūtīt Suricata tikai to trafiku, kuru vēlamies pārbaudīt padziļināti.

Suricata pamata instalēšana no avota koda

Tiem, kas dod priekšroku Suricata kompilēšanai pakotņu izmantošanas vietā, process Debian/Ubuntu tipa distribūcijās vispirms ietver kompilācijas atkarību (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev utt.) instalēšanu, tarball lejupielādi no oficiālās vietnes un klasiskās komandas ./configure, make, make install palaišanu.

Konfigurēšanas fāzē skripts norādīs, kuras atbalsta funkcijas ir iespējotas: AF_PACKET jā/nē, PF_RING, NFQUEUE jā/nē, NFLOG, IPFW, atbalsts libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP utt. Ir svarīgi pārbaudīt, vai NFQUEUE ir iespējots, ja vēlamies strādāt šajā režīmā , un vai ir atrasta mūs interesējošā uztveršanas bibliotēka.

Pēc binārā faila instalēšanas varat palaist komandu `make install-conf` , lai izvietotu noklusējuma konfigurāciju failā `/etc/suricata`, un komandu `make install-rules` , lai lejupielādētu un ievietotu jauno draudu noteikumu kopu failā `/etc/suricata/rules`. Šīs kopas pēc tam var atjaunināt, izmantojot tādus rīkus kā `suricata-update`.

Red Hat/CentOS sistēmās loģika ir līdzīga, atkarībām (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel utt.) tiek izmantots yum vai dnf, un pēc tam kompilācija tiek veikta ar tām pašām darbībām. Veiktspējas apsvērumu dēļ ieteicams arī atspējot LRO/GRO uztveršanas saskarnē, izmantojot ethtool, jo šīs pārsūtīšanas funkcijas var ietekmēt pakotņu redzamību IDS līmenī.

Suricata konfigurācija: YAML, mainīgie un pavedienu veidošana

Suricata galvenā konfigurācija atrodas failā /etc/suricata/suricata.yaml . Tas ir diezgan viegli lasāms un daudz komentēts YAML fails, kurā ir definēts viss, sākot no žurnālu ceļiem un noteikumu kopām līdz mērķa operētājsistēmas politikām un pavedienu parametriem.

Viens no pamatlaukiem ir `default-log-dir` , kas norāda, kur tiks glabāti žurnālfaili (pēc noklusējuma `/var/log/suricata`). Sadaļā `vars` ir tādi mainīgie kā `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` un `SSH_PORTS`, kas noteikumos kalpo kā saīsinājumi. `HOME_NET` parasti tiek konfigurēts ar lokālā tīkla diapazonu, kuru vēlamies aizsargāt, savukārt `EXTERNAL_NET` parasti tiek definēts kā `!HOME_NET`.

Vēl viena svarīga daļa ir host-os-policy , kas norāda Suricata, kurai operētājsistēmai ir paredzēts darbināt noteiktus IP diapazonus. Tas ļauj tai pielāgot TCP atkārtotas montāžas vai noteiktu tīkla steka darbību interpretāciju , apgrūtinot protokolu apiešanu, pamatojoties uz atšķirībām starp stekiem (Windows pret Linux utt.). Konkrētus diapazonus var piešķirt tādām kategorijām kā Windows, Linux, BSD, Vista, Windows 2003 utt.

Runājot par pavedienu veidošanu, pavedienu sadaļa ļauj precīzi noregulēt centrālā procesora (CPU) afinitāti un noteikšanas pavedienu skaitu. Pēc noklusējuma `set-cpu-affinity` parasti ir atspējots, kas ļauj sistēmas plānotājam sadalīt pavedienus pa kodoliem. Parametrs `detect-thread-ratio` norāda, cik noteikšanas pavedienu tiek izveidoti uz katru pieejamo kodolu; ar `detect-thread-ratio: 1.5` 8 kodolu datorā Suricata ģenerēs 12 noteikšanas pavedienus, kā arī uztveršanas un pārvaldības pavedienus.

Viss šis modelis pēc tam tiek atspoguļots izvadē, kad dēmons tiek startēts: ir redzams uztveršanas pavediens (piemēram, pcap) un vairāki detektora pavedieni, kā arī plūsmas pārvaldnieki un statistikas pārvaldnieki. Šī daudzprocesu arhitektūra ļauj Suricata mērogoties daudz labāk nekā viena pavediena dzinējiem, saskaroties ar 10/40 Gbit/s saitēm.

Noteikumi un parakstu atjauninājumi Suricatā

Suricata paļaujas uz noteikumu kopām, lai atklātu uzbrukumu modeļus, anomālu uzvedību un protokola ļaunprātīgu izmantošanu. Papildus noteikumu pieņemšanai Snort formātā , visizplatītākā ekosistēma ir jauno draudu ekosistēma: ET Open (bezmaksas) un ET Pro (komerciāla), ar noteikumiem, kas ir vērsti uz pašreizējiem draudiem.

Daudzās mūsdienu distribūcijās ir iekļauts rīks `suricata-update` , kas vienkāršo noteikumu pārvaldību: tas atjaunina avotus, iespējo vai atspējo konkrētus pakalpojumu sniedzējus un lejupielādē jaunākās parakstu kopu versijas. Tipiska darbplūsma būtu instalēt `suricata-update` (piemēram, izmantojot pip), palaist pirmo `suricata-update`, lai lejupielādētu ET Open, uzskaitīt avotus ar `suricata-update list-sources`, iespējot papildu avotus, piemēram, `ptresearch/attackdetection`, `oisf/trafficid` vai `sslbl/ssl-fp-blacklist`, un vēlreiz palaist `suricata-update`, lai atjaunotu noteikumu failu.

Fails suricata.yaml tiek pielāgots, lai norādītu uz pareizo noteikumu ceļu, un no turienes Suricata sāks ģenerēt brīdinājuma notikumus, kas tiks reģistrēti fast.log (ātrs, lasāms teksts) un eve.json (strukturēts JSON ar ļoti pilnīgu informāciju) . Šis pēdējais formāts ir īpaši noderīgs informācijas paneļu, korelācijas sistēmu vai pielāgotu skriptu apgādei.

Papildus parakstiem Suricata ietver dekodētājus un parsētājus vairākiem protokoliem , ļaujot tai būt mazāk atkarīgai no portiem: tā var identificēt HTTP datplūsmu pat tad, ja tā iet caur nestandarta portiem, noteikt SSH, TLS, DNS utt. dažādos portos un iekapsulēšanas līmeņos (tostarp jauktos IPv4/IPv6 tuneļus).

Praktisks pielietojums: no tīmekļa izmantošanas atklāšanas līdz automātiskai bloķēšanai

Viens no vēlamākajiem lietošanas gadījumiem mitināšanas vidēs vai datu centros ir reāllaikā atklāt mēģinājumus izmantot tīmekļa lietojumprogrammu (piemēram, WordPress un tā spraudņu) ievainojamības un automātiski reaģēt, parasti bloķējot vai iekļaujot avota IP adresi ugunsmūra melnajā sarakstā.

Suricata, ko nodrošina atjaunināti noteikumi, spēj atpazīt specifiskus uzbrukumu modeļus pret URL, parametriem, HTTP vērtajām slodzēm un pat pieprasījumu secībām, kas atbilst zināmiem uzbrukumiem. IDS var darboties pasīvā režīmā, saņemot datplūsmu, izmantojot spoguļošanu no komutatora porta (SPAN), bet, lai darbotos kā IPS un bloķētu uzbrukumus, tai jābūt integrētai ar pārsūtīšanas plakni.

Pastāv divas izplatītas pieejas: IDS iestatīšana kā tiešsaistes tilts, lai datplūsma fiziski ietu caur mašīnu (izmantojot iptables, AF_PACKET vai PF atkarībā no platformas), vai topoloģijas atstāšana tādu, kāda tā ir, bet spoguļošana tiek apvienota ar darbībām centrālajā ugunsmūrī, izmantojot API, skriptus vai NFQUEUE . Pirmā pieeja samazina latentumu starp noteikšanu un bloķēšanu, pievienojot vēl vienu elementu tīkla "vidū"; otrā pieeja piedāvā lielāku elastību un noturību, bet sarežģī orķestrēšanu.

Ir pilnīgi iespējams, ka ielaušanās atklāšanas sistēma (IDS) var atklāt mēģinājumu izmantot neaizsargātu WordPress spraudni un pēc tam, tieši vai izmantojot saistītu komponentu, pievienot uzbrucēja IP adresi iptables melnajam sarakstam. To var izdarīt, izmantojot Suricata JSON izvadi un skriptus, kas izsauc iptables/nftables , vai deleģējot daļu loģikas NFQUEUE, kur pati programma vai saistītais process pieņem lēmumu acumirklī, negaidot ārēja saraksta atjaunināšanu.

Tas ļauj koncentrēties uz patiešām svarīgiem draudiem (izaicinājumiem, eskalācijas mēģinājumiem, ļoti agresīvām skenēšanām), ignorējot vai vienkārši reģistrējot fona troksni, piemēram, pamata portu skenēšanu, kas daudzos kontekstos pati par sevi nerada bažas.

Suricata Pfsense platformā: atvērtā koda ugunsmūris ar integrētu IDS/IPS

Ne visi var vai vēlas atļauties patentētu augstas klases ugunsmūri, piemēram, Palo Alto. Daudzās vidēs pievilcīgāk ir izveidot atvērtā koda risinājumu ar pfSense un Suricata , kas aptver gan paplašinātās ugunsmūra vajadzības (vairākus WAN, VLAN, VPN, NAT utt.), gan IDS/IPS.

Pfsense, kas balstīts uz FreeBSD un Packet Filter, īpaši labi darbojas ar virtualizētām vidēm (Proxmox, KVM utt.), izņemot to, ka KVM iekārtās ieteicams izmantot E1000 kartes Virtio vietā, ja vēlaties izvairīties no veiktspējas problēmām un avārijām slodzes laikā, ja vien nepielietojat Netgate ieteikumus (atspējojiet aparatūras kontrolsummas atspējošanu sadaļā System > Advanced > Networking un restartējiet datoru, zinot, ka ar ļoti lielu slodzi tas var nebūt pietiekami).

Minimālās aparatūras prasības laboratorijai ar Suricata uz Pfsense var būt pieticīgas (1 centrālais procesors ar frekvenci 500 MHz, 1 GB RAM, 4 GB disks), taču nopietnai lietošanai ieteicams vismaz 2 centrālais procesors, 4 GB RAM un 16 GB krātuve , neaizmirstot par vairākām tīkla saskarnēm (vienu WAN, otru LAN, vairāk, ja vēlaties vairākus WAN vai sarežģītus VLAN).

Pati pfSense instalēšana ir ļoti ātra: jūs startējat no ISO faila, akceptējat licenci, izvēlaties instalēšanu, izvēlaties valodu un tastatūras izkārtojumu, atstājat nodalījumu automātisku (Auto UFS, ja plānojat izmantot visu disku), un pēc dažām minūtēm sistēma ir gatava pirmajai startēšanai. Konsolē ir izvēlne saskarņu piešķiršanai, restartēšanai, čaulas palaišanai utt.

Laboratorijas darbos, piemēram, VirtualBox, ir ierasts īslaicīgi atspējot Pfsense ugunsmūri no konsoles ar komandu pfctl -d , lai piekļūtu tīmekļa saskarnei, izmantojot WAN (lietotājvārds admin, parole pfsense) un pabeigtu sākotnējo vedni: vispārīgie dati, NTP serveri, WAN konfigurācija (laboratorijas darbos parasti pietiek ar DHCP), LAN, administratora paroles maiņa un konfigurācijas lietošana.

Kad piekļuve ir stabilizēta, WAN ugunsmūrī varat izveidot noteikumu, kas atļauj HTTPS no jebkura avota uz pfsense IP adresi, pievienojot aprakstošus atdalītājus, lai vizuāli sakārtotu noteikumus (piemēram, "Piekļuve ugunsmūrim"). Ieteicams arī atspējot opciju bloķēt privātos tīklus WAN tīklā, ja atrodaties testa vidē ar RFC1918 adresēm, lai izvairītos no pastāvīgas `pfctl -d` lietošanas.

Suricata instalēšana pfSense un pārskats

Kad pfSense bāze ir instalēta un darbojas, Suricata instalēšana ir pavisam vienkārša: dodieties uz Sistēma > Pakotņu pārvaldnieks > Pieejamās pakotnes , meklējiet Suricata un instalējiet pakotni. Procesa laikā tiek lejupielādēti vairāki faili, un tas var aizņemt kādu laiku atkarībā no aparatūras, taču to pilnībā atbalsta tīmekļa saskarne.

Pēc instalēšanas cilnē Pakalpojumi parādās ieraksts Suricata, kur var konfigurēt instances pēc saskarnes (WAN, LAN, VLAN utt.), izvēlēties, kuras noteikumu kopas izmantot, aktivizēt IDS vai IPS režīmu un pielāgot veiktspējas un reģistrēšanas parametrus. Iespēju klāsts ir plašs (pietiekami daudz rakstiem tikai par konfigurēšanu), taču priekšrocība ir tā, ka daudzi uzdevumi, kuriem Linux sistēmā nepieciešama manuāla YAML rediģēšana, šeit tiek apstrādāti ar formām un izvēles rūtiņām.

Svarīga piezīme: Lai gan laboratorijas vidē varētu rasties kārdinājums atvērt pfSense administrēšanu tieši internetam, ražošanas vidē ir svarīgi ierobežot piekļuvi statiskām IP adresēm, izmantot VPN attālinātai pārvaldībai un par katru cenu izvairīties no tīmekļa konsoles pieejamības . pfSense ir ļoti elastīgs, taču tas ir jāuztver arī kā kritisks elements.

Kad pfSense platformā ir iespējota Suricata, tiek iegūta vide, kurā trafika iet caur pfSense ugunsmūra un NAT nolūkos, un Suricata to pārbauda saskaņā ar saviem noteikumiem un var bloķēt IPS režīmā . Šī kombinācija, ko pārvalda no vienas tīmekļa saskarnes, ievērojami vienkāršo DPI aizsardzības ieviešanu mazos un vidēja lieluma tīklos.

Daudzos izvietojumos to papildina Pfsense/Suricata savienojums ar SIEM vai centralizētu žurnālu platformu, izmantojot strukturētus izvades formātus, lai korelētu notikumus un atklātu plašākas kampaņas.

Notikumu uzraudzība un piemēru žurnāli Suricata valodā

Kad Suricata darbojas, notikumi tiek reģistrēti ceļā, kas definēts ar noklusējuma žurnāla direktoriju, parasti /var/log/suricata . Fast.log fails izmanto kompaktu teksta formātu ar laika zīmogiem, noteikumu ID, klasifikācijām un prioritāti, kas ir piemērots ātrai pārbaudei no termināļa (tail -f).

Piemēram, saskaroties ar datplūsmu ar nepareizām TCP kontrolsummām, mēs varam redzēt šādas rindas: laika zīmogi ar datumu un laiku, kam seko noteikuma identifikators (piemēram, 1:2200074:1), ziņojums "SURICATA TCPv4 nederīga kontrolsumma", klasifikācija, prioritāte un avota-mērķa IP/porta pāris. Šāda veida brīdinājumi ļauj ātri identificēt pakešu integritātes problēmas vai apiešanas mēģinājumus.

Failā eve.json ir tie paši notikumi JSON formātā ar tādiem laukiem kā timestamp, event_type, src_ip, dest_ip, src_port, dest_port, proto un brīdinājuma apakšfailu ar action, gid, signature_id, rev, signature, category un severity. Šo formātu var viegli apstrādāt ar Logstash, Fluentd, Filebeat vai jebkuru citu žurnālu aģentu , kas nodrošina daudz bagātīgāku analīzi nekā vienkārši izmantojot vienkāršu tekstu.

Izvietojot Suricata daudzkodolu serverī (piemēram, 8 kodolos), pavedienu saspiešana ir viegli pamanāma tādos rīkos kā htop pavedienu režīmā, parādot vienu vai vairākus uztveršanas pavedienus (pcap, AF_PACKET vai NFQ) un lielu skaitu noteikšanas pavedienu, kas sadalīti pa kodoliem. Noteikšanas pavedienu attiecības un centrālā procesora afinitātes pielāgošana var būtiski ietekmēt caurlaidspēju un latentumu, kad datplūsmas apjoms tuvojas platformas robežām.

Pirms ieviešanas ražošanas vidē ieteicams veltīt laiku, lai precizētu, kuri noteikumu kopumi tiek aktivizēti , lai izvairītos no viltus pozitīvu rezultātu pārpilnības, kas varētu bloķēt likumīgu datplūsmu vai pārblīvēt žurnālus. Suricata-update ļauj atspējot veselas kategorijas vai atsevišķus noteikumus, lai atrastu saprātīgu līdzsvaru starp jutīgumu un lietojamību.

Īpašas lietojumprogrammas: VoIP, audio analītika un radošā NFQUEUE

Papildus klasiskajiem lietojumiem (tīmekļa pakalpojumu aizsardzība, ļaunprogrammatūras noteikšana, DDoS analīze), Netfilter+NFQUEUE duets piedāvā diezgan radošus risinājumus tādās jomās kā VoIP. Piemēram, ir iespējams iestatīt anti-SPIT (surogātpasta pār IP telefoniju) filtru vai sistēmu lamuvārdu cenzēšanai RTP plūsmās.

Ideja būtu šāda: identificēt RTP datplūsmu pēc portiem vai protokola atpazīšanas un nosūtīt to uz NFQUEUE; no lietotāja lietojumprogrammas rekonstruēt RTP plūsmu, izmantojot tādu bibliotēku kā librtp , iegūt audio WAV formātā un nodot to atslēgvārdu atpazīšanas dzinējam (vārdu noteikšanai), piemēram, trešās puses piedāvātai sintēzes vai atpazīšanas bibliotēkai.

Pamatojoties uz noteiktajiem vārdiem, NFQUEUE process varētu izlemt atļaut, bloķēt vai pat mainīt atskaņošanu, ievietojot straumē pīkstienu, lai gan pēdējam ir nepieciešama ļoti precīza RTCP, pakešu secību un laika kontrole — gandrīz kā “cilvēks vidū” pieeja. Tas nav triviāli, bet teorētiski tas ir pilnībā sasniedzams, izmantojot to pašu rindu un spriedumu sistēmu.

Ir taisnība, ka daļu no tā varētu paveikt ar vienkāršu sniferu, kas padod datus ārējam procesoram un pēc tam iedarbojas uz SIP signalizāciju vai izmantojot SBC (Asterisk, Kamailio utt.). Atšķirība, izmantojot NFQUEUE, ir tā, ka darbība RTP plūsmā var būt tūlītēja un tieša , bez nepieciešamības koordinēt vairākus komponentus vai gaidīt, kamēr signalizācijas slānis pabeidz zvanu.

Šie scenāriji skaidri ilustrē GNU/Linux + Netfilter + Suricata + trešo pušu bibliotēku kombinācijas potenciālu: runa nav tikai par portu un IP adrešu bloķēšanu, bet gan par sarežģītu datplūsmas lēmumu pieņemšanu reāllaikā, izmantojot 100% brīvas programmatūras ekosistēmu.

Aplūkojot visu procesu, sākot ar mazo C programmu, kas vienmēr pieņem paketes, līdz daudzprocesu Suricata izvietošanai, kas integrēta ar NFQUEUE, Pfsense, datubāzēm un kešatmiņām, var novērtēt elastību, ko šis tehnoloģiju komplekts piedāvā, lai izveidotu visu, sākot no vienkāršiem dinamiskiem ugunsmūriem līdz datu centra mēroga IDS/IPS arhitektūrām, ar reālām padziļinātas pārbaudes iespējām un automatizētu reaģēšanu uz arvien sarežģītākiem uzbrukumiem.