Firewall‑logs teknisk: sessioner, NAT og tidsstempler

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

En firewall-log er en registrering af forbindelser, ikke af indhold. Hver linje beskriver typisk en session: hvem forbandt til hvem, på hvilken port, hvornår, hvor længe, med hvor mange bytes hver vej, og hvilken regel der tillod eller afviste det. Flowdata og pakkeopsamling går et skridt videre; se NetFlow og pakkeopsamling. Bag en offentlig IP-adresse står firewallens NAT-oversættelse, og kun firewallen ved, hvilken intern adresse og port der lå bag en bestemt udgående forbindelse. Det gør firewallen til et centralt led, når en hændelse i en ekstern log skal føres tilbage til en enhed på netværket, og når mængden af data, der har forladt netværket, skal opgøres.

Haster det? Firewalls gemmer ofte kun logs i en intern buffer eller en kort periode, så sessioner og NAT-oversættelser fra sagens tidsrum kan være overskrevet hurtigt. Se akut forensisk sikring, og bemærk, at hastesager koster ekstra.

Hvilke typer logs der findes, og hvorfor de skal sikres hurtigt, er beskrevet for ikke-teknikere i Firewall-, VPN- og loginlogs. Her går vi i dybden med felterne.

Felterne i en sessionslog

Navnene varierer mellem producenter, men indholdet går igen:

Tidspunkt · Hvornår loglinjen blev skrevet, ved sessionens start, slut eller begge
Kilde-IP og kildeport · Den, der startede forbindelsen
Destinations-IP og destinationsport · Den, der blev forbundet til
Protokol · Fx TCP, UDP eller ICMP
NAT-kilde og NAT-port · Adressen og porten efter oversættelse, set udefra
Handling · Tilladt, afvist, droppet eller nulstillet
Regel · Navn eller nummer på den regel, der matchede
Bytes sendt og modtaget · Datamængde hver vej
Pakker · Antal pakker hver vej
Varighed · Sessionens længde
Zoner eller interfaces · Hvor trafikken kom ind og gik ud
Applikation og bruger · Hvis firewallen genkender applikationer eller kobler adresser til brugere

Start, slut og byte-tællere

Mange firewalls kan logge en session ved start, ved slut eller begge. Datamængden kendes først, når sessionen slutter. En log, der kun skriver ved start, har derfor ingen byte-tællere, og en log, der kun skriver ved slut, har et tidsstempel, der kan ligge timer efter, at forbindelsen blev oprettet, hvis sessionen var lang. Find ud af, hvad tidspunktet i den konkrete log betyder, før det bruges i en tidslinje.

Lange sessioner, fx en synkroniseringsklient, der holder en forbindelse åben hele dagen, kan give én linje med en stor datamængde. Nogle firewalls skriver mellemliggende linjer med løbende tællere. Læg dem ikke sammen uden at vide, om tællerne er kumulative.

Retningen er relativ til den, der startede forbindelsen. “Sendt” fra en klient til en cloudtjeneste er upload. Ved en forbindelse udefra og ind er det omvendt. Det lyder banalt, men forveksling af retning er en af de hyppigste fejl ved opgørelse af dataudtræk.

NAT og korrelation

Udgående trafik fra et internt netværk får typisk firewallens offentlige adresse som afsender og en ny kildeport. I en log fra en ekstern tjeneste, fx en cloudtjenestes loginlog, står derfor firewallens offentlige adresse. For at finde den interne enhed skal du:

Finde sessioner i firewallloggen til tjenestens adresse omkring tidspunktet.
Matche på NAT-kildeport, hvis den eksterne log har kildeporten. Ellers matche på tidspunkt og destination, hvilket på et travlt netværk kan give mange kandidater.
Læse den interne kildeadresse og gå videre til DHCP-loggen; se DHCP, Wi-Fi og NAC.

Uden kildeport i den eksterne log er koblingen en sandsynlighedsvurdering, og den skal beskrives som sådan. Hvorfor porten er afgørende, er forklaret i IP-adresser som bevis.

Hvad der faktisk bliver logget

En firewall logger kun det, den er sat op til. Typiske huller:

Tilladt trafik logges ikke. Mange firewalls logger kun afviste forbindelser som standard eller på visse regler, fordi tilladt trafik giver store mængder data.
Regler uden logning. Logning er ofte en indstilling pr. regel. En bred tilladelsesregel uden logning gør trafikken usynlig.
Lokal buffer. Uden videresendelse til en syslog-server eller et SIEM-system rummer firewallen typisk kun en kort periode.
Tab ved videresendelse. Syslog over UDP kan tabe beskeder ved høj belastning uden at sige det.
Prøvetagning. Nogle systemer logger kun et udsnit af sessioner.

Gem derfor regelsæt og logindstillinger sammen med loggen. Uden dem kan du ikke sige, om en manglende linje betyder, at trafikken ikke fandt sted.

Applikations- og brugergenkendelse

Mange firewalls kan genkende applikationer ud fra trafikmønstre eller TLS-oplysninger og koble interne adresser til brugere via domænecontrolleren, en agent eller en loginportal. Det giver felter som applikationsnavn og brugernavn direkte i loggen. Begge felter er firewallens fortolkning. Applikationsgenkendelse kan tage fejl, og brugerkoblingen kan være forældet, hvis en anden bruger overtog adressen. Kontrollér afgørende brugerkoblinger mod DHCP- og loginlogs.

VPN og fjernadgang gennem firewallen

Mange firewalls er også VPN-endepunkt. Sessioner fra VPN-klienter optræder da med den interne adresse, VPN-puljen tildelte, ikke med brugerens hjemmeadresse. For at koble en session til en bruger skal firewallloggen sammenholdes med VPN-loggen for samme tidspunkt, hvor tildelingen af adressen står. Med split tunneling går kun en del af brugerens trafik gennem firewallen, så trafik til private cloudtjenester kan helt mangle. Detaljerne er beskrevet i VPN-logs: sessioner, tildelte adresser og datamængder.

Tid

Firewallens ur skal være synkroniseret, og tidszonen skal kendes. Nogle firewalls logger i lokal tid, andre i UTC, og en syslog-server kan tilføje sit eget modtagelsestidspunkt. Har du begge, så notér forskellen. I klynger med to firewalls kan loglinjer for samme session komme fra begge enheder.

Sikring

Eksportér logs fra firewallen, fra syslog-serveren og fra producentens cloudportal, hvis den findes, for hele perioden.
Gem konfigurationen: regelsæt, logindstillinger pr. regel, NAT-regler, tidszone og NTP-opsætning, firmwareversion.
Eksportér i rå form, ikke kun som rapporter eller dashboards.
Notér modelnavn, serienummer og klyngestatus.
Beregn hashværdier.

Lokale buffere kan være meget korte. Sikr dem først. Rotationen er beskrevet i Logfiler og logrotation.

Opgørelse af datamængder

Ved mistanke om dataudtræk bruges firewallloggen til at opgøre, hvor meget data der gik fra bestemte interne adresser til bestemte destinationer i en periode. Det kræver, at tilladt trafik blev logget med byte-tællere. Opgørelsen viser trafik på netværksniveau inkl. protokoloverhead, kryptering og gentagelser. Den siger ikke, hvilke filer der blev sendt. Ved ransomware og andre angreb bruges samme metode til at vurdere, om data har forladt netværket; se Dataudtræk før kryptering.

Hvad firewallloggen kan og ikke kan bevise

En komplet firewalllog kan vise, at en intern adresse havde forbindelse til en ekstern adresse på et bestemt tidspunkt, hvor længe, og med hvor mange bytes hver vej. Den kan understøtte NAT-kobling og opgørelse af datamængder. Den kan ikke vise indhold, filer eller brugerhandlinger, og den kan ikke alene vise, hvilken person der brugte enheden.

Dokumentation

Angiv model og firmware, logkilder, logindstillinger og regler, tidszone, perioder med manglende logs, eksportmetode og hashværdier. Beskriv for hver kobling, hvilke felter den bygger på, og om den er entydig eller en sandsynlighedsvurdering. Opgøres datamængder, så angiv metoden, de filtre der er brugt, og om tallene er målt på netværksniveau eller omregnet.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Netværk og logs

Læs også: DNS-logs som spor · VPN-logs: sessioner, tildelte adresser og datamængder

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · 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