Hvad er DDoS-angreb?
Et DDoS-angreb (Distributed Denial of Service) er et koordineret forsøg på at gøre en online tjeneste utilgængelig. Det sker typisk ved at sende meget store mængder trafik eller udnytte ressourcer i et tempo, som mål-systemet (eller en del af det) ikke kan håndtere. Formålet er ofte ikke at stjæle data, men at afbryde eller forringe tilgængeligheden.
“Distributed” betyder, at angrebet kommer fra flere kilder samtidig. Det gør det sværere at blokere alene via en enkel afsenderliste, fordi trafikken kan ligne “almindelig” aktivitet for mange observatører.
Hvordan virker DDoS, og hvilke typer findes der?
DDoS kan groft inddeles efter, hvilket lag eller hvilken ressource det påvirker. Nogle typer handler mest om volumener, andre om at udløse dyr behandling i systemet.
1) Netværks- eller båndbredderelateret overbelastning Her forsøger angriberen at fylde den tilgængelige netværkskapacitet. Når linket eller den samlede gennemstrømning er “fyldt”, kan legitime brugere opleve langsom respons eller timeouts, fordi deres trafik ikke kommer igennem.
2) Protokolrelateret pres Nogle angreb udnytter, at forbindelser og sessioner kræver håndtering i protokolstakken. Hvis angriberen kan skabe mange samtidige forespørgsler eller mønstre, der tvinger mål-systemet til at arbejde hårdt (for eksempel på connection- eller session-niveau), kan tjenesten blive træt af at behandle forespørgslerne.
3) Applikations- eller “layer 7”-påvirkning I applikationslag kan angriberen forsøge at ramme selve funktionen: webforespørgsler, API-kald, søgninger eller login-endepunkter. Her er mængden ikke nødvendigvis enorm i netværksvolumen, men behandlingen kan være dyr, og systemet kan blive overbelastet af CPU, hukommelse eller backend-ressourcer (for eksempel databaser eller tredjepartsafhængigheder).
Det er vigtigt at bemærke, at reelle angreb ofte kombinerer flere elementer. Derfor kan en løsning, der kun adresserer én type (for eksempel ren volumenkontrol), være utilstrækkelig.
Afgrænsning: DDoS vs. andre trusler
DDoS handler primært om tilgængelighed. Andre typer angreb kan have et andet mål—fx at kompromittere konti, stjæle data eller ændre indhold. Det betyder dog ikke, at DDoS “udelukker” andre mål; i praksis kan hændelser indeholde flere komponenter samtidig.
En praktisk måde at afgrænse på er at spørge:
- Hvad er den dominerende virkning? (utilgængelighed, ydelsesfald, fejlrate, timeouts)
- Hvilket spor i loggen forklarer effekten? (trafikmønstre, forbindelsesrate, ressourceforbrug i app/backend)
- Er det et forsøg på at overtage systemer eller manipulere data—eller kun at overvælde kapaciteten?
Hvad begrænser et “DDoS-svar”, og hvorfor kan resultater variere?
Der findes ikke én universel afhjælpning, fordi DDoS både kan variere i måltype og i angrebsstrategi. Fire konkrete begrænsninger, der ofte påvirker udfaldet:
Kapacitetsforskel og topologisk placering Hvis overbelastningen rammer et sted i kæden, hvor man ikke kan afbøde (eller hvor man ikke har tilstrækkelig “buffer” og kontrol), kan tjenesten stadig blive påvirket selv ved gode lokale tiltag.
Angrebsprofilens hastighed Nogle hændelser bygger hurtigt op. Hvis målinger og beslutninger om blokering kræver tid (for eksempel store kalibreringer eller manuel godkendelse), kan brugerne nå at opleve nedbrud, før afhjælpningen slår igennem.
Kendetegn som både kan ligne legitime brugere Ved applikationsnære angreb kan trafikken se “brugerlignende” ud. Her kan for aggressive regler give falske positiver og blokere rigtige brugere, mens for lempelige regler ikke stopper overbelastningen.
Afhængigheder og “blast radius” En tjeneste kan blive ramt via afhængigheder: CDN, DNS, API-gateways eller backend-komponenter. Selv hvis fronten klarer sig, kan backend-ressourcer gøre, at den samlede brugeroplevelse falder.
Da der ikke er leveret et specifikt teknisk setup eller miljø i dette materiale, er det mest korrekte at sige: forvent varierende resultater afhængigt af mål, arkitektur og angribers valg.
Praktiske kontrolpunkter: sådan kan du undersøge og vurdere en DDoS-hændelse
Hvis du vil være i stand til at placere et muligt DDoS-angreb korrekt, kan du bruge kontrolpunkter, der ikke kræver “magisk” viden:
-
Mål effekten først Overvåg tilgængelighed og brugeroplevelse: fejlrate, timeouts, responstid og pludselige ændringer i trafikmønstre.
-
Kig efter hvor ressourcen bliver presset Spor om presset primært ses i netværksindikatorer, protokolrelaterede metrics (som forbindelsesrate) eller i applikations-/backend-metrics (CPU, hukommelse, kølængder, databaseforespørgsler).
-
Sammenlign før/under/efter Notér baseline og ændringer. Hvis der er et skarpt skift i bestemte indikatorer samtidig med en funktionsnedgang, er det ofte et stærkt spor.
-
Vurder mønstre frem for enkelt-IP’er Ved distribuerede angreb kan enkeltkilder være mange og skifte. Kig derfor efter mønstre: rater, sessionsadfærd og samtidighed, frem for at fokusere på én eller få adresser.
-
Sæt en beredskabsplan op på forhånd For at reducere tid til handling er det nyttigt at have en plan for, hvem der gør hvad, hvilke metrics der tæller som “impact”, og hvordan man kommunikerer internt under en hændelse.
Hvis du kan besvare, hvilken type pres der dominerer (volumen, protokol, applikation), og hvor i kæden det rammer, får du et mere præcist beslutningsgrundlag—uden at konkludere for tidligt.
Hvilken information kan ændre svaret?
Svaret kan blive mere konkret, hvis du kender:
- hvilken tjeneste der er målet (web, API, login, download, intern proces)
- om problemet primært er netværk, protokol eller applikation
- hvilke afhængigheder der påvirkes (for eksempel backend, database eller tredjepartsleverandører)
- om hændelsen er kortvarig eller vedvarende
Uden de oplysninger er den bedste tilgang at holde sig til generelle, kontrollerbare principper: DDoS forstås som tilgængelighedspres fra distribuerede kilder, og korrekt placering kræver måling af effekt og hvor ressourcerne bliver påvirket.
