Skydda Project Zomboid-servern mot DDoS-attacker

Den som vill skydda sin Project Zomboid-server mot DDoS-attacker måste först veta vad en angripare över huvud taget skjuter på. En dedikerad server upptar exakt två UDP-portar, 16261 och 16262, och båda måste stå öppna i nätet, för annars kan ingen ansluta. Den här artikeln går fram i den ordning som räknas i skarpt läge: först det du kan göra själv under de närmaste tio minuterna utan extra kostnad, därefter stället där de åtgärderna tar slut rent tekniskt, och till sist det som måste hända i nätet framför.

Alla uppgifter gäller den dedikerade servern (Steam-app 380870) under Debian 12, Debian 13, Ubuntu 22.04 LTS eller Ubuntu 24.04 LTS, för build 41 lika väl som för build 42. Konfigurationsfilen heter servertest.ini och ligger under ~/Zomboid/Server/, världsdata ligger under ~/Zomboid/Saves/Multiplayer/. Kommandona är skrivna för root, som vanlig användare sätter du sudo framför.

Om attacken pågår just nu: ändra ingenting i servertest.ini nu och starta inte om servern. Säkra först mätvärdena (avsnitt 9), efter attacken är de borta. En omstart kostar dessutom den tid som servern behöver för att läsa in världen, och det är precis den tiden angriparen vill ta ifrån dig.

Varför Project Zomboid-servrar blir mål för DDoS-attacker

Project Zomboid är ett spel med permanent död och en värld som löper vidare i månader. Ett avbrott mitt i en farlig situation kostar här mer än i nästan något annat genre: karaktären är borta, och världen minns det. Just det gör ett avbrott till ett vapen. En attack klockan 20 träffar en fast community, och den träffar den på det ställe där den har mest att förlora.

Därtill kommer att själva attacken inte kostar något och inte kräver någon kunskap. Bokade attacktjänster, i kretsarna kallade booter eller stresser, riktas med några få klick mot en IP-adress och en port, och hos Project Zomboid är målet alltid detsamma: 16261 UDP. Den som ligger i tvist med en bannlyst spelare eller driver en konkurrerande community har därmed ett verktyg i handen som varken kräver kunskap eller några nämnvärda pengar.

Därtill kommer att en spelserver måste publicera sin adress. Står Public=true i servertest.ini dyker servern upp i spelets serverlista, och en server med Steam-anslutning är ändå synlig i Steams serverlista. Frågan är alltså aldrig om en angripare hittar din IP-adress, utan bara vad som händer när han skjuter på den.

Tekniskt kommer den obehagligaste delen till sist: hela speltrafiken går över UDP. UDP känner inte till någon uppkoppling som man skulle kunna kräva, varje paket står för sig, och avsändaradressen går att förfalska. En angripare måste alltså varken gå in på din server eller tilltala den korrekt för att skapa last. Vad en DDoS-attack är i detalj förklaras i artikeln Vad är en DDoS-attack?.

Vilka portar en Project Zomboid-server verkligen behöver

En dedikerad Project Zomboid-server behöver exakt två öppna portar: 16261 UDP och 16262 UDP. Spelets officiella portlista nämner ingen tredje. I servertest.ini står de som två skilda direktiv, den andra porten följer inte automatiskt av den första:

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

Arbetsfördelningen är entydig. 16261 UDP bär speltrafiken och uppkopplingen och besvarar serverlistans förfrågningar. 16262 UDP är porten för klienternas direktanslutning. Saknas den första hittar ingen servern, saknas den andra ser dina spelare posten och kommer ändå inte in. Just därifrån kommer spelets mest kända felmeddelande, att port 16262 skulle vara stängd.

Två punkter som regelbundet ställer till besvär. För det första: varje serverinstans behöver två lediga UDP-portar. Den som driver en andra värld på samma maskin tilldelar ett andra par för den, till exempel 16274 och 16275, och skriver in båda värdena i den andra instansens servertest.ini. För det andra: SteamPort1 och SteamPort2 står med 8766 och 8767 i konfigurationsfilen, men hör till Steam-anslutningen och inte till speltrafiken. Öppna dem bara om din server inte dyker upp i Steam-listan utan dem, inte för säkerhets skull.

Vad du kan göra själv innan du lägger ut pengar

Det här avsnittet är det längsta, och det är avsiktligt. En rent konfigurerad server klarar små och medelstora attacker av egen kraft, oavsett hos vem den står. Den tar ingen volymetrisk attack ifrån dig, men ser till att billiga attacker förblir verkningslösa och att du i skarpt läge har siffror i stället för gissningar.

1. Inventering: vad lyssnar egentligen

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:16261 och [::]:16261 betyder "nåbar från hela internet", 127.0.0.1:27015 betyder "bara lokalt" och behöver ingen öppning. Stäm av resultatet mot din konfiguration i stället för att förlita dig på standardvärden:

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

Angriparens vy får du med en portskanning utifrån. Eftersom Project Zomboid uteslutande använder UDP krävs UDP-skanningen för det, en ren TCP-skanning visar inte spelporten alls:

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

2. Lämna bara 16261 och 16262 öppna

Två öppningar utåt räcker, allt annat begränsas eller publiceras inte alls. Med UFW ser det ut så här, och då i exakt den ordningen så att du inte låser ute dig själv:

ufw allow 22/tcp comment "SSH"
ufw allow 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid direktanslutning"
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

Ersätt 203.0.113.10 med din egen adress. Ordningen vid aktiveringen avgör om du låser ute dig själv. Den står tillsammans med vägen tillbaka i artikeln Sätta upp UFW-brandväggen utan att låsa ute dig själv. Skulle det ändå hända: vid KVM-rootservrar och dedikerade servrar från KernelHost når du systemet via VNC-konsolen i kundportalen, som arbetar oberoende av gästsystemets nätverk.

Ett ord om databaser och extratjänster: Project Zomboid behöver inga. Det som vid sidan av spelet lyssnar på 0.0.0.0 kommer från en tidigare installation eller från en förvaltningspanel och hör antingen hemma bundet till 127.0.0.1 eller avstängt.

3. Ta RCON på port 27015 ur det öppna nätet

RCON är serverns fjärrstyrning och ligger hos Project Zomboid på 27015 TCP. I den levererade servertest.ini står RCONPassword= utan värde. Den som använder RCON sätter ett långt slumpmässigt lösenord, för protokollet överför okrypterat, och en nåbar RCON-port med svagt lösenord lämnar över servern fullständigt, utan att ett enda paket attacktrafik behövs för det.

Den säkra vägen är att inte öppna porten utåt alls och att nå den via en SSH-portvidarebefordran. Därefter talar du lokalt med 127.0.0.1:27015:

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

Den som inte behöver RCON lämnar lösenordsfältet tomt och porten stängd. En tjänst som inte är nåbar går varken att prova sig fram mot eller att översvämma.

4. Begränsa paketfrekvensen per källadress

Mot små attacker och slarviga bottar hjälper ett tak per källadress. Eftersom båda spelportarna ligger bredvid varandra räcker en regel för intervallet:

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

Regeln kasserar UDP-paket så snart samma källadress varaktigt skickar mer än 400 paket per sekund. Värdet är ett startvärde, ingen sanning: en server med 30 spelare i samma stad skapar betydligt mer trafik än en med fyra spelare i olika hörn av kartan, och den som ställer in för snävt kastar ut sina egna spelare. Mät först en vecka i normal drift, sätt sedan gränsen till ett mångdubbelt av toppvärdet.

Två anmärkningar till det. Rena iptables-regler är borta efter en omstart, under Debian och Ubuntu säkrar man dem så här:

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

Och under UFW hör sådana regler hemma i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload. Kontrollera med träffräknarna ur iptables -L INPUT -n -v om regeln över huvud taget nås. Stannar räknarna på noll står den på fel ställe.

5. Avlasta anslutningsspårningen

En ofta förbisedd flaskhals sitter i kärnan. Anslutningsspårningen lägger upp en post per källadress och port även för UDP, och en flod med förfalskade avsändare fyller den tabellen på sekunder. Blir den full kasserar servern även legitima paket, och i systemloggen står "nf_conntrack: table full". Läge och tak visar:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Speltrafiken hos Project Zomboid behöver ingen tillståndsspårning, eftersom UDP inte har något tillstånd. Du kan därför hålla de båda spelportarna utanför tabellen:

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

Det avlastar kärnan märkbart. Viktigt: regeln passar bara så länge servern får paketen direkt. Den som driver en adressöversättning framför, till exempel i en containeruppsättning med portvidarekoppling, får inte sätta den, eftersom riktningen tillbaka då inte längre kan tilldelas.

6. Säkra anslutningen och platserna

Följande rader kostar ingenting och verkar mot allt som kommer via den reguljära anslutningsvägen:

Password=ETT-LÅNGT-SLUMPMÄSSIGT-LÖSENORD
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password är det gemensamma serverlösenordet och skilt från den enskilda spelarens konto. Open=false betyder att bara konton som en administratör har lagt upp i förväg får ansluta, det är spelets vitlista. MaxAccountsPerUser begränsar hur många konton en enskild Steam-användare får lägga upp på din server, standardvärdet 0 betyder obegränsat. MaxPlayers står som standard på 32, och däröver varnar dokumentationen uttryckligen för dålig efterladdning av kartan och desynkronisering.

PingLimit är fällan på det här stället. Direktivet kastar ut spelare från en latens i millisekunder och står som standard på 0, alltså av. Under en attack stiger latensen hos dina egna spelare först, ett snävt värde kickar alltså precis de personer du vill behålla. Lämna gränsen avstängd eller sätt den generöst.

Och en sak måste stå klar: en vitlista skyddar din spellogik, inte din uppkoppling. En angripare som översvämmar din server vill inte ansluta alls. Hans paket avvisas, men de har ändå kommit fram, och det är precis poängen.

7. Modavstämningen vid anslutning är din servers dyraste sekund

Project Zomboid prövar mer än ett lösenord vid anslutningen. Serverns modlista står i två rader i servertest.ini: WorkshopItems innehåller de numeriska Workshop-ID:na, Mods moddarnas ladd-ID:n, båda åtskilda med semikolon. Vid anslutningen stämmer klienten av den listan, hämtar saknat Workshop-innehåll automatiskt via Steam och får först därefter världsdata strömmade till sig. Dessutom jämför servern vid DoLuaChecksum=true kontrollsummorna för spelfilerna och kastar ut klienter vars filer inte passar till dess egna.

För en angripare är just det intressant, för arbetet uppstår före det egentliga deltagandet i spelet. Varje anslutningsförsök kostar servern beräkningstid för version, kontrollsumma, modlista och kartdata, även det försök som avvisas till slut. En lång modlista gör varje sådant försök dyrare. En anslutningsflod är därför verksammare på en kraftigt modifierad server än på en oförändrad, och den behöver för det en bråkdel av bandbredden i en volymetrisk attack. Spelet har två inbyggda bromsar mot det:

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer avvisar nya inloggningar så länge servern är överbelastad, i stället för att riva med sig den pågående omgången. LoginQueueEnabled ställer anslutande i en kö i stället för att beta av dem samtidigt, och LoginQueueConnectTimeout fastställer hur länge en anslutning får ta, standardvärde 60 sekunder, tillåtet är 20 till 1200.

En detalj hör till, eftersom den ofta löses fel: på Linux-servrar finns ett dokumenterat fel där DoLuaChecksum slår falskt larm och inte släpper in spelare. Operatörer stänger därför av kontrollen. Det är begripligt, men tar bort en kontroll som håller klienter med förändrade spelfiler borta. Den som måste stänga av den bör sätta serverlösenord, vitlista och kontogräns desto strängare.

8. Serverlistan, UPnP och den egna adressen

Här lönar sig ärlighet i stället för önsketänkande: din IP-adress går inte att hålla hemlig. Public=true visar servern i spelets serverlista, och en server med Steam-anslutning är enligt dokumentationen ändå synlig i Steams serverlista. Public=false tar alltså ifrån dig synligheten för nya spelare utan att göra dig osynlig.

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

UPnP står som standard på true och låter servern själv försöka sätta upp en portöppning vid en internetgateway. På en hyrd server finns ingen sådan gateway, försöket går ut i tomma intet och hör hemma avstängt. server_browser_announced_ip förblir tomt, utom när din server har flera adresser och riktat ska dyka upp under en av dem. Just det fältet behöver du igen senare, när du ställer om till en dedikerad skydds-IP.

Två vanor hjälper mer än någon inställning. Publicera aldrig den råa IP-adressen själv, alltså varken i Discord-kanalen eller på projektsidan, och ge dina spelare ett värdnamn. Klassikern vid ett adressbyte är gamla DNS-poster: en bortglömd A-post till den tidigare adressen gör varje byte verkningslöst.

9. Mät så länge allt går normalt

Det viktigaste steget är det som nästan ingen gör i förväg: att lägga upp en jämförelsegrund så länge allt är lugnt. Utan normalvärde kan du efter en händelse inte säga om 40 000 paket per sekund var mycket eller helt enkelt lördagskväll. Med apt-get install -y vnstat sysstat löper mätningen varaktigt med. Under en händelse räcker fyra kommandon:

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 två första visar gränssnittets paketfrekvens och räknare för kasserade paket, det tredje ett kort stickprov av trafiken, det fjärde serverns meddelanden, förutsatt att den körs som systemd-tjänst (anpassa tjänstens namn). För tcpdump gäller: begränsa alltid med -c, en inspelning under full last belastar en redan överbelastad server ytterligare. Hur du tolkar värdena står i Känna igen en DDoS-attack på servern.

Var de här åtgärderna tar slut: bandbredd och paketfrekvens

Nu den del som ingen konfigurationsfil kan lösa. Alla åtgärder hittills körs på din server, alltså i änden av ledningen. En brandväggsregel avgör om ett paket som redan har gått över kabeln. Du kan kassera det, men inte göra det osänt.

Räkna med en gång. En typisk spelserver hänger på 1 Gbit/s, det är 125 megabyte per sekund, och uppkopplingen är full så fort någon skickar mer. Den andra storheten är paketfrekvensen, och den slår ofta till tidigare än bandbredden: vid små paket på 64 byte ryms runt 1,49 miljoner paket per sekund i 1 Gbit/s, medan en vanlig serverkärna beroende på processor och nätverkskort bara bearbetar några hundratusen av dem innan den börjar kassera. En attack som inte ens fyller en tredjedel av din uppkoppling kan alltså lamslå din server. Operatörer upplever det som "belastningen var ju inte ens hög, ändå var allt borta".

Vanliga attacker mot spelserver-communityer ligger mellan 5 och 50 Gbit/s, alltså på fem till femtio gånger en normal uppkoppling. För det finns ingen lokal inställning. Volymetriska attacker måste ta slut i nätet framför servern.

Vad KernelHost ställer emot DDoS-attacker mot spelservrar

Det permanenta skyddet som ingår på varje server

DDoS-skyddet från KernelHost är uppbyggt i två steg och permanent aktivt, utan att du behöver 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 kasseras, paket för paket.

Två egenskaper är avgörande. Skyddet löper permanent och måste inte först reagera på en attack, det finns alltså inga minuter i början där servern är borta. Och ingen null-routning används: din IP-adress stannar i nätet, bara de skadliga paketen kasseras. Den som tar bort IP-adressen ur nätet åstadkommer för dig samma resultat som angriparen. Vilka spel och protokoll som täcks listas i DDoS-skydd för spelservrar i realtid.

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

Vissa projekt angrips inte då och då, utan riktat och under veckor. För det finns Advanced DDoS Protection från 50,00 EUR i månaden, PrePaid, utan bindningstid och utan uppläggningsavgift. Skillnaden ligger inte i mer kapacitet utan i kontrollen:

• Dedikerad skydds-IP ur Frankfurt-kärnan, som din server ställs om till i vårt eget nät. På din sida behövs ingen ombyggnad, den nya adressen skriver du bara in där dina spelare hittar servern.
• Skyddsregler per port och protokoll som du förvaltar själv i kundportalen: du fastställer vad som är tillåtet på 16261 och 16262 UDP, och allt annat förblir stängt, utan att skriva ett ärende för det.
• Ändringar griper i realtid, du kan alltså justera under en pågående attack.
• Passande skyddsprofil. För gängse spel finns färdiga profiler, för modifierade och egna applikationer sätter du reglerna per port och protokoll själv. Project Zomboid går därvid att avgränsa särskilt noggrant, eftersom hela speltrafiken går över två närliggande UDP-portar.

De båda stegen i jämförelse

För de flesta Project Zomboid-servrar räcker det inkluderade permanenta skyddet tillsammans med en ren konfiguration. Advanced DDoS Protection är svaret på att någon tar det personligt.

Vanliga fel och lösningar

"Mina spelare får meddelandet att port 16262 är stängd": det är ingen attack utan en saknad öppning. Servern behöver båda portarna, 16261 UDP och 16262 UDP, och då som UDP-regel. En TCP-öppning på samma nummer gör ingenting. Kontrollera med ufw status verbose och en UDP-skanning utifrån om båda verkligen är öppna.

"Jag bytte IP-adress och var offline igen två timmar senare": angriparen har den nya adressen ur samma källa som den gamla, oftast posten i serverlistan, en Discord-bot med statusvisning eller en gammal DNS-post. Hos Project Zomboid kostar bytet dessutom extra: klienterna lägger kartdata lokalt under adress och port, i en mapp enligt mönstret 123.45.0.12_16261_... under Zomboid/Saves. Efter ett byte laddar varje spelare den utforskade kartan på nytt från servern. Ett adressbyte är alltså tidsvinst med extra kostnader, ingen lösning.

"Mina iptables-regler griper 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 uppkoppling som redan är full. Kontrollera med iptables -L INPUT -n -v om träffräknarna stiger.

"Spelare åker ut vid anslutningen, men servern löper normalt vidare": det är nästan alltid avstämningen och inte en attack. Orsakerna är en versionsskillnad mellan klient och server, en saknad eller föråldrad Workshop-post eller en kontrollsumma som inte stämmer. Klienten anger som regel de moddar som inte överensstämmer. Stäm av WorkshopItems och Mods rad för rad.

"Lagg-spikar med några minuters mellanrum, sedan löper det igen": det är det vanliga mönstret för korta attacker, som bara pågår tills spelarna ger upp av irritation. Titta först på nätverksräknarna, inte på processorlasten. Förblir sar -n DEV 1 10 och räknarna för kasserade paket oanmärkningsvärda var det ingen attack utan last: för många spelare i samma cell, en dyr modd eller för lite arbetsminne för Java-instansen.

"Min tidigare leverantör spärrade min IP-adress": det är null-routning. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i ytterligare timmar efteråt. Fråga vid tveksamhet efter om det filtreras eller null-routas. Svaret avgör mer om din tillgänglighet än någon hårdvaruuppgift.

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

Kort sammanfattat

• En dedikerad Project Zomboid-server behöver exakt två öppna portar: 16261 UDP (DefaultPort) och 16262 UDP (UDPPort). Båda står som skilda direktiv i servertest.ini.
• RCON löper på 27015 TCP och är som standard inskrivet utan lösenord. Porten hör inte hemma i det öppna internet, utan begränsad till den egna adressen eller stängd.
• Modavstämningen vid anslutning är det dyraste stället: version, kontrollsumma, Workshop-lista och kartdata kostar beräkningstid, även vid varje avvisat försök. DenyLoginOnOverloadedServer och inloggningskön är de inbyggda bromsarna mot det.
• Serverlösenord, Open=false och MaxAccountsPerUser=1 skyddar spellogiken. Mot en mättad uppkoppling verkar ingen av de inställningarna.
• Den fysiska gränsen ligger fast: 1 Gbit/s är 125 megabyte per sekund och vid 64 byte stora paket runt 1,49 miljoner paket per sekund. Vanliga attacker mot spelservrar ligger på 5 till 50 Gbit/s.
• Volymetriska attacker måste ta slut i nätet framför servern. Hos KernelHost är det 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket och en Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main, utan extra kostnad och utan null-routning.
• Den som beskjuts varaktigt styr filtreringen själv med Advanced DDoS Protection: dedikerad skydds-IP, regler per port och protokoll, ändringar i realtid, från 50,00 EUR i månaden.

Körs din server redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå något avvikande, öppna 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.