Vad är en DDoS-attack? Teknik, nivåer och försvar

En DDoS-attack är försöket att göra en tjänst onåbar genom konstgjord överbelastning, utfört samtidigt av mycket många olika avsändare. Förkortningen står för Distributed Denial of Service, alltså för en distribuerat framkallad tjänstevägran. Det som attackeras är varken innehållet på en server eller en säkerhetslucka i dess programvara, utan en resurs som är ändlig: ledningens bandbredd, nätverkskortets paketfrekvens, en plats i en av kärnans tillståndstabeller eller den processortid som applikationen lägger på en enda förfrågan. Är en av de fyra resurserna upptagen kommer riktiga användare inte längre fram, och det utan att någon har brutit sig in i systemet.

Det här inlägget är ingången till ämnet. Det förklarar de tre nivåer som attacker sker på, med vilka förstärkningsfaktorer en byte förfrågan blir 51 000 byte svar, varifrån attackkapaciteten kommer och vad den kostar på marknaden, hur du känner igen en attack på dina egna mätvärden, vad som fortfarande hjälper på servern själv och var exakt den gränsen går. Alla siffror är angivna med källa, så att du kan kontrollera dem. Står din tjänst just nu: läs först avsnittet "Vad du ska göra vid en attack" och mät i stället för att skruva.

Vad en DDoS-attack är rent tekniskt

Varje DDoS-attack lever av en asymmetri: att skicka ett paket måste kosta angriparen mindre än det kostar målet att bearbeta samma paket. Allt annat är bara frågan om var den asymmetrin är störst. Det finns exakt fyra ställen, och vart och ett har en hård övre gräns som går att räkna ut.

Ledningens bandbredd. En anslutning med 1 Gbit/s transporterar 125 megabyte per sekund, inte mer. Den som skickar mer skapar förluster, och förlusterna träffar dina användares paket lika hårt som angriparens, eftersom en full anslutning inte väljer.

Paketfrekvensen. Det minsta tillåtna ethernetpaketet är 64 byte långt och upptar med preambel och paketlucka 84 byte på ledningen. I 1 Gbit/s får runt 1,49 miljoner av dem plats per sekund. En vanlig serverkärna bearbetar beroende på CPU och nätverkskort några hundratusen innan den börjar förkasta. Paketfrekvensen är därför nästan alltid den gräns som nås före bandbredden.

Tillståndstabellerna. Kärnan håller reda på halvöppna TCP-anslutningar och paketflöden. De tabellerna är begränsade till antalet, inte i bit per sekund. De går att fylla med mycket lite bandbredd, om varje paket bär en ny avsändaradress.

Applikationens processortid. En sökförfrågan, ett inloggningsförsök med lösenordskontroll eller en serverförfrågan som lämnar tillbaka en hel mod-lista kostar målet tusenfalt mer än avsändaren. Här behöver en verksam attack ofta inte ens 10 Mbit/s.

DoS och DDoS: skillnaden som går att mäta

Den begreppsliga grunden ger RFC 4732, "Internet Denial-of-Service Considerations", en informationell publikation från IETF i november 2006. Där heter det ordagrant: "A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work." En DoS-attack är alltså definierad via verkan, inte via antalet källor. Distribuerad, alltså DDoS, är den när de källorna är talrika och oberoende av varandra.

Praktiskt räknas skillnaden på exakt ett ställe: på längden av din blockeringslista. En DoS-attack ur en källa avslutar du med en regel. Cloudflare har i maj 2025 dokumenterat en attack som kom från 122 145 olika källadresser i 161 länder och 5 433 autonoma system, i snitt 26 855 nya adresser per sekund, som mest 45 097. Mot något sådant finns ingen blockeringslista som växer snabbt nog, och varje post i den kostar dessutom minne och söktid på den enhet som ändå redan är överbelastad.

Den gemensamma vägledningen "Understanding and Responding to Distributed Denial-of-Service Attacks" från CISA, FBI och MS-ISAC delar in attacker i exakt tre tekniker: volymetriska, protokollrelaterade och applikationsrelaterade. Den tredelningen är den mest användbara som finns, eftersom den samtidigt beskriver vilken av dina fyra resurser som attackeras och var försvaret måste sitta.

De tre nivåerna i en DDoS-attack

Volymetriska attacker på lager 3 och 4

En volymetrisk attack vill ingenting annat än att fylla ledningen framför målet. Mätningen sker i bit per sekund. Medlet är som regel en UDP-flood, eftersom UDP inte känner någon uppkoppling som man skulle kunna kräva, och eftersom avsändaradresser går att förfalska.

Det för närvarande största offentligt dokumenterade exemplet: Cloudflare rapporterar för tiden fram till slutet av 2025 en automatiskt avvärjd attack med 31,4 Tbit/s som varade i 35 sekunder. Det är kapaciteten hos runt 31 400 serveranslutningar med 1 Gbit/s, samtidigt, under en dryg halvminut. I samma rapport står ett andra värde som gör storleksordningen mer gripbar än toppvärdet: under 2025 har samma operatör avvärjt 47,1 miljoner DDoS-attacker, en ökning med 121 procent mot året innan, i snitt 5 376 attacker per timme.

Det bättre dokumenterade fallet från maj 2025 visar hur en sådan attack ser ut när man tar isär den: 7,3 Tbit/s som mest, 37,4 terabyte data på 45 sekunder, alltså i snitt runt 830 gigabyte per sekund. En ledning med 1 Gbit/s hade behövt drygt tre dygn för samma datamängd. 99,996 procent av trafiken var rena UDP-floods, fördelade över i snitt 21 925 målportar samtidigt, som mest 34 517. Den fördelningen över alla portar är typisk: angriparen vet inte vilken port som är den viktiga, alltså tar han alla.

Protokollattacker: tabellerna, inte ledningen

En protokollattack utnyttjar att kärnan måste hålla reda på tillstånd. Standardexemplet är SYN-flooden: angriparen skickar TCP-paket med satt SYN-bit och förfalskad avsändaradress, servern lägger upp en post för vart och ett i sin kö för halvöppna anslutningar, svarar med SYN-ACK till en adress som aldrig har frågat, och väntar. Här mäts det i paket per sekund, inte i gigabit.

Längden på den kön står i net.ipv4.tcp_max_syn_backlog och ligger på en vanlig server i det fyrsiffriga området. En kö med 1 024 platser är vid 1,49 miljoner SYN-paket per sekund full på mindre än en millisekund. För det räcker rent räknemässigt 1 Gbit/s, och är bara tabellen målet räcker en bråkdel av det.

Till samma familj hör ett förfarande som beskrevs först 2021: TCP-reflektion via tillståndsbärande mellanliggande enheter. Arbetet "Weaponizing Middleboxes for TCP Reflected Amplification" visar att brandväggar och censurinfrastruktur, som bara till hälften följer med i TCP-tillståndet, svarar på ett enda förfalskat paket med hela sidor. Därmed går för första gången även TCP att missbruka för förstärkning, vilket dittills gällde som praktiskt taget omöjligt.

Applikationsattacker på lager 7

En applikationsattack ser ut som vanlig trafik, eftersom den är vanlig trafik, bara i fel mängd. Mätningen sker i förfrågningar per sekund. Den kommer över en fullständigt uppbyggd anslutning och överlever alltså varje kontroll som bara bedömer uppkopplingen, och den behöver lite bandbredd: 10 000 HTTP-förfrågningar per sekund är beroende på förfrågningsstorlek mindre än 50 Mbit/s och ändå nog för att tvinga en databas på knä.

Måttstocken för det heter HTTP/2 Rapid Reset, offentliggjord den 10 oktober 2023 som CVE-2023-44487. Sårbarheten ligger i HTTP/2:s förmåga att multiplexa: angriparen öppnar en dataström, skickar förfrågan och avbryter strömmen omedelbart igen. Servern har redan påbörjat arbetet, medan angriparen genast har en ledig plats i fönstret igen. Värdena som därmed uppnåddes låg på 201 miljoner förfrågningar per sekund (Cloudflare), 398 miljoner (Google) och 155 miljoner (Amazon). Som jämförelse: Cloudflares dittills högsta uppmätta attack på lager 7 låg på 71 miljoner förfrågningar per sekund.

Hos spelservrar är lager 7-nivån själva uppkopplingen. Nullping, QuietException och falska handskakningsfloods mot Minecraft-nätverk behöver nästan ingen bandbredd och lamslår hela proxyförbund, eftersom varje paket tvingar proxyn till ett dyrt tillståndsbeslut. Hur de mönstren ser ut i detalj står i DDoS-skydd och nullping-skydd för Minecraft.

De tre nivåerna jämförda

Verkliga attacker håller sig inte till den indelningen. Det i praktiken obehagligaste fallet är den flerskiktade attacken: en volymetrisk andel som håller ledningen upptagen, plus en andel på lager 7 som kommer fram i just det ögonblick då uppmärksamheten ligger på bandbredden. En av de attacker som visas längre ner och som filtrerades hos KernelHost bestod av över tolv olika huvudmönster samtidigt.

Förstärkningsattacker: hur en byte blir 51 000

En förstärkningsattack är en attack där angriparen inte själv skjuter på målet, utan får främmande, offentligt nåbara tjänster att göra det åt sig. Han skickar en liten förfrågan till en öppen tjänst och skriver in offrets IP-adress som avsändare. Tjänsten svarar pliktskyldigt, bara till offret, och svaret är en multipel av förfrågan.

Förhållandet mellan svarsstorlek och förfrågningsstorlek heter Bandwidth Amplification Factor, kort BAF. En BAF på 50 betyder att en angripare med 1 Gbit/s egen anslutning styr 50 Gbit/s mot målet. Två saker hör ihop för att det ska fungera: ett protokoll över UDP som svarar med mer än det tillfrågas om, och möjligheten att förfalska avsändaradressen. Därför är IP-spoofing förutsättningen för varje förstärkningsattack och inte bara en taktik för att dölja sig.

För försvararen följer därav en obehaglig egenskap: trafiken kommer från riktiga, legitima servrar. Det är verkliga DNS-resolvrar, verkliga tidsservrar, verkliga spelservrar. En blockeringslista efter källadress spärrar alltså antingen ute halva länder eller verkar inte alls.

Förstärkningsfaktorerna hos de missbrukade protokollen

Följande faktorer kommer ur varningen TA14-017A från US-CERT respektive CISA, "UDP-Based Amplification Attacks", som byggs ut löpande sedan 2014. Den är den referens som hela branschen hänvisar till.

Tabellen förklarar varför listan över spärrade portar ser likartad ut i varje välskött brandvägg. Vad du själv kan göra är överskådligt, men viktigt: kontrollera med ss -lnup om en tjänst ur den tabellen står öppen mot nätet på din server. En memcached som inte är bunden till 127.0.0.1 gör din server till ett vapen mot tredje part, kostar dig din egen utgående bandbredd och för upp din IP-adress på blockeringslistor som den har svårt att komma bort från igen.

Varför spelens förfrågningsprotokoll hör hit

Spelservrar står med två roller i den tabellen. De är förstärkare, eftersom deras query-port svarar på ett litet paket med namn, karta, spelarantal och hela mod-listan. Och de är offer, eftersom samma förfrågan kostar processortid, ofta på exakt den kärna som bär spelsimuleringen.

Steam-protokollets förstärkningsfaktor ligger lågt med 5,5, det äldre Quake-protokollets högt med 63,9. Verkan hänger dock inte på faktorn ensam, utan på svarsstorleken i det enskilda fallet: en server med 200 mods levererar ett betydligt större svar än en utan. Bohemia Interactive dokumenterar för Arma 3 under ärendet T83469 sedan 2015 att redan 4 Mbit/s förfalskade förfrågningar mot Steam-query-porten räckte för att frysa en server. Fyra megabit per sekund är mindre än vad en enda hushållsanslutning klarar.

Därav följer regeln som gäller för varje spel: begränsa query-porten, spärra den inte. Den som spärrar den försvinner ur serverlistan och hittas inte längre av nya spelare. Vilken port det är per spel och hur snävt den får köras står i de spelspecifika inläggen längre ner, till exempel för Arma 3, CS2 och Source-titlarna eller Rust.

Fallet memcached: 1,35 Tbit/s mot GitHub

Den 28 februari 2018 var GitHub onåbart från 17:21 till 17:26 UTC och fram till 17:30 UTC bara tidvis. Attacken nådde 1,35 Tbit/s vid 126,9 miljoner paket per sekund och kom från över 1 000 olika autonoma system och tiotusentals enskilda slutpunkter. Förstärkt blev den via memcached, med en faktor på upp till 51 000: en byte från angriparen skapade upp till 51 kilobyte i riktning mot målet.

Det fallet är än i dag det bästa läroexemplet, eftersom det visar tre saker på en gång. För det första: förstärkning slår botnätsstorlek. Angriparen behövde inga hundratusen enheter, han behövde öppna memcached-instanser, av vilka det då stod fler än 90 000 i nätet världen över. För det andra: 126,9 miljoner paket per sekund är runt 85 gånger så mycket som en ledning med 1 Gbit/s överhuvudtaget kan transportera. Ingen inställning på servern ändrar på det. För det tredje: försvaret fungerade, eftersom trafiken leddes om till ett filternät och avbrottstiden därmed slutade vid nio minuter i stället för nio timmar.

Varifrån kapaciteten till en DDoS-attack kommer

Botnät av kapade enheter

Ett botnät är ett förbund av främmande enheter som tagits över med skadeprogram och som en angripare fjärrstyr centralt. Ägarna märker som regel ingenting, eftersom enheten fortsätter göra det den köptes för. Attackerade blir framför allt enheter som hänger varaktigt i nätet, sällan uppdateras och bär standardlösenord: routrar, övervakningskameror, nätverksinspelare, tv-boxar.

Måttstocken är Mirai, vars källkod offentliggjordes i slutet av september 2016. Arbetet "Understanding the Mirai Botnet" (USENIX Security 2017) följer nätet över sju månader och anger toppnoteringen till över 600 000 infekterade enheter. Attacken mot Brian Krebs sida i september 2016 nådde 620 Gbit/s och kom från mer än 175 000 enheter. Vid attacken mot DNS-operatören Dyn den 21 oktober 2016, som samtidigt gjorde Twitter, Spotify och Reddit onåbara, räknades runt 107 000 attackerande IP-adresser.

Nio år senare är storleksordningen en annan. Cloudflare härleder rekordattacken med 31,4 Tbit/s till ett botnät med en uppskattad storlek av en till fyra miljoner infekterade enheter, till övervägande del Android-tv-boxar. I attackvågen i december 2025 räknades 902 hypervolymetriska attacker, i snitt 53 per dag, med toppvärden på 9 miljarder paket per sekund, 24 Tbit/s och 205 miljoner förfrågningar per sekund. Botnätsstorleken har därmed på ett årtionde vuxit med faktor 5, den uppnådda bandbredden med faktor 50.

Booter- och stresser-tjänster och vad en attack kostar

Mellan botnätet och uppdragsgivaren sitter en tjänst som säljer attackkapaciteten som abonnemang. De tjänsterna uppträder som "booters", "stressers" eller "IP-stressers" och påstår i sina användarvillkor att de tjänar till belastningstest av egna system. De kontrollerar därvid aldrig om det angivna målet tillhör användaren, och exakt där går skillnaden mellan ett verktyg och ett erbjudande.

Handhavandet sker via ett webbgränssnitt med tre fält: mål, port, varaktighet. Det finns betalningsflöden, kundtjänst och återförsäljarprogram. Instegspaketen ligger på runt 10 till 20 euro i månaden, större paket med mer bandbredd och längre attacktid på några hundra euro i månaden. Därmed är frågan besvarad varför det också drabbar små projekt: en attack som kostar en spelserver lördagskvällen kostar den som utlöser den mindre än två biobiljetter och inget tekniskt kunnande.

På andra sidan står ett permanent utredningstryck. Under aktionsveckan i den internationella operationen PowerOFF i april 2026 har myndigheter från 21 länder tagit över 53 domäner som tillhörde sådana tjänster, gripit fyra personer och genomfört 25 husrannsakningar. Därvid fick utredarna åtkomst till uppgifterna om över tre miljoner användarkonton, och mer än 75 000 identifierade användare kontaktades. I december 2024 hade 27 plattformar stängts av i samma operation. Den som betalar för en sådan tjänst lämnar alltså ett betalningsspår i en databas som förr eller senare beslagtas.

Hur du känner igen en DDoS-attack

Vad användarna rapporterar, och vad det redan säger

Den första informationen kommer nästan alltid från användarna, och den är mer användbar än den låter. Fyra rapporter har en tydlig betydelse:

• "Alla åkte ut samtidigt." Ett samtidigt avbrott hos alla användare talar för ledningen eller tjänsteprocessen, inte för enskilda anslutningar. Ett lastproblem träffar användare en efter en.
• "Pingen hoppar från 20 till 400 och tillbaka." Svajande svarstid vid fortsatt bestående anslutning är mönstret för en överfylld kö framför målet, inte för en överbelastad process.
• "Serverlistan visar oss som offline, men jag kan ansluta." Det är fingervisningen mot en query-flood: query-porten svarar inte längre, spelporten gör det.
• "Via mobilnätet kommer jag in, via min anslutning inte." Olika beteende beroende på accessnät tyder på att det inte är din server, utan en väg dit som är mättad.

De fyra mätvärdena på servern

Därefter mäter man, och i den här ordningen: paketfrekvens, bandbredd, anslutningstillstånd, räknare för förkastade paket. Belastningsvisningen för CPU:n kommer sist, eftersom den vid en nätattack ofta förblir oanmärkningsvärd.

sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

sar -n DEV 1 10 levererar paket och byte per sekund per gränssnitt över tio sekunder. Avgörande är förhållandet: många paket vid få byte betyder små paket, alltså en protokollattack. Få paket vid mycket många byte betyder stora paket, alltså en förstärkningsattack. ip -s link show visar i kolumnerna dropped och overrun om kärnan redan förkastar. ss -tn state syn-recv räknar halvöppna anslutningar: ett tresiffrigt värde är normalt, ett femsiffrigt är en SYN-flood. Och nstat levererar de räknare som blir kvar även när attacken är över.

Det viktigaste steget är det som nästan ingen tar i förväg: att lägga upp en jämförelsegrund så länge allt går normalt. Utan normalvärde kan du inte säga om 40 000 paket per sekund är mycket eller helt enkelt lördagskväll. Med apt-get install -y vnstat sysstat går mätningen varaktigt i bakgrunden. Den utförliga anvisningen för utvärderingen står i Känn igen en DDoS-attack.

Loggraderna som är entydiga

Fyra meddelanden i kärnans logg och i webbserverns logg är praktiskt taget bevisande. dmesg -T | tail -50 visar de tre första:

kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough

Den första raden betyder att kön för halvöppna anslutningar har svämmat över och att kärnan har växlat till SYN-cookies. Står det i stället Dropping request är net.ipv4.tcp_syncookies satt till 0, och servern förkastar förfrågningar inklusive de riktiga. Den andra raden betyder att anslutningsspårningen är full, och från det ögonblicket förkastar servern även legitim trafik. Den tredje raden är en bieffekt: kärnan undertrycker meddelanden, eftersom den annars vore upptagen med att logga. Den fjärde raden flyttar problemet in i applikationen.

I webbserverns åtkomstlogg är två saker talande. En plötslig andel av statuskoden 499 betyder att klienten stänger anslutningen innan svaret är färdigt, och exakt det gör en attack på lager 7 som bara vill utlösa arbete och inte läsa. Och ett tomt referrer-fält vid nästan alla förfrågningar skiljer en attack från en äkta besöksrusning, som bär med sig referrer från sökmotorer och sociala nätverk.

Motprovet: attack, rusning eller eget fel

Vad som hjälper på servern själv

På servern går det att uppnå mer än vad som ofta påstås, och det mot allt som förblir litet: slarviga bottar, enskilda källor, query-floods och applikationsattacker. Verktygen för det är nftables, anslutningsspårningen, SYN-cookies och en hastighetsbegränsning per källadress. Alla följande uppgifter gäller för Debian 12, Debian 13, Ubuntu 22.04 LTS och Ubuntu 24.04 LTS och är skrivna för root.

nftables: förkasta tidigt, räkna lite

Grundsatsen lyder: ett paket som förkastas ska förkastas så tidigt och så billigt som möjligt. Varje regel som körs dessförinnan kostar processortid gånger paketfrekvens. Följande regelverk för /etc/nftables.conf släpper igenom en webbserver och en speltjänst och förkastar resten, med en hastighetsbegränsning för nya TCP-anslutningar per källadress:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set newconn {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid counter drop

        ip saddr @adminips tcp dport 22 accept

        tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
        tcp dport { 80, 443 } accept

        udp dport 25565 accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

Skriv in din egen fasta adress under adminips innan du laddar, annars låser du ute dig själv från SSH. Kontroll och aktivering går så här:

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn

Tre punkter avgör verkan. ct state established,related accept står medvetet som andra regel, så att befintliga anslutningar inte löper genom hela regeluppsättningen. ct state invalid counter drop tar bort felaktiga flaggkombinationer och försenade fragment, utan att du måste beskriva dem var för sig. Och counter före varje drop är skälet till att du efteråt vet vilken regel som har bitit: står räknarna kvar på noll nås regeln inte, och det är en helt annan diagnos än en verkningslös regeluppsättning.

SYN-cookies och backlogens gräns

SYN-cookies är ett förfarande där servern inte håller reda på en halvöppen anslutning, utan skriver in de nödvändiga uppgifterna krypterat i sitt eget svarsnummer. Kommer det tredje paketet i uppkopplingen tillbaka räknar den fram tillståndet ur det igen. Därmed svämmar kön inte längre över, för det finns ingen kö för de anslutningarna.

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216

De värdena hör hemma i en fil under /etc/sysctl.d/ och övertas med sysctl --system, annars är de borta efter nästa omstart. På Debian och Ubuntu står tcp_syncookies från fabrik på 1, vilket är riktigt. Värdet 1 betyder inte "alltid cookies", utan "cookies så snart kön svämmar över".

Priset för det är verkligt och nämns sällan. I en cookie finns ingen plats för motpartens TCP-optioner. Linux räddar fönsterförstoring och selektiv bekräftelse bara när net.ipv4.tcp_timestamps står på 1, eftersom uppgifterna då följer med i tidsstämpeln. Utan tidsstämpel faller de bort, och anslutningen går långsammare resten av sin livstid. Dessutom står bara tre bitar till förfogande för den maximala paketstorleken, alltså åtta grova steg i stället för det exakta värdet. SYN-cookies är en nöddrift som räddar anslutningar, ingen inställning för normalfallet.

conntrack: tabellen som är full först

Kärnans anslutningsspårning lägger upp en post för varje paketflöde, även för UDP, trots att UDP inte känner några anslutningar. Exakt den tabellen är vid en distribuerad attack den första resurs som tar slut, och den tar slut mycket fort: vid 1,49 miljoner paket per sekund med ny avsändaradress varje gång är en tabell med 262 144 platser fylld på mindre än en femtedels sekund.

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

En post upptar runt 300 byte, 524 288 poster alltså omkring 150 megabyte kärnminne. Hashtabellens storlek sätts inte via sysctl, utan som modulparameter, vanligen till en fjärdedel av den övre gränsen, i /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack hashsize=131072

För en ren spel- eller röstserver är den elegantare lösningen att inte låta speltrafiken spåras alls. Det sparar in tabellen fullständigt:

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack

Observera: notrack och tillståndsbärande regler utesluter varandra. Den som undantar en port från spårningen får inte längre använda någon regel med ct state för den porten, annars biter inte öppningen längre och tjänsten är stängd.

Hastighetsbegränsning per källadress

En hastighetsbegränsning per källadress är den verksammaste enskilda åtgärden på servern, eftersom den träffar exakt det som en angripare gör och släpper igenom exakt det som en användare gör. Skillnaden är stor: en riktig serverbrowser frågar några gånger per minut, en angripare hundratals gånger per sekund. Med nftables arbetar man för det med dynamiska mängder, som i regelverket ovan, med klassiska iptables med hashlimit:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27015 -m length --length 0:27 -j DROP

Alla siffror i sådana regler är startvärden, inga sanningar. Mät först en vecka i normal drift, annars kastar du ut dina egna användare, och det i sämsta möjliga stund. Tänk dessutom på att rena iptables-regler är borta efter en omstart (apt-get install -y iptables-persistent, sedan netfilter-persistent save) och att de under UFW hör hemma i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload. Den fullständiga regeluppsättningen för löpande drift står i Skydda servern mot DDoS-attacker.

Var all filtrering på servern tar slut

Nu den del som ingen konfigurationsfil löser. Alla åtgärder hittills går på din server, alltså i änden av ledningen. En brandväggsregel avgör vad som händer med ett paket som redan har gått genom kabeln. Du kan förkasta det, men inte göra det oskickat. Är ledningen framför full kommer dina användares paket inte fram redan dessförinnan, och det oberoende av hur bra din regeluppsättning är.

Den tabellen besvarar frågan om egenskyddet räcker, för varje enskilt fall. Attacken mot GitHub med 126,9 miljoner paket per sekund får i paketfrekvens knappt plats på en anslutning med 100 Gbit/s, vid 1,35 Tbit/s volym skulle man dock behöva fjorton sådana samtidigt. Rekordattacken med 31,4 Tbit/s motsvarar 314 fullständigt mättade anslutningar med 100 Gbit/s. En spelserver hänger typiskt på 1 Gbit/s eller på två gånger 1 Gbit/s: gränsen för egenskyddet ligger därmed vid runt 1,5 till 3 miljoner paket per sekund, och praktiskt sett betydligt lägre, eftersom kärnan ger upp dessförinnan.

Det finns ännu en, obehagligare gräns. Så snart ledningen är mättad når dig under vissa omständigheter inte ens SSH-sessionen som du ville mäta med. Den som då inte har en nätoberoende åtkomst, till exempel en VNC-konsol i kundportalen, kan inte ens se efter vad som händer.

Vad som bara hjälper framför servern: filtrering i nätet och scrubbing

Verksamt filtrera kan bara den som har mer kapacitet än attacken. Det förutsätter ett ställe där många ledningar löper samman, alltså ett nät, inte en maskin. Där finns två förfaranden som kompletterar varandra.

Realtidsfiltrering i nätet. Hela trafiken går varaktigt genom ett filtersteg som bedömer varje paket innan det lämnas vidare till servern. Fördelen är att det inte finns någon omkoppling: skyddet måste inte först känna igen en attack för att verka. Exakt det avgör vid spel, för en omkopplingstid på två minuter är en förlorad runda, och en omkopplingstid på två minuter vid en attack som varar i 35 sekunder är överhuvudtaget inget försvar.

Scrubbing. Känner nätet igen en stor volymetrisk attack leds den berörda trafiken om till filtercentraler, befrias där från de skadliga andelarna och levereras sedan vidare i riktning mot målet. Meningen med den omledningen är närhet: attacktrafiken slutar på det ställe där den kommer in, i stället för först vid datacentret. Filterreglerna fördelas för det i nätet, tekniskt beskrivet i RFC 8955 som Flow Specification.

Den strukturella motåtgärden mot förfalskade avsändaradresser är för övrigt känd sedan år 2000 och står i RFC 2827, alltså BCP 38: den som ansluter en kund förkastar vid den gränsen alla paket vars avsändaradress inte hör till den kunden. RFC 3704 utvidgar det till nät med flera anslutningar. Om alla nätoperatörer genomförde det vore hela klassen av förstärkningsattacker avklarad. Den är det inte, eftersom det räcker att några låter bli.

Och det finns en tredje metod som man måste känna till, eftersom den ofta säljs som skydd: null-routning, tekniskt Remote Triggered Black Hole Filtering enligt RFC 5635. Därvid annonseras den attackerade IP-adressen i nätet som onåbar, all trafik till den förkastas, attacktrafiken lika väl som dina användares. Det skyddar leverantörens nät, för dig är resultatet identiskt med en lyckad attack, och oftast i timmar därefter. Fråga i tveksamma fall om det filtreras eller null-routas. Svaret avgör mer om din tillgänglighet än varje hårdvaruuppgift.

Vad KernelHost ställer mot det

Det permanenta skyddet som ingår i varje serverpaket

KernelHosts DDoS-skydd är uppbyggt i två steg och permanent aktivt, utan att du måste slå på, beställa eller konfigurera något:

• Steg 1: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket. Volymetriska attacker rensas nära sin källa innan de når datacentret.
• Steg 2: Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main. Direkt framför servern känns protokollspecifika mönster igen och förkastas, paket för paket.

Två egenskaper är avgörande. Skyddet går permanent och är aktivt från leveransen av servern, det finns alltså inga minuter i början av en attack då tjänsten är borta. Och ingen null-routning används: din IP-adress blir kvar i nätet, bara de skadliga paketen förkastas. Vilka spel och protokoll som har egna filterprofiler listar DDoS-skydd för spelservrar i realtid.

Advanced DDoS Protection för projekt under ständig beskjutning

Vissa projekt attackeras inte tillfälligt, utan riktat och under veckor, varje kväll vid samma tid och med växlande mönster. För det finns Advanced DDoS Protection från 50,00 € i månaden, PrePaid, utan bindningstid och utan uppläggningsavgift. Skillnaden ligger inte i mer kapacitet, utan i kontrollen:

• Dedikerad skydds-IP ur Frankfurt-kärnan, som din server ställs om till inom det egna nätet. På din sida behövs ingen ombyggnad.
• Skyddsregler per port och protokoll som du hanterar själv i kundportalen: du ställer separat in vad som tillåts på spelporten och vad som tillåts på query-porten, och kan därmed utnyttja exakt den asymmetri som avsnittet om förfrågningsprotokollen beskriver.
• Ändringar träder i kraft i realtid, du kan alltså justera under en pågående attack i stället för att vänta på ett underhållsfönster.
• Skyddsprofil anpassad till respektive tjänst, likaså för modifierade och egenskrivna applikationer på valfria TCP- eller UDP-portar.

Advanced DDoS Protection riktar sig till KernelHost-kunder och förutsätter en server hos KernelHost. Går ditt projekt för närvarande någon annanstans och står där regelbundet under attack, är flytten hit vägen, inte en fjärrskötsel av din hittillsvarande adress.

De båda stegen jämförda

Fyra verkligt filtrerade attacker ur driften

Följande fyra attacker träffade servrar hos KernelHost-kunder och filtrerades fullständigt i realtid, varje gång utan avbrott. Bilderna kommer ur försvarets live-övervakning.

TeamSpeak-3-röstserver, port 9987 UDP. Komplex attack med flera samtidiga mönster, över 473,4 Gbit/s och över 41,5 miljoner paket per sekund. Det är ungefär 28 gånger paketfrekvensen hos en anslutning med 1 Gbit/s.

ARK-spelserver, port 7777 UDP. Enkel UDP-flood utan komplex struktur, i gengäld över 112,2 Gbit/s och över 8,7 miljoner paket per sekund. Hur ett ARK-kluster vid sidan av säkras själv står i Skydda ARK-servern mot DDoS.

All-port-attack, portarna 0-65535 TCP och UDP. Över tolv olika huvudmönster mot samtliga portar samtidigt, sammanlagt över 21,3 Gbit/s och över 3,9 miljoner paket per sekund. Det fallet visar spridningen över alla portar, som även Cloudflare-fallet från maj 2025 uppvisar med i snitt 21 925 målportar.

Minecraft och OpenVPN, portarna 25565 TCP och 1194 UDP. Kombinerad attack med över sexton olika huvudmönster, över 4 miljoner paket per sekund och över 8,6 Gbit/s. Båda tjänsterna förblev nåbara hela tiden, trots att de talar olika protokoll.

Vad du ska göra vid en attack, i den här ordningen

Ordningen är viktigare än de enskilda stegen, eftersom de vanligaste felen sker under de första fem minuterna.

1. Mät, skruva inte. Säkra först värdena ur sar -n DEV 1 10, ip -s link show, ss -s och dmesg -T i en fil. Efter attacken är de borta, och utan dem kan ingen hjälpa dig.
2. Starta inte om. En omstart raderar alla räknare, alla anslutningstillstånd och varje bevis, och lasten är tillbaka efter några sekunder.
3. Fastställ vilken nivå det är. Byte delat med paket ger den genomsnittliga paketstorleken. Under 100 byte tyder på en protokollattack, över 1 000 byte på en förstärkningsattack, normala storlekar vid hög CPU-last på lager 7.
4. Stäng administrationsportarna. Panel, databas, RCON och allt som inte måste vara offentligt hör begränsat till din egen adress. Det minskar attackytan omedelbart och utan risk för användarna.
5. Sätt en hastighetsbegränsning, snävt på query-porten, vitt på nyttoporten. Spärra inte query-porten, annars försvinner du ur varje serverlista.
6. Byt inte din egen adress förhastat. Ett adressbyte verkar bara så länge den nya adressen inte står offentligt igen, och en bortglömd gammal DNS-post gör bytet verkningslöst.
7. Koppla in leverantören med siffror. Öppna ett ärende med tidpunkt, målport, paketfrekvens, bandbredd och genomsnittlig paketstorlek. De fem uppgifterna avgör hur snabbt filterreglerna för din adress justeras.
8. Dokumentera efteråt. Anteckna när det började, hur länge det varade och vilket mönster det var. Återkommande attacker vid samma klockslag är kriteriet för om ett projekt behöver en dedikerad skydds-IP.

Det utförliga förloppet för en svår attack som pågår längre står i Svår DDoS-attack: vad gör man?.

Rättsläget: en DDoS-attack är ett brott

I Österrike faller en DDoS-attack under § 126b i strafflagen (StGB), "störning av ett datorsystems funktionsduglighet". Grundbrottet ger fängelse i upp till sex månader eller böter på upp till 360 dagsböter. Varar störningen under längre tid är det upp till två år. Attackeras många system med ett program som uppenbart har skapats för det, är det upp till tre år. Och vid en skada över 300 000 euro, vid en attack mot kritisk infrastruktur eller som medlem i en kriminell organisation ligger straffskalan på sex månader till fem år. Kompletterande straffbelägger § 126c StGB redan tillverkning, spridning och tillgängliggörande av de program som är avsedda för det.

I Tyskland gäller § 303b StGB, "datorsabotage": upp till tre års fängelse eller böter, upp till fem år när databehandlingen tjänar en verksamhet, ett företag eller en myndighet, och i särskilt svåra fall sex månader till tio år, till exempel vid yrkesmässigt handlande eller vid påverkan på kritisk infrastruktur. Försök är straffbart, och för förberedelsehandlingar hänvisar § 303b femte stycket StGB till § 202c StGB.

Booter- och stresser-tjänster är därför ingen gråzon, utan den betalda delen av ett brott. Tre punkter missförstås regelbundet. För det första gör hänvisningen "bara för belastningstest av egna system" ingenting lagligt, eftersom tjänsterna inte kontrollerar vem det angivna målet tillhör. För det andra är även uppdragsgivaren straffbar, inte bara operatören: Europol har efter aktionsveckan i april 2026 uttryckligen kontaktat mer än 75 000 identifierade användare för att klargöra just det. För det tredje är ett belastningstest mot den egna servern via en sådan tjänst inte heller någon lösning, eftersom attacktrafiken går genom leverantörens nät och därmed över andra kunders ledningar, vilket varje hostingavtal förbjuder. Den som verkligen vill mäta sin tjänsts tålighet gör det aviserat och i samråd med leverantören. Det här avsnittet återger lagens innehåll och är ingen juridisk rådgivning.

Den passande guiden för din tjänst

Det här inlägget förklarar principen. Vilken port som hör öppen, vilket konfigurationsdirektiv som begränsar vilken förfrågan, och var gränsen går i det enskilda spelet: det står i inläggen om den enskilda tjänsten, vart och ett med en faktatabell över portarna.

• Grunder och tillvägagångssätt: Känn igen en DDoS-attack, Skydda servern mot DDoS-attacker, Svår DDoS-attack: vad gör man?, Game-DDoS-skydd med realtidsfiltrering
• Minecraft och röst: Minecraft och nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
• Rollspel på GTA-basis: FiveM, RedM, RAGE MP och alt:V, SA-MP och open.mp, MTA:SA
• Överlevnad och uppbyggnad: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
• Taktik och skjutspel: CS2 och Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2

Kort sammanfattat

• En DDoS-attack upptar en av fyra ändliga resurser: bandbredd, paketfrekvens, en tillståndstabell i kärnan eller applikationens processortid. Den utnyttjar ingen säkerhetslucka, därför skyddar inte uppdatering ensam.
• RFC 4732 definierar en DoS-attack via verkan, inte via antalet källor. Distribuerad heter den när källorna är talrika: i Cloudflare-fallet från maj 2025 var det 122 145 adresser ur 161 länder.
• CISA, FBI och MS-ISAC skiljer på tre tekniker: volymetrisk i Gbit/s, protokollrelaterad i paket per sekund, applikationsrelaterad i förfrågningar per sekund. Var och en behöver ett annat försvar.
• Förstärkningsattacker missbrukar öppna UDP-tjänster. Faktorerna sträcker sig från 5,5 hos Steam-protokollet över 30,8 hos SSDP och 556,9 hos NTP upp till 51 000 hos memcached, att läsa i US-CERT TA14-017A.
• Kapaciteten kommer ur botnät av kapade enheter, från 600 000 hos Mirai år 2016 upp till uppskattningsvis en till fyra miljoner bakom rekordattacken med 31,4 Tbit/s, och säljs vidare från runt 10 euro i månaden.
• På servern verkar nftables, SYN-cookies, anpassade conntrack-gränser och hastighetsbegränsning per källadress. De tar slut vid runt 1,5 miljoner paket per sekund, eftersom en anslutning med 1 Gbit/s inte transporterar mer.
• Ovanför den gränsen avgör uteslutande filtreringen i nätet framför servern. Null-routning är inget försvar, utan det resultat som angriparen ville ha.
• Hos KernelHost ingår det permanenta skyddet i två steg i varje serverpaket utan extra kostnad och är aktivt från leveransen, utan null-routning: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket plus Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main. Advanced DDoS Protection kompletterar det från 50,00 € i månaden med en dedikerad skydds-IP och regler per port som du hanterar själv.
• En DDoS-attack är i Österrike straffbar enligt § 126b StGB och i Tyskland enligt § 303b StGB, för uppdragsgivaren lika väl som för dem som driver tjänsterna.

Går ditt projekt redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå något anmärkningsvärt öppnar du ett supportärende med de fem uppgifterna ur steg 7, så att filterreglerna för din IP-adress justeras. Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883.