Wireshark Tutorial 2026: Fang Netværkstrafik I 12 Trin

Den 5. oktober 2026 bekræftede det danske digitaliseringsministerium, at omkring 8,8 millioner CPR-poster var blevet misbrugt af en leverandør med legitim adgang til registret. Flere opsamlinger af hændelsen i de følgende uger, blandt andet DanSec Dailys gennemgang af sagen, pegede på, at tilgangen skete via en ekstern aktørs legitime forespørgselsrettigheder snarere end et klassisk indbrud. En af de konkrete advarsler fra efterfølgende sikkerhedsbriefinger var simpel: hvis man havde overvåget netværkstrafikken til de bagvedliggende systemer, ville de unormalt høje forespørgselsmængder være synlige lang før lækken blev offentlig. Det er præcis den opgave, Wireshark er bygget til at løse.

Dette er en praktisk, trin-for-trin guide til at installere, konfigurere og bruge Wireshark 4.6.9 til netværksanalyse, trafikovervågning og de første skridt i en incident response. Guiden er skrevet, så du kan følge den uden forudgående erfaring med pakkeanalyse, men stadig få konkrete, avancerede teknikker med i bagagen, som erfarne sikkerhedsanalytikere rent faktisk bruger i felten.

Du lærer at fange pakker korrekt, bygge capture- og display-filtre, følge en hel TCP-samtale, analysere DNS- og TLS-trafik, opdage mistænkelige mønstre i databasetrafik, og automatisere analysen med kommandolinjeværktøjet TShark. Vi bygger desuden en trafik-baseline, ser kort på de juridiske rammer for overvågning i en dansk kontekst, og samler til sidst det hele i et komplet, lille overvågningsprojekt, som du kan køre på din egen maskine eller server.

Hvad er Wireshark, og hvorfor er det relevant i 2026

Wireshark er et open source-værktøj til pakkefangst og netværksanalyse, der har eksisteret siden 1998 (dengang under navnet Ethereal). Værktøjet opfanger rå netværkstrafik, dekoder hver protokol i hver pakke, og viser resultatet i en struktureret, søgbar brugerflade. Hvor et IDS, en firewall eller en EDR-løsning giver dig en alarm, giver Wireshark dig beviset: hvilken pakke, hvilket indhold, hvilket tidspunkt og hvilken afsender og modtager.

Den nyeste version er Wireshark 4.6.9, udgivet 8. oktober 2026, parallelt med den langsigtede supportgren 4.4.19, udgivet samme dag. Begge udgivelser retter en række fejl i protokol-dissektorer, heriblandt en nedbrudsfejl i ZigBee ZCL-dissektoren (CVE-2026-95391), en nedbrudsfejl i SCTP-dissektoren (CVE-2026-95389) og en uendelig løkke i TTL-filparseren (CVE-2026-95386). Det er et godt eksempel på, hvorfor du altid bør køre den nyeste stabile version: selv et analyseværktøj kan blive et angrebsmål, hvis det bruges til at åbne en ondsindet konstrueret pakkefangst.

Wireshark bruges typisk til tre ting: fejlfinding af netværksproblemer, undervisning i protokoller, og sikkerhedsanalyse. Det sidste punkt er særligt relevant i den nordiske kontekst lige nu. Når en virksomhed oplever unormalt mange forbindelser til en database, et pludseligt stort dataudtræk, eller trafik til en ukendt ekstern server, er en pakkefangst ofte den hurtigste måde at bekræfte eller afkræfte, om der er tale om et reelt angreb. Wireshark kan ikke bevise, præcis hvilke data der blev læst i en krypteret session, men det kan afsløre forbindelsesmønstre, volumen og timing, som sammen med database- og adgangslogge giver et fuldt billede.

Et IAM- og sikkerhedsbriefing fra oktober 2026 peger på, at CISA i samme periode tilføjede flere kritiske sårbarheder til sin katalog over aktivt udnyttede sårbarheder, heriblandt en autentifikationsomgåelse i Cisco Catalyst SD-WAN Manager med en CVSS-score på 9,8. Den type sårbarheder bliver ofte udnyttet, længe før en organisation selv opdager det, og netop her er pakkeanalyse værdifuld: den fanger netværksadfærden, uafhængigt af om det bagvedliggende system allerede har logget hændelsen korrekt. I praksis betyder det, at Wireshark fungerer som et sidste sikkerhedsnet, når logning fra applikationer, databaser eller sky-tjenester er mangelfuld, forsinket, eller slet ikke er sat op til at fange netop den type adfærd, en angriber udviser.

Forudsætninger og systemkrav

Før du går i gang, skal du bruge følgende:

En computer med Windows 10/11, macOS 13 eller nyere, eller en gængs Linux-distribution (Ubuntu 24.04 LTS eller nyere er brugt i eksemplerne)
Administrator- eller root-rettigheder til installation og pakkefangst
Wireshark version 4.6.9 (den aktuelle stabile udgivelse) eller 4.4.19 (langsigtet support)
Mindst 4 GB RAM og 2 GB ledig diskplads til installation og mindre pakkefangster
Et kablet eller trådløst netværksinterface, du har lovlig ret til at overvåge
Grundlæggende kendskab til TCP/IP, DNS og HTTP er en fordel, men ikke et krav

En vigtig juridisk bemærkning: du må kun fange trafik på netværk og systemer, du selv ejer, administrerer, eller har skriftlig tilladelse til at overvåge. At opsnappe andres trafik uden samtykke kan være strafbart efter straffelovens bestemmelser om brud på kommunikationshemmeligheden, uanset hvor teknisk enkelt det er at gøre med dette værktøj.

Trin 1: Installer Wireshark 4.6.9

Download den nyeste installer direkte fra Wiresharks officielle hjemmeside, og undgå tredjeparts-downloadsider, da pakkefangstværktøjer er et oplagt mål for ondsindede installere. På Windows kører du den downloadede .exe-fil og accepterer installation af Npcap, som er driveren, der gør det muligt for Wireshark at fange pakker på netværkskortet.

På macOS bruger du .dmg-filen og installerer samtidig ChmodBPF-komponenten, der giver din brugerkonto adgang til at fange pakker uden at skulle køre som root hver gang. På Linux installerer du typisk via pakkehåndteringen:

sudo apt update
sudo apt install wireshark

# Under installationen bliver du spurgt, om ikke-root-brugere
# skal kunne fange pakker. Svar "Yes" hvis du vil undgå sudo hver gang.

Bekræft, at installationen lykkedes, og at du har den rigtige version, ved at køre:

wireshark --version
# Forventet output (eksempel):
# Wireshark 4.6.9 (v4.6.9-0-g...)
# Copyright 1998-2026 Gerald Combs...

Hvis du på en ældre maskine eller en server uden grafisk miljø ikke kan installere den grafiske klient, kan du nøjes med at installere pakken tshark, som er kommandolinje-versionen og deler samme analysemotor. Vi kommer tilbage til TShark senere i artiklen.

Trin 2: Giv Wireshark rettigheder til pakkefangst

Pakkefangst kræver i udgangspunktet root- eller administratorrettigheder, fordi netværksinterfacet skal sættes i “promiscuous mode” for at fange al trafik, ikke kun den, der er adresseret direkte til din maskine. At køre hele Wireshark som root er en dårlig idé: hvis en ondsindet pakke udnytter en fejl i en protokol-dissektor, kører den kode med fulde rettigheder. Den sikre løsning er at lade kun selve pakkefangsten køre med forhøjede rettigheder, mens resten af programmet kører som normal bruger.

På Linux gøres det ved at tilføje din bruger til gruppen wireshark:

sudo usermod -aG wireshark $USER
# Log ud og ind igen, så gruppemedlemskabet tager effekt
groups
# Forventet output inkluderer nu: ... wireshark ...

På Windows og macOS er dette allerede håndteret af Npcap og ChmodBPF, som blev installeret i trin 1. Du kan derfor normalt starte Wireshark som din almindelige bruger på alle tre platforme, efter rettighederne er sat korrekt op én gang.

Trin 3: Vælg netværksinterface og optag din første trafik

Når du åbner Wireshark, viser startskærmen en liste over tilgængelige netværksinterfaces, hver med en lille, levende graf over trafikken lige nu. Det gør det nemt at identificere det interface, der faktisk har trafik på, hvis du er i tvivl, om det er dit kablede eller trådløse kort.

Dobbeltklik på det interface, du vil overvåge, for at starte optagelsen med det samme
Generér nu lidt trafik: åbn en browser og gå ind på en hjemmeside
Vend tilbage til Wireshark, og du vil se pakker løbe forbi i pakkelisten i realtid
Klik på det røde stop-ikon i værktøjslinjen for at afslutte optagelsen

Gem optagelsen med Ctrl+S (eller Cmd+S på macOS) i formatet .pcapng, som er standardformatet siden Wireshark 1.8 og det format, der bruges af stort set alle moderne netværksanalyseværktøjer, inklusive TShark, Zeek og tcpdump.

Trin 4: Naviger brugerfladen

Wiresharks vindue er delt i tre paneler, og at forstå dem er nøglen til effektiv analyse:

Pakkelisten (øverst): en linje per pakke med nummer, tidsstempel, kilde-IP, destinations-IP, protokol og et kort resumé
Pakkedetaljer (midten): et udfoldeligt træ, der viser hvert protokollag i den valgte pakke, fra Ethernet-rammen op til applikationslaget
Byte-visningen (nederst): den rå hexadecimale repræsentation af pakken, med det felt, du har valgt i midten, markeret

Farvekodningen i pakkelisten er ikke kosmetisk. Lyseblå linjer er typisk TCP-trafik, lyslilla er UDP, sort med rød tekst markerer fejl som fejlslagne TCP-tjeksummer, og mørkegrå markerer typisk TCP-retransmissioner. Når du analyserer en mistænkelig session, er det ofte de sorte og mørkegrå linjer, der fortæller historien først.

Statistics-menuen i toppen er en genvej, mange begyndere overser. “Protocol Hierarchy” giver et øjebliksbillede af, hvor stor en andel af den samlede fangst der er HTTP, DNS, TLS og så videre, hvilket er en hurtig måde at få en fornemmelse af, om trafikken ser normal ud. “Endpoints” lister alle unikke IP-adresser, der optræder i fangsten, sammen med hvor mange pakker og bytes hver af dem har sendt og modtaget. Begge dele er nyttige, før du overhovedet begynder at skrive filtre, fordi de giver dig et overblik over, hvad du faktisk kigger på.

Trin 5: Capture-filtre med BPF-syntaks

Capture-filtre bestemmer, hvilke pakker der overhovedet bliver fanget og gemt, før Wireshark viser dem. De bruger BPF-syntaks (Berkeley Packet Filter), som er den samme syntaks, tcpdump bruger. Fordelen ved et capture-filter er, at det reducerer mængden af data, du skal gennemgå, og sparer diskplads og CPU på lange optagelser.

# Fang kun trafik til og fra en specifik vært
host 192.0.2.10

# Fang kun trafik på et helt undernet
net 192.0.2.0/24

# Fang kun HTTPS-trafik (port 443)
tcp port 443

# Fang kun DNS-trafik
udp port 53

# Udelad SSH-trafik, så du ikke fanger din egen fjernforbindelse
not port 22

# Kombinér: trafik fra en specifik klient til en database-port
src host 192.0.2.10 and dst port 5432

Ulempen ved capture-filtre er, at de ikke kan bruge Wiresharks fulde protokolfelter. Du kan filtrere på IP og port, men ikke på for eksempel et specifikt HTTP-headerfelt. Til den slags detaljeret analyse bruger du i stedet display-filtre efter optagelsen.

Trin 6: Display-filtre og Wireshark-syntaks

Display-filtre ændrer kun, hvad der vises i pakkelisten, og fjerner ikke data fra den underliggende fangst. Det betyder, at du altid kan nulstille filteret og se alt igen. Display-filtre bruger Wiresharks eget filtersprog, som er langt mere udtryksfuldt end BPF, fordi det kender hvert dekodet felt i hver protokol.

# Vis kun trafik til eller fra en bestemt IP
ip.addr == 192.0.2.10

# Vis kun trafik på en bestemt TCP-port
tcp.port == 443

# Vis alle DNS-forespørgsler
dns

# Vis kun HTTP-forespørgsler (ikke svar)
http.request

# Vis TLS handshake-pakker, nyttigt til certifikatanalyse
tls.handshake

# Find kun SYN-pakker (nye forbindelsesforsøg) uden ACK
tcp.flags.syn == 1 && tcp.flags.ack == 0

# Kombinér kilde-IP og destinationsport, til databaseanalyse
ip.src == 192.0.2.10 && tcp.dstport == 5432

Skriv filteret i den grønne filterbjælke over pakkelisten. Hvis boksen bliver grøn, er syntaksen korrekt. Bliver den rød, er der en fejl i udtrykket. Et godt trick er at højreklikke på et felt i pakkedetaljerne og vælge “Apply as Filter”, hvorefter Wireshark selv skriver det korrekte filterudtryk for dig, hvilket er den nemmeste måde at lære syntaksen på i praksis.

Trin 7: Følg samtaler med Follow TCP Stream

Når du har fundet en interessant pakke i en TCP-session, er næste skridt næsten altid at se hele samtalen i sammenhæng, ikke bare den enkelte pakke. Højreklik på pakken, vælg “Follow”, og derefter “TCP Stream”. Wireshark samler nu alle pakker i den session og viser dem som en sammenhængende tekst, med klientens data i rødt og serverens svar i blåt.

Dette er særligt nyttigt, når du undersøger ukrypteret trafik som almindelig HTTP eller FTP, hvor du direkte kan læse headers, forespørgsler og svartekst. For krypteret trafik som HTTPS og TLS 1.3 kan du stadig følge strømmen for at se metadata som timing og volumen, men selve indholdet kræver, at du har adgang til den private nøgle eller en TLS-dekrypteringsnøgle, som typisk kun er tilgængelig i kontrollerede testmiljøer.

Trin 8: Analysér DNS, HTTP og TLS-trafik

DNS er ofte det første sted, et kompromitteret system afslører sig selv, fordi malware typisk skal slå domænenavne op, før den kan kontakte en kontrolserver. Brug filteret dns til at se alle opslag, og kig efter domæner, der virker tilfældigt genererede, usædvanligt lange, eller som peger på nyregistrerede domæner.

# Find DNS-svar med usædvanligt mange registrerede A-poster,
# et kendt mønster ved fast-flux og visse C2-infrastrukturer
dns.flags.response == 1 && dns.count.answers > 5

# Find HTTP-forespørgsler til en specifik User-Agent, der kan
# indikere automatiserede scripts snarere end en browser
http.user_agent contains "python"

# Find TLS-handshakes, hvor certifikatets udsteder er selvsigneret
# eller afviger fra det forventede, nyttigt ved mistanke om MITM
tls.handshake.type == 11

For HTTP-trafik viser filteret http.request alle udgående forespørgsler. Kig efter mønstre som mange forespørgsler til samme sti i hurtig rækkefølge, hvilket kan indikere et script, der tester eller skraber et endepunkt, i modsætning til en menneskelig bruger, der klikker rundt i en browser.

Trin 9: Opdag bulk-forespørgsler og anomal databasetrafik

Den type incident, der ramte det danske CPR-register, hvor rapporter beskriver omkring 14 millioner automatiserede opslag over en periode på 21 dage, er præcis den slags mønster, en pakkefangst kan hjælpe med at afsløre tidligt, selv før det bliver et offentligt kendt databrud. Databasetrafik går typisk over velkendte porte: PostgreSQL på 5432, MySQL på 3306, Microsoft SQL Server på 1433 og Oracle på 1521.

# Vis al trafik til en PostgreSQL-server
tcp.port == 5432

# Vis kun nye forbindelser (SYN-pakker) til databaseporten,
# nyttigt til at tælle, hvor mange separate sessioner der åbnes
tcp.port == 5432 && tcp.flags.syn == 1 && tcp.flags.ack == 0

# Find usædvanligt store svar fra databasen, som kan indikere
# et stort dataudtræk i stedet for en normal enkelt-postforespørgsel
tcp.port == 5432 && tcp.len > 4000

Vigtigt: Wireshark kan vise dig, at én klient pludselig åbner langt flere forbindelser end normalt, eller at svarstørrelserne vokser markant, men det kan ikke, i en krypteret session, vise dig selve SQL-forespørgslen eller hvilke specifikke poster der blev læst. Den slags detektion skal derfor altid kombineres med databasens egne audit-logs, API-logs og adgangskontrol-hændelser, for at få det fulde billede af, hvad der faktisk blev tilgået.

Trin 10: Automatisér med TShark fra kommandolinjen

TShark er Wiresharks kommandolinje-udgave og deler samme dekodnings-motor og filtersyntaks som den grafiske klient. Det gør TShark ideel til at automatisere analyse, køre på servere uden skrivebordsmiljø, og til at integrere pakkefangst i scripts og overvågningspipelines.

# Fang 60 sekunders trafik og gem til en fil
tshark -i eth0 -a duration:60 -w optagelse.pcapng

# Læs en gemt fangst og vis kun DNS-trafik
tshark -r optagelse.pcapng -Y "dns"

# Tæl antal forbindelser per kilde-IP til en database-port,
# nyttigt til hurtigt at identificere en klient med usædvanlig volumen
tshark -r optagelse.pcapng -Y "tcp.port == 5432 && tcp.flags.syn == 1" \
  -T fields -e ip.src | sort | uniq -c | sort -rn

Eksempel på output fra den sidste kommando:

   1842 198.51.100.77
     34 203.0.113.12
     12 192.0.2.44

Her springer tallet 1.842 forbindelser fra en enkelt IP-adresse direkte i øjnene, sammenlignet med de øvrige klienter, der ligger under 40. Det er netop den slags outlier, der i praksis kickstarter en incident response, længe før nogen har bekræftet, om det er et legitimt batch-job eller et tegn på misbrug.

Trin 11: Byg et komplet overvågningsprojekt

Lad os samle det hele til et lille, men komplet, fungerende projekt: et shell-script, der kører periodisk, fanger trafik på et interface, og sender en advarsel, hvis en enkelt kilde-IP overskrider en grænse for antal nye databaseforbindelser inden for et givet tidsvindue.

#!/bin/bash
# bulk-query-watch.sh
# Overvåger nye forbindelser til en databaseport og advarer
# hvis en enkelt kilde-IP overstiger en tærskelværdi.

INTERFACE="eth0"
DB_PORT="5432"
DURATION="300"          # sekunder per overvågningsvindue
THRESHOLD="500"         # maks. nye forbindelser per kilde-IP
OUTFILE="/tmp/dbwatch_$(date +%s).pcapng"

tshark -i "$INTERFACE" -a duration:"$DURATION" \
  -f "tcp port $DB_PORT" -w "$OUTFILE" 2>/dev/null

tshark -r "$OUTFILE" \
  -Y "tcp.port == $DB_PORT && tcp.flags.syn == 1 && tcp.flags.ack == 0" \
  -T fields -e ip.src | sort | uniq -c | sort -rn | while read COUNT IP; do
    if [ "$COUNT" -ge "$THRESHOLD" ]; then
      echo "[ADVARSEL] $IP oprettede $COUNT nye forbindelser til port $DB_PORT i $DURATION sekunder" \
        | tee -a /var/log/dbwatch-alerts.log
    fi
done

rm -f "$OUTFILE"

Gem scriptet, gør det eksekverbart med chmod +x bulk-query-watch.sh, og sæt det op til at køre hvert femte minut via cron:

crontab -e
# Tilføj linjen:
*/5 * * * * /sti/til/bulk-query-watch.sh

Dette er naturligvis et forenklet eksempel og ingen erstatning for et dedikeret SIEM eller en platform som Zeek i produktionsmiljøer, men det illustrerer kernen i, hvad automatiseret trafikanalyse faktisk gør: tælle, sammenligne med en baseline, og råbe op, når noget afviger markant.

Trin 12: Eksportér beviser og dokumentér dine fund

Hvis din analyse peger på en reel sikkerhedshændelse, er dokumentation afgørende, både til den interne incident-rapport og til eventuel senere brug som bevis. Wireshark gør det nemt at eksportere præcis de pakker, der er relevante.

Anvend dit display-filter, så kun de relevante pakker er vist
Gå til File → Export Specified Packets, og vælg “Displayed” for kun at gemme de filtrerede pakker
Gem som .pcapng for at bevare alle metadata og kommentarer
Brug File → Export Packet Dissections til at gemme en læsbar tekstrapport som CSV eller ren tekst
Tilføj en pakke-kommentar (højreklik → Packet Comment) til nøglepakker, så andre analytikere forstår, hvorfor netop den pakke er markeret

Opbevar altid den originale, ufiltrerede fangst et sikkert sted, så den kan genanalyseres, hvis nye spørgsmål dukker op senere i en undersøgelse.

Byg en trafik-baseline, før du leder efter afvigelser

Et tal som “1.842 forbindelser fra én IP-adresse” er kun alarmerende, hvis du ved, hvad der er normalt for netop dit netværk. Et batch-job, der synkroniserer data hver nat, kan sagtens generere flere tusinde forbindelser uden at være et problem, mens samme tal fra en klient, der normalt kun laver 10-20 forespørgsler i timen, er en tydelig afvigelse. Derfor er det første skridt i en reel overvågningsopsætning ikke at jagte anomalier, men at opbygge en baseline for, hvad normal trafik ser ud som på dit netværk.

En praktisk måde at gøre det er at køre dit TShark-script fra tidligere i artiklen over flere dage, uden at reagere på resultaterne, og blot logge dem. Gennemgå derefter loggen og notér, hvilke IP-adresser der normalt har høj trafikvolumen, på hvilke tidspunkter af døgnet trafikken typisk topper, og hvilke databaseforbindelser der kommer fra forventede, interne systemer som applikationsservere eller rapporteringsværktøjer. Når du har denne baseline, kan du sætte en tærskelværdi, der ligger tydeligt over den normale variation, i stedet for at gætte på et rundt tal.

Et godt tommelfingerregel er at sætte den indledende tærskel til omkring tre gange den højeste observerede normale værdi, og derefter justere den ned over tid, i takt med at du opbygger mere erfaring med, hvad der reelt udløser falske positiver på dit netværk. Mangel på en baseline er en af de mest underspillede grunde til, at overvågningsprojekter ender med at blive slået fra igen efter få uger: hvis tærsklen er sat for lavt, drukner det reelle signal i falske alarmer, og teamet holder op med at tjekke dem.

Juridiske rammer for netværksovervågning i en dansk kontekst

At fange og analysere netværkstrafik rejser spørgsmål, der går videre end den tekniske opsætning. I en virksomhedssammenhæng er netværkstrafik ofte persondata i databeskyttelsesforordningens forstand, især hvis trafikken indeholder IP-adresser, der kan henføres til en identificeret person, brugernavne i klartekst, eller indhold fra ukrypterede protokoller. Det betyder, at en permanent, bred overvågning af al trafik på et firmanetværk som udgangspunkt kræver et klart retsgrundlag, typisk legitim interesse i IT-sikkerhed, kombineret med gennemsigtighed over for medarbejderne om, at overvågningen finder sted.

I praksis betyder det, at du bør have en skriftlig IT-sikkerhedspolitik, der beskriver, hvornår og hvorfor netværkstrafik kan blive fanget og analyseret, hvem der har adgang til de fangne data, og hvor længe de opbevares. Begræns adgang til optagne pakkefangster til de medarbejdere, der faktisk arbejder med sikkerhedsanalyse, og undgå at opbevare fulde fangster længere end nødvendigt for undersøgelsen. Hvis din organisation er omfattet af NIS2-direktivet, som gælder for en bred vifte af danske virksomheder fra efteråret 2024, er evnen til at dokumentere og undersøge sikkerhedshændelser, herunder via netværksanalyse, en del af de forventede tekniske og organisatoriske foranstaltninger.

Uden for arbejdspladsen er reglerne skarpere. At fange trafik på et offentligt Wi-Fi-netværk, en nabos router, eller et hjemmenetværk uden samtykke fra de øvrige brugere kan være strafbart, uanset hvor let det tekniske set er at gøre med et værktøj som Wireshark. God praksis er altid at øve sig i et isoleret testmiljø, for eksempel en virtuel maskine med sit eget virtuelle netværk, hvor du selv er den eneste bruger af trafikken.

Almindelige faldgruber

Her er de fejl, nye Wireshark-brugere oftest begår, og hvordan du undgår dem:

Forveksling af capture- og display-filtre: at skrive display-filter-syntaks (tcp.port == 443) i capture-filter-feltet giver en fejl, fordi capture-filtre kun forstår BPF-syntaks (tcp port 443)
At køre Wireshark som root hele tiden: dette udvider angrebsfladen unødigt, da en fejl i en dissektor dermed kører med fulde rettigheder, i stedet for kun at give fangst-rettigheder via grupper eller Npcap
At fange trafik uden tilladelse: selv på et firmanetværk kan det være et brud på interne politikker eller loven at overvåge kollegers trafik uden klar hjemmel
At forvente at kunne læse krypteret TLS-indhold uden nøgler: uden adgang til sessionsnøgler eller en kontrolleret MITM-opsætning viser Wireshark kun metadata for HTTPS-trafik, aldrig det krypterede indhold
At fange trafik uden et filter på et belastet netværk: dette kan generere gigabyte af data på minutter, fylde disken, og gøre analysen uoverskuelig
At ignorere “Follow Stream” og analysere pakke for pakke: det gør simpel fejlfinding unødigt langsom, når hele samtalen ofte fortæller historien på få sekunder
At stole blindt på navnet “promiscuous mode” som løsning på alt: på mange moderne switch-netværk ser dit interface alligevel kun trafik adresseret til dig selv, med mindre du har sat en SPAN-port eller netværks-TAP op til at spejle trafikken fra andre enheder
At glemme at nulstille display-filteret: et gammelt filter, der stadig står i filterbjælken, kan give det fejlagtige indtryk, at der ikke er mere trafik at analysere, selvom fangsten bare er filtreret væk

Fælles for de fleste af disse faldgruber er, at de opstår, fordi Wireshark viser en enorm mængde information på én gang. Løsningen er sjældent at lære flere funktioner, men at blive disciplineret omkring at starte bredt med statistik og filtre, og først derefter dykke ned i enkeltpakker, når du allerede har en konkret hypotese at teste.

Fejlfinding: typiske problemer og løsninger

Selv med korrekt installation løber de fleste brugere ind i et par af disse problemer. Tabellen herunder samler de otte mest almindelige, men flere af dem er værd at uddybe, fordi den hurtige løsning i tabellen ikke altid forklarer, hvorfor fejlen opstår.

Problem	Sandsynlig årsag	Løsning
Interfacelisten er tom	Npcap/ChmodBPF er ikke installeret korrekt	Geninstallér Wireshark og vælg Npcap/ChmodBPF-komponenten eksplicit
“You don’t have permission to capture”	Din bruger er ikke i wireshark-gruppen (Linux)	Kør `sudo usermod -aG wireshark $USER`, log ud og ind igen
Ingen pakker vises trods aktiv trafik	Forkert interface valgt, eller capture-filter udelukker alt	Vælg interfacet med graf-aktivitet, og tøm capture-filterfeltet
Display-filterfeltet er rødt	Syntaksfejl eller forkert feltnavn	Brug autocomplete-forslagene, eller “Apply as Filter” på et felt du kender
Wireshark fryser under en stor fangst	For mange pakker holdes i hukommelsen samtidig	Brug ringbuffer-optagelse (Capture Options → Output → flere filer)
TLS-trafik kan ikke læses	Ingen sessionsnøgler tilgængelige	Konfigurér SSLKEYLOGFILE i browseren til testmiljøer, eller accepter at kun metadata er synlig
TShark-kommandoen findes ikke	Kun den grafiske pakke er installeret	Installér separat med `sudo apt install tshark`
Pakkefangst dropper pakker (“Dropped”)	CPU eller disk kan ikke følge med trafikmængden	Brug et snævrere capture-filter, eller fang på en dedikeret TAP/SPAN-port
Wireshark starter ikke efter opdatering	Gammel konfigurationsfil er inkompatibel	Omdøb profilmappen midlertidigt (~/.config/wireshark) og genstart

Pakkedrop er værd at nævne særskilt, fordi det er en af de fejl, der giver et fejlagtigt analyseresultat uden at give en tydelig fejlmeddelelse. Hvis Wireshark eller TShark dropper pakker under en travl fangst, kan det se ud som om en klient sender færre forespørgsler end den faktisk gør, hvilket kan skjule netop den type bulk-aktivitet, du leder efter. Tjek altid fangstens statistikpanel for antallet af droppede pakker, før du konkluderer noget baseret på volumen.

Problemet med TLS-dekryptering er en anden hyppig kilde til frustration. Mange forventer, at Wireshark “bare kan” dekryptere HTTPS, fordi det kan dekryptere ældre protokoller som WEP. Det kan det ikke uden en nøgle, og det er faktisk en styrke snarere end en svaghed: det betyder, at en angriber, der opsnapper din trafik, heller ikke kan læse den, hvis din TLS-opsætning er korrekt konfigureret.

Avancerede tips til erfarne analytikere

Når du har de grundlæggende trin på plads, er her nogle teknikker, der sparer tid i en rigtig undersøgelse:

Brug “Statistics → Conversations” til hurtigt at se, hvilke IP-par der har udvekslet mest data, sorteret efter byte-volumen, i stedet for at bladre gennem tusinder af enkeltpakker
Brug “Statistics → IO Graph” til at visualisere trafikmængden over tid og øjeblikkeligt se spidser, der afviger fra baseline
Gem ofte brugte display-filtre som “Filter Buttons” i værktøjslinjen, så du kan skifte mellem dem med ét klik under en live-analyse
Brug -2 flagget i TShark til to-pass-analyse, hvilket giver mere nøjagtig protokolgenkendelse på fragmenterede strømme
Kombinér Wiresharks dybde med Zeeks skala: lad Zeek generere strukturerede connection-logs over hele netværket kontinuerligt, og dyk ned i Wireshark kun på de specifikke sessioner, Zeek flager som interessante
Brug “File → Export Objects” til automatisk at udtrække filer, der er overført via HTTP eller SMB i en fangst, nyttigt ved undersøgelse af malware-download eller dataeksfiltrering
Opret et SSLKEYLOGFILE-miljøvariabel i et testmiljø, så browseren logger TLS-sessionsnøgler til en fil, som du derefter kan pege Wireshark på under Edit → Preferences → Protocols → TLS, hvis du har brug for at dekryptere din egen trafik til fejlfinding
Brug tastaturgenvejen Ctrl+Alt+Shift+T (eller menuen View → Time Display Format) til at skifte tidsstempler til “Seconds Since Previous Displayed Packet”, hvilket gør det langt nemmere at spotte pauser og bursts i en samtale

Ingen af disse tips kræver et opgraderet værktøj eller en dyrere licens. Wireshark er og bliver gratis og open source, og den funktionalitet, der adskiller en nybegynder fra en erfaren analytiker, ligger primært i, hvor hurtigt man kan gå fra “noget ser forkert ud” til en konkret, dokumenteret konklusion, ikke i hvilke knapper man trykker på.

Wireshark vs. tcpdump, TShark og Zeek

Ingen af disse værktøjer er reelt konkurrenter, de løser forskellige dele af samme opgave, og et velfungerende sikkerhedsteam bruger typisk flere af dem sammen: en sensor fanger trafikken, Zeek omdanner den til strukturerede logge i stor skala, TShark automatiserer udtræk af specifikke felter, og Wireshark bruges til den dybe, interaktive analyse af enkeltstående hændelser.

Værktøj	Type	Bedst til	Grafisk flade
Wireshark	Interaktiv pakkeanalysator	Dyb undersøgelse af specifikke sessioner og hændelser	Ja
tcpdump	Letvægts kommandolinje-fangst	Hurtig fangst på servere og fjernopkoblede systemer	Nej
TShark	Kommandolinje-analysator	Scriptet filtrering, feltudtræk og automatisering	Nej
Zeek	Netværksovervågningsplatform	Kontinuerlig logning og adfærdsdetektion i stor skala	Nej (eget logformat)

En typisk arbejdsgang i et moderne sikkerhedsteam ser derfor ofte ud som: sensor eller tcpdump fanger råtrafikken, Zeek eller et SIEM gør den første triage på tværs af hele netværket, TShark trækker specifikke felter ud til automatiseret rapportering, og Wireshark bruges, når et menneske skal forstå præcis, hvad der skete i én bestemt samtale.

Sikkerhed: nylige CVE’er og patch-anbefalinger

Wireshark selv er, ironisk nok, også et mål for sårbarhedsforskning, netop fordi det parser enorme mængder kompleks, uforudsigelig netværksdata fra potentielt ondsindede kilder. Wireshark-projektets udviklere peger selv på, at den seneste tids stigning i rapporterede fejl hænger sammen med en stigning i AI-assisterede sårbarhedsrapporter, der systematisk har fundet nedbrudsfejl i mindre brugte protokol-dissektorer.

Version 4.4.19 retter desuden en fejl i import af profiler, registreret som CVE-2026-96419, hvor en ondsindet konstrueret profilfil potentielt kan udnyttes til kodeudførelse. Den praktiske konsekvens er klar: behandl pakkefangster og importerede profiler fra ukendte kilder som utroværdigt input, hold altid Wireshark opdateret til nyeste version, og åbn fremmede fangster i et isoleret analysemiljø, især hvis fangsten stammer fra en formodet kompromitteret maskine.

Opdatér til 4.6.9 (nyeste gren) eller 4.4.19 (langsigtet support) så hurtigt som muligt
Abonnér på Wiresharks sikkerhedsrådgivninger for løbende at få besked om nye sårbarheder
Undgå at køre analysen på den samme maskine, der behandler produktionstrafik eller følsomme systemer
Deaktivér protokol-dissektorer, du ikke har brug for, under Edit → Preferences → Protocols, for at mindske angrebsfladen

Denne forsigtighed er en del af et bredere billede i 2026. En gennemgang fra pentestingfirmaet Secarma fra samme periode kobler det danske CPR-brud sammen med andre aktuelle trusler, heriblandt en zero-day-sårbarhed i Citrix NetScaler, og peger på et gennemgående mønster: svage adgangskontroller, forsinket patching og mangel på overvågning af forespørgselsmønstre går igen som de reelle rodårsager, langt oftere end avancerede, nye angrebstekniker. CISA har i samme periode tilføjet flere kritiske sårbarheder med CVSS-score op mod 9,8 og 10,0 til sin katalog over aktivt udnyttede sårbarheder, hvilket understreger, at patch-tempoet i mange organisationer stadig halter efter udnyttelsestempoet.

Ofte stillede spørgsmål

Er det lovligt at bruge Wireshark?
Ja, værktøjet selv er fuldt lovligt og open source. Det, der kan være ulovligt, er at overvåge netværkstrafik, du ikke har ret til at fange, for eksempel andres private kommunikation uden samtykke eller hjemmel.

Kan Wireshark læse indholdet i HTTPS-trafik?
Ikke uden videre. Wireshark viser metadata som IP-adresser, porte og tidspunkter for krypteret trafik, men kan kun vise det faktiske indhold, hvis du har adgang til sessionsnøglerne, typisk kun muligt i et kontrolleret testmiljø.

Hvad er forskellen på et capture-filter og et display-filter?
Et capture-filter bestemmer, hvilke pakker der overhovedet bliver gemt under optagelsen, og bruger BPF-syntaks. Et display-filter ændrer kun, hvad du ser i en allerede gemt fangst, og bruger Wiresharks eget, mere detaljerede filtersprog.

Hvilken version af Wireshark bør jeg bruge?
Brug den nyeste stabile version, 4.6.9, til ny funktionalitet og de nyeste sikkerhedsrettelser. Hvis du har brug for en mere konservativ opdateringscyklus i et produktionsmiljø, er 4.4.19-grenen (langsigtet support) et godt alternativ, da den også modtager sikkerhedsrettelser.

Kan jeg bruge Wireshark til at opdage databrud, som det der ramte CPR-registret?
Wireshark kan hjælpe med at opdage det netværksmæssige fodspor af et bulk-dataudtræk, som et usædvanligt antal forbindelser eller en stor datamængde fra en enkelt klient. Det kan dog ikke på egen hånd bekræfte, hvilke specifikke poster der blev læst i en krypteret session. Det kræver korrelation med database- og adgangslogge.

Hvorfor kan jeg ikke se nogen interfaces i Wireshark?
Det sker typisk, hvis Npcap (Windows) eller ChmodBPF (macOS) ikke er installeret korrekt, eller hvis din brugerkonto på Linux ikke er medlem af wireshark-gruppen. Geninstallér med driveren valgt, eller justér gruppemedlemskabet.

Er TShark det samme som Wireshark?
TShark deler den samme analysemotor og filtersyntaks som Wireshark, men kører fra kommandolinjen uden grafisk flade. Det gør det ideelt til servere, automatisering og scripts, mens den grafiske Wireshark-klient er bedre til interaktiv, visuel analyse.

Hvor ofte udgiver Wireshark-projektet sikkerhedsopdateringer?
Ganske ofte. I løbet af 2026 har projektet udgivet flere mindre versioner stort set hver måned, primært med rettelser til protokol-dissektorer. Det bedste råd er derfor at tjekke for opdateringer regelmæssigt i stedet for at antage, at en installeret version forbliver sikker over tid.

Skal jeg vælge Wireshark 4.6.9 eller den langsigtede supportgren 4.4.19?
Vælg 4.6.9, hvis du vil have de nyeste funktioner og protokolrettelser så hurtigt som muligt, hvilket er oplagt til en analytikers egen arbejdsstation. Vælg 4.4.19, hvis du installerer Wireshark eller TShark på en server eller et produktionssystem, hvor du ønsker færre og mere forudsigelige ændringer mellem opdateringerne, men stadig vil have sikkerhedsrettelserne.

Kan jeg bruge Wireshark på en virtuel maskine eller i et containermiljø?
Ja, så længe det virtuelle netværkskort er sat til en tilstand, der giver adgang til den trafik, du vil analysere, typisk “bridged” eller “promiscuous” netværk i din virtualiseringsplatform. I container-miljøer kan det kræve, at containeren får udvidede netværksrettigheder (for eksempel NET_ADMIN i Docker), fordi pakkefangst ellers er blokeret af standard-sikkerhedsprofilen.