Hvad er et DDoS-angreb?

Et DDoS-angreb (Distributed Denial of Service) er et forsøg på at gøre en online tjeneste langsom eller utilgængelig ved at sende en stor mængde uønsket trafik eller anmodninger mod den. Målet er typisk ikke at stjæle data, men at forstyrre tilgængeligheden, så brugere ikke kan få adgang, og systemer ikke kan svare hurtigt nok.

Når belastningen bliver for høj, kan servere eller netværkskomponenter nå deres kapacitet. Resultatet kan være timeout-fejl, 5xx-fejl, meget lange svartider eller at bestemte funktioner (fx login eller checkout) bryder sammen først.

Enkelt model: hvor DDoS rammer din forretning

Tænk på din online forretning som et kædeled af ressourcer: netværk, webserver, applikation og database. Et DDoS-angreb kan ramme et eller flere led samtidigt.

I praksis kan det vise sig som:

  • Trafik- og ressourcestigninger, der ikke ligner normale kampagner eller spidsbelastning
  • Flaskehalse i overvågningen (fx CPU, samtidige forbindelser, kølængder eller netværksbåndbredde)
  • Ujævn tilgængelighed, hvor nogle sider virker, mens andre fejler
  • Forringelser i brugerflow (fx øget fejlrate i formularer eller afvisning af API-kald)

Det vigtige for forretningen er, at selv “begrænsede” problemer kan have stor effekt, fordi konvertering ofte falder ved friktion: fejl, langsomhed og manglende adgang koster salg og supportbelastning.

Typer og forskelle: volumetrisk vs. applikationsnær påvirkning

DDoS er ikke én ensartet teknik. I bred forstand kan angreb variere i, hvad de oversvømmer, og hvor i systemet de mærkes.

  • Volumetrisk påvirkning: Fokus på at fylde netværket eller den indkommende kapacitet, så trafik ikke kan håndteres.
  • Protokol-/serverpåvirkning: Fokus på at skabe mange anmodninger eller forbindelser, så systemet bruger tid på at håndtere dem.
  • Applikationsnær påvirkning: Fokus på at ramme funktioner i din software, så ressourcer bruges på at behandle anmodninger, selv hvis den samlede mængde ikke ser ekstrem ud.

En nyttig afgrænsning er derfor symptomer frem for antagelser: Hvis du primært ser enorme netværksmængder, er det ofte en volumetrisk problemtype. Hvis du ser høj fejlrate og udtømning af applikationsressourcer, kan det ligne en mere applikationsnær påvirkning. Uanset type er resultatet typisk det samme: tilgængelighed forringes.

Undtagelser og begrænsninger: hvad DDoS ikke er

Nogle driftsproblemer ligner DDoS, men har andre årsager. Det er vigtigt, fordi det ændrer hvad du bør kontrollere.

Mulige “forvekslingskilder”:

  • Legitime trafikspidser (fx kampagner, nyheder, sæson): Mønsteret ligner ofte kendte historiske perioder.
  • Fejlkonfiguration eller deployment: Brugere rammes typisk mere ensartet, og fejl kan knyttes til specifikke ændringer i kode eller opsætning.
  • Dårlig kapacitetsplanlægning: Belastning kan være normal, men overstiger hvad systemet er dimensioneret til.

En praktisk begrænsning er også, at “hvor meget” trafik en tjeneste kan tåle, varierer fra miljø til miljø. Derfor er det bedre at arbejde med observable tegn og tærskler i overvågningen end at antage, at ethvert usædvanligt peak automatisk er et DDoS-angreb.

Praktiske kontrolpunkter: sådan kan du vurdere påvirkningen

Når du vil forstå, om det ligner DDoS, kan du kontrollere data uden at antage for hurtigt:

  1. Overvåg netværk og applikation samtidigt Se efter sammenhæng mellem trafikmønster (fx indkommende rate) og applikationssymptomer (fx fejlrate, timeouts, kølængder). En DDoS-lignende hændelse ses ofte i flere lag samtidig.

  2. Sammenlign med baseline Brug historik for normale spidsbelastninger. Hvis toppe er markant anderledes i mønster (fx pludselige, lange eller bredt fordelte), er det et stærkere tegn.

  3. Identificér hvilke funktioner der fejler først Hvis kun bestemte endpoints eller funktioner rammes, kan det pege på en mere applikationsnær påvirkning. Hvis alt falder på samme tid, kan det være mere grundlæggende kapacitetsproblemer.

  4. Dokumentér og eskalér hurtigt Notér tidspunkt, varighed, observerede metrics og berørte brugerrejser. Det hjælper med både intern beslutning og ekstern rådgivning, hvis du har behov for den type support.

  5. Genopretning og kommunikation Når tilgængelighed påvirkes, er det afgørende at have en klar plan for, hvordan du håndterer brugere og supportkanaler. Fokusér på at minimere driftstid og informere brugerne korrekt om, hvad der sker.

Hvis du vil være forberedt, handler det overordnet om at kombinere løbende overvågning, tydelige tærskler for eskalering og en beredskabsplan for tilgængelighed—så du kan reagere systematisk, selv når årsagen er usikker.