Arma-3-server beschermen tegen DDoS-aanvallen

Wie een Arma-3-server tegen DDoS-aanvallen wil beschermen, heeft met precies vijf UDP-poorten te maken: 2302 tot en met 2306. Een dedicated server die 's avonds midden in de operatie voor alle spelers tegelijk wegvalt, heeft zelden een hardwareprobleem. Meestal loopt er een aanval op precies dit poortblok, en wel op het moment dat de serverlijst het hoogste aantal spelers toont. Dit artikel laat eerst zien wat u zonder extra kosten zelf kunt afschermen, daarna waar die maatregelen technisch ophouden, en tot slot wat er in het netwerk vóór de server moet gebeuren.

Alle gegevens gaan uit van een dedicated Arma-3-server (SteamCMD-toepassing 233780) onder Debian 12, Debian 13, Ubuntu 22.04 LTS of Ubuntu 24.04 LTS. 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 configuratie en start de server niet opnieuw op, maar leg eerst de meetwaarden uit de paragraaf "Vastleggen" vast. Na de aanval zijn ze verdwenen.

Waarom Arma-3-servers worden aangevallen en wanneer DDoS-bescherming nodig wordt

Arma 3 verenigt meerdere eigenschappen die een server tot een gemakkelijk doelwit maken. Ten eerste publiceert de server zijn adres uit zichzelf: hij meldt zich via poort 2304 UDP aan bij de Steam-masterserver en beantwoordt op poort 2303 UDP opvragingen met naam, kaart, aantal spelers en modlijst. Zonder deze twee poorten vindt niemand u, met deze twee poorten staat uw IP-adres in elke serverbrowser en op elke statuspagina die de serverbrowser uitleest.

Ten tweede is de spelersgroep aan vaste tijden gebonden. Life-rollenspelprojecten op Altis en Tanoa, Exile, Antistasi en King of the Hill lopen 's avonds en in het weekend vol, een uitval om 20 uur is dus maximaal zichtbaar. Ten derde is er concurrentie tussen projecten, zijn er verbannen spelers en interne conflicten, en kost een aanval de veroorzaker kunde noch noemenswaardig geld.

Technisch komt daar het doorslaggevende punt bij: Arma 3 loopt volledig over UDP, TCP heeft het spel voor het spelbedrijf niet nodig. UDP kent geen verbindingsopbouw die u zou kunnen eisen, en afzenderadressen laten zich vervalsen. Een aanvaller hoeft uw server dus niet te betreden en hoeft hem ook niet correct aan te spreken om belasting te veroorzaken. Daarbij komt dat de simulatielus van een Arma-3-server in de kern op één rekenkern draait: wie genoeg pakketten stuurt, kost die ene kern rekentijd, en wel ongeacht hoeveel kernen de machine verder heeft. Wat een DDoS-aanval in detail is, legt het artikel Wat is een DDoS-aanval? uit.

De poorten waar het werkelijk om gaat

Een Arma-3-server bezet standaard het blok 2302 tot en met 2306 UDP. De startparameter -port=2302 legt alleen de eerste poort vast, de overige vier volgen daar vast uit, namelijk als spelpoort plus 1 tot en met plus 4. Wie meerdere instanties op dezelfde machine draait, houdt daarom minstens 100 poorten afstand (2302, 2402, 2502), anders pakken de instanties elkaar de volgpoorten af.

Van deze acht regels horen er precies drie op het open internet: 2302, 2303 en 2304 UDP. Al het andere is beheer, en open beheerpoorten zijn de meest gemaakte vermijdbare fout op Arma-3-servers.

Wat u zelf kunt doen voordat u geld uitgeeft

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

1. Inventarisatie: wat luistert er op de server?

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:2302 betekent "vanaf het hele internet bereikbaar", 127.0.0.1:3306 betekent "alleen lokaal" en heeft geen firewallregel nodig. Naast het spel duiken op een Life-server regelmatig MariaDB, een webserver voor de fractiepagina, een TeamSpeak- of voicedienst en een vergeten panel op. Het beeld van de aanvaller levert een poortscan van buitenaf:

nmap -Pn -sU -p 2300-2320 UW.SERVER.IP.ADRES
nmap -Pn -p- --min-rate 1000 UW.SERVER.IP.ADRES

Het eerste commando toont het UDP-blok van het spel, het tweede alles wat op TCP open staat. Een Arma-3-server heeft voor het spelbedrijf geen enkele open TCP-poort nodig.

2. Alleen de poorten openlaten die Arma 3 werkelijk nodig heeft

Drie UDP-poorten naar buiten volstaan, al het andere wordt beperkt. Met UFW ziet dat er zo uit, en wel precies in deze volgorde, zodat u zichzelf niet buitensluit:

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

Vervang 203.0.113.10 door uw eigen adres. Poort 2305 blijft dicht, omdat Bohemia hem als gereserveerd en momenteel ongebruikt vermeldt. Belangrijk is de regel ufw default allow outgoing: BattlEye bouwt vanaf de server een verbinding naar arma31.battleye.com op en heeft daarvoor uitgaand 2344 op TCP en UDP nodig, plus 2345 op TCP. Wie uitgaand alles dichtzet, sluit zijn eigen anti-cheat buiten. Controleer na de omzetting met een echte deelname dat BattlEye uw spelers nog steeds doorlaat. De volledige handleiding inclusief reddingsweg staat in UFW-firewall instellen zonder uzelf buiten te sluiten.

De database hoort in geen geval op het open internet. Altis Life en de andere Life-frameworks praten via de uitbreiding extDB3 met een MySQL-database, en de toegangsgegevens staan leesbaar in @extDB3/extdb3-conf.ini. Controleer in /etc/mysql/mariadb.conf.d/50-server.cnf of daar staat:

bind-address = 127.0.0.1

3. De Steam-querypoort afzwakken zonder uit de serverbrowser te vallen

Poort 2303 UDP is het gevoeligste punt van een openbare Arma-3-server. Hij beantwoordt A2S-opvragingen, dus de standaardopvraging van de Steam-serverbrowser: A2S_INFO levert naam, kaart en aantal spelers, A2S_PLAYERS de spelerslijst, A2S_RULES de mod- en handtekeninglijst. Een opvraging is een klein UDP-pakket, het antwoord is daar een veelvoud van. US-CERT voert het Steam-protocol in alert TA14-017A met een bandbreedteversterkingsfactor van 5,5, en bij Arma 3 valt het antwoord bijzonder groot uit, omdat de volledige modlijst wordt meegestuurd.

Daaruit volgen twee dingen. Ten eerste kan uw server als versterker tegen derden worden misbruikt wanneer een aanvaller opvragingen met een vervalst afzenderadres stuurt. Ten tweede, en voor u belangrijker, kost elke opvraging rekentijd op de ene kern die de simulatie draagt. Bohemia houdt daar sinds 2015 een ticket over bij (T83469): vervalste UDP-pakketten naar de spelpoort of de Steam-querypoort dreven de CPU naar 100 procent en bevroren de server, en voor een geslaagde aanval via de querypoort volstond al 4 Mbit/s. Dat is de reden waarom bij Arma 3 de pakketsnelheid gevaarlijker is dan de bandbreedte.

De eerste hefboom is de antwoordgrootte. De directive steamProtocolMaxDataSize in de server.cfg legt vast hoeveel bytes de server in zijn queryantwoord mag stoppen. Beheerders van grote modlijsten verhogen hem naar 2048 of meer, omdat anders de waarschuwing "Query data overflow, Mods/Signatures will not be correctly received by clients" in het logboek staat. Elke verhoging vergroot echter precies het antwoord dat een aanvaller versterkt. Zet de waarde daarom zo laag als uw modlijst nog net toelaat, en haal ongebruikte mods uit het startcommando:

steamProtocolMaxDataSize = 2048;

De tweede hefboom is een ratelimiet per bronadres die alleen de querypoort raakt. Sluit 2303 UDP niet zonder meer af: zonder queryantwoord verdwijnt uw server uit de serverbrowser en van elke statuspagina, en nieuwe spelers vinden hem niet meer. Een legitieme serverbrowser vraagt enkele keren per minuut op, niet honderden keren per seconde.

4. BattlEye-RCon van het open internet afhalen

BattlEye is de anti-cheat van Arma 3 en wordt in de server.cfg met BattlEye = 1; ingeschakeld. De bijbehorende afstandsbediening, BattlEye RCon, is een eigen UDP-protocol en wordt in BattlEye/beserver_x64.cfg geconfigureerd (het bestand met de toevoeging _x64 geldt voor arma3server_x64, de tegenwoordig gangbare server):

RConPassword UwAlfanumeriekeWachtwoord
RConPort 2306
RConIP 127.0.0.1
MaxPing 350
RestrictRCon 0

Drie punten zijn doorslaggevend. Het RCon-wachtwoord moet puur alfanumeriek zijn: speciale tekens brengen de protocolparser van BattlEye stilletjes van de wijs, en een RCon-toegang met een stille fout is er een die u in geval van nood niet hebt. RConIP legt vast op welk adres RCon luistert: staat daar 127.0.0.1, dan is de interface alleen lokaal bereikbaar en bereikt uw RCon-gereedschap haar via een SSH-tunnel. En RConPort moet boven het spelblok liggen, gebruikelijk is de spelpoort plus 4, dus 2306. Wie RCon naar buiten moet openen, geeft de poort uitsluitend vrij voor het vaste adres van zijn adminteam.

Eén ding moet daarbij duidelijk zijn: BattlEye is een anti-cheat, geen DDoS-bescherming. Het controleert spelers die verbonden zijn. Een aanvaller die uw server overspoelt, wil helemaal niet meedoen.

5. De headless client vast binden

Een headless client is een tweede Arma-3-instantie zonder grafische weergave, die zich als een speler met de server verbindt en hem de berekening van de AI uit handen neemt. Dat is bij grote missies de belangrijkste prestatiewinst die er is, omdat de AI anders op dezelfde kern ligt als de simulatie. Vrijgegeven wordt hij in de server.cfg:

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

De server laat zonder deze regels geen enkele headless-clientverbinding toe, dat is het goede nieuws. Het slechte: localClient[] gunt het ingevoerde adres onbeperkte bandbreedte en praktisch geen latentiecontrole. Vul daar uitsluitend 127.0.0.1 in of het vaste adres van uw eigen headless-clientserver, nooit een heel adresbereik. Gestart wordt de client met -client -connect=127.0.0.1 -port=2302 -password=..., en hij bezet een slot uit maxPlayers. Reken daar dus op, anders staan uw spelers voor een volle server.

6. Deelname, handtekeningen en stemmingen harden

Deze instellingen beschermen uw lijn niet, maar ze sluiten alles af wat via de reguliere weg naar binnen komt: gemanipuleerde clients, scriptuitvoering in het spel en misbruik van stemmingen. De volgende regels horen in elke server.cfg van een openbare 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 dwingt de handtekeningcontrole versie 2 af voor alle addons en is de minimumeis voor elke openbare server met mods. allowedFilePatching = 0 weigert clients die met -filePatching zijn gestart de toegang (waarde 1 staat het alleen headless clients toe, waarde 2 iedereen). kickDuplicate = 1 gooit de tweede verbinding met dezelfde identificatie eruit. kickClientsOnSlowNetwork[] bepaalt per vermelding of de vier drempels uit maxPing, maxPacketLoss, maxDesync en disconnectTimeout alleen worden vastgelegd (0) of ook worden afgedwongen (1). disconnectTimeout accepteert waarden van 5 tot 90 seconden. Een voteThreshold boven 1 maakt stemmingen onhaalbaar en beëindigt daarmee de populairste manier om een server te verstoren zonder één enkel aanvalspakket: de missiewissel per stemming.

7. Pakket- en verbindingssnelheden per bronadres begrenzen

Tegen kleine aanvallen en slordige bots helpt een bovengrens per bronadres. Omdat Arma 3 puur UDP gebruikt, werkt men met hashlimit, en de querypoort krijgt een duidelijk strakkere grens dan de spelpoort:

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

De eerste regel verwerpt queryopvragingen uit dezelfde bron zodra er blijvend meer dan tien per seconde komen, de tweede spelpakketten vanaf blijvend meer dan 900 per seconde, de derde UDP-pakketten zonder bruikbare nuttige lading. Alle drie de getallen zijn startwaarden, geen waarheden: een volle Life-server met 80 spelers produceert duidelijk meer pakketten dan een Antistasi-ronde met zes man, en wie te krap instelt, gooit zijn eigen spelers eruit. Meet daarom eerst een week lang in normaal bedrijf.

Twee opmerkingen daarbij. 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. Een vaak over het hoofd gezien knelpunt is bovendien de verbindingsregistratie van de kernel: ook UDP legt daar records aan, en een queryflood uit veel vervalste adressen vult de tabel in seconden. Loopt die 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

8. basic.cfg: bandbreedte, pakketgroottes en extra bestanden

Het tweede configuratiebestand van een Arma-3-server heet basic.cfg en wordt met -cfg= geladen, terwijl -config= de server.cfg laadt. Het stuurt het netwerkgedrag aan en bevat precies één waarde die rechtstreeks met veiligheid te maken heeft:

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

MaxCustomFileSize is de maximale grootte in bytes voor gezichts- en geluidsbestanden die spelers meebrengen en die de server aan alle anderen uitdeelt. De waarde 0 schakelt die verspreiding uit. Daarmee vervalt een weg waarlangs één enkele client de bandbreedte van uw server bezet zonder ook maar enige aanvalsinfrastructuur. MinBandwidth is de bandbreedte die de server als gegarandeerd aanneemt, richtwaarde is het aantal spelers maal 256 kbit/s, dus ongeveer 16 Mbit/s voor 64 slots. Te optimistische waarden verhogen belasting en desynchronisatie, omdat de server berichten aanmaakt die hij daarna verwerpt. MaxMsgSend begrenst de pakketten per simulatiestap en is de eerste hefboom tegen desynchronisatie, de standaardwaarde 128 is voor moderne servers te laag gekozen.

9. Vastleggen, 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. Met apt-get install -y vnstat sysstat loopt de meting permanent mee, en logFile = "arma3server.log"; in de server.cfg geeft u daarbij het beeld van de server zelf. 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 portrange 2302-2306 -c 200 -q

Veelzeggend is de vergelijking van de poorten. Ligt de belasting bijna volledig op 2303, dan is het een queryflood, en die raakt de rekentijd. Verdeelt zij zich gelijkmatig over 2302 tot en met 2306 met steeds nieuwe afzenderadressen, dan is het een vervalste UDP-flood, en die raakt de lijn. 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 herkennen. Hoe de server om te beginnen netjes wordt geïnstalleerd en bijgewerkt, staat in Gameserver installeren met SteamCMD.

Waar deze maatregelen ophouden

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

Rekent u even mee. Een 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 bij Arma 3 slaat die bijna altijd het eerst toe. Bij kleine pakketten van 64 byte passen er in een lijn van 1 Gbit/s ongeveer 1,49 miljoen pakketten per seconde. Een gewone serverkernel verwerkt daarvan, afhankelijk van CPU en netwerkkaart, enkele honderdduizenden voordat hij begint te verwerpen, en de Arma-3-simulatie hangt daarbovenop aan één enkele kern.

De regel met de 4 Mbit/s is de onaangenaamste. Een aanval hoeft bij Arma 3 niet groot te zijn om te werken: hij moet alleen genoeg pakketten naar de juiste poort sturen. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch was alles weg". Omgekeerd geldt voor volumetrische aanvallen de eenvoudige natuurkunde: bij 473,4 Gbit/s is elke lokale instelling betekenisloos, omdat de pakketten van uw spelers al eerder niet meer doorkomen. Volumetrische aanvallen moeten in het netwerk vóór de server eindigen.

Wat KernelHost daartegenover zet

De permanente bescherming die bij elke server inbegrepen is

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

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

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

Advanced DDoS Protection voor projecten die permanent onder vuur liggen

Sommige projecten worden niet af en toe, maar gericht en wekenlang aangevallen. Een Life-server met een vaste spelersgroep en een concurrerende scene is daarvoor de regel, niet de uitzondering. 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 enkele aanpassing nodig.
• Zelf beheerbare beschermingsregels per poort en protocol in het klantenpaneel: u stelt gescheiden in wat op 2302 UDP is toegestaan en wat op 2303 UDP, en kunt de querypoort daarmee duidelijk strakker houden dan de spelpoort.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen in plaats van op een onderhoudsvenster te wachten.
• Een beschermingsprofiel dat bij het betreffende spel past, net zo goed als voor aangepaste en eigen applicaties op willekeurige TCP- of UDP-poorten.

De twee lagen naast elkaar

Voor de meeste Arma-3-projecten volstaat de inbegrepen permanente bescherming samen met een nette serverconfiguratie. De Advanced DDoS Protection is het antwoord op iemand die het persoonlijk maakt.

Veelgemaakte fouten en oplossingen

"Ik heb de poort van 2302 naar 2402 verlegd, de aanval liep gewoon door": dat is te verwachten. De server meldt zijn nieuwe poort zelf aan bij de Steam-masterserver, en de serverlijst publiceert hem onmiddellijk weer. Een poortwissel helpt alleen tegen iemand die een oud adres uit een oude schermafbeelding gebruikt.

"Ik heb 2303 volledig geblokkeerd, nu vindt niemand ons meer": precies dat gebeurt er. Zonder antwoord op de Steam-querypoort ontbreekt de vermelding in de serverbrowser, en elke statuspagina en elke Discord-bot toont de server als offline. Juist is een ratelimiet per bronadres, geen blokkade.

"In het logboek staat NetServer::SendMsg: cannot find channel": deze melding komt wanneer de server naar een verbinding wil schrijven die er niet meer is. Ze begeleidt doorgaans afbrekende spelersverbindingen en prestatieverlies (Bohemia voert dat onder T83936), niet per se een aanval. Controleer eerst of de pakketsnelheid van de interface überhaupt opvalt.

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

"BattlEye kickt sinds de nieuwe firewall alle spelers": de server bereikt arma31.battleye.com niet meer. De uitgaande poorten 2344 op TCP en UDP en 2345 op TCP moeten open blijven, anders valt de anti-cheatverbinding van de server weg.

"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 Arma-3-server heeft naar buiten precies drie UDP-poorten nodig: 2302 voor spel en spraak, 2303 voor de Steam-query en 2304 voor de aanmelding bij de Steam-masterserver. TCP heeft het spel niet nodig.
• Poort 2306 UDP draagt BattlEye en de RCon-interface en hoort uitsluitend op uw eigen adminadressen, ingesteld via RConPort en RConIP in beserver_x64.cfg.
• De Steam-querypoort 2303 is het gevoeligste punt: het Steam-protocol heeft volgens US-CERT TA14-017A een versterkingsfactor van 5,5, en elke opvraging kost rekentijd op de kern die de simulatie draagt. Begrenzen in plaats van blokkeren.
• steamProtocolMaxDataSize zo klein houden als de modlijst toelaat, en MaxCustomFileSize = 0; in de basic.cfg zetten: beide verkleinen de hoeveelheid gegevens die uw server ongevraagd uitlevert.
• Bij Arma 3 beslist de pakketsnelheid, niet de bandbreedte. Bohemia documenteert sinds 2015 onder T83469 dat al 4 Mbit/s op de querypoort volstond om een server te bevriezen.
• Lokale maatregelen eindigen bij de lijn. Vanaf 1 Gbit/s aanvalsvolume of enkele honderdduizenden pakketten per seconde beslist uitsluitend de filtering in het netwerk vóór de server.
• Bij KernelHost is de permanente bescherming in twee lagen bij elk serverpakket zonder meerprijs inbegrepen en vanaf de oplevering actief, zonder null-routing. De Advanced DDoS Protection vult haar vanaf 50,00 € per maand aan met een dedicated beschermd IP-adres en zelf beheerbare regels per poort.

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