ARK-server beschermen tegen DDoS-aanvallen

Een ARK-cluster valt zelden op een willekeurig moment uit. Wie PvP-servers beheert, kent het patroon: net voordat een vijandelijke basis valt, wordt de server onbereikbaar, vliegen alle spelers eruit, en tegen de tijd dat hij terug is, is de raid voorbij. Dit artikel laat eerst zien wat u op de server zelf kunt instellen, daarna waar die maatregelen technisch ophouden, en tot slot wat KernelHost ervoor zet.

Waarom juist ARK zo gericht wordt aangevallen

Bij de meeste spellen is een serveruitval vooral vervelend. Bij ARK: Survival Evolved en ARK: Survival Ascended is het een zet in het spel. Verlies in het spel is blijvend, een raidvenster duurt maar een paar minuten, en elke offline-raidbescherming werkt alleen zolang de server bereikbaar is. Wie de verdedigers tien minuten uit het spel haalt, wint grondstoffen en creatures. De aanval levert dus concrete winst op, heeft een gepland tijdstip, en herhaalt zich zodra hij één keer heeft gewerkt.

Daar komt de opbouw van een cluster bij. Meerdere kaarten draaien meestal op dezelfde machine achter hetzelfde IP-adres. Een aanval raakt daarom niet één server, maar The Island, Ragnarok, Aberration en de transfer daartussen tegelijk. Spelers die precies tijdens een transfer blijven hangen, raken in het ongunstigste geval hun personage en hun voorwerpen kwijt. Wat er bij een DDoS-aanval technisch gebeurt, legt het artikel Wat is een DDoS-aanval? uit.

De poorten waar het om gaat

ARK wikkelt het spelverkeer volledig via UDP af. Dat is de reden dat veel firewallhandleidingen hier niet helpen: die openen TCP.

Survival Evolved bezet daarnaast de poort direct boven de spelpoort, omdat de engine daar een tweede UDP-socket opent. Survival Ascended heeft die tweede poort niet meer nodig. De queryport beantwoordt statusaanvragen in Steam-formaat (servernaam, kaart, aantal spelers, speeltijd) en is voor aanvallers de interessantste poort.

In een cluster geeft u de poorten in stappen van twee uit, zodat de tweede socket niet botst met de volgende instantie: 7777 en 7778 voor de eerste kaart, 7779 en 7780 voor de tweede, plus 27015 en 27016 als queryports.

Wat u zelf kunt doen voordat u geld uitgeeft

De volgende stappen kosten niets en werken tegen de meest voorkomende gevallen: kleine gerichte floods vanuit weinig bronnen, misbruikte queryports en pogingen om via RCON de controle over te nemen. Ze zijn ook zinvol wanneer er al een netwerkfilter voor staat.

1. Alleen openzetten wat het cluster echt nodig heeft

Een ARK-host heeft al snel meer open poorten dan u denkt: een panel, een database, een webserver voor de kaart, en daarnaast de spelinstanties. Elk daarvan is een doelwit voor pakketten. Het volgende nftables-regelwerk voor /etc/nftables.conf laat door wat een cluster met twee kaarten nodig heeft en verwerpt de rest.

#!/usr/sbin/nft -f

flush ruleset

table inet ark {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set queryflood {
        type ipv4_addr
        size 65535
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority 0; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        ip saddr @adminips tcp dport { 22, 27020 } accept

        udp dport { 7777-7780 } accept

        udp dport { 27015-27016 } add @queryflood { ip saddr limit rate over 10/second burst 20 packets } drop
        udp dport { 27015-27016 } accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Vul onder adminips uw vaste IP-adres in voordat u het regelwerk laadt, anders verliest u uw eigen SSH-toegang.

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset

nft -c controleert alleen de syntaxis en verandert niets. Pas het tweede commando laadt het regelwerk en zorgt dat het een herstart overleeft. Werkt u liever met UFW, dan staat die weg beschreven in UFW-firewall instellen. Let op: flush ruleset wist ook de regels van UFW en Docker. Draait een van beide, laat die regel dan weg.

2. De queryport begrenzen in plaats van hem te sluiten

De queryport is de enige poort waar uw server aan elke willekeurige buitenstaander op een piepklein verzoek een duidelijk groter antwoord terugstuurt. Daaruit volgen twee problemen. Ten eerste is uw server als versterker te misbruiken: de aanvaller vervalst het afzenderadres, uw server antwoordt een onbekend slachtoffer, en uw lijn draagt het uitgaande verkeer. Ten tweede kost elk antwoord rekentijd in precies het proces dat ook het spel berekent. Een flood op 27015 uit zich daarom vaak als haperen en niet als een verbroken verbinding.

De poort sluiten is geen oplossing, want dan verdwijnt de server uit de serverlijst. De regel hierboven begrenst in plaats daarvan per bronadres: tien opvragingen per seconde met een buffer van twintig pakketten volstaan voor spelers en monitoring, terwijl een bron met duizenden verzoeken per seconde wordt verworpen. Welke adressen op dit moment begrensd worden, laat dit zien:

nft list set inet ark queryflood

3. RCON van het internet afhalen

RCON geeft volledige controle: wie het wachtwoord heeft, verwijdert spelers, stopt de server en grijpt in de spelwereld in. De poort is TCP, het wachtwoord staat in leesbare tekst in de configuratie, en er geldt geen limiet op het aantal inlogpogingen. Daarom staat die poort in het regelwerk hierboven alleen open voor het adres van de beheerder.

[ServerSettings]
RCONEnabled=True
RCONPort=27020
ServerAdminPassword=<lang willekeurig wachtwoord>

Het bestand GameUserSettings.ini staat in de servermap onder ShooterGame/Saved/Config/. Een bruikbaar wachtwoord maakt u zo:

openssl rand -base64 24

Gebruikt een webpanel op dezelfde machine RCON, dan volstaat toegang via 127.0.0.1 en blijft de poort van buitenaf dicht. Draait het panel ergens anders, dan hoort het adres daarvan in adminips thuis en nergens anders.

4. De connection tracking ontlasten

Een UDP-flood velt een Linux-server vaak niet via de bandbreedte, maar via de connection tracking. De kernel legt voor elk binnenkomend UDP-pakket een vermelding aan, de tabel loopt vol, en daarna verwerpt hij ook pakketten van echte spelers, herkenbaar aan nf_conntrack: table full, dropping packet in het logboek. Voor spelverkeer heeft die tracking geen enkel nut, dus haalt u de spelpoorten eruit:

table inet arkraw {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        udp dport { 7777-7780, 27015-27016 } notrack
    }

    chain output {
        type filter hook output priority -300; policy accept;
        udp sport { 7777-7780, 27015-27016 } notrack
    }
}

Beide richtingen zijn nodig, anders ontstaan er halve vermeldingen voor uitgaand verkeer. Daarnaast een paar kernelparameters in /etc/sysctl.d/90-ark.conf:

net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_udp_timeout = 15
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216
net.ipv4.tcp_syncookies = 1

sysctl --system
cat /proc/sys/net/netfilter/nf_conntrack_count

Loopt de tweede waarde tijdens een aanval op richting het maximum, dan was de connection tracking het knelpunt en niet de lijn.

5. Whitelist en serverwachtwoord

Bedient uw cluster toch al een besloten groep, dan is een toegangslijst de meest effectieve maatregel tegen storende spelers. ARK levert die zelf mee, de server start daarvoor met -exclusivejoin:

./ShooterGameServer "TheIsland?listen?SessionName=MijnCluster?Port=7777?QueryPort=27015?RCONEnabled=True?RCONPort=27020" -server -log -exclusivejoin

De toegelaten spelers staan dan, één ID per regel, in PlayersExclusiveJoinList.txt in de map van het uitvoerbare serverbestand. Tijdens het draaien onderhoudt u de lijst via de serverconsole of via RCON:

AllowPlayerToJoinNoCheck <speler-ID>
DisallowPlayerToJoinNoCheck <speler-ID>

Een serverwachtwoord via ServerPassword werkt vergelijkbaar, maar wordt in de praktijk snel doorgegeven. Beide hebben dezelfde harde grens: de controle gebeurt in het spelproces, dus pas nadat het pakket is aangekomen. Tegen een pakketstroom helpt een whitelist niet, tegen de speler die uw cluster eerst komt verkennen wel degelijk.

6. Wat anti-cheat en plug-ins wel en niet doen

Op beide titels draait standaard een anti-cheatsysteem, en daarnaast zijn er serverplug-ins via de bijbehorende server-API. Beide zijn zinvol, maar lossen een ander probleem op. Anti-cheat controleert of een verbonden client gemanipuleerd is, een plug-in kan verbindingspogingen tellen of spelers bij opvallend gedrag loskoppelen. Al die controles draaien in hetzelfde proces als het spel en grijpen pas in wanneer het pakket wordt verwerkt. Zit dat proces vol, dan valt de beveiligingslogica samen met dat proces uit. Een plug-in die DDoS-aanvallen afweert kan om die reden niet bestaan. Wat wel helpt: houd serverbestanden en mods actueel en houd het aantal mods klein, want een flink deel van de crashes in ARK-clusters komt door defecte mods en niet door aanvallen.

7. Uw adres staat in de serverlijst

Een openbaar vermelde ARK-server publiceert zijn IP-adres en queryport, anders zou niemand hem kunnen vinden, en die lijsten worden voortdurend automatisch opgevraagd en gearchiveerd. Uw adres is dus bekend zodra de server één keer vermeld heeft gestaan. Verstoppen is geen optie, want wie niet in de lijst staat, groeit niet. Wat overblijft, zijn de zijwegen waarlangs een adres bovendien weglekt:

• Oude DNS-records. Een A-record dat nog naar de vorige server wijst, verraadt het oude adres. Zulke records horen verwijderd te worden.
• Andere diensten op hetzelfde adres. Een website, een kaartweergave, het panel, een voiceserver en de database zijn stuk voor stuk een tweede weg om het cluster te raken.
• De eigen Discord. Statusbots, schermafbeeldingen uit de console en verbindingsinstructies bevatten het adres vaak gewoon leesbaar.

8. Meten in plaats van gokken

De meest voorkomende fout midden in een storing is de verkeerde diagnose. Een gecrashte mod, een vol bestandssysteem en een echte aanval voelen voor de spelers hetzelfde. Uit elkaar houden lukt in één minuut. Eerst de pakketsnelheid op de netwerkkaart:

r1=$(cat /sys/class/net/eth0/statistics/rx_packets)
sleep 1
r2=$(cat /sys/class/net/eth0/statistics/rx_packets)
echo "$((r2-r1)) pakketten per seconde"

Een cluster met vijftig spelers zit normaal in de lage tienduizenden, waarden met zes of zeven cijfers duiden op een aanval. Daarna de tellers van de netwerkstack:

nstat -az UdpInDatagrams UdpNoPorts UdpRcvbufErrors
ss -ulnp | grep -E '7777|27015'

UdpNoPorts loopt op wanneer er pakketten binnenkomen op poorten waar niets luistert, een typisch teken van een blind rondgestrooide flood. UdpRcvbufErrors loopt op wanneer het serverproces de pakketten niet snel genoeg meer ophaalt. Tot slot het logbestand van het spel:

tail -n 200 ShooterGame/Saved/Logs/ShooterGame.log

Staat daar een crashrapport terwijl de pakkettellers niets bijzonders laten zien, dan was het geen aanval. Gebruik tijdens een storing geen tcpdump: de opname kost rekentijd op een systeem dat die op dat moment niet heeft. Meer kenmerken noemt het artikel DDoS-aanval op de server herkennen.

Waar deze maatregelen ophouden

Alles wat tot hier beschreven is, werkt op de server, en precies daar ligt de grens. Een firewallregel kan alleen verwerpen wat al is aangekomen. Het knelpunt zit echter daarvoor, op de lijn.

De cijfers zijn eenduidig. Een aansluiting van 1 Gbit/s zit bij de kleinst mogelijke pakketten na ongeveer 1,49 miljoen pakketten per seconde vol, ongeacht wat de server daarmee van plan is. Een echte UDP-flood op een ARK-gameserver bij KernelHost, poort 7777, kwam uit op ruim 112,2 Gbit/s en ruim 8,7 miljoen pakketten per seconde, gemiddeld dus ongeveer 1,6 kilobyte per pakket. Dat is 112 keer een lijn van 1 Gbit/s en nog altijd meer dan elf keer een lijn van 10 Gbit/s.

Ook het tweede knelpunt is snel bereikt: een CPU-kern verwerpt met een gewoon regelwerk, afhankelijk van de hardware, enkele honderdduizenden pakketten per seconde. Bij 8,7 miljoen klopt die rekensom ook met veel kernen niet meer. De regel doet precies wat hij moet doen, en toch staat de server offline.

Volumetrische aanvallen moeten daarom in het netwerk vóór de server worden gefilterd. Op de server zelf is dat niet op te lossen, niet met meer hardware en niet met een beter regelwerk.

Wat KernelHost ervoor zet

De inbegrepen permanente bescherming op elke server

Op elke server van KernelHost draait een tweelaagse permanente DDoS-bescherming, zonder bestelling en zonder configuratie. De eerste laag is een wereldwijd scrubbing-netwerk met 17 Tbps mitigatiecapaciteit: volumetrische aanvallen worden dicht bij hun bron afgevangen, ruim voordat zij het datacenter bereiken. De tweede laag is een Arbor realtime filtering met 3,2 Tbps direct ter plaatse in het datacenter maincubes in Frankfurt am Main (Duitsland). Die doet het fijne werk op laag 3, 4 en 7 en kent de protocolpatronen van gangbare gameservers.

Drie eigenschappen zijn doorslaggevend. De bescherming is permanent actief, er is dus geen reactietijd waarin een aanval eerst herkend zou moeten worden. Er wordt geen null-routing toegepast: het aangevallen IP-adres blijft in het netwerk en alleen de schadelijke pakketten vallen weg. En er zijn geen extra kosten aan verbonden. Hoe dat er voor gameservers uitziet, beschrijft het artikel Gameserver-DDoS-bescherming in realtime.

Advanced DDoS Protection voor projecten die permanent onder vuur liggen

Sommige clusters worden niet één keer geraakt, maar wekenlang, elke avond op hetzelfde tijdstip en met wisselende patronen. Daarvoor is er de Advanced DDoS Protection vanaf 50,00 euro per maand, PrePaid en daarmee zonder minimale looptijd, zonder opzegtermijn, zonder contract en zonder installatiekosten.

U krijgt een dedicated beschermd IP-adres uit de Frankfurtse kern. Uw server wordt in het netwerk van KernelHost daarop omgezet, een verbouwing aan uw kant is niet nodig. Het verschil zit in wat daarna komt: de beschermingsregels beheert u zelf in het klantenpaneel, gescheiden per poort en protocol, en wijzigingen gelden in realtime, zonder ticket. Als beschermingsprofiel kiest u de titel die de betreffende poort bedient, beschikbaar voor ruim 40 spellen, diensten en protocollen, waaronder ARK: Survival Evolved. Voor een cluster betekent dat: het spelprofiel op de spelpoorten, een strakkere limiet op de queryport en een eigen regel voor een webpanel, in plaats van overal hetzelfde compromis.

De twee lagen vergeleken

Veelgemaakte fouten en oplossingen

Alleen TCP opengezet, de server draait maar niemand komt binnen: het spelverkeer van ARK is UDP, een regel voor tcp dport 7777 verandert daar niets aan. Controleer met ss -ulnp en zet de poorten open als udp dport.

De server is bereikbaar maar staat niet in de serverlijst: meestal is de queryport dicht of is de ratelimiet te strak. Zet 27015 UDP open en verhoog de limiet. Ter controle laat nft list set inet ark queryflood zien welke adressen begrensd worden.

De eigen statusbot meldt de server als offline terwijl er spelers op zitten: een Discord-bot vraagt vanaf één enkel bronadres op, vaak meerdere keren per seconde en voor elke kaart apart, en loopt daarmee in dezelfde limiet als een aanvaller. Zet een uitzondering voor dat adres vóór de limietregel.

Na het laden van het regelwerk is SSH niet meer mogelijk: in adminips stond het verkeerde adres, of SSH draait op een andere poort. Via de VNC-console in het klantenpaneel komt u terug op de server, want IPMI of iDRAC is er bij de dedicated servers en KVM-rootservers niet. Voer daar nft flush ruleset uit als noodrem en corrigeer daarna het bestand.

sysctl kan de conntrack-waarden niet instellen: de parameters onder net.netfilter bestaan pas wanneer de module geladen is. Laad die met modprobe nf_conntrack en roep sysctl --system opnieuw aan.

Een vermeende aanval blijkt in werkelijkheid een mod: zijn de pakkettellers normaal en staat er in ShooterGame.log een crashrapport, dan lag de oorzaak niet bij het netwerk. Na een update in de Workshop is dat de waarschijnlijkste verklaring, zeker wanneer het altijd dezelfde kaart betreft.

Het hele cluster gaat tegelijk offline: alle instanties hangen aan hetzelfde IP-adres, waardoor een aanval alles in één keer raakt, de transfer inbegrepen. Een dedicated beschermd IP lost precies dit patroon op, omdat de filtering dan vóór het adres staat in plaats van op de server erachter.

Kort samengevat

Zet alleen de spelpoorten, de queryport en de toegang voor uw eigen adres open, begrens de queryport per bron, houd RCON van het internet af en meet pakketsnelheden voordat u een oorzaak aanneemt. Dat kost niets en dekt de dagelijkse praktijk af. Alles daarboven wordt niet meer op de server beslist: de inbegrepen permanente bescherming met 17 Tbps mitigatiecapaciteit in het wereldwijde scrubbing-netwerk en 3,2 Tbps Arbor realtime filtering in Frankfurt am Main vangt dat op, zonder meerprijs en zonder null-routing. Bij aanhoudend vuur vult de Advanced DDoS Protection dat aan met een dedicated beschermd IP en regels die u zelf instelt. De exploitant is KernelHost GmbH, gevestigd in Wenen (Oostenrijk).