Project-Zomboid-server beschermen tegen DDoS-aanvallen

Wie zijn Project-Zomboid-server tegen DDoS-aanvallen wil beschermen, moet eerst weten waarop een aanvaller überhaupt schiet. Een dedicated server bezet precies twee UDP-poorten, 16261 en 16262, en beide moeten open op het netwerk staan, omdat anders niemand kan meedoen. Dit artikel gaat te werk in de volgorde die in geval van nood telt: eerst wat u in de komende tien minuten zonder extra kosten zelf kunt doen, daarna het punt waarop die maatregelen technisch ophouden, en tot slot wat er in het netwerk ervoor moet gebeuren.

Alle informatie hier gaat uit van de dedicated server (Steam-app 380870) onder Debian 12, Debian 13, Ubuntu 22.04 LTS of Ubuntu 24.04 LTS, voor build 41 net zo goed als voor build 42. Het configuratiebestand heet servertest.ini en staat onder ~/Zomboid/Server/, de wereldgegevens staan onder ~/Zomboid/Saves/Multiplayer/. De 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 servertest.ini en start de server niet opnieuw op. Leg eerst de meetwaarden vast (paragraaf 9), na de aanval zijn ze verdwenen. Een herstart kost bovendien de tijd die de server nodig heeft om de wereld te laden, en juist die wil de aanvaller u afnemen.

Waarom Project-Zomboid-servers het doelwit van DDoS-aanvallen worden

Project Zomboid is een spel met permanente dood en een wereld die maandenlang doorloopt. Een verbindingsverlies midden in een gevaarlijke situatie kost hier meer dan in vrijwel elk ander genre: het personage is weg, en de wereld onthoudt dat. Juist dat maakt een uitval tot een wapen. Een aanval om 20 uur treft een vaste community, en hij treft haar op de plek waar zij het meest te verliezen heeft.

Daar komt bij dat de aanval zelf niets kost en geen kunde verlangt. Geboekte aanvalsdiensten, in het milieu booters of stressers genoemd, richten zich met een paar klikken tegen een IP-adres en een poort, en bij Project Zomboid is het doelwit altijd hetzelfde: 16261 UDP. Wie ruzie heeft met een verbannen speler of een concurrerende community beheert, heeft daarmee een werktuig in handen waarvoor hij kennis noch noemenswaardig geld nodig heeft.

Daar komt bij dat een gameserver zijn adres moet publiceren. Staat er Public=true in de servertest.ini, dan verschijnt de server in de browser van het spel, en een server met Steam-koppeling is sowieso zichtbaar in de Steam-serverbrowser. De vraag luidt dus nooit of een aanvaller uw IP-adres vindt, maar alleen wat er gebeurt wanneer hij daarop schiet.

Technisch komt het onaangenaamste deel als laatste: het volledige spelverkeer loopt over UDP. UDP kent geen verbindingsopbouw die u zou kunnen eisen, elk pakket staat op zichzelf, 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. Wat een DDoS-aanval in detail is, legt het artikel Wat is een DDoS-aanval? uit.

Welke poorten een Project-Zomboid-server werkelijk nodig heeft

Een dedicated Project-Zomboid-server heeft precies twee open poorten nodig: 16261 UDP en 16262 UDP. De officiële poortenlijst van het spel noemt geen derde. In de servertest.ini staan ze als twee gescheiden directives, de tweede poort volgt niet automatisch uit de eerste:

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

De taakverdeling is eenduidig. 16261 UDP draagt het spelverkeer en de verbindingsopbouw en beantwoordt de opvragen van de serverbrowser. 16262 UDP is de poort voor de directe verbinding van de clients. Ontbreekt de eerste, dan vindt niemand de server, ontbreekt de tweede, dan zien uw spelers de vermelding en komen ze toch niet binnen. Precies daar komt de bekendste foutmelding van het spel vandaan, dat poort 16262 gesloten zou zijn.

Twee punten die geregeld last geven. Ten eerste: elke serverinstantie heeft twee vrije UDP-poorten nodig. Wie een tweede wereld op dezelfde machine draait, geeft daarvoor een tweede paar uit, bijvoorbeeld 16274 en 16275, en zet beide waarden in de servertest.ini van de tweede instantie. Ten tweede: SteamPort1 en SteamPort2 staan met 8766 en 8767 in het configuratiebestand, maar horen bij de Steam-koppeling en niet bij het spelverkeer. Zet ze alleen open wanneer uw server zonder hen niet in de Steam-lijst opduikt, niet uit voorzorg.

Wat u zelf kunt doen voordat u geld uitgeeft

Dit hoofdstuk is het langste, en dat met opzet. Een netjes geconfigureerde server houdt kleine en middelgrote aanvallen op eigen kracht uit, ongeacht bij wie hij staat. Hij neemt u geen volumetrische aanval af, maar zorgt er wel voor dat goedkope aanvallen zonder gevolg blijven en dat u in geval van nood cijfers hebt in plaats van vermoedens.

1. Inventarisatie: wat luistert er werkelijk

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:16261 en [::]:16261 betekenen "vanaf het hele internet bereikbaar", 127.0.0.1:27015 betekent "alleen lokaal" en heeft geen openstelling nodig. Leg het resultaat naast uw configuratie in plaats van op standaardwaarden te vertrouwen:

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

Het beeld van de aanvaller levert een poortscan van buitenaf. Omdat Project Zomboid uitsluitend UDP gebruikt, is daarvoor de UDP-scan nodig, een zuivere TCP-scan toont de spelpoort helemaal niet:

nmap -Pn -sU -p 16261,16262,8766,8767 UW.SERVER.IP.ADRES
nmap -Pn -p- --min-rate 1000 UW.SERVER.IP.ADRES

2. Alleen 16261 en 16262 openlaten

Twee openstellingen naar buiten volstaan, 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 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid directe verbinding"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Vervang 203.0.113.10 door uw eigen adres. De volgorde bij het scherpstellen bepaalt of u zichzelf buitensluit. Die staat inclusief terugweg in het artikel UFW-firewall instellen zonder uzelf buiten te sluiten. Mocht het toch gebeuren: bij KVM-rootservers en dedicated servers van KernelHost bereikt u het systeem via de VNC-console in het klantenpaneel, die losstaat van het netwerk van het gastsysteem.

Een woord over databases en aanvullende diensten: Project Zomboid heeft er geen nodig. Wat naast het spel op 0.0.0.0 luistert, stamt uit een eerdere installatie of van een beheerpaneel en hoort ofwel aan 127.0.0.1 gebonden te worden ofwel uitgeschakeld.

3. RCON op poort 27015 uit het internet halen

RCON is de afstandsbediening van de server en loopt bij Project Zomboid op 27015 TCP. In de meegeleverde servertest.ini staat RCONPassword= zonder waarde. Wie RCON gebruikt, zet er een lang willekeurig wachtwoord op, want het protocol verstuurt onversleuteld, en een bereikbare RCON-poort met een zwak wachtwoord geeft de server volledig weg, zonder dat daarvoor ook maar één pakket aanvalsverkeer nodig is.

De veilige weg is om de poort helemaal niet naar buiten open te zetten en hem via een poortdoorschakeling per SSH te bereiken. Daarna praat u lokaal met 127.0.0.1:27015:

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

Wie RCON niet nodig heeft, laat het wachtwoordveld leeg en de poort gesloten. Een dienst die niet bereikbaar is, kan niet worden doorgeprobeerd en niet worden overspoeld.

4. Pakketsnelheden per bronadres begrenzen

Tegen kleine aanvallen en slordige bots helpt een bovengrens per bronadres. Omdat beide spelpoorten naast elkaar liggen, volstaat één regel voor het bereik:

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

De regel verwerpt UDP-pakketten zodra hetzelfde bronadres blijvend meer dan 400 pakketten per seconde stuurt. De waarde is een startwaarde, geen waarheid: een server met 30 spelers in dezelfde stad produceert duidelijk meer verkeer dan een met vier spelers in verschillende hoeken van de kaart, en wie te krap instelt, gooit zijn eigen spelers eruit. Meet eerst een week lang in normaal bedrijf, daarna zet u de grens op een veelvoud van de piekwaarde.

Twee opmerkingen daarbij. Kale iptables-regels zijn na een herstart verdwenen; onder Debian en Ubuntu bewaart men ze zo:

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

En onder UFW horen zulke regels in /etc/ufw/before.rules, omdat ze anders bij de volgende ufw reload verdwijnen. Controleer met de treffertellers uit iptables -L INPUT -n -v of de regel überhaupt wordt bereikt. Blijven de tellers op nul staan, dan staat ze op de verkeerde plek.

5. De verbindingsregistratie ontlasten

Een vaak over het hoofd gezien knelpunt zit in de kernel. De verbindingsregistratie legt ook voor UDP een record aan per bronadres en poort, en een flood met vervalste afzenders vult die tabel in seconden. Loopt ze vol, dan verwerpt de server ook legitieme pakketten, en in het logboek staat "nf_conntrack: table full". Stand en bovengrens toont:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Het spelverkeer van Project Zomboid heeft geen toestandsregistratie nodig, omdat UDP geen toestand kent. U kunt de beide spelpoorten daarom buiten die tabel houden:

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

Dat ontlast de kernel merkbaar. Belangrijk: de regel past alleen zolang de server de pakketten rechtstreeks krijgt. Wie er een adresomzetting voor heeft staan, bijvoorbeeld in een containeropzet met poortdoorgifte, mag haar niet zetten, omdat de retourrichting dan niet meer wordt toegewezen.

6. Toetreding en plaatsen afschermen

De volgende regels kosten niets en werken tegen alles wat via de reguliere toetredingsweg binnenkomt:

Password=EEN-LANG-WILLEKEURIG-WACHTWOORD
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password is het gemeenschappelijke serverwachtwoord en staat los van het account van de afzonderlijke speler. Open=false betekent dat alleen accounts mogen toetreden die een beheerder vooraf heeft aangemaakt, dat is de whitelist van het spel. MaxAccountsPerUser begrenst hoeveel accounts één Steam-gebruiker op uw server mag aanmaken, de standaardwaarde 0 betekent onbeperkt. MaxPlayers staat standaard op 32, en daarboven waarschuwt de documentatie uitdrukkelijk voor slecht nalezen van de kaart en desynchronisatie.

PingLimit is op deze plek de valkuil. De directive gooit spelers eruit vanaf een latentie in milliseconden en staat standaard op 0, dus uit. Onder een aanval stijgt de latentie van uw eigen spelers het eerst, een krappe waarde kickt dus precies de mensen die u wilt houden. Laat die grens uit staan of zet haar ruim.

En één ding moet duidelijk zijn: een whitelist 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 mod-vergelijking bij het verbinden is de duurste seconde van uw server

Project Zomboid controleert bij het verbinden meer dan een wachtwoord. De modlijst van de server staat in twee regels van de servertest.ini: WorkshopItems bevat de numerieke Workshop-ID's, Mods de laad-ID's van de mods, beide gescheiden door een puntkomma. Bij het toetreden vergelijkt de client die lijst, laadt ontbrekende Workshop-inhoud automatisch via Steam na en krijgt pas daarna de wereldgegevens gestreamd. Daarnaast vergelijkt de server bij DoLuaChecksum=true de controlesommen van de spelbestanden en gooit clients eruit waarvan de bestanden niet bij de zijne passen.

Voor een aanvaller is juist dat interessant, want het werk valt vóór de eigenlijke spelname aan. Elke verbindingspoging kost de server rekentijd voor versie, controlesom, modlijst en kaartgegevens, ook de poging die uiteindelijk wordt afgewezen. Een lange modlijst maakt elk van die pogingen duurder. Een join-flood is op een sterk gemodificeerde server daarom werkzamer dan op een onveranderde, en hij heeft daarvoor een fractie van de bandbreedte van een volumetrische aanval nodig. Het spel brengt daartegen twee ingebouwde remmen mee:

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer wijst nieuwe aanmeldingen af zolang de server overbelast is, in plaats van de lopende ronde mee te laten sneuvelen. LoginQueueEnabled zet toetreders in een wachtrij in plaats van ze gelijktijdig af te handelen, en LoginQueueConnectTimeout legt vast hoe lang een toetreding mag duren, standaardwaarde 60 seconden, toegestaan zijn 20 tot 1200.

Eén detail hoort erbij, omdat het vaak verkeerd wordt opgelost: op Linux-servers bestaat een gedocumenteerde fout waarbij DoLuaChecksum vals alarm slaat en spelers niet binnenlaat. Beheerders schakelen de controle daarom uit. Dat is navolgbaar, maar verwijdert wel een controle die clients met gewijzigde spelbestanden buiten houdt. Wie haar moet uitschakelen, hoort serverwachtwoord, whitelist en accountgrens des te strenger te zetten.

8. Serverlijst, UPnP en het eigen adres

Hier loont eerlijkheid meer dan wensdenken: uw IP-adres laat zich niet geheimhouden. Public=true toont de server in de browser van het spel, en een server met Steam-koppeling is volgens de documentatie sowieso zichtbaar in de Steam-serverbrowser. Public=false neemt u dus de zichtbaarheid voor nieuwe spelers af zonder u onzichtbaar te maken.

Public=true
PublicName=Mijn Zomboid-server
UPnP=false
server_browser_announced_ip=

UPnP staat standaard op true en laat de server proberen om op een internetgateway zelf een poortopenstelling in te richten. Op een gehuurde server bestaat zo'n gateway niet, de poging loopt in het niets en hoort uitgeschakeld te worden. server_browser_announced_ip blijft leeg, tenzij uw server meerdere adressen heeft en gericht onder een daarvan moet opduiken. Precies dat veld hebt u later weer nodig wanneer u overstapt op een dedicated beschermd IP-adres.

Twee gewoonten helpen meer dan welke instelling ook. Publiceer het kale IP-adres nergens zelf, dus niet in het Discord-kanaal en niet op de projectpagina, en geef uw spelers een hostnaam. De klassieker bij een adreswissel zijn oude DNS-records: een vergeten A-record naar het vorige adres maakt elke wissel zinloos.

9. Meten zolang alles normaal draait

De belangrijkste stap is die welke bijna niemand vooraf zet: een vergelijkingsbasis aanleggen zolang alles rustig is. Zonder normaalwaarde kunt u na een incident niet zeggen of 40.000 pakketten per seconde veel was of gewoon zaterdagavond. 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
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

De eerste twee tonen pakketsnelheid en tellers voor verworpen pakketten van de interface, de derde een korte steekproef van het verkeer, de vierde de meldingen van de server, voor zover hij als systemd-dienst draait (naam van de dienst aanpassen). 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 deze maatregelen ophouden: 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 u kunt niet terugdraaien dat het verstuurd is.

Rekent u even mee. Een typische gameserver hangt aan 1 Gbit/s, dat is 125 megabyte per seconde, en de lijn zit vol zodra iemand meer stuurt. De tweede grootheid is de pakketsnelheid, en die slaat vaak eerder toe dan de bandbreedte: bij kleine pakketten van 64 byte passen er in 1 Gbit/s ongeveer 1,49 miljoen pakketten per seconde, terwijl een gewone serverkernel er afhankelijk van CPU en netwerkkaart maar enkele honderdduizenden van verwerkt voordat hij begint te verwerpen. Een aanval die uw lijn nog niet eens voor een derde vult, kan uw server dus platleggen. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch was alles weg".

Gebruikelijke aanvallen tegen gameservercommunity's liggen tussen 5 en 50 Gbit/s, dus op het vijf- tot vijftigvoudige van een normale lijn. Daarvoor bestaat geen lokale instelling. Volumetrische aanvallen moeten in het netwerk vóór de server eindigen.

Wat KernelHost tegen DDoS-aanvallen op gameservers zet

De permanente bescherming die op 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, 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 spellen en protocollen gedekt zijn, somt Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor permanent beschoten projecten

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, zonder minimale looptijd en zonder installatiekosten. 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 aanpassing nodig, het nieuwe adres zet u alleen daar neer waar uw spelers de server vinden.
• Zelf beheerbare beschermingsregels per poort en protocol in het klantenpaneel: u legt vast wat op 16261 en 16262 UDP is toegestaan, en al het andere blijft dicht, zonder daarvoor een ticket te schrijven.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen.
• Een passend beschermingsprofiel. Voor gangbare spellen bestaan kant-en-klare profielen, voor gemodificeerde en eigen applicaties zet u de regels per poort en protocol zelf. Project Zomboid laat zich daarbij bijzonder nauwkeurig afbakenen, omdat het volledige spelverkeer over twee naast elkaar liggende UDP-poorten loopt.

De twee lagen naast elkaar

Voor de meeste Project-Zomboid-servers volstaat de inbegrepen permanente bescherming samen met een nette configuratie. De Advanced DDoS Protection is het antwoord erop dat iemand het persoonlijk maakt.

Veelgemaakte fouten en oplossingen

"Mijn spelers krijgen de melding dat poort 16262 gesloten is": dat is geen aanval, maar een ontbrekende openstelling. De server heeft beide poorten nodig, 16261 UDP en 16262 UDP, en wel als UDP-regel. Een TCP-openstelling op dezelfde nummers doet niets. Controleer met ufw status verbose en een UDP-scan van buitenaf of er werkelijk twee open 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 vermelding in de lijst, een Discord-bot met statusweergave of een oud DNS-record. Bij Project Zomboid kost de wissel bovendien extra: de clients leggen de kaartgegevens lokaal onder adres en poort weg, in een map volgens het patroon 123.45.0.12_16261_... onder Zomboid/Saves. Na een wissel laadt elke speler de verkende kaart opnieuw van de server. Een adreswissel is dus tijdwinst met extra kosten, geen oplossing.

"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.

"Spelers vliegen er bij het toetreden uit, maar de server draait gewoon door": dat is bijna altijd de vergelijking, niet een aanval. Oorzaken zijn een versieverschil tussen client en server, een ontbrekende of verouderde Workshop-vermelding of een controlesom die niet past. De client noemt in de regel de mods die niet overeenkomen. Leg WorkshopItems en Mods regel voor regel naast elkaar.

"Om de paar minuten lagpieken, dan loopt het weer": dat is het gebruikelijke patroon van korte aanvallen die alleen zo lang lopen tot de spelers gedesillusioneerd stoppen. Kijk eerst naar de netwerktellers, niet naar de CPU-belasting. Blijven sar -n DEV 1 10 en de tellers voor verworpen pakketten onopvallend, dan was het geen aanval, maar belasting: te veel spelers in dezelfde cel, een dure mod of te weinig werkgeheugen voor de Java-instantie.

"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.

Kort samengevat

• Een dedicated Project-Zomboid-server heeft precies twee open poorten nodig: 16261 UDP (DefaultPort) en 16262 UDP (UDPPort). Beide staan als gescheiden directives in de servertest.ini.
• RCON loopt op 27015 TCP en staat standaard zonder wachtwoord ingevuld. Die poort hoort niet op het open internet, maar beperkt tot het eigen adres of gesloten.
• De mod-vergelijking bij het verbinden is de duurste plek: versie, controlesom, Workshop-lijst en kaartgegevens kosten rekentijd, ook bij elke afgewezen poging. DenyLoginOnOverloadedServer en de wachtrij bij het toetreden zijn daartegen de ingebouwde remmen.
• Serverwachtwoord, Open=false en MaxAccountsPerUser=1 beschermen de spellogica. Tegen een volle lijn werkt geen van deze instellingen.
• De natuurkundige grens staat vast: 1 Gbit/s is 125 megabyte per seconde en bij pakketten van 64 byte ongeveer 1,49 miljoen pakketten per seconde. Gebruikelijke aanvallen tegen gameservers liggen bij 5 tot 50 Gbit/s.
• Volumetrische aanvallen moeten in het netwerk vóór de server eindigen. Bij KernelHost zijn dat 17 Tbps mitigatiecapaciteit in het globale scrubbing-netwerk en een Arbor realtime filtering met 3,2 Tbps in Frankfurt am Main, zonder meerprijs en zonder null-routing.
• Wie permanent wordt beschoten, stuurt de filtering met de Advanced DDoS Protection zelf: dedicated beschermd IP-adres, regels per poort en protocol, wijzigingen in realtime, vanaf 50,00 € per maand.

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.