- NFQUEUE antaa Netfilterille mahdollisuuden delegoida suodatus- ja merkintäpäätökset käyttäjätilan prosesseille, mikä mahdollistaa dynaamiset IP-palomuurit ja -reitittimet.
- Suricata tarjoaa moniajoisen IDS/IPS-moottorin, joka tukee NFQUEUE- ja AF_PACKET-hyökkäyksiä sekä Snortin ja Emerging Threatsin kanssa yhteensopivia sääntöjä.
- NFQUEUE-integrointi Suricatan, tietokantojen, Memcachedin tai Pfsensen kanssa mahdollistaa edistyneiden tietoturva- ja reititysratkaisujen rakentamisen ilmaisilla ohjelmistoilla.
- Suorituskyky riippuu pitkälti säikeiden suunnittelusta ja käyttäjätilan logiikasta, joten on tärkeää optimoida ja valita tarkastettava liikenne huolellisesti.
Jos työskentelet GNU/Linux-verkkojen ( parhaat Linux-jakelut turvallisuuden ja yksityisyyden kannalta ) parissa ja olet kiinnostunut menemään tyypillisen staattisen palomuurin ulkopuolelle, olet luultavasti kiinnostunut siitä, miten yhdistää Netfilter, NFQUEUE ja Suricata rakentaaksesi todella joustavan IDS/IPS:n ilman, että kulutetaan omaisuuksia omaisuuksiin suljetussa laitteistossa. Juuri tätä aluetta tutkimme tässä artikkelissa yhdistämällä matalan tason elementtejä (ydin, jonot, C) korkean tason työkaluihin (Suricata, säännöt, MySQL, Memcached, pfSense).
Perusajatuksena on erittäin tehokas: hyödyntää sitä tosiasiaa, että ydin (katso kuinka optimoida Linux-ydin ) voi jonottaa paketteja käyttäjätilaan ja antaa mukautetun ohjelman päättää, mitä niille tehdään. Tätä voidaan käyttää liikenteen suodattamiseen (kehittynyt palomuuri, IPS), dynaamiseen reititykseen tai liiketoimintalogiikan integrointiin (tietokannat, välimuistit, verkkosovellushyökkäysten tunnistus, VoIP jne.). Ja jos lisäämme Suricatan moniprosessisena IDS/IPS-moottorina, meillä on erittäin vankka yhdistelmä ympäristöille laboratorioista paljon liikennöityihin datakeskuksiin.
NFQUEUE ja Netfilter: palomuurin nostaminen käyttäjätilaan
Tyypillisessä GNU/Linux-järjestelmässä Netfilter/iptables- (tai nftables-) sääntöjä käytetään yleensä staattisina käytäntöinä, jotka sijaitsevat kokonaan kernel-tilassa . Frontend-ohjelmat ja laitteet (mukaan lukien monet Netfilteriin tai BSD:n Packet Filter -suodattimeen perustuvat ratkaisut) tallentavat kokoonpanon teksti-, XML- tai SQLite-tiedostoihin, ja kun jokin muuttuu, ne luovat ja lataavat säännöt uudelleen. Tämä on joustavaa, mutta logiikka pysyy eräänlaisena tilannekuvana palomuurista pienin dynaamisin muutoksin (yhteysmäärän rajoitukset sekunnissa, yhteyden seuranta, maan yhteensovitus, kerros 7, jos saatavilla, jne.).
NFQUEUE ehdottaa mullistavaa ratkaisua: sen sijaan, että ydin tekisi aina lopullisen päätöksen, voimme delegoida päätöksen käyttäjäprosessille . Ydin asettaa paketin numeroituun jonoon, ja libnetfilter_queue-kirjastoa käyttävä sovellus hakee sen, analysoi sen ja palauttaa päätöksen: hyväksyy, hylkää tai jopa merkitsee sen käytäntöreititystä varten. Se on kuin palomuurin päällä olisi ohjelmoitava "tuomari", joka on kirjoitettu C-, Python- tai Perl-kielellä.
Tämän kauneus piilee siinä, että ohjelmamme voi kirjaimellisesti tehdä mitä tahansa haluamme: tehdä kyselyn /dev/urandomiin, tietokantaan, verkkopalveluun, hajautettuun välimuistiin tai käyttää hienostunutta algoritmia ennen kuin se vastaa ytimelle. Arkkitehtuurin kannalta palomuuri lakkaa olemasta yksinkertainen joukko staattisia sääntöjä ja siitä tulee putki, jossa Netfilter, jonot ja käyttäjäsovellukset sopivat yhteen kuin palapelin palaset.
NFQUEUE koostuu kahdesta osasta: iptables-kirjaston NFQUEUE-kohteesta , joka lähettää paketit tiettyyn jonoon, ja libnetfilter_queue-käyttäjäkirjastosta , jonka avulla voit lukea nämä paketit ja antaa tuloksen. Se ei ole yksinkertainen nuuskija kuten tcpdump: tässä meillä on mahdollisuus päättää suoraan paketin kulkemasta polusta.
Iptablesin peruskonfiguraatio NFQUEUE:lla
IpTablesin näkökulmasta NFQUEUE:n käyttö on melko suoraviivaista: lisäät haluamasi ketjun säännön, joka lähettää jonoon tietyt kriteerit täyttävät paketit (lähde-/kohde-IP, portit, tilat, lisämoduulit, kuten GeoIP tai layer7, jos saatavilla, jne.).
Jos esimerkiksi haluamme lähettää NFQUEUE-palveluun kaikki itse isännälle saapuvat pingit:
iptables -I INPUT -p icmp -j NFQUEUE
Tämä lähettää saapuvat ICMP-paketit jonoon 0 (ellei toisin ole mainittu). Voisimme määrittää toisen jonon esimerkiksi komennolla `--queue-num 3` . Kun listaamme säännöt laskureilla (`iptables -L -n -v -x`), näemme laskurien kasvavan, mikä osoittaa, että paketteja jonossa . Tärkeä yksityiskohta: jos jonossa on paketteja eikä mikään käyttäjäprosessi nouda ja käsittele niitä, oletusarvoisesti ne estetään. Sovellusvirhe johtaa siis liikenteen estymiseen.
Ohjelmointi libnetfilter_queue-ohjelmaa vastaan: "hello world" C-kielellä
Jonoon liittymiseen käyttäjätilasta käytetään libnetfilter_queue- kirjastoa (joka puolestaan on riippuvainen libnfnetlinkistä). Debianin kaltaisissa jakeluissa asenna vain kehityspaketit:
apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc
Minimalistisen, aina paketteja hyväksyvän ohjelman runko koostuu muutamasta hyvin selkeästä vaiheesta: kirjaston avaaminen, olemassa olevien käsittelijöiden sidonnan purkaminen, AF_INET-protokollaan sitominen, jonon luominen takaisinkutsufunktiolla, kopiointitilan määrittäminen ja vastaanottosilmukan käynnistäminen . Takaisinkutsu suoritetaan jokaiselle jonossa olevalle paketille, jolloin tunniste puretaan ja tulos palautetaan.
Käytännössä työnkulku on jotakuinkin seuraavanlainen: `nfq_open` hakee kahvan, `nfq_unbind_pf` siivoaa sen, `nfq_bind_pf` liittää sen AF_INET:iin, `nfq_create_queue` rekisteröi takaisinkutsun jonoon 0, `nfq_set_mode` ilmaisee, halutaanko metatiedot vai koko paketin, silmukka `recv()`:lla deskriptorin yli ja `nfq_handle_packet` käsittelee jokaisen paketin . Poistuessa jono tuhotaan `nfq_destroy_queue`:lla ja kahva suljetaan `nfq_close`:lla.
Tämän tyyppinen "hello world" mahdollistaa NFQUEUE-muuttujaan liittyvän vaikutuksen selkeän mittaamisen. Jos käännämme esimerkin esimerkiksi näin:
gcc -o nftest koodi.c -lnfnetlink -lnetfilter_queue
Ja jos jonotamme iperfistä tulevaa liikennettä (esimerkiksi TCP-portti 5001 INPUT- ja OUTPUT-lomakkeissa), huomaamme, että pakettien pelkkä hyväksyminen ei juurikaan vaikuta suorituskykyyn gigabitin verkossa . On kuitenkin yksi tärkeä yksityiskohta: tietojen tulostaminen callback-funktiossa (printf, fflush jne.) heikentää merkittävästi läpivirtausta, kuten voidaan nähdä, kun vertaamme iperfiä näytön virheenkorjauksella ja ilman sitä.
Edistyneet NFQUEUE-asetukset: ohitus, tasapainotus ja vikasietoinen avaus
NFQUEUE sisältää useita mielenkiintoisia iptables-asetuksia, jotka muokkaavat jonojen oletuskäyttäytymistä ja jotka tulisi tuntea ennen tuotanto- tai tehokasta ympäristöön siirtymistä, koska ne vaikuttavat siihen, miten käyttäjäsovelluksen virheitä tai jonon täyttöä käsitellään.
Komennolla `--queue-bypass` voit varmistaa, että jos mikään prosessi ei kuuntele jonoa, paketteja ei pudoteta, vaan ne välitetään iptables-ketjun seuraavalle hypylle. Tästä voi olla hyötyä, jos haluat järjestelmän "avautuvan virheen", kun käyttäjäpalvelu ei ole käytettävissä, vaikkakin turvallisuuden näkökulmasta se on kaksiteräinen miekka.
`--queue-balance` -valinnan avulla voit jakaa paketteja useille jonoille (esimerkiksi 0:sta 3:een) ja sitten käyttää useita itsenäisiä prosesseja tai säikeitä jokaista jonosta . Netfilterin koodi varmistaa, että saman virran paketit päätyvät aina samaan jonoon, mikä yksinkertaistaa huomattavasti päätöksentekologiikan johdonmukaisuuden ylläpitämistä.
Käytössä on myös `--fail-open`- tila , joka hallitsee, mitä tapahtuu, kun jono täyttyy käyttäjäprosessin liian hitaan toiminnan vuoksi. Tämän tilan käyttöönotto saa ytimen hyväksymään paketteja suoraan niiden hylkäämisen sijaan, mikä estää massiiviset liikenteen häiriöt. Tämäkin voi olla tietoturvaongelma, koska jos haluamme tehdä päätöksiä tapauskohtaisesti, päätöspakettien menettäminen tarkoittaa tavoitteen saavuttamatta jättämistä.
Jonojen tilanteen valvomiseksi Netfilter paljastaa tietoja pseudo-fs-tiedostossa /proc/net/netfilter/nfnetlink_queue , jota voidaan helposti hakea skripteistä tai valvontatyökaluista.
Liiketoimintalogiikan integrointi: testaus Memcachedin ja MySQL:n avulla
Kun "hello world" -prosessi on hallinnassa, seuraava luonnollinen askel on rikastuttaa takaisinkutsua kutsuilla ulkoisiin järjestelmiin . Tyypillinen kokeilu sisältää paketin hyväksymisen tai hylkäämisen päättämisen sen perusteella, näkyykö lähteen IP-osoite missään taustajärjestelmässä, kuten MySQL-tietokannassa tai Memcached-välimuistissa.
Memcachedin tapauksessa daemon asennetaan (apt-get install memcached) ja avain, esimerkiksi authorized , ladataan meitä kiinnostavalla IP-osoitteella. Voimme tehdä tämän yksinkertaisella echo- ja netcat-komennoilla ja varmistaa sitten get-komennolla, että arvo on tallennettu oikein. Tämän jälkeen NFQUEUE-ohjelma vastaanottaa paketin ID:n lisäksi koko paketin NFQNL_COPY_PACKET- metodilla , purkaa IP-otsikon (struct iphdr) ja muuntaa lähdeosoitteen merkkijonoksi inet_ntop-metodilla.
Jotta vältetään ajan hukkaaminen yhteyksien avaamisessa kullakin paketilla, Memcached-yhteys alustetaan vain kerran päämetodissa (memcached_create, memcached_server_list_append, memcached_server_push), ja käsittelijä tallennetaan globaaleihin muuttujiin. Takaisinkutsussa memcached_get-funktiota kutsutaan halutulla avaimella, lähteen IP-osoitetta verrataan noudettuun arvoon, ja jos ne vastaavat toisiaan, palautetaan NF_ACCEPT; muuten palautetaan NF_DROP. Jos avainta ei ole tai on virhe, paketti hylätään konservatiivisen käytännön mukaisesti.
iperf-strategiaa käytettäessä tämä strategia vähentää läpäisykyvyn noin 140 Mbit/s:iin gigabitin verkossa , ja on havaittu, että jonossa alkaa tapahtua häviöitä (mikä näkyy esimerkiksi koodin symboleissa). Toisin sanoen pelkkä välimuistipalvelun kutsuminen pakettia kohden aiheuttaa jo merkittäviä kustannuksia, vaikka se on optimoituna edelleen mahdollinen keskisuurten liikennemäärien kanssa.
MySQL:n kanssa lähestymistapa on samanlainen, mutta monimutkaisempi: palvelin- ja asiakaskirjasto asennetaan, tietokanta (esimerkiksi nfqueue) luodaan yksinkertaisella taulukolla nimeltä authorized(ip varchar(50)), ja sallittu IP-osoite lisätään. Ohjelmassa `mysql_init` ja `mysql_real_connect` suoritetaan käynnistyksen yhteydessä, ja takaisinkutsun yhteydessä muodostetaan kysely, kuten `select * from authorized where ip like 'xxxx'`. Jos kysely suoritetaan onnistuneesti ja rivi löytyy, paketti hyväksytään; muuten se hylätään.
Kun MySQL-kyselyvälimuisti on käytössä, testitulokset ovat noin 188 Mbit/s , mikä laskee 103 Mbit/s: iin , kun kyselyvälimuisti on poistettu käytöstä. Nämä luvut, vaikka ne ovatkin kaukana gigabittiluvuista, osoittavat, että jopa vähiten elegantilla lähestymistavalla (yksisäikeinen, ilman optimointia) voidaan käsitellä kunnioitettavia liikennemääriä tietokantapohjaisilla tai välimuistiin perustuvilla päätöksillä.
Suorituskyky, monisäikeisyys ja suorittimen käyttö
iperf-, Memcached- ja MySQL-testit osoittavat selvästi, että suorituskykykattoa ei niinkään aseta itse NFQUEUE, vaan pikemminkin käyttäjätilaan lisäämämme logiikka ja sen toteutustapa. Suoritettava tiedosto, joka palauttaa vain NF_ACCEPT-arvon, saavuttaa lähes gigabitin ilman ongelmia; heti kun otamme käyttöön I/O- tai verkkokutsuja, läpimenoaika laskee ja NFQUEUE-koneen, Memcached-daemonin tai MySQL:n suorittimen kuormitus joutuu äärirajoilleen.
Arkkitehtuurin näkökulmasta tällä on kaksi seurausta. Yhtäältä se vahvistaa, että palomuuripäätösten delegointi käyttäjäsovelluksille merkittävien liikennemäärien osalta on täysin toteuttamiskelpoista , kunhan kunkin puhelun todelliset kustannukset otetaan huomioon. Toisaalta se osoittaa, että alustan maksimiominaisuuksien saavuttamiseksi on harkittava monisäikeisyyttä tai moniajoa . NFQUEUE mahdollistaa liikenteen jakamisen useille jonoille; voisimme käynnistää useita kopioita sovelluksestamme, joista jokainen kuuntelee eri jonoa, ja hyödyntää useita ytimiä ilman pthreadsien tai massiivisten haarukoiden vaivaa.
Toinen ilmeinen optimointi olisi rajoittaa NFQUEUE-protokollan läpi kulkevaa liikennettä . Testeissä koko iperf-virta jonotettiin, mutta tosielämän skenaariossa voisimme jonottaa vain UUSI-tilassa olevia paketteja, sallia PERUSTETTUJEN/SUHTEIDEN pakettien läpikulun ja varata kalliin logiikan kirjautumisille tai epäilyttäville kaavoille.
Viime kädessä prosessorin käyttö ja säikeiden suunnittelu ovat avainasemassa: jos käyttäjäprosessi jää vajaaksi, jono täyttyy ja joudumme turvautumaan esimerkiksi vikasietoisiin avauksiin tai säikeiden poistoihin, jolloin menetämme osan tämän lähestymistavan tavoittelemasta hienosäädöstä.
Dynaaminen reititys Netfilter-brändäyksellä
NFQUEUE ei rajoitu pelkkään "accept"- tai "throw"-komennon käyttämiseen. Sitä voidaan käyttää myös Netfilter (fwmark) -lippujen soveltamiseen paketteihin ja niiden yhdistämiseen ip-säännön ja iproute2:n kanssa erittäin joustavien, lähes kevyiden VRF-tyylisten poliittisten reititysjärjestelmien luomiseksi.
Laajasti ottaen menettelytapa olisi seuraava: määritetään useita reititystaulukoita tiedostossa /etc/iproute2/rt_tables , esimerkiksi hidas ja nopea; määritetään kullekin taulukolle eri oletusreitti (yksi kuidun kautta ja toinen rajoitetumman linkin kautta); käytetään ip-sääntöä määrittämään, että fwmark 1:n omaavat paketit menevät nopeaan taulukkoon, fwmark 2:n omaavat hitaaseen taulukkoon jne.; ja lopuksi käytetään NFQUEUE-käskyä pakettien merkitsemiseen asianmukaisesti ennen lopputuloksen palauttamista.
Voit asettaa tuloksen takaisinkutsusta käyttämällä `nfq_set_verdict2` -metodia . Se on samanlainen kuin `nfq_set_verdict`, mutta sen avulla voit asettaa tuloksen arvon, jonka `ip rule` sitten näkee. Yhdistämällä kaiken tämän voit rakentaa IP-reitittimen, joka päättää reitityspaikan mielivaltaisten kriteerien perusteella: absurdeista asioista, kuten parillisista/parittomista paketin kokoista, ulkoisiin syötteisiin, kuten liikenteen ennustusalgoritmeihin, sosiaalisen median tapahtumiin tai valvontajärjestelmien signaaleihin.
Tuloksena on järjestelmä, jossa ydin jatkaa pakettien välittämistä normaalilla nopeudella, mutta kunkin vuon tarkka reitti delegoidaan ulkoiselle ohjelmistolle , joka voi muuttaa mieltään reaaliajassa koskematta staattisiin sääntöihin.
NFQUEUE ja Suricata: Korkean tason IPS GNU/Linuxissa
Kaikki edellä mainittu voidaan ohjelmoida käsin C:llä, mutta tunkeutumisen havaitsemisen ja syvällisen pakettien tarkastuksen osalta järkevä vaihtoehto on yleensä luottaa kypsään IDS/IPS-moottoriin . Tässä kohtaa Suricata tulee mukaan kuvaan, sillä se syntyi juuri Snortin moniprosessisena vaihtoehtona, ja siinä on IPS-ominaisuudet alusta alkaen sekä vahva keskittyminen nykyään saatavilla olevien monien suorittimen ytimien hyödyntämiseen.
Suricata on kirjoitettu tyhjästä ja jaettu GPLv2-lisenssillä ; Open Information Security Foundation (OISF) ylläpitää sekä ohjelmointimoottoria että melko kattavaa sääntöjen ja dokumentaation ekosysteemiä. Toisin kuin Snort 2.x, joka peri yksisäikeisen ytimen ja päivitettiin siihen, Suricata suunniteltiin jakamaan työmäärä useiden säikeiden kesken: sieppaus, dekoodaus, tunnistus ja tulostus, käyttäen erilaisia kuormituksenjakostrategioita.
Toiminnallisella tasolla Suricata tarjoaa natiivin tuen IPv6:lle, kerroksen 7 tarkastukselle (erittäin edistynyt HTTP HTP-kirjaston kautta), porteista riippumattomalle protokollan tunnistukselle , vuon rekonstruoinnille ja erittäin tehokkaan istuntomuuttujien (vuobittien) järjestelmän useiden TCP-yhteyksien yli levinneen hyökkäyksen eri vaiheiden korreloimiseksi.
Lisävahvuutena on sen yhteensopivuus Snort-sääntöjen kanssa ja kyky käyttää sekä Sourcefire VRT- että Emerging Threats -tunnistejoukkoja (ilmainen ET Open ja kaupallinen ET Pro -versio). Lisäksi se vie tapahtumia erittäin hyödyllisissä muodoissa (fast.log, JSON eve.json-tiedostossa) integrointia varten SIEM-, ELK-, Splunk- ja muiden järjestelmien kanssa.
Suricata IPS:nä Linuxissa: kaappaustilat ja NFQUEUE
GNU/Linuxissa Suricata voi toimia eri tiloissa riippuen siitä, miten liikennettä siepataan: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … Jokaisella on omat etunsa ja vaatimuksensa. Puhtaalla IPS-tasolla kaksi tärkeintä ovat NFQUEUE ja AF_PACKET.
NFQ (NFQUEUE) -tilassa työnkulku on samanlainen kuin aiemmin kuvattu: joukko iptables-sääntöjä lähettää paketteja jonoon; käyttäjätilassa suoritettava Suricata lukee jonosta, tarkistaa sisällön sääntöjensä mukaisesti ja palauttaa ytimelle tuloksen: NF_ACCEPT, NF_DROP tai NF_REPEAT. Kolmatta moodia voidaan käyttää paketin palauttamiseen samaan iptables-taulukkoon lisämerkkien tai muutosten jälkeen.
Tämä tila on erittäin joustava ja helppo ottaa käyttöön olemassa olevissa infrastruktuureissa , koska se vaatii sääntöjen muokkaamista vain tietyissä kohdissa (esimerkiksi FORWARD, INPUT, OUTPUT) ja kaiken muun jättämistä ennalleen. Kustannuksena on pakettien välittämisen NFQUEUE-reittilinjan kautta ylös ja alas aiheuttama lisäkustannus, jolla on edellä mainittu vaikutus, jos määrä on erittäin suuri tai säännöt ovat resursseja vaativia.
AF_PACKET- tilassa Suricata toimii lähempänä verkkorajapintaa ja kopioi paketteja AF_PACKET-pistorasioiden kautta. Tämä on paljon nopeampi kopiointivapaa lähestymistapa , mutta se edellyttää, että järjestelmä toimii yhdyskäytävänä, jossa on kaksi rajapintaa, ja että liikenteen esto suoritetaan edelleenlähetystasolla verkkokorttien välillä: estettävää pakettia ei yksinkertaisesti välitetä tulorajapinnasta lähtörajapintaan.
Molemmissa tiloissa Suricataa voidaan yhdistää Netfilterin kanssa, mutta NFQUEUE sopii erityisen hyvin tilanteisiin, joissa haluamme käyttää uudelleen kaikkea iptables-logiikkaa (käytäntöjä, alueita, aiempia sääntöjä) ja lähettää Suricatalle vain liikenteen, jota haluamme tutkia perusteellisesti.
Suricatan perusasennus lähdekoodista
Niille, jotka mieluummin kääntävät Suricatan pakettien käyttämisen sijaan, Debian/Ubuntu-tyyppisissä jakeluissa prosessiin kuuluu ensin käännösriippuvuuksien (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev jne.) asentaminen, tar-tiedoston lataaminen viralliselta verkkosivustolta ja klassisen ./configure, make, make install -komennon suorittaminen.
Konfigurointivaiheen aikana skripti ilmoittaa, mitkä tukiominaisuudet on otettu käyttöön: AF_PACKET kyllä/ei, PF_RING, NFQUEUE kyllä/ei, NFLOG, IPFW, tuki libnss:lle, libjanssonille, Preludelle, PCRE JIT:lle, Lualle, GeoIP:lle jne. On tärkeää varmistaa, että NFQUEUE on käytössä, jos haluamme työskennellä kyseisessä tilassa , ja että meitä kiinnostava tallennuskirjasto on löydetty.
Binääritiedoston asentamisen jälkeen voit ajaa komennon `make install-conf` ottaaksesi käyttöön oletusasetukset tiedostossa `/etc/suricata` ja komennon `make install-rules` ladataksesi ja sijoittaaksesi joukon nousevia uhkia koskevia sääntöjä tiedostoon `/etc/suricata/rules`. Näitä joukkoja voidaan sitten päivittää työkaluilla, kuten `suricata-update`.
Red Hat/CentOS-järjestelmissä logiikka on samankaltainen: riippuvuuksille (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel jne.) käytetään yum- tai dnf-komentoa, ja käännetään sitten samoilla vaiheilla. Suorituskyvyn vuoksi on myös suositeltavaa poistaa LRO/GRO käytöstä kaappauskäyttöliittymässä ethtoolin avulla, koska nämä siirtofunktiot voivat vaikuttaa pakettien näkyvyyteen IDS-tasolla.
Suricata-konfiguraatio: YAML, muuttujat ja säikeitys
Suricatan pääasetukset sijaitsevat tiedostossa /etc/suricata/suricata.yaml . Se on melko luettava ja paljon kommentoitu YAML-tiedosto, jossa määritellään kaikki lokipoluista ja sääntöjoukoista kohdekäyttöjärjestelmän käytäntöihin ja säikeistysparametreihin.
Yksi peruskentistä on `default-log-dir` , joka määrittää lokitiedostojen tallennuspaikan (oletusarvoisesti `/var/log/suricata`). `vars`-osiossa on muuttujia, kuten `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` ja `SSH_PORTS`, jotka toimivat lyhenteinä säännöissä. `HOME_NET` konfiguroidaan yleensä suojattavan paikallisen verkkoalueen mukaan, kun taas `EXTERNAL_NET` määritellään tyypillisesti muodossa `!HOME_NET`.
Toinen tärkeä osa on host-os-policy , joka kertoo Suricatalle, minkä käyttöjärjestelmän on tarkoitus käyttää tiettyjä IP-alueita. Tämän avulla se voi säätää TCP:n uudelleenkokoamista tai tiettyjen verkkopinon toimintatapojen tulkintaa , mikä vaikeuttaa protokollien kiertämistä pinojen välisten erojen perusteella (Windows vs. Linux jne.). Tietyt alueet voidaan määrittää luokille, kuten Windows, Linux, BSD, Vista, Windows 2003 jne.
Säikeiden osalta säikeytysosio antaa sinun hienosäätää suorittimen affiniteettia ja tunnistussäikeiden määrää. Oletusarvoisesti `set-cpu-affinity` on yleensä pois käytöstä, jolloin järjestelmän ajoitusohjelma voi jakaa säikeet ytimien kesken. `detect-thread-ratio` -parametri ilmaisee, kuinka monta tunnistussäiettä luodaan käytettävissä olevaa ydintä kohden; jos `detect-thread-ratio: 1.5` on 8-ytimisessä koneessa, Suricata luo 12 tunnistussäiettä sekä sieppaus- ja hallintasäikeet.
Koko tämä malli heijastuu sitten tulosteeseen, kun daemon käynnistyy: näkyvissä on sieppaussäie (esimerkiksi pcap) ja useita ilmaisinsäikeitä, sekä vuonhallintaohjelmat ja tilastonhallintaohjelmat. Tämä moniajoarkkitehtuuri mahdollistaa Suricatan skaalautumisen paljon paremmin kuin yksisäikeiset moottorit 10/40 Gbit/s linkkien kanssa.
Säännöt ja allekirjoituspäivitykset Suricatassa
Suricata käyttää sääntöjoukkoja hyökkäysmallien, poikkeavan käyttäytymisen ja protokollan väärinkäytön havaitsemiseen. Snort-muotoisten sääntöjen hyväksymisen lisäksi yleisin ekosysteemi on Emerging Threats: ET Open (ilmainen) ja ET Pro (kaupallinen), joiden säännöt on suunnattu nykyisiin uhkiin.
Monissa nykyaikaisissa jakeluissa on `suricata-update` -työkalu , joka yksinkertaistaa sääntöjen hallintaa: se päivittää lähteet, ottaa käyttöön tai poistaa käytöstä tiettyjä palveluntarjoajia ja lataa uusimmat versiot allekirjoitusjoukoista. Tyypillinen työnkulku olisi asentaa `suricata-update` (esimerkiksi pip-komennon kautta), suorittaa ensimmäinen `suricata-update` ET Openin lataamiseksi, listata lähteet `suricata-update list-sources`-komennolla, ottaa käyttöön lisälähteitä, kuten `ptresearch/attackdetection`, `oisf/trafficid` tai `sslbl/ssl-fp-blacklist`, ja suorittaa `suricata-update` uudelleen sääntötiedoston luomiseksi uudelleen.
suricata.yaml-tiedostoa säädetään osoittamaan oikeaan sääntöpolkuun, ja siitä lähtien Suricata alkaa luoda hälytystapahtumia, jotka kirjataan fast.log-tiedostoon (nopea, luettava teksti) ja eve.json-tiedostoon (rakenteinen JSON, jossa on erittäin täydelliset tiedot) . Jälkimmäinen muoto on erityisen hyödyllinen kojelaudoille, korrelaatiojärjestelmille tai mukautettujen komentosarjojen syöttämiseen.
Allekirjoitusten lisäksi Suricata sisältää dekoodereita ja jäsentimiä useille protokollille , minkä ansiosta se on vähemmän riippuvainen porteista: se pystyy tunnistamaan HTTP-liikenteen, vaikka se kulkisi epästandardien porttien kautta, havaitsemaan SSH:n, TLS:n, DNS:n jne. eri porttien ja kapselointitasojen kautta (mukaan lukien sekalaiset IPv4/IPv6-tunnelit).
Käytännön käyttö: verkkohyökkäysten havaitsemisesta automaattiseen estämiseen
Yksi halutuimmista käyttötapauksista hosting-ympäristöissä tai datakeskuksissa on havaita reaaliajassa yritykset hyödyntää verkkosovellusten (esim. WordPressin ja sen laajennusten) haavoittuvuuksia ja reagoida niihin automaattisesti, yleensä estämällä tai mustalle listalle asettamalla lähde-IP-osoitteen palomuurissa.
Päivitettyjen sääntöjen avulla Suricata pystyy tunnistamaan tiettyjä hyökkäyskuvioita URL-osoitteita, parametreja, HTTP-hyötykuormia ja jopa pyyntösekvenssejä vastaan, jotka vastaavat tunnettuja hyökkäyksiä. IDS voi toimia passiivisessa tilassa ja vastaanottaa liikennettä peilauksen kautta kytkinportista (SPAN), mutta toimiakseen IPS:nä ja estääkseen hyökkäykset se on integroitava edelleenlähetystasoon.
Yleisiä lähestymistapoja on kaksi: IDS:n määrittäminen online-sillaksi, jolloin liikenne kulkee fyysisesti koneen läpi (käyttäen iptables-, AF_PACKET- tai PF-ohjelmaa alustasta riippuen), tai topologian jättäminen sellaisenaan, mutta peilauksen yhdistäminen keskitetyn palomuurin toimintoihin API:n, komentosarjojen tai NFQUEUE-rajapinnan kautta . Ensimmäinen lähestymistapa minimoi havaitsemisen ja estämisen välisen viiveen, mutta lisää samalla uuden elementin verkon "keskelle". Toinen lähestymistapa tarjoaa suurempaa joustavuutta ja vikasietoisuutta, mutta tuo mukanaan enemmän monimutkaisuutta orkestrointiin.
On täysin mahdollista, että tunkeutumisen havaintojärjestelmä (IDS) havaitsee yrityksen hyödyntää haavoittuvaa WordPress-lisäosaa ja sitten, joko suoraan tai siihen liittyvän komponentin kautta, lisää hyökkääjän IP-osoitteen iptables-mustalle listalle. Tämä voidaan tehdä Suricatan JSON-tulosteen ja iptables/nftables-kutsuja kutsuvien komentosarjojen avulla tai delegoimalla osa logiikasta NFQUEUE-komennon käyttöön, jossa itse moottori tai siihen liittyvä prosessi tekee päätöksen lennossa odottamatta ulkoisen listan päivitystä.
Näin voit keskittyä uhkiin, joilla on todella merkitystä (hyökkäykset, eskalointiyritykset, erittäin aggressiiviset skannaukset) ja jättää huomiotta tai yksinkertaisesti kirjata taustamelun, kuten perusporttiskannaukset, jotka monissa yhteyksissä eivät itsessään ole huolestuttavia.
Suricata Pfsensessä: avoimen lähdekoodin palomuuri integroidulla IDS/IPS:llä
Kaikki eivät voi tai halua ostaa Palo Alton kaltaista omaa huippuluokan palomuuria. Monissa ympäristöissä on houkuttelevampaa perustaa avoimen lähdekoodin ratkaisu pfSensen ja Suricatan avulla , joka kattaa sekä edistyneet palomuuritarpeet (moni-WAN, VLAN, VPN, NAT jne.) että IDS/IPS:n.
FreeBSD:hen ja Packet Filteriin perustuva Pfsense toimii erityisen hyvin virtualisoiduissa ympäristöissä (Proxmox, KVM jne.), sillä poikkeuksella, että KVM-koneissa suositellaan E1000-korttien käyttöä Virtio-korttien sijaan, jos halutaan välttää suorituskykyongelmia ja kaatumisia kuormituksen aikana, ellei sitten noudateta Netgaten suosituksia (poista laitteiston tarkistussumman purkaminen käytöstä kohdassa Järjestelmä > Lisäasetukset > Verkkoyhteydet ja käynnistä tietokone uudelleen tietäen, että tämä ei välttämättä riitä erittäin suurilla kuormilla).
Suricataa Pfsense-alustalla käyttävän laboratorion vähimmäislaitteistovaatimukset voivat olla vaatimattomat (1 suoritin 500 MHz, 1 Gt RAM-muistia, 4 Gt levyä), mutta vakavaan käyttöön suositellaan vähintään kahta suoritinta, 4 Gt RAM-muistia ja 16 Gt tallennustilaa. On myös tärkeää, että verkkoliitäntöjä on useita (yksi WAN-verkkoa varten, toinen lähiverkkoa varten ja useampia, jos haluat useita WAN-verkkoja tai monimutkaisia VLAN-verkkoja).
pfSensen asentaminen on erittäin nopeaa: käynnistät ISO-tiedostolta, hyväksyt lisenssin, valitset asennuksen, valitset kielen ja näppäimistöasettelun, jätät osioinnin automaattiseksi (Auto UFS, jos aiot käyttää koko levyä) ja muutamassa minuutissa järjestelmä on valmis ensimmäiseen käynnistykseen. Konsolissa on valikko liitäntöjen määrittämiseen, uudelleenkäynnistykseen, komentotulkin käynnistämiseen jne.
Laboratoriossa, esimerkiksi VirtualBoxissa, on yleistä poistaa Pfsense-palomuuri tilapäisesti käytöstä konsolista komennolla pfctl -d, jotta web-käyttöliittymään pääsee WAN-verkon kautta (käyttäjätunnus admin, salasana pfsense) ja voi suorittaa alkuasettelutoiminnon loppuun: yleiset tiedot, NTP-palvelimet, WAN-kokoonpano (DHCP riittää yleensä laboratoriossa), lähiverkko, järjestelmänvalvojan salasanan vaihto ja kokoonpanon käyttöönotto.
Kun pääsy on vakiintunut, voit luoda WAN-palomuuriin säännön, joka sallii HTTPS-yhteyden mistä tahansa lähteestä pfsense IP-osoitteeseen. Voit lisätä kuvaavia erottimia sääntöjen visuaaliseen järjestämiseen (esimerkiksi "Palomuurin käyttöoikeus"). On myös suositeltavaa poistaa käytöstä yksityisten verkkojen esto WAN-verkossa , jos olet testiympäristössä, jossa on RFC1918-osoitteita, jotta vältät jatkuvan `pfctl -d`-komennon käytön.
Suricatan asennus pfSenseen ja yleiskatsaus
Kun pfSense-peruspaketti on käytössä, Suricatan asentaminen on helppoa: mene kohtaan Järjestelmä > Paketinhallinta > Käytettävissä olevat paketit , etsi Suricata ja asenna paketti. Prosessiin ladataan useita tiedostoja ja se voi kestää jonkin aikaa laitteistostasi riippuen, mutta se tapahtuu täysin web-käyttöliittymän kautta.
Asennuksen jälkeen Palvelut-välilehdelle ilmestyy Suricata-merkintä, jossa voit määrittää instansseja rajapinnan mukaan (WAN, LAN, VLAN jne.), valita käytettävät sääntöjoukot, aktivoida IDS- tai IPS-tilan ja säätää suorituskyky- ja lokiparametreja. Vaihtoehtoja on laaja (riittää kokonaisiin artikkeleihin pelkästään konfigurointia varten), mutta etuna on, että monet Linuxissa manuaalista YAML-muokkausta vaativat tehtävät käsitellään täällä lomakkeiden ja valintaruutujen avulla.
Tärkeä huomautus: Vaikka pfSense-hallinnan avaaminen suoraan internetille laboratorioympäristössä saattaa olla houkuttelevaa, tuotannossa on erittäin tärkeää rajoittaa pääsy staattisiin IP-osoitteisiin, käyttää VPN-yhteyksiä etähallintaan ja välttää verkkokonsolin jättämistä alttiiksi hinnalla millä hyvänsä . pfSense on erittäin joustava, mutta sitä on myös käsiteltävä kriittisenä elementtinä, joka se on.
Kun Suricata on käytössä pfSensessä, saat ympäristön, jossa liikenne kulkee pfSensen läpi palomuuria ja NAT:ia varten, ja Suricata tarkastaa sen sääntöjensä mukaisesti ja voi estää sen IPS-tilassa . Tämä yhdistelmä, jota hallitaan yhdestä verkkokäyttöliittymästä, yksinkertaistaa huomattavasti DPI-suojauksen käyttöönottoa pienissä ja keskisuurissa verkoissa.
Monissa käyttöönotoissa tätä täydentää Pfsense/Suricata-yhteys SIEM-järjestelmään tai keskitettyyn lokialustaan, jossa hyödynnetään jäsenneltyjä tulostusmuotoja tapahtumien korreloimiseksi ja laajempien kampanjoiden havaitsemiseksi.
Tapahtumien valvonta ja esimerkkilokit Suricatassa
Kun Suricata on käynnissä, tapahtumat kirjataan default-log-dir-tiedoston määrittämään polkuun, joka on yleensä /var/log/suricata . fast.log-tiedosto on tiivis tekstimuotoinen ja sisältää aikaleimat, sääntötunnukset, luokitukset ja prioriteetin, mikä soveltuu nopeaan tarkasteluun päätelaitteesta (tail -f).
Esimerkiksi kohdatessamme liikennettä, jossa on virheelliset TCP-tarkistussummat, saatamme nähdä seuraavanlaisia rivejä: aikaleimat päivämäärällä ja kellonajalla, joita seuraa säännön tunniste (esim. 1:2200074:1), viesti "SURICATA TCPv4 virheellinen tarkistussumma", luokittelu, prioriteetti ja lähde-kohde-IP/portti-pari. Tällaiset hälytykset mahdollistavat pakettien eheysongelmien tai kiertoyritysten nopean tunnistamisen.
Eve.json-tiedosto sisältää samat tapahtumat JSON-muodossa, ja siinä on kenttiä, kuten timestamp, event_type, src_ip, dest_ip, src_port, dest_port ja proto, sekä hälytysalitiedosto, jossa on tiedot action, gid, signature_id, rev, signature, category ja severity. Tämä muoto on helposti luettavissa Logstashilla, Fluentdillä, Filebeatilla tai millä tahansa muulla lokiagenssilla , mikä mahdollistaa paljon rikkaamman analytiikan kuin pelkkä tekstin käyttö.
Kun Suricataa käytetään moniydinpalvelimella (esim. 8 ydintä), säikeiden pakkaus näkyy helposti työkaluissa, kuten htop, säikeiden tilassa, jolloin näkyviin tulee yksi tai useampi sieppaussäike (pcap, AF_PACKET tai NFQ) ja suuri määrä tunnistussäikeitä jakautuneena ytimien kesken. Tunnistussäikeiden suhteen ja suorittimen affiniteetin säätäminen voi vaikuttaa merkittävästi läpimenoon ja viiveeseen, kun liikennemäärä lähestyy alustan rajoja.
Ennen käyttöönottoa tuotantoympäristössä on suositeltavaa käyttää aikaa aktivoitavien sääntöjoukkojen hienosäätöön, jotta vältetään väärien positiivisten tulosten tulva, joka voi estää laillista liikennettä tai sotkea lokeja. Suricata-update-työkalun avulla voit poistaa käytöstä kokonaisia luokkia tai yksittäisiä sääntöjä löytääksesi kohtuullisen tasapainon herkkyyden ja käytettävyyden välillä.
Erikoissovellukset: VoIP, äänianalytiikka ja luova NFQUEUE
Klassisten käyttötapojen (verkkopalveluiden suojaus, haittaohjelmien tunnistus, DDoS-analyysi) lisäksi Netfilter+NFQUEUE-kaksikko mahdollistaa varsin luovia ratkaisuja esimerkiksi VoIP-puheluissa. Esimerkiksi on mahdollista asentaa SPIT-suodatin (roskapostin esto IP-puhelinliikenteen kautta) tai järjestelmä RTP-striimien kirosanojen sensurointiin .
Ajatuksena olisi: tunnistaa RTP-liikenne porttien tai protokollan tunnistuksen avulla ja lähettää se NFQUEUE:lle; käyttäjäsovelluksesta käsin rekonstruoida RTP-virta käyttämällä librtp:n kaltaista kirjastoa , poimia ääni WAV-muodossa ja välittää se avainsanojen tunnistusmoottorille (wordspotting), kuten kolmannen osapuolen tarjoamalle synteesi- tai tunnistuskirjastolle.
Havaittujen sanojen perusteella NFQUEUE-prosessi voi päättää sallia, estää tai jopa muuttaa toistoa lisäämällä piippauksen virtaan, vaikka jälkimmäinen vaatiikin erittäin hienosäädettyä RTCP:n, pakettisekvenssien ja ajoitusten hallintaa – lähes välikäsi-lähestymistapaa. Se ei ole triviaalia, mutta teoriassa se on täysin saavutettavissa hyödyntämällä samaa jono- ja päätösjärjestelmää.
On totta, että osa tästä voitaisiin tehdä yksinkertaisella nuuskijalla, joka syöttää dataa ulkoiselle prosessorille ja sitten toimii SIP-signaloinnin perusteella tai SBC:n (Asterisk, Kamailio jne.) kautta. NFQUEUE-kertoimen ero on siinä, että RTP-virtaan kohdistuva toiminta voi olla välitöntä ja suoraa ilman, että useita komponentteja tarvitsee koordinoida tai odottaa signalointikerroksen suorittavan puhelun loppuun.
Nämä skenaariot havainnollistavat selvästi GNU/Linuxin + Netfilterin + Suricatan + kolmannen osapuolen kirjastojen yhdistelmän potentiaalia: kyse ei ole pelkästään porttien ja IP-osoitteiden estämisestä, vaan monimutkaisten liikennepäätösten tekemisestä reaaliajassa käyttämällä 100 % vapaata ohjelmistoekosysteemiä.
Kun tarkastellaan koko matkaa pienestä C-ohjelmasta, joka aina hyväksyy paketteja, aina NFQUEUE:n, Pfsensen, tietokantojen ja välimuistien kanssa integroituun moniajousiseen Suricata-käyttöönottoon, voidaan arvostaa tämän teknologiapinon tarjoamaa joustavuutta kaiken rakentamiseen yksinkertaisista dynaamisista palomuureista konesalimittakaavan IDS/IPS-arkkitehtuureihin, joissa on todelliset syvätarkastusominaisuudet ja automaattinen reagointi yhä monimutkaisempiin hyökkäyksiin.