En reverse proxy er den komponent, der tager imod trafik fra internettet og sender den videre til systemer, som i øvrigt står på det interne net. Testen afprøver derfor to ting på samme tid: om proxyen selv er forsvarligt sat op og vedligeholdt, og om den kun gør de systemer og funktioner tilgængelige, som virksomheden har besluttet at vise frem. Det første er et spørgsmål om drift. Det andet er et spørgsmål om, hvad der i årenes løb er blevet publiceret.
For IT-afdelingen kan det være den anden del, der overrasker. Proxyen blev sat op til ét formål, og siden er der kommet flere interne systemer bag den, uden at nogen har set på helheden.
En komponent med mange navne
Funktionen findes under forskellige betegnelser. Det kan være en selvstændig proxyserver, en publiceringsfunktion i firewallen, en load balancer, en applikationsgateway i Azure eller AWS eller en tjeneste, som hostingleverandøren stiller til rådighed. Fælles for dem er, at de står ved grænsen og afgør, hvad der slipper igennem til det interne.
Det betyder, at opgaven skal nævne komponenten direkte. Står der kun “intranettet” og “tidsregistreringen” i listen over systemer, kan testen ende med at handle om de to løsninger, mens selve vejen ind, og de andre systemer, der deler den, ikke bliver vurderet. Skriv i stedet, hvilke proxyer eller gateways I har, og hvilke publiceringer der hører til hver af dem.
Det, testen kigger efter
En test af området tager udgangspunkt i det, der kan ses og nås udefra. Typisk vurderes disse forhold:
- Hvad der er publiceret · hvilke interne systemer, stier og funktioner kan nås fra internettet, og svarer det til jeres hensigt?
- Adgangsregler · gælder begrænsningerne på fx administrationssider for alle veje ind, eller kun for den vej, der var tænkt?
- Login foran systemet · kræver proxyen, at brugeren er logget ind, før forespørgslen sendes videre, eller overlades det helt til det interne system?
- Selve komponenten · kører proxyen en udgave, som leverandøren stadig vedligeholder, og er den opdateret?
- Administration · hvorfra kan proxyen administreres, og hvem har adgang til det?
- Oplysninger i svarene · afslører svarene interne servernavne, versioner eller fejlbeskeder?
OWASP Web Security Testing Guide samler den slags forhold under konfiguration og drift af infrastrukturen omkring en webløsning. Det er et nyttigt fælles sprog, når I og testeren skal blive enige om, hvad der hører med. → Webserverens opsætning
Det, IT skal have klar
Testeren kan kun vurdere publiceringerne, hvis nogen kan forklare, hvad de er til. Saml derfor en kort oversigt, før testen begynder.
- Publiceringer · for hver: det eksterne navn, det interne mål, formålet og en ejer i virksomheden.
- Driftsansvar · administrerer I selv proxyen, eller gør driftsleverandøren, hostingfirmaet eller en cloudtjeneste det?
- Beskyttelse foran · er der en webapplikationsfirewall eller lignende filtrering, og skal den være aktiv under testen? → Webapplikationsfirewall og testen
- Logning · kan I bagefter se, hvilke forespørgsler testeren sendte, og hvilke der blev afvist?
- Kontakt · hvem kan svare hurtigt, hvis testeren støder på et system, ingen har nævnt?
Oversigten er ikke kun til testeren. Den kan være første gang, nogen har set alle publiceringerne samlet ét sted.
Fund, der går igen
Rapporter om området kan pege på de samme typer forhold. Forholdene skyldes ikke nødvendigvis en enkelt fejl, men kan skyldes, at proxyen er blevet brugt som en praktisk genvej over længere tid.
Interne systemer kan være publiceret efter et projekt, der for længst er afsluttet. Administrationssider for proxyen eller for systemerne bag den kan være tilgængelige fra internettet. → Administrationsflader på internettet
Et hyppigt forhold er uenighed mellem proxyen og systemet bag den om, hvem der kontrollerer hvad. Det interne system kan være bygget til et net, hvor alle var kendte, og regne med, at den, der når frem, allerede er godkendt. Når det samme system gøres tilgængeligt udefra, holder den antagelse ikke længere.
Endelig kan proxyen selv mangle opdateringer, eller svarene kan røbe detaljer om det interne miljø. Den slags fund kan have lav alvorlighed hver for sig, men de fortæller noget om, hvor meget opmærksomhed komponenten får. → Versionsoplysninger og fejlmeddelelser
Prioritering og rettelser
Begynd med publiceringerne. Alt, hvad ingen kan begrunde, bør lukkes eller midlertidigt slås fra, indtil en ejer har taget stilling. Det kan være den billigste rettelse i hele rapporten.
Derefter kommer de systemer, der skal være tilgængelige. Her handler rettelserne på begrebsniveau om at flytte kontrollen frem: kun brugere, der er logget ind, skal kunne nå det interne system, og administrationsdele skal slet ikke publiceres. Administration af selve proxyen bør ske fra et adskilt net og ikke fra internettet. → Administrationsnet
Sørg også for, at nye publiceringer fremover går gennem ændringsstyringen med en ejer, et formål og en slutdato, hvor det giver mening. En publicering, der blev oprettet til et kortvarigt samarbejde med en leverandør, skal have en naturlig afslutning. Ellers står den der stadig ved næste test, og så er det samme fund, der går igen. Notér desuden, hvem der godkender en ny publicering, så beslutningen ikke ligger hos den, der tilfældigvis har adgang til at oprette den.
Hvis flere fund går igen på tværs af publiceringer, ligger årsagen sandsynligvis i en fælles skabelon eller standardopsætning. Ret den, så nye publiceringer ikke arver de samme svagheder. → Gør rettelserne permanente
Det skal I lade være med
- At teste systemerne bag uden at nævne proxyen. Så bliver vejen ind ikke vurderet.
- At publicere uden ejer. En publicering, ingen ejer, bliver aldrig lukket.
- At lade proxyen erstatte login. Begrænsning ved grænsen og kontrol i systemet supplerer hinanden.
- At administrere proxyen fra internettet. Adgangen til at ændre reglerne er mere værd end noget enkelt system bag den.
- At slå filtreringen fra uden aftale. Beslut på forhånd, om testen skal ske med eller uden den, og skriv det i opgaven.
Hvad kan og ikke kan konkluderes
En test af proxyen viser, hvad der kunne nås udefra, og hvordan komponenten var sat op i testperioden. Den siger ikke, at de interne systemer bag den er sikre i sig selv, medmindre de var med i opgaven og blev testet med login. Den kan heller ikke tage højde for publiceringer, der kommer til efter testen. Til gengæld giver den et klart billede af, hvor grænsen faktisk gik, og det er et godt udgangspunkt for en oprydning.
Tjekliste før testen
- ☐ Er alle proxyer, gateways og publiceringsfunktioner nævnt i opgaven?
- ☐ Har hver publicering et formål og en ejer?
- ☐ Er det afklaret, hvem der administrerer komponenten?
- ☐ Er det besluttet, om filtreringen skal være aktiv?
- ☐ Kan I se testerens forespørgsler i loggen bagefter?
- ☐ Er publiceringer uden begrundelse lukket før testen eller markeret som tvivlsomme?
Kilder
- OWASP Web Security Testing Guide, kapitlet om konfiguration og drift: testområder for infrastruktur, platform og administrationsflader omkring en webløsning.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Webapplikationsfirewall og testen · Typiske fund i en ekstern test
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
