Snort eller Suricata. Del 3: skydda kontorsnätet

I den föregående artikeln Vi har förklarat hur man kör en stabil version av Suricata på Ubuntu 18.04 LTS. Att konfigurera IDS på en nod och koppla ihop gratis regelpaket är ganska enkelt. Idag kommer vi att gå igenom hur man använder Suricata installerat på en virtuell server för att skydda det företagsnätverk mot de vanligaste typerna av attacker. För detta behöver vi en VDS på Linux med två CPU-kärnor. Mängden RAM beror på belastningen: vissa klarar sig med 2 GB, medan mer krävande uppgifter kan kräva 4 eller till och med 6. Fördelen med en virtuell maskin är möjligheten att experimentera: du kan börja med en minimal konfiguration och öka resurserna vid behov.

foto: Reuters

• Snort eller Suricata. Del 1: Väljer en kostnadsfri IDS/IPS för att skydda det företagsnätverk
• Snort eller Suricata. Del 2: installation och grundläggande konfiguration av Suricata

Förenar nätverk

Att flytta IDS till en virtuell maskin kan först och främst behövas för tester. Om du aldrig har arbetat med liknande lösningar är det inte värt att skynda sig att beställa fysiskt hårdvara och ändra nätverksarkitekturen. Det är bättre att prova systemet säkert och utan onödiga kostnader, för att bestämma behovet av beräkningsresurser. Det är viktigt att förstå att all företagsdata då måste passera genom en enda extern nod: för att ansluta ett lokalt nätverk (eller flera nätverk) till VDS med installerad IDS Suricata kan du använda SoftEther – en lättkonfigurerad plattformsoberoende VPN-server som erbjuder pålitlig kryptering. Kontorskopplingen till internet kanske inte har en verklig IP, så det är bättre att sätta upp det på en VPS. Det finns inga färdiga paket i Ubuntu-repositoriet, så programvaran måste laddas ner antingen från projektets webbplats, eller från en extern repository på tjänsten Launchpad (om du litar på den):

sudo add-apt-repository ppa:paskal-07/softethervpn
sudo apt-get update

Du kan se en lista över tillgängliga paket med följande kommando:

apt-cache search softether

Vi behöver softether-vpnserver (servern i testkonfigurationen körs på VDS), samt softether-vpncmd – kommandoradsverktyg för dess konfiguration.

sudo apt-get install softether-vpnserver softether-vpncmd

För att konfigurera servern används ett speciellt kommandoradsverktyg:

sudo vpncmd

Vi kommer inte att gå in på detaljrika inställningar: proceduren är ganska enkel, den är väl beskriven i många publikationer och rör inte direkt ämnet för artikeln. Om vi sammanfattar, efter att ha startat vpncmd, behöver man välja alternativ 1 för att gå till serverns kontrollkonsol. För detta ändamål måste man ange namnet localhost och trycka på Enter istället för att ange namnet på hubben. I konsolen ställer man in administratörslösenordet med kommandot serverpasswordset, tar bort den virtuella hubben DEFAULT (kommandot hubdelete) och skapar en ny med namnet Suricata_VPN, samt ställer in dess lösenord (kommandot hubcreate). Därefter behöver man gå till kontrollkonsolen för den nya hubben med kommandot hub Suricata_VPN för att skapa en grupp och en användare med kommandona groupcreate och usercreate. Användarlösenordet ställs in med kommandot userpasswordset.

SoftEther stödjer två trafiköverföringslägen: SecureNAT och Local Bridge. Den första är en egen teknik för att bygga en virtuell privat nätverk med egen NAT och DHCP. SecureNAT kräver varken TUN/TAP eller konfiguration av Netfilter eller någon annan brandvägg. Ruttningen berör inte systemets kärna, och alla processer virtualiseras och fungerar på vilken VPS/VDS som helst oavsett vilken hypervisor som används. Detta leder till ökad belastning på processorn och minskad hastighet jämfört med läget Local Bridge, som kopplar den virtuella hubben SoftEther med den fysiska nätverksadaptern eller TAP-enheten.

Inställningen blir svårare i det här fallet, eftersom ruttningen sker på kärnnivå med Netfilter. Våra VDS byggs på Hyper-V, så på det sista steget skapar vi en lokal bro och aktiverar TAP-enheten med kommandot bridgecreate Suricate_VPN -device:suricate_vpn -tap:yes. När vi lämnar kontrollkonsolen för hubben ser vi ett nytt nätverksgränssnitt i systemet, som ännu inte har tilldelats något IP:

ifconfig

Vidare måste vi aktivera paketrutten mellan gränssnitten (ip forward), om den inte är aktiv:

sudo nano /etc/sysctl.conf

Avkommentera följande rad:

net.ipv4.ip_forward = 1

Spara ändringarna i filen, lämna redigeraren och tillämpa dem med följande kommando:

sudo sysctl -p

Därefter behöver vi bestämma en sub-nätverksadress för det virtuella nätverket med fiktiva IP-adresser (till exempel 10.0.10.0/24) och tilldela en adress till gränssnittet:

sudo ifconfig tap_suricata_vp 10.0.10.1/24

Sedan kommer det att krävas att vi definierar Netfilter-regler.

1. Vid behov, tillåt inkommande paket på de lyssnande portarna (SoftEther-protokollet använder HTTPS och port 443)

sudo iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 992 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
sudo iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 5555 -j ACCEPT

2. Ställ in NAT från nätverket 10.0.10.0/24 till serverns huvud-IP

sudo iptables -t nat -A POSTROUTING -s 10.0.10.0/24 -j SNAT --to-source 45.132.17.140

3. Tillåt passerande paket från nätverket 10.0.10.0/24

sudo iptables -A FORWARD -s 10.0.10.0/24 -j ACCEPT

4. Tillåt passerande paket för redan etablerade anslutningar

sudo iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

Vi lämnar automatiseringen av processen vid systemstart via init-skript som en övning till läsarna.

Om du vill tilldela IP automatiskt till klienterna, måste du också installera någon form av DHCP-tjänst för den lokala bron. Nu är serverinställningen klar och vi kan gå vidare till klienterna. SoftEther stöder många protokoll, vars användning beror på utrustningens kapabiliteter i det lokala nätverket.

netstat -ap |grep vpnserver

Eftersom vår testrouter också kör Ubuntu, installerar vi mjukvarupaketen softether-vpnclient och softether-vpncmd från ett externt repository för att använda det proprietära protokollet. Vi måste starta klienten:

sudo vpnclient start

För att konfigurera använder vi verktyget vpncmd, och väljer localhost som maskin där vpnclient körs. Alla kommandon utförs i konsolen: vi behöver skapa ett virtuellt gränssnitt (NicCreate) och ett konto (AccountCreate).

I vissa fall behöver vi ange autentiseringsmetod med kommandona AccountAnonymousSet, AccountPasswordSet, AccountCertSet och AccountSecureCertSet. Eftersom vi inte använder DHCP, anges adressen för den virtuella adaptern manuellt.

Dessutom behöver vi aktivera ip-forward (parametern net.ipv4.ip_forward=1 i filen /etc/sysctl.conf) och konfigurera statiska rutter. Vid behov kan portöppningar ställas in på VDS med Suricata för att använda tjänsterna i det lokala nätverket. Nu kan sammanslagningen av nätverken anses vara avslutad.

Den föreslagna konfigurationen kommer ungefär att se ut så här:

Konfigurera Suricata

I den föregående artikeln Vi har pratat om två arbetslägen för IDS: genom kö NFQUEUE (NFQ-läget) och genom zero copy (AF_PACKET-läget). Den andra kräver två gränssnitt, men erbjuder bättre prestanda – vi kommer att använda just den. Parametern är förinställd i /etc/default/suricata. Vi behöver också redigera avsnittet vars i /etc/suricata/suricata.yaml, där vi anger det virtuella undermedlet som hemmanätverk.

För att starta om IDS använder vi kommandot:

systemctl restart suricata

Lösningen är klar, nu kan det vara nödvändigt att kontrollera dess motståndskraft mot angripares åtgärder.

Simulera attacker

Det finns flera scenarier för fältanvändning av externa IDS-tjänster:

Skydd mot DDoS-attacker (huvudsakligt syfte)

Att implementera en sådan lösning inom företagsnätverket är svårt, eftersom paketen för analys måste komma till det gränssnitt som övervakar internet. Även om IDS blockerar dem, kan parasittrafik överbelasta datakanalen. För att undvika detta behöver man beställa en VPS med tillräckligt kraftfull internetanslutning som kan hantera all trafik från det lokala nätverket och all extern trafik. Detta är ofta enklare och billigare än att utöka kontorets kanal. Som alternativ bör man nämna specialiserade tjänster för skydd mot DDoS. Kostnaden för deras tjänster är jämförbar med kostnaden för en virtuell server, samtidigt som man slipper arbetskrävande inställningar, men det finns också nackdelar – klienten får endast skydd mot DDoS för sina pengar, medan en egen IDS kan konfigureras hur som helst.

Skydd mot externa attacker av andra typer

Suricata kan hantera försök att utnyttja olika sårbarheter i de tjänster som är tillgängliga från internet i företagsnätverket (e-postserver, webbserver och webbapplikationer osv.). Vanligtvis installeras IDS inuti det lokala nätverket efter gränsenhetsenheter, men att ha den utanför är också en giltig lösning.

Skydd mot interna angripare

Trots alla ansträngningar från systemadministratören kan datorerna i det företagsnätverk bli infekterade med skadlig programvara. Dessutom kan ibland störare dyka upp i det lokala nätverket och försöka utföra oetiska operationer. Suricata kan hjälpa till att blockera sådana försök, även om det är bäst att installera den inom perimetern för att skydda det interna nätverket och använda den tillsammans med en switch som kan spegla trafik till en port. En extern IDS är också inte helt onödig – åtminstone kan den upptäcka försök från onda program som finns i LAN:et att kontakta externa servrar.

Låt oss först skapa ytterligare en testande angripande VPS, och på routern i det lokala nätverket startar vi Apache med standardkonfigurationen, varefter vi vidarebefordrar den 80:e porten från IDS-servern. Nästa steg blir att simulera en DDoS-attack från angriparen. För detta behöver vi ladda ner, kompilera och köra ett litet program xerxes på angriparens nod (installationen av paketet gcc kan vara nödvändig):

git clone https://github.com/Soldie/xerxes-DDos-zanyarjamal-C.git
cd xerxes-DDos-zanyarjamal-C/
gcc xerxes.c -o xerxes
./xerxes 45.132.17.140 80

Resultatet av dess arbete visade sig vara följande:

Suricata blockerar skurken, medan standard Apache-sidan öppnas trots vår improviserade attack och det relativt svaga bandbredden i "kontors" (faktiskt hemmanätverket). För mer seriösa uppgifter bör man använda Metasploit Framework. Den är avsedd för penetrationstestning och gör det möjligt att simulera olika typer av attacker. Installationsinstruktionen är tillgängligt finns på projektets hemsida. Efter installationen behöver den uppdateras:

sudo msfupdate

För teständamål startar vi msfconsole.

Tyvärr saknar de senaste versionerna av ramverket möjligheten till automatisk hackning, så exploiter måste genomgås manuellt och köras med kommandot use. Först bör öppna portar på den attackerade maskinen identifieras, exempelvis med hjälp av nmap (i vårt fall kan det ersättas med netstat på den attackerade noden), och sedan välja och använda lämpliga Metasploit-moduler.. 

Det finns också andra verktyg för att kontrollera IDS:ens motståndskraft mot attacker, inklusive onlinetjänster. Av ren nyfikenhet kan vi genomföra ett stresstest med hjälp av testversionen av IP Stresser. För att kontrollera reaktionen på handlingar från interna angripare bör speciella verktyg installeras på en av maskinerna i det lokala nätverket. Det finns många alternativ och de bör periodiskt tillämpas, inte bara på experimentella miljöer utan även på arbetsystem; men det är en helt annan historia.

Källa: habr.com