Når en ekstern penetrationstest bestilles, regner nogle i virksomheden med, at den også viser, om hjemmesiden og fjernadgangen kan holde til et overbelastningsangreb. Det gør den normalt ikke. En penetrationstest leder efter svagheder i opsætning, adgang og software, mens en DDoS-test måler, hvor meget trafik der skal til, før en tjeneste holder op med at svare. Det er to forskellige spørgsmål, der kræver forskellige aftaler, og måske også forskellige leverandører.
For IT-afdelingen er det vigtigste at få udeladelsen skrevet ind i opgaven, så ingen læser rapporten som et svar på et spørgsmål, den aldrig stillede.
To spørgsmål, to slags svar
En penetrationstest spørger, om en angriber kan komme ind, se noget, ændre noget eller få mere adgang end tilsigtet. Testeren arbejder med forholdsvis lidt trafik og forsøger netop at undgå at forstyrre driften. Et godt resultat beskriver svagheder, som kan rettes i opsætning eller software.
En DDoS-test spørger, om tjenesten forbliver tilgængelig, når den rammes af store mængder trafik fra mange kilder. Svaret afhænger af kapacitet og beskyttelse hos internetudbyderen, i cloudplatformen, i firewallen og i selve applikationen. Resultatet beskriver grænser og flaskehalse, ikke svagheder i almindelig forstand.
De to opgaver kan supplere hinanden, men den ene kan ikke stå i stedet for den anden.
Forvekslingen kan opstå, fordi begge dele omtales som angreb udefra, og fordi ledelsen tænker på konsekvensen: hjemmesiden er nede, kunderne kan ikke bestille, og medarbejderne kan ikke arbejde hjemmefra. For IT-afdelingen er det en god anledning til at forklare, at sikkerhed har flere sider. Fortrolighed og integritet afprøves i penetrationstesten. Tilgængelighed under pres kræver sin egen vurdering. Når forskellen er sagt højt inden bestillingen, undgår I også skuffelse, når rapporten kommer og ikke nævner emnet.
Platformenes regler trækker også en grænse
Ligger jeres systemer i cloud, gælder udbyderens regler for test. Microsoft skriver i sin vejledning om penetrationstest i Azure, at test af lammelsesangreb af enhver art ikke er tilladt, og at kunder i stedet kan bruge godkendte samarbejdspartnere til simulering. AWS forbyder ligeledes den slags test i sin politik for penetrationstest og henviser til en særskilt politik for DDoS-simulering med egne krav til, hvem der må udføre den, og hvordan.
Det understreger pointen. Selv hvis jeres tester var villig til at afprøve belastning som en del af den eksterne test, ville det i mange miljøer kræve en anden aftale og en anden leverandør. → AWS’ politik for penetrationstest
Systemer hos et hostingfirma eller en internetudbyder har tilsvarende vilkår, selv om de ikke altid er lige så tydeligt beskrevet. Spørg, før nogen planlægger noget, der ligner belastning.
Det, den eksterne test alligevel kan sige om tilgængelighed
En penetrationstest kan godt give oplysninger, der er relevante for tilgængeligheden, uden at testeren forsøger at overbelaste noget. Rapporten kan fx pege på:
- Tjenester uden for beskyttelsen · systemer, der ikke ligger bag den filtrering, resten af internetsiden er beskyttet af.
- Unødvendige åbne tjenester · alt, der svarer udefra, er også noget, der kan rammes.
- Skrøbelige komponenter · ældre udstyr eller software, som reagerede uventet på helt almindelige forespørgsler.
- Manglende overvågning · at ingen bemærkede testens trafik, hvilket kan betyde, at en begyndende overbelastning heller ikke bliver set.
Det er nyttig viden, men den er en bivirkning. Den erstatter ikke en vurdering af kapaciteten. → Typiske fund i en ekstern test
Skriv udeladelsen ind i opgaven
Når opgaven beskrives, skal det stå tydeligt, at belastning og lammelsesangreb ikke er en del af testen. Det beskytter både jer og testeren: I ved, hvad rapporten ikke dækker, og testeren har en klar ramme at arbejde i. Bed om, at udeladelsen også gentages i rapportens afsnit om omfang. En kunde eller revisor, der kun læser resuméet, skal ikke kunne få indtryk af, at tilgængeligheden er vurderet.
Notér også, hvilke systemer der er særligt følsomme over for trafik, så testeren kan tage hensyn. Det kan være en ældre fjernadgang, en lille webserver hos et hostingfirma eller en tjeneste, der deler forbindelse med kontorets internet. → Skrøbelige systemer
Under testen bør driften holde øje med belastning og svartider på de systemer, der testes. Selv en penetrationstest giver mere trafik end normalt, og det er bedre at opdage en påvirkning tidligt end at få en henvendelse fra brugerne. → Driftsovervågning under testen
Hvis I vil vide noget om DDoS-modstand
Spørgsmålet om tilgængelighed under angreb kan være relevant for virksomheden, men det besvares bedst ad flere veje.
- Begynd med aftalerne. Spørg internetudbyderen, hostingfirmaet og cloududbyderen, hvilken beskyttelse der indgår, og hvad der sker, når den aktiveres.
- Kortlæg afhængighederne. Hvilke tjenester deler forbindelse, og hvad rammes med, hvis én bliver overbelastet?
- Gennemgå beredskabet. Hvem kontakter hvem, hvis hjemmesiden eller fjernadgangen går ned, og hvordan arbejder medarbejderne imens?
- Overvej en planlagt simulering. Den skal aftales med alle de leverandører, trafikken passerer, og udføres efter platformens regler.
Det sidste punkt er en opgave for sig, med egen planlægning og eget ansvar. Det første til tredje punkt kan IT selv komme langt med, og svarene er nyttige, uanset om en simulering nogensinde bliver gennemført. De giver et billede af, hvor sårbar driften er over for et udfald, og hvem der skal handle. → Beredskabsplanen efter testen
Det skal I lade være med
- At antage, at den eksterne test dækker belastning. Det skal stå i opgaven, hvad der er med og ikke med.
- At bede testeren om at prøve lidt belastning. Det kræver en særskilt aftale og kan være i strid med platformens regler.
- At glemme hostingfirmaets og udbyderens vilkår. Trafik, der ligner et angreb, kan blive blokeret eller føre til en henvendelse.
- At læse en ren rapport som et svar om tilgængelighed. Rapporten svarer kun på det, testen undersøgte.
- At udelade følsomme systemer fra oplysningerne til testeren. Så kan testeren ikke tage hensyn.
Hvad kan og ikke kan konkluderes
En ekstern penetrationstest kan vise, hvilke svagheder der fandtes i internetsiden på testtidspunktet, og den kan pege på forhold, der har betydning for tilgængeligheden. Den kan ikke vise, hvor meget trafik jeres tjenester tåler, eller om beskyttelsen hos udbyderen virker, når den skal. Det kræver en anden type afprøvning, der er planlagt efter de regler, der gælder for de platforme, trafikken rammer.
Tjekliste til opgaven
- ☐ Står det i opgaven, at belastning og lammelsesangreb ikke indgår?
- ☐ Er testeren oplyst om systemer, der er følsomme over for trafik?
- ☐ Er cloududbyderens og hostingfirmaets regler læst?
- ☐ Overvåger driften belastningen under testen?
- ☐ Er det afklaret, hvilken DDoS-beskyttelse jeres aftaler indeholder?
- ☐ Er det besluttet, om spørgsmålet om tilgængelighed skal undersøges separat?
Kilder
- Microsoft Learn: Penetration testing (Azure): test af lammelsesangreb er ikke tilladt; simulering via godkendte partnere.
- AWS: Penetration Testing: lammelsesangreb er blandt de forbudte aktiviteter.
- AWS: DDoS Simulation Testing Policy: særskilte krav til DDoS-simulering.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Driftsovervågning under testen · Ekstern penetrationstest i praksis
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
