IP‑adresser og domæner i opgaven: hvad skal med fra internetsiden?

En ekstern penetrationstest kan kun undersøge det, der står på listen, og den må kun undersøge det, virksomheden har ret til at lade teste. Listen over IP-adresser og domæner skal derfor bygge på to ting: et opdateret overblik over, hvad virksomheden viser på internettet, og en afklaring af, hvem der ejer og driver hver enkelt adresse.

Det korte svar er, at listen skal rumme alle de adresser og domæner, der indgår i testens spørgsmål, med en ejer og en status for hver. Hvad der ikke står på listen, er ikke testet. Hvad der står på listen uden afklaret ejerskab, bør ikke testes, før ejerskabet er på plads.

Adresselisten er opgavens grænse

I en ekstern test er listen over adresser og domæner det mest konkrete udtryk for omfanget. Testeren holder sig til den, og rapporten bør henvise til den. Hvis listen er ufuldstændig, bliver resultatet det også, uden at det nødvendigvis fremgår tydeligt af resuméet.

Valget af perspektiv er beskrevet andetsteds. Her er spørgsmålet, hvordan køberen samler og kontrollerer selve listen, så den passer til det, testen skal svare på. → Ekstern eller intern penetrationstest

Hvor oplysningerne findes

Overblikket ligger sjældent ét sted. Saml oplysninger fra flere kilder, og sammenlign dem.

Domæneregistreringer · hvilke domæner virksomheden har registreret, også gamle kampagnedomæner.
Navneopslag · hvilke underdomæner der peger på hvilke adresser.
Internetforbindelser · adresser, som internetudbyderen har tildelt kontoret.
Hosting og cloud · adresser hos hostingfirmaet og i virksomhedens cloudkonti.
Leverandører · løsninger, som en leverandør driver under virksomhedens navn.

Driftsleverandøren og hostingfirmaet kan ofte levere en del af oversigten. Bed om den skriftligt, og bed om at få oplyst, hvornår den sidst blev opdateret. Oplysninger fra hukommelsen er ikke nok til at afgrænse en test.

Hold listen i et format, som både IT, leverandører og tester kan læse. En enkel oversigt med adresse eller domæne, formål, ejer, driftsansvarlig og kontaktperson er ofte nok. Formålet er vigtigt, fordi det fortæller testeren, hvad løsningen bruges til, og hjælper køberen med at vurdere, om den hører til testens spørgsmål. En adresse, som ingen kan forklare formålet med, er i sig selv en oplysning, der bør følges op internt, uanset om den kommer med i testen eller ej.

Notér også, hvilke adresser der kun bruges i bestemte perioder, eksempelvis til en sæsonkampagne. De kan være slukket på testtidspunktet og give et misvisende billede.

Ejerskab skal afklares for hver adresse

Det vigtigste spørgsmål ved hver linje er, hvem der råder over adressen. En adresse, som virksomheden selv har fået tildelt, er en anden sag end en adresse hos et hostingfirma, hvor andre kunder kan ligge på samme maskine. En tjeneste i cloud har sine egne regler fra udbyderen.

Testeren må kun undersøge det, den, der bestiller testen, har ret til at lade undersøge. Hvis en adresse tilhører en leverandør, kræver det leverandørens godkendelse. Microsoft og AWS beskriver på deres egne sider, hvilke regler der gælder for test af kunders ressourcer hos dem. Reglerne bør læses før testen og ikke bagefter. → Er en penetrationstest lovlig?

Giv hver adresse en status: virksomhedens egen, leverandørens med godkendelse, leverandørens uden godkendelse eller ukendt. Kun de to første hører hjemme i testen. Hvad I gør, når en godkendelse mangler, er beskrevet i → Leverandørens godkendelse mangler.

Domæner og adresser er ikke det samme

En adresse er et nummer på nettet. Et domæne er et navn, der peger på et eller flere numre. De to lister skal kunne kobles sammen, fordi samme webshop kan være tilgængelig under flere navne, og fordi flere løsninger kan dele samme adresse.

Når en løsning ligger bag en fælles tjeneste, eksempelvis hos et hostingfirma med mange kunder, giver adressen alene ikke mening som afgrænsning. Her er det domænet og løsningen, der skal stå i opgaven, sammen med hostingfirmaets vilkår. Omvendt kan en adresse på kontorets internetforbindelse rumme flere tjenester, der ikke har noget domænenavn. Begge dele skal med, hvis de indgår i spørgsmålet.

Det glemte og det gamle

Listen bliver ofte for kort, fordi gamle løsninger er glemt. Et testmiljø fra et tidligere projekt, et kampagnesite eller en adgang, som en tidligere leverandør oprettede, kan stadig svare på internettet. Det er netop sådanne løsninger, en ekstern test kan have gavn af at få med, hvis virksomheden råder over dem. → Glemte testmiljøer på internettet

Det modsatte sker også. Listen kan rumme adresser, som virksomheden har opgivet, og som nu er overtaget af andre. En gammel adresse fra en tidligere hostingaftale er ikke længere virksomhedens at teste. Kontrollér derfor, at hver adresse stadig hører til jer på tidspunktet for testen.

Spørg også, om testeren skal hjælpe med at finde det, der mangler på listen. Det kan aftales som en del af opgaven, men det er et særskilt valg. Hvis det aftales, skal fund uden for listen meldes til virksomheden og afklares, før de undersøges nærmere. Det, virksomheden samlet viser udadtil, er beskrevet under → Angrebsflade.

Listen skal kunne genfindes i rapporten

Rapporten bør gengive eller henvise til den liste, testen bygger på, med dato. Hvis adresser blev fjernet eller tilføjet undervejs, skal ændringen fremgå. Så kan en senere læser se, præcis hvad konklusionen gælder for.

Det er særlig vigtigt, når rapporten skal vises til en kunde. Et resumé om webshoppen må ikke kunne læses, som om alle virksomhedens adresser var undersøgt. Listen er den mest præcise måde at vise dækningen på. Hvordan listen indgår i den samlede beskrivelse til testeren, findes i → Opgavebeskrivelsen.

Det skal I lade være med

At sende en liste fra hukommelsen. Saml oplysningerne fra domæner, navneopslag, udbydere og leverandører.
At tage leverandørens adresser med uden godkendelse. Råderet skal være afklaret for hver linje.
At glemme de gamle domæner. Kampagnesites og testmiljøer kan stadig være synlige.
At beholde adresser, I har opgivet. De kan i dag tilhøre andre.
At ændre listen undervejs uden at skrive det ned. Ændringer skal kunne genfindes i rapporten.

Hvad kan og ikke kan konkluderes

En ekstern test kan sige noget om de adresser og domæner, der stod på listen, set udefra på testtidspunktet. Den kan ikke sige noget om adresser, der manglede, eller om løsninger, der kom til efter testen.

En kort liste giver et kort svar. Hvis virksomheden er i tvivl om, hvorvidt listen er fuldstændig, bør tvivlen stå i rapportens forudsætninger, så den ikke forsvinder i resuméet.

Tjekliste til adresselisten

☐ Er domæner, underdomæner og adresser samlet fra flere kilder?
☐ Har hver linje en ejer og en status for godkendelse?
☐ Er udbydernes regler for test af cloud og hosting læst?
☐ Er gamle og glemte løsninger kontrolleret?
☐ Er opgivne adresser fjernet fra listen?
☐ Er det aftalt, hvordan fund uden for listen håndteres?
☐ Fremgår den daterede liste af rapporten?

Kilder

Microsoft Learn: Penetration testing: Microsofts vilkår, når kunder lader deres Azure-ressourcer teste.
AWS: Penetration Testing: AWS’ vilkår for sikkerhedstest af tjenester hos AWS.

Senest gennemgået: oktober 2026.