Komplett guide för att implementera Netfilter och Suricata på Linux

Informatec Digital » Resurser » Komplett guide till implementering av Netfilter och Suricata på Linux

Om du arbetar med nätverk på GNU/Linux ( bästa Linuxdistributionerna för säkerhet och integritet ) och är intresserad av att gå bortom den typiska statiska brandväggen, är du förmodligen nyfiken på hur man kombinerar Netfilter, NFQUEUE och Suricata för att bygga ett verkligt flexibelt IDS/IPS utan att spendera en förmögenhet på proprietär hårdvara. Det är just det område vi ska utforska i den här artikeln, genom att blanda lågnivåelement (kärna, köer, C) med högnivåverktyg (Suricata, regler, MySQL, Memcached, pfSense).

Den underliggande idén är mycket kraftfull: utnyttja det faktum att kärnan (se hur man optimerar Linuxkärnan ) kan köa paket till användarutrymme och låta ett anpassat program bestämma vad som ska göras med dem. Detta kan användas för trafikfiltrering (avancerad brandvägg, IPS), dynamisk routing eller integrering av affärslogik (databaser, cacher, attackdetektering för webbapplikationer, VoIP, etc.). Och om vi lägger till Suricata som en IDS/IPS-motor för flera processer, har vi en mycket robust kombination för miljöer som sträcker sig från laboratorier till datacenter med hög trafik.

NFQUEUE och Netfilter: utöka brandväggen till användarutrymmet

I ett typiskt GNU/Linux-system används Netfilter/iptables (eller nftables) regler vanligtvis som statiska policyer som helt och hållet finns i kärnutrymmet . Frontends och apparater (inklusive många lösningar baserade på Netfilter eller BSD:s Packet Filter) lagrar konfigurationen i text-, XML- eller SQLite-filer, och när något ändras regenererar och laddar de om reglerna. Detta är flexibelt, men logiken förblir en slags ögonblicksbild av brandväggen med mindre dynamiska justeringar (gränser för anslutningar per sekund, conntrack, landsmatchning, lager 7 om tillgängligt, etc.).

Det NFQUEUE föreslår är banbrytande: istället för att kärnan alltid ska fatta det slutgiltiga beslutet kan vi delegera det beslutet till en användarprocess . Kärnan köar paketet i en numrerad kö, och en applikation som använder libnetfilter_queue-biblioteket hämtar det, analyserar det och returnerar ett omdöme: acceptera, ignorera eller till och med markera det för policyrouting. Det är som att ha en programmerbar "domare" skriven i C, Python eller Perl ovanpå brandväggen.

Det fina med detta är att vårt program bokstavligen kan göra vad vi vill: fråga /dev/urandom, en databas, en webbtjänst, en distribuerad cache eller en sofistikerad algoritm innan den svarar på kärnan. Arkitektoniskt sett upphör brandväggen att vara en enkel uppsättning statiska regler och blir en pipeline där Netfilter, köer och användarapplikationer passar ihop som pusselbitar.

NFQUEUE består av två delar: NFQUEUE-målet i iptables , som skickar paket till en specifik kö, och användarbiblioteket libnetfilter_queue , som låter dig läsa dessa paket och utfärda en dom. Det är inte en enkel sniffer som tcpdump: här har vi möjlighet att direkt bestämma vilken väg paketet tar.

Grundläggande iptables-konfiguration med NFQUEUE

Ur ett iptables-perspektiv är det ganska enkelt att använda NFQUEUE: du lägger till en regel i den kedja du är intresserad av för att skicka paket som uppfyller vissa kriterier (käll-/destinations-IP, portar, tillstånd, extra moduler som GeoIP eller layer7 om tillgängligt, etc.) till kön.

Om vi ​​till exempel vill skicka alla pings som anländer till själva värden till NFQUEUE:

iptables -I INPUT -p icmp -j NFQUEUE

Detta skickar inkommande ICMP-paket till kö 0 (om inget annat anges). Vi skulle kunna ange en annan kö med något i stil med `--kö-num 3` . När vi listar reglerna med räknare (`iptables -L -n -v -x`) ser vi att räknarna ökar, vilket indikerar att paket placeras i kö . En viktig detalj: om det finns paket i kön och ingen användarprocess hämtar och bearbetar dem, är standardbeteendet att neka dem, så ett programfel resulterar avsiktligt i att trafiken blockeras.

Programmering mot libnetfilter_queue: "hej världen" i C

För att ansluta till kön från användarutrymmet används biblioteket libnetfilter_queue (som i sin tur är beroende av libnfnetlink). På distributioner som Debian, installera helt enkelt utvecklingspaketen:

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

Skelettet för ett minimalt program som alltid accepterar paket består av några få tydliga steg: öppna biblioteket, avbind alla befintliga hanterare, bind till AF_INET-protokollet, skapa kön med en återanropsfunktion, definiera kopieringsläget och starta en mottagningsslinga . Återanropet körs för varje köat paket, vilket extraherar ID:t och returnerar resultatet.

I praktiken ser flödet ut ungefär så här: `nfq_open` för att hämta handle-filen, `nfq_unbind_pf` för att rensa upp den, `nfq_bind_pf` för att associera med AF_INET, `nfq_create_queue` för att registrera återanropet i kö 0, `nfq_set_mode` för att indikera om vi vill ha metadata eller hela paketet, en loop med `recv()` över deskriptorn och `nfq_handle_packet` för att bearbeta varje paket . Vid utgången förstörs kön med `nfq_destroy_queue` och handle-filen stängs med `nfq_close`.

Den här typen av "hej världen" möjliggör en tydlig mätning av effekten av NFQUEUE. Om vi ​​kompilerar exemplet med något i stil med:

gcc -o nftest code.c -lnfnetlink -lnetfilter_queue

Och om vi köar trafiken från en iperf (till exempel TCP-port 5001 i INPUT och OUTPUT), kommer vi att se att kod som helt enkelt accepterar paket knappt påverkar prestandan i ett gigabitnätverk . Det finns dock en viktig detalj: utskrift av information i callback-funktionen (printf, fflush, etc.) minskar dataflödet avsevärt, vilket kan ses när man jämför iperf med och utan skärmfelsökning.

Avancerade NFQUEUE-alternativ: bypass, balansering och felöppning

NFQUEUE innehåller flera intressanta iptables-alternativ som modifierar standardbeteendet för köer och som bör kännas till innan man går in i en produktions- eller högpresterande miljö, eftersom de påverkar hur fel i användarapplikationer eller köfyllning hanteras.

Kommandot `--queue-bypass` låter dig säkerställa att om ingen process lyssnar på kön, så tappas inte paketen utan vidarebefordras istället till nästa hopp i iptables-kedjan. Detta kan vara användbart om du vill att systemet ska "fail open" när användartjänsten inte är tillgänglig, även om det ur ett säkerhetsperspektiv är ett tveeggat svärd.

Alternativet `--queue-balance` låter dig distribuera paket över ett intervall av köer (till exempel från 0 till 3) och sedan ha flera oberoende processer eller trådar som förbrukar från varje kö . Netfilters kod säkerställer att paket från samma flöde alltid hamnar i samma kö, vilket avsevärt förenklar att upprätthålla konsekvens i beslutslogiken.

Det finns också läget `--fail-open` , som styr vad som händer när kön fylls på grund av att användarprocessen körs för långsamt. Att aktivera det gör att kärnan accepterar paket direkt istället för att släppa dem, vilket förhindrar massiva trafikstörningar. Återigen kan detta vara ett säkerhetsproblem, eftersom om vi vill fatta beslut från fall till fall innebär förlust av beslutspaket att vi inte uppfyller det målet.

För att övervaka vad som händer med köerna exponerar Netfilter information i pseudo-fs /proc/net/netfilter/nfnetlink_queue , vilken enkelt kan efterfrågas från skript eller övervakningsverktyg.

Integrering av affärslogik: testning med Memcached och MySQL

När "hej världen"-processen är under kontroll är nästa naturliga steg att berika återanropet med anrop till externa system . Ett typiskt experiment innebär att man avgör om man ska acceptera eller avvisa ett paket baserat på om käll-IP-adressen visas i någon backend, till exempel en MySQL-databas eller en Memcached-cache.

När det gäller Memcached installeras daemonen (apt-get install memcached) och en nyckel, till exempel authorized , laddas med den IP-adress vi är intresserade av. Vi kan göra detta med ett enkelt echo och netcat, och sedan verifiera med ett get-kommando att värdet är korrekt lagrat. Därifrån tar NFQUEUE-programmet, förutom att hämta paket-ID:t, emot hela paketet med hjälp av NFQNL_COPY_PACKET , extraherar IP-headern (struct iphdr) och konverterar källadressen till en sträng med inet_ntop.

För att undvika att slösa tid på att öppna anslutningar med varje paket initieras Memcached-anslutningen endast en gång i main-metoden (memcached_create, memcached_server_list_append, memcached_server_push), och hanteraren lagras i globala variabler. I återanropet anropas memcached_get med önskad nyckel, käll-IP-adressen jämförs med det hämtade värdet, och om de matchar returneras NF_ACCEPT; annars returneras NF_DROP. Om nyckeln inte finns eller om det finns ett fel, tas paketet bort som en konservativ policy.

Med iperf minskar denna strategi dataflödet till cirka 140 Mbit/s på ett gigabitnätverk , och det observeras att kön börjar uppleva förluster (indikeras till exempel av symboler i själva koden). Med andra ord, att bara anropa en cachetjänst per paket medför redan en betydande kostnad, även om det fortfarande är genomförbart för medelstora trafikvolymer om det optimeras.

Med MySQL är tillvägagångssättet liknande men mer komplext: server- och klientbiblioteket installeras, en databas (till exempel nfqueue) skapas med en enkel tabell som heter authorized(ip varchar(50)), och den tillåtna IP-adressen infogas. I programmet körs `mysql_init` och `mysql_real_connect` vid start, och i återanropet konstrueras en fråga som `select * from authorized där ip som 'xxxx'`. Om frågan körs korrekt och en rad hittas accepteras paketet; annars kasseras det.

Med MySQL-frågecache aktiverad ger tester cirka 188 Mbit/s , vilket sjunker till 103 Mbit/s när frågecache är inaktiverad. Dessa siffror, även om de är långt ifrån gigabit, visar att även med den minst eleganta metoden (enkeltrådad, utan optimering) , kan respektabla trafikvolymer hanteras med hjälp av databasdrivna eller cachebaserade beslut.

Prestanda, multitrådning och CPU-användning

Tester med iperf, Memcached och MySQL visar tydligt att prestandataket inte bestäms så mycket av NFQUEUE självt utan snarare av logiken vi lägger till i användarutrymmet och hur vi implementerar det. En körbar fil som bara returnerar NF_ACCEPT uppnår nästan en gigabit utan att behöva svettas; så fort vi introducerar I/O- eller nätverksanrop sjunker dataflödet och processorn i NFQUEUE-maskinen, Memcached-daemonen eller MySQL pressas till sina gränser.

Ur ett arkitektoniskt perspektiv har detta två implikationer. Å ena sidan bekräftar det att det är fullt genomförbart att delegera brandväggsbeslut till användarapplikationer för betydande trafikvolymer , förutsatt att de faktiska kostnaderna för varje anrop beaktas. Å andra sidan visar det att för att närma sig plattformens maximala kapacitet måste multitrådning eller multiprocessering övervägas . NFQUEUE tillåter trafik att distribueras över flera köer; vi skulle kunna starta flera kopior av vår app, där var och en lyssnar på en annan kö, och utnyttja flera kärnor utan besväret med p-trådar eller massiva forks.

En annan uppenbar optimering skulle vara att begränsa vilken trafik som passerar genom NFQUEUE . I testerna köades hela iperf-flödet, men i ett verkligt scenario kunde vi bara köa paket med ett NYTT tillstånd, tillåta ESTABLISHED/RELATED-paket att passera och reservera den dyra logiken för inloggningar eller misstänkta mönster.

I slutändan är CPU-användning och tråddesign avgörande: om användarprocessen inte når upp till förväntningarna fylls kön upp och vi måste tillgripa saker som att öppna felmeddelanden eller acceptera dropps, vilket förlorar en del av den fina kontroll som denna metod syftar till.

Dynamisk routing med Netfilter-varumärkesbyggande

NFQUEUE är inte begränsat till att bara säga "acceptera" eller "kasta". Det kan också användas för att tillämpa Netfilter (fwmark)-flaggor på paket och kombinera dem med ip-regeln och iproute2 för att skapa mycket flexibla, nästan lätta politiska routingscheman i VRF-stil.

Proceduren, i stort sett, skulle vara: definiera flera routingtabeller i /etc/iproute2/rt_tables , till exempel långsam och snabb; tilldela varje tabell en annan standardrutt (en via fiber och en annan via en mer begränsad länk); använd ip-regeln för att ange att paket med fwmark 1 går till snabbtabellen, de med fwmark 2 till långsam, etc.; och slutligen använd NFQUEUE för att markera paketen på lämpligt sätt innan resultatet returneras.

För att ställa in ett domslut från återanropet används `nfq_set_verdict2` , vilket är likt `nfq_set_verdict` men låter dig ställa in ett domslutvärde som `ip rule` sedan ser. Genom att kombinera allt detta kan du bygga en IP-router som bestämmer vart den ska dirigeras baserat på godtyckliga kriterier: från absurda saker som jämn/udda paketstorlek till externa indata som trafikprediktionalgoritmer, händelser i sociala medier eller signaler från övervakningssystem.

Resultatet är ett system där kärnan fortsätter att vidarebefordra paket i vanlig takt, men den exakta vägen som varje flöde tar delegeras till extern programvara som kan ändra sig i realtid utan att röra statiska regler.

NFQUEUE och Suricata: Högnivå-IPS i GNU/Linux

Allt ovanstående kan programmeras för hand i C, men när det gäller intrångsdetektering och djup paketinspektion är det förnuftiga alternativet vanligtvis att förlita sig på en mogen IDS/IPS-motor . Det är där Suricata kommer in i bilden, som föddes just som ett multiprocessalternativ till Snort, med IPS-funktioner från början och ett starkt fokus på att utnyttja de många CPU-kärnor som finns tillgängliga idag.

Suricata är skrivet från grunden och distribueras under GPLv2-licensen ; Open Information Security Foundation (OISF) underhåller både motorn och ett ganska omfattande ekosystem av regler och dokumentation. Till skillnad från Snort 2.x, som ärvde en enkeltrådad kärna och patchades till den, designades Suricata för att dela upp arbetsbelastningen över flera trådar: infångning, avkodning, detektering och utdata, med olika lastdelningsstrategier.

På funktionell nivå tillhandahåller Suricata inbyggt stöd för IPv6, lager 7-inspektion (mycket avancerad HTTP via HTP-bibliotek), protokolligenkänning oberoende av portar , flödesrekonstruktion och ett mycket kraftfullt system av sessionsvariabler (flödesbitar) för att korrelera olika steg i en attack spridd över flera TCP-anslutningar.

En ytterligare styrka är dess kompatibilitet med Snort-regler och dess förmåga att använda både Sourcefire VRT och Emerging Threats signaturuppsättningar (den kostnadsfria ET Open- och den kommersiella ET Pro-versionen). Dessutom exporterar den händelser i mycket användbara format (fast.log, JSON i eve.json) för integration med SIEM, ELK, Splunk och andra system.

Suricata som en IPS i Linux: inspelningslägen och NFQUEUE

På GNU/Linux kan Suricata fungera i olika lägen beroende på hur trafiken avlyssnas: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … Var och en har sina fördelar och krav. På ren IPS-nivå är de två viktigaste NFQUEUE och AF_PACKET.

I NFQ-läge (NFQUEUE) liknar flödet det som beskrivits tidigare: en uppsättning iptables-regler skickar paket till en kö; Suricata, som körs i användarutrymmet, läser från den kön, inspekterar innehållet enligt dess regler och returnerar ett resultat till kärnan: NF_ACCEPT, NF_DROP eller NF_REPEAT. Den tredje kan användas för att återinjicera paketet i samma iptables-tabell efter att ha tillämpat ytterligare markeringar eller modifieringar.

Detta läge är mycket flexibelt och enkelt att implementera i befintliga infrastrukturer , eftersom det bara kräver att reglerna ändras vid specifika punkter (till exempel FORWARD, INPUT, OUTPUT) och att allt annat lämnas som det är. Kostnaden är den extra kostnaden för att skicka paket upp och ner genom NFQUEUE, med den ovannämnda effekten om volymen är mycket hög eller reglerna är resurskrävande.

I AF_PACKET- läge arbetar Suricata närmare nätverksgränssnittet och kopierar paket över AF_PACKET-sockets. Detta är en mycket snabbare nollkopieringsmetod , men det kräver att systemet fungerar som en gateway med två gränssnitt och att trafikblockering utförs på vidarebefordringsnivå mellan nätverkskort: paketet som ska blockeras skickas helt enkelt inte från ingångsgränssnittet till utgångsgränssnittet.

I båda lägena kan Suricata kombineras med Netfilter, men NFQUEUE passar särskilt bra i scenarier där vi vill återanvända all iptables-logik (policyer, intervall, tidigare regler) och bara skicka den trafik till Suricata som vi är intresserade av att granska på djupet.

Grundläggande installation av Suricata från källkod

För de som föredrar att kompilera Suricata istället för att använda paket, innebär processen på Debian/Ubuntu-liknande distributioner att man först installerar kompileringsberoendena (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev, etc.), laddar ner tarballen från den officiella webbplatsen och kör den klassiska ./configure, make, make install.

Under konfigurationsfasen kommer skriptet att indikera vilka supportfunktioner som har aktiverats: AF_PACKET ja/nej, PF_RING, NFQUEUE ja/nej, NFLOG, IPFW, stöd för libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP, etc. Det är viktigt att verifiera att NFQUEUE är aktiverat om vi vill arbeta i det läget , och att det insamlingsbibliotek vi är intresserade av har hittats.

Efter att du har installerat binärfilen kan du köra `make install-conf` för att distribuera en standardkonfiguration till `/etc/suricata` och `make install-rules` för att ladda ner och placera en uppsättning Emerging Threats-regler i `/etc/suricata/rules`. Dessa uppsättningar kan sedan uppdateras med verktyg som `suricata-update`.

På Red Hat/CentOS-system är logiken liknande, med användning av yum eller dnf för beroenden (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel, etc.) och sedan kompilering med samma steg. Av prestandaskäl är det också lämpligt att inaktivera LRO/GRO i insamlingsgränssnittet med ethtool, eftersom dessa avlastningsfunktioner kan påverka synligheten av paket på IDS-nivå.

Suricata-konfiguration: YAML, variabler och trådning

Suricatas huvudkonfiguration finns i /etc/suricata/suricata.yaml . Det är en ganska läsbar och kraftigt kommenterad YAML-fil, där allt från loggsökvägar och regeluppsättningar till måloperativsystempolicyer och trådparametrar definieras.

Ett av de grundläggande fälten är `default-log-dir` , som anger var loggfilerna ska lagras (som standard `/var/log/suricata`). Under `vars`-sektionen finns variabler som `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` och `SSH_PORTS`, vilka fungerar som förkortningar i reglerna. `HOME_NET` konfigureras vanligtvis med det lokala nätverksintervallet vi vill skydda, medan `EXTERNAL_NET` vanligtvis definieras som `!HOME_NET`.

En annan viktig del är host-os-policyn , som talar om för Suricata vilket operativsystem som ska köra vissa IP-intervall. Detta gör att det kan justera hur det återmonterar TCP eller tolkar vissa beteenden hos nätverksstacken , vilket gör det svårare att kringgå protokoll baserat på skillnader mellan stackar (Windows vs. Linux, etc.). Specifika intervall kan tilldelas kategorier som Windows, Linux, BSD, Vista, Windows 2003, etc.

Angående trådning låter trådningssektionen dig finjustera CPU-affinitet och antalet detekteringstrådar. Som standard är `set-cpu-affinity` vanligtvis inaktiverat, vilket låter systemschemaläggaren distribuera trådar över kärnorna. Parametern `detect-thread-ratio` anger hur många detekteringstrådar som skapas per tillgänglig kärna; med `detect-thread-ratio: 1.5` på en 8-kärnig maskin genererar Suricata 12 detekteringstrådar, plus trådar för infångning och hantering.

Hela modellen återspeglas sedan i utdata när daemonen startar: en capture-tråd (till exempel pcap) och flera detektortrådar är synliga, utöver flödeshanterare och statistikhanterare. Denna flerprocessarkitektur är det som gör att Suricata kan skala mycket bättre än enkeltrådade motorer när de ställs inför 10/40 Gbit/s-länkar.

Regler och signaturuppdateringar i Suricata

Suricata förlitar sig på regeluppsättningar för att upptäcka attackmönster, avvikande beteenden och protokollmissbruk. Förutom att acceptera regler i Snort-format är det vanligaste ekosystemet det för Emerging Threats: ET Open (gratis) och ET Pro (kommersiellt), med regler inriktade på aktuella hot.

Många moderna distributioner inkluderar verktyget `suricata-update` , vilket förenklar regelhanteringen: det uppdaterar källor, aktiverar eller inaktiverar specifika leverantörer och laddar ner de senaste versionerna av signaturuppsättningar. Ett typiskt arbetsflöde skulle vara att installera `suricata-update` (till exempel via pip), köra den första `suricata-update` för att ladda ner ET Open, lista källor med `suricata-update list-sources`, aktivera ytterligare källor som `ptresearch/attackdetection`, `oisf/trafficid` eller `sslbl/ssl-fp-blacklist` och köra `suricata-update` igen för att återskapa regelfilen.

Filen suricata.yaml justeras för att peka på rätt sökväg till reglerna, och därifrån börjar Suricata generera varningshändelser som loggas i fast.log (snabb, läsbar text) och eve.json (strukturerad JSON med mycket fullständig information). Det senare formatet är särskilt användbart för att mata instrumentpaneler, korrelationssystem eller anpassade skript.

Förutom signaturer innehåller Suricata avkodare och parsers för flera protokoll , vilket gör att den är mindre beroende av portar: den kan identifiera HTTP-trafik även om den går genom icke-standardiserade portar, detektera SSH, TLS, DNS etc. över olika portar och inkapslingsnivåer (inklusive blandade IPv4/IPv6-tunnlar).

Praktisk användning: från att upptäcka webbattacker till automatisk blockering

Ett av de mest önskvärda användningsområdena i webbhotellsmiljöer eller datacenter är att i realtid upptäcka försök att utnyttja sårbarheter i webbapplikationer (t.ex. WordPress och dess plugins) och reagera automatiskt, vanligtvis genom att blockera eller svartlista käll-IP-adressen i brandväggen.

Suricata, som drivs av uppdaterade regler, kan känna igen specifika attackmönster mot URL:er, parametrar, HTTP-nyttolaster och till och med förfrågningssekvenser som matchar kända attacker. IDS kan fungera i passivt läge och ta emot trafik via spegling från en switchport (SPAN), men för att fungera som en IPS och blockera attacker måste den integreras med vidarebefordringsplanet.

Det finns två vanliga metoder: att konfigurera IDS som en onlinebrygga, så att trafiken fysiskt passerar genom maskinen (med hjälp av iptables, AF_PACKET eller PF, beroende på plattform), eller att lämna topologin som den är men kombinera spegling med åtgärder på den centrala brandväggen via API, skript eller NFQUEUE . Det första tillvägagångssättet minimerar latensen mellan detektering och blockering, på bekostnad av att lägga till ytterligare ett element "mitt i" nätverket; det andra erbjuder större flexibilitet och motståndskraft, men introducerar mer komplexitet i orkestreringen.

Det är fullt möjligt för ett intrångsdetekteringssystem (IDS) att upptäcka ett försök att utnyttja ett sårbart WordPress-plugin och sedan, antingen direkt eller via en associerad komponent, lägga till angriparens IP-adress till en iptables-svartlista. Detta kan göras via Suricatas JSON-utdata och skript som anropar iptables/nftables , eller genom att delegera en del av logiken till NFQUEUE, där själva sökmotorn eller en associerad process fattar beslutet i farten utan att vänta på att en extern lista ska uppdateras.

Detta gör att du kan fokusera på hot som verkligen spelar roll (exploits, eskaleringsförsök, mycket aggressiva skanningar), ignorera eller helt enkelt logga bakgrundsljud som grundläggande portskanningar som i många sammanhang inte är oroande i sig.

Suricata på Pfsense: öppen källkodsbrandvägg med integrerade IDS/IPS

Inte alla kan eller vill ha råd med en proprietär avancerad brandvägg som Palo Alto. I många miljöer är det mer attraktivt att sätta upp en öppen källkodslösning med pfSense och Suricata , som täcker både avancerade brandväggsbehov (multi-WAN, VLAN, VPN, NAT, etc.) och IDS/IPS.

Pfsense, baserat på FreeBSD och Packet Filter, fungerar särskilt bra med virtualiserade miljöer (Proxmox, KVM, etc.), med undantaget att det rekommenderas att använda E1000-kort istället för Virtio i KVM-maskiner om man vill undvika prestandaproblem och krascher under belastning, såvida man inte tillämpar Netgates rekommendationer (inaktivera avlastning av hårdvarukontrollsumma i System > Avancerat > Nätverk och starta om, med vetskapen om att detta kanske inte räcker vid mycket höga belastningar).

Minimikraven för hårdvara för ett labb med Suricata på Pfsense kan vara blygsamma (1 processor 500 MHz, 1 GB RAM, 4 GB hårddisk), men för seriös användning rekommenderas minst 2 processorer, 4 GB RAM och 16 GB lagringsutrymme, och man bör inte glömma att ha flera nätverksgränssnitt (ett för WAN, ett annat för LAN, fler om man vill ha flera WAN eller komplexa VLAN).

Att installera pfSense går väldigt snabbt: du startar från ISO-filen, accepterar licensen, väljer installation, väljer språk och tangentbordslayout, låter partitioneringen vara automatisk (Auto UFS om du ska använda hela disken) och inom några minuter är systemet redo för sin första start. Konsolen erbjuder en meny för att tilldela gränssnitt, omstart, starta gränssnittet etc.

I labbet, till exempel i VirtualBox, är det vanligt att tillfälligt inaktivera Pfsense-brandväggen från konsolen med pfctl -d för att komma åt webbgränssnittet via WAN (användarnamn admin, lösenord pfsense) och slutföra den initiala guiden: allmänna data, NTP-servrar, WAN-konfiguration (DHCP räcker vanligtvis i labbet), LAN, ändring av administratörslösenord och tillämpning av konfigurationen.

När åtkomsten är stabiliserad kan du skapa en regel i WAN-brandväggen som tillåter HTTPS från vilken källa som helst till pfsense IP-adress, och lägga till beskrivande avgränsare för att visuellt organisera reglerna (till exempel "Brandväggsåtkomst"). Det är också lämpligt att inaktivera alternativet att blockera privata nätverk på WAN om du befinner dig i en testmiljö med RFC1918-adresser, för att undvika att ständigt behöva använda `pfctl -d`.

Suricata-installation på pfSense och översikt

Med pfSense-basen igång är installationen av Suricata lika enkelt som att gå till System > Pakethanterare > Tillgängliga paket , söka efter Suricata och installera paketet. Processen laddar ner flera filer och kan ta ett tag beroende på din hårdvara, men den assisteras helt via webbgränssnittet.

När det är installerat visas en Suricata-post på fliken Tjänster, där du kan konfigurera instanser efter gränssnitt (WAN, LAN, VLAN, etc.), välja vilka regeluppsättningar som ska användas, aktivera IDS- eller IPS-läge och justera prestanda- och loggparametrar. Utbudet av alternativ är omfattande (tillräckligt för hela artiklar bara om konfiguration), men fördelen är att många uppgifter som i Linux kräver manuell YAML-redigering hanteras här med formulär och kryssrutor.

Viktig anmärkning: Även om det kan vara frestande att öppna pfSense-administrationen direkt mot internet i en labbmiljö, är det i produktion avgörande att begränsa åtkomsten till statiska IP-adresser, använda VPN för fjärrhantering och undvika att lämna webbkonsolen exponerad till varje pris . pfSense är mycket flexibel, men den måste också behandlas som det kritiska element den är.

Med Suricata aktiverat på pfSense får du en miljö där trafik passerar genom pfSense för brandvägg och NAT, och Suricata inspekterar den enligt sina regler och kan blockera den i IPS-läge . Denna kombination, som hanteras från ett enda webbgränssnitt, förenklar avsevärt implementeringen av DPI-skydd i små och medelstora nätverk.

I många implementeringar kompletteras detta av en koppling mellan Pfsense/Suricata och en SIEM- eller centraliserad loggplattform, vilket drar nytta av strukturerade utdataformat för att korrelera händelser och upptäcka bredare kampanjer.

Händelseövervakning och exempelloggar i Suricata

När Suricata körs loggas händelser till den sökväg som definieras av default-log-dir, vanligtvis /var/log/suricata . fast.log-filen använder ett kompakt textformat med tidsstämplar, regel-ID:n, klassificeringar och prioritet, lämpligt för snabb inspektion från terminalen (tail -f).

Till exempel, när vi stöter på trafik med felaktiga TCP-kontrollsummor, kan vi se rader som dessa: tidsstämplar med datum och tid, följt av regelidentifieraren (t.ex. 1:2200074:1), meddelandet "SURICATA TCPv4 ogiltig kontrollsumma", klassificering, prioritet och käll-destinations-IP/portpar. Dessa typer av varningar möjliggör snabb identifiering av paketintegritetsproblem eller kringgående försök.

Filen eve.json innehåller samma händelser i JSON-format, med fält som timestamp, event_type, src_ip, dest_ip, src_port, dest_port, proto och en underfil för varningar med action, gid, signature_id, rev, signature, category och severity. Detta format kan enkelt matas in med Logstash, Fluentd, Filebeat eller någon annan loggagent , vilket möjliggör mycket mer omfattande analyser än att bara använda vanlig text.

När man distribuerar Suricata på en server med flera kärnor (t.ex. 8 kärnor) är trådkomprimeringen tydligt uppenbar i verktyg som htop i trådläge, där en eller flera infångningstrådar (pcap, AF_PACKET eller NFQ) och ett stort antal detektionstrådar fördelade över kärnorna visas. Att justera detektionstrådförhållandet och CPU-affiniteten kan påverka dataflödet och latensen avsevärt när trafikvolymen närmar sig plattformens gränser.

Innan du driftsätter den i produktion är det lämpligt att lägga lite tid på att finjustera vilka regeluppsättningar som aktiveras för att undvika en flod av falska positiva resultat som kan blockera legitim trafik eller störa loggarna. Med Suricata-uppdateringen kan du inaktivera hela kategorier eller enskilda regler för att hitta en rimlig balans mellan känslighet och användbarhet.

Specialapplikationer: VoIP, ljudanalys och kreativ NFQUEUE

Utöver klassiska användningsområden (skydd mot webbtjänster, upptäckt av skadlig kod, DDoS-analys) möjliggör duon Netfilter+NFQUEUE ganska kreativa lösningar inom områden som VoIP. Det är till exempel möjligt att konfigurera ett anti-SPIT-filter (spam över IP-telefoni) eller ett system för att censurera svordomar i RTP-strömmar.

Tanken skulle vara: att identifiera RTP-trafik via portar eller protokolligenkänning och skicka den till NFQUEUE; från användarapplikationen, rekonstruera RTP-strömmen med hjälp av ett bibliotek som librtp , extrahera ljudet i WAV-format och skicka det till en nyckelordsigenkänningsmotor (wordspotting), såsom ett syntes- eller igenkänningsbibliotek som erbjuds av en tredje part.

Baserat på de detekterade orden kan NFQUEUE-processen besluta att tillåta, blockera eller till och med ändra uppspelning genom att infoga ett pip i strömmen, även om det senare kräver mycket finjusterad kontroll av RTCP, paketsekvenser och tidpunkter – nästan en man-in-the-middle-metod. Det är inte trivialt, men teoretiskt sett är det fullt möjligt genom att utnyttja samma kö- och domslutsystem.

Det är sant att en del av detta skulle kunna göras med en enkel sniffer som matar data till en extern processor och sedan agerar på SIP-signaleringen eller via en SBC (Asterisk, Kamailio, etc.). Skillnaden med att använda NFQUEUE är att åtgärden på RTP-flödet kan vara omedelbar och direkt , utan att behöva koordinera flera komponenter eller vänta på att signallagret ska slutföra samtalet.

Dessa scenarier illustrerar tydligt potentialen i kombinationen GNU/Linux + Netfilter + Suricata + tredjepartsbibliotek: det handlar inte bara om att blockera portar och IP-adresser, utan om att orkestrera komplexa trafikbeslut i realtid med hjälp av ett 100 % fritt programvaruekosystem.

Om man tittar på hela resan, från det lilla C-programmet som alltid accepterar paket till en flerprocessdriven Suricata-distribution integrerad med NFQUEUE, Pfsense, databaser och cacher, kan man uppskatta den flexibilitet som denna teknikstack erbjuder för att bygga allt från enkla dynamiska brandväggar till IDS/IPS-arkitekturer i datacenterskala, med verkligt djupgående inspektionsmöjligheter och automatiserade svar på alltmer komplexa attacker.