Udhëzues i plotë për zbatimin e Netfilter dhe Suricata në Linux

Informatec Digital » Burime » Udhëzues i plotë për zbatimin e Netfilter dhe Suricata në Linux

Nëse punoni me rrjete në GNU/Linux ( shpërndarjet më të mira të Linux për siguri dhe privatësi ) dhe jeni të interesuar të shkoni përtej firewall-it tipik statik, ndoshta jeni kuriozë se si të kombinoni Netfilter, NFQUEUE dhe Suricata për të ndërtuar një IDS/IPS vërtet fleksibël pa shpenzuar një pasuri për harduer të patentuar. Kjo është pikërisht fusha që do të shqyrtojmë në këtë artikull, duke përzier elementët e nivelit të ulët (bërthama, radhët, C) me mjete të nivelit të lartë (Suricata, rregullat, MySQL, Memcached, pfSense).

Ideja themelore është shumë e fuqishme: shfrytëzoni faktin që kerneli (shihni se si të optimizoni kernelin Linux ) mund të vendosë paketat në radhë në hapësirën e përdoruesit dhe të lejojë që një program i personalizuar të vendosë se çfarë të bëjë me to. Kjo mund të përdoret për filtrimin e trafikut (firewalling i avancuar, IPS), rrugëzimin dinamik ose integrimin e logjikës së biznesit (bazat e të dhënave, memorjet e përkohshme, zbulimin e sulmeve të aplikacioneve web, VoIP, etj.). Dhe nëse shtojmë Suricata si një motor shumëprocesor IDS/IPS, kemi një kombinim shumë të fuqishëm për mjedise që variojnë nga laboratorët deri te qendrat e të dhënave me trafik të lartë.

NFQUEUE dhe Netfilter: ngritja e firewall-it në hapësirën e përdoruesit

Në një sistem tipik GNU/Linux, rregullat e Netfilter/iptables (ose nftables) zakonisht përdoren si politika statike që ndodhen tërësisht në hapësirën e kernelit . Frontend-et dhe pajisjet (duke përfshirë shumë zgjidhje të bazuara në Netfilter ose Filtrin e Paketave BSD) e ruajnë konfigurimin në skedarë teksti, XML ose SQLite, dhe kur diçka ndryshon, ato rigjenerojnë dhe ringarkojnë rregullat. Kjo është fleksibile, por logjika mbetet një lloj pamjeje e murit të zjarrit me ndryshime të vogla dinamike (kufizime lidhjeje për sekondë, kontakte, përputhje vendi, shtresa 7 nëse është e disponueshme, etj.).

Ajo që propozon NFQUEUE është një ndryshim rrënjësor: në vend që kerneli të marrë gjithmonë vendimin përfundimtar, ne mund ta delegojmë atë vendim te një proces përdoruesi . Kerneli e vendos paketën në një radhë të numëruar dhe një aplikacion që përdor bibliotekën libnetfilter_queue e rimerr atë, e analizon dhe kthen një vendim: e pranon, e hedh poshtë ose edhe e shënon atë për rrugëzimin e politikave. Është si të kesh një "gjyqtar" të programueshëm të shkruar në C, Python ose Perl sipër murit të zjarrit.

Bukuria e kësaj qëndron në faktin se programi ynë mund të bëjë çfarë të duam: të kërkojë në /dev/urandom, një bazë të dhënash, një shërbim web, një memorje të shpërndarë ose një algoritëm të sofistikuar përpara se t'i përgjigjet bërthamës. Në terma arkitekturorë, firewall-i pushon së qeni një grup i thjeshtë rregullash statike dhe bëhet një tubacion ku Netfilter, radhët dhe aplikacionet e përdoruesit përshtaten së bashku si pjesë të një enigme.

NFQUEUE përbëhet nga dy pjesë: objektivi NFQUEUE në iptables , i cili dërgon paketa në një radhë specifike, dhe biblioteka e përdoruesit libnetfilter_queue , e cila ju lejon të lexoni ato paketa dhe të jepni një vendim. Nuk është një program i thjeshtë sniffer si tcpdump: këtu kemi mundësinë të vendosim drejtpërdrejt për rrugën që merr paketa.

Konfigurimi bazë i iptables me NFQUEUE

Nga pikëpamja e iptables, përdorimi i NFQUEUE është mjaft i thjeshtë: ju shtoni një rregull në zinxhirin që ju intereson për të dërguar në radhë paketat që plotësojnë kritere të caktuara (IP burim/destinacion, portet, gjendjet, modulet shtesë si GeoIP ose layer7 nëse janë të disponueshme, etj.).

Për shembull, nëse duam t'i dërgojmë NFQUEUE të gjitha ping-et që mbërrijnë te vetë hosti:

iptables -I INPUT -p icmp -j NFQUEUE

Kjo i dërgon paketat ICMP hyrëse në radhën 0 (përveç nëse specifikohet ndryshe). Ne mund të specifikojmë një radhë tjetër me diçka si `--queue-num 3` . Kur renditim rregullat me numërues (`iptables -L -n -v -x`), do të shohim që numëruesit rriten, duke treguar se paketat po vendosen në radhë . Një detaj i rëndësishëm: nëse ka paketa në radhë dhe asnjë proces përdoruesi nuk i merr dhe përpunon ato, sjellja e parazgjedhur është t'i mohojë ato, kështu që një dështim i aplikacionit, nga vetë dizajni, rezulton në bllokimin e trafikut.

Programimi kundër libnetfilter_queue: "përshëndetje botë" në C

Për t'u bashkuar me radhën nga hapësira e përdoruesit, përdoret biblioteka libnetfilter_queue (e cila nga ana tjetër mbështetet në libnfnetlink). Në shpërndarje si Debian, thjesht instaloni paketat e zhvillimit:

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

Skeleti i një programi minimal që pranon gjithmonë paketa përbëhet nga disa hapa shumë të qartë: hapni bibliotekën, shkëputni çdo trajtues ekzistues, lidheni me protokollin AF_INET, krijoni radhën me një funksion rikthimi, përcaktoni modalitetin e kopjimit dhe hyni në një lak marrjeje . Rikthimi ekzekutohet për secilën paketë në radhë, duke nxjerrë ID-në dhe duke kthyer verdiktin.

Në praktikë, rrjedha është diçka e tillë: `nfq_open` për të marrë handle-in, `nfq_unbind_pf` për ta pastruar, `nfq_bind_pf` për t'u lidhur me AF_INET, `nfq_create_queue` për të regjistruar thirrjen mbrapsht në radhën 0, `nfq_set_mode` për të treguar nëse duam meta të dhënat apo të gjithë paketën, një lak me `recv()` mbi përshkruesin, dhe `nfq_handle_packet` për të përpunuar çdo paketë . Pas daljes, radha shkatërrohet me `nfq_destroy_queue` dhe handle mbyllet me `nfq_close`.

Ky lloj "përshëndetje botë" lejon një matje të qartë të ndikimit të NFQUEUE. Nëse e përpilojmë shembullin me diçka si:

gcc -o nftest code.c -lnfnetlink -lnetfilter_queue

Dhe nëse e vendosim trafikun nga një iperf (për shembull, porta TCP 5001 në INPUT dhe OUTPUT), do të shohim se kodi që thjesht pranon paketa mezi ndikon në performancën në një rrjet gigabit . Megjithatë, ka një detaj kyç: printimi i informacionit në thirrjen kthyese (printf, fflush, etj.) penalizon ndjeshëm rendimentin, siç mund të shihet kur krahasojmë iperf me dhe pa debugging të ekranit.

Opsione të avancuara të NFQUEUE: anashkalim, balancim dhe hapje në rast dështimi

NFQUEUE përfshin disa opsione interesante të iptables që modifikojnë sjelljen e parazgjedhur të radhëve dhe që duhet të dihen para se të hyjnë në një mjedis prodhimi ose me performancë të lartë, pasi ato ndikojnë në mënyrën se si trajtohet dështimi i aplikacionit të përdoruesit ose mbushja e radhës.

Komanda `--queue-bypass` ju lejon të siguroheni që nëse asnjë proces nuk po dëgjon radhën, paketat nuk hidhen poshtë, por përkundrazi përcillen në hapjen tjetër në zinxhirin iptables. Kjo mund të jetë e dobishme nëse dëshironi që sistemi të "dështojë në hapje" kur shërbimi i përdoruesit nuk është i disponueshëm, megjithëse nga një perspektivë sigurie është një shpatë me dy tehe.

Opsioni `--queue-balance` ju lejon të shpërndani paketa nëpër një gamë radhësh (për shembull, nga 0 në 3) dhe më pas të keni procese ose fije të shumëfishta të pavarura që konsumojnë nga secila radhë . Kodi i Netfilter siguron që paketat nga e njëjta rrjedhë përfundojnë gjithmonë në të njëjtën radhë, gjë që thjeshton shumë ruajtjen e qëndrueshmërisë në logjikën e vendimmarrjes.

Ekziston edhe modaliteti `--fail-open` , i cili kontrollon se çfarë ndodh kur radha mbushet sepse procesi i përdoruesit po funksionon shumë ngadalë. Aktivizimi i tij bën që bërthama të pranojë paketa direkt në vend që t'i heqë ato, duke parandaluar ndërprerje masive të trafikut. Përsëri, ky mund të jetë një problem sigurie, sepse nëse duam të marrim vendime rast pas rasti, humbja e paketave të vendimmarrjes do të thotë dështim në përmbushjen e këtij objektivi.

Për të monitoruar se çfarë po ndodh me radhët, Netfilter ekspozon informacion në pseudo-fs /proc/net/netfilter/nfnetlink_queue , i cili mund të kërkohet lehtësisht nga skriptet ose mjetet e monitorimit.

Integrimi i logjikës së biznesit: testimi me Memcached dhe MySQL

Pasi procesi "përshëndetje botë" të jetë nën kontroll, hapi tjetër natyror është pasurimi i thirrjes kthyese me thirrje drejt sistemeve të jashtme . Një eksperiment tipik përfshin vendosjen nëse do të pranohet apo refuzohet një paketë bazuar në faktin nëse adresa IP e burimit shfaqet në ndonjë backend, siç është një bazë të dhënash MySQL ose një memorje cache Memcached.

Në rastin e Memcached, daemoni instalohet (apt-get install memcached) dhe një çelës, për shembull authorized , ngarkohet me adresën IP që na intereson. Mund ta bëjmë këtë me një komandë të thjeshtë echo dhe netcat, dhe pastaj të verifikojmë me një komandë get që vlera është ruajtur saktë. Nga aty, programi NFQUEUE, përveç marrjes së ID-së së paketës, merr të gjithë paketën duke përdorur NFQNL_COPY_PACKET , nxjerr kokën IP (struct iphdr) dhe konverton adresën burimore në një varg me inet_ntop.

Për të shmangur humbjen e kohës duke hapur lidhje me secilën paketë, lidhja Memcached inicializohet vetëm një herë në metodën kryesore (memcached_create, memcached_server_list_append, memcached_server_push) dhe trajtuesi ruhet në variabla globale. Në rikthimin e thirrjes, memcached_get thirret me çelësin e dëshiruar, adresa IP e burimit krahasohet me vlerën e marrë dhe nëse përputhen, kthehet NF_ACCEPT; përndryshe, kthehet NF_DROP. Nëse çelësi nuk ekziston ose ka një gabim, paketa hiqet si një politikë konservative.

Duke përdorur iperf, kjo strategji e zvogëlon shpejtësinë në afërsisht 140 Mbit/s në një rrjet gigabit , dhe vërehet se radha fillon të përjetojë humbje (të treguara, për shembull, nga simbolet brenda vetë kodit). Me fjalë të tjera, thjesht thirrja e një shërbimi të memories cache për paketë tashmë sjell një kosto të konsiderueshme, megjithëse mbetet e zbatueshme për vëllime mesatare trafiku nëse optimizohet.

Me MySQL, qasja është e ngjashme, por më komplekse: instalohen biblioteka e serverit dhe klientit, krijohet një bazë të dhënash (për shembull, nfqueue) me një tabelë të thjeshtë të quajtur authorized(ip varchar(50)), dhe futet adresa IP e lejuar. Në program, `mysql_init` dhe `mysql_real_connect` ekzekutohen në fillim, dhe në thirrjen kthyese, ndërtohet një pyetje si `select * from authorized where ip like 'xxxx''. Nëse pyetja ekzekutohet me sukses dhe gjendet një rresht, paketa pranohet; përndryshe, ajo hidhet poshtë.

Me aktivizimin e ruajtjes në memorje të pyetjeve në MySQL, testet japin rreth 188 Mbit/s , shpejtësi që bie në 103 Mbit/s kur çaktivizohet ruajtja në memorje e pyetjeve. Këto shifra, ndonëse larg gigabitëve, tregojnë se edhe me qasjen më pak elegante (me një fije të vetme, pa optimizim) , vëllime të respektueshme trafiku mund të trajtohen duke përdorur vendime të bazuara në bazën e të dhënave ose në ruajtje në memorje.

Performanca, shumëfillëzimi dhe përdorimi i CPU-së

Testet me iperf, Memcached dhe MySQL tregojnë qartë se kufiri i performancës nuk imponohet aq shumë nga vetë NFQUEUE sesa nga logjika që shtojmë në hapësirën e përdoruesit dhe mënyra se si e zbatojmë atë. Një skedar ekzekutues që kthen vetëm NF_ACCEPT arrin pothuajse një gigabit pa u lodhur shumë; sapo prezantojmë thirrje I/O ose rrjeti, rendimenti bie dhe CPU-ja e makinës NFQUEUE, demoni Memcached ose MySQL shtyhet në kufijtë e tij.

Nga një këndvështrim arkitektonik, kjo ka dy implikime. Nga njëra anë, konfirmon se delegimi i vendimeve të firewall-it te aplikacionet e përdoruesve për vëllime të konsiderueshme trafiku është plotësisht i zbatueshëm , me kusht që të merren parasysh kostot aktuale të secilës thirrje. Nga ana tjetër, tregon se për t'iu afruar aftësive maksimale të platformës, duhet të merret në konsideratë multithreading ose multiprocessing . NFQUEUE lejon që trafiku të shpërndahet nëpër radhë të shumta; ne mund të lançojmë disa kopje të aplikacionit tonë, secila duke dëgjuar një radhë të ndryshme, dhe të shfrytëzojmë bërthama të shumta pa shqetësimin e pthreads ose fork-eve masive.

Një tjetër optimizim i dukshëm do të ishte kufizimi i trafikut që kalon përmes NFQUEUE . Në testime, i gjithë rrjedha e iperf po vihej në radhë, por në një skenar të botës reale, ne mund të vendosnim në radhë vetëm paketa me një gjendje të RE, të lejonim kalimin e paketave TË KRIJUARA/TË LIDHURA dhe të rezervonim logjikën e shtrenjtë për hyrje ose modele të dyshimta.

Në fund të fundit, përdorimi i CPU-së dhe dizajni i fijeve të punës janë thelbësorë: nëse procesi i përdoruesit dështon, radha mbushet dhe ne duhet të përdorim gjëra të tilla si hapja me dështim ose pranimi i rënieve, duke humbur disi kontrollin e imët që synon kjo qasje.

Rrugëzim dinamik me markën Netfilter

NFQUEUE nuk kufizohet vetëm në thënien "prano" ose "hedh". Mund të përdoret gjithashtu për të aplikuar flamuj Netfilter (fwmark) në paketa dhe për t'i kombinuar ato me rregullin ip dhe iproute2 për të krijuar skema rrugëzimi politik shumë fleksibël dhe pothuajse të lehta në stilin VRF.

Procedura, në përgjithësi, do të ishte: të përcaktohen disa tabela rrugëzimi në /etc/iproute2/rt_tables , për shembull "i ngadaltë" dhe "i shpejtë"; të caktohet secila tabelë një rrugë e parazgjedhur e ndryshme (njëra nëpërmjet fibrës dhe tjetra nëpërmjet një lidhjeje më të kufizuar); të përdoret rregulli ip për të specifikuar që paketat me fwmark 1 të shkojnë në tabelën e shpejtë, ato me fwmark 2 në të ngadaltë, etj.; dhe së fundmi, të përdoret NFQUEUE për të shënuar paketat në mënyrë të përshtatshme para se të kthehet verdikti.

Për të vendosur një vendim nga rikthimi i thirrjes, përdoret `nfq_set_verdict2` , i cili është i ngjashëm me `nfq_set_verdict`, por ju lejon të vendosni një vlerë vendimi që `ip rule` do ta shohë më pas. Duke kombinuar të gjitha këto, mund të ndërtoni një router IP që vendos se ku të drejtohet bazuar në kritere arbitrare: nga gjëra absurde si madhësia e paketës çift/tek deri te inputet e jashtme si algoritmet e parashikimit të trafikut, ngjarjet në mediat sociale ose sinjalet nga sistemet e monitorimit.

Rezultati është një sistem në të cilin bërthama vazhdon të përcjellë paketat me shpejtësinë e zakonshme, por rruga e saktë që merr çdo rrjedhë i delegohet softuerit të jashtëm që mund të ndryshojë mendje në kohë reale pa prekur rregullat statike.

NFQUEUE dhe Suricata: IPS i nivelit të lartë në GNU/Linux

Të gjitha sa më sipër mund të programohen manualisht në C, por kur bëhet fjalë për zbulimin e ndërhyrjeve dhe inspektimin e thellë të paketave, opsioni më i arsyeshëm është zakonisht të mbështeteni në një motor të zhvilluar IDS/IPS . Këtu hyn në lojë Suricata, i cili lindi pikërisht si një alternativë shumë-procesore ndaj Snort, me aftësi IPS që nga fillimi dhe një fokus të madh në shfrytëzimin e shumë bërthamave të CPU-së që janë në dispozicion sot.

Suricata është shkruar nga e para dhe shpërndahet sipas licencës GPLv2 ; Fondacioni i Sigurisë së Informacionit të Hapur (OISF) mirëmban si motorin ashtu edhe një ekosistem mjaft gjithëpërfshirës rregullash dhe dokumentacioni. Ndryshe nga Snort 2.x, i cili trashëgoi një bërthamë me një fije të vetme dhe u patchua në të, Suricata u projektua për të ndarë ngarkesën e punës nëpër fije të shumta: kapja, dekodimi, zbulimi dhe dalja, me strategji të ndryshme të ndarjes së ngarkesës.

Në një nivel funksional, Suricata ofron mbështetje native për IPv6, inspektim të shtresës 7 (HTTP shumë i avancuar nëpërmjet bibliotekës HTP), njohje të protokollit të pavarur nga portet , rindërtim të rrjedhës dhe një sistem shumë të fuqishëm të variablave të sesionit (flowbits) për të lidhur fazat e ndryshme të një sulmi të përhapur në disa lidhje TCP.

Një pikë e fortë shtesë është përputhshmëria e tij me rregullat e Snort dhe aftësia e tij për të përdorur si Sourcefire VRT ashtu edhe setet e nënshkrimeve të Emerging Threats (versionet falas të ET Open dhe ato komerciale të ET Pro). Për më tepër, ai eksporton ngjarje në formate shumë të dobishme (fast.log, JSON në eve.json) për integrim me SIEM, ELK, Splunk dhe sisteme të tjera.

Suricata si një IPS në Linux: mënyrat e kapjes dhe NFQUEUE

Në GNU/Linux, Suricata mund të funksionojë në mënyra të ndryshme në varësi të mënyrës se si interceptohet trafiku: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … Secili ka avantazhet dhe kërkesat e veta. Në nivelin e pastër IPS, dy më të rëndësishmet janë NFQUEUE dhe AF_PACKET.

Në modalitetin NFQ (NFQUEUE) , rrjedha është e ngjashme me atë të përshkruar më parë: një grup rregullash iptables dërgon paketa në një radhë; Suricata, duke u ekzekutuar në hapësirën e përdoruesit, lexon nga ajo radhë, inspekton përmbajtjen sipas rregullave të saj dhe kthen një vendim në bërthamë: NF_ACCEPT, NF_DROP ose NF_REPEAT. E treta mund të përdoret për të riinjektuar paketën në të njëjtën tabelë iptables pas aplikimit të shenjave ose modifikimeve shtesë.

Kjo mënyrë është shumë fleksibile dhe e lehtë për t’u zbatuar në infrastrukturat ekzistuese , sepse kërkon vetëm modifikimin e rregullave në pika specifike (për shembull, FORWARD, INPUT, OUTPUT) dhe lënien e gjithçkaje tjetër siç është. Kostoja është mbingarkesa e shtuar e kalimit të paketave lart e poshtë përmes NFQUEUE, me ndikimin e lartpërmendur nëse vëllimi është shumë i lartë ose rregullat kërkojnë shumë burime.

Në modalitetin AF_PACKET , Suricata vepron më afër ndërfaqes së rrjetit, duke kopjuar paketa nëpër soketat AF_PACKET. Kjo është një qasje shumë më e shpejtë e zero-kopjimit , por kërkon që sistemi të funksionojë si një portë hyrëse me dy ndërfaqe dhe që bllokimi i trafikut të kryhet në nivelin e përcjelljes midis NIC-ve: paketa që do të bllokohet thjesht nuk kalohet nga ndërfaqja hyrëse në ndërfaqen dalëse.

Në të dyja mënyrat, Suricata mund të kombinohet me Netfilter, por NFQUEUE përshtatet veçanërisht mirë në skenarët ku duam të ripërdorim të gjithë logjikën e iptables (politikat, diapazonet, rregullat e mëparshme) dhe t'i dërgojmë Suricata vetëm trafikun që jemi të interesuar të inspektojmë në thellësi.

Instalimi bazë i Suricata nga kodi burimor

Për ata që preferojnë të kompilojnë Suricata në vend që të përdorin paketa, procesi në shpërndarjet e tipit Debian/Ubuntu përfshin së pari instalimin e varësive të kompilimit (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev, etj.), shkarkimin e skedarit tarball nga faqja zyrtare e internetit dhe ekzekutimin e skedarit klasik ./configure, make, make install.

Gjatë fazës së konfigurimit, skripti do të tregojë se cilat veçori mbështetëse janë aktivizuar: AF_PACKET po/jo, PF_RING, NFQUEUE po/jo, NFLOG, IPFW, mbështetje për libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP, etj. Është e rëndësishme të verifikojmë që NFQUEUE është aktivizuar nëse duam të punojmë në atë modalitet dhe që biblioteka e kapjes që na intereson është gjetur.

Pas instalimit të skedarit binar, mund të ekzekutoni `make install-conf` për të vendosur një konfigurim të parazgjedhur në `/etc/suricata` dhe `make install-rules` për të shkarkuar dhe vendosur një grup rregullash të Kërcënimeve në Zhvillim në `/etc/suricata/rules`. Këto grupe mund të përditësohen më pas duke përdorur mjete si `suricata-update`.

Në sistemet Red Hat/CentOS, logjika është e ngjashme, duke përdorur yum ose dnf për varësitë (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel, etj.) dhe më pas duke kompiluar me të njëjtat hapa. Për arsye performance, këshillohet gjithashtu të çaktivizoni LRO/GRO në ndërfaqen e kapjes duke përdorur ethtool, pasi këto funksione të shkarkimit mund të ndikojnë në dukshmërinë e paketave në nivelin IDS.

Konfigurimi i Suricata-s: YAML, variablat dhe fijet

Konfigurimi kryesor i Suricata-s ndodhet në /etc/suricata/suricata.yaml . Është një skedar YAML mjaft i lexueshëm dhe shumë i komentuar, ku përcaktohet gjithçka, nga shtigjet e regjistrave dhe grupet e rregullave deri te politikat e sistemit operativ të synuar dhe parametrat e filetimit.

Një nga fushat bazë është `default-log-dir` , e cila specifikon se ku do të ruhen skedarët e regjistrit (si parazgjedhje, `/var/log/suricata`). Nën seksionin `vars` ndodhen variabla të tilla si `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` dhe `SSH_PORTS`, të cilat shërbejnë si shkurtime në rregulla. `HOME_NET` zakonisht konfigurohet me diapazonin e rrjetit lokal që duam të mbrojmë, ndërsa `EXTERNAL_NET` zakonisht përcaktohet si `!HOME_NET`.

Një pjesë tjetër e rëndësishme është host-os-policy , e cila i tregon Suricata-s se cili sistem operativ supozohet të ekzekutojë diapazone të caktuara IP. Kjo i lejon asaj të rregullojë mënyrën se si rimonton TCP-në ose interpreton sjellje të caktuara të stivave të rrjetit , duke e bërë më të vështirë shmangien e protokolleve bazuar në ndryshimet midis stivave (Windows vs. Linux, etj.). Diapazone specifike mund t'u caktohen kategorive të tilla si Windows, Linux, BSD, Vista, Windows 2003, etj.

Lidhur me procesin e threading-ut, seksioni i procesit të threading-ut ju lejon të rregulloni imët afinitetin e CPU-së dhe numrin e thread-eve të zbulimit. Si parazgjedhje, `set-cpu-affinity` zakonisht është i çaktivizuar, gjë që i lejon planifikuesit të sistemit të shpërndajë thread-et nëpër bërthama. Parametri `detect-thread-ratio` tregon se sa thread-e zbulimit krijohen për çdo bërthamë të disponueshme; me `detect-thread-ratio: 1.5` në një makinë me 8 bërthama, Suricata do të gjenerojë 12 thread-e zbulimi, plus thread-e kapjeje dhe menaxhimi.

I gjithë ky model pasqyrohet më pas në rezultat kur fillon daemoni: një fije kapjeje (për shembull, pcap) dhe fije të shumëfishta detektorësh janë të dukshme, përveç menaxherëve të rrjedhës dhe menaxherëve të statistikave. Kjo arkitekturë me shumë procese është ajo që i lejon Suricata-s të shkallëzohet shumë më mirë sesa motorët me një fije të vetme kur përballet me lidhje 10/40 Gbit/s.

Rregullat dhe përditësimet e nënshkrimeve në Suricata

Suricata mbështetet në grupe rregullash për të zbuluar modelet e sulmit, sjelljen anomale dhe keqpërdorimin e protokollit. Përveç pranimit të rregullave në formatin Snort , ekosistemi më i zakonshëm është ai i Kërcënimeve në Zhvillim: ET Open (falas) dhe ET Pro (komercial), me rregulla të orientuara drejt kërcënimeve aktuale.

Shumë shpërndarje moderne përfshijnë mjetin `suricata-update` , i cili thjeshton menaxhimin e rregullave: ai përditëson burimet, aktivizon ose çaktivizon ofrues specifikë dhe shkarkon versionet më të fundit të grupeve të nënshkrimeve. Një rrjedhë tipike pune do të ishte instalimi i `suricata-update` (për shembull, nëpërmjet pip), ekzekutimi i `suricata-update`-it të parë për të shkarkuar ET Open, listimi i burimeve me `suricata-update list-sources`, aktivizimi i burimeve shtesë si `ptresearch/attackdetection`, `oisf/trafficid` ose `sslbl/ssl-fp-blacklist` dhe ekzekutimi i `suricata-update` përsëri për të rigjeneruar skedarin e rregullave.

Skedari suricata.yaml rregullohet për të treguar në rrugën e saktë të rregullave, dhe prej andej Suricata do të fillojë të ngrejë ngjarje alarmi që do të regjistrohen në fast.log (tekst i shpejtë dhe i lexueshëm) dhe eve.json (JSON i strukturuar me informacion shumë të plotë) . Ky format i fundit është veçanërisht i dobishëm për furnizimin e paneleve, sistemeve të korrelacionit ose skripteve të personalizuara.

Përveç nënshkrimeve, Suricata përfshin dekoderë dhe analizues për protokolle të shumëfishta , duke e lejuar atë të jetë më pak i varur nga portet: mund të identifikojë trafikun HTTP edhe nëse kalon nëpër porte jo standarde, të zbulojë SSH, TLS, DNS, etj., mbi porte dhe nivele të ndryshme të enkapsulimit (duke përfshirë tunele të përziera IPv4/IPv6).

Përdorimi praktik: nga zbulimi i shfrytëzimeve të uebit deri te bllokimi automatik

Një nga rastet e përdorimit më të dëshiruara në mjediset e pritjes ose qendrat e të dhënave është zbulimi në kohë reale i përpjekjeve për të shfrytëzuar dobësitë në aplikacionet web (p.sh., WordPress dhe plugin-et e tij) dhe reagimi automatik, zakonisht duke bllokuar ose duke e futur në listën e zezë IP-në burimore në firewall.

Suricata, e mundësuar nga rregulla të përditësuara, është e aftë të njohë modele specifike sulmi kundër URL-ve, parametrave, ngarkesave HTTP dhe madje edhe sekuencave të kërkesave që përputhen me shfrytëzime të njohura. IDS mund të funksionojë në modalitet pasiv, duke marrë trafik nëpërmjet pasqyrimit nga një port switch (SPAN), por për të vepruar si një IPS dhe për të bllokuar sulmet, duhet të integrohet me planin e përcjelljes.

Ekzistojnë dy qasje të zakonshme: konfigurimi i IDS si një urë online, në mënyrë që trafiku të kalojë fizikisht përmes makinës (duke përdorur iptables, AF_PACKET ose PF, varësisht nga platforma), ose lënia e topologjisë siç është, por duke kombinuar pasqyrimin me veprimet në firewall-in qendror nëpërmjet API-t, skripteve ose NFQUEUE . Qasja e parë minimizon vonesën midis zbulimit dhe bllokimit, me koston e shtimit të një elementi tjetër "në mes" të rrjetit; e dyta ofron fleksibilitet dhe qëndrueshmëri më të madhe, por sjell më shumë kompleksitet në orkestrim.

Është krejtësisht e realizueshme që një Sistem Zbulimi Ndërhyrjesh (IDS) të zbulojë një përpjekje për të shfrytëzuar një plugin të cenueshëm të WordPress dhe më pas, qoftë drejtpërdrejt ose nëpërmjet një komponenti të lidhur, të shtojë adresën IP të sulmuesit në një listë të zezë të iptables. Kjo mund të bëhet nëpërmjet daljes JSON të Suricata dhe skripteve që thërrasin iptables/nftables , ose duke deleguar një pjesë të logjikës te NFQUEUE, ku vetë motori ose një proces i lidhur merr vendimin menjëherë pa pritur që të përditësohet një listë e jashtme.

Kjo ju lejon të përqendroheni te kërcënimet që kanë vërtet rëndësi (shfrytëzimi, përpjekjet për përshkallëzim, skanimet shumë agresive), duke injoruar ose thjesht duke regjistruar zhurmën në sfond, siç janë skanimet bazë të porteve, të cilat, në shumë kontekste, nuk janë shqetësuese në vetvete.

Suricata në Pfsense: firewall me burim të hapur me IDS/IPS të integruar

Jo të gjithë mund ose duan të përballojnë një firewall të nivelit të lartë si Palo Alto. Në shumë mjedise, është më tërheqëse të krijosh një zgjidhje me burim të hapur me pfSense dhe Suricata , e cila mbulon si nevojat e avancuara të firewall-it (multi-WAN, VLAN, VPN, NAT, etj.) ashtu edhe IDS/IPS.

Pfsense, i bazuar në FreeBSD dhe Packet Filter, funksionon veçanërisht mirë me mjedise të virtualizuara (Proxmox, KVM, etj.), me përjashtim të faktit që rekomandohet të përdorni karta E1000 në vend të Virtio në makinat KVM nëse doni të shmangni problemet e performancës dhe rrëzimet nën ngarkesë, përveç nëse zbatoni rekomandimet e Netgate (çaktivizoni shkarkimin e kontrollit të harduerit në Sistemi > i Avancuar > Rrjetëzimi dhe rinisni, duke ditur se kjo mund të mos jetë e mjaftueshme me ngarkesa shumë të larta).

Kërkesat minimale të harduerit për një laborator me Suricata në Pfsense mund të jenë modeste (1 CPU 500 MHz, 1 GB RAM, 4 GB disk), por për përdorim serioz, rekomandohen të paktën 2 CPU, 4 GB RAM dhe 16 GB hapësirë ​​ruajtjeje , duke mos harruar të keni disa ndërfaqe rrjeti (një për WAN, një tjetër për LAN, më shumë nëse dëshironi WAN të shumëfishta ose VLAN komplekse).

Instalimi i pfSense në vetvete është shumë i shpejtë: ju e nisni nga ISO-ja, pranoni licencën, zgjidhni ta instaloni, zgjidhni gjuhën dhe paraqitjen e tastierës, e lini ndarjen në automatike (Auto UFS nëse do të përdorni të gjithë diskun) dhe brenda pak minutash sistemi është gati për nisjen e tij të parë. Konsola ofron një menu për caktimin e ndërfaqeve, rinisjen, nisjen e shell-it, etj.

Në laborator, për shembull në VirtualBox, është e zakonshme të çaktivizohet përkohësisht firewall-i i Pfsense nga konzola me pfctl -d për të aksesuar ndërfaqen web nëpërmjet WAN (emri i përdoruesit admin, fjalëkalimi pfsense) dhe për të përfunduar asistentin fillestar: të dhëna të përgjithshme, serverat NTP, konfigurimi i WAN (DHCP zakonisht është i mjaftueshëm në laborator), LAN, ndryshimi i fjalëkalimit të administratorit dhe aplikimi i konfigurimit.

Pasi të stabilizohet qasja, mund të krijoni një rregull në firewall-in e WAN që lejon HTTPS nga çdo burim në adresën IP të pfsense, duke shtuar ndarës përshkrues për të organizuar vizualisht rregullat (për shembull, "Firewall Access"). Këshillohet gjithashtu të çaktivizoni opsionin për të bllokuar rrjetet private në WAN nëse jeni në një mjedis testimi me adresa RFC1918, për të shmangur përdorimin e vazhdueshëm të `pfctl -d`.

Instalimi i Suricata në pfSense dhe përmbledhje

Me bazën pfSense të instaluar dhe në punë, instalimi i Suricata është aq i thjeshtë sa të shkosh te Sistemi > Menaxheri i Paketave > Paketat e Availueshme , të kërkosh për Suricata dhe të instalosh paketën. Procesi shkarkon disa skedarë dhe mund të zgjasë pak në varësi të harduerit tuaj, por ndihmohet plotësisht përmes ndërfaqes së internetit.

Pasi të instalohet, një hyrje Suricata shfaqet në skedën Shërbime, ku mund të konfiguroni instancat sipas ndërfaqes (WAN, LAN, VLAN, etj.), të zgjidhni se cilat grupe rregullash do të përdorni, të aktivizoni modalitetin IDS ose IPS dhe të rregulloni parametrat e performancës dhe të regjistrimit. Gama e opsioneve është e gjerë (e mjaftueshme për artikuj të tërë vetëm në konfigurim), por avantazhi është se shumë detyra që në Linux kërkojnë redaktim manual të YAML trajtohen këtu me formularë dhe kuti kontrolli.

Shënim i rëndësishëm: Ndërsa mund të jetë joshëse të hapet administrimi i pfSense direkt në internet në një mjedis laboratori, në prodhim është thelbësore të kufizohet qasja në adresat statike IP, të përdoren VPN për menaxhim në distancë dhe të shmanget me çdo kusht lënia e konsolës së internetit të ekspozuar . pfSense është shumë fleksibël, por duhet të trajtohet edhe si elementi kritik që është.

Me Suricata të aktivizuar në pfSense, ju merrni një mjedis ku trafiku kalon përmes pfSense për firewalling dhe NAT, dhe Suricata e inspekton atë sipas rregullave të saj dhe mund ta bllokojë atë në modalitetin IPS . Ky kombinim, i menaxhuar nga një ndërfaqe e vetme web, thjeshton shumë vendosjen e mbrojtjes DPI në rrjete të vogla dhe të mesme.

Në shumë implementime, kjo plotësohet nga një lidhje e Pfsense/Suricata me një SIEM ose platformë të centralizuar të regjistrave, duke përfituar nga formatet e strukturuara të daljes për të lidhur ngjarjet dhe për të zbuluar fushata më të gjera.

Monitorimi i ngjarjeve dhe regjistrat e shembujve në Suricata

Pasi Suricata fillon të ekzekutohet, ngjarjet regjistrohen në shtegun e përcaktuar nga default-log-dir, zakonisht /var/log/suricata . Skedari fast.log përdor një format teksti kompakt me pulla kohore, ID rregullash, klasifikime dhe përparësi, i përshtatshëm për inspektim të shpejtë nga terminali (tail -f).

Për shembull, kur hasim trafik me shuma kontrolli TCP të pasakta, mund të shohim rreshta si këto: pulla kohore me datën dhe orën, të ndjekura nga identifikuesi i rregullit (p.sh., 1:2200074:1), mesazhi "SURICATA TCPv4 kontroll i pavlefshëm", klasifikimi, përparësia dhe çifti IP/port burim-destinacion. Këto lloje alarmesh lejojnë identifikimin e shpejtë të problemeve të integritetit të paketave ose përpjekjeve të shmangies.

Skedari eve.json përmban të njëjtat ngjarje në formatin JSON, me fusha të tilla si timestamp, event_type, src_ip, dest_ip, src_port, dest_port, proto dhe një nënskedar alarmi me action, gid, signature_id, rev, signature, category dhe severity. Ky format mund të përpunohet lehtësisht me Logstash, Fluentd, Filebeat ose çdo agjent tjetër log , duke lejuar analiza shumë më të pasura sesa përdorimi i thjeshtë i tekstit të thjeshtë.

Kur vendoset Suricata në një server me shumë bërthama (p.sh., 8 bërthama), kompresimi i thread-eve është lehtësisht i dukshëm në mjete si htop në modalitetin thread, duke treguar një ose më shumë thread-e kapjeje (pcap, AF_PACKET ose NFQ) dhe një numër të madh thread-esh zbulimi të shpërndara nëpër bërthama. Rregullimi i raportit të detect-thread-ratio dhe afinitetit të CPU-së mund të ndikojë ndjeshëm në rendimentin dhe vonesën kur vëllimi i trafikut i afrohet kufijve të platformës.

Përpara se ta vendosni në prodhim, këshillohet të kaloni pak kohë duke përmirësuar se cilat grupe rregullash aktivizohen për të shmangur një përmbytje të rezultateve të rreme pozitive që mund të bllokojnë trafikun legjitim ose të mbingarkojnë regjistrat. Suricata-update ju lejon të çaktivizoni kategori të tëra ose rregulla individuale për të gjetur një ekuilibër të arsyeshëm midis ndjeshmërisë dhe përdorshmërisë.

Aplikacione të veçanta: VoIP, analiza audio dhe NFQUEUE krijuese

Përtej përdorimeve klasike (mbrojtja nga shërbimet web, zbulimi i malware-ve, analiza DDoS), dyshja Netfilter+NFQUEUE lejon zgjidhje mjaft krijuese në fusha të tilla si VoIP. Për shembull, është e mundur të konfigurohet një filtër anti-SPIT (spam over IP telephony) ose një sistem për censurimin e fjalëve të pista në transmetimet RTP.

Ideja do të ishte: të identifikohej trafiku RTP nga portet ose nga njohja e protokollit dhe të dërgohej në NFQUEUE; nga aplikacioni i përdoruesit, të rindërtohej rrjedha RTP duke përdorur një bibliotekë si librtp , të nxirrej audio në formatin WAV dhe t'ia kalohej një motori për njohjen e fjalëve kyçe (wordspotting), siç është një bibliotekë sinteze ose njohjeje e ofruar nga një palë e tretë.

Bazuar në fjalët e zbuluara, procesi NFQUEUE mund të vendosë të lejojë, bllokojë ose edhe të ndryshojë riprodhimin duke futur një bip në rrjedhë, megjithëse kjo e fundit kërkon kontroll shumë të imët të RTCP-së, sekuencave të paketave dhe kohëzgjatjeve - pothuajse një qasje njeri-në-mes. Nuk është e parëndësishme, por teorikisht është plotësisht e arritshme duke përdorur të njëjtin sistem radhësh dhe vendimesh.

Është e vërtetë që një pjesë e kësaj mund të bëhet me një sniffer të thjeshtë që u jep të dhëna një procesori të jashtëm dhe më pas vepron mbi sinjalizimin SIP ose nëpërmjet një SBC (Asterisk, Kamailio, etj.). Dallimi me përdorimin e NFQUEUE është se veprimi mbi rrjedhën RTP mund të jetë i menjëhershëm dhe i drejtpërdrejtë , pa pasur nevojë të koordinohen komponentë të shumtë ose të pritet që shtresa e sinjalizimit të përfundojë thirrjen.

Këto skenarë ilustrojnë qartë potencialin e kombinimit të GNU/Linux + Netfilter + Suricata + librari të palëve të treta: nuk ka të bëjë vetëm me bllokimin e porteve dhe adresave IP, por me orkestrimin e vendimeve komplekse për trafikun në kohë reale duke përdorur një ekosistem softuerësh 100% falas.

Duke parë të gjithë procesin, nga programi i vogël C që pranon gjithmonë paketa deri te një implementim shumëprocesor Suricata i integruar me NFQUEUE, Pfsense, bazat e të dhënave dhe memorjet e përkohshme, mund të vlerësohet fleksibiliteti që ofron ky grumbull teknologjish për të ndërtuar gjithçka, nga firewall-et dinamike të thjeshta deri te arkitekturat IDS/IPS në shkallë qendre të të dhënave, me aftësi të vërteta inspektimi të thella dhe përgjigje të automatizuar ndaj sulmeve gjithnjë e më komplekse.