Skydda Call-of-Duty-servern mot DDoS-attacker

Att skydda en Call-of-Duty-server mot DDoS-attacker är hos de klassiska titlarna en glädjande konkret uppgift: det handlar om exakt en UDP-port, om en handfull dvars i server.cfg och om en förstärkningsvektor som motorn har burit med sig sedan 2003. En server som på kvällen mitt i rundan förlorar alla spelare samtidigt har däremot sällan ett hårdvaruproblem. Oftast pågår en attack, och den kommer precis när servern är full.

Den här artikeln visar först vilka titlar den överhuvudtaget gäller för, sedan vad du kan säkra själv utan extra kostnader, därefter var de åtgärderna tar slut rent tekniskt, och till sist vad som då måste hända i nätet framför servern. Kommandona är skrivna för Debian 12, Debian 13, Ubuntu 22.04 LTS och Ubuntu 24.04 LTS och förutsätter root, som vanlig användare sätter du sudo framför.

Om attacken pågår just nu: ändra ingenting i server.cfg och starta inte om servern. Säkra först mätvärdena (se avsnittet "Logga"), efter attacken är de borta.

För vilka Call-of-Duty-titlar du kan skydda en server mot DDoS

Du kan bara skydda en Call-of-Duty-server mot DDoS hos de titlar som tillåter egna dedikerade servrar. Det är originalutgåvorna av Call of Duty (2003), Call of Duty United Offensive, Call of Duty 2, Call of Duty 4 Modern Warfare och Call of Duty World at War, till det kommer community-plattformarna Plutonium (World at War, Black Ops, Black Ops II, Modern Warfare 3), IW4x (Modern Warfare 2) och CoD4X (Call of Duty 4). Alla de här titlarna bär samma mönster: en server.cfg, en öppen UDP-port och en post i en offentlig serverlista.

För de moderna delarna gäller den här artikeln uttryckligen inte. Warzone, Modern Warfare (2019), Black Ops Cold War, Vanguard, Modern Warfare II, Modern Warfare III och Black Ops 6 känner inga hyrbara dedikerade servrar: partierna går på Activisions matchmaking-infrastruktur, det finns ingen server.cfg, ingen serverbrowser och ingen port som du skulle kunna öppna eller säkra. Portlistorna som Activision publicerar för de här titlarna (bland annat TCP 3074 och 27014 till 27050 samt UDP 3074, 3478 och 27000 till 27031) beskriver klient- och plattformsportar, inga serverportar. Den som har anslutningsavbrott i Warzone har ett problem på sin egen uppkoppling eller ett hos Activision, men inget som en hyrd server skulle lösa.

Varför just Call-of-Duty-servrar attackeras

Call-of-Duty-servrar förenar fyra egenskaper som gör dem till ett bekvämt mål. För det första publicerar varje listad server sin adress själv: posten i serverlistan innehåller IP-adress och port i klartext, annars skulle ingen kunna gå in på den. För det andra går all trafik över UDP, och UDP känner ingen uppkoppling som man skulle kunna kräva, avsändaradresser går att förfalska. För det tredje besvarar motorn statusförfrågningar från vem som helst, utan att någon måste starta spelet. För det fjärde ligger fjärrstyrningen RCON på samma port som spelet självt.

Till det kommer den sociala delen: bannade spelare, konkurrens mellan klaner, bråk i en community som har känt varandra i åratal. En attack kostar den som utlöser den varken kunnande eller nämnvärda pengar, så kallade booters och stressers säljs som abonnemang för några euro i månaden, och förstärkningsattacker via spelservrar hör där till standardutbudet. Vad en DDoS-attack är i detalj förklarar artikeln Vad är en DDoS-attack?.

Portarna som det faktiskt handlar om

En klassisk Call-of-Duty-server upptar exakt en UDP-port, nämligen 28960. På den enda porten går tre saker samtidigt: speltrafiken, serverlistans statusförfrågningar och fjärrstyrningen RCON. En egen query-port och en egen RCON-port finns inte. Startraden för en dedikerad server ser likadan ut hos alla titlar, bara namnet på den körbara filen skiljer sig:

+set dedicated 2 +set net_ip 0.0.0.0 +set net_port 28960 +set sv_maxclients 32 +exec server.cfg +map_rotate

Masterserverportarna hör inte hemma bland dina brandväggsöppningar. 20810 och 20800 är målportar på motparten, inga lyssnande portar på din maskin: din server kontaktar listan på eget initiativ. Många anvisningar om portöppning rekommenderar ändå att öppna dem inkommande. Det förstorar attackytan helt utan motvärde.

Vanliga storleksordningar hos Call of Duty

Den andra tabellen är den viktigare om du vill bedöma om du fortfarande får ordning på det själv. Den ställer den normala lasten på en full server mot de tal som det handlar om vid en attack.

Varför spel, query och RCON ligger på samma port

Det är den för Call of Duty avgörande egenheten. id-Tech-3-motorn, som alla klassiska Call-of-Duty-titlar bygger på, känner inga separata portar för spel, förfrågan och fjärrstyrning. Allt går över så kallade anslutningslösa paket på den enda UDP-porten. Ett anslutningslöst paket är ett UDP-paket som börjar med fyra byte 0xFF och därefter bär kommandonamnet i klartext: getstatus, getinfo, getchallenge, connect eller rcon.

Den praktiska följden är obekväm: du kan inte skilja RCON från spelet med brandväggen utan att spärra spelet på köpet. En regel på port 28960 träffar alltid allt. Den som vill sortera bort query-floods och RCON-attacker riktat måste titta i paketets innehåll och inte bara på portnumret. Just därför når portbaserade brandväggsregler hos Call of Duty sin gräns tidigare än hos spel med separat query-port.

Vad är getstatus-reflection hos Call of Duty?

getstatus-reflection är en förstärkningsattack där en angripare skickar små statusförfrågningar med förfalskad avsändaradress till många spelservrar, så att deras betydligt större svar landar hos det egentliga offret. Spelservrarna är därvid inte målet, utan förstärkaren. Vektorn är dokumenterad för id-Tech-3-motorn sedan mer än ett decennium och berör Call of Duty precis som Quake 3 och dess övriga avläggare.

Dubbelt drabbar det dig från två håll. Som angripen får du en flod av getstatus-förfrågningar som förbrukar processortid och utgående bandbredd, och dina spelare märker det som lagspikar. Som ofrivillig förstärkare skickar du svar till ett främmande offer, och abuse-anmälan landar hos dig. Bådadera sker på samma port, med samma paket, och bådadera ser i belastningsgrafen först harmlöst ut.

Hur ett getstatus-paket ser ut

Förfrågan består av fyra byte 0xFF och ordet getstatus, tillsammans 13 byte nyttolast. Med IP- och UDP-huvud blir det 41 byte på nätet. Det är precis det som längdkontrollen siktar på i de brandväggsregler som har gått runt i Call-of-Duty-forum i åratal:

iptables -A INPUT -p udp -m length --length 41:45 -m recent --set --name getstatus_cod
iptables -A INPUT -p udp -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

Svaret är ojämförligt mycket större. Ett statusResponse innehåller hela serverkonfigurationen som teckensträng plus en rad per ansluten spelare, vid full server alltså flera kilobyte. CISA anger Quake-nätverksprotokollets förstärkningsfaktor till 63,9 i sin översikt över UDP-förstärkningsattacker (TA14-017A) och benämner uttryckligen utbytet av serverinformation som det missbrukade kommandot. Ur 1 Mbit/s förfalskade förfrågningar blir därmed runt 64 Mbit/s hos offret. Som jämförelse: DNS ligger i samma översikt på 28 till 54, NTP på 556,9.

Den inbyggda bromsen: sv_queryIgnoreTime och sv_queryIgnoreMegs

Call of Duty 4 har sedan serverversion 1.7 en inbyggd query-broms. Den kommer ihåg varje adress som har skickat en statusförfrågan och ignorerar ytterligare förfrågningar från samma adress under en inställbar tid. Fyra dvars styr det, med de här förvalen:

sv_queryIgnoreMegs        1
sv_queryIgnoreTime        2000
sv_queryBounceIgnoreTime  12000
sv_queryIgnoreDebug       0

sv_queryIgnoreMegs bestämmer hur mycket arbetsminne ignoreringslistan får uppta. 1 megabyte rymmer runt 65 000 adresser, varje ytterligare megabyte cirka 87 000 till. Värdet 0 stänger av bromsen helt, och precis det är fallet på många servrar, eftersom konfigurationen kommer ur en gammal mall. sv_queryIgnoreTime är spärrtiden i millisekunder. sv_queryBounceIgnoreTime griper in när ett svar kommer tillbaka med "ICMP Port Unreachable", alltså precis då när din server just missbrukas som förstärkare mot ett främmande offer. sv_queryIgnoreDebug 1 skriver träffarna till loggen, så att du överhuvudtaget ser om något händer.

Den som använder CoD4X har dessutom fasta övre gränser i serverkoden: högst 20 getstatus-svar per 20 sekunder, högst 100 getinfo-svar per 100 sekunder och högst ett RCON-felmeddelande per 100 millisekunder. Kommentaren i källkoden benämner avsikten tydligt: servern får gärna låta sig översvämmas, men den ska inte slösa utgående bandbredd på det. Det är rätt prioritering, men den ersätter ingen filtrering framför servern.

Varför RCON hos Call of Duty historiskt är ett problem

RCON är serverns fjärrstyrning, och hos Call of Duty är den ett okrypterat UDP-paket på spelporten. Ett RCON-kommando ser ut så här på nätet: fyra byte 0xFF, sedan ordet rcon, sedan lösenordet i klartext, sedan det egentliga kommandot. Det finns ingen kryptering, ingen session, inget användarkonto och ingen andra faktor. Ur det följer tre problem, som alla är verkliga:

• Avlyssning. Den som ser trafiken någonstans på vägen läser ditt RCON-lösenord i klartext. Det gäller varje nät mellan dig och servern och varje verktyg som du ger lösenordet.
• Gissning. Det finns ingen inloggning som skulle kunna spärras och ingen kontospärr efter tio misslyckade försök. En angripare provar lösenord i valfri hastighet. Originalservern bromsar det inte alls, CoD4X bromsar enbart svaret till ett felmeddelande per 100 millisekunder och loggar försöket som "Bad rcon".
• Reflection. Även ett RCON-felmeddelande är ett svar på ett förfalskat paket. Den som beskjuter din server med förfalskade RCON-paket använder den som en liten förstärkare, och din server skriver på köpet full sin logg.

Den praktiska konsekvensen: sätt rcon_password bara om du verkligen behöver RCON. Om ja, då långt och slumpmässigt. CoD4X kräver minst åtta tecken, det är en undre gräns och ingen rekommendation. Administrera i vardagen över SSH och serverkonsolen i stället för över RCON ur det öppna nätet. Och driver du ett förvaltningsverktyg som IW4MAdmin, som i sin tur talar över RCON, hör dess webbgränssnitt på port 1624 inte hemma i det öppna nätet.

Vad du kan göra själv innan du lägger pengar på saken

Det här avsnittet är det längsta, och det med avsikt. En rent konfigurerad Call-of-Duty-server står emot små och medelstora attacker av egen kraft, oberoende av var den står.

1. Inventering: vad lyssnar överhuvudtaget?

Innan du skriver en enda regel tittar du efter vad din server erbjuder utåt. Inte gissa, titta efter:

ss -lntup

Intressant är kolumnen med den lokala adressen. 0.0.0.0:28960 och [::]:28960 betyder "nåbar från hela internet", 127.0.0.1:3306 betyder "bara lokalt" och behöver ingen brandväggsregel. Vid sidan av spelet dyker där ofta IW4MAdmin upp, en webbserver för fast download, en databas för statistik och en bortglömd andra spelinstans. Angriparens vy ger en portskanning utifrån:

nmap -Pn -sU -p 28960-28970,4976,27016 DIN.SERVER.IP.ADRESS
nmap -Pn -p- --min-rate 1000 DIN.SERVER.IP.ADRESS

2. Lämna bara öppet det som spelet verkligen behöver

För en enskild Call-of-Duty-server räcker en enda öppning utåt, allt annat begränsas eller publiceras inte alls. Med UFW ser det ut så här, och i exakt den ordningen, så att du inte låser ute dig själv:

ufw allow 22/tcp comment 'SSH'
ufw allow 28960/udp comment 'Call of Duty'
ufw allow from 203.0.113.10 to any port 1624 proto tcp comment 'IW4MAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Ersätt 203.0.113.10 med din egen adress. Hos Plutonium T6 träder 4976/udp i stället för 28960/udp, hos Plutonium IW5 är det 27016/udp. Driver du flera instanser öppnar du uteslutande det område som faktiskt används, alltså till exempel 28960:28962/udp och inte schablonmässigt 28960 till 28970. Varje port där inget lyssnar är visserligen ingen väg in, men kostar ändå kärnan arbete vid en attack. Den fullständiga anvisningen inklusive räddningsväg hittar du under Sätt upp UFW-brandväggen utan att låsa ute dig själv.

3. Slå på query-bromsen i server.cfg

De här fyra raderna hör hemma i varje server.cfg på en Call-of-Duty-4-server och kostar ingenting utöver några megabyte arbetsminne:

set sv_queryIgnoreMegs "4"
set sv_queryIgnoreTime "2000"
set sv_queryBounceIgnoreTime "12000"
set sv_queryIgnoreDebug "0"

4 megabyte rymmer runt 326 000 adresser, det räcker även för en allvarlig flood. Höj sv_queryIgnoreTime bara försiktigt utöver de förvalda 2000 millisekunderna: serverlistan och varje serverbrowser frågar din server över samma mekanism, och den som sätter spärrtiden för högt försvinner ur listan. Sätt sv_queryIgnoreDebug tillfälligt på 1 om du vill veta om bromsen överhuvudtaget biter, och därefter tillbaka på 0, så att loggen inte fyller din disk.

4. Sortera bort query-floods i brandväggen

Bromsen i motorn verkar först sedan paketet har nått spelprocessen. En brandväggsregel avgör tidigare och kostar mindre. De här två raderna begränsar getstatus per källadress:

iptables -A INPUT -p udp --dport 28960 -m length --length 41:45 -m recent --set --name cod_query --rsource
iptables -A INPUT -p udp --dport 28960 -m string --algo bm --string "getstatus" -m recent --update --seconds 2 --hitcount 4 --name cod_query --rsource -j DROP

Den första raden kommer ihåg varje källadress som skickar ett paket i den typiska längden för en statusförfrågan. Den andra förkastar varje ytterligare getstatus-förfrågan så snart samma adress har skickat mer än fyra av dem inom två sekunder. Fyra förfrågningar per två sekunder räcker för varje serverbrowser. I forum cirkulerar även varianter med 20 förfrågningar per sekund, som är betydligt generösare och verkar mer mot grova bottar än mot en ren reflection-våg.

Rena iptables-regler är borta efter en omstart, under Debian och Ubuntu sparar man dem så här:

apt-get install -y iptables-persistent
netfilter-persistent save

Under UFW hör sådana regler hemma i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload. Kontrollera därefter med iptables -L INPUT -n -v om träffräknarna stiger. Står de kvar på noll nås regeln inte.

5. Stäng av RCON eller styr det snävt

Den säkraste RCON-åtkomsten är den som inte finns. Ett tomt rcon_password avvisar varje RCON-paket:

set rcon_password ""

Observera en finess: servern svarar även då, nämligen med ett felmeddelande, och förblir därmed en liten förstärkare. Den som vill utesluta det och ändå bara behöver RCON från en fast adress förkastar paketen dessförinnan:

iptables -A INPUT -p udp --dport 28960 ! -s 203.0.113.10 -m string --algo bm --string "rcon " -j DROP

Den regeln har en bieffekt som du bör känna till: teckensträngen rcon kan teoretiskt även dyka upp i ett chattpaket från en ansluten spelare, paketet skulle då likaså förkastas. I praktiken är det uthärdligt. Den som inte vill ha bieffekten utelämnar regeln och arbetar bara med ett tomt eller mycket långt lösenord.

6. Avvärja anslutningsflood och utmattning av platserna

En anslutningsflood siktar inte på nätanslutningen utan på spellogiken: angriparen skickar i snabb följd getchallenge- och connect-paket tills alla platser är belagda med halvfärdiga anslutningar. Riktiga spelare får då "Server is full", trots att ingen står i spelet. Mot det verkar de här inställningarna:

set sv_maxclients "32"
set sv_reconnectLimit "3"
set sv_floodProtect "1"
set sv_connectTimeout "30"
set sv_timeout "120"

sv_reconnectLimit begränsar hur ofta samma spelare får återansluta i följd. sv_floodProtect begränsar hur många klientkommandon servern bearbetar per spelare och förhindrar därmed att en enskild klient bromsar servern med kommandon. sv_connectTimeout och sv_timeout bestämmer hur länge en halvfärdig respektive en stum anslutning blockerar en plats: den som låter generösa värden ur en gammal mall stå kvar gör det lätt för angriparen att utmatta platserna.

På CoD4X tillkommer sv_authorizemode. Värdet 1 släpper bara in spelare med giltig kopia, 0 bara spelare utan, och -1 båda. Den som sätter 1 spärrar ute en stor del av engångsklienterna, men förlorar också riktiga spelare utan originalkopia. Det hårdaste medlet är ett serverlösenord via g_password, som verkar mot allt som använder den reguljära anslutningsvägen. Och en sak måste vara klar: ett lösenord skyddar din spellogik, inte din nätanslutning. En angripare som översvämmar din server vill inte alls gå med. Hans paket avvisas, men de har ändå kommit fram, och det är precis poängen.

7. Posten i serverlistan och din egen adress

Här lönar sig ärlighet i stället för önsketänkande: din IP-adress går inte att hålla hemlig. Varje spelare som en gång har varit ansluten känner till den, och listposten publicerar den ändå, tillsammans med porten. Du kan stänga av posten genom att inte sätta någon masterserver i server.cfg (dvars heter sv_master1, sv_master2 och så vidare). Det kostar dock all synlighet för nya spelare och hjälper bara mot den bekvämaste av alla angripare.

En anmärkning om var listorna ligger: Activisions ursprungliga masterservrar (codmaster.activision.com på 20510, cod2master.activision.com på 20710, cod4master.activision.com på 20810) besvarar ingenting längre för de gamla titlarna. Den som vill stå listad i dag använder community-listorna: CoD4X driver en egen och kräver för det ett token i sv_authtoken, Plutonium har med en egen serverlista. På saken i sig ändrar det ingenting, adressen står där lika mycket i klartext.

Två vanor verkar ändå. Publicera aldrig den råa IP-adressen själv, alltså inte i Discord-kanalen och inte på klansidan. Och låt dina spelare ansluta via ett värdnamn, så att du i nödfall kan byta adress utan att alla hänvisningar går sönder. Klassikern är därvid en bortglömd A-post mot den gamla adressen: den gör varje byte verkningslöst.

8. Ta webbgränssnitt, databas och fast download ur det öppna nätet

Vid sidan av spelet går det på de flesta Call-of-Duty-servrar ännu mer: IW4MAdmin med sitt webbgränssnitt på port 1624, en webbserver för fast download av kartorna, ibland en databas för statistik. Var och en av de tjänsterna är en egen attackyta, och ingen av dem hör obegränsat hemma i det öppna nätet.

Begränsa 1624 till din egen adress, eller nå gränssnittet via en SSH-vidarebefordran och öppna därefter lokalt http://127.0.0.1:1624:

ssh -N -L 1624:127.0.0.1:1624 root@DIN.SERVER.IP.ADRESS

Databasen binder du till 127.0.0.1, den har under inga omständigheter något i det öppna nätet att göra. Och lägg fast download på en egen webbserver i stället för i spelprocessen: en webbserver under last tar annars från spelet precis den processortid som det behöver för simuleringen.

9. Logga, så att du har data när det gäller

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 ett normalvärde kan du efter en incident inte säga om 40 000 paket per sekund var mycket eller helt enkelt fredagskväll. Med apt-get install -y vnstat sysstat går mätningen varaktigt i bakgrunden. Under en incident räcker fyra kommandon:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp port 28960 -c 200 -q

För Call of Duty finns ett femte, som besvarar den avgörande frågan. Den inspelningen visar uteslutande de anslutningslösa paketen, alltså precis getstatus, getinfo, getchallenge, connect och rcon:

tcpdump -ni eth0 'udp port 28960 and udp[8:4] = 0xffffffff' -c 200 -A

Står det där hundratals gånger getstatus från ständigt nya adresser har du en query-flood. Står det rcon försöker någon gissa ditt lösenord. Står det bara getchallenge och connect är det en anslutningsflood. För tcpdump gäller alltid: begränsa med -c, en inspelning under full last belastar en redan överbelastad server ytterligare. Hur du tolkar värdena står i Känn igen en DDoS-attack.

Var de här åtgärderna tar slut

Nu den del som ingen konfigurationsfil kan lösa. Alla åtgärder hittills går på din server, alltså i änden av nätanslutningen. 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äkna på det en gång. En full server med 32 platser skapar utgående runt 6,4 Mbit/s, det är mindre än en procent av en gigabitanslutning. Samma anslutning är full så snart någon skickar 125 megabyte per sekund, och precis på det är de attacker utlagda som man kan beställa för tio euro i månaden. Om din iptables-regel bakom är bra spelar då ingen roll längre, eftersom dina spelares paket inte kommer fram redan dessförinnan.

Den andra storheten är paketfrekvensen, och den slår hos Call of Duty regelbundet till tidigare än bandbredden. Vid små paket på 64 byte får runt 1,49 miljoner paket per sekund plats i en nätanslutning med 1 Gbit/s. Kärnan i ett vanligt serversystem bearbetar beroende på CPU och nätverkskort några hundratusen av dem innan den börjar förkasta. En getstatus-förfrågan är med 41 byte ännu mindre än så: en attack som inte ens fyller din anslutning till en tredjedel lamslår ändå din server, eftersom hela processortiden går åt till att förkasta. De som driver servrar upplever det som "belastningen var ju inte alls hög, ändå var allt borta".

Hos Call of Duty tillkommer en egenhet som skärper räkningen. Eftersom spel, query och RCON ligger på samma port kan du inte stänga 28960 i nödfall: det vore detsamma som att stänga av servern. Och eftersom motorn besvarar varje statusförfrågan med en multipel av förfrågans storlek förbrukar en angripare mindre egen bandbredd för samma verkan än hos andra spel.

Till inordningen, vilka storleksordningar som verkligen förekommer: på KernelHost-servrar filtrerades bland annat en attack med över 473,4 Gbit/s vid över 41,5 miljoner paket per sekund mot en röstserver och en UDP-flood med över 112,2 Gbit/s mot en spelserver. För det finns ingen lokal inställning. Volymetriska attacker måste sluta i nätet framför servern.

Vad KernelHost ställer mot det

Det permanenta skyddet som ingår i varje server

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 behöver inte först reagera på en attack, det finns alltså inga minuter i början då servern är borta. Och ingen nullrouting används: din IP-adress blir kvar i nätet, bara de skadliga paketen förkastas. Den som tar IP-adressen ur nätet uppnår för dig samma resultat som angriparen. Vilka spel och protokoll som täcks listar DDoS-skydd för spelservrar i realtid.

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

Vissa klaner och communities attackeras inte tillfälligt utan riktat och under veckor. För sådana fall finns Advanced DDoS Protection från 50,00 EUR i månaden, PrePaid och utan bindningstid. 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 in vad som tillåts på 28960 UDP utan att skriva ett ärende för det, och vid flera instanser separat per port.
• Ändringar träder i kraft i realtid, du kan alltså justera under en pågående attack.
• Skyddsprofil anpassad till respektive spel, även för modifierade och egna applikationer på valfria TCP- eller UDP-portar. Det är den relevanta punkten för Plutonium och CoD4X, eftersom deras portar kan avvika från förvalen.

Advanced DDoS Protection riktar sig till servrar som står hos KernelHost. Går din Call-of-Duty-server för närvarande någon annanstans och tas där regelbundet ur nätet, är flytten till KernelHost den väg som ändrar något.

De båda stegen jämförda

För de flesta Call-of-Duty-servrar räcker det inkluderade permanenta skyddet tillsammans med en ren server.cfg. Advanced DDoS Protection är svaret på att någon tar det personligt.

Vanliga fel och lösningar

"Jag bytte IP-adress och var offline igen två timmar senare": Angriparen har den nya adressen ur samma källa som den gamla, oftast listposten, en Discord-bot med statusvisning eller en gammal DNS-post. Ett adressbyte är tidsvinst, ingen lösning.

"Min leverantör skickar mig en abuse-anmälan, fast jag ju är offret": Då är din server inte målet, utan förstärkaren. Någon skickar förfalskade getstatus-förfrågningar, och din server svarar beskedligt till ett främmande offer. Kontrollera först om sv_queryIgnoreMegs står på 0, och sätt de fyra query-dvars samt brandväggsregeln ur avsnitt 4.

"Servern står i listan som full men är tom": Det är en anslutningsflood, och den träffar spellogiken, inte nätanslutningen. Mot det verkar sv_reconnectLimit, kortare värden för sv_connectTimeout och sv_timeout och i tveksamma fall ett serverlösenord.

"Servern försvinner ur serverlistan under attacken": Det är följden, inte orsaken. Serverlistan kontrollerar över samma statusförfrågningar om din server lever. Kommer svaren inte fram eller förkastades de av din egen broms, gäller servern som offline. Kontrollera om sv_queryIgnoreTime står för högt innan du misstänker brandväggen.

"Mina iptables-regler biter inte": Tre orsaker är vanliga. Reglerna står bakom UFW-kedjorna och nås aldrig, de var borta efter den senaste omstarten (då hjälper netfilter-persistent save eller en post i /etc/ufw/before.rules), eller så är attacken volymetrisk och regeln arbetar korrekt vid en nätanslutning som redan är full. Kontrollera med iptables -L INPUT -n -v om träffräknarna stiger.

"Servern går, men alla spelare har lagspikar": Titta först på gränssnittets paketfrekvens, inte på CPU-lasten. Förblir sar -n DEV 1 10 oanmärkningsvärt och hackar det ändå, ligger det oftast på en mod, en överdriven sv_maxRate eller helt enkelt på för många bottar i rundan.

"Min tidigare leverantör har spärrat min IP-adress": Det är nullrouting. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i timmar därefter. Fråga i tveksamma fall om det filtreras eller nullroutas. Svaret avgör mer om din tillgänglighet än varje hårdvaruuppgift.

"I tcpdump ser jag inget anmärkningsvärt": Filtreras trafiken redan i nätet framför kommer som väntat ingenting fram på servern. Det är normalfallet vid fungerande filtrering. Omvänt gäller: är nätanslutningen mättad når dig under vissa omständigheter inte ens SSH-sessionen som du ville mäta med. Använd då VNC-konsolen i kundportalen, som fungerar oberoende av gästsystemets nätverk.

Kort sammanfattat

• En klassisk Call-of-Duty-server behöver exakt en öppen port: 28960 UDP. Hos Plutonium T6 är det 4976 UDP, hos Plutonium IW5 27016 UDP.
• Spel, statusförfrågan och RCON ligger hos Call of Duty på samma port. Du kan inte skilja RCON från spelet med en portregel, för det behöver du en regel som tittar i paketets innehåll.
• getstatus-reflection är den speltypiska förstärkningsvektorn: 41 byte förfrågan, enligt CISA-varningen TA14-017A faktor 63,9 hos Quake-nätverksprotokollet, alltså runt 2 600 byte svar.
• Slå på query-bromsen: sv_queryIgnoreMegs 4, sv_queryIgnoreTime 2000, sv_queryBounceIgnoreTime 12000. På många servrar står den på 0 och är därmed av.
• Sätt rcon_password bara om du verkligen behöver RCON: lösenordet går okrypterat över UDP och går att gissa hur många gånger som helst utan kontospärr.
• Masterserverportarna 20810 och 20800 är utgående målportar och hör inte hemma bland dina inkommande öppningar.
• Från runt 1 Gbit/s eller några hundratusen paket per sekund avgör uteslutande nätet framför servern, inte längre din konfiguration.

Går din server 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, 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.