En webapplikationsfirewall foran en webløsning stopper mange forsøg, før de når løsningen. Det er godt i drift, men under en penetrationstest kan det skjule, hvordan løsningen selv er bygget. Om firewallen skal være slået til, afhænger af, hvilket spørgsmål testen skal besvare. Svaret hviler på en enkel skelnen: vil I vide, hvor robust løsningen er i sig selv, eller hvor godt den samlede opstilling holder i dag? De to spørgsmål giver hver sit svar, og mange IT-afdelinger har brug for begge.
To spørgsmål, to opstillinger
Løsningen i sig selv. Testeren skal kunne nå løsningen uden at blive stoppet af firewallen. Det kan ske ved, at testerens adresse undtages fra filtreringen i testperioden, eller ved at firewallen sættes til kun at registrere og ikke blokere. Resultatet viser de svagheder, der sidder i løsningen og dens opsætning. Hvis firewallen en dag fejler, bliver omgået eller ændres, er det dem, der står tilbage.
Den samlede opstilling. Firewallen kører som i produktionen. Resultatet viser, hvad en angriber udefra ville møde i dag. Det kan være et relevant spørgsmål, men det giver et ufuldstændigt billede af selve løsningen, fordi svagheder bag firewallen ikke nødvendigvis bliver set.
Det almindelige valg er at teste løsningen med testerens adresse undtaget og supplere med en kortere afprøvning af, om firewallen faktisk reagerer, som I forventer. Valget skal stå i aftalen, så rapporten kan læses rigtigt.
Hvorfor beskyttelsen ikke erstatter rettelsen
En webapplikationsfirewall arbejder med regler, der genkender mønstre i trafikken. Den kender ikke løsningens forretningslogik. Den ved ikke, at en almindelig bruger ikke må se en anden kundes faktura, eller at en rabat ikke må kunne bruges to gange. Svagheder af den slags ser ud som normal trafik og slipper igennem. Det samme gælder fund i adgangskontrollen, hvor testeren blot beder om noget, brugeren ikke burde have adgang til.
Firewallen kan desuden blive slået fra ved en fejl, få ændret sine regler ved en opdatering eller blive flyttet, når løsningen flytter. Derfor er den et lag i forsvaret og ikke en rettelse. Når en test finder en svaghed i løsningen, skal den rettes i løsningen, selvom firewallen i dag ville have stoppet forsøget.
Kravsættet PCI DSS, der gælder for betalingskortdata, peger i samme retning. I den udgave af kravene, som Microsoft gengiver, kræver punkt 6.4.2, at offentligt tilgængelige webløsninger har en automatisk teknisk løsning foran sig, der løbende opdager og forhindrer angreb, er opdateret, logger og enten blokerer eller giver en alarm, som straks undersøges. Kravet står ved siden af kravene om at finde og rette svagheder, ikke i stedet for dem.
Det, IT aftaler og registrerer
Når firewallen ændres for testens skyld, er det en midlertidig undtagelse og skal håndteres som en. → Midlertidige undtagelser til testen
- Hvad der ændres · undtagelse for bestemte adresser, skift til kun registrering, eller ingen ændring.
- Hvilke løsninger · kun dem, der er omfattet af testen, ikke alle løsninger bag samme firewall.
- Hvornår · start og slut, så undtagelsen ikke lever videre efter testen.
- Hvem · hvem der laver ændringen, og hvem der kontrollerer, at den er fjernet igen.
- Overvågning · om firewallens alarmer stadig skal sendes til overvågningen, og hvordan den ved, at det er testen. → Alarmer under testen
Når en anden driver firewallen
Firewallen er ikke altid IT-afdelingens egen. Den kan være en del af en hostingaftale, en tjeneste hos en cloududbyder eller noget, en MSP passer. Så er det den part, der skal lave undtagelsen, og den part, der skal fjerne den igen. Bestil ændringen i god tid, for en undtagelse, der ikke er på plads, er en almindelig grund til, at testen ikke kan begynde til tiden.
Spørg samtidig, hvad parten selv ser. Nogle udbydere overvåger trafikken og reagerer på mønstre, der ligner angreb, ved at spærre adressen eller kontakte jer. Det skal de vide på forhånd, ellers kan testen blive afbrudt midt i et forløb. Aftal også, hvem der modtager firewallens logs fra testperioden. De kan bruges bagefter til at se, hvad firewallen opdagede, og hvad den lod passere. → Hostede servere i den eksterne test
Når testen er slut
Fjern undtagelsen samme dag, som testen slutter, og kontrollér det. En glemt undtagelse for en adresse er ikke i sig selv en stor risiko, men en firewall, der stadig kun registrerer, er det. → Oprydning efter testen
Brug også resultatet til at se på firewallen selv. Gav den alarmer, da testeren arbejdede uden undtagelse? Blev alarmerne set? Er reglerne opdateret? Er der løsninger, der slet ikke står bag den? En test er ikke en revision af firewallen, men den kan vise, om den virker, som I tror.
Fund, hvor firewallen er den midlertidige løsning
Nogle gange kan en svaghed ikke rettes med det samme, fx fordi rettelsen skal komme fra en leverandør. Så kan en regel i firewallen være en fornuftig midlertidig beskyttelse. Den skal registreres med en udløbsdato og en ejer, og fundet skal stå som åbent, til den rigtige rettelse er på plads. → Midlertidige afhjælpninger
Kontrollér også, at reglen virker. En regel, der er skrevet til at stoppe et bestemt mønster, kan efterlade andre veje til samme svaghed. Spørg testeren, om reglen dækker fundet, eller om den kun gør det sværere.
Det skal I lade være med
- At teste med firewallen slået til uden at skrive det i aftalen. Rapporten ser bedre ud, end løsningen er.
- At lukke et fund med en firewallregel. Fundet er stadig åbent, til løsningen er rettet.
- At slå firewallen helt fra for alle. Undtag testerens adresse, så løsningen stadig er beskyttet mod andre.
- At glemme at fjerne undtagelsen. Kontrollér det, og notér det.
- At gå ud fra, at alle løsninger står bag firewallen. Testen kan vise, at nogle gør det ikke.
Hvad kan og ikke kan konkluderes
En test med undtagelse viser svagheder i løsningen og dens opsætning, uafhængigt af firewallen. En test med firewallen slået til viser, hvad der kunne nås gennem den samlede opstilling på testtidspunktet. Ingen af dem viser, at firewallen vil stoppe fremtidige forsøg, eller at den er korrekt opsat for andre løsninger. Rapporten skal sige, hvilken opstilling der blev brugt.
Tjekliste til firewallen og testen
- ☐ Er det aftalt, om testen skal se løsningen med eller uden firewall?
- ☐ Er undtagelsen registreret med start, slut og ansvarlig?
- ☐ Er hostingudbyderen eller tjenesten orienteret i god tid?
- ☐ Ved overvågningen, at alarmer fra testerens adresse kan forekomme?
- ☐ Er undtagelsen fjernet og kontrolleret efter testen?
- ☐ Er fund, der dækkes af en firewallregel, stadig registreret som åbne?
Kilder
- Microsoft Learn: Microsoft Entra ID and PCI-DSS Requirement 6: gengivelse af PCI DSS 6.4.1 og 6.4.2 om beskyttelse af offentligt tilgængelige webløsninger med en automatisk teknisk løsning, der opdager og forhindrer angreb, er opdateret, logger og blokerer eller giver alarm.
- OWASP Web Security Testing Guide: OWASP’s vejledning i test af webapplikationer.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Reverse proxy foran interne systemer · Testmiljø til webtesten
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
