Zeek fyllde 9.0 den 14 september 2026. Projektet la ut sitt officiella releaseblogginlägg fyra dagar senare, och versionen är märkt som LTS (Long-Term Support), vilket betyder att den är byggd för att köras i produktion under lång tid utan att tvinga fram snabba uppgraderingar. För säkerhetsteam i Sverige och övriga Norden är det ett bra tillfälle att sätta upp nätverksövervakning från grunden eller uppdatera en gammal installation. Den här guiden går igenom hela vägen: från ett tomt Linux-system till en fungerande Zeek-sensor som loggar trafik, upptäcker misstänkt beteende och skickar data vidare till ett SIEM.

Guiden är skriven för säkerhetsingenjörer, nätverksadministratörer och den som ansvarar för incidenthantering i en mellanstor eller stor organisation, men den kräver inga tidigare Zeek-kunskaper. Räkna med att avsätta cirka 90 minuter för att gå igenom samtliga fjorton steg på en testserver, från installation till en fungerande detektionsregel. Ska ni driftsätta i ett kluster med flera workers tillkommer ytterligare tid för planering av nätverksarkitekturen, men grundflödet är detsamma oavsett skala.

Zeek beskriver sig självt inte som en klassisk brandvägg eller ett vanligt intrångsdetekteringssystem, utan som en network security monitor. Skillnaden märks direkt när man börjar arbeta med det. Istället för att bara larma på signaturer bygger Zeek strukturerade loggar av allt som händer på nätverksnivå: anslutningar, DNS-slagningar, HTTP-förfrågningar, TLS-handskakningar och mycket annat. Den datan blir grunden för både hotjakt och incidenthantering, och den går utmärkt att mata in i verktyg som ni redan använder för incidenthantering eller threat intelligence.

Vad är Zeek 9.0 och varför det spelar roll just nu

Zeek startade som forskningsprojektet Bro på 1990-talet och bytte namn till Zeek 2018. Det är fortfarande ett av de mest använda öppna verktygen för djup nätverksanalys, både i akademiska nätverk och hos kommersiella säkerhetsteam. Version 9.0.0 gick ut som release candidate i slutet av augusti 2026 och testades av communityn innan den slutliga byggen landade den 14 september. Att den märks som LTS betyder att organisationer kan planera en produktionsdistribution utan att oroa sig för att versionen fasas ut om några månader.

Namnbytet från Bro till Zeek 2018 var mer än kosmetiskt. Det speglade en mognadsprocess där projektet gick från ett akademiskt forskningsverktyg till en plattform som stora organisationer kan lita på i skarp drift, med tydligare versionshantering, bättre dokumentation och en mer förutsägbar releasetakt. Den utvecklingen syns tydligt i hur 9.0-cykeln hanterades: en offentlig utvecklingsuppdatering i augusti, en release candidate öppen för communitytestning, och till slut en LTS-märkt slutversion. Det är en betydligt mer strukturerad process än vad många öppna säkerhetsverktyg erbjuder, och det är en av anledningarna till att Zeek fortsatt används brett trots konkurrens från både kommersiella och andra öppna alternativ.

Det som gör tidpunkten intressant är hur hotbilden har förskjutits. Allt fler intrång bygger på krypterad trafik för att dölja kommando- och kontrollkanaler, vilket gör paketinspektion på applikationslagret svårare men inte omöjligt. Zeek löser inte kryptering, men det ger analytiker möjlighet att se mönster: ovanliga TLS-versioner, långa uppkopplingar mot okända destinationer, DNS-slagningar med onormalt hög frekvens. Kombinerat med ett skriptbaserat gränssnitt kan ett säkerhetsteam bygga egna detektionsregler som är skräddarsydda för den egna miljön, snarare än att förlita sig enbart på färdiga signaturer.

Zeek är öppen källkod och kostar inget att installera eller köra, vilket är en tydlig fördel jämfört med kommersiella nätverkssensorer med licenskostnad per sensor. Projektet drivs av en aktiv community: utvecklingsuppdateringar, release candidates och LTS-annonseringar har publicerats löpande under augusti och september 2026, vilket visar att utvecklingstakten är hög snarare än stillastående. Företaget Corelight bygger kommersiella produkter och support ovanpå samma öppna kod, ungefär som Elastic gör med Elasticsearch, men själva Zeek-projektet förblir fritt att ladda ner och driftsätta utan avtal.

Zeek jämfört med Suricata och Snort: tre olika angreppssätt

En vanlig fråga när man börjar planera nätverksövervakning är vilket verktyg man egentligen ska välja. Svaret beror mindre på vilket som är “bäst” och mer på vilket problem ni försöker lösa. Suricata och Snort är signaturbaserade IDS/IPS-motorer som i grunden jämför trafik mot en regeldatabas och larmar när något matchar, medan Zeek bygger en löpande, strukturerad bild av allt som passerar nätverket oavsett om det matchar en känd signatur eller inte. Många säkerhetsteam i praktiken kör flera av dessa verktyg parallellt snarare än att välja bort de andra.

VerktygPrimärt fokusStyrkaBegränsning
ZeekProtokollanalys och strukturerad loggningDjup kontext, skriptbar detektionslogik, stark för hotjaktKräver mer eget arbete för att bygga faktiska larmregler
SuricataSignaturbaserad IDS/IPSSnabba larm på kända hot, kan aktivt blockera trafikMissar okända hot som saknar signatur
SnortSignaturbaserad IDS/IPSVäl beprövat, stort community kring reglerLiknande begränsning som Suricata mot nya hot

I praktiken kompletterar de varandra bra: Suricata eller Snort fångar det som redan är känt och dokumenterat, medan Zeek ger analytikern rådata och sammanhang för att hitta det som ingen signatur ännu täcker. Ett team som bara har budget eller tid för ett verktyg bör fråga sig vad de faktiskt saknar idag. Saknar ni realtidsblockering av kända hot, väger Suricata tyngre. Saknar ni möjligheten att i efterhand förstå vad som hände under en incident, är Zeek det naturliga valet, och det är också därför den här guiden fokuserar på just Zeek.

Förutsättningar: det här behöver du innan du börjar

Du behöver inte en stor budget för att komma igång, men du behöver rätt förutsättningar. Zeek kräver ett Linux-baserat system med tillgång till root eller sudo, ett nätverksgränssnitt som kan sättas i promiskuöst läge (eller en TAP/SPAN-port om du vill se riktig trafik) och grundläggande erfarenhet av kommandoraden. Kunskap om nätverksprotokoll som TCP, DNS och TLS underlättar när du senare ska tolka loggarna, men det går utmärkt att lära sig detta parallellt med installationen. Tabellen nedan sammanfattar vad som krävs för en fungerande testmiljö.

KomponentRekommenderad nivåVarför det behövs
Operativsystem64-bitars Linux, t.ex. Ubuntu 24.04 LTS eller Debian 12Officiellt paketstöd och stabila kärnbibliotek
Zeek9.0.0 (LTS)Släppt 14 september 2026, nuvarande långtidsstödda version
CMake3.15 eller senareKrävs om du bygger Zeek från källkod
Python3.8 eller senareAnvänds av zkg och en del skript och verktyg
ArbetsminneMinst 4 GB, 8 GB+ i produktionLoggning och protokollanalys är minneskrävande vid hög trafik
DiskutrymmeMinst 20 GB ledigtLoggfiler växer snabbt, särskilt conn.log och dns.log
NätverksåtkomstSPAN-port, TAP eller virtuellt gränssnittZeek måste se trafiken den ska analysera

Vill du testa utan att röra produktionsnätverket kan du köra allt i en virtuell maskin och analysera inspelade pcap-filer istället för livetrafik. Det är ett bra sätt att lära sig grunderna innan du kopplar in en riktig SPAN-port. Har du redan ett nätverksscanningsflöde på plats, till exempel med Nmap, kompletterar Zeek det flödet genom att visa vad som faktiskt passerar nätet över tid, inte bara en ögonblicksbild.

Steg 1–3: Förbered servern och installera beroenden

Börja med en ren server och uppdatera paketlistorna. Zeek kan installeras antingen via färdiga paket från projektets egna repositories eller genom att bygga från källkod. För en LTS-version rekommenderas paketinstallation i produktion, eftersom det förenklar framtida säkerhetsuppdateringar.

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl gnupg2 lsb-release build-essential \
  cmake make gcc g++ flex bison libpcap-dev libssl-dev \
  python3 python3-dev python3-pip zlib1g-dev libmaxminddb-dev \
  swig sqlite3

Steg två är att avgöra vilken installationsväg som passar din miljö. Kör du Ubuntu eller Debian går det snabbast att använda Zeek-projektets eget paketförråd, vilket ger snabbare säkerhetsuppdateringar än att bygga om från källkod varje gång en ny version släpps.

# Lägg till Zeek-projektets repository för din distribution
echo 'deb http://download.opensuse.org/repositories/security:/zeek/ /' \
  | sudo tee /etc/apt/sources.list.d/zeek.list
curl -fsSL https://download.opensuse.org/repositories/security:zeek/xUbuntu_24.04/Release.key \
  | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/zeek.gpg > /dev/null
sudo apt update

Steg tre handlar om att skapa en dedikerad användare och katalogstruktur innan installationen. Kör aldrig Zeek som root i produktion längre än nödvändigt, utan begränsa rättigheterna till vad processen faktiskt behöver för att läsa nätverksgränssnittet.

sudo mkdir -p /opt/zeek
sudo groupadd zeek 2>/dev/null
sudo useradd -r -g zeek -d /opt/zeek -s /usr/sbin/nologin zeek 2>/dev/null
sudo chown -R zeek:zeek /opt/zeek

Steg 4–6: Ladda ner, bygg och installera Zeek 9.0.0

Valde du paketvägen installerar du direkt via apt. Vill du istället bygga från källkod, till exempel för att aktivera specifika funktioner eller köra på en distribution utan färdiga paket, hämtar du källkoden från projektets nedladdningssida.

# Alternativ A: installera via paket
sudo apt install -y zeek

# Alternativ B: bygg från källkod
curl -LO https://download.zeek.org/zeek-9.0.0.tar.gz
tar xzf zeek-9.0.0.tar.gz
cd zeek-9.0.0
./configure --prefix=/opt/zeek
make -j$(nproc)
sudo make install

Byggsteget kan ta allt från tio minuter till över en timme beroende på antal CPU-kärnor. Lägg till binärsökvägen i din shell-profil så att kommandona zeek, zeekctl och zkg blir tillgängliga globalt.

Vilken väg ska du då välja? Paketinstallation vinner nästan alltid i produktion: uppdateringar sköts av apt, och ni slipper hantera egna byggmiljöer på flera servrar. Källkodsbygget är mest värdefullt när ni behöver aktivera experimentella funktioner som ännu inte finns i paketen, eller när ni kör en distribution som saknar officiellt paketstöd. Ett tredje alternativ, som inte täcks i detalj här, är att köra Zeek i en container, vilket kan förenkla utrullning över flera sensorer men kräver extra omsorg kring hur nätverksgränssnittet exponeras till containern.

echo 'export PATH=/opt/zeek/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
zeek --version

Går allt rätt visar kommandot version 9.0.0 tillsammans med kompileringsdetaljer. Det är den kontrollpunkt du bör klara innan du går vidare till konfigurationen. Får du felmeddelanden om saknade bibliotek är det nästan alltid ett tecken på att ett beroende från steg ett saknades, snarare än ett fel i själva Zeek-koden.

Steg 7–8: Konfigurera nätverksgränssnitt och noder

Zeek styrs av två centrala konfigurationsfiler i grundinstallationen: node.cfg för att definiera vilka processer som ska köras och på vilka gränssnitt, samt networks.cfg för att tala om vilka IP-intervall som räknas som interna. Öppna node.cfg och peka ut det nätverksgränssnitt som tar emot speglad trafik.

# /opt/zeek/etc/node.cfg
[zeek]
type=standalone
host=localhost
interface=eth1

Byt eth1 mot det gränssnitt som faktiskt är kopplat till din SPAN-port eller TAP. Ett vanligt nybörjarmisstag är att peka Zeek mot förvaltningsgränssnittet istället för övervakningsgränssnittet, vilket gör att loggarna bara visar Zeek-serverns egen trafik.

# /opt/zeek/etc/networks.cfg
10.0.0.0/8        Interna nätverk
172.16.0.0/12     Interna nätverk
192.168.0.0/16    Interna nätverk

Den här filen används av Zeeks skript för att avgöra vad som är “inifrån” och “utifrån”, vilket i sin tur styr en stor del av logiken i standarddetektionsskripten. Utan korrekt konfigurerade interna intervall riskerar du falska positiva larm om intern trafik som ser ut som externa anslutningar.

Steg 9: Starta Zeek med zeekctl och verifiera drift

Med konfigurationen på plats är det dags att driftsätta. Zeekctl är kontrollverktyget som hanterar start, stopp och statuskontroll av Zeek-processerna, och det är samma verktyg oavsett om du kör en enda sensor eller ett kluster.

sudo /opt/zeek/bin/zeekctl deploy
sudo /opt/zeek/bin/zeekctl status

En lyckad start ger ett utdata som liknar det här:

Name         Type       Host          Status    Pid    Started
zeek         standalone localhost     running   18422  18 Sep 09:14:02

Status “running” tillsammans med ett processid betyder att Zeek nu läser trafik från det gränssnitt du angav. Kontrollera direkt att loggkatalogen fylls med data, vanligtvis under /opt/zeek/logs/current/. Ser du bara tomma eller mycket små filer efter några minuter, gå tillbaka och dubbelkolla gränssnittsnamnet i node.cfg.

Autostart vid omstart med systemd

Zeekctl startar inte automatiskt om servern startas om, vilket är lätt att glömma tills en oplanerad omstart plötsligt lämnar er utan nätverksövervakning. Lägg till en enkel systemd-tjänst som anropar zeekctl vid uppstart, så slipper ni bero på att någon manuellt loggar in och kör deploy-kommandot igen.

# /etc/systemd/system/zeek.service
[Unit]
Description=Zeek Network Security Monitor
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/opt/zeek/bin/zeekctl deploy
ExecStop=/opt/zeek/bin/zeekctl stop
User=root

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now zeek.service
sudo systemctl status zeek.service

Med tjänsten aktiverad hanterar systemd omstarter automatiskt, och ni kan använda samma verktyg för övervakning av tjänsten som ni redan använder för andra kritiska system i miljön, till exempel genom att larma om tjänsten fallerar.

Steg 10: Läs och tolka Zeeks loggfiler

Zeeks styrka ligger i hur strukturerade loggarna är. Varje protokoll får sin egen loggfil med tabbseparerade fält, vilket gör dem enkla att ladda in i analysverktyg eller filtrera med vanliga kommandoradsverktyg som awk och grep. Till skillnad från rå pcap-data, som kräver att man öppnar och tolkar enskilda paket för hand, ger Zeeks loggar en färdig sammanfattning på applikationsnivå. Det gör att en analytiker på några minuter kan svara på frågor som “vilka interna värdar har pratat med den här IP-adressen den senaste veckan” utan att behöva bearbeta terabyte av rå trafik.

LoggfilInnehållTypisk användning
conn.logAlla nätverksanslutningar med tid, portar, byte och varaktighetGrundläggande trafikanalys och anomalidetektion
dns.logDNS-frågor och svarUpptäcka DNS-tunnling och kontakt med skadliga domäner
http.logHTTP-förfrågningar, user-agent, statuskoderIdentifiera ovanliga nedladdningar eller C2-kommunikation
ssl.logTLS-handskakningar, certifikat, versionerFlagga föråldrade TLS-versioner eller misstänkta certifikat
files.logFiler som extraherats ur trafikflödenKoppla ihop nedladdade filer med hashvärden för vidare analys
notice.logLarm genererade av Zeeks inbyggda detektionsskriptFörsta anhalten för en analytiker som triagerar händelser

Exempel på en rad i conn.log

175818842.123456  CxjM8x1Z9j2  10.0.5.14  51322  185.220.101.7  443  tcp
duration=812.4  orig_bytes=48213  resp_bytes=1240981  conn_state=S1

En anslutning som pågår i över tretton minuter (812 sekunder) mot en extern IP-adress, med mycket mer data nedladdat än uppladdat, är inte automatiskt skadlig men förtjänar en närmare titt, särskilt om destinationen inte finns med i några kända allowlistor. Det är precis den typen av mönster som gör Zeek användbart vid triage och som kompletterar paketanalys i Wireshark när ni behöver gräva djupare i en specifik session.

Steg 11: Skriv ditt första Zeek-skript för anpassad detektion

Zeeks eget skriptspråk gör det möjligt att koda detektionslogik som är specifik för er miljö, snarare än att förlita sig enbart på generiska signaturer. Ett vanligt nybörjarexempel är att flagga ovanligt långa DNS-svar, vilket ofta är ett tecken på DNS-tunnling.

> cat /opt/zeek/share/zeek/site/lang-dns-length.zeek

event dns_message(c: connection, is_orig: bool, msg: dns_msg, len: count)
    {
    if ( len > 512 )
        {
        NOTICE([$note=Notice::ACTION_LOG,
                $msg=fmt("Ovanligt stort DNS-svar (%d byte) från %s",
                         len, c$id$resp_h),
                $conn=c]);
        }
    }

Lägg till skriptet i din local.zeek genom att peka på filen, ladda om konfigurationen och kontrollera att den nya regeln laddas utan syntaxfel.

echo '@load ./lang-dns-length.zeek' >> /opt/zeek/share/zeek/site/local.zeek
sudo /opt/zeek/bin/zeekctl check
sudo /opt/zeek/bin/zeekctl deploy

Kommandot zeekctl check validerar syntaxen innan skriptet appliceras live, vilket sparar dig från att av misstag ta ner hela sensorn på grund av ett skrivfel i en produktionsfil.

Steg 12: Hantera tillägg med Zeek Package Manager (zkg)

Istället för att skriva allt själv finns ett växande ekosystem av färdiga Zeek-paket, allt från protokollanalysatorer till färdiga detektionsregler för specifika hotaktörer. Pakethanteraren zkg gör det enkelt att installera, uppdatera och ta bort dessa, ungefär på samma sätt som pip fungerar för Python eller npm för Node.js. Ett paket kan lägga till stöd för ett protokoll Zeek inte analyserar ur lådan, eller leverera färdiga skript som redan implementerar en viss detektionslogik, vilket sparar tid jämfört med att skriva om samma sak från grunden internt.

zkg refresh
zkg search intel
zkg install zeek/corelight/community-id
zkg list

Paketet community-id lägger till ett standardiserat flödes-id i loggarna, vilket underlättar korrelation mellan Zeek och andra verktyg som stödjer samma standard, exempelvis vissa IDS-lösningar och kommersiella SIEM-plattformar. Testa alltid nya paket i en icke-produktionsmiljö innan de rullas ut brett, eftersom vissa community-paket uppdateras mer sällan än kärnprojektet.

Steg 13: Integrera Zeek med SIEM och threat intelligence

Zeek-loggar blir mest värdefulla när de korreleras med data från andra källor: endpoint-loggar, brandväggshändelser och känd hotinformation. Ett vanligt mönster är att skicka loggarna vidare i JSON-format till ett centralt system.

# Aktivera JSON-loggning i local.zeek
echo 'redef LogAscii::use_json = T;' >> /opt/zeek/share/zeek/site/local.zeek
sudo /opt/zeek/bin/zeekctl deploy

Med JSON-formatet aktiverat kan loggarna skickas vidare via exempelvis Filebeat till en SIEM-lösning som Wazuh, där de korreleras med andra händelser i miljön. En minimal Filebeat-konfiguration som pekar mot Zeeks loggkatalog ser ut ungefär så här:

# /etc/filebeat/filebeat.yml (utdrag)
filebeat.inputs:
  - type: log
    paths:
      - /opt/zeek/logs/current/*.log
    json.keys_under_root: true
    json.add_error_key: true

output.elasticsearch:
  hosts: ["10.10.0.20:9200"]
  index: "zeek-logs-%{+yyyy.MM.dd}"

Vill ni gå ett steg längre kan Zeeks intel-ramverk laddas med indikatorer från en threat intelligence-plattform, till exempel MISP, så att kända skadliga IP-adresser och domäner flaggas automatiskt när de dyker upp i trafiken. Den kombinationen, rå nätverksdata plus extern hotinformation, är i praktiken vad som skiljer en grundläggande installation från en som faktiskt bidrar till incidenthantering.

Steg 14: Optimera prestanda för högtrafiknät

En enda Zeek-process räcker sällan till på nätverk med hög trafikvolym. Lösningen är att köra Zeek i kluster-läge, där en manager-process, en eller flera loggers och flera worker-processer delar upp arbetet mellan sig utifrån flödesbaserad lastbalansering.

# /opt/zeek/etc/node.cfg (kluster-läge)
[manager]
type=manager
host=10.10.0.10

[logger]
type=logger
host=10.10.0.10

[worker-1]
type=worker
host=10.10.0.11
interface=eth1

[worker-2]
type=worker
host=10.10.0.12
interface=eth1

Antalet workers bör motsvara antalet CPU-kärnor tillgängliga för paketbearbetning, minus de kärnor som reserveras för manager och logger. Testa gärna kapaciteten stegvis: börja med två workers, mät CPU- och minnesbelastning under en representativ trafiktopp, och skala upp därefter. Att kasta för många resurser på klustret från början gör det svårare att identifiera var den faktiska flaskhalsen ligger.

Som grov tumregel klarar en modern worker-kärna någonstans mellan några hundra Mbit/s och ett par Gbit/s beroende på hur komplex trafikmixen är, TLS-tung webbtrafik är dyrare att analysera än enkel DNS-trafik. Ett nätverk med 10 Gbit/s totalt genomflöde kräver därför sannolikt fyra till åtta workers snarare än en enda process, och det är bättre att provisionera lite för mycket kapacitet från start än att upptäcka tappade paket mitt under en pågående incident. Håll även koll på minnesanvändningen per worker, eftersom protokollanalys av många samtidiga sessioner kan bli minneskrävande på riktigt trafiktunga nät.

Praktiskt exempel: fånga DNS-tunnling och misstänkt C2-trafik

För att knyta ihop hela guiden till ett komplett, fungerande projekt: bygg en liten detektionspipeline som kombinerar tre saker ni redan har på plats efter föregående steg. Skriptet för långa DNS-svar (steg 11), JSON-loggning (steg 13) och notice.log som central larmkälla.

# Enkel övervakningsloop som visar nya larm i realtid
tail -F /opt/zeek/logs/current/notice.log | while read -r line; do
    echo "[$(date '+%H:%M:%S')] NYTT LARM: $line"
done

Kör sedan ett kontrollerat test genom att göra en DNS-slagning med ett artificiellt stort svar (till exempel via ett testverktyg i en labbmiljö, aldrig mot produktionsdomäner) och bekräfta att larmet dyker upp i terminalen inom några sekunder. Fungerar det, har ni ett minimalt men fullt fungerande övervakningsflöde: trafik in, protokollanalys, anpassad detektionslogik och ett larm som går att agera på. Härifrån är det en fråga om att lägga till fler regler, koppla in fler datakällor och skala upp klustret i takt med att nätverket växer.

Tre verkliga användningsfall från säkerhetsteam

Teori är en sak, men det blir tydligare varför man lägger tid på Zeek när man ser hur andra team faktiskt använder det i vardagen. Här är tre typiska scenarier som återkommer i diskussioner om nätverksövervakning inom incidenthantering.

Scenario 1: tidiga tecken på ransomware-förberedelse

Innan ett ransomware-angrepp krypterar filer brukar angriparen först röra sig lateralt i nätverket, ofta via SMB-protokollet, för att hitta filservrar och backuper värda att kryptera. Den rörelsen syns i Zeeks smb-loggar som ett plötsligt hopp i antalet interna anslutningar från en enskild klient till flera olika servrar under kort tid, ett mönster en vanlig slutpunktslösning inte alltid fångar eftersom varje enskild anslutning ser normal ut isolerad. Ett Zeek-skript som räknar unika interna destinationer per källa under ett tidsfönster kan flagga just den typen av spridning innan krypteringen ens hinner börja.

Scenario 2: dataexfiltrering via DNS-tunnling

DNS är ett av de protokoll som oftast tillåts passera brandväggar utan större granskning, vilket gör det attraktivt för att smuggla ut data i små bitar kodade i subdomännamn. Skriptet från steg 11 i den här guiden, som flaggar ovanligt stora DNS-svar, är en enkel startpunkt, men ett mer träffsäkert mönster är att titta på volymen unika subdomäner som slås upp mot samma överordnade domän under kort tid. En legitim tjänst slår sällan upp tusentals unika subdomäner i timmen, medan ett exfiltreringsverktyg ofta gör precis det.

Scenario 3: nätverksinventering inför en revision

Långt ifrån alla användningsfall handlar om att jaga en aktiv angripare. Många team sätter upp Zeek enbart för att äntligen få svar på frågan vilka tjänster som faktiskt pratar med vilka andra tjänster i nätverket, något som blir allt viktigare inför en NIS2-revision eller ett internt säkerhetsarbete. Genom att låta Zeek gå några veckor i passivt läge och sedan analysera conn.log i sin helhet, går det att bygga en faktisk karta över trafikmönster snarare än att förlita sig på en föråldrad nätverksdokumentation som ingen underhållit på länge.

GDPR och lagring av nätverksloggar i Sverige och Norden

En sak som ofta glöms bort i entusiasmen över nya loggkällor är att conn.log, dns.log och http.log innehåller personuppgifter i GDPR:s mening. IP-adresser räknas som personuppgifter så snart de går att koppla till en identifierbar person, vilket i praktiken gäller det mesta av trafiken från anställdas arbetsstationer. Innan ni rullar ut Zeek brett i en svensk eller nordisk organisation bör IT-säkerhet och juridik eller dataskyddsombud komma överens om lagringstid, åtkomstbegränsningar och syfte med loggningen, precis som för andra säkerhetsloggar ni redan hanterar.

I praktiken brukar det räcka att dokumentera loggningen som en del av den lagliga grunden “berättigat intresse” för nätverkssäkerhet, sätta en rimlig lagringstid (många svenska organisationer landar mellan 30 och 180 dagar beroende på verksamhetens riskprofil och sektorsspecifika krav), och begränsa åtkomsten till loggarna till den personal som faktiskt arbetar med incidenthantering. Zeeks egen konfiguration påverkar inte dessa juridiska krav automatiskt, så loggrotation och rensningsrutiner (samma sak som nämns som ett vanligt nybörjarmisstag nedan) behöver kopplas till er faktiska policy, inte bara till hur mycket diskutrymme servern råkar ha.

Verksamheter som omfattas av NIS2 eller andra sektorsspecifika säkerhetskrav har ofta ytterligare skäl att spara nätverksloggar under en längre period, eftersom en fullständig incidentutredning i efterhand kräver historisk data. Balansen mellan att spara tillräckligt länge för att kunna utreda en incident och att inte spara längre än nödvändigt av integritetsskäl är precis den typ av avvägning som bör göras medvetet, snarare än att bara låta standardinställningarna styra.

Vanliga nybörjarmisstag att undvika

De flesta problem med en ny Zeek-installation går att spåra tillbaka till ett fåtal återkommande misstag. Går ni igenom listan nedan innan ni driftsätter i produktion sparar ni sannolikt flera timmars felsökning senare.

  • Fel gränssnitt i node.cfg. Att peka Zeek mot förvaltningsgränssnittet istället för SPAN-porten är det absolut vanligaste felet, och det ger tomma eller meningslösa loggar utan några felmeddelanden.
  • Glömd konfiguration av networks.cfg. Utan korrekta interna IP-intervall blir intern trafik felaktigt klassad som extern, vilket ger falska positiva larm och förvirrande loggar.
  • Att köra Zeek som root i onödan. Processen behöver särskilda rättigheter för att läsa nätverksgränssnittet, men bör inte köras med fullständiga root-rättigheter permanent i produktion.
  • Ingen loggrotation eller lagringsplan. conn.log och dns.log växer snabbt på trafiktunga nät, och utan rotation och rensning fylls disken förr eller senare, vilket stoppar loggningen helt.
  • Att installera community-paket utan test. Tredjepartspaket via zkg uppdateras i olika takt, och ett trasigt paket i produktion kan få hela sensorn att sluta logga.
  • Att förvänta sig färdiga larm direkt. Standardinstallationen ger grundläggande loggning, men verkligt värde kommer först när ni skriver egna regler och kopplar in hotinformation.

Felsökning: vanliga problem och lösningar

ProblemTrolig orsakLösning
zeekctl status visar “not running”Konfigurationsfel eller saknad behörighet på gränssnittetKör zeekctl check och läs loggar i /opt/zeek/spool/
Tomma loggfiler efter startFel gränssnitt angivet i node.cfgVerifiera med ip link och jämför mot SPAN-portens faktiska namn
“command not found: zeek”PATH-variabeln pekar inte mot /opt/zeek/binKör source ~/.bashrc eller lägg till sökvägen permanent
Hög CPU-belastning på en enda kärnaStandalone-läge på ett nät med hög trafikvolymByt till kluster-läge med flera workers enligt steg 14
zkg install misslyckas med beroendefelSaknade Python-bibliotek eller föråldrad zkg-versionKör zkg refresh och uppdatera Python-beroenden med pip
Diskutrymmet tar slut snabbtIngen loggrotation konfigureradAktivera zeekctl:s inbyggda arkivering och sätt en rensningspolicy
Notice.log är helt tomtInga detektionsskript laddade utöver standardKontrollera local.zeek och bekräfta att @load-rader är korrekta
JSON-loggar syns inte i SIEMInsamlingsagenten pekar på fel katalog eller formatBekräfta sökväg till /opt/zeek/logs/current/ och att use_json är aktiverat
Byggfel vid “make” från källkodSaknat systembibliotek från steg ettLäs felmeddelandet noga och installera det specifika paketet som saknas

Hamnar ni i ett problem som inte täcks ovan, är /opt/zeek/spool/ nästan alltid rätt ställe att börja gräva. Där hamnar zeekctl:s egna drifts- och felloggar, separat från de faktiska trafikloggarna i /opt/zeek/logs/current/. Communityforumet på community.zeek.org är dessutom aktivt bevakat av både utvecklare och erfarna användare, vilket gör det till en bra resurs för problem som är specifika för just er nätverkskonfiguration.

Avancerade tips för säkerhetsteam

När grundinstallationen är stabil finns det flera sätt att höja ribban ytterligare. Ett är att aktivera filextraktion så att Zeek automatiskt sparar filer som laddas ner över HTTP eller SMB, vilket gör det möjligt att i efterhand köra dem genom en sandlåda eller jämföra hashvärden mot kända hotindikatorer. Ett annat är att bygga dashboards ovanpå loggarna, snarare än att läsa rådata direkt, vilket gör det lättare för hela teamet att följa trender över tid och inte bara reagera på enskilda larm.

Ett tredje tips handlar om att koppla ihop Zeeks nätverkssynlighet med containermiljöer. Kör ni redan runtime-övervakning på Kubernetes-nivå med ett verktyg som Falco, ger Zeek ett kompletterande lager: Falco ser vad som händer inuti containrarna, medan Zeek ser vad som faktiskt lämnar och når nätverket. Tillsammans ger de en betydligt mer heltäckande bild av en incident än vad endera verktyget klarar på egen hand. Slutligen: dokumentera era egna Zeek-skript ordentligt. Ett halvår senare är det lätt att glömma varför en viss regel skrevs, och en kort kommentar om vilket hot regeln adresserar sparar mycket tid vid framtida felsökning.

Ett fjärde tips är att koppla notice.log till samma system ni redan använder för ärendehantering, snarare än att låta larmen bara ligga i en loggfil som ingen tittar på förrän något gått fel. Skickar ni larmen vidare till en plattform för incidenthantering, blir varje larm ett spårbart ärende med tilldelad ägare och status, istället för en rad text som riskerar att drunkna bland tusentals andra loggrader. Det är ofta skillnaden mellan att ett tidigt varningstecken faktiskt undersöks samma dag, och att det upptäcks först veckor senare vid en efterhandsgranskning.

Enligt Zeek-projektets egen beskrivning är try.zeek.org “our interactive tutorial that allows you to get a glimpse of what it’s like to use Zeek without installing anything”, vilket är ett bra ställe att testa nya skriptidéer innan de rullas ut på en riktig sensor. Läs mer på Zeeks officiella nedladdningssida och i projektets blogg, där releasen av 9.0 beskrivs i detalj.

Vill ni jämföra Zeeks synsätt med ett signaturbaserat alternativ som komplement snarare än ersättning, är Suricata värt att titta på. Många säkerhetsteam kör faktiskt båda parallellt: Suricata för snabba signaturlarm, Zeek för djupare protokollkontext och hotjakt i efterhand. Vill du strukturera detektionslogiken kring kända angreppstekniker kan MITRE ATT&CK användas som referensram när ni bestämmer vilka Zeek-skript som bör skrivas först.

Vanliga frågor

Är Zeek gratis att använda i produktion?

Ja. Zeek är öppen källkod och kan installeras och köras utan licenskostnad, oavsett hur många sensorer eller workers ni driftsätter. Kommersiella leverantörer erbjuder support och färdiga applianser byggda på Zeek, men grundverktyget kostar inget.

Vad är skillnaden mellan Zeek och ett vanligt IDS som Suricata?

Signaturbaserade IDS-verktyg letar primärt efter kända mönster i trafiken. Zeek fokuserar istället på att bygga rika, strukturerade loggar av protokollbeteende som analytiker och skript sedan kan bearbeta, vilket gör det starkare för hotjakt och efterhandsanalys snarare än enbart realtidslarm.

Behöver jag ett dedikerat kluster för att komma igång?

Nej. En standalone-installation på en enda server räcker gott och väl för att lära sig grunderna och för mindre nätverk. Kluster-läge blir relevant först när trafikvolymen börjar överstiga vad en enskild process hinner bearbeta.

Hur ofta uppdateras Zeek?

Projektet har haft en aktiv releasetakt under 2026, med utvecklingsuppdateringar och release candidates som föregick den slutliga 9.0.0-versionen i mitten av september. LTS-versioner är tänkta att få säkerhetsuppdateringar under en längre period än ordinarie mellanversioner.

Kan Zeek analysera krypterad trafik direkt?

Nej, Zeek dekrypterar inte trafik den inte har nycklar till. Det den gör är att analysera metadata kring den krypterade sessionen, till exempel TLS-version, certifikatinformation och anslutningsmönster, vilket ofta räcker för att flagga misstänkt beteende utan att se det faktiska innehållet.

Fungerar Zeek tillsammans med molnmiljöer?

Ja, förutsatt att ni kan spegla trafiken från den virtuella nätverksmiljön till en instans som kör Zeek. De flesta större molnleverantörer erbjuder någon form av trafikspegling som kan användas för det ändamålet, men konfigurationen skiljer sig åt mellan plattformar.

Vilka loggfiler bör jag prioritera om jag bara har tid att granska ett fåtal?

Börja med notice.log för färdiga larm, conn.log för översikt över trafikmönster och dns.log för att fånga tunnling och kontakt med skadliga domäner. Dessa tre täcker en stor del av de vanligaste hotscenarierna redan från start.

Kan jag köra Zeek parallellt med Wireshark?

Absolut, och de kompletterar varandra bra. Zeek ger den löpande, aggregerade bilden över lång tid, medan Wireshark är bättre lämpat för att gräva djupt i en enskild session eller ett specifikt paketflöde när ni väl har identifierat något värt att undersöka närmare.