DayZ-server beschermen tegen DDoS-aanvallen

Een DayZ-server die 's avonds midden in het spel alle spelers eruit gooit en daarna minutenlang uit de serverbrowser verdwijnt, heeft zelden een hardwareprobleem. Meestal loopt er een aanval, en wel precies wanneer de meeste spelers online zijn of de geplande herstart eraan komt. Wie zijn DayZ-server tegen DDoS-aanvallen wil beschermen, heeft daarom beide nodig: een nette poortvrijgave op de server en een filtering in het netwerk ervoor. Dit artikel laat eerst zien wat u zonder extra kosten zelf kunt afschermen, daarna waar die maatregelen technisch ophouden, en tot slot wat er dan vóór de server moet gebeuren.

Alle gegevens hebben betrekking op een eigen DayZ-dedicated server met serverDZ.cfg, ongeacht of die onder Windows Server draait of onder Debian en Ubuntu via een compatibiliteitslaag. Een productierijp, native Linux-serverprogramma voor de stable-tak levert Bohemia Interactive niet uit, en de experimentele Linux-build accepteert uitsluitend experimentele clients. De Linux-commando's zijn voor root geschreven, als gewone gebruiker zet u er sudo voor.

Loopt de aanval op dit moment: verander nu niets aan de serverDZ.cfg en start de server niet opnieuw op. Een DayZ-herstart laadt de mods en de centrale economie opnieuw en kost u meerdere minuten waarin de server gegarandeerd offline is. Leg eerst de meetwaarden vast (zie de paragraaf "Loggen"), na de aanval zijn ze verdwenen.

Waarom DayZ-servers zo vaak doelwit van DDoS-aanvallen zijn

DayZ verenigt meerdere eigenschappen die een server tot een gemakkelijk doelwit maken. Ten eerste publiceert een communityserver zijn adres uit zichzelf: om in de serverbrowser van het spel en in de DZSA-launcher te verschijnen, moet hij Steam-opvragingen beantwoorden, en dat antwoord bevat het IP-adres en de poort in leesbare vorm. Een aanvaller hoeft dus niets uit te zoeken, hij hoeft alleen een lijst te lezen.

Ten tweede is het dagritme van een DayZ-server openbaar. Vrijwel alle projecten starten elke drie tot vier uur automatisch opnieuw op, kondigen dat per chatbericht aan en zetten het schema in hun Discord. Een aanval die precies in dat tijdvenster valt, werkt dubbel: de server is toch al even onbereikbaar, en de spelers die in het wachtgebied blijven hangen, gaan ergens anders heen.

Ten derde is de inzet voor de spelers hoog. Een uitval op de verkeerde minuut betekent in DayZ niet alleen frustratie, maar verloren uitrusting, afgebroken raids en een basis die onbeschermd in de wereld staat. Juist daarom zijn verbannen spelers, vijandige groepen en concurrerende projecten de meest voorkomende opdrachtgevers. Een aanval via een van de gebruikelijke booterdiensten kost de veroorzaker kunde noch noemenswaardig geld.

Ten vierde loopt al het DayZ-verkeer over UDP. UDP kent geen verbindingsopbouw die u zou kunnen eisen, en het afzenderadres laat zich vervalsen. Een aanvaller hoeft uw server dus niet te betreden en hoeft hem ook niet correct aan te spreken om belasting te veroorzaken. Dat zelfs de maker daar last van heeft, liet februari 2025 zien: de onlinediensten van Bohemia Interactive voor DayZ en Arma Reforger lagen ruim een week onder DDoS-vuur, op 3 februari 2025 bevestigd en op 6 februari 2025 nog altijd niet beëindigd, en communityservers waren mede getroffen. Wat een DDoS-aanval in detail is, legt het artikel Wat is een DDoS-aanval? uit.

De poorten van een DayZ-server: feitentabel

Een DayZ-server spreekt uitsluitend UDP. Er is geen TCP-spelpoort. De enige waarde die bij DayZ werkelijk vastligt, is 2302/UDP als spelpoort, al het overige is configureerbaar en verschilt per hoster. Kijk daarom in uw eigen startregel en uw eigen serverDZ.cfg na in plaats van op een standaardwaarde te vertrouwen.

Twee waarden zorgen regelmatig voor verwarring, daarom hier de opheldering. De Steam-querypoort: de door Bohemia meegeleverde voorbeeldconfiguratie zet steamQueryPort = 2305;, terwijl een groot deel van de hosters 27016/UDP gebruikt. Beide waarden zijn geldig, doorslaggevend is alleen de waarde in uw bestand. De BattlEye-RCon-poort: hier bestaat helemaal geen bindende standaard. De verbreide vuistregel is spelpoort plus drie, dus 2305, andere hosters zetten 2310. Sinds DayZ 1.13 leest BattlEye de parameter RConPort in de BEServer_x64.cfg betrouwbaar uit, daarvoor was de poort moeilijk te voorspellen.

Daaruit volgt een valkuil waar veel beheerders in lopen: zet steamQueryPort en RConPort nooit op dezelfde waarde. Voorziet uw configuratie 2305 voor de Steam-opvraging, dan hoort RCon op een andere poort, bijvoorbeeld 2310.

Waarom de Steam-querypoort de gevoeligste poort is

De Steam-querypoort beantwoordt de drie opvragingen A2S_INFO, A2S_PLAYERS en A2S_RULES. A2S_INFO levert servernaam, kaart, spelersaantal en versie, A2S_PLAYERS de namen van de verbonden spelers, A2S_RULES de ingestelde servervariabelen. Elk van die antwoorden is duidelijk groter dan de aanvraag die het heeft uitgelokt, en juist dat maakt de poort dubbel gevaarlijk.

Voor u als doelwit betekent het: een aanvaller kan uw querypoort met enkele bytes per aanvraag bezighouden, terwijl uw server elke keer een volledig antwoord samenstelt en verstuurt. Voor derden betekent het: een aanvaller kan uw server met een vervalst afzenderadres opvragen en de antwoorden naar zijn eigenlijke doelwit leiden. Uw server is dan niet alleen slachtoffer, maar ook versterker. Valve heeft A2S_INFO in december 2020 daarom uitgebreid met een challenge-opvraging: de server antwoordt eerst met een willekeurig getal dat de aanvrager moet terugsturen. Dat ontkracht de versterking, maar beëindigt haar niet, omdat lang niet elke opvraging die weg gaat.

DayZ heeft hier een bijzonderheid die andere games niet hebben: er vragen twee gescheiden serverlijsten bij u aan, de ingebouwde community-serverbrowser en de wijdverbreide DZSA-launcher. De querypoort eenvoudigweg sluiten is daarom geen optie, want dan is uw project uit beide lijsten verdwenen hoewel de directe verbinding blijft werken. Begrenzen in plaats van sluiten is het juiste antwoord.

Wat u zelf kunt doen voordat u geld uitgeeft

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

1. Inventarisatie: welke poorten uw DayZ-server werkelijk opent

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

ss -lnup
ss -lntup

Onder Windows Server levert de opdrachtprompt hetzelfde beeld:

netstat -ano -p UDP | findstr "2302 2303 2304 2305 27016"

Interessant is de kolom met het lokale adres. 0.0.0.0:2302 betekent "vanaf het hele internet bereikbaar", 127.0.0.1:2310 betekent "alleen lokaal" en heeft geen openstelling nodig. Daarna leest u de werkelijke waarden rechtstreeks uit uw configuratiebestanden in plaats van op een handleiding te vertrouwen:

grep -iE "steamQueryPort|maxPlayers|password|enableWhitelist|verifySignatures" serverDZ.cfg
grep -iE "RConPort|RestrictRCon" battleye/BEServer_x64.cfg

Het beeld van de aanvaller levert een UDP-poortscan van buitenaf, uitgevoerd vanaf een andere machine:

nmap -Pn -sU -p 2302-2310,27015-27020 UW.SERVER.IP.ADRES

2. Alleen openstellen wat startregel en serverDZ.cfg werkelijk nodig hebben

Voor DayZ volstaan twee openstellingen naar buiten: het spelpoortblok en de querypoort. Al het andere wordt tot uw eigen adres 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 2302:2305/udp comment 'DayZ spelpoort'
ufw allow 27016/udp comment 'DayZ Steam Query'
ufw allow from 203.0.113.10 to any port 2310 proto udp comment 'BattlEye RCon'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Vervang 203.0.113.10 door uw eigen adres en 27016 door de waarde die werkelijk in uw steamQueryPort-regel staat. De volledige handleiding inclusief reddingsweg vindt u onder UFW-firewall instellen zonder uzelf buiten te sluiten. Op een Windows-server geldt hetzelfde principe: één inkomende regel per poortgroep, Remote Desktop beperkt tot het eigen adres, al het overige geblokkeerd.

3. De Steam-querypoort begrenzen in plaats van hem te sluiten

Een bovengrens per bronadres scheidt echte serverlijsten van opvraagfloods. Een serverbrowser vraagt u per seconde aan, een aanvaller per milliseconde:

iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name dayz_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name dayz_game --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

De eerste regel verwerpt Steam-opvragingen zodra er blijvend meer dan tien per seconde uit dezelfde bron komen, de tweede spelpakketten vanaf meer dan 600 per seconde. Beide getallen zijn startwaarden, geen waarheden. Een volle server met 60 spelers produceert duidelijk meer pakketten dan een lege, en wie te krap instelt, gooit zijn eigen spelers eruit of vliegt uit de serverlijst. Meet daarom eerst een week lang in normaal bedrijf.

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. Daarnaast kent de Steam-serverbibliotheek een eigen rem voor verbindingsloze pakketten: de omgevingsvariabele STEAM_GAMESERVER_RATE_LIMIT_200MS verwerpt alle A2S-pakketten van een adres zodra er in een venster van 200 milliseconden meer dan de ingestelde waarde binnenkomt.

Het derde punt kost helemaal niets: toont uw Discord-bot of uw projectpagina de spelersstand, vraag de server dan niet vanuit de bezoeker op, maar sla het resultaat op vaste intervallen tussentijds op. Daarmee veroorzaakt een druk bezochte statuspagina één opvraag per interval in plaats van één per bezoeker.

4. BattlEye-RCon van het open internet halen

BattlEye is de anti-cheatcomponent van DayZ en wordt in de serverDZ.cfg met BattlEye = 1; ingeschakeld. Het beheer op afstand staat daarentegen in een eigen bestand, de BEServer_x64.cfg in de BattlEye-map naast BEServer_x64.dll, die de startregel met -BEpath= aanwijst:

RConPassword EenLangWillekeurigWachtwoord
RConPort 2310
RestrictRCon 0

Drie regels daarbij. Ten eerste: de RCon-poort is UDP, niet TCP. Een firewallregel die per ongeluk proto tcp zegt, filtert niets en laat tegelijk de beheerhulpmiddelen in het niets lopen. Ten tweede: beperk de poort tot de adressen van uw beheerders. Wie geen vast adres heeft, laat de poort van buitenaf volledig dicht en start het beheerhulpmiddel rechtstreeks op de server, bereikbaar via SSH of Remote Desktop. Ten derde: RestrictRCon 1 begrenst de via RCon uitvoerbare commando's en is de juiste instelling zodra meer dan één persoon toegang heeft.

Een open RCon-poort is twee dingen tegelijk: een uitnodiging om wachtwoorden door te proberen en nog een UDP-poort die men kan overspoelen. Beide vallen weg zodra de openstelling nog maar voor een handvol adressen geldt.

5. Loginwachtrij, whitelist en slotuitputting

DayZ werkt verbindingen niet allemaal tegelijk af, maar via een wachtrij. Vijf waarden in de serverDZ.cfg sturen haar aan:

maxPlayers = 60;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 100;
guaranteedSlots = 10;
maxPing = 200;

loginQueueConcurrentPlayers legt vast hoeveel spelers tegelijk worden binnengelaten (standaardinstelling 5), loginQueueMaxPlayers begrenst de wachtrij zelf (gebruikelijke waarden tussen 100 en 500). Precies daar zet de slotuitputting aan: een aanvaller heeft geen bandbreedte nodig, hij heeft alleen genoeg accounts of verbindingspogingen nodig om de wachtrij te bezetten. Echte spelers komen er dan niet meer door, hoewel de server technisch onberispelijk draait. guaranteedSlots reserveert plaatsen voor uw team, zodat u in precies die situatie zelf nog op de server komt.

Daartegen helpt de ingebouwde whitelist. Die wordt met enableWhitelist = 1; geactiveerd en leest vervolgens het bestand profiles/whitelist.txt, met één Steam64-ID per regel. Elke niet vermelde ID wordt bij het verbinden afgewezen. Het bestand wordt bij het opstarten van de server ingelezen, wijzigingen vereisen dus een herstart. Een aanvullend password in de serverDZ.cfg werkt vergelijkbaar, maar is zwakker, omdat een wachtwoord wordt doorgegeven en een Steam64-ID niet.

Eén ding moet daarbij duidelijk zijn: een whitelist beschermt uw spelersplaatsen, 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.

6. Mods, handtekeningcontrole en het tijdvenster na de herstart

Mods zijn bij DayZ niet alleen een comfortkwestie, ze zijn een deel van het aanvalsoppervlak. Vier instellingen in de serverDZ.cfg horen in elk geval gezet te zijn:

verifySignatures = 2;
forceSameBuild = 1;
allowFilePatching = 0;
BattlEye = 1;

verifySignatures = 2 controleert elk PBO-bestand tegen de bijbehorende .bisign-handtekening en heeft daarvoor de passende .bikey-bestanden in de map keys nodig. forceSameBuild = 1 verlangt exact dezelfde spelversie als op de server. allowFilePatching = 0 wijst clients af die met gewijzigde spelbestanden starten. Geen van deze instellingen stopt een volumetrische aanval, maar alle drie sluiten de weg waarlangs een gemanipuleerde client uw server uit het lood brengt.

Het tweede punt is het belangrijkere en wordt bijna altijd over het hoofd gezien: de startfase. Een DayZ-server laadt bij het opstarten eerst zijn modlijst uit de startregel en daarna de centrale economie met alle loottabellen. Bij een sterk gemodificeerde server zijn dat al snel meerdere minuten waarin de server geen enkele Steam-opvraging beantwoordt:

./DayZServer -config=serverDZ.cfg -port=2302 -profiles=./profiles -BEpath=./battleye -mod=@CF;@UwMod;@NogEenMod -cpuCount=4 -dologs -adminlog -netlog -freezecheck

Omdat vrijwel elk project elke drie tot vier uur opnieuw opstart en dat schema ook nog aankondigt, is dat tijdvenster voor een aanvaller triviaal te treffen. Drie tegenmaatregelen zijn werkzaam en kosten niets. Houd de modlijst zo kort mogelijk, elke extra mod verlengt precies dat venster. Leg de hersteltijden op onronde waarden in plaats van op het hele uur. En meet één keer na hoe lang uw start werkelijk duurt in plaats van te schatten: met timeStampFormat = "Full"; en een ingesteld logFile staat de duur daarna in het logboek.

7. Verbindingsregistratie, ontvangstbuffers en kernelparameters

Een vaak over het hoofd gezien knelpunt is de verbindingsregistratie van de kernel. UDP kent weliswaar geen verbindingen, maar de kernel legt toch voor elk paar van bron- en doeladres een vermelding aan. Loopt de tabel vol, dan verwerpt de server ook legitieme pakketten en staat er in het logboek "nf_conntrack: table full". Stand en bovengrens toont:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Voor een pure gameserver is de nette oplossing om het spelverkeer helemaal niet te laten volgen, en daarnaast de ontvangstbuffers en de wachtrij van de netwerkkaart te vergroten:

iptables -t raw -A PREROUTING -p udp --dport 2302 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 2302 -j NOTRACK
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=1048576
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.netfilter.nf_conntrack_max=524288

Let op: NOTRACK en toestandsgebonden regels sluiten elkaar uit. Wie de spelpoort van de registratie uitzondert, mag voor die poort geen regel met -m conntrack --ctstate meer gebruiken, anders werkt de openstelling niet meer. Blijvend horen de sysctl-waarden in /etc/sysctl.d/, anders zijn ze na de volgende herstart verdwenen.

8. Uw IP-adres staat in de serverbrowser

Hier loont eerlijkheid meer dan wensdenken: het IP-adres van een openbare DayZ-server laat zich niet geheimhouden. Iedere speler die ooit verbonden is geweest, kent het, de serverbrowser publiceert het, en de DZSA-launcher slaat het tussentijds op. Een adreswissel levert u uren op, zelden dagen.

Werkzamer zijn twee gewoonten. Publiceer het kale IP-adres nergens aanvullend, dus niet in het vastgezette Discord-bericht en niet op de projectpagina. En ruim uw DNS-records op: een vergeten A-record naar het vorige adres maakt elke wissel zinloos, en juist daarop lopen de meeste wisselingen stuk. Wie op de oude server nog een statusdienst laat draaien, verraadt het nieuwe adres meteen mee.

9. Loggen, zodat u tijdens een aanval niet hoeft te gokken

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 zaterdagavond. Aan serverzijde schakelt u daarvoor de ingebouwde logboeken in:

timeStampFormat = "Short";
logAverageFps = 300;
logPlayers = 300;
logFile = "server_console.log";

logAverageFps is daarbij de eerlijkste waarde die DayZ levert. Zakt de framerate van de server in terwijl het spelersaantal gelijk blijft, dan is dat een mod- of economieprobleem. Blijft de framerate stabiel terwijl spelers eruit vliegen, dan ligt het aan het netwerk. Aan systeemzijde lopen de metingen met apt-get install -y vnstat sysstat permanent mee, en 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 2302 -c 200 -q

Voor tcpdump geldt: begrens hem altijd 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 op de server herkennen.

Waar de eigen bescherming ophoudt: bandbreedte en pakketsnelheid

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 niet terugdraaien dat het verstuurd is.

De pakketsnelheid slaat bij DayZ vaak eerder toe dan de bandbreedte, en dat heeft een eenvoudige reden: het spelverkeer bestaat uit veel kleine UDP-pakketten, niet uit weinig grote. Een aanval die uw lijn nog niet eens voor een derde vult, kan uw server daarom toch platleggen, omdat de rekentijd opgaat aan het verwerpen. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch had iedereen lagpieken en vloog er de een na de ander uit".

Volumetrische aanvallen moeten in het netwerk vóór de server eindigen. Dat is geen productuitspraak, maar natuurkunde.

DayZ-DDoS-bescherming: wat KernelHost daartegenover zet

De permanente bescherming die op elke server loopt

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, dus er zijn 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 projecten 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 gescheiden in wat op 2302/UDP is toegestaan, wat op de querypoort en wat op de RCon-poort. Precies die scheiding is bij DayZ de hefboom, omdat spelverkeer en opvraagverkeer er volkomen verschillend uitzien.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen in plaats van op een ticket te wachten.
• Een beschermingsprofiel dat bij het spel past, ook voor sterk gemodificeerde servers en eigen applicaties op willekeurige TCP- of UDP-poorten.

De twee lagen naast elkaar

Voor de meeste DayZ-projecten volstaat de inbegrepen permanente bescherming samen met een nette serverconfiguratie. De Advanced DDoS Protection is het antwoord op iemand die het persoonlijk maakt. Wie zijn DayZ-server momenteel elders draait, kan de bescherming niet achteraf bijbouwen: ze is deel van het netwerk en geldt voor servers die bij KernelHost staan. De weg daarheen is een verhuizing, geen extra product.

Veelgemaakte fouten en oplossingen

"Mijn server is uit de DZSA-launcher en de serverbrowser verdwenen, via een directe verbinding kom ik er wel op": dat is in de meeste gevallen geen aanval, maar de querypoort. Ofwel staat er in steamQueryPort een andere waarde dan in de firewall, ofwel verwerpt een te krappe snelheidsbegrenzing de opvragingen van de serverlijst. Controleer beide waarden tegen elkaar voordat u een aanval vermoedt.

"RCon verbindt niet meer sinds ik de poorten heb gefilterd": BattlEye-RCon loopt over UDP. Een openstelling met proto tcp op dezelfde poort doet niets. Controleer bovendien of RConPort en steamQueryPort per ongeluk op dezelfde waarde staan.

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

"De aanval komt elke dag exact bij de herstart": dat is geen toeval. Het herstartschema staat in de Discord en wordt in het spel aangekondigd, en terwijl mods en economie laden, antwoordt de server toch al niet. Een kortere modlijst, onronde hersteltijden en een filtering die permanent loopt in plaats van eerst op een aanval te reageren, ontnemen dit patroon zijn werking.

"Alle spelers hebben lagpieken, maar het netwerk is rustig": dan was het geen DDoS-aanval. Kijk eerst in logAverageFps of de framerate van de server is ingezakt, en daarna in de centrale economie en de modlijst. Blijft sar -n DEV 1 10 onopvallend, dan ligt het niet aan het netwerk.

"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 treffertellers oplopen. Blijven ze op nul staan, dan wordt de regel niet bereikt.

"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 DayZ-server heeft naar buiten toe precies twee dingen nodig: het spelpoortblok vanaf 2302/UDP en de Steam-querypoort uit uw steamQueryPort-regel. Al het andere hoort beperkt of gesloten te zijn.
• De BattlEye-RCon-poort heeft geen bindende standaard, loopt over UDP en wordt in de BEServer_x64.cfg met RConPort gezet. Hij hoort nooit op het open internet en nooit op dezelfde waarde als de querypoort.
• De querypoort begrenzen in plaats van sluiten: wie hem dichtzet, verdwijnt uit de serverbrowser en uit de DZSA-launcher, hoewel de directe verbinding blijft werken.
• Whitelist, guaranteedSlots en de loginwachtrij beschermen uw spelersplaatsen tegen slotuitputting, maar niet uw lijn tegen bandbreedte.
• Het gevaarlijkste tijdvenster van een DayZ-server is de geplande herstart elke drie tot vier uur, omdat mods en centrale economie minutenlang laden en het tijdstip openbaar bekend is.
• Vanaf ongeveer 1 Gbit/s aanvalsvolume of enkele honderdduizenden pakketten per seconde beslist uitsluitend het netwerk vóór de server, niet meer uw firewall.
• Bij KernelHost zit de permanente bescherming in twee lagen in elk serverpakket inbegrepen, zonder meerprijs en zonder null-routing. De Advanced DDoS Protection vanaf 50,00 € per maand komt daarbij wanneer u de regels per poort zelf wilt sturen.

Draait uw project 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 de filterregels voor uw IP-adres worden bijgesteld. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883.