Tilpasset DDoS-angrepsreduksjon med programmerbar flytbeskyttelse

Informatec Digital » Ressurser » Tilpasset DDoS-angrepsreduksjon med programmerbar flytbeskyttelse

Vi lever i en tid der nettverket er bindevevet i nesten alt vi gjør. Når et selskap mister tjenesten på grunn av et tjenestenektangrep, er det ikke bare et nettsted som går ned: salg, interne prosesser, kundeservice og i de mest alvorlige tilfellene viktige tjenester blir lammet. Derfor har tilpasset DDoS-begrensning med programmerbar flytbeskyttelse blitt en strategisk komponent i enhver moderne arkitektur.

Fremveksten av teknologier som Cloudflares Programmable Flow Protection for Magic Transit , bruken av tilpasset C-logikk distribuert som eBPF, integrasjon med skyer som AWS og Azure, og støtte fra spesialiserte forsvarstjenester har radikalt endret landskapet. Det er nå mulig å modellere hva som utgjør «god» eller «ondsinnet» trafikk på pakkenivå, skreddersy begrensninger til svært spesifikke UDP-protokoller (som de som brukes i online spill eller VoIP), og kombinere dette med forretningsintelligens og AI-løsninger som lærer av hvert angrep.

Hva er et DDoS-angrep, og hvorfor har det blitt et så alvorlig problem?

Et distribuert tjenestenektangrep (DDoS) har som mål å overbelaste et systems ressurser (servere, lenker, applikasjoner eller mellomliggende infrastruktur) ved å starte en flom av trafikk fra flere samtidige kilder. I motsetning til et klassisk DoS-angrep, der én enkelt kilde utløser angrepet, involverer et DDoS-angrep tusenvis eller til og med millioner av kompromitterte enheter, organisert i et botnett.

Motivasjonene bak DDoS-angrep er varierte: økonomisk utpressing, sabotasje blant konkurrenter, aktivisme, represalier mot journalister eller mediehus, eller rett og slett styrketester av nye botnett i «evnedemonstrasjonsmodus». Resultatet er imidlertid alltid det samme: utilgjengelighet av tjenester , alvorlig ytelsesforringelse og økonomisk og omdømmemessig skade.

De siste årene har det vært en jevn økning i hyppigheten og intensiteten til disse angrepene. Rapporter fra store sikkerhetsleverandører indikerer en vedvarende vekst i hypervolumetriske angrep (over 1 Tbps eller én milliard pakker per sekund), ofte rettet mot kritisk infrastruktur som finansielle tjenester, forsyningsselskaper og telekommunikasjon.

Typer DDoS-angrep: fra nettverket til applikasjonen

For å forstå hvordan tilpasset DDoS-begrensning fungerer, er det nyttig å se gjennom hovedkategoriene av angrep. Generelt sett kan vi gruppere dem i fire hovedfamilier, knyttet til ulike lag i OSI-modellen og de ulike ressursene de søker å utarme.

Nettverkslagsangrep (L3/L4) fokuserer på å utnytte nettverks- og transportprotokoller (IP, TCP, UDP, ICMP) for å tappe begrensede ressurser fra serveren eller mellomliggende infrastruktur: CPU, minne, brannmurtabeller, ventende tilkoblinger eller nettverksbuffere. Klassiske eksempler inkluderer SYN-flod (oversvømmelse av serveren med TCP-tilkoblingsforespørsler som aldri fullfører håndtrykket), UDP-flod til tilfeldige porter og ICMP-angrep.

Applikasjonslagsangrep (L7) retter seg mot mindre båndbredde enn ressursene til selve webapplikasjonen eller API-et. De genererer et stort volum av HTTP-forespørsler (GET/POST), komplekse spørringer til interne søkemotorer, kall til tunge API-er eller interaksjoner som, selv om de tilsynelatende er legitime, tvinger backend-, database- eller innholdsgenereringssystemene til å jobbe på sitt ytterste.

Volumetriske angrep: Her er målet å oversvømme lenken til den blir ubrukelig. Store mengder trafikk sendes, ofte ved å utnytte forsterknings- og refleksjonsteknikker på feilkonfigurerte UDP-tjenester, som offentlige DNS-servere (DNS, NTP, Memcached, CLDAP, SNMP, SSDP, Chargen, SLP, osv.), slik at en liten forespørselspakke genererer en mye større respons rettet mot det utgitte offeret.

Flervektorangrep er for tiden de mest komplekse. De kombinerer flere metoder (volumetriske, protokoll- og applikasjonsbaserte) og endrer strategi i sanntid når de oppdager at et forsvar lykkes. Et enkelt angrep kan starte som en UDP-flom, deretter gå over til en SYN-flom, og deretter vende til et Layer 7 HTTP-angrep, noe som tvinger offeret til å distribuere omfattende og koordinerte forsvar.

Den virkelige utviklingen av DDoS-angrep: fra Mirai til Tbps-hyperangrep

Teorien er grei, men problemets virkelige omfang blir tydelig i virkelige tilfeller. I løpet av det siste tiåret har vi gått fra angrep på hundrevis av Gbps til hendelser som lett overstiger flere terabit per sekund (Tbps) , med pakkehastigheter som når milliarder per sekund.

I 2016 nådde et angrep mot Dyn – en stor DNS-leverandør – omtrent 1,2 Tbps og tok midlertidig ned nettsteder som Twitter, GitHub, PayPal og Netflix. Mirai-botnettet, som rekrutterte over 600 000 IoT-enheter (rutere, kameraer og DVR-er med standard påloggingsinformasjon), ble brukt til å generere massiv trafikk til Dyns DNS-servere, sannsynligvis ved hjelp av en kombinasjon av UDP-flomding og forsterkningsteknikker.

Samme år ble sikkerhetsbloggen KrebsOnSecurity utsatt for et angrep på omtrent 623 Gbps , også drevet av Mirai. I nesten fire dager ble store UDP-pakker primært sendt til tilfeldige porter, noe som mettet lenkene og tvang frem omdirigering av trafikk til spesialiserte sikkerhetsbegrensningstjenester som Akamai Prolexic, som brukte signatur- og atferdsfiltrering.

I 2018 var GitHub målet for et 1,35 Tbps-angrep basert på Memcached-amplifisering. Angriperne sendte små UDP-forespørsler til Memcached-servere eksponert på port 11211, ved hjelp av en forfalsket GitHub IP-adresse. Hver liten forespørsel utløste svar 50–100 ganger større rettet mot GitHubs systemer, som ble tvunget til å omdirigere trafikk til opprydningssentre der Memcached-svarene ble filtrert for sine spesifikke mønstre.

I 2020 rapporterte Amazon at AWS Shield hadde dempet et angrep på 2,3 Tbps basert på CLDAP-refleksjon (UDP 389). Angrepsvektoren involverte å bombardere statsløse LDAP-servere med spørringer som genererte svar i høyt volum til offeret. AWS distribuerte trafikken over sitt globale nettverk og brukte filtreringsregler for det spesifikke CLDAP-mønsteret.

Nylig har botnett som Mēris dukket opp , og utnytter sårbarheter i MikroTik-rutere. I 2021 ble det registrert topper på 21,8 millioner forespørsler per sekund (RPS), og i 2022 nådde disse 46 millioner RPS mot Googles infrastruktur, med omtrentlige volumer på 1,3 Tbps. Tiltakene knyttet til dette involverte masseoppdatering av enheter, lukking av porter som 5678 og bruk av spesifikke filtreringsregler for Mēris-signaturen på nettverk som Cloudflare og Akamai.

I april 2025 rapporterte Cloudflare et hyperangrep på omtrent 6,5 Tbps og flere milliarder pakker per sekund. Ifølge analysen deres var det et uattribuert botnett med egenskaper som ligner på Mēris og Aisuru, som primært brukte direkte UDP-flom fra IoT-enheter og feilkonfigurerte servere, uten å kreve tradisjonell forsterkning. Forsvaret var avhengig av Cloudflares globale Anycast-nettverk, XDP/eBPF-redusering i kanten, dynamisk skrubbing og hastighetsbegrensning per IP og per region.

Og i mai 2025 skapte KrebsOnSecurity overskrifter igjen ved å motstå et angrep på omtrent 6,3 Tbps lansert av Aisuru-botnettet. I dette tilfellet ble rundt 585 millioner UDP-pakker generert per sekund i omtrent 40–45 sekunder. Google Project Shield, som beskyttet nettstedet, aktiverte umiddelbart aggressive filtreringsregler for uønsket UDP og omdirigerte trafikk til opprydningssentre distribuert over det globale nettverket, slik at virkningen på tjenesten var praktisk talt umerkelig.

Angripernes ressurser og teknikker: botnett, forsterkning og unnvikelse

For å oppnå disse svimlende tallene bruker angripere en rekke ressurser og kombinerer dem i henhold til målet sitt. Massive botnett er grunnlaget: nettverk av kompromitterte enheter over hele verden, rekruttert ved å utnytte kjente sårbarheter, standardpassord eller eksponerte administrative tjenester. Mirai, Mēris og Aisuru er familienavn, men utallige varianter finnes, som retter seg mot forskjellige produsenter eller tjenester.

Den andre store sårbarheten er feilkonfigurerte servere som fungerer som reflektorer. Enhver uautentisert UDP-tjeneste som svarer med mer data enn den mottar er en kandidat: DNS (port 53), NTP (123), Memcached (11211), CLDAP (389), SNMP (161), SSDP, Chargen, SLP, TFTP, Portmap, P2P-tjenester, eller til og med videospillprotokoller. Angriperen sender små forespørsler som forfalsker offerets IP-adresse, og serverne forsterker og returnerer svaret til det faktiske målet.

I DNS, for eksempel, kan en ANY-spørring til en åpen resolver multiplisere forespørselsstørrelsen med omtrent 28 ganger. I NTP nådde den gamle MONLIST-kommandoen forsterkningsforhold på 50–500x. Memcached er et ekstremt tilfelle: en liten forespørsel kan returnere hundrevis av kilobyte og nå forsterkningsforhold på titusenvis. CLDAP opererer med faktorer på 56–70x, mens SLP har blitt brukt med verdier som overstiger 2000x.

Videre forbedrer angripere sine unnvikelsesteknikker. IP-forfalskning er fortsatt en klassisk metode for å skjule den sanne opprinnelsen og utnytte refleksjon. Andre metoder inkluderer konstant roterende angrepsvektorer, blanding av kryptert trafikk for å tvinge høyere prosesseringsbelastning på forsvareren, bruk av "lav og langsom" teknikker (gradvis forbruk av ressurser uten åpenbare topper), eller å bringe trafikk nærmere applikasjonslaget, der den ligner mye mer på legitim trafikk.

I fasen før angrepet brukes masseskanningsverktøy som masscan eller zmap for å finne sårbare tjenester, sammen med utnyttelsessett spesielt utviklet for IoT eller servere. Under angrepet brukes trafikkgeneratorer som hping3, LOIC/HOIC eller optimaliserte C/Python-skript, mens angriperne selv kan bruke Wireshark, tcpdump og overvåkingsplattformer for analyse etter angrepet.

Faser i et DDoS-angrep og behovet for adaptivt forsvar

Selv om de ofte oppfattes som kaotiske trafikkutbrudd, går sofistikerte DDoS-angrep gjennom flere forskjellige faser . Først rekognoseringsfasen, der angriperen studerer den eksponerte overflaten, identifiserer domener, IP-adresser, åpne tjenester, CDN-er eller leverandører av sikkerhetsbegrensninger, og ser etter sårbarheter.

Deretter kommer enhetskompromittering, som innebærer å infisere datamaskinene som skal mate botnettet. Dette kan bety å utnytte sårbarheter i rutere, kameraer, fjernstyringssystemer eller servere, ofte ved å dra nytte av utdatert programvare eller standardlegitimasjon. Når de er rekruttert, kobler de seg til C2-infrastrukturen, som sentraliserer kommandoer og oppdateringer.

Utførelsesfasen av angrepet er vanligvis tidsbestemt til å sammenfalle med kritiske øyeblikk for offeret: markedsføringskampanjer, produktlanseringer, helger med færre ansatte på vakt, eller politisk eller mediesensitive datoer. Målet er å maksimere effekt og press . I neste generasjons angrep er det også en dynamisk tilpasningskomponent: botnettet overvåker offerets respons og endrer angrepsvektoren sin hvis det oppdager effektiv begrensning.

På forsvarssiden nødvendiggjør dette utforming av like tilpasningsdyktige strategier. En statisk brannmur eller båndbreddeterskel er ikke lenger tilstrekkelig: systemer som er i stand til å oppdage trafikkavvik i sanntid , korrelere hendelser, distribuere nye regler underveis og skalere ressurser (databehandling, lagring og nettverkskapasitet) på forespørsel er påkrevd.

En fersk studie viste at DDoS-angrep mot kritisk infrastruktur har vokst med mer enn 50 % på fire år, og at de ofte brukes som et røykteppe for andre inntrenginger, som for eksempel utplassering av løsepengevirus mens sikkerhetsteamet fokuserer på å «slukke brannen» i tjenestenekt.

Tradisjonell avbøtende tiltak: skrubbingsentre, CDN-er, brannmurer og WAF-er

Profesjonelt DDoS-forsvar er avhengig av en kombinasjon av teknologier og leverandører. Den mest karakteristiske komponenten er trafikkrensesentre , store distribuerte infrastrukturer som kan absorbere titalls Tbps og filtrere ondsinnet trafikk før de bare returnerer gyldige tilkoblinger til klienten.

Selskaper som Netscout/Arbor, Akamai/Prolexic, Cloudflare, Radware, Imperva og AWS Shield administrerer globale nettverk med flere tilstedeværelsespunkter. Når et angrep oppdages, blir trafikk som er ment for offerorganisasjonen omdirigert (via BGP-endringer eller DNS-oppdateringer) til disse sentrene, hvor filtre brukes basert på signaturer, atferd, svartelister, statistisk analyse og tilpassede regler.

Parallelt distribuerer mange organisasjoner lokale anti-DDoS-enheter i sine egne datasentre eller datasentrene til internettleverandørene sine. Enheter som Arbor TMS, Radware DefensePro, FortiDDoS eller visse F5-løsninger er ansvarlige for å oppdage og redusere angrep opp til en bestemt kapasitetsgrense. Det er vanlig praksis å kombinere disse lokale enhetene med en skybasert skrubbingsløsning for angrep som overskrider kapasiteten deres.

CDN-er og Anycast-arkitekturer – som de fra Cloudflare, Akamai, Fastly eller Google Cloud CDN – legger til et ekstra lag med forsvar ved å spre belastningen geografisk. Ved å publisere en tjeneste bak et CDN fordeles trafikken på tvers av flere noder, og volumetriske angrep fortynnes ved at de ikke konsentreres på ett enkelt punkt. Videre integrerer de vanligvis webapplikasjonsbrannmurer (WAF-er) og hastighetsbegrensende policyer på HTTP-nivå.

Til slutt lar nettverksbrannmurer (Cisco, Palo Alto, iptables på Linux, osv.) og spesialiserte WAF-er (ModSecurity, Cloudflare WAF, AWS WAF) deg filtrere trafikk etter IP-adresse, port, flagg og applikasjonsmønstre . Selv om de alene ikke vil stoppe et Tbps-angrep på stamnettnivå, er de viktige for å blokkere kjente angrepsvektorer, begrense mistenkelige tilkoblinger og beskytte lag 6 og 7 i stakken.

Programmerbar strømningsbeskyttelse og tilpasset begrensning med Magic Transit

I denne sammenhengen med stadig mer komplekse angrep og stadig mer spesifikke protokoller, dukker det opp løsninger som Cloudflares Programmable Flow Protection for Magic Transit , som markerer et kvalitativt sprang: de lar selskaper skrive sin egen avbøtende logikk og distribuere den direkte på en global leverandørs nettverk.

Ideen er enkel, men kraftig: Magic Transit-kunder kan laste inn tilstandsfulle pakkebehandlingsprogrammer skrevet i C. Cloudflare validerer, kompilerer og transformerer disse programmene til eBPF, og kjører dem i brukerområdet innenfor sin globale infrastruktur. Dette lar dem inspisere applikasjons-UDP-trafikk på en protokollbevisst måte: forstå overskrifter spesifikke for et online spill, et høyfrekvent handelssystem, VoIP-tjenester eller strømmeplattformer, og bestemme, pakke for pakke, hva som skal tillates og hva som skal blokkeres.

Denne tilpassede logikken integreres med Flowtrackd, Cloudflares plattform for tilstandsbasert mitigasjon. Funksjonen støtter både symmetriske og asymmetriske topologier, men i denne lukkede betafasen fokuserer den på å analysere innkommende trafikk. All administrasjon håndteres gjennom Cloudflare API, med endepunkter for opplasting av programmer, oppretting av tilknyttede regler, liste opp konfigurasjoner eller sletting av dem etter hvert som behovene endrer seg.

Den viktigste konklusjonen her er at vi ikke lenger bare er avhengige av generiske leverandørsignaturer og heuristikker. Et videospillselskap kan for eksempel tydelig definere den legitime flyten av sin proprietære UDP-protokoll (håndtrykk, posisjonsmeldinger, keep-alive osv.) og hvilke mønstre som er karakteristiske for et angrep. Denne logikken kompileres og distribueres på tvers av alle Cloudflare-tilstedeværelsespunkter, noe som bringer beslutningen nærmere nettverkskanten.

For miljøer med tilpassede protokoller eller applikasjoner med svært høye latenskrav, er denne DDoS-angrepsreduksjonen med programmerbar flytbeskyttelse banebrytende: den legger til et lag med forretningsspesifikk intelligens i tillegg til standardforsvar. Og når den kombineres med skytjenester som AWS eller Azure, og med tilpassede programvareløsninger (som de som er utviklet av selskaper som spesialiserer seg på AI og analyse, som Q2BSTUDIO), muliggjør den enda større automatisering av regeldeteksjon og oppdateringer basert på nye trusler.

Hvorfor internettleverandører og organisasjoner trenger avansert DDoS-begrensning

Internettleverandører (ISP-er) og store organisasjoner er i frontlinjen. Et tilstrekkelig stort angrep kan overvelde ikke bare én enkelt kunde, men en hel del av en operatørs nettverk, noe som forårsaker kaskadeavbrudd som rammer tusenvis av brukere. Derfor har DDoS-begrensning blitt et essensielt krav, ikke et valgfritt tillegg.

Fra et forretningsperspektiv er konsekvensene av å ikke forsvare seg tydelige: avbrudd i tjenesten, brudd på tjenestenivåavtaler (SLA-er), kontraktsmessige gebyrer, direkte tap av inntekter og kundeavgang til konkurrenter som oppfattes som mer pålitelige. Hvis en kritisk applikasjon ikke er tilgjengelig når brukeren trenger den, vil de naturligvis søke alternativer.

I sektorer som bank, forsikring, forsyningsselskaper og helsevesen kan virkningen strekke seg utover det økonomiske: forstyrrelser i fysiske prosesser , driftsrisikoer og forstyrrelser i viktige tjenester. Videre er det en omdømmekostnad som er vanskelig å dekke når et merke er assosiert med et «systemned» i timevis på sosiale medier og i pressen.

For å gjøre vondt verre, brukes DDoS-angrep ofte som dekke for mer skadelige angrep. Mens sikkerhetsteamet fokuserer på å håndtere trafikkøkningen, kan angripere forsøke å bevege seg sidelengs innenfor nettverket, distribuere løsepengevirus eller stramme inn data. Med andre ord fungerer DDoS-angrep som lokkeduer og distraksjoner i flertrinnsangrep.

Moderne løsninger for risikobegrensning, både lokalt og i skyen, reduserer nedetid betydelig, opprettholder forretningskontinuitet og beskytter både lokale eiendeler og offentlige skyressurser. Nøkkelen er deres evne til å skalere automatisk for å håndtere massive trafikktopper og tilby klare garantier for kapasitet og responstid.

Spesifikke avbøtende teknikker: fra hastighetsbegrensning til blackholing

Utover de store teknologiske blokkeringene finnes det en rekke spesifikke teknikker som brukes daglig for å bekjempe ulike typer angrep. En av de mest grunnleggende er perimeterfiltrering ved hjelp av brannmurer og tilgangskontrolllister (ACL-er) på rutere og svitsjer, som blokkerer pakker basert på kilde-IP-adresse, destinasjons-IP-adresse, porter, TCP-flagg eller størrelse.

En annen klassisk komponent er hastighetsbegrensning , både på lag 3/4 og i HTTP. På Linux-systemer tilbyr iptables moduler som hashlimit eller SYNPROXY for å kontrollere hvor mange tilkoblinger eller pakker per sekund som aksepteres fra en enkelt IP-adresse. På applikasjonsnivå kan proxyer som Nginx eller HAProxy sette grenser for forespørsler per klient eller per rute.

For lag 7-angrep er det svært nyttig å implementere utfordringer eller ekstra autentisering . CAPTCHA-er, JavaScript-utfordringer og lignende mekanismer gir bedre skille mellom virkelige nettlesere og automatiserte roboter, noe som reduserer belastningen på den faktiske applikasjonen. I TCP hjelper teknikker som SYN-informasjonskapsler serveren med å unngå å måtte lagre tilstand for hvert tilkoblingsforsøk før håndtrykket er fullført.

Når volumet av et angrep er uhåndterlig selv for avbøtende infrastruktur, kan BGP blackholing brukes : Internettleverandøren annonserer ruten til det angrepne nettverket som et "svart hull", og forkaster all trafikk som er ment for det prefikset før den kommer inn i ryggraden. Det er en siste utvei, fordi det gjør tjenesten utilgjengelig, men det forhindrer at angrepet påvirker andre deler av nettverket.

Tjenester for skyrensing – som de som tilbys av Cloudflare, Akamai, AWS Shield, Google Project Shield, Radware og andre – lar deg rute all trafikk til datasentrene deres og rense den der, ved å bruke spesifikke regler for vektorer som Memcached-amplifisering, CLDAP, DNS, NTP, uforsterket UDP-flod og så videre. Hvert blokkerte angrep mater maskinlæringsmodeller og signaturdatabaser som brukes i fremtidige tiltak for å redusere risikoen.

God praksis og lærdommer i møte med nåværende DDoS-angrep

Flere klare lærdommer kan trekkes fra de store hendelsene de siste årene. Den første er at det er avgjørende å sikre IoT-enheter : mye av kraften til botnett som Mirai, Mēris eller Aisuru kommer fra hjemmerutere, kameraer og andre enheter med utdatert fastvare og fabrikkinnstilte passord.

Det andre er at vi må eliminere forsterkningsvektorer i våre egne nettverk: deaktivere unødvendige UDP-tjenester, filtrere utgående NTP-, DNS- eller Memcached-trafikk, bruke brannmurregler som bare tillater spørringer fra autoriserte områder, og regelmessig gjennomgå eksponerte porter. Enhver feilkonfigurert server kan bli en forsterker for en angriper.

Tidlig oppdagelse av avvik er også viktig . Verktøy som NetFlow, sFlow, IDS/IPS (Snort, Suricata), logganalyseplattformer eller SIEM-er bør konfigureres til å varsle så snart uvanlige trafikktopper, plutselige endringer i tilkoblingsmønstre eller kjente angrepssignaturer dukker opp. Jo raskere responsen aktiveres, desto mindre tid er det for angrepet å eskalere.

I webmiljøer er det nesten obligatorisk å bruke oppdaterte WAF-er, CAPTCHA-er når de passer brukeropplevelsen, og mellombuffere eller CDN-er for å absorbere noe av belastningen. På systemnivå reduserer aktivering av SYN-informasjonskapsler, justering av terskler for samtidige tilkoblinger og lukking av eventuelle ikke-essensielle tjenester angrepsflaten.

Til slutt bør alle organisasjoner ha en dokumentert DDoS-beredskapsplan : en håndbok med klare trinn, utpekte ansvarlige parter, tekniske kontakter hos leverandører av tiltaksbegrensninger og internettleverandører, og forhåndsdefinerte kriterier for når man skal aktivere skrubbing, når man skal be om blackholing, eller når man skal degradere ikke-essensielle funksjoner for å beskytte kjernevirksomheten.

Trenden peker mot stadig raskere, mer intense og adaptive angrep, men også mot smartere og mer tilpassbare forsvar. Ved å utnytte mulighetene til løsninger som Programmable Flow Protection, kombinert med konstant trafikkovervåking, beste konfigurasjonspraksis og redundante skyarkitekturer, kan bedrifter fortsette å operere normalt selv midt i en pakkestorm, og beskytte ikke bare dataene sine, men også omdømmet og kundenes tillit.