DDoS-beskyttelse – arkitektur og beredskap

Et tjenestenektangrep prøver å gjøre en tjeneste treg eller utilgjengelig. DDoS betyr at forsøket kommer distribuert fra mange kilder, men konsekvensen trenger ikke skyldes rekordstor trafikk. En dyr søkefunksjon, liten tilkoblingspool eller ekstern avhengighet kan være nok til å velte hele tjenesten.

God beskyttelse begynner derfor med spørsmålet: hvilken ressurs går tom først, og hvilken funksjon må fortsatt virke?

Tre hovedtyper belastning

Et angrep kan kombinere lagene. En WAF kan redusere bestemte HTTP-mønstre, men hjelper ikke hvis nettverksforbindelsen er mettet før forespørslene når WAF-en.

Lavt volum kan ha stor effekt

Angriperen leter etter asymmetri: en billig forespørsel som utløser dyrt arbeid hos målet.

Eksempler:

• ett søk starter mange databaseoperasjoner
• passordreset sender e-post og skriver til flere systemer
• en rapport genereres på nytt for hver forespørsel
• store filer hentes fra origin uten cache
• en tredjeparts betalings- eller identitetstjeneste har lav kvote
• hver ny klient oppretter kostbare TLS- eller backend-forbindelser
• autoskalering øker ressurser og kostnad uten øvre grense

NSMs råd om forebyggelse av tjenestenektangrep fremhever nettopp flaskehalser, ytre beskyttelse, skaleringsgrenser, overvåking og plan for redusert funksjon.

Definer hva som skal være tilgjengelig

Ikke behandle «nettsiden» som én funksjon. Prioriter:

Bestem på forhånd hvem som kan redusere funksjon, hvilke data som kan gå tapt og hvordan brukeren får korrekt beskjed.

Kartlegg hele leveringskjeden

Beskyttelsen er ikke sterkere enn svakeste nødvendige ledd:

DNS
  → nettverk / edge / CDN
  → WAF / lastbalanserer
  → origin
  → applikasjon og cache
  → database, kø og lagring
  → identitet, betaling, e-post og andre leverandører

For hvert ledd, dokumenter:

• eier og nødnummer
• kapasitet og kvoter
• protokoller, porter og vertsnavn
• avhengigheter
• automatisk og manuell mitigering
• kostnadsmodell ved trafikkøkning
• telemetri og lagringstid
• failover- og feilmodus
• hva som skjer hvis kontrollplanet er utilgjengelig

En CDN-kontrakt hjelper lite hvis DNS, innlogging eller databasen fortsatt er et ubeskyttet enkeltpunkt.

DNS må tåle hendelsen

Hvis autoritative navnetjenere ikke svarer, finner brukerne verken edge eller statusinformasjon. Vurder:

• distribuert/anycast DNS hos egnet leverandør
• kapasitets- og DDoS-vilkår for DNS-planen
• at alle nødvendige soner og underdomener er dekket
• separate administrator- og gjenopprettingskanaler
• overvåking fra flere nettverk
• trygg endringskontroll og DNSSEC-drift

DNSSEC beskytter integritet, ikke kapasitet. Anycast kan spre belastning, men er heller ikke en garanti uten nok kapasitet og god drift.

CDN og reverse proxy

Et CDN eller edge-nettverk kan:

• svare fra distribuerte punkter
• cache statisk og cachebart innhold
• absorbere eller filtrere mye trafikk før origin
• terminere forbindelser nær brukeren
• tilby rate-, bot- og DDoS-kontroller

Men «CDN aktiv» betyr ikke at alt er dekket:

• ukachede og dynamiske forespørsler kan fortsatt treffe origin
• andre porter og protokoller kan gå utenom
• DNS-only-verter kan peke direkte til serveren
• opprinnelig IP kan være kjent fra gammel DNS eller andre tjenester
• planen kan ha grenser for forespørsler, mitigering, support eller kostnad
• cachemiss kan brukes til å forsterke belastningen på backend

Les CDN forklart uten leverandørløfter for cachearkitekturen.

Lås origin uten å miste nødtilgang

Hvis origin kan nås direkte, kan angriperen omgå edge-beskyttelsen. Kontroller:

• nettverksregler som bare tillater forventet proxy-/plattformtrafikk
• autentisert forbindelse eller klientsertifikat der det støttes
• IPv4, IPv6 og alternative porter
• gamle vertsnavn og DNS-historikk
• direkte forespørsler med manipulert Host
• administrativ tilgang gjennom en separat, beskyttet kanal

En hemmelig HTTP-header alene er svak hvis den kan lekke i kode eller logger. En statisk liste over leverandør-IP-er må oppdateres og testes uten å åpne eller stenge feil trafikk.

Cache før du skalerer dyrt arbeid

Skalering hjelper bare hvis underliggende ressurser følger med. Ti nye applikasjonsnoder beskytter ikke en database med samme tilkoblingsgrense.

Bruk flere tiltak:

• cache offentlige svar der semantikken tillater det
• sammenslå like forespørsler og bruk kø for dyrt arbeid
• sett tidsavbrudd og samtidighetsgrenser
• bruk belastningsvern mellom tjenester
• returner et billig, kontrollert feilsvar ved overlast
• prioriter kritiske operasjoner
• ha maksimum for autoskalering og kostnad

Et kostnadstak må kombineres med degradert modus. Ellers byttes en økonomisk hendelse bare mot full nedetid når taket nås.

Ratebegrens etter ressurs og identitet

Én global grense per IP er sjelden nok. Bedriftsnett, mobiloperatører og proxyer kan samle mange legitime brukere på samme IP, mens angripere fordeler trafikken.

Vurder signaler som:

• konto eller sesjon
• API-nøkkel og klient
• rute og operasjonens beregningskostnad
• feilrate og tidligere mønster
• IP, nettverk og geografi
• kølengde og backend-helse

En søkerute kan trenge lavere rate enn en cachet informasjonsside. Passordreset må hindre misbruk uten at angriperen kan sperre alle brukere ved å oppgi adressene deres.

Se rate limiting uten enkle IP-myter .

WAF hjelper på applikasjonslaget

En WAF kan blokkere bestemte forespørsler, kjente mønstre og misbruk av ruter. Den kan ikke absorbere all nettverkstrafikk eller forstå all forretningslogikk.

Utfordringer som CAPTCHA kan redusere noen typer automatisering, men:

• de kan hindre legitime brukere og hjelpemidler
• API-er og maskin-til-maskin-trafikk kan ikke løse dem
• angripere kan bruke ekte nettlesere eller løsetjenester
• tredjepartsskriptet kan gi personvern- og tilgjengelighetskonsekvenser

Bruk utfordring målrettet og ha en tilgjengelig alternativ flyt. WAF-guiden forklarer loggmodus, origin-bypass og smale unntak.

Overvåk flaskehalsene, ikke bare total trafikk

Et brukbart normalbilde inkluderer:

• DNS-feil og svartid
• båndbredde, pakker og forbindelser
• forespørsler per vertsnavn, rute og metode
• cachetreff og trafikk videre til origin
• responstid i percentiler, ikke bare gjennomsnitt
• 4xx/5xx, timeouts og avbrutte forbindelser
• CPU, minne, filbeskrivelser og tilkoblingspooler
• databaseoperasjoner, låser og kølengde
• tredjepartskvoter og feil
• autoskalering, egress og løpende kostnad
• forretningsutfall som fullførte innlogginger eller bestillinger

Legg overvåking og varslingskanal slik at de ikke forsvinner sammen med tjenesten. En status-side under samme angrepne DNS- og hostingkjede kan bli utilgjengelig samtidig.

Skille angrep fra egen feil og legitim trafikk

En markedsføringskampanje, nyhetshendelse, feil i en klient eller intern løkke kan ligne DDoS. Før irreversible tiltak:

1. sammenlign med normal trafikk per rute og kilde
2. se om en ny release eller konfigurasjon sammenfaller med feilen
3. kontroller database, kø og tredjepart
4. undersøk om ekte kunder rapporterer et legitimt rush
5. korreler edge-, origin- og applikasjonsdata

Geoblokkering kan gi rask avlastning når virksomheten kjenner sitt normale marked, men angripere kan bruke noder i tillatte land og legitime brukere kan være på reise eller VPN. Bruk den som et dokumentert, reversibelt tiltak—ikke som universell løsning.

Minimal responsplan

Før hendelsen

• oppdaterte kontaktpunkter hos DNS, CDN, sky, ISP og hendelsespartner
• roller for teknisk ledelse, kommunikasjon og forretningsbeslutning
• terskler for automatisk og manuell mitigering
• godkjent degradert modus per kritisk funksjon
• kostnadsgrenser og fullmakt til å øke dem
• uavhengig administrativ og kommunikativ kanal
• ferdige, testede regelendringer og rollback

Under hendelsen

1. Bekreft omfang, starttid og berørte funksjoner.
2. Beskytt administrativ tilgang og bevar telemetri.
3. Kontakt oppstrøms leverandør med identifikatorer og målinger.
4. Prioriter kritiske funksjoner og aktiver degradert modus.
5. Sett inn målrettet rate, cache, blokkering eller kapasitetsendring.
6. Følg effekt, falske positiver, kostnad og angriperens tilpasning.
7. Kommuniser fakta og alternativ kanal til brukere og partnere.

Etter hendelsen

• fjern midlertidige blokker og ekstra kapasitet kontrollert
• kontroller data, køer og duplikater før normal drift
• bevar tidslinje, logger, kostnad og leverandørrespons
• avgjør om hendelsen skjulte andre angrep
• oppdater arkitektur, terskler og kontaktliste
• test forbedringene uten uautorisert storskala trafikk

NCSCs minimale DoS-responsplan legger samme vekt på å forstå hendelsen, velge riktig forsvar, kommunisere og gjenopprette kontrollert.

Trussel eller krav om betaling

Et utpressingskrav kan komme før, under eller uten et reelt angrep. Ikke la en enkelt driftsoperatør forhandle eller betale fra normal e-posttråd.

• bevar meldingen og tekniske hoder
• varsle ledelse og sikkerhets-/hendelsesansvarlig
• kontakt relevante leverandører og eventuelt politi/myndighet etter virksomhetens plan
• involver juridisk, forsikring og kommunikasjon der det er relevant
• ikke følg lenker eller verifiser «bevis» i et ukjent vedlegg
• styrk beredskapen uten å avsløre intern kapasitet til avsenderen

Et krav kan også være ren svindel. Behandle både budskapet og eventuell trafikk som separate bevis.

Test uten å skape egen nedetid

Ikke kjør uavtalt volumtest mot produksjon, ISP eller beskyttelsestjeneste. Den kan bryte vilkår, utløse mitigering og ramme andre kunder.

Bruk:

• skrivebordsøvelse med leverandører og ledelse
• kontrollert test av alarmer og kontaktvei
• funksjonstest av rate, cache og degradert modus
• lav og avtalt belastning mot identifiserte flaskehalser
• verifisering av origin-lås og alternative protokoller
• planlagt gjenoppretting og rollback

Avtal mål, stoppkriterier, tidspunkt, kildesystemer og hvem som kan avbryte.

Velge beskyttelse og leverandør

«Ubegrenset DDoS-beskyttelse» må oversettes til tekniske og kontraktsmessige svar. Et tjenestekreditt etter nedetid er ikke det samme som at tjenesten fortsatte å virke.

Hva gjelder Vymos nettside?

Vymos standardtilbud er én enkel bedriftsside som Vymo setter opp og hoster. Kunden får ikke et selvbetjent DDoS-panel, egen scrubbingavtale, kundestyrte WAF-regler eller en publisert tilgjengelighets-SLA som del av standardtilbudet.

Den begrensede funksjonsflaten gjør en standard informasjonsside enklere å beskytte enn en nettbutikk eller innlogget applikasjon, men den lover ikke uavbrutt tilgjengelighet under ethvert angrep.

Har virksomheten kritiske transaksjoner, innlogging, API, store kampanjer eller et dokumentert tilgjengelighetskrav, må arkitektur, overvåking, respons, kapasitet og pris avtales separat. Beskriv kritiske ruter, trafikk, avhengigheter og ønsket degradert modus før bestilling. Den gratis enkle nettsiden inkluderer ikke en skreddersydd DDoS-beredskapsleveranse.