- Pinapayagan ng NFQUEUE ang Netfilter na magtalaga ng mga desisyon sa pag-filter at pagmamarka sa mga proseso ng user-space, na nagbibigay-daan sa mga dynamic na IP firewall at router.
- Nagbibigay ang Suricata ng isang multi-process IDS/IPS engine na may suporta para sa NFQUEUE, AF_PACKET at mga panuntunang tugma sa Snort at mga Emerging Threat.
- Ang pagsasama ng NFQUEUE sa Suricata, mga database, Memcached o Pfsense ay nagbibigay-daan sa iyong bumuo ng mga advanced na solusyon sa seguridad at pagruruta gamit ang libreng software.
- Ang pagganap ay higit na nakasalalay sa disenyo ng thread at lohika ng user-space, kaya mahalagang i-optimize at maingat na piliin ang trapikong susuriin.
Kung gumagamit ka ng mga network na gumagamit ng GNU/Linux ( pinakamahusay na distribusyon ng Linux para sa seguridad at privacy ) at interesado kang lumampas sa karaniwang static firewall, malamang na interesado ka kung paano pagsamahin ang Netfilter, NFQUEUE, at Suricata upang bumuo ng isang tunay na flexible na IDS/IPS nang hindi gumagastos nang malaki sa proprietary hardware. Iyan mismo ang paksang tatalakayin natin sa artikulong ito, ang paghahalo ng mga low-level na elemento (kernel, queues, C) sa mga high-level na tool (Suricata, rules, MySQL, Memcached, pfSense).
Ang pinagbabatayang ideya ay napakalakas: gamitin ang katotohanan na ang kernel (tingnan kung paano i-optimize ang Linux kernel ) ay maaaring mag-queue ng mga packet sa user space at hayaan ang isang custom na programa na magdesisyon kung ano ang gagawin sa mga ito. Maaari itong gamitin para sa traffic filtering (advanced firewalling, IPS), dynamic routing, o integration ng business logic (mga database, cache, web application attack detection, VoIP, atbp.). At kung idadagdag natin ang Suricata bilang isang multi-process IDS/IPS engine, magkakaroon tayo ng napakatatag na kumbinasyon para sa mga environment mula sa mga lab hanggang sa mga data center na may mataas na trapiko.
NFQUEUE at Netfilter: pag-angat ng firewall sa espasyo ng gumagamit
Sa isang tipikal na sistemang GNU/Linux, ang mga tuntunin ng Netfilter/iptables (o nftables) ay karaniwang ginagamit bilang mga static na patakaran na ganap na nasa espasyo ng kernel . Ang mga frontend at appliances (kabilang ang maraming solusyon batay sa Netfilter o Packet Filter ng BSD) ay nag-iimbak ng configuration sa mga text, XML, o SQLite file, at kapag may nagbago, nire-regenerate at nire-reload ng mga ito ang mga tuntunin. Ito ay flexible, ngunit ang lohika ay nananatiling isang uri ng snapshot ng firewall na may maliliit na dynamic na pag-aayos (mga limitasyon sa koneksyon kada segundo, koneksyon, pagtutugma ng bansa, layer 7 kung mayroon, atbp.).
Ang iminumungkahi ng NFQUEUE ay isang game-changer: sa halip na ang kernel ang laging gumagawa ng pangwakas na desisyon, maaari nating italaga ang desisyong iyon sa isang proseso ng gumagamit . Inilalagay ng kernel ang packet sa isang naka-queue na pila, at kinukuha ito ng isang application na gumagamit ng libnetfilter_queue library, sinusuri ito, at nagbabalik ng isang hatol: tanggapin, itapon, o markahan pa nga ito para sa policy routing. Para itong pagkakaroon ng isang programmable na "judge" na nakasulat sa C, Python, o Perl sa ibabaw ng firewall.
Ang kagandahan nito ay literal na magagawa ng ating programa ang anumang gusto natin: mag-query sa /dev/urandom, isang database, isang web service, isang distributed cache, o isang sopistikadong algorithm bago tumugon sa kernel. Sa mga terminong arkitektura, ang firewall ay hindi na isang simpleng hanay ng mga static na panuntunan at nagiging isang pipeline kung saan ang Netfilter, mga pila, at mga aplikasyon ng gumagamit ay nagsasama-sama na parang mga piraso ng isang palaisipan.
Ang NFQUEUE ay binubuo ng dalawang bahagi: ang NFQUEUE target sa iptables , na nagpapadala ng mga packet sa isang partikular na queue, at ang libnetfilter_queue user library , na nagbibigay-daan sa iyong basahin ang mga packet na iyon at maglabas ng hatol. Hindi ito isang simpleng sniffer tulad ng tcpdump: dito ay mayroon tayong kakayahang direktang magdesisyon sa landas na tatahakin ng packet.
Pangunahing konpigurasyon ng iptables gamit ang NFQUEUE
Mula sa pananaw ng iptables, ang paggamit ng NFQUEUE ay medyo diretso: magdaragdag ka ng isang panuntunan sa chain na interesado ka upang ipadala sa pila ang mga packet na nakakatugon sa ilang pamantayan (source/destination IP, mga port, mga estado, mga karagdagang module tulad ng GeoIP o layer7 kung mayroon, atbp.).
Halimbawa, kung gusto nating ipadala sa NFQUEUE ang lahat ng ping na dumarating sa mismong host:
iptables -I INPUT -p icmp -j NFQUEUE
Nagpapadala ito ng mga papasok na ICMP packet sa queue 0 (maliban kung may ibang tinukoy). Maaari tayong tumukoy ng isa pang queue na may katulad na `--queue-num 3` . Kapag inililista ang mga panuntunan gamit ang mga counter (`iptables -L -n -v -x`), makikita natin ang pagdami ng mga counter, na nagpapahiwatig na ang mga packet ay nakapila . Isang mahalagang detalye: kung may mga packet sa queue at walang proseso ng user ang kumukuha at nagpoproseso sa mga ito, ang default na gawi ay ang pagtanggi sa mga ito, kaya ang isang pagkabigo ng application, sa pamamagitan ng disenyo, ay magreresulta sa pagharang ng trapiko.
Pagprograma laban sa libnetfilter_queue: ang "hello world" sa C
Para sumali sa pila mula sa espasyo ng gumagamit, ginagamit ang libnetfilter_queue library (na siya namang umaasa sa libnfnetlink). Sa mga distribusyon tulad ng Debian, i-install lamang ang mga development package:
apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc
Ang balangkas ng isang minimal program na laging tumatanggap ng mga packet ay binubuo ng ilang napakalinaw na hakbang: buksan ang library, tanggalin ang anumang umiiral na handler, i-bind sa AF_INET protocol, lumikha ng queue gamit ang callback function, tukuyin ang copy mode, at magpasok ng receive loop . Ang callback ay isinasagawa para sa bawat naka-queue na packet, kinukuha ang ID at ibinabalik ang verdict.
Sa pagsasagawa, ang daloy ay ganito: `nfq_open` para makuha ang handle, `nfq_unbind_pf` para linisin ito, `nfq_bind_pf` para iugnay sa AF_INET, `nfq_create_queue` para irehistro ang callback sa queue 0, `nfq_set_mode` para ipahiwatig kung gusto natin ang metadata o ang buong packet, isang loop na may `recv()` sa ibabaw ng descriptor, at `nfq_handle_packet` para iproseso ang bawat packet . Pagkalabas, ang queue ay sisirain gamit ang `nfq_destroy_queue` at ang handle ay isasara gamit ang `nfq_close`.
Ang ganitong uri ng "hello world" ay nagbibigay-daan para sa isang malinaw na pagsukat ng epekto ng NFQUEUE. Kung iko-compile natin ang halimbawa gamit ang isang bagay tulad ng:
gcc -o nftest code.c -lnfnetlink -lnetfilter_queue
At kung ipipila natin ang trapiko mula sa isang iperf (halimbawa, TCP port 5001 sa INPUT at OUTPUT), makikita natin na ang code na tumatanggap lamang ng mga packet ay halos hindi nakakaapekto sa performance sa isang gigabit network . Gayunpaman, mayroong isang mahalagang detalye: ang pag-print ng impormasyon sa callback (printf, fflush, atbp.) ay makabuluhang nagpapataw ng parusa sa throughput, gaya ng makikita kapag inihambing ang iperf na mayroon at walang screen debugging.
Mga advanced na opsyon sa NFQUEUE: bypass, balance, at fail-open
Isinasama ng NFQUEUE ang ilang mga kawili-wiling opsyon sa iptables na nagbabago sa default na pag-uugali ng mga pila at dapat malaman bago pumasok sa isang production o high-performance na kapaligiran, dahil nakakaapekto ang mga ito kung paano pinangangasiwaan ang pagkabigo ng aplikasyon ng gumagamit o pagpuno ng pila.
Ang utos na `--queue-bypass` ay nagbibigay-daan sa iyong matiyak na kung walang prosesong nakikinig sa pila, ang mga packet ay hindi ida-drop kundi ipapasa sa susunod na hop sa iptables chain. Maaari itong maging kapaki-pakinabang kung gusto mong "mabigong magbukas" ang sistema kapag hindi magagamit ang serbisyo ng gumagamit, bagama't mula sa pananaw ng seguridad, ito ay isang tabak na may dalawang talim.
Ang opsyong `--queue-balance` ay nagbibigay-daan sa iyong ipamahagi ang mga packet sa iba't ibang hanay ng mga pila (halimbawa, mula 0 hanggang 3) at pagkatapos ay magkaroon ng maraming independiyenteng proseso o thread na kumukuha mula sa bawat pila . Tinitiyak ng code ng Netfilter na ang mga packet mula sa parehong daloy ay laging napupunta sa parehong pila, na lubos na nagpapadali sa pagpapanatili ng pagkakapare-pareho sa lohika ng desisyon.
Nariyan din ang `--fail-open` mode , na kumokontrol sa kung ano ang mangyayari kapag napuno ang pila dahil masyadong mabagal ang proseso ng gumagamit. Ang pagpapagana nito ay nagiging sanhi ng direktang pagtanggap ng kernel ng mga packet sa halip na i-drop ang mga ito, na pumipigil sa napakalaking pagkagambala sa trapiko. Muli, maaari itong maging isang isyu sa seguridad, dahil kung gusto nating gumawa ng mga desisyon sa bawat kaso, ang pagkawala ng mga decision packet ay nangangahulugan ng hindi pagkamit ng layuning iyon.
Para masubaybayan ang nangyayari sa mga pila, inilalantad ng Netfilter ang impormasyon sa pseudo-fs /proc/net/netfilter/nfnetlink_queue , na madaling ma-query mula sa mga script o mga tool sa pagsubaybay.
Pagsasama ng business logic: pagsubok gamit ang Memcached at MySQL
Kapag kontrolado na ang prosesong "hello world", ang susunod na natural na hakbang ay ang pagyamanin ang callback gamit ang mga tawag sa mga panlabas na sistema . Ang isang karaniwang eksperimento ay kinabibilangan ng pagpapasya kung tatanggapin o tatanggihan ang isang packet batay sa kung ang pinagmulang IP address ay lilitaw sa anumang backend, tulad ng isang MySQL database o isang Memcached cache.
Sa kaso ng Memcached, ang daemon ay naka-install (apt-get install memcached) at isang key, halimbawa authorized , ay nilo-load kasama ang IP address na interesado tayo. Magagawa natin ito gamit ang isang simpleng echo at netcat, at pagkatapos ay beripikahin gamit ang isang get command na ang value ay wastong nakaimbak. Mula doon, ang programang NFQUEUE, bilang karagdagan sa pagkuha ng packet ID, ay tumatanggap ng buong packet gamit ang NFQNL_COPY_PACKET , kinukuha ang IP header (struct iphdr), at kino-convert ang source address sa isang string gamit ang inet_ntop.
Upang maiwasan ang pag-aaksaya ng oras sa pagbubukas ng mga koneksyon sa bawat packet, ang koneksyon sa Memcached ay ini-initialize nang isang beses lamang sa main method (memcached_create, memcached_server_list_append, memcached_server_push), at ang handler ay iniimbak sa mga global variable. Sa callback, ang memcached_get ay tinatawag gamit ang ninanais na key, ang source IP address ay inihahambing sa nakuha na value, at kung magkatugma ang mga ito, ang NF_ACCEPT ay ibabalik; kung hindi, ang NF_DROP ay ibabalik. Kung ang key ay hindi umiiral o mayroong error, ang packet ay ida-drop bilang isang konserbatibong patakaran.
Gamit ang iperf, binabawasan ng estratehiyang ito ang throughput sa humigit-kumulang 140 Mbit/s sa isang gigabit network , at naobserbahan na ang pila ay nagsisimulang makaranas ng mga pagkalugi (ipinapahiwatig, halimbawa, ng mga simbolo sa loob mismo ng code). Sa madaling salita, ang simpleng pagtawag sa isang cache service bawat packet ay nagdudulot na ng malaking gastos, bagama't nananatili itong mabisa para sa katamtamang dami ng trapiko kung ia-optimize.
Sa MySQL, ang pamamaraan ay magkatulad ngunit mas kumplikado: ang server at client library ay ini-install, isang database (halimbawa, nfqueue) ang ginagawa gamit ang isang simpleng table na tinatawag na authorized(ip varchar(50)), at ang pinapayagang IP address ay ipinasok. Sa programa, ang `mysql_init` at `mysql_real_connect` ay pinapatakbo sa startup, at sa callback, isang query tulad ng `select * from authorized kung saan ang ip tulad ng 'xxxx'` ay binuo. Kung ang query ay matagumpay na naisakatuparan at isang row ang natagpuan, ang package ay tatanggapin; kung hindi, ito ay itatapon.
Kapag pinagana ang MySQL query caching, ang mga pagsubok ay nagreresulta sa humigit-kumulang 188 Mbit/s , na bumababa sa 103 Mbit/s kapag hindi pinagana ang query caching. Ang mga bilang na ito, bagama't malayo sa gigabits, ay nagpapakita na kahit na sa pinaka-hindi eleganteng pamamaraan (single-threaded, nang walang pag-optimize) , ang kagalang-galang na dami ng trapiko ay maaaring pangasiwaan gamit ang mga desisyong batay sa database o caching.
Pagganap, multithreading, at paggamit ng CPU
Malinaw na ipinapakita ng mga pagsubok gamit ang iperf, Memcached, at MySQL na ang performance ceiling ay hindi masyadong ipinapataw ng NFQUEUE mismo kundi ng lohika na idinaragdag natin sa user space at kung paano natin ito ipinapatupad. Ang isang executable na nagbabalik lamang ng NF_ACCEPT ay nakakamit ng halos isang gigabit nang hindi nagpapakahirap; sa sandaling magpakilala tayo ng I/O o mga network call, bumababa ang throughput, at ang CPU ng NFQUEUE machine, ang Memcached daemon, o MySQL ay napupunta sa mga limitasyon nito.
Mula sa pananaw ng arkitektura, mayroon itong dalawang implikasyon. Sa isang banda, kinukumpirma nito na ang pagtatalaga ng mga desisyon sa firewall sa mga aplikasyon ng gumagamit para sa malaking dami ng trapiko ay ganap na praktikal , basta't isinasaalang-alang ang aktwal na gastos ng bawat tawag. Sa kabilang banda, ipinapakita nito na upang lapitan ang pinakamataas na kakayahan ng platform, dapat isaalang-alang ang multithreading o multiprocessing . Pinapayagan ng NFQUEUE ang trapiko na maipamahagi sa maraming pila; maaari tayong maglunsad ng ilang kopya ng ating app, bawat isa ay nakikinig sa ibang pila, at gamitin ang maraming core nang walang abala ng mga pthread o malalaking fork.
Ang isa pang malinaw na pag-optimize ay ang paglimita kung aling trapiko ang dumadaan sa NFQUEUE . Sa mga pagsubok, ang buong daloy ng iperf ay nakapila, ngunit sa isang totoong senaryo, maaari lamang naming i-pila ang mga packet na may NEW state, payagan ang mga ESTABLISHED/RELATED packet na dumaan, at ireserba ang mamahaling lohika para sa mga login o kahina-hinalang pattern.
Sa huli, ang paggamit ng CPU at disenyo ng thread ang susi: kung ang proseso ng gumagamit ay hindi magiging maayos, mapupuno ang pila at kailangan nating gumamit ng mga bagay tulad ng fail-open o pagtanggap ng mga drop, na mawawala ang ilan sa pinong kontrol na nilalayon ng pamamaraang ito.
Dinamikong pagruruta gamit ang Netfilter branding
Ang NFQUEUE ay hindi limitado sa simpleng pagsasabi ng "accept" o "throw." Maaari rin itong gamitin upang ilapat ang mga flag ng Netfilter (fwmark) sa mga packet at pagsamahin ang mga ito sa ip rule at iproute2 upang lumikha ng lubos na nababaluktot, halos magaan na mga scheme ng political routing na istilo ng VRF.
Ang pamamaraan, sa pangkalahatan, ay: tukuyin ang ilang mga routing table sa /etc/iproute2/rt_tables , halimbawa mabagal at mabilis; magtalaga sa bawat talahanayan ng ibang default na ruta (isa sa pamamagitan ng fiber at isa pa sa pamamagitan ng mas limitadong link); gamitin ang ip rule upang tukuyin na ang mga packet na may fwmark 1 ay pupunta sa fast table, ang mga may fwmark 2 ay sa mabagal, atbp.; at panghuli, gamitin ang NFQUEUE upang markahan nang naaangkop ang mga packet bago ibalik ang verdict.
Para magtakda ng hatol mula sa callback, ginagamit ang `nfq_set_verdict2` , na parang `nfq_set_verdict` ngunit nagbibigay-daan sa iyong magtakda ng halaga ng hatol na makikita ng `ip rule`. Sa pagsasama-sama ng lahat ng ito, maaari kang bumuo ng isang IP router na magpapasya kung saan iruruta batay sa mga arbitraryong pamantayan: mula sa mga bagay na walang katotohanan tulad ng pantay/kakaibang laki ng packet hanggang sa mga panlabas na input tulad ng mga algorithm ng prediksyon ng trapiko, mga kaganapan sa social media, o mga signal mula sa mga sistema ng pagsubaybay.
Ang resulta ay isang sistema kung saan ang kernel ay patuloy na nagpapasa ng mga packet sa karaniwang bilis, ngunit ang eksaktong landas na tinatahak ng bawat daloy ay itinatalaga sa panlabas na software na maaaring magbago ng isip nito sa totoong oras nang hindi naaapektuhan ang mga static na panuntunan.
NFQUEUE at Suricata: Mataas na antas ng IPS sa GNU/Linux
Lahat ng nabanggit ay maaaring i-program nang mano-mano sa C, ngunit pagdating sa intrusion detection at deep packet inspection, ang makatwirang opsyon ay karaniwang umasa sa isang mature na IDS/IPS engine . Dito pumapasok ang Suricata, na isinilang bilang isang multi-process na alternatibo sa Snort, na may mga kakayahan sa IPS mula pa sa simula at lubos na nakatuon sa paggamit ng maraming CPU core na magagamit ngayon.
Ang Suricata ay isinusulat mula sa simula at ipinamamahagi sa ilalim ng lisensyang GPLv2 ; pinapanatili ng Open Information Security Foundation (OISF) ang parehong engine at isang medyo komprehensibong ecosystem ng mga patakaran at dokumentasyon. Hindi tulad ng Snort 2.x, na nagmana ng isang single-threaded core at ipinares dito, ang Suricata ay idinisenyo upang hatiin ang workload sa maraming thread: capture, decoding, detection, at output, na may iba't ibang estratehiya sa load-sharing.
Sa antas ng paggana, ang Suricata ay nagbibigay ng katutubong suporta para sa IPv6, inspeksyon ng layer 7 (napaka-advanced na HTTP sa pamamagitan ng HTP library), pagkilala ng protocol na hiwalay sa mga port , muling pagbuo ng daloy, at isang napakalakas na sistema ng mga variable ng session (mga flowbit) upang iugnay ang iba't ibang yugto ng isang pag-atake na nakakalat sa ilang mga koneksyon ng TCP.
Isang karagdagang kalakasan ang pagiging tugma nito sa mga panuntunan ng Snort at ang kakayahang gamitin ang parehong Sourcefire VRT at Emerging Threats signature set (ang libreng ET Open at ang komersyal na mga bersyon ng ET Pro). Bukod pa rito, nag-e-export ito ng mga kaganapan sa mga kapaki-pakinabang na format (fast.log, JSON sa eve.json) para sa integrasyon sa mga SIEM, ELK, Splunk, at iba pang mga sistema.
Suricata bilang isang IPS sa Linux: mga capture mode at NFQUEUE
Sa GNU/Linux, maaaring gumana ang Suricata sa iba't ibang mga mode depende sa kung paano hinarang ang trapiko: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech ... Bawat isa ay may kanya-kanyang bentahe at mga kinakailangan. Sa purong antas ng IPS, ang dalawa na pinakamahalaga ay ang NFQUEUE at AF_PACKET.
Sa NFQ (NFQUEUE) mode , ang daloy ay katulad ng inilarawan kanina: isang hanay ng mga patakaran ng iptables ang nagpapadala ng mga packet sa isang pila; ang Suricata, na tumatakbo sa espasyo ng gumagamit, ay nagbabasa mula sa pila na iyon, sinusuri ang mga nilalaman ayon sa mga patakaran nito, at nagbabalik ng isang hatol sa kernel: NF_ACCEPT, NF_DROP, o NF_REPEAT. Ang pangatlo ay maaaring gamitin upang muling ipasok ang packet sa parehong talahanayan ng iptables pagkatapos maglapat ng mga karagdagang marka o pagbabago.
Ang mode na ito ay lubos na nababaluktot at madaling ipatupad sa mga umiiral na imprastraktura , dahil nangangailangan lamang ito ng pagbabago sa mga patakaran sa mga partikular na punto (halimbawa, FORWARD, INPUT, OUTPUT) at pag-iwan sa lahat ng iba pa nang walang pagbabago. Ang gastos ay ang karagdagang gastos sa pagpasa ng mga packet pataas at pababa sa pamamagitan ng NFQUEUE, na may nabanggit na epekto kung ang volume ay napakataas o ang mga patakaran ay masinsinan sa mapagkukunan.
Sa AF_PACKET mode , ang Suricata ay gumagana nang mas malapit sa network interface, kinokopya ang mga packet sa mga AF_PACKET socket. Ito ay isang mas mabilis na zero-copy na pamamaraan , ngunit kinakailangan nito na ang sistema ay gumana bilang isang gateway na may dalawang interface at ang pagharang ng trapiko ay dapat isagawa sa antas ng pagpapasa sa pagitan ng mga NIC: ang packet na haharangan ay hindi lamang ipinapasa mula sa input interface patungo sa output interface.
Sa parehong mode, maaaring pagsamahin ang Suricata sa Netfilter, ngunit ang NFQUEUE ay lalong akma sa mga sitwasyon kung saan gusto nating gamitin muli ang lahat ng lohika ng iptables (mga patakaran, saklaw, mga nakaraang panuntunan) at ipadala lamang sa Suricata ang trapikong interesado tayong suriin nang malaliman.
Pangunahing pag-install ng Suricata mula sa source code
Para sa mga mas gustong mag-compile ng Suricata sa halip na gumamit ng mga package, ang proseso sa mga distribusyon na uri ng Debian/Ubuntu ay kinabibilangan muna ng pag-install ng mga compilation dependencies (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev, atbp.), pag-download ng tarball mula sa opisyal na website, at pagpapatakbo ng classic na ./configure, make, make install.
Sa yugto ng pag-configure, ipapakita ng script kung aling mga support feature ang pinagana: AF_PACKET yes/no, PF_RING, NFQUEUE yes/no, NFLOG, IPFW, suporta para sa libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP, atbp. Mahalagang beripikahin na pinagana ang NFQUEUE kung gusto nating magtrabaho sa mode na iyon , at kung natagpuan na ang capture library na ating pinag-iisipan.
Pagkatapos i-install ang binary, maaari mong patakbuhin ang `make install-conf` para mag-deploy ng default na configuration sa `/etc/suricata` at `make install-rules` para mag-download at maglagay ng set ng mga Emerging Threats rules sa `/etc/suricata/rules`. Ang mga set na ito ay maaaring i-update gamit ang mga tool tulad ng `suricata-update`.
Sa mga sistemang Red Hat/CentOS, ang lohika ay magkatulad, ginagamit ang yum o dnf para sa mga dependency (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel, atbp.) at pagkatapos ay kino-compile gamit ang parehong mga hakbang. Para sa mga kadahilanan ng pagganap, ipinapayong i-disable din ang LRO/GRO sa capture interface gamit ang ethtool, dahil ang mga offload function na ito ay maaaring makaapekto sa visibility ng mga package sa antas ng IDS.
Konpigurasyon ng Suricata: YAML, mga baryabol, at pag-thread
Ang pangunahing configuration ng Suricata ay nasa /etc/suricata/suricata.yaml . Ito ay isang medyo madaling basahin at maraming komentong YAML file, kung saan ang lahat mula sa mga log path at rule set hanggang sa mga target na patakaran ng operating system at mga threading parameter ay tinukoy.
Isa sa mga pangunahing field ay ang `default-log-dir` , na tumutukoy kung saan itatago ang mga log file (bilang default, `/var/log/suricata`). Sa ilalim ng seksyong `vars` ay mga variable tulad ng `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS`, at `SSH_PORTS`, na nagsisilbing mga pagpapaikli sa mga panuntunan. Ang `HOME_NET` ay karaniwang kino-configure gamit ang lokal na saklaw ng network na gusto nating protektahan, habang ang `EXTERNAL_NET` ay karaniwang tinutukoy bilang `!HOME_NET`.
Ang isa pang mahalagang bahagi ay ang host-os-policy , na nagsasabi sa Suricata kung aling operating system ang dapat magpatakbo ng ilang partikular na hanay ng IP. Pinapayagan nito itong isaayos kung paano nito muling binubuo ang TCP o binibigyang-kahulugan ang ilang partikular na pag-uugali ng network stack , na ginagawang mas mahirap iwasan ang mga protocol batay sa mga pagkakaiba sa pagitan ng mga stack (Windows vs. Linux, atbp.). Ang mga partikular na hanay ay maaaring italaga sa mga kategorya tulad ng Windows, Linux, BSD, Vista, Windows 2003, atbp.
Tungkol sa threading, ang seksyon ng threading ay nagbibigay-daan sa iyong i-fine-tune ang CPU affinity at ang bilang ng mga detection thread. Bilang default, ang `set-cpu-affinity` ay karaniwang hindi pinagana, na nagbibigay-daan sa system scheduler na ipamahagi ang mga thread sa mga core. Ang parameter na `detect-thread-ratio` ay nagpapahiwatig kung gaano karaming mga detection thread ang nalilikha sa bawat available na core; na may `detect-thread-ratio: 1.5` sa isang 8-core na makina, ang Suricata ay bubuo ng 12 detection thread, kasama ang mga capture at management thread.
Ang buong modelong ito ay makikita sa output kapag nagsimula ang daemon: isang capture thread (halimbawa, pcap) at maraming detector thread ang makikita, bilang karagdagan sa mga flow manager at statistics manager. Ang multi-process architecture na ito ang nagbibigay-daan sa Suricata na mag-scale nang mas mahusay kaysa sa mga single-threaded engine kapag nahaharap sa 10/40 Gbit/s links.
Mga patakaran at pag-update ng lagda sa Suricata
Umaasa ang Suricata sa mga hanay ng mga tuntunin upang matukoy ang mga pattern ng pag-atake, maanomalyang pag-uugali, at maling paggamit ng protocol. Bukod sa pagtanggap ng mga tuntunin sa format na Snort , ang pinakakaraniwang ecosystem ay ang Emerging Threats: ET Open (libre) at ET Pro (komersyal), na may mga tuntuning nakatuon sa mga kasalukuyang banta.
Maraming modernong distribusyon ang kinabibilangan ng tool na `suricata-update` , na nagpapadali sa pamamahala ng panuntunan: ina-update nito ang mga mapagkukunan, pinapagana o hindi pinapagana ang mga partikular na provider, at dina-download ang mga pinakabagong bersyon ng mga signature set. Ang isang karaniwang daloy ng trabaho ay ang pag-install ng `suricata-update` (halimbawa, sa pamamagitan ng pip), patakbuhin ang unang `suricata-update` upang i-download ang ET Open, ilista ang mga mapagkukunan gamit ang `suricata-update list-sources`, paganahin ang mga karagdagang mapagkukunan tulad ng `ptresearch/attackdetection`, `oisf/trafficid`, o `sslbl/ssl-fp-blacklist`, at patakbuhin muli ang `suricata-update` upang muling buuin ang rules file.
Inaayos ang suricata.yaml file upang tumuro sa tamang landas ng mga panuntunan, at mula roon ay magsisimulang maglabas ang Suricata ng mga alertong kaganapan na ila-log sa fast.log (mabilis at nababasang teksto) at eve.json (nakabalangkas na JSON na may kumpletong impormasyon) . Ang huling nabanggit na format ay lalong kapaki-pakinabang para sa pagpapakain ng mga dashboard, mga sistema ng korelasyon, o mga custom na script.
Bukod sa mga signature, isinasama ng Suricata ang mga decoder at parser para sa maraming protocol , na nagbibigay-daan upang hindi ito gaanong umasa sa mga port: maaari nitong matukoy ang trapiko ng HTTP kahit na dumadaan ito sa mga hindi karaniwang port, matukoy ang SSH, TLS, DNS, atbp. sa iba't ibang port at antas ng encapsulation (kabilang ang magkahalong IPv4/IPv6 tunnels).
Praktikal na gamit: mula sa pagtukoy ng mga web exploit hanggang sa awtomatikong pagharang
Isa sa mga pinaka-inaasahang gamit sa mga hosting environment o data center ay ang pagtuklas sa real time ng mga pagtatangkang pagsamantalahan ang mga kahinaan sa mga web application (hal., WordPress at mga plugin nito) at awtomatikong tumugon, kadalasan sa pamamagitan ng pagharang o pag-blacklist sa source IP sa firewall.
Ang Suricata, na pinapagana ng mga na-update na panuntunan, ay may kakayahang kilalanin ang mga partikular na pattern ng pag-atake laban sa mga URL, parameter, HTTP payload, at maging ang mga sequence ng kahilingan na tumutugma sa mga kilalang exploit. Ang IDS ay maaaring gumana sa passive mode, tumatanggap ng trapiko sa pamamagitan ng mirroring mula sa isang switch port (SPAN), ngunit upang magsilbing isang IPS at harangan ang mga pag-atake, kailangan itong maisama sa forwarding plane.
Mayroong dalawang karaniwang pamamaraan: pag-set up ng IDS bilang isang online bridge, upang ang trapiko ay pisikal na dumaan sa makina (gamit ang iptables, AF_PACKET, o PF, depende sa platform), o pag-iwan sa topology nang walang pagbabago ngunit pinagsasama ang mirroring sa mga aksyon sa central firewall sa pamamagitan ng API, scripts, o NFQUEUE . Ang unang pamamaraan ay nagpapaliit ng latency sa pagitan ng detection at blocking, kapalit ng pagdaragdag ng isa pang elemento "sa gitna" ng network; ang pangalawa ay nag-aalok ng mas malawak na flexibility at resilience, ngunit nagpapakilala ng mas maraming komplikasyon sa orchestration.
Posible para sa isang Intrusion Detection System (IDS) na matukoy ang isang pagtatangkang pagsamantalahan ang isang mahinang WordPress plugin at pagkatapos, direkta man o sa pamamagitan ng isang nauugnay na component, idagdag ang IP address ng attacker sa isang iptables blacklist. Magagawa ito sa pamamagitan ng JSON output at mga script ng Suricata na tumatawag sa iptables/nftables , o sa pamamagitan ng pagdelegate ng ilan sa logic sa NFQUEUE, kung saan ang engine mismo o ang isang nauugnay na proseso ang gumagawa ng desisyon nang mabilisan nang hindi naghihintay na ma-update ang isang panlabas na listahan.
Nagbibigay-daan ito sa iyong tumuon sa mga banta na talagang mahalaga (mga pagsasamantala, mga pagtatangkang pag-escalate, mga napakaagresibong pag-scan), hindi papansinin o basta i-log ang ingay sa background tulad ng mga pangunahing port scan na, sa maraming konteksto, ay hindi naman nakakabahala sa kanilang sarili.
Suricata sa Pfsense: opensource firewall na may integrated IDS/IPS
Hindi lahat ay kayang bumili o gustong bumili ng isang proprietary high-end firewall tulad ng Palo Alto. Sa maraming kapaligiran, mas kaakit-akit na mag-set up ng isang open-source na solusyon gamit ang pfSense at Suricata , na sumasaklaw sa parehong mga advanced na pangangailangan sa firewall (multi-WAN, VLAN, VPN, NAT, atbp.) at IDS/IPS.
Ang Pfsense, batay sa FreeBSD at Packet Filter, ay mahusay na gumagana sa mga virtualized na kapaligiran (Proxmox, KVM, atbp.), maliban sa inirerekomendang gumamit ng mga E1000 card sa halip na Virtio sa mga KVM machine kung gusto mong maiwasan ang mga problema sa performance at pag-crash habang naglo-load, maliban na lang kung ilalapat mo ang mga rekomendasyon ng Netgate (i-disable ang hardware checksum offload sa System > Advanced > Networking at i-restart, dahil alam mong maaaring hindi ito sapat sa napakataas na load).
Ang pinakamababang kinakailangan sa hardware para sa isang lab na may Suricata sa Pfsense ay maaaring katamtaman lamang (1 CPU 500 MHz, 1 GB RAM, 4 GB disk), ngunit para sa seryosong paggamit, hindi bababa sa 2 CPU, 4 GB ng RAM at 16 GB ng storage ang inirerekomenda , at hindi rin nakakalimutang magkaroon ng ilang network interface (isa para sa WAN, isa pa para sa LAN, at higit pa kung gusto mo ng maraming WAN o kumplikadong VLAN).
Napakabilis ng pag-install ng pfSense mismo: magbo-boot ka mula sa ISO, tatanggapin ang lisensya, pipiliing i-install, pipiliin ang iyong wika at layout ng keyboard, hahayaan ang partitioning na naka-automate (Auto UFS kung gagamitin mo ang buong disk), at sa loob ng ilang minuto ay handa na ang system para sa unang boot nito. Nag-aalok ang console ng menu para sa pagtatalaga ng mga interface, pag-restart, paglulunsad ng shell, atbp.
Sa laboratoryo, halimbawa sa VirtualBox, karaniwan na pansamantalang i-disable ang Pfsense firewall mula sa console gamit ang pfctl -d upang ma-access ang web interface sa pamamagitan ng WAN (username admin, password pfsense) at makumpleto ang unang wizard: pangkalahatang data, mga NTP server, configuration ng WAN (karaniwang sapat ang DHCP sa laboratoryo), LAN, pagpapalit ng admin password at paglalapat ng configuration.
Kapag na-stabilize na ang access, maaari kang gumawa ng rule sa WAN firewall na nagpapahintulot sa HTTPS mula sa anumang source papunta sa pfsense IP address, sa pamamagitan ng pagdaragdag ng mga descriptive separator para biswal na maisaayos ang mga rule (halimbawa, "Firewall Access"). Maipapayo rin na i-disable ang opsyong harangan ang mga pribadong network sa WAN kung nasa isang test environment ka na may mga RFC1918 address, para maiwasan ang patuloy na paggamit ng `pfctl -d`.
Pag-install ng Suricata sa pfSense at pangkalahatang-ideya
Kapag gumagana na ang pfSense base, ang pag-install ng Suricata ay kasing simple lang ng pagpunta sa System > Package Manager > Available Packages , paghahanap ng Suricata, at pag-install ng package. Ang proseso ay nagda-download ng ilang file at maaaring magtagal depende sa iyong hardware, ngunit ito ay ganap na tinutulungan sa pamamagitan ng web interface.
Kapag na-install na, lilitaw ang isang entry ng Suricata sa tab na Mga Serbisyo, kung saan maaari mong i-configure ang mga instance ayon sa interface (WAN, LAN, VLAN, atbp.), piliin kung aling mga rule set ang gagamitin, i-activate ang IDS o IPS mode , at isaayos ang mga parameter ng performance at logging. Malawak ang hanay ng mga opsyon (sapat para sa buong artikulo sa configuration lamang), ngunit ang bentahe ay maraming gawain na sa Linux ay nangangailangan ng manu-manong pag-edit ng YAML ay hinahawakan dito gamit ang mga form at checkbox.
Mahalagang paalala: Bagama't maaaring nakakaakit na buksan ang pfSense administration nang direkta sa internet sa isang lab environment, sa production, mahalagang paghigpitan ang access sa mga static IP address, gumamit ng mga VPN para sa remote management, at iwasang iwanang nakalantad ang web console anuman ang mangyari . Napaka-flexible ng pfSense, ngunit dapat din itong ituring bilang isang kritikal na elemento.
Kapag naka-enable ang Suricata sa pfSense, makakakuha ka ng environment kung saan dumadaan ang trapiko sa pfSense para sa firewalling at NAT, at sinusuri ito ng Suricata ayon sa mga patakaran nito at maaari itong harangan sa IPS mode . Ang kombinasyong ito, na pinamamahalaan mula sa iisang web interface, ay lubos na nagpapadali sa pag-deploy ng proteksyon ng DPI sa maliliit at katamtamang laki ng mga network.
Sa maraming deployment, kinukumpleto ito ng koneksyon ng Pfsense/Suricata sa isang SIEM o sentralisadong log platform, na sinasamantala ang mga nakabalangkas na format ng output upang iugnay ang mga kaganapan at matukoy ang mas malawak na mga kampanya.
Pagsubaybay sa kaganapan at mga halimbawang talaan sa Suricata
Kapag tumatakbo na ang Suricata, ang mga kaganapan ay itinatala sa path na tinukoy ng default-log-dir, kadalasan ay /var/log/suricata . Ang fast.log file ay gumagamit ng isang compact text format na may mga timestamp, rule ID, klasipikasyon, at priyoridad, na angkop para sa mabilis na inspeksyon mula sa terminal (tail -f).
Halimbawa, kapag nakakaranas ng trapiko na may maling mga TCP checksum, maaari tayong makakita ng mga linyang tulad nito: mga timestamp na may petsa at oras, na sinusundan ng rule identifier (hal., 1:2200074:1), ang mensaheng "SURICATA TCPv4 invalid checksum", klasipikasyon, prayoridad, at ang source-destination IP/port pair. Ang mga ganitong uri ng alerto ay nagbibigay-daan para sa mabilis na pagtukoy ng mga isyu sa integridad ng packet o mga pagtatangkang umiwas.
Ang eve.json file ay naglalaman ng parehong mga kaganapan sa format na JSON, na may mga field tulad ng timestamp, event_type, src_ip, dest_ip, src_port, dest_port, proto, at isang alert subfile na may action, gid, signature_id, rev, signature, category, at severity. Ang format na ito ay madaling ma-intake gamit ang Logstash, Fluentd, Filebeat, o anumang iba pang log agent , na nagbibigay-daan para sa mas masaganang analytics kaysa sa simpleng paggamit ng plain text.
Kapag idine-deploy ang Suricata sa isang multi-core server (hal., 8 cores), ang thread compression ay madaling makikita sa mga tool tulad ng htop sa thread mode, na nagpapakita ng isa o higit pang capture threads (pcap, AF_PACKET, o NFQ) at isang malaking bilang ng mga detection thread na nakakalat sa mga cores. Ang pagsasaayos ng detect-thread-ratio at CPU affinity ay maaaring makaapekto nang malaki sa throughput at latency kapag ang dami ng trapiko ay lumalapit sa mga limitasyon ng platform.
Bago ito i-deploy sa produksyon, ipinapayong maglaan ng ilang oras sa pag-aayos kung aling mga hanay ng panuntunan ang na-activate upang maiwasan ang pagbaha ng mga maling positibo na maaaring humarang sa lehitimong trapiko o magkalat sa mga log. Pinapayagan ka ng Suricata-update na i-disable ang buong kategorya o indibidwal na mga panuntunan upang makahanap ng makatwirang balanse sa pagitan ng sensitivity at usability.
Mga espesyal na aplikasyon: VoIP, audio analytics, at malikhaing NFQUEUE
Higit pa sa mga klasikong gamit (proteksyon sa serbisyo sa web, pagtuklas ng malware, pagsusuri ng DDoS), ang duo ng Netfilter+NFQUEUE ay nagbibigay-daan para sa mga malikhaing solusyon sa mga larangan tulad ng VoIP. Halimbawa, posibleng mag-set up ng isang anti-SPIT (spam over IP telephony) filter o isang sistema para sa pagsensura ng kalaswaan sa mga RTP stream.
Ang ideya ay: tukuyin ang trapiko ng RTP sa pamamagitan ng mga port o sa pamamagitan ng pagkilala sa protocol at ipadala ito sa NFQUEUE; mula sa aplikasyon ng gumagamit, muling buuin ang stream ng RTP gamit ang isang library tulad ng librtp , kunin ang audio sa format na WAV at ipasa ito sa isang keyword recognition engine (wordspotting), tulad ng isang synthesis o recognition library na inaalok ng isang third party.
Batay sa mga natukoy na salita, maaaring magpasya ang prosesong NFQUEUE na payagan, harangan, o baguhin pa ang playback sa pamamagitan ng paglalagay ng beep sa stream, bagama't ang huli ay nangangailangan ng napakahusay na kontrol sa RTCP, mga sequence ng packet, at mga timing—halos isang man-in-the-middle na pamamaraan. Hindi ito basta-basta, ngunit sa teorya, perpektong makakamit ito sa pamamagitan ng paggamit ng parehong sistema ng pila at hatol.
Totoo na ang ilan sa mga ito ay maaaring gawin gamit ang isang simpleng sniffer na nagpapakain ng data sa isang panlabas na processor, at pagkatapos ay kumikilos batay sa SIP signaling o sa pamamagitan ng isang SBC (Asterisk, Kamailio, atbp.). Ang pagkakaiba sa paggamit ng NFQUEUE ay ang aksyon sa daloy ng RTP ay maaaring maging agarang at direkta , nang hindi kinakailangang i-coordinate ang maraming bahagi o maghintay para makumpleto ng signaling layer ang tawag.
Malinaw na inilalarawan ng mga sitwasyong ito ang potensyal ng kombinasyon ng GNU/Linux + Netfilter + Suricata + mga third-party library: hindi lamang ito tungkol sa pagharang sa mga port at IP address, kundi tungkol din sa pagsasaayos ng mga kumplikadong desisyon sa trapiko sa totoong oras gamit ang isang 100% libreng ecosystem ng software.
Kung titingnan ang buong paglalakbay, mula sa maliit na C program na laging tumatanggap ng mga packet hanggang sa isang multiprocess na Suricata deployment na isinama sa NFQUEUE, Pfsense, mga database at cache, mapapahalagahan ng isa ang kakayahang umangkop na iniaalok ng technology stack na ito upang bumuo ng lahat mula sa mga simpleng dynamic firewall hanggang sa mga arkitektura ng IDS/IPS na nasa antas ng data center, na may tunay na malalim na kakayahan sa inspeksyon at awtomatikong tugon sa patuloy na pagiging kumplikado ng mga pag-atake.