Call-of-Duty-server beschermen tegen DDoS-aanvallen

Een Call-of-Duty-server tegen DDoS-aanvallen beschermen is bij de klassieke titels een aangenaam concrete opgave: het gaat om precies één UDP-poort, om een handvol dvars in de server.cfg en om een versterkingsvector die de engine sinds 2003 met zich meedraagt. Een server die 's avonds midden in de ronde alle spelers tegelijk verliest, heeft daarentegen zelden een hardwareprobleem. Meestal loopt er een aanval, en die loopt precies wanneer de server vol zit.

Dit artikel laat eerst zien voor welke titels het überhaupt geldt, daarna wat u zonder extra kosten zelf kunt afschermen, vervolgens waar die maatregelen technisch ophouden, en tot slot wat er dan in het netwerk vóór de server moet gebeuren. De commando's zijn voor Debian 12, Debian 13, Ubuntu 22.04 LTS en Ubuntu 24.04 LTS geschreven en gaan uit van root, als gewone gebruiker zet u er sudo voor.

Loopt de aanval op dit moment: verander nu niets aan de server.cfg en start de server niet opnieuw op. Leg eerst de meetwaarden vast (zie de paragraaf "Vastleggen"), na de aanval zijn ze verdwenen.

Voor welke Call-of-Duty-titels u een server tegen DDoS kunt beschermen

Een Call-of-Duty-server tegen DDoS beschermen kunt u alleen bij de titels die eigen dedicated servers toelaten. Dat zijn de originele uitgaven van Call of Duty (2003), Call of Duty United Offensive, Call of Duty 2, Call of Duty 4 Modern Warfare en Call of Duty World at War, plus de communityplatformen Plutonium (World at War, Black Ops, Black Ops II, Modern Warfare 3), IW4x (Modern Warfare 2) en CoD4X (Call of Duty 4). Al deze titels brengen hetzelfde patroon mee: een server.cfg, een open UDP-poort en een vermelding in een openbare serverlijst.

Voor de moderne delen geldt dit artikel uitdrukkelijk niet. Warzone, Modern Warfare (2019), Black Ops Cold War, Vanguard, Modern Warfare II, Modern Warfare III en Black Ops 6 kennen geen huurbare dedicated servers: de partijen lopen op de matchmaking-infrastructuur van Activision, er is geen server.cfg, geen serverbrowser en geen poort die u zou kunnen vrijgeven of afschermen. De poortlijsten die Activision voor deze titels publiceert (onder meer TCP 3074 en 27014 tot 27050 en UDP 3074, 3478 en 27000 tot 27031) beschrijven client- en platformpoorten, geen serverpoorten. Wie in Warzone verbindingsonderbrekingen heeft, heeft een probleem op de eigen lijn of een probleem bij Activision, maar geen probleem dat een gehuurde server zou oplossen.

Waarom juist Call-of-Duty-servers worden aangevallen

Call-of-Duty-servers verenigen vier eigenschappen die ze tot een gemakkelijk doelwit maken. Ten eerste publiceert elke vermelde server zijn adres uit zichzelf: de vermelding in de serverlijst bevat IP-adres en poort leesbaar, anders zou niemand hem kunnen betreden. Ten tweede loopt al het verkeer over UDP, en UDP kent geen verbindingsopbouw die u zou kunnen eisen, afzenderadressen laten zich vervalsen. Ten derde beantwoordt de engine statusopvragingen van iedereen, zonder dat iemand het spel hoeft te starten. Ten vierde ligt de afstandsbediening RCON op dezelfde poort als het spel zelf.

Daar komt het sociale deel bij: verbannen spelers, concurrentie tussen clans, ruzie in een community die elkaar al jaren kent. Een aanval kost de veroorzaker kunde noch noemenswaardig geld, zogeheten booters en stressers worden als abonnement voor een paar euro per maand verkocht, en versterkingsaanvallen via gameservers horen daar tot het standaardaanbod. Wat een DDoS-aanval in detail is, legt het artikel Wat is een DDoS-aanval? uit.

De poorten waar het werkelijk om gaat

Een klassieke Call-of-Duty-server bezet precies één UDP-poort, namelijk 28960. Op die ene poort lopen drie dingen tegelijk: het spelverkeer, de statusopvragingen van de serverlijst en de afstandsbediening RCON. Een eigen querypoort en een eigen RCON-poort bestaan niet. De startregel van een dedicated server ziet er bij alle titels hetzelfde uit, alleen de naam van het uitvoerbare bestand verschilt:

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

De masterserverpoorten horen niet in uw firewallvrijgaven. 20810 en 20800 zijn doelpoorten aan de andere kant, geen luisterpoorten op uw machine: uw server spreekt de lijst uit zichzelf aan. Veel handleidingen voor poortvrijgave raden toch aan om ze inkomend te openen. Dat vergroot het aanvalsoppervlak zonder enige tegenwaarde.

Gangbare ordes van grootte bij Call of Duty

De tweede tabel is de belangrijkste wanneer u wilt inschatten of u het nog zelf in de hand kunt houden. Zij zet de normale belasting van een volle server tegenover de getallen waar het bij een aanval om gaat.

Waarom spel, query en RCON op dezelfde poort liggen

Dat is de voor Call of Duty doorslaggevende bijzonderheid. De id-Tech-3-engine waarop alle klassieke Call-of-Duty-titels zijn gebouwd, kent geen gescheiden poorten voor spel, opvraging en afstandsbediening. Alles loopt via zogeheten verbindingsloze pakketten op die ene UDP-poort. Een verbindingsloos pakket is een UDP-pakket dat met vier bytes 0xFF begint en daarna de naam van het commando leesbaar draagt: getstatus, getinfo, getchallenge, connect of rcon.

Het praktische gevolg is onhandig: u kunt RCON niet per firewall van het spel scheiden zonder het spel mee af te sluiten. Een regel op poort 28960 raakt altijd alles. Wie queryfloods en RCON-aanvallen gericht wil uitsorteren, moet in de inhoud van het pakket kijken en niet alleen naar het poortnummer. Precies daarom lopen poortgebaseerde firewallregels bij Call of Duty eerder tegen hun grens aan dan bij spellen met een gescheiden querypoort.

Wat is de getstatus-reflection bij Call of Duty?

De getstatus-reflection is een versterkingsaanval waarbij een aanvaller kleine statusopvragingen met een vervalst afzenderadres naar veel gameservers stuurt, zodat hun duidelijk grotere antwoorden bij het eigenlijke slachtoffer terechtkomen. De gameservers zijn daarbij niet het doelwit, maar de versterker. Deze vector is voor de id-Tech-3-engine al meer dan tien jaar gedocumenteerd en treft Call of Duty net zo goed als Quake 3 en de overige afgeleiden daarvan.

Het raakt u dubbel, vanuit twee richtingen. Als aangevallene krijgt u een vloed aan getstatus-aanvragen die rekentijd en uitgaande bandbreedte verbruikt, en uw spelers merken dat als lagspikes. Als onvrijwillige versterker verstuurt u antwoorden naar een onbekend slachtoffer, en de abuse-melding komt bij u terecht. Beide gebeuren op dezelfde poort, met dezelfde pakketten, en beide zien er in de belastingsgrafiek aanvankelijk onschuldig uit.

Hoe een getstatus-pakket eruitziet

De aanvraag bestaat uit vier bytes 0xFF en het woord getstatus, samen 13 byte nuttige lading. Met IP- en UDP-kop zijn dat 41 byte op de lijn. Precies daarop mikt de lengtecontrole in de firewallregels die in Call-of-Duty-forums al jaren worden doorgegeven:

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

Het antwoord is onvergelijkbaar groter. Een statusResponse bevat de volledige serverconfiguratie als tekenreeks plus een regel per verbonden speler, bij een volle server dus meerdere kilobytes. De CISA voert het Quake-netwerkprotocol in haar overzicht van UDP-versterkingsaanvallen (TA14-017A) met een versterkingsfactor van 63,9 en benoemt als misbruikt commando uitdrukkelijk de uitwisseling van serverinformatie. Uit 1 Mbit/s aan vervalste aanvragen wordt daarmee ongeveer 64 Mbit/s bij het slachtoffer. Ter vergelijking: DNS ligt in hetzelfde overzicht op 28 tot 54, NTP op 556,9.

De ingebouwde rem: sv_queryIgnoreTime en sv_queryIgnoreMegs

Call of Duty 4 heeft sinds serverversie 1.7 een ingebouwde queryrem. Die onthoudt elk adres dat een statusopvraging heeft gestuurd, en negeert verdere opvragingen van datzelfde adres gedurende een instelbare tijd. Vier dvars sturen dat aan, met deze standaardwaarden:

sv_queryIgnoreMegs        1
sv_queryIgnoreTime        2000
sv_queryBounceIgnoreTime  12000
sv_queryIgnoreDebug       0

sv_queryIgnoreMegs bepaalt hoeveel werkgeheugen de negeerlijst mag bezetten. 1 megabyte bevat ongeveer 65.000 adressen, elke verdere megabyte zo'n 87.000 extra. De waarde 0 schakelt de rem volledig uit, en precies dat is op veel servers het geval, omdat de configuratie uit een oud voorbeeldbestand stamt. sv_queryIgnoreTime is de blokkeertijd in milliseconden. sv_queryBounceIgnoreTime grijpt in wanneer een antwoord met "ICMP Port Unreachable" terugkomt, dus precies wanneer uw server op dat moment als versterker tegen een onbekend slachtoffer wordt misbruikt. sv_queryIgnoreDebug 1 schrijft de treffers naar het logboek, zodat u überhaupt ziet of er iets gebeurt.

Wie CoD4X inzet, heeft daarnaast vaste bovengrenzen in de servercode: hoogstens 20 getstatus-antwoorden per 20 seconden, hoogstens 100 getinfo-antwoorden per 100 seconden en hoogstens één RCON-foutmelding per 100 milliseconden. De opmerking in de broncode benoemt de bedoeling helder: de server mag zich gerust laten overspoelen, maar hij mag daarbij geen uitgaande bandbreedte verspillen. Dat is de juiste prioriteitstelling, maar het vervangt geen filtering vóór de server.

Waarom RCON bij Call of Duty historisch een probleem is

RCON is de afstandsbediening van de server, en bij Call of Duty is dat een onversleuteld UDP-pakket op de spelpoort. Een RCON-commando ziet er op de lijn zo uit: vier bytes 0xFF, dan het woord rcon, dan het wachtwoord leesbaar, dan het eigenlijke commando. Er is geen versleuteling, geen sessie, geen gebruikersaccount en geen tweede factor. Daaruit volgen drie problemen, die alle drie reëel zijn:

• Meelezen. Wie het verkeer ergens onderweg ziet, leest uw RCON-wachtwoord leesbaar mee. Dat geldt voor elk netwerk tussen u en de server en voor elk stuk gereedschap waaraan u het wachtwoord geeft.
• Raden. Er is geen aanmelding die geblokkeerd kan worden en geen accountblokkering na tien mislukte pogingen. Een aanvaller probeert wachtwoorden in willekeurig tempo door. De originele server remt dat helemaal niet af, CoD4X remt uitsluitend het antwoord af tot één foutmelding per 100 milliseconden en legt de poging vast als "Bad rcon".
• Reflection. Ook een RCON-foutmelding is een antwoord op een vervalst pakket. Wie uw server met vervalste RCON-pakketten bestookt, gebruikt hem als kleine versterker, en uw server schrijft er ondertussen het logboek mee vol.

De praktische consequentie: stel rcon_password alleen in wanneer u RCON werkelijk nodig hebt. Zo ja, dan lang en willekeurig. CoD4X eist minstens acht tekens, dat is een ondergrens en geen aanbeveling. Beheer uw server in het dagelijks gebruik via SSH en de serverconsole in plaats van via RCON uit het open internet. En draait u een beheergereedschap zoals IW4MAdmin, dat zelf via RCON praat, dan hoort de webinterface daarvan op poort 1624 niet op het open internet.

Wat u zelf kunt doen voordat u geld uitgeeft

Dit hoofdstuk is het langste, en dat met opzet. Een netjes geconfigureerde Call-of-Duty-server houdt kleine en middelgrote aanvallen op eigen kracht uit, ongeacht bij wie hij staat.

1. Inventarisatie: wat luistert er eigenlijk?

Voordat u ook maar één regel schrijft, kijkt u na wat uw server naar buiten aanbiedt. Niet gokken, maar kijken:

ss -lntup

Interessant is de kolom met het lokale adres. 0.0.0.0:28960 en [::]:28960 betekenen "vanaf het hele internet bereikbaar", 127.0.0.1:3306 betekent "alleen lokaal" en heeft geen firewallregel nodig. Naast het spel duiken daar vaak IW4MAdmin, een webserver voor de fast download, een database voor statistieken en een vergeten tweede spelinstantie op. Het beeld van de aanvaller levert een poortscan van buitenaf:

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

2. Alleen openlaten wat het spel echt nodig heeft

Voor een enkele Call-of-Duty-server volstaat één openstelling naar buiten, al het andere wordt beperkt of helemaal niet gepubliceerd. Met UFW ziet dat er zo uit, en wel precies in deze volgorde, zodat u zichzelf niet buitensluit:

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

Vervang 203.0.113.10 door uw eigen adres. Bij Plutonium T6 komt 4976/udp in de plaats van 28960/udp, bij Plutonium IW5 is het 27016/udp. Draait u meerdere instanties, geef dan uitsluitend het werkelijk gebruikte bereik vrij, dus bijvoorbeeld 28960:28962/udp en niet zonder meer 28960 tot 28970. Elke poort waarop niets luistert is weliswaar geen toegangsweg, maar kost de kernel bij een aanval toch werk. De volledige handleiding inclusief reddingsweg vindt u onder UFW-firewall instellen zonder uzelf buiten te sluiten.

3. De queryrem in de server.cfg inschakelen

Deze vier regels horen in elke server.cfg van een Call-of-Duty-4-server en kosten niets behalve een paar megabyte werkgeheugen:

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

4 megabyte bevat ongeveer 326.000 adressen, dat is ook voor een serieuze flood genoeg. Verhoog sv_queryIgnoreTime slechts voorzichtig boven de standaardwaarde van 2000 milliseconden: de serverlijst en elke serverbrowser vragen uw server via hetzelfde mechanisme op, en wie de blokkeertijd te hoog zet, verdwijnt uit de lijst. Zet sv_queryIgnoreDebug tijdelijk op 1 wanneer u wilt weten of de rem überhaupt aangrijpt, en daarna weer op 0, zodat het logboek uw schijf niet volschrijft.

4. Queryfloods in de firewall uitsorteren

De rem in de engine werkt pas nadat het pakket het spelproces heeft bereikt. Een firewallregel beslist eerder en kost minder. Deze twee regels begrenzen getstatus per bronadres:

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

De eerste regel onthoudt elk bronadres dat een pakket in de typische lengte van een statusopvraging stuurt. De tweede verwerpt elke verdere getstatus-aanvraag zodra hetzelfde adres er binnen twee seconden meer dan vier heeft gestuurd. Vier aanvragen per twee seconden zijn voor elke serverbrowser voldoende. In forums circuleren ook varianten met 20 aanvragen per seconde, die duidelijk ruimhartiger zijn en eerder tegen grove bots werken dan tegen een nette reflectiegolf.

Kale iptables-regels zijn na een herstart verdwenen, onder Debian en Ubuntu bewaart u ze zo:

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

Onder UFW horen zulke regels in /etc/ufw/before.rules, omdat ze anders bij de volgende ufw reload verdwijnen. Controleer daarna met iptables -L INPUT -n -v of de tellers oplopen. Blijven ze op nul staan, dan wordt de regel niet bereikt.

5. RCON uitschakelen of strak houden

De veiligste RCON-toegang is die welke er niet is. Een leeg rcon_password wijst elk RCON-pakket af:

set rcon_password ""

Let daarbij op een subtiliteit: de server antwoordt ook dan nog, namelijk met een foutmelding, en blijft daarmee een kleine versterker. Wie dat wil uitsluiten en RCON sowieso alleen vanaf een vast adres nodig heeft, verwerpt de pakketten eerder:

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

Deze regel heeft een neveneffect dat u moet kennen: de tekenreeks rcon kan theoretisch ook in een chatpakket van een verbonden speler opduiken, dat pakket zou dan eveneens worden verworpen. In de praktijk is dat te overzien. Wie het neveneffect niet wil, laat de regel weg en werkt alleen met een leeg of zeer lang wachtwoord.

6. Joinflood en slotuitputting afweren

Een joinflood mikt niet op de lijn, maar op de spellogica: de aanvaller stuurt in snelle opeenvolging getchallenge- en connect-pakketten, totdat alle slots met halfafgemaakte verbindingen bezet zijn. Echte spelers krijgen dan "Server is full", hoewel er in het spel niemand staat. Daartegen werken deze instellingen:

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

sv_reconnectLimit begrenst hoe vaak dezelfde speler zich achter elkaar opnieuw mag verbinden. sv_floodProtect begrenst hoeveel clientcommando's de server per speler verwerkt en voorkomt daarmee dat een enkele client de server met commando's afremt. sv_connectTimeout en sv_timeout bepalen hoe lang een halfafgemaakte respectievelijk een stille verbinding een slot blokkeert: wie hier ruime waarden uit een oud voorbeeldbestand laat staan, maakt de aanvaller de slotuitputting gemakkelijk.

Op CoD4X komt sv_authorizemode daarbij. De waarde 1 laat alleen spelers met een geldige kopie binnen, 0 alleen spelers zonder, en -1 beide. Wie 1 instelt, sluit een groot deel van de wegwerpclients buiten, maar verliest ook echte spelers zonder originele kopie. Het hardste middel is een serverwachtwoord via g_password, dat werkt tegen alles wat de reguliere weg naar binnen gebruikt. En één ding moet duidelijk zijn: een wachtwoord beschermt uw spellogica, niet uw lijn. Een aanvaller die uw server overspoelt, wil helemaal niet meedoen. Zijn pakketten worden geweigerd, maar ze zijn wel aangekomen, en precies daar gaat het om.

7. De vermelding in de serverlijst en uw eigen adres

Hier loont eerlijkheid meer dan wensdenken: uw IP-adres laat zich niet geheimhouden. Iedere speler die ooit verbonden is geweest, kent het, en de vermelding in de lijst publiceert het sowieso, inclusief poort. U kunt die vermelding uitschakelen door in de server.cfg geen masterserver te zetten (de dvars heten sv_master1, sv_master2 enzovoort). Dat kost echter alle zichtbaarheid voor nieuwe spelers en helpt alleen tegen de meest gemakzuchtige aanvaller.

Een opmerking over de plaats van de lijsten: de oorspronkelijke masterservers van Activision (codmaster.activision.com op 20510, cod2master.activision.com op 20710, cod4master.activision.com op 20810) beantwoorden voor de oude titels niets meer. Wie vandaag vermeld wil staan, gebruikt de communitylijsten: CoD4X draait een eigen lijst en verlangt daarvoor een token in sv_authtoken, Plutonium brengt een eigen serverlijst mee. Aan de zaak zelf verandert dat niets, het adres staat daar net zo goed leesbaar in.

Twee gewoonten werken desondanks. Publiceer het kale IP-adres nergens zelf, dus niet in het Discord-kanaal en niet op de clanpagina. En laat uw spelers via een hostnaam verbinden, zodat u in geval van nood het adres kunt wisselen zonder dat alle verwijzingen breken. De klassieker daarbij is een vergeten A-record naar het oude adres: dat maakt elke wissel zinloos.

8. Webinterfaces, database en fast download van het open internet afhalen

Naast het spel draait er op de meeste Call-of-Duty-servers nog meer: IW4MAdmin met zijn webinterface op poort 1624, een webserver voor de fast download van de kaarten, soms een database voor statistieken. Elk van deze diensten is een eigen aanvalsoppervlak, en geen daarvan hoort onbeperkt op het open internet.

Beperk 1624 tot uw eigen adres of bereik de interface via een SSH-tunnel, daarna opent u lokaal http://127.0.0.1:1624:

ssh -N -L 1624:127.0.0.1:1624 root@UW.SERVER.IP.ADRES

De database bindt u aan 127.0.0.1, die heeft op het open internet in geen geval iets te zoeken. En leg de fast download op een eigen webserver in plaats van in het spelproces: een webserver onder belasting neemt het spel anders precies de rekentijd af die het voor de simulatie nodig heeft.

9. Vastleggen, zodat u in geval van nood cijfers hebt

De belangrijkste stap is die welke bijna niemand vooraf zet: een vergelijkingsbasis aanleggen zolang alles normaal draait. Zonder normaalwaarde kunt u na een incident niet zeggen of 40.000 pakketten per seconde veel was of gewoon vrijdagavond. Met apt-get install -y vnstat sysstat loopt de meting permanent mee. Tijdens een incident volstaan vier commando's:

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

Voor Call of Duty is er een vijfde, die de beslissende vraag beantwoordt. Deze opname toont uitsluitend de verbindingsloze pakketten, dus precies getstatus, getinfo, getchallenge, connect en rcon:

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

Staat daar honderd keer getstatus uit steeds nieuwe adressen, dan hebt u een queryflood. Staat daar rcon, dan probeert iemand uw wachtwoord te raden. Staat daar alleen getchallenge en connect, dan is het een joinflood. Voor tcpdump geldt altijd: begrens hem met -c, want een opname onder volle belasting belast een toch al overbelaste server nog extra. Hoe u de waarden uitleest, staat in DDoS-aanval herkennen.

Waar deze maatregelen ophouden

Nu het deel dat geen enkel configuratiebestand kan oplossen. Alle maatregelen tot hier draaien op uw server, dus aan het einde van de lijn. Een firewallregel beslist over een pakket dat al over de kabel is gekomen. U kunt het verwerpen, maar u kunt niet terugdraaien dat het verstuurd is.

Rekent u even mee. Een volle server met 32 slots produceert uitgaand ongeveer 6,4 Mbit/s, dat is minder dan één procent van een gigabitlijn. Diezelfde lijn zit vol zodra iemand 125 megabyte per seconde stuurt, en precies daarop zijn de aanvallen berekend die u voor tien euro per maand kunt bestellen. Of uw iptables-regel daarachter goed is, doet dan niet meer ter zake, want de pakketten van uw spelers komen al eerder niet door.

De tweede grootheid is de pakketsnelheid, en die slaat bij Call of Duty regelmatig eerder toe dan de bandbreedte. Bij kleine pakketten van 64 byte passen er in een lijn van 1 Gbit/s ongeveer 1,49 miljoen pakketten per seconde. Een gewone serverkernel verwerkt daarvan, afhankelijk van CPU en netwerkkaart, enkele honderdduizenden voordat hij begint te verwerpen. Een getstatus-aanvraag is met 41 byte nog kleiner dan dat: een aanval die uw lijn niet eens voor een derde vult, legt uw server toch plat, omdat de volledige rekentijd opgaat aan het verwerpen. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch was alles weg".

Bij Call of Duty komt er een bijzonderheid bij die de rekensom verscherpt. Omdat spel, query en RCON op dezelfde poort liggen, kunt u 28960 niet in geval van nood dichtzetten: dat zou hetzelfde zijn als de server uitschakelen. En omdat de engine op elke statusopvraging met een veelvoud van de aanvraaggrootte antwoordt, verbruikt een aanvaller voor hetzelfde effect minder eigen bandbreedte dan bij andere spellen.

Ter oriëntatie, welke ordes van grootte werkelijk voorkomen: op KernelHost-servers zijn onder meer een aanval met meer dan 473,4 Gbit/s bij meer dan 41,5 miljoen pakketten per seconde op een voiceserver en een UDP-flood met meer dan 112,2 Gbit/s op een gameserver weggefilterd. Daarvoor bestaat geen lokale instelling. Volumetrische aanvallen moeten in het netwerk vóór de server eindigen.

Wat KernelHost daartegenover zet

De permanente bescherming die bij elke server inbegrepen is

De DDoS-bescherming van KernelHost is in twee lagen opgebouwd en permanent actief, zonder dat u iets hoeft in te schakelen, te bestellen of te configureren:

• Laag 1: 17 Tbps mitigatiecapaciteit in het globale scrubbing-netwerk. Volumetrische aanvallen worden dicht bij hun bron geschoond, nog voordat ze het datacenter bereiken.
• Laag 2: Arbor realtime filtering met 3,2 Tbps in Frankfurt am Main. Direct vóór de server worden protocolspecifieke patronen herkend en verworpen, pakket voor pakket.

Twee eigenschappen zijn doorslaggevend. De bescherming loopt permanent en hoeft niet eerst op een aanval te reageren, er zijn dus geen eerste minuten waarin de server weg is. En er wordt geen null-routing toegepast: uw IP-adres blijft in het netwerk, alleen de kwaadaardige pakketten worden verworpen. Wie het IP-adres uit het netwerk haalt, bereikt voor u hetzelfde resultaat als de aanvaller. Welke games en protocollen gedekt zijn, somt Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor projecten die permanent onder vuur liggen

Sommige clans en communities worden niet af en toe, maar gericht en wekenlang aangevallen. Daarvoor is er de Advanced DDoS Protection vanaf 50,00 € per maand, PrePaid en zonder minimale looptijd. Het verschil zit niet in meer capaciteit, maar in de controle:

• Een dedicated beschermd IP-adres uit het Frankfurtse kernnetwerk, waarnaar uw server binnen ons eigen netwerk wordt omgezet. Aan uw kant is geen enkele aanpassing nodig.
• Zelf beheerbare beschermingsregels per poort en protocol in het klantenpaneel: u stelt in wat op 28960 UDP is toegestaan, zonder daarvoor een ticket te schrijven, en bij meerdere instanties per poort gescheiden.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen.
• Een beschermingsprofiel dat bij het betreffende spel past, ook voor aangepaste en eigen applicaties op willekeurige TCP- of UDP-poorten. Dat is voor Plutonium en CoD4X het relevante punt, omdat hun poorten van de standaardwaarden kunnen afwijken.

De Advanced DDoS Protection is bedoeld voor servers die bij KernelHost staan. Draait uw Call-of-Duty-server op dit moment ergens anders en wordt hij daar regelmatig uit het netwerk gehaald, dan is de verhuizing naar KernelHost de weg die iets verandert.

De twee lagen naast elkaar

Voor de meeste Call-of-Duty-servers volstaat de inbegrepen permanente bescherming samen met een nette server.cfg. De Advanced DDoS Protection is het antwoord op iemand die het persoonlijk maakt.

Veelgemaakte fouten en oplossingen

"Ik heb het IP-adres gewisseld en was twee uur later weer offline": de aanvaller heeft het nieuwe adres uit dezelfde bron als het oude, meestal de vermelding in de lijst, een Discord-bot met statusweergave of een oud DNS-record. Een adreswissel levert tijd op, geen oplossing.

"Mijn aanbieder stuurt mij een abuse-melding, terwijl ik toch het slachtoffer ben": dan is uw server niet het doelwit, maar de versterker. Iemand stuurt vervalste getstatus-aanvragen, en uw server antwoordt braaf aan een onbekend slachtoffer. Controleer eerst of sv_queryIgnoreMegs op 0 staat, en stel de vier query-dvars plus de firewallregel uit paragraaf 4 in.

"De server staat in de lijst als vol, maar is leeg": dat is een joinflood, en die raakt de spellogica, niet de lijn. Daartegen werken sv_reconnectLimit, kortere waarden voor sv_connectTimeout en sv_timeout en bij twijfel een serverwachtwoord.

"De server verdwijnt tijdens de aanval uit de serverlijst": dat is het gevolg, niet de oorzaak. De serverlijst controleert via dezelfde statusopvragingen of uw server leeft. Komen de antwoorden niet door of zijn ze door uw eigen rem verworpen, dan geldt de server als offline. Controleer of sv_queryIgnoreTime te hoog staat voordat u de firewall verdenkt.

"Mijn iptables-regels grijpen niet": drie oorzaken komen vaak voor. De regels staan achter de UFW-ketens en worden nooit bereikt, ze waren na de laatste herstart verdwenen (dan helpen netfilter-persistent save of een regel in /etc/ufw/before.rules), of de aanval is volumetrisch en de regel werkt correct aan een lijn die al vol zit. Controleer met iptables -L INPUT -n -v of de tellers oplopen.

"De server draait, maar alle spelers hebben lagspikes": kijk eerst naar de pakketsnelheid van de interface, niet naar de CPU-belasting. Blijft sar -n DEV 1 10 onopvallend en hapert het toch, dan ligt het meestal aan een mod, aan een overdreven sv_maxRate of simpelweg aan te veel bots in de ronde.

"Mijn vorige aanbieder heeft mijn IP-adres geblokkeerd": dat is null-routing. De aanbieder beschermt daarmee zijn eigen netwerk, voor u is het resultaat identiek aan een geslaagde aanval, meestal nog urenlang daarna. Vraag bij twijfel na of er wordt gefilterd of null-geroutet. Dat antwoord bepaalt meer over uw beschikbaarheid dan welke hardwarespecificatie ook.

"In de tcpdump zie ik niets opvallends": wordt het verkeer al in het netwerk ervoor gefilterd, dan komt er op de server zoals verwacht niets aan. Dat is het normale beeld bij een werkende filtering. Omgekeerd geldt: zit de lijn vol, dan bereikt u onder omstandigheden zelfs de SSH-sessie niet meer waarmee u wilde meten. Gebruik dan de VNC-console in het klantenpaneel, die losstaat van het netwerk van het gastsysteem.

Kort samengevat

• Een klassieke Call-of-Duty-server heeft precies één open poort nodig: 28960 UDP. Bij Plutonium T6 is dat 4976 UDP, bij Plutonium IW5 27016 UDP.
• Spel, statusopvraging en RCON liggen bij Call of Duty op dezelfde poort. U kunt RCON niet met een poortregel van het spel scheiden, daarvoor hebt u een regel nodig die in de inhoud van het pakket kijkt.
• De getstatus-reflection is de spelspecifieke versterkingsvector: 41 byte aanvraag, volgens CISA-waarschuwing TA14-017A factor 63,9 bij het Quake-netwerkprotocol, dus ongeveer 2.600 byte antwoord.
• Schakel de queryrem in: sv_queryIgnoreMegs 4, sv_queryIgnoreTime 2000, sv_queryBounceIgnoreTime 12000. Op veel servers staat zij op 0 en is daarmee uit.
• Stel rcon_password alleen in wanneer u RCON werkelijk nodig hebt: het wachtwoord loopt onversleuteld over UDP en laat zich zonder accountblokkering onbeperkt vaak raden.
• De masterserverpoorten 20810 en 20800 zijn uitgaande doelpoorten en horen niet in uw inkomende vrijgaven.
• Vanaf ongeveer 1 Gbit/s of enkele honderdduizenden pakketten per seconde beslist uitsluitend het netwerk vóór de server, niet meer uw configuratie.

Draait uw server al bij KernelHost, dan is de filtering actief zonder dat u iets hoeft te doen. Merkt u toch iets ongewoons, open dan een supportticket, zodat wij de filterregels voor uw IP-adres bijstellen. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883.