DDoS-skydd: bygg försvaret i lager

En DDoS-attack försöker inte läsa era filer eller stjäla lösenord. Den försöker göra tjänsten oanvändbar, och den lyckas genom att tömma den resurs som tar slut först: bandbredden in till nätet, anslutningstabellerna i brandväggen, processorns arbetsminne eller databasens lediga anslutningar.

Därför räcker ingen enskild produkt. Olika attacker tömmer olika resurser, och varje lager täcker ett eget slags haveri. Nedan går vi igenom lagren i den ordning de stoppar trafik, och avslutar med en runbook för läget när attacken redan pågår.

Vad attacken faktiskt tar slut på

Det hjälper att dela in attackerna efter vad de konsumerar i stället för efter vad de kallas. Samma trafikmängd kan vara harmlös i ett lager och dödlig i ett annat.

Typ av attack	Exempel	Vad som tar slut	Var den måste stoppas
Volymattack	UDP-flöden, DNS- och NTP-förstärkning, spridda attacker mot många adresser	Er nätlänk och länken till leverantören	Uppströms, hos driftleverantören eller i ett filtreringsnät
Tillståndsutmattning	SYN-flöden, anslutningsflöden, långsamma handskakningar	Anslutningstabeller i servrar, brandväggar och lastbalanserare	Hastighetsgränser i kanten, kärnparametrar, SYN-cookies
Applikationsskiktet	HTTP-flöden, cache-busting, långsamma förfrågningar, missbruk av API	Processor, arbetstrådar, databasanslutningar	CDN och WAF, cachelagring, gränser per endpoint

Tabellen är också en prioriteringsordning. Är attacken större än er upplänk spelar serverinställningarna ingen roll — paketen har redan vunnit när en lokal brandväggsregel ser dem. Volymskydd måste ligga uppströms.

Varför lagret ovanför er server avgör utfallet

Varje seriöst försvar börjar med kapacitet ni inte äger. Anycast-nät och filtreringstjänster sprider attacktrafiken över många platser, rensar den och skickar vidare bara det som ser ut som riktiga förfrågningar.

Tre frågor avgör om lagret håller:

Är skyddet påslaget hela tiden, eller aktiveras det först vid misstanke? Skydd som slås på vid upptäckt lämnar en lucka precis när attacken börjar.
Hur stor kapacitet finns framför er adress, och delas den med andra kunder?
Skickas trafiken via anycast, så att en volymattack späds ut geografiskt i stället för att en anläggning ska absorbera allt?

Det vanligaste misstaget är att tro att ett CDN löser hela problemet. Det är lager ett av flera.

Lås ursprungsadressen

Här hoppar många över ett steg som gör resten av arbetet verkningslöst. Får någon reda på serverns riktiga adress går den förbi CDN:et och träffar ursprunget direkt: direct-to-origin.

Var adressen läcker

DNS-historik. Gamla A-poster från tiden före proxyn ligger kvar i sökbara arkiv.
Certifikatloggar. Certifikat som utfärdats för ursprungsvärdnamnet är offentliga.
Subdomäner. Adresser som post., vpn., ftp. och dev. pekar ofta rakt mot samma server.
Mejlhuvuden. Utgående post kan bära ursprungsadressen i mottagningsraderna.
Äldre poster. MX, SPF och TXT som pekar på infrastruktur utanför skyddet.

Byt adress efter att skyddet är på plats, brandvägga ursprunget så att bara leverantörens publicerade intervall når port 80 och 443, och kontrollera exponeringen en gång i kvartalet. Ett penetrationstest verifierar det utifrån.

WAF: läser förfrågan, inte bara paketet

En nätverksbrandvägg ser en giltig TCP-anslutning och släpper igenom den. En WAF läser själva HTTP-förfrågan, och det är där applikationsattackerna bor: trasiga förfrågningar, försök att utnyttja kända brister och botflöden mot inloggning och sökfunktioner.

Regler att börja med

Aktivera leverantörens hanterade regler först, inklusive OWASP:s kärnregler, och lägg till egna för det som är specifikt för er applikation. Tre som ger mest: avvisa för stora kroppar på uppladdningssidor, kräv utmaning på administrativa sökvägar och sätt gränser per endpoint i stället för per sajt — annars skyddas billiga sidor och de dyra lämnas öppna.

Hastighetsbegränsning i flera nivåer

Hastighetsbegränsning är den mest kostnadseffektiva kontrollen ni har, och den som oftast är felkonfigurerad. Regler bara i webbservern hjälper inte mot trafik som mättar nätet först, och regler per IP-adress gör liten skillnad mot ett botnät med tusentals källor.

Lägg gränserna i tre nivåer:

I kanten: förfrågningar per adress, per nät och där det är motiverat per land.
I applikationen: per session, per API-nyckel och per inloggad användare.
Per endpoint: snäva gränser på inloggning, lösenordsåterställning, sökning och kassa, alltså de vägar som kostar mest att betjäna.

Använd glidande fönster eller hinkmodeller i stället för hårda tak per sekund, och svara med statuskod 429 och en Retry-After-rubrik. Då backar legitima klienter av i stället för att försöka igen ännu hårdare.

Tillståndsutmattning i TCP-stacken

Ett SYN-flöde fyller anslutningstabellen innan en enda HTTP-förfrågan har kommit fram. Åtgärderna är gamla och verkningsfulla: slå på SYN-cookies, höj kön för inkommande anslutningar så att den matchar er samtidighet, korta tidsgränserna och begränsa samtidiga anslutningar per källa i kanten. Mät före och efter — kopierade värden utan egen baslinje gör ofta saken värre.

Låt cachen ta smällen

En förfrågan som besvaras från cachen når aldrig ursprunget och tar varken arbetstråd eller databasanslutning. Allt som kan vara statiskt bör vara det: bilder, stilark, skript och HTML för besökare som inte är inloggade.

Cache-busting är dessutom en attackmetod i sig: slumpade frågeparametrar tvingar varje förfrågan hela vägen fram, så låt CDN:et bortse från ovidkommande parametrar på sidor som går att cacha. Träffsäkerheten är ett säkerhetsmått — faller den från 85 till 20 procent under en incident betalar ni ursprungets kostnad för attacktrafik.

Mät normalläget innan attacken

Ni kan inte försvara er mot det ni inte ser. Dokumentera normalläget i förväg: förfrågningar per sekund, byte in och ut, andel 4xx- och 5xx-svar, svarstid vid 95:e percentilen och antal anslutningar.

Larma på avvikelser i stället för absoluta tal. En femdubbling med stabil felfrekvens är ofta en lyckad kampanj, medan oförändrad trafik med stigande svarstider och fler anslutningar tyder på tillståndsutmattning. Nätflödesdata och applikationsloggar ger båda bilderna.

Runbook som är läst och övad

Under en attack är det sämsta tänkbara tillfälle att bestämma vem som ringer leverantören och vem som får slå på skärpt läge.

Det som ska stå på en sida

Vem som utropar en incident, och var.
Vem som kontaktar driftleverantören eller CDN-supporten, med kontonummer.
Vilka kontroller som slås på i vilken ordning, och vem som har mandat.
Vem som kommunicerar med kunder, och med vilken formulering.
När juridiska åtgärder eller polisanmälan aktualiseras, särskilt vid utpressning.

Öva den en gång i kvartalet med ett bordsövningsscenario. En runbook som ingen har läst är inredning.

Om attacken redan pågår

Arbeta i den här ordningen, från minst till mest ingripande:

Bekräfta att det är en attack. Titta på källor, förfrågningsmönster, vanligaste adresser och geografi. Jämför med en legitim kampanj innan ni blockerar något.
Identifiera lagret. Mättad bandbredd pekar uppströms, fulla anslutningstabeller mot nätverkslagret och hög processorbelastning på enstaka sidor mot applikationslagret.
Öppna ett ärende hos leverantören direkt. Uppströms filtrering tar tid att aktivera, så starta det innan diagnosen är klar.
Slå på kantens kontroller. Skärpt läge, hanterade WAF-regler, stramare gränser och en utmaning på de mest missbrukade vägarna.
Skydda ursprunget. Kontrollera att det bara tar emot trafik från CDN:et och blockera direkta anrop mot IP-adressen.
Kommunicera. Statusmeddelande först, supportkanaler sedan. Tystnad skadar mer än attacken.
Säkra bevisning. Spara loggar, tidsstämplar och paketfångster — de behövs mot leverantören, försäkringsbolaget och i en utredning.

Vad skyddet kostar i praktiken

Alternativ	Typisk kostnad	Passar
CDN i gratis- eller låg nivå	0–250 kronor i månaden	Bloggar, mindre företagssajter, tjänster med låg risk
Molnleverantörens grundskydd	Ingår i infrastrukturen	Arbetslaster som redan ligger i molnet
Hanterad WAF med DDoS-skydd	Cirka 500–25 000 kronor i månaden	Intäktskritiska tjänster och krav på rapportering
Dedikerad filtreringstjänst	Företagsavtal, ofta från 50 000 kronor i månaden	Högvärdiga mål inom spel, finans och offentlig sektor

Talet som avgör valet är vad en timmes driftstopp kostar er, gånger hur ofta ni räknar med att bli utsatta. För de flesta mindre verksamheter slår en välkonfigurerad låg nivå med inövad runbook en dyr apparat som ingen kan hantera.

Vanliga frågor

Går det att skydda sig helt mot DDoS-attacker? Nej. Vem som helst kan skicka trafik mot en publik tjänst. Det realistiska målet är att absorbera och filtrera den medan legitima besökare är kvar.

Räcker ett CDN för att stoppa en attack? Ett CDN hanterar volymflöden och mycket av missbruket i applikationsskiktet, men inte exponerat ursprung, dyra endpoints eller utmattade anslutningstillstånd. Det är ett lager av flera.

Hur skiljer jag en attack från en trafiktopp? Titta på sammansättningen, inte volymen. En topp från en geografi, med ovanliga klientprogram, stigande svarstider och oförändrad konvertering är en attack. En topp fördelad över era vanliga källor är oftast en kampanj som fungerar.

Vad bör ett mindre företag göra först? Lägg trafiken bakom ett CDN med skydd, lås ursprungsadressen, slå på hanterade WAF-regler och skriv runbooken på en sida — den ordningen täcker de vanligaste attackerna till lägst kostnad.

Behöver vi en dedikerad DDoS-leverantör? Bara om driftstoppet kostar mer än avtalet. Börja på CDN-nivån, mät exponeringen och uppgradera när ekonomin motiverar det.

Vill ni veta var ert försvar brister först? Prata med teamet så går vi igenom kant, ursprung och applikation tillsammans.

Så skyddar ni er mot DDoS-attacker i flera lager