Værtsbaseret firewall og tilladelseslister for applikationer

En netværksfirewall sidder ved perimeteren og filtrerer trafik mellem netværkssegmenter. En værtsbaseret firewall kører på det enkelte slutpunkt og filtrerer trafik til og fra den pågældende maskine. Værtsbaserede firewalls giver defense-in-depth: Selv hvis en angriber omgår netværksfirewallen (via en VPN, en kompromitteret insider eller lateral bevægelse fra en anden inficeret vært), håndhæver værtsfirewallen lokale trafikregler. De er især vigtige for bærbare computere, der bevæger sig uden for virksomhedens perimeter og opretter forbindelse til netværk, der ikke er tillid til.

Windows Defender Firewall (WDF) er den indbyggede værtsfirewall i alle moderne Windows-versioner. Den understøtter tre profiler: Domain (forbundet til virksomhedens domæne — typisk mere tilladende), Private (netværk i hjemmet, der er tillid til) og Public (netværk, der ikke er tillid til — mest begrænsende). WDF-regler kan filtrere efter port, protokol, applikationssti, ekstern IP og brugeridentitet. Snap-in-modulet Windows Defender Firewall with Advanced Security (WFAS) til MMC og Group Policy muliggør centraliseret administration af firewallregler i virksomheden på alle domænetilsluttede maskiner.

Linux-værtsfirewalls bruger kernerammen Netfilter, som kan konfigureres via iptables (ældre, men stadig udbredt) eller den moderne nftables. Reglerne organiseres i kæder (INPUT, OUTPUT, FORWARD) i tabeller (filter, nat, mangle). Standardpolitikken bør være DROP med eksplicitte ACCEPT-regler for nødvendig trafik — en afvis-alt-som-standard-holdning. Værktøjer på højere niveau som ufw (Ubuntu) og firewalld (RHEL/CentOS) giver mere brugervenlige grænseflader, men bruger stadig Netfilter under overfladen.

Værtsbaserede firewalls kan håndhæve regler på applikationslaget — de filtrerer trafik efter den applikation, der genererede den, ikke kun efter porten. Windows Defender Firewall understøtter applikationsbaserede regler: Tillad C:\Program Files\MyApp\app.exe at oprette udgående forbindelser, mens alt andet på den samme port blokeres. Det forhindrer malware i at kapre tilladte porte ved at udgive sig for at være en applikation, der er tillid til. Regler på applikationslaget er betydeligt mere effektive end regler, der kun er baseret på porte, og som kan omgås ved at knytte malware til almindelige porte som 443.

Tilladelseslister for applikationer (tidligere kaldet whitelisting) er en sikkerhedskontrol, der kun tillader udtrykkeligt godkendte applikationer at køre på et slutpunkt. Alle eksekverbare filer, der ikke står på tilladelseslisten, blokeres, uanset om de er malware eller blot ikke-godkendt software. Dette er et effektivt forsvar mod malware, fordi selv ny malware og zero-day-malware blokeres, hvis den ikke står på den godkendte liste. Udfordringen er driftsmæssig: Administration af tilladelseslisten i store, dynamiske miljøer kræver en moden proces til ændringsstyring og genererer mange supportsager, hvis den ikke er korrekt finjusteret.

AppLocker er Windows' indbyggede funktion til applikationskontrol, som er tilgængelig i Enterprise- og Education-udgaverne. Den filtrerer kørsel efter: sti (blokér eksekverbare filer fra %TEMP% eller mapper, som brugere kan skrive til), filhash (tillad kun kendte, sikre hashværdier) eller udgiver (tillad software, der er signeret af Microsoft eller Adobe). AppLocker-politikker implementeres via Group Policy og logges i Windows Event Log (hændelses-id 8003 = blokeret). Hvis AppLocker først køres i Audit Mode — hvor blokeringer logges uden at blive håndhævet — kan teams finjustere tilladelseslisten, før håndhævelsen begynder.

WDAC er den mere effektive efterfølger til AppLocker og håndhæves på kerneniveau i stedet for i brugerområdet. I modsætning til AppLocker kan WDAC ikke omgås af angribere med lokale administratorrettigheder, hvilket gør den til den foretrukne kontrol i miljøer med høje sikkerhedskrav. WDAC-politikker skrives i XML og konverteres til binære politikfiler, der implementeres via MDM (Intune) eller Group Policy. WDAC muliggør også integration med Intelligent Security Graph (ISG), som bruger Microsofts cloudbaserede omdømmetjeneste til automatisk at tillade software med et omdømme, der er tillid til — hvilket mindsker den driftsmæssige byrde ved manuelt at vedligeholde tilladelseslisten.

Tilladelseslister er effektive, men krævende at administrere. Almindelige udfordringer er: LOLBins (Living-Off-the-Land Binaries) — angribere bruger Windows-systemværktøjer som PowerShell, wscript.exe og mshta.exe, der typisk står på alle tilladelseslister; tilladelseslisten skal begrænse, hvordan disse værktøjer startes, ikke kun om de må køre. Skriptsprog (PowerShell, Python) står ofte på tilladelseslisten, men kan udføre skadelig kode. Falske positiver — legitim software, der blokeres af tilladelseslisten — genererer supportsager og pres for at svække kontrollerne. Modne programmer for tilladelseslister håndterer LOLBins gennem yderligere politikker for begrænset sprogtilstand.

Tilladelseslister tillader kun udtrykkeligt godkendte elementer og blokerer alt andet — en stærkere sikkerhedstilstand. Afvisningslister (blacklisting) blokerer udtrykkeligt kendte, skadelige elementer og tillader alt andet — den traditionelle antivirusmodel. Afvisningslister beskytter ikke mod ukendte trusler; tilladelseslister beskytter ikke mod LOLBins og alt for brede tilladelsesposter. De fleste modne sikkerhedsprogrammer bruger tilladelseslister som den primære kontrol på kritiske systemer, mens adfærdsbaseret detektering (EDR) bruges til at opdage misbrug af tilladte applikationer. På mindre kritiske systemer kan en veltilpasset afvisningsliste med adfærdsovervågning være acceptabel.

Værtsbaserede firewalls og tilladelseslister for applikationer er komplementære, lagdelte kontroller. Tilladelseslisten forhindrer uautoriseret kode i at køre; firewallen forhindrer uautoriserede netværksforbindelser fra autoriseret, men kompromitteret kode. Sammen implementerer de principperne om mindst mulige privilegier på både applikations- og netværkslaget på slutpunktet. Hvis du tilføjer EDR som et tredje lag, får du en defense-in-depth-stak, hvor hver kontrol opfanger det, de andre muligvis overser, og dermed øges omkostningerne og kompleksiteten ved vellykkede angreb på slutpunkter markant.

Værtsbaserede firewalls er kun så værdifulde som de logfiler, de genererer. Aktivér logning af blokerede forbindelser for at registrere angrebsforsøg og overtrædelser af politikker. Aktivér logning af tilladte forbindelser for følsomme regler (for eksempel regler, der tillader administrative værktøjer) for at opretholde et revisionsspor. Videresend firewall-logfiler til SIEM med henblik på korrelation — et mønster af blokerede udgående forbindelser fra en enkelt vært kan være tegn på malware, der forsøger at oprette C2-callbacks. I Windows skrives firewall-logfiler som standard til %systemroot%\System32\LogFiles\Firewall\pfirewall.log og bør videresendes via Windows Event Forwarding (WEF) eller en logagent.

I denne lektion lærte du: værtsbaserede firewalls (Windows Defender Firewall, iptables) filtrerer trafik pr. slutpunkt med en afvis-alt-som-standard-holdning og regler med applikationsafgrænsning, tilladelseslister for applikationer (AppLocker, WDAC) blokerer uautoriserede eksekverbare filer, herunder malware, så de ikke kan køre, og lagdeling af firewall, tilladelsesliste og EDR skaber defense-in-depth, der øger omkostningerne ved et angreb markant. Dernæst ser vi på e-mailgodkendelse: SPF, DKIM og DMARC.