NetFlow og pakkeopsamling i civile undersøgelser

Forside › Netværk og logs · Gennemgået oktober 2026 · Af John Nielsen

NetFlow og lignende flowdata registrerer forbindelser på netværket: hvem talte med hvem, hvornår, på hvilken port og med hvor mange bytes og pakker. Pakkeopsamling, ofte kaldet PCAP efter filformatet, gemmer selve pakkerne og dermed i princippet indholdet. I civile undersøgelser er flowdata langt den mest anvendelige af de to, fordi de ofte findes i forvejen og kan dokumentere datamængder ved mistanke om udtræk. Fuld pakkeopsamling findes sjældent bagud i tid, og at starte den fremadrettet kræver et klart lovligt grundlag og en afgrænsning, der står mål med formålet.

Flowdata: hvad en flowpost indeholder

En router, switch, firewall eller sensor samler pakker med samme nøgle til et flow. Nøglen er typisk de fem felter kilde-IP, destinations-IP, kildeport, destinationsport og protokol. For hvert flow registreres:

starttidspunkt og sluttidspunkt,
antal bytes og pakker,
TCP-flag, som kan vise, om forbindelsen blev oprettet og afsluttet normalt,
interfaces, retning og evt. VLAN,
i nyere formater også applikationsoplysninger eller NAT-adresser.

Udbredte formater er NetFlow i version 5 og 9, IPFIX og sFlow. NetFlow og IPFIX samler typisk alle pakker, mens sFlow bygger på stikprøver. Flowdata sendes til en collector, som gemmer dem i en database eller i filer.

Timeouts deler lange forbindelser

Udstyret afslutter et flow efter en inaktiv timeout, eller når en aktiv timeout udløber for en lang forbindelse. En forbindelse, der varer en time, kan derfor stå som mange på hinanden følgende flowposter med samme nøgle. For at opgøre den samlede datamængde skal posterne lægges sammen, og for at angive sessionens start og slut skal første og sidste post findes. Standardværdierne varierer mellem producenter og er ofte ændret lokalt; i Cisco IOS er de fx 30 minutter for aktiv og 15 sekunder for inaktiv timeout. Notér derfor timeoutværdierne fra den konkrete konfiguration.

Stikprøver

Ved stikprøver registreres fx kun hver tusinde pakke, og tallene skaleres op. Det er tilstrækkeligt til at se trafikmønstre, men ikke til præcise opgørelser af små overførsler, og en kort forbindelse kan helt mangle. Stikprøveforholdet skal fremgå af konfigurationen og af rapporten, og tal skal angives som estimater.

Flowlogs i cloud

De store cloudplatforme har deres egne flowlogs for virtuelle netværk, fx VPC Flow Logs hos AWS og Google Cloud og flowlogs for virtuelle netværk hos Azure, som afløser de ældre flowlogs for netværkssikkerhedsgrupper. De registrerer forbindelser til og fra virtuelle maskiner og andre ressourcer med adresser, porte, bytes, pakker og om trafikken blev tilladt eller afvist. De er som udgangspunkt ikke slået til og skal aktiveres pr. netværk, subnet eller interface, og de skrives med en vis forsinkelse og samlet i intervaller, hos AWS som standard ti minutter, med mulighed for ét minut. Google Cloud kan desuden nøjes med en stikprøve af trafikken, afhængigt af indstillingen. Felterne afhænger af det valgte logformat, så konfigurationen skal gemmes med. Er de slået til, er de ofte den eneste kilde til trafikdata for servere i cloud, fordi der ikke findes en fysisk switch eller firewall, kunden selv kan logge fra. De sikres som andre cloudlogs: eksport i rå form, konfigurationen med og hashværdier af eksporten.

Datamængder som spor efter udtræk

Ved mistanke om, at data har forladt netværket, kan flowdata vise:

hvilke interne adresser der sendte usædvanligt meget data ud,
til hvilke eksterne adresser og porte,
i hvilke tidsrum,
om mønsteret afviger fra normalen for samme adresse.

Flowdata viser bytes på netværksniveau, inkl. protokoloverhead og kryptering. De kan ikke vise filnavne eller indhold, og de kan ikke skelne en upload af fortrolige filer fra en backup eller et videomøde med samme modpart. De kan derimod afgrænse tidsrum og destinationer, som derefter undersøges i endpoint-, proxy- og cloudlogs. Samme metode bruges ved angreb, hvor spørgsmålet er, om data blev taget før kryptering; se Dataudtræk før kryptering.

Byg en baseline for de relevante adresser over en længere periode, før en enkelt dag fremhæves som usædvanlig. Det er ikke usædvanligt, at en udviklers computer sender gigabyte ud om dagen.

Pakkeopsamling

Fuld pakkeopsamling gemmer hele pakker eller de første bytes af hver pakke. Den kan vise protokolforløb, servernavne fra TLS-forhandlingen, ukrypteret indhold og præcise tidsforløb. I praksis er den begrænset af tre forhold:

Den findes sjældent bagud. De fleste netværk opsamler ikke løbende, og systemer, der gør, gemmer typisk kun i en ringbuffer på timer eller dage.
Indholdet er krypteret. Det meste trafik er TLS, så indholdet kan ikke læses uden dekryptering, som kun sker i særlige opsætninger.
Datamængden er stor. Opsamling på et travlt link fylder hurtigt terabyte. Hvordan så store mængder kopieres og verificeres, står i Store datamængder: forensisk kopi af multi-terabyte-systemer.

Er der en ringbuffer, fx i et netværksbaseret detektionssystem, skal den sikres med det samme, før den overskrives.

Fremadrettet opsamling: lovligt grundlag og proportionalitet

At starte ny pakkeopsamling eller udvidet flowlogning for at undersøge en bestemt medarbejder er en form for overvågning af kommunikation. Det kræver et lovligt grundlag, information efter de regler, der gælder for kontrol af medarbejdere, og en afgrænsning, der står mål med formålet. Indholdsopsamling er markant mere indgribende end flowdata, og flowdata er mere indgribende end logning, der allerede findes. Vælg det mindst indgribende middel, der kan besvare spørgsmålet, og afklar det juridiske grundlag med virksomhedens rådgiver, før opsamlingen starter. Hvordan arbejdsgiverens kontrol kan blive mødt i en senere tvist, er beskrevet i Arbejdsgiverens kontrol som bevis.

Den praktiske side for virksomheden er beskrevet i Kontrol og overvågning af medarbejdere, og principperne for dataminimering i Dataminimering i forensic. Ved digital stalking, hvor den ramte selv vil undersøge sit eget netværk for overvågning, er udgangspunktet et andet; se hjælp ved digital stalking.

Sikring af eksisterende data

Find kilderne: flowcollector, netværksbaseret detektion, firewall med flowfunktion, cloudplatformens flowlogs for virtuelle netværk.
Eksportér flowdata for perioden i rå form eller i collectorens eget format, ikke kun som rapporter.
Gem konfigurationen: hvilke interfaces der eksporterer flow, timeouts, stikprøveforhold, format og collectorens opbevaring.
Sikr ringbuffere med pakker, hvis de findes.
Notér opsamlingspunktet for PCAP: hvor i netværket, hvilket filter, hvor mange bytes pr. pakke, og om der blev tabt pakker undervejs.
Beregn hashværdier for alle filer.

Fejlkilder

Asymmetrisk routing: Udstyret ser kun én retning af en forbindelse.
NAT: Flowdata før og efter NAT har forskellige adresser. Find ud af, hvor i netværket flowet er målt.
Dubletter: Samme trafik kan være målt på flere enheder og tælle dobbelt, hvis kilderne lægges sammen ukritisk.
Tid: Udstyrets ur og collectorens ur kan afvige.
Tabt eksport: Flowdata sendes ofte over UDP og kan gå tabt ved belastning.

Hvad flow og pakker kan og ikke kan bevise

Flowdata kan vise, at to adresser udvekslede en bestemt mængde data i et bestemt tidsrum, og om mønsteret afviger fra det normale. Pakkeopsamling kan vise protokolforløb og ukrypteret indhold. Ingen af dem viser, hvilken person der brugte enheden, og flowdata viser ikke, hvilke filer der blev overført. Sammen med firewall- og endpointspor kan de indgå i en samlet vurdering; se Firewall-logs teknisk.

Dokumentation

Angiv kilde og målepunkt, format, timeouts, stikprøveforhold, tidszone, periode, eksportmetode og hashværdier. Angiv datamængder som målte eller estimerede værdier med de forbehold, der følger af metoden. Beskriv også, hvilke dele af netværket der ikke var dækket af flowdata eller opsamling i perioden, så det er tydeligt, hvad fravær af trafik betyder.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Netværk og logs

Læs også: Proxy- og webfilterlogs · Webserverlogs (IIS, Apache, Nginx): felter, tidszoner, proxy og CDN

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik