Skydda Arma-3-servern mot DDoS-attacker

Den som vill skydda en Arma-3-server mot DDoS-attacker har att göra med exakt fem UDP-portar: 2302 till 2306. En dedikerad server som på kvällen mitt i uppdraget faller bort för alla spelare samtidigt har sällan ett hårdvaruproblem. Oftast pågår en attack mot just det portblocket, och den kommer då när serverlistan visar det högsta spelarantalet. Den här artikeln visar först vad du kan säkra själv utan extra kostnader, sedan var de åtgärderna tar slut rent tekniskt, och till sist vad som måste hända i nätet framför servern.

Alla uppgifter gäller en dedikerad Arma-3-server (SteamCMD-applikation 233780) under Debian 12, Debian 13, Ubuntu 22.04 LTS eller Ubuntu 24.04 LTS. 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 konfigurationen och starta inte om servern, utan säkra först mätvärdena ur avsnittet "Logga". Efter attacken är de borta.

Varför Arma-3-servrar attackeras och när DDoS-skydd behövs

Arma 3 förenar flera egenskaper som gör en server till ett bekvämt mål. För det första publicerar servern sin adress själv: den anmäler sig via port 2304 UDP till Steams masterserver och besvarar på port 2303 UDP förfrågningar med namn, karta, spelarantal och mod-lista. Utan de båda portarna hittar ingen dig, med dem står din IP-adress i varje serverbrowser och på varje statussida som läser serverlistan.

För det andra är spelarskaran bunden till fasta tider. Life-rollspelsprojekt på Altis och Tanoa, Exile, Antistasi och King of the Hill fylls på kvällar och helger, ett avbrott klockan 20 är alltså maximalt synligt. För det tredje finns konkurrens mellan projekt, bannade spelare och interna konflikter, och en attack kostar den som utlöser den varken kunnande eller nämnvärda pengar.

Tekniskt tillkommer den avgörande punkten: Arma 3 går helt över UDP, TCP behöver spelet inte för speldriften. UDP känner ingen uppkoppling som man skulle kunna kräva, och avsändaradresser går att förfalska. En angripare behöver alltså varken gå in på din server eller tilltala den korrekt för att skapa last. Till det kommer att simuleringsslingan i en Arma-3-server i grunden går på en enda processorkärna: den som skickar tillräckligt många paket kostar just den kärnan processortid, och det oberoende av hur många kärnor maskinen i övrigt har. Vad en DDoS-attack är i detalj förklarar artikeln Vad är en DDoS-attack?.

Portarna som det faktiskt handlar om

En Arma-3-server upptar från fabrik blocket 2302 till 2306 UDP. Startparametern -port=2302 fastställer bara den första porten, de övriga fyra följer fast av den, nämligen som spelporten plus 1 till plus 4. Den som driver flera instanser på samma maskin lämnar därför minst 100 portar emellan (2302, 2402, 2502), annars tar instanserna följdportarna från varandra.

Av dessa åtta rader hör exakt tre hemma i det öppna internet: 2302, 2303 och 2304 UDP. Allt annat är administration, och öppna administrationsportar är det vanligaste undvikbara felet på Arma-3-servrar.

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

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

1. Inventering: vad lyssnar på servern?

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:2302 betyder "nåbar från hela internet", 127.0.0.1:3306 betyder "bara lokalt" och behöver ingen brandväggsregel. Vid sidan av spelet dyker på en Life-server regelbundet MariaDB, en webbserver för fraktionssidan, en TeamSpeak- eller rösttjänst och en bortglömd panel upp. Angriparens vy ger en portskanning utifrån:

nmap -Pn -sU -p 2300-2320 DIN.SERVER.IP.ADRESS
nmap -Pn -p- --min-rate 1000 DIN.SERVER.IP.ADRESS

Det första kommandot visar spelets UDP-block, det andra allt som står öppet på TCP. En Arma-3-server behöver inte en enda öppen TCP-port för speldriften.

2. Lämna bara de portar öppna som Arma 3 verkligen behöver

Tre UDP-portar utåt räcker, allt annat begränsas. Med UFW ser det ut så här, och i exakt den ordningen, så att du inte låser ute dig själv:

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH'
ufw allow 2302:2304/udp comment 'Arma 3 spel, Steam-query, Steam-master'
ufw allow from 203.0.113.10 to any port 2306 proto udp comment 'BattlEye 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. Port 2305 förblir stängd, eftersom Bohemia anger den som reserverad och för närvarande oanvänd. Viktig är raden ufw default allow outgoing: BattlEye bygger från servern upp en anslutning till arma31.battleye.com och behöver för det utgående 2344 på TCP och UDP samt 2345 på TCP. Den som spärrar utgående över hela linjen spärrar ute sitt eget anti-cheat. Kontrollera efter omställningen med en riktig anslutning att BattlEye fortfarande släpper in dina spelare. Den fullständiga anvisningen inklusive räddningsväg står i Sätt upp UFW-brandväggen utan att låsa ute dig själv.

Databasen hör under inga omständigheter hemma i det öppna nätet. Altis Life och de övriga Life-ramverken talar via tillägget extDB3 med en MySQL-databas, och inloggningsuppgifterna står i klartext i @extDB3/extdb3-conf.ini. Kontrollera i /etc/mysql/mariadb.conf.d/50-server.cnf att det står:

bind-address = 127.0.0.1

3. Ta udden av Steam-query-porten utan att åka ur serverlistan

Port 2303 UDP är den känsligaste punkten på en offentlig Arma-3-server. Den besvarar A2S-förfrågningar, alltså standardfrågan från Steams serverbrowser: A2S_INFO levererar namn, karta och spelarantal, A2S_PLAYERS spelarlistan, A2S_RULES mod- och signaturlistan. En förfrågan är ett litet UDP-paket, svaret är en multipel av det. US-CERT anger Steam-protokollets bandbreddsförstärkningsfaktor till 5,5 i varningen TA14-017A, och hos Arma 3 blir svaret särskilt stort eftersom hela mod-listan följer med.

Av det följer två saker. För det första kan din server missbrukas som förstärkare mot tredje part om en angripare skickar förfrågningar med förfalskad avsändaradress. För det andra, och viktigare för dig, kostar varje förfrågan processortid på den enda kärna som bär simuleringen. Bohemia har sedan 2015 ett ärende om saken (T83469): förfalskade UDP-paket mot spelporten eller Steam-query-porten drev CPU:n till 100 procent och frös servern, och för en lyckad attack via query-porten räckte redan 4 Mbit/s. Det är skälet till att paketfrekvensen hos Arma 3 är farligare än bandbredden.

Den första hävstången är svarsstorleken. Direktivet steamProtocolMaxDataSize i server.cfg fastställer hur många byte servern får packa in i sitt query-svar. De som driver stora mod-listor höjer det till 2048 eller mer, eftersom varningen "Query data overflow, Mods/Signatures will not be correctly received by clients" annars står i loggen. Varje höjning förstorar dock exakt det svar som en angripare förstärker. Sätt därför värdet så lågt som din mod-lista precis tillåter, och rensa bort oanvända mods ur startkommandot:

steamProtocolMaxDataSize = 2048;

Den andra hävstången är en hastighetsbegränsning per källadress som bara träffar query-porten. Spärra inte 2303 UDP över hela linjen: utan query-svar försvinner din server ur serverlistan och från varje statussida, och nya spelare hittar den inte längre. En legitim serverbrowser frågar några gånger per minut, inte hundratals gånger per sekund.

4. Ta BattlEye-RCon ur det öppna nätet

BattlEye är anti-cheat i Arma 3 och slås på i server.cfg med BattlEye = 1;. Den tillhörande fjärrstyrningen, BattlEye RCon, är ett eget UDP-protokoll och konfigureras i BattlEye/beserver_x64.cfg (filen med tillägget _x64 gäller för arma3server_x64, dagens vanliga server):

RConPassword DittAlfanumeriskaLosenord
RConPort 2306
RConIP 127.0.0.1
MaxPing 350
RestrictRCon 0

Tre punkter är avgörande. RCon-lösenordet måste vara rent alfanumeriskt, specialtecken får BattlEyes protokolltolk ur balans utan att säga till, och en RCon-åtkomst med tyst fel är en åtkomst du inte har när det gäller. RConIP fastställer på vilken adress RCon lyssnar: står det 127.0.0.1 är gränssnittet bara nåbart lokalt, och ditt RCon-verktyg når det via en SSH-vidarebefordran. Och RConPort måste ligga ovanför spelblocket, vanligt är spelporten plus 4, alltså 2306. Den som måste öppna RCon utåt släpper fram porten enbart för admin-teamets fasta adress.

En sak bör vara klar: BattlEye är ett anti-cheat, inget DDoS-skydd. Det kontrollerar spelare som är anslutna. En angripare som översvämmar din server vill inte alls gå in på den.

5. Bind headless client hårt

En headless client är en andra Arma-3-instans utan grafik som ansluter till servern som en spelare och tar över beräkningen av AI:n. Vid stora uppdrag är det den viktigaste prestandavinsten överhuvudtaget, eftersom AI:n annars ligger på samma kärna som simuleringen. Den släpps fram i server.cfg:

headlessClients[] = {"127.0.0.1"};
localClient[] = {"127.0.0.1"};

Servern tillåter utan de här posterna överhuvudtaget ingen headless-client-anslutning, det är den goda nyheten. Den dåliga: localClient[] ger den angivna adressen obegränsad bandbredd och praktiskt taget ingen latenskontroll. Ange där uteslutande 127.0.0.1 eller den fasta adressen till din egen headless-client-maskin, aldrig ett helt adressområde. Klienten startas med -client -connect=127.0.0.1 -port=2302 -password=..., och den upptar en plats ur maxPlayers. Räkna alltså in den, annars står dina spelare inför en full server.

6. Härda anslutning, signaturer och omröstningar

De här inställningarna skyddar inte din nätanslutning, men de stänger allt som kommer den reguljära anslutningsvägen: manipulerade klienter, skriptkörning i spelet och missbruk av omröstningar. Följande rader hör hemma i varje server.cfg på en offentlig server:

verifySignatures = 2;
BattlEye = 1;
kickDuplicate = 1;
allowedFilePatching = 0;
maxPlayers = 64;
disconnectTimeout = 30;
maxPing = 200;
maxDesync = 150;
maxPacketLoss = 50;
kickClientsOnSlowNetwork[] = {1, 1, 1, 1};
voteThreshold = 1.5;
voteMissionPlayers = 100;
onUnsignedData = "kick (_this select 0)";
onHackedData = "kick (_this select 0)";

verifySignatures = 2 framtvingar signaturkontroll version 2 för alla addons och är minimikravet för varje offentlig server med mods. allowedFilePatching = 0 nekar klienter som startats med -filePatching att ansluta (värdet 1 tillåter det bara för headless clients, värdet 2 för alla). kickDuplicate = 1 kastar ut den andra anslutningen med samma identitet. kickClientsOnSlowNetwork[] avgör per post om de fyra trösklarna ur maxPing, maxPacketLoss, maxDesync och disconnectTimeout bara loggas (0) eller genomdrivs (1). disconnectTimeout accepterar värden från 5 till 90 sekunder. Ett voteThreshold över 1 gör omröstningar ouppnåeliga och avslutar därmed det populäraste sättet att störa en server utan ett enda attackpaket: byte av mission via omröstning.

7. Begränsa paket- och anslutningsfrekvens per källadress

Mot små attacker och slarviga bottar hjälper en övre gräns per källadress. Eftersom Arma 3 kör ren UDP arbetar man med hashlimit, och query-porten får en betydligt snävare gräns än spelporten:

iptables -I INPUT -p udp --dport 2303 -m hashlimit --hashlimit-name a3_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name a3_game --hashlimit-mode srcip --hashlimit-above 900/sec --hashlimit-burst 1200 -j DROP
iptables -I INPUT -p udp --dport 2302:2306 -m length --length 0:27 -j DROP

Den första regeln förkastar query-förfrågningar från samma källa från och med varaktigt mer än tio per sekund, den andra spelpaket från och med varaktigt mer än 900 per sekund, den tredje UDP-paket utan användbar nyttolast. Alla tre siffrorna är startvärden, inga sanningar: en full Life-server med 80 spelare skapar betydligt fler paket än en Antistasi-runda på sex personer, och den som ställer för snävt kastar ut sina egna spelare. Mät först en vecka i normal drift.

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

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

Under UFW hör sådana regler hemma i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload. En ofta förbisedd flaskhals är dessutom kärnans anslutningsspårning: även UDP lägger upp poster där, och en query-flood från många förfalskade adresser fyller tabellen på sekunder. Blir den full förkastar servern även legitima paket, och i loggen står "nf_conntrack: table full". Läge och övre gräns visar:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. basic.cfg: bandbredd, paketstorlekar och extrafiler

Den andra konfigurationsfilen i en Arma-3-server heter basic.cfg och läses in med -cfg=, medan -config= läser in server.cfg. Den styr nätverksbeteendet och innehåller exakt ett värde som är omedelbart säkerhetsrelevant:

MaxMsgSend = 1024;
MaxSizeGuaranteed = 512;
MaxSizeNonguaranteed = 256;
MinBandwidth = 15000000;
MaxBandwidth = 100000000;
MinErrorToSend = 0.001;
MinErrorToSendNear = 0.01;
MaxCustomFileSize = 0;
class sockets { maxPacketSize = 1400; };

MaxCustomFileSize är den maximala storleken i byte för ansikts- och ljudfiler som spelare tar med sig och som servern delar ut till alla andra. Värdet 0 stänger av den utdelningen. Därmed faller en väg bort på vilken en enskild klient upptar din servers bandbredd helt utan angreppsinfrastruktur. MinBandwidth är den bandbredd som servern antar som säkrad, riktvärdet är spelarantalet gånger 256 kbit/s, alltså runt 16 Mbit/s för 64 platser. För optimistiska värden ökar last och desynkronisering, eftersom servern skapar meddelanden som den sedan förkastar. MaxMsgSend begränsar paketen per simuleringssteg och är den första hävstången mot desynkronisering, standardvärdet 128 är för lågt satt för moderna servrar.

9. Logga, så att du inte behöver gissa under attacken

Det viktigaste steget är det som nästan ingen tar i förväg: att lägga upp en jämförelsegrund så länge allt går normalt. Utan ett normalvärde kan du efter en incident inte säga om 40 000 paket per sekund var mycket eller helt enkelt lördagskväll. Med apt-get install -y vnstat sysstat går mätningen varaktigt i bakgrunden, och logFile = "arma3server.log"; i server.cfg ger dig serverns vy till det. Under en incident räcker fyra kommandon:

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

Upplysande är jämförelsen mellan portarna. Ligger lasten nästan helt på 2303 är det en query-flood, och den träffar processortiden. Fördelar den sig jämnt över 2302 till 2306 med ständigt nya avsändaradresser är det en förfalskad UDP-flood, och den träffar nätanslutningen. 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änn igen en DDoS-attack. Hur servern överhuvudtaget installeras och uppdateras rent står i Installera spelservrar med SteamCMD.

Var de här åtgärderna tar slut

Nu den del som ingen konfigurationsfil kan lösa. Alla åtgärder hittills går på din server, alltså i änden av nätanslutningen. En brandväggsregel avgör vad som händer med ett paket som redan har gått genom kabeln. Du kan förkasta det, men inte göra det oskickat.

Räkna på det en gång. En typisk spelserver hänger på 1 Gbit/s, det är 125 megabyte per sekund, och nätanslutningen är full så snart någon skickar mer. Den andra storheten är paketfrekvensen, och hos Arma 3 slår den nästan alltid till först. Vid små paket på 64 byte får runt 1,49 miljoner paket per sekund plats i en nätanslutning med 1 Gbit/s. Kärnan i ett vanligt serversystem bearbetar beroende på CPU och nätverkskort några hundratusen av dem innan den börjar förkasta, och Arma-3-simuleringen hänger dessutom på en enda processorkärna.

Raden med 4 Mbit/s är den obehagligaste. En attack behöver hos Arma 3 inte vara stor för att verka: den måste bara skicka tillräckligt många paket till rätt port. De som driver servrar upplever det som "belastningen var ju inte alls hög, ändå var allt borta". Omvänt gäller för volymetriska attacker den enkla fysiken: vid 473,4 Gbit/s är varje lokal inställning betydelselös, eftersom dina spelares paket inte kommer fram redan dessförinnan. Volymetriska attacker måste sluta i nätet framför servern.

Vad KernelHost ställer mot det

Det permanenta skyddet som ingår i varje server

KernelHosts DDoS-skydd är uppbyggt i två steg och permanent aktivt, utan att du måste slå på, beställa eller konfigurera något:

• Steg 1: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket. Volymetriska attacker rensas nära sin källa innan de når datacentret.
• Steg 2: Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main. Direkt framför servern känns protokollspecifika mönster igen och förkastas, paket för paket.

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

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

Vissa projekt attackeras inte tillfälligt utan riktat och under veckor. En Life-server med fast spelarskara och en konkurrensscen är regelfallet för det, inte undantaget. För sådana fall finns Advanced DDoS Protection från 50,00 EUR i månaden, PrePaid, utan bindningstid och utan startavgift. Skillnaden ligger inte i mer kapacitet, utan i kontrollen:

• Dedikerad skydds-IP ur Frankfurt-kärnan, som din server ställs om till inom det egna nätet. På din sida behövs ingen ombyggnad.
• Skyddsregler per port och protokoll som du hanterar själv i kundportalen: du ställer separat in vad som tillåts på 2302 UDP och vad som tillåts på 2303 UDP, och kan därmed köra query-porten betydligt snävare än spelporten.
• Ändringar träder i kraft i realtid, du kan alltså justera under en pågående attack i stället för att vänta på ett underhållsfönster.
• Skyddsprofil anpassad till respektive spel, likaså för modifierade och egna applikationer på valfria TCP- eller UDP-portar.

De båda stegen jämförda

För de flesta Arma-3-projekt räcker det inkluderade permanenta skyddet tillsammans med en ren serverkonfiguration. Advanced DDoS Protection är svaret på att någon tar det personligt.

Vanliga fel och lösningar

"Jag flyttade porten från 2302 till 2402, attacken fortsatte": Det är att vänta. Servern anmäler sin nya port själv till Steams masterserver, och serverlistan publicerar den genast igen. Ett portbyte hjälper bara mot någon som använder en gammal uppgift ur en gammal skärmbild.

"Jag spärrade 2303 helt, nu hittar ingen oss längre": Precis det händer. Utan svar på Steam-query-porten saknas posten i serverlistan, och varje statussida och varje Discord-bot visar servern som offline. Rätt är en hastighetsbegränsning per källadress, ingen spärr.

"I loggen står NetServer::SendMsg: cannot find channel": Det meddelandet kommer när servern vill skriva till en anslutning som inte längre finns. Det åtföljer som regel spelaranslutningar som bryts och prestandafall (Bohemia listar det under T83936), inte tvunget en attack. Kontrollera först om gränssnittets paketfrekvens överhuvudtaget är anmärkningsvärd.

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

"BattlEye kickar alla spelare sedan den nya brandväggen": Servern når inte längre arma31.battleye.com. De utgående portarna 2344 på TCP och UDP samt 2345 på TCP måste förbli öppna, annars faller serverns anti-cheat-anslutning bort.

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

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

Kort sammanfattat

• En Arma-3-server behöver utåt exakt tre UDP-portar: 2302 för spel och röst, 2303 för Steam-query och 2304 för anmälan till Steams masterserver. TCP behöver spelet inte.
• Port 2306 UDP bär BattlEye och RCon-gränssnittet och hör uteslutande hemma på dina egna adminadresser, satt via RConPort och RConIP i beserver_x64.cfg.
• Steam-query-porten 2303 är den känsligaste punkten: Steam-protokollet har enligt US-CERT TA14-017A en förstärkningsfaktor på 5,5, och varje förfrågan kostar processortid på den kärna som bär simuleringen. Begränsa i stället för att spärra.
• Håll steamProtocolMaxDataSize så lågt som mod-listan tillåter, och sätt MaxCustomFileSize = 0; i basic.cfg: båda förminskar den datamängd som din server levererar ut ombedd.
• Hos Arma 3 avgör paketfrekvensen, inte bandbredden. Bohemia dokumenterar sedan 2015 under T83469 att redan 4 Mbit/s mot query-porten räckte för att frysa en server.
• Lokala åtgärder slutar vid nätanslutningen. Från 1 Gbit/s attackvolym eller några hundratusen paket per sekund avgör uteslutande filtreringen i nätet framför servern.
• Hos KernelHost ingår det permanenta skyddet i två steg i varje serverpaket utan extra kostnad och är aktivt från leveransen, utan nullrouting. Advanced DDoS Protection kompletterar det från 50,00 EUR i månaden med en dedikerad skydds-IP och regler per port som du hanterar själv.

Går ditt projekt redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå något anmärkningsvärt öppnar du ett supportärende, så att filterreglerna för din IP-adress justeras. Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883.