- NFQUEUE омогућава Netfilter-у да делегира одлуке о филтрирању и обележавању процесима корисничког простора, омогућавајући динамичке IP заштитне зидове и рутере.
- Сурицата пружа вишепроцесни IDS/IPS механизам са подршком за NFQUEUE, AF_PACKET и правила компатибилна са Snort и Emerging Threats.
- Интеграција NFQUEUE-а са Suricata-ом, базама података, Memcached-ом или Pfsense-ом вам омогућава да изградите напредна безбедносна и рутирајућа решења са бесплатним софтвером.
- Перформансе у великој мери зависе од дизајна нити и логике корисничког простора, што чини кључним оптимизацију и пажљив одабир саобраћаја који ће се испитати.
Ако радите са мрежама на ГНУ/Линуксу ( најбоље Линукс дистрибуције за безбедност и приватност ) и заинтересовани сте да превазиђете типични статички заштитни зид (фајервол), вероватно вас занима како да комбинујете Нетфилтер, НФКВЈУЕ и Сурицату да бисте изградили заиста флексибилан ИДС/ИПС без трошења богатства на власнички хардвер. То је управо област коју ћемо истражити у овом чланку, комбинујући елементе ниског нивоа (језгро, редови чекања, Ц) са алатима високог нивоа (Сурицата, правила, MySQL, Мемкешд, пфСенсе).
Основна идеја је веома моћна: искористити чињеницу да језгро (погледајте како оптимизовати Линукс језгро ) може да постави пакете у кориснички простор и дозволи прилагођеном програму да одлучи шта да ради са њима. Ово се може користити за филтрирање саобраћаја (напредни заштитни зид, IPS), динамичко рутирање или интеграцију пословне логике (базе података, кеш меморије, откривање напада на веб апликације, VoIP, итд.). А ако додамо Suricata као вишепроцесни IDS/IPS механизам, имамо веома робусну комбинацију за окружења, од лабораторија до дата центара са великим прометом.
NFQUEUE и Netfilter: подизање заштитног зида на ниво корисничког простора
У типичном ГНУ/Линукс систему, правила Netfilter/iptables (или nftables) се обично користе као статичке политике које се у потпуности налазе у простору језгра . Фронтендови и уређаји (укључујући многа решења заснована на Netfilter-у или BSD-овом Packet Filter-у) чувају конфигурацију у текстуалним, XML или SQLite датотекама и када се нешто промени, они регенеришу и поново учитавају правила. Ово је флексибилно, али логика остаје нека врста снимка заштитног зида са мањим динамичким подешавањима (ограничења броја конекција по секунди, conntrack, подударање земаља, слој 7 ако је доступан, итд.).
Оно што NFQUEUE предлаже је револуција: уместо да језгро увек доноси коначну одлуку, ту одлуку можемо делегирати корисничком процесу . Језгро ставља пакет у нумерисани ред, а апликација која користи библиотеку libnetfilter_queue га преузима, анализира и враћа пресуду: прихвати, одбаци или чак означи за рутирање политиком. То је као да имате програмабилног „судију“ написаног у C-у, Python-у или Perl-у на врху заштитног зида (фајервола).
Лепота овога је у томе што наш програм буквално може да уради шта год желимо: да упита /dev/urandom, базу података, веб сервис, дистрибуирани кеш или софистицирани алгоритам пре него што одговори језгру. У архитектонском смислу, заштитни зид престаје да буде једноставан скуп статичких правила и постаје цевовод где се Netfilter, редови и корисничке апликације уклапају као делови слагалице.
NFQUEUE се састоји од два дела: циља NFQUEUE у iptables-у , који шаље пакете у одређени ред, и корисничке библиотеке libnetfilter_queue , која вам омогућава да читате те пакете и издате пресуду. То није једноставан снифер попут tcpdump-а: овде имамо могућност да директно одлучимо о путањи којом ће пакет кренути.
Основна конфигурација iptables-а помоћу NFQUEUE-а
Са становишта iptables-а, коришћење NFQUEUE-а је прилично једноставно: додајете правило ланцу који вас занима да бисте послали у ред пакете који испуњавају одређене критеријуме (изворна/одредишна IP адреса, портови, стања, додатни модули као што су GeoIP или layer7 ако су доступни, итд.).
На пример, ако желимо да пошаљемо на NFQUEUE све пингове који стигну на сам хост:
iptables -I INPUT -p icmp -j NFQUEUE
Ово шаље долазне ICMP пакете у ред 0 (осим ако није другачије наведено). Могли бисмо да одредимо други ред са нечим попут `--queue-num 3` . Приликом навођења правила са бројачима (`iptables -L -n -v -x`), видећемо да се бројачи повећавају, што указује да се пакети стављају у ред . Важан детаљ: ако постоје пакети у реду и ниједан кориснички процес их не преузима и не обрађује, подразумевано понашање је да их одбије, тако да квар апликације, по дизајну, доводи до блокирања саобраћаја.
Програмирање против libnetfilter_queue: „здраво свете“ у C-у
Да бисте се придружили реду из корисничког простора, користи се библиотека libnetfilter_queue (која се заузврат ослања на libnfnetlink). На дистрибуцијама попут Дебијана, једноставно инсталирајте развојне пакете:
apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc
Скелет минималног програма који увек прихвата пакете састоји се од неколико веома јасних корака: отварање библиотеке, одвајање свих постојећих обрађивача, повезивање са AF_INET протоколом, креирање реда са функцијом повратног позива, дефинисање режима копирања и улазак у петљу пријема . Повратни позив се извршава за сваки пакет у реду чекања, издвајајући ИД и враћајући пресуду.
У пракси, ток је отприлике овакав: `nfq_open` за добијање дескриптора, `nfq_unbind_pf` за његово чишћење, `nfq_bind_pf` за повезивање са AF_INET, `nfq_create_queue` за регистровање повратног позива у реду 0, `nfq_set_mode` за означавање да ли желимо метаподатке или цео пакет, петља са `recv()` преко дескриптора и `nfq_handle_packet` за обраду сваког пакета . По изласку, ред се уништава са `nfq_destroy_queue`, а дескриптор се затвара са `nfq_close`.
Ова врста „здраво свете“ омогућава прецизно мерење утицаја NFQUEUE. Ако пример компајлирамо са нечим попут:
gcc -o nftest code.c -lnfnetlink -lnetfilter_queue
А ако саобраћај из iperf-а ставимо у ред (на пример, TCP порт 5001 у INPUT и OUTPUT), видећемо да код који једноставно прихвата пакете једва утиче на перформансе на гигабитној мрежи . Међутим, постоји кључни детаљ: исписивање информација у повратном позиву (printf, fflush, итд.) значајно смањује пропусност, као што се може видети када се упореди iperf са и без отклањања грешака на екрану.
Напредне NFQUEUE опције: бајпас, балансирање и отварање у случају квара
NFQUEUE укључује неколико занимљивих iptables опција које мењају подразумевано понашање редова чекања и које би требало знати пре уласка у продукционо или високоперформансно окружење, јер утичу на то како се обрађује отказивање корисничких апликација или попуњавање редова.
Команда `--queue-bypass` вам омогућава да осигурате да, ако ниједан процес не слуша ред, пакети се не одбацују већ се прослеђују на следећи скок у iptables ланцу. Ово може бити корисно ако желите да систем „неуспешно отвори“ када кориснички сервис није доступан, иако је са безбедносне тачке гледишта то мач са две оштрице.
Опција `--queue-balance` вам омогућава да дистрибуирате пакете у распону редова (на пример, од 0 до 3) и затим имате више независних процеса или нити које троше из сваког реда . Netfilter-ов код осигурава да пакети из истог тока увек заврше у истом реду, што знатно поједностављује одржавање доследности у логици одлучивања.
Такође постоји и режим `--fail-open` , који контролише шта се дешава када се ред попуни зато што кориснички процес ради преспоро. Његово омогућавање доводи до тога да језгро директно прихвата пакете уместо да их одбацује, спречавајући масовне прекиде саобраћаја. Поново, ово може бити безбедносни проблем, јер ако желимо да доносимо одлуке од случаја до случаја, губитак пакета одлука значи неуспех у испуњавању тог циља.
Да би пратио шта се дешава са редовима чекања, Netfilter открива информације у псеудо-fs датотеци /proc/net/netfilter/nfnetlink_queue , која се може лако добити из скрипти или алата за праћење.
Интеграција пословне логике: тестирање помоћу Memcached-а и MySQL-а
Када је процес „здраво свете“ под контролом, следећи природан корак је обогаћивање повратног позива позивима ка екстерним системима . Типичан експеримент укључује одлучивање о томе да ли ће се прихватити или одбити пакет на основу тога да ли се изворна IP адреса појављује у неком бекенду, као што је MySQL база података или Memcached кеш.
У случају Memcached-а, демон се инсталира (apt-get install memcached) и кључ, на пример authorized , се учитава са IP адресом која нас занима. То можемо урадити једноставним echo и netcat командама, а затим проверити помоћу get команде да ли је вредност исправно сачувана. Одатле, NFQUEUE програм, поред добијања ID-а пакета, прима цео пакет користећи NFQNL_COPY_PACKET , издваја IP заглавље (struct iphdr) и конвертује изворну адресу у стринг са inet_ntop.
Да би се избегло губљење времена на отварање веза са сваким пакетом, Memcached веза се иницијализује само једном у главној методи (memcached_create, memcached_server_list_append, memcached_server_push), а руковалац се чува у глобалним променљивим. У повратном позиву, memcached_get се позива са жељеним кључем, изворна IP адреса се упоређује са преузетом вредношћу и ако се подударају, враћа се NF_ACCEPT; у супротном, враћа се NF_DROP. Ако кључ не постоји или постоји грешка, пакет се одбацује као конзервативна политика.
Коришћењем iperf-а, ова стратегија смањује пропусност на приближно 140 Mbit/s на гигабитној мрежи , и примећено је да ред почиње да доживљава губитке (што је назначено, на пример, симболима унутар самог кода). Другим речима, само позивање кеш сервиса по пакету већ ствара значајан трошак, иако остаје одрживо за средње количине саобраћаја ако се оптимизује.
Са MySQL-ом, приступ је сличан, али сложенији: инсталирају се серверска и клијентска библиотека, креира се база података (на пример, nfqueue) са једноставном табелом под називом authorized(ip varchar(50)) и убацује се дозвољена IP адреса. У програму, `mysql_init` и `mysql_real_connect` се покрећу при покретању, а у повратном позиву се конструише упит попут `select * from authorized where ip like 'xxxx'`. Ако се упит успешно изврши и пронађе се ред, пакет се прихвата; у супротном, одбацује се.
Са омогућеним кеширањем упита у MySQL-у, тестови дају око 188 Mbit/s , што пада на 103 Mbit/s када је кеширање упита онемогућено. Ове бројке, иако далеко од гигабита, показују да чак и са најмање елегантним приступом (једнонитни, без оптимизације) , респектабилне количине саобраћаја могу се обрадити коришћењем одлука вођених базом података или заснованих на кеширању.
Перформансе, вишенитност и коришћење процесора
Тестови са iperf-ом, Memcached-ом и MySQL-ом јасно показују да ограничење перформанси није толико наметнуто самим NFQUEUE-ом колико логиком коју додајемо у кориснички простор и начином на који је имплементирамо. Извршна датотека која враћа само NF_ACCEPT постиже скоро гигабит без икаквог проблема; чим уведемо I/O или мрежне позиве, пропусност пада, а CPU NFQUEUE машине, Memcached демона или MySQL-а је гурнут до својих граница.
Са архитектонског становишта, ово има две импликације. С једне стране, потврђује да је делегирање одлука о заштитном зиду корисничким апликацијама за значајне количине саобраћаја сасвим одрживо , под условом да се узму у обзир стварни трошкови сваког позива. С друге стране, показује да се, да би се приближили максималним могућностима платформе, мора размотрити вишенитност или вишепроцесна обрада . NFQUEUE омогућава дистрибуцију саобраћаја у више редова; могли бисмо да покренемо неколико копија наше апликације, од којих свака слуша други ред, и да искористимо више језгара без муке са pthread-овима или масивним форковима.
Још једна очигледна оптимизација би била ограничавање саобраћаја који пролази кроз NFQUEUE . У тестовима, цео iperf ток је био стављен у ред чекања, али у стварном сценарију, могли бисмо да ставимо у ред само пакете са NEW стањем, дозволимо пролаз ESTABLISHED/RELATED пакетима и резервишемо скупу логику за пријаве или сумњиве обрасце.
На крају крајева, коришћење процесора и дизајн нити су кључни: ако кориснички процес не успе, ред се попуњава и морамо да прибегнемо стварима попут отварања при отказу или прихватања одбацивања, губећи део фине контроле којој овај приступ тежи.
Динамичко рутирање са брендирањем Netfilter-а
NFQUEUE није ограничен само на изговарање „прихвати“ или „баци“. Такође се може користити за примену Netfilter (fwmark) заставица на пакете и њихово комбиновање са ip rule и iproute2 за креирање веома флексибилних, готово лаганих VRF-стилских политичких шема рутирања.
Поступак, уопштено говорећи, би био: дефинисати неколико табела рутирања у /etc/iproute2/rt_tables , на пример споро и брзо; доделити свакој табели различиту подразумевану руту (једну преко оптичког кабла, а другу преко ограниченије везе); користити ip правило да би се одредило да пакети са fwmark 1 иду у брзу табелу, они са fwmark 2 у спору, итд.; и на крају, користити NFQUEUE да би се пакети обележили на одговарајући начин пре враћања пресуде.
Да би се поставила пресуда из повратног позива, користи се `nfq_set_verdict2` , што је слично `nfq_set_verdict`, али вам омогућава да поставите вредност пресуде коју ће `ip rule` затим видети. Комбинујући све ово, можете направити IP рутер који одлучује где да рутира на основу произвољних критеријума: од апсурдних ствари попут парне/непарне величине пакета до спољних улаза као што су алгоритми за предвиђање саобраћаја, догађаји на друштвеним мрежама или сигнали из система за праћење.
Резултат је систем у коме језгро наставља да прослеђује пакете уобичајеном брзином, али тачна путања којом сваки ток иде је делегирана спољном софтверу који може да промени мишљење у реалном времену без додиривања статичких правила.
NFQUEUE и Suricata: IPS високог нивоа у GNU/Linux-у
Све горе наведено може се програмирати ручно у C-у, али када је у питању детекција упада и дубинска инспекција пакета, разумна опција је обично ослањање на зрели IDS/IPS механизам . Ту долази до изражаја Suricata, која је настала управо као вишепроцесна алтернатива Snort-у, са IPS могућностима од самог почетка и снажним фокусом на искоришћавање многих CPU језгара доступних данас.
Суриката је написана од нуле и дистрибуирана под GPLv2 лиценцом ; Фондација за отворену информациону безбедност (OISF) одржава и механизам и прилично свеобухватан екосистем правила и документације. За разлику од Snort 2.x, који је наследио једнонитно језгро и на њега је додат закрпа, Суриката је дизајнирана да подели радно оптерећење на више нити: снимање, декодирање, детекција и излаз, са различитим стратегијама расподеле оптерећења.
На функционалном нивоу, Suricata пружа изворну подршку за IPv6, инспекцију слоја 7 (веома напредни HTTP преко HTP библиотеке), препознавање протокола независно од портова , реконструкцију протока и веома моћан систем променљивих сесије (flowbits) за корелацију различитих фаза напада који се шире преко неколико TCP веза.
Додатна предност је његова компатибилност са Snort правилима и могућност коришћења и Sourcefire VRT и Emerging Threats потписних скупова (бесплатна ET Open и комерцијална ET Pro верзија). Штавише, извози догађаје у веома корисним форматима (fast.log, JSON у eve.json) за интеграцију са SIEM-овима, ELK-ом, Splunk-ом и другим системима.
Suricata као IPS у Линуксу: режими снимања и NFQUEUE
На ГНУ/Линуксу, Сурицата може да ради у различитим режимима у зависности од тога како се саобраћај пресрета: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … Сваки има своје предности и захтеве. На чистом IPS нивоу, два најважнија су NFQUEUE и AF_PACKET.
У NFQ (NFQUEUE) режиму , ток је сличан оном описаном раније: скуп iptables правила шаље пакете у ред чекања; Suricata, која се покреће у корисничком простору, чита из тог реда, прегледа садржај у складу са својим правилима и враћа пресуду језгру: NF_ACCEPT, NF_DROP или NF_REPEAT. Трећи се може користити за поновно убризгавање пакета у исту iptables табелу након примене додатних ознака или модификација.
Овај режим је веома флексибилан и једноставан за имплементацију у постојећим инфраструктурама , јер захтева само модификовање правила на одређеним тачкама (на пример, НАПРЕД, УЛАЗ, ИЗЛАЗ) и остављање свега осталог како јесте. Цена је додатни трошак пропуштања пакета горе-доле кроз NFQUEUE, са горе поменутим утицајем ако је запремина веома велика или су правила захтевна за ресурсе.
У AF_PACKET режиму , Suricata ради ближе мрежном интерфејсу, копирајући пакете преко AF_PACKET сокета. Ово је много бржи приступ без копирања , али захтева да систем функционише као гејтвеј са два интерфејса и да се блокирање саобраћаја врши на нивоу прослеђивања између мрежних картица: пакет који треба блокирати се једноставно не прослеђује са улазног на излазни интерфејс.
У оба режима, Suricata се може комбиновати са Netfilter-ом, али NFQUEUE се посебно добро уклапа у сценарије где желимо да поново користимо сву iptables логику (политике, опсеге, претходна правила) и да Suricata-и шаљемо само саобраћај који нас занима за детаљан преглед.
Основна инсталација Сурицате из изворног кода
За оне који више воле да компајлирају Suricata-у уместо коришћења пакета, процес на Debian/Ubuntu дистрибуцијама подразумева прво инсталирање зависности компајлирања (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev, итд.), преузимање tarball-а са званичне веб странице и покретање класичне команде ./configure, make, make install.
Током фазе конфигурације, скрипта ће назначити које су функције подршке омогућене: AF_PACKET да/не, PF_RING, NFQUEUE да/не, NFLOG, IPFW, подршка за libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP, итд. Важно је проверити да ли је NFQUEUE омогућен ако желимо да радимо у том режиму и да ли је библиотека за снимање која нас занима лоцирана.
Након инсталирања бинарне датотеке, можете покренути `make install-conf` да бисте распоредили подразумевану конфигурацију у `/etc/suricata` и `make install-rules` да бисте преузели и поставили скуп правила о новим претњама у `/etc/suricata/rules`. Ови скупови се затим могу ажурирати помоћу алата као што је `suricata-update`.
На Red Hat/CentOS системима, логика је слична, коришћење yum или dnf за зависности (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel, итд.) а затим компајлирање истим корацима. Из разлога перформанси, такође је препоручљиво онемогућити LRO/GRO у интерфејсу за снимање помоћу ethtool-а, јер ове функције растерећења могу утицати на видљивост пакета на нивоу IDS-а.
Конфигурација Сурицате: YAML, променљиве и нити
Главна конфигурација Сурицате налази се у /etc/suricata/suricata.yaml . То је прилично читљива и јако коментарисана YAML датотека, где је дефинисано све, од путања логова и скупова правила до циљних политика оперативног система и параметара за нити.
Једно од основних поља је `default-log-dir` , које одређује где ће се лог датотеке чувати (подразумевано, `/var/log/suricata`). У одељку `vars` налазе се променљиве као што су `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` и `SSH_PORTS`, које служе као скраћенице у правилима. `HOME_NET` је обично конфигурисан са локалним мрежним опсегом који желимо да заштитимо, док је `EXTERNAL_NET` обично дефинисан као `!HOME_NET`.
Још један важан део је host-os-policy , која говори Suricata-и који оперативни систем треба да покреће одређене IP опсеге. Ово му омогућава да прилагоди начин на који поново саставља TCP или интерпретира одређена понашања мрежног стека , што отежава заобилажење протокола на основу разлика између стекова (Windows наспрам Linux-а, итд.). Одређени опсези могу се доделити категоријама као што су Windows, Linux, BSD, Vista, Windows 2003, итд.
Што се тиче нити, одељак за нити вам омогућава да фино подесите афинитет процесора и број нити за детекцију. Подразумевано, `set-cpu-affinity` је обично онемогућен, што омогућава системском распоређивачу да дистрибуира нити по језгрима. Параметар `detect-thread-ratio` показује колико нити за детекцију се креира по доступном језгру; са `detect-thread-ratio: 1.5` на машини са 8 језгара, Suricata ће генерисати 12 нити за детекцију, плус нити за хватање и управљање.
Читав овај модел се затим одражава у излазу када се демон покрене: видљиви су нит за снимање (на пример, pcap) и више нити детектора, поред менаџера тока и менаџера статистике. Ова вишепроцесна архитектура је оно што омогућава Suricata-и да се много боље скалира од једнонитних мотора када се суочи са везама од 10/40 Gbit/s.
Ажурирања правила и потписа у Сурикати
Сурицата се ослања на скупове правила за откривање образаца напада, аномалног понашања и злоупотребе протокола. Поред прихватања правила у Снорт формату , најчешћи екосистем је онај од Emerging Threats: ET Open (бесплатно) и ET Pro (комерцијално), са правилима усмереним ка тренутним претњама.
Многе модерне дистрибуције укључују алатку `suricata-update` , која поједностављује управљање правилима: ажурира изворе, омогућава или онемогућава одређене провајдере и преузима најновије верзије скупова потписа. Типичан ток рада би био инсталирање `suricata-update` (на пример, путем pip-а), покретање првог `suricata-update` за преузимање ET Open-а, листање извора помоћу `suricata-update list-sources`, омогућавање додатних извора као што су `ptresearch/attackdetection`, `oisf/trafficid` или `sslbl/ssl-fp-blacklist` и поновно покретање `suricata-update` за регенерацију датотеке са правилима.
Датотека suricata.yaml се подешава тако да указује на исправну путању правила, и одатле ће Suricata почети да подиже догађаје упозорења који ће бити евидентирани у fast.log (брз, читљив текст) и eve.json (структурирани JSON са веома комплетним информацијама) . Овај други формат је посебно користан за слање података контролним таблама, системима корелације или прилагођеним скриптама.
Поред потписа, Сурицата укључује декодере и парсере за више протокола , што јој омогућава да буде мање зависна од портова: може да идентификује HTTP саобраћај чак и ако пролази кроз нестандардне портове, да детектује SSH, TLS, DNS итд. преко различитих портова и нивоа енкапсулације (укључујући мешовите IPv4/IPv6 тунеле).
Практична употреба: од откривања веб експлоата до аутоматског блокирања
Један од најпожељнијих случајева употребе у хостинг окружењима или дата центрима јесте откривање у реалном времену покушаја искоришћавања рањивости у веб апликацијама (нпр. WordPress и његови додаци) и аутоматско реаговање, обично блокирањем или стављањем изворне IP адресе на црну листу у заштитном зиду (фајерволу).
Суриката, покретана ажурираним правилима, способна је да препозна специфичне обрасце напада на URL-ове, параметре, HTTP корисне податке , па чак и секвенце захтева које се подударају са познатим експлоитима. IDS може да ради у пасивном режиму, примајући саобраћај путем огледала са порта свитча (SPAN), али да би деловао као IPS и блокирао нападе, мора бити интегрисан са равни прослеђивања.
Постоје два уобичајена приступа: подешавање IDS-а као онлајн моста, тако да саобраћај физички пролази кроз машину (коришћењем iptables, AF_PACKET или PF, у зависности од платформе), или остављање топологије каква јесте, али комбиновањем огледала са акцијама на централном заштитном зиду путем API-ја, скрипти или NFQUEUE . Први приступ минимизира латенцију између детекције и блокирања, по цену додавања још једног елемента „у средини“ мреже; други нуди већу флексибилност и отпорност, али уводи већу сложеност у оркестрацију.
Сасвим је изводљиво да систем за детекцију упада (IDS) открије покушај искоришћавања рањивог WordPress додатка, а затим, директно или преко повезане компоненте, дода IP адресу нападача на црну листу iptables-а. То се може урадити путем Suricata JSON излаза и скрипти које позивају iptables/nftables , или делегирањем дела логике NFQUEUE-у, где сам механизам или повезани процес доноси одлуку у ходу без чекања да се спољна листа ажурира.
Ово вам омогућава да се фокусирате на претње које су заиста важне (експлоатације, покушаји ескалације, веома агресивна скенирања), игноришући или једноставно евидентирајући позадинску буку као што су основна скенирања портова која, у многим контекстима, сама по себи нису забрињавајућа.
Suricata на Pfsense-у: заштитни зид отвореног кода са интегрисаним IDS/IPS-ом
Не могу или не желе сви да приуште врхунски заштитни зид попут оног у Пало Алту. У многим окружењима, атрактивније је подесити решење отвореног кода са pfSense и Suricata , које покрива и напредне потребе за заштитним зидовима (multi-WAN, VLAN, VPN, NAT, итд.) и IDS/IPS.
Pfsense, базиран на FreeBSD-у и Packet Filter-у, посебно добро функционише са виртуелизованим окружењима (Proxmox, KVM, итд.), с тим што се препоручује коришћење E1000 картица уместо Virtio у KVM машинама ако желите да избегнете проблеме са перформансама и падове система под оптерећењем, осим ако не примените Netgate-ове препоруке (онемогућите hardware checksum offload у System > Advanced > Networking и поново покрените систем, знајући да ово можда неће бити довољно са веома великим оптерећењима).
Минимални хардверски захтеви за лабораторију са Suricata-ом на Pfsense-у могу бити скромни (1 CPU 500 MHz, 1 GB RAM-а, 4 GB диска), али за озбиљну употребу препоручују се најмање 2 CPU-а, 4 GB RAM-а и 16 GB простора за складиштење , не заборављајући да имате неколико мрежних интерфејса (један за WAN, други за LAN, више ако желите више WAN-ова или сложене VLAN-ове).
Инсталирање самог pfSense-а је веома брзо: покрећете систем са ISO датотеке, прихватате лиценцу, бирате инсталацију, бирате језик и распоред тастатуре, остављате партиционисање укључено аутоматски (Auto UFS ако ћете користити цео диск) и за неколико минута систем је спреман за прво покретање. Конзола нуди мени за додељивање интерфејса, поновно покретање, покретање командне линије итд.
У лабораторији, на пример у VirtualBox-у, уобичајено је да се привремено онемогући Pfsense заштитни зид из конзоле помоћу pfctl -d како би се приступило веб интерфејсу преко WAN мреже (корисничко име admin, лозинка pfsense) и завршио почетни чаробњак: општи подаци, NTP сервери, WAN конфигурација (DHCP је обично довољан у лабораторији), LAN, промена администраторске лозинке и примена конфигурације.
Када се приступ стабилизује, можете креирати правило у WAN заштитном зиду (фајерволу) које дозвољава HTTPS из било ког извора на pfsense IP адресу, додајући описне сепараторе за визуелно организовање правила (на пример, „Приступ заштитном зиду“). Такође је препоручљиво онемогућити опцију за блокирање приватних мрежа на WAN мрежи ако сте у тест окружењу са RFC1918 адресама, како бисте избегли стално коришћење `pfctl -d`.
Инсталација Suricata-е на pfSense-у и преглед
Са покренутом и покренутом pfSense базом, инсталирање Suricata-е је једноставно као одлазак на Систем > Менаџер пакета > Доступни пакети , тражење Suricata-е и инсталирање пакета. Процес преузима неколико датотека и може потрајати неко време у зависности од вашег хардвера, али је у потпуности потпомогнут путем веб интерфејса.
Једном инсталиран, у картици Сервиси се појављује унос Сурицате, где можете конфигурисати инстанце према интерфејсу (WAN, LAN, VLAN, итд.), изабрати које скупове правила ћете користити, активирати IDS или IPS режим и подесити параметре перформанси и евидентирања. Распон опција је широк (довољан за целе чланке само о конфигурацији), али предност је што се многи задаци који у Линуксу захтевају ручно YAML уређивање овде обављају помоћу образаца и поља за потврду.
Важна напомена: Иако би могло бити примамљиво отворити pfSense администрацију директно на интернет у лабораторијском окружењу, у продукцији је кључно ограничити приступ статичким IP адресама, користити VPN-ове за даљинско управљање и избегавати остављање веб конзоле изложеном по сваку цену . pfSense је веома флексибилан, али се такође мора третирати као критични елемент какав јесте.
Са омогућеним Suricata-ом на pfSense-у, добијате окружење у којем саобраћај пролази кроз pfSense ради заштитног зида и NAT-а, а Suricata га прегледа према својим правилима и може га блокирати у IPS режиму . Ова комбинација, којом се управља из једног веб интерфејса, значајно поједностављује имплементацију DPI заштите у малим и средњим мрежама.
У многим имплементацијама, ово је допуњено повезивањем Pfsense/Suricata са SIEM-ом или централизованом платформом за логовање, користећи предности структурираних излазних формата за корелацију догађаја и откривање ширих кампања.
Праћење догађаја и примери логова у Suricata-и
Када се Suricata покрене, догађаји се евидентирају на путањи дефинисаној помоћу default-log-dir, обично /var/log/suricata . Датотека fast.log користи компактан текстуални формат са временским ознакама, ИД-овима правила, класификацијама и приоритетом, погодан за брзу проверу из терминала (tail -f).
На пример, када наиђемо на саобраћај са нетачним TCP контролним збировима, можемо видети линије попут ових: временске ознаке са датумом и временом, праћене идентификатором правила (нпр. 1:2200074:1), поруком „SURICATA TCPv4 неважећи контролни збир“, класификацијом, приоритетом и паром IP/порт извора и одредишта. Ове врсте упозорења омогућавају брзу идентификацију проблема са интегритетом пакета или покушаја избегавања.
Датотека eve.json садржи исте догађаје у JSON формату, са пољима као што су timestamp, event_type, src_ip, dest_ip, src_port, dest_port, proto и поддатотеком упозорења са action, gid, signature_id, rev, signature, category и severity. Овај формат се може лако унети помоћу Logstash-а, Fluentd-а, Filebeat-а или било ког другог агента за логовање , што омогућава много богатију аналитику него једноставно коришћење обичног текста.
Приликом примене Suricata-е на вишејезгарном серверу (нпр. 8 језгара), компресија нити је лако видљива у алатима као што је htop у режиму нити, приказујући једну или више нити за снимање (pcap, AF_PACKET или NFQ) и велики број нити за детекцију распоређених по језгрима. Подешавање односа нити за детекцију и афинитета процесора може значајно утицати на пропусност и латенцију када се обим саобраћаја приближи ограничењима платформе.
Пре него што га примените у продукцију, препоручљиво је да проведете неко време фино подешавајући који се скупови правила активирају како бисте избегли поплаву лажно позитивних резултата који би могли да блокирају легитиман саобраћај или затрпају логове. Suricata-update вам омогућава да онемогућите читаве категорије или појединачна правила како бисте пронашли разумну равнотежу између осетљивости и употребљивости.
Специјалне примене: VoIP, аудио аналитика и креативни NFQUEUE
Поред класичних употреба (заштита веб сервиса, откривање злонамерног софтвера, DDoS анализа), Netfilter+NFQUEUE дуо омогућава прилично креативна решења у областима као што је VoIP. На пример, могуће је подесити anti-SPIT (спам преко IP телефоније) филтер или систем за цензурисање вулгарности у RTP стримовима.
Идеја би била: идентификовати RTP саобраћај помоћу портова или препознавања протокола и послати га у NFQUEUE; из корисничке апликације, реконструисати RTP ток користећи библиотеку као што је librtp , издвојити аудио у WAV формату и проследити га механизму за препознавање кључних речи (wordspotting), као што је библиотека за синтезу или препознавање коју нуди трећа страна.
На основу детектованих речи, NFQUEUE процес би могао да одлучи да дозволи, блокира или чак измени репродукцију уметањем звучног сигнала у ток, иако ово друго захтева веома фино подешену контролу RTCP-а, секвенци пакета и времена - готово приступ „човек у средини“. Није тривијално, али теоретски је сасвим оствариво коришћењем истог система редова и пресуда.
Тачно је да се део овога може урадити једноставним снифером који доставља податке спољном процесору, а затим делује на SIP сигнализацију или путем SBC-а (Asterisk, Kamailio, итд.). Разлика у коришћењу NFQUEUE је у томе што акција на RTP ток може бити тренутна и директна , без потребе за координисањем више компоненти или чекањем да сигнални слој заврши позив.
Ови сценарији јасно илуструју потенцијал комбинације GNU/Linux + Netfilter + Suricata + библиотека трећих страна: не ради се само о блокирању портова и IP адреса, већ о оркестрирању сложених одлука о саобраћају у реалном времену користећи екосистем 100% слободног софтвера.
Посматрајући целокупно путовање, од малог C програма који увек прихвата пакете до вишепроцесног Suricata имплементирања интегрисаног са NFQUEUE, Pfsense, базама података и кеш меморијама, може се ценити флексибилност коју овај технолошки стек нуди за изградњу свега, од једноставних динамичких заштитних зидова до IDS/IPS архитектура на нивоу дата центра, са стварним могућностима дубинске инспекције и аутоматизованим одговором на све сложеније нападе.