Rust-server beschermen tegen DDoS-aanvallen

Een Rust-server gaat zelden toevallig offline. Het tijdstip verraadt bijna altijd het motief: de aanval begint op de minuut van de wipe of midden in een raid. Wie onder vuur ligt, heeft geen principiële discussie nodig, maar een volgorde. Dit artikel laat eerst zien wat u zelf op de server kunt aanpassen, daarna waar die mogelijkheden ophouden, en tot slot wat er ervoor in het netwerk moet gebeuren.

Waarom juist Rust-servers zo vaak worden aangevallen

Rust is een spel waarin vooruitgang aan tijd gebonden is. Een raid duurt minuten, een wipe-cyclus weken. Daarom is uitval hier waardevoller dan in bijna elk ander spel: wie verdedigt, wint tijd zodra de server omvalt. Wie aanvalt, voorkomt dat de tegenpartij online komt. En wie een concurrerende community draait, weet dat de eerste wipe-avond bepaalt hoeveel spelers hij die maand haalt.

Daar komt een punt bij dat u niet weg kunt configureren: een Rust-server is met IP-adres en poort openbaar vindbaar, anders zou niemand kunnen meedoen. Anders dan een website achter een proxy moet een gameserver zijn echte adres publiceren. De vraag is dus nooit of de aanvaller uw IP-adres vindt, maar alleen wat er gebeurt zodra hij erop schiet.

Om welke poorten het gaat

Een Rust-server gebruikt in de gebruikelijke configuratie vier poorten:

• 28015/UDP, de spelpoort (server.port). Hier loopt het volledige spelverkeer overheen. UDP kent geen verbindingsopbouw, elk pakket staat op zichzelf en het afzenderadres is te vervalsen. Voor een aanvaller betekent dat: geen traceerbaarheid, en toch werk voor uw server bij elk pakket.
• De query-poort (server.queryport), eveneens UDP. Daarover beantwoordt de server de Steam-opvragingen A2S_INFO, A2S_PLAYERS en A2S_RULES; zonder die poort verschijnt hij in geen enkele serverlijst. Zonder expliciete waarde ligt hij direct naast de spelpoort, veel startregels zetten hem op 28017/UDP. Kijk in uw eigen startregel na in plaats van op een standaardwaarde te vertrouwen.
• 28016/TCP, RCON (rcon.port), bij rcon.web 1 als WebSocket-variant.
• 28082/TCP, de companion-app Rust+ (app.port).

De query-poort is de lastigste van de vier, want een A2S-antwoord is duidelijk groter dan de vraag. Een aanvaller kan vreemde gameservers met een vervalst afzenderadres bevragen en de antwoorden naar zijn eigenlijke doelwit sturen. Uw server is dan niet alleen slachtoffer, maar ook versterker tegen derden. Valve heeft A2S_INFO daarom uitgebreid met een challenge-opvraging, wat het probleem verkleint maar niet oplost. Waaraan u een aanval herkent, beschrijft het artikel DDoS-aanval op de server herkennen.

Wat u zelf kunt doen voordat u geld uitgeeft

Het volgende deel kost niets en loont ongeacht waar uw server staat. Het houdt geen volumetrische aanval tegen, maar zorgt er wel voor dat kleine aanvallen zonder effect blijven en dat u in een noodgeval niet hoeft te gokken.

1. Inventarisatie: wat luistert er werkelijk

Voordat u een regel schrijft, brengt u in kaart welke diensten bereikbaar zijn. Op een gameserver die in de loop van de tijd is gegroeid, zijn dat er bijna altijd meer dan verwacht:

ss -lntup

Alles wat aan 127.0.0.1 of ::1 gebonden is, hoeft niet te worden vrijgegeven. Alles op 0.0.0.0 of [::] is vanaf het internet bereikbaar, ook de databasedienst die een plugin heeft meegebracht. Vergelijk de uitvoer met uw startregel:

./RustDedicated -batchmode -nographics \
  +server.port 28015 \
  +server.queryport 28017 \
  +server.identity "wipe" \
  +server.maxplayers 150 \
  +rcon.port 28016 \
  +rcon.web 1 \
  +rcon.password "UW-LANGE-WILLEKEURIGE-WACHTWOORD"

Is Rust bij u via SteamCMD geïnstalleerd, dan helpt het artikel Gameserver met SteamCMD installeren met de onderbouw.

2. Alleen de poorten openlaten die Rust echt nodig heeft

Vier poorten, meer niet. RCON hoort niet op het open internet, maar beperkt tot uw eigen adres, en Rust+ opent u alleen als u de companion-app gebruikt:

ufw allow 28015/udp comment "Rust spelpoort"
ufw allow 28017/udp comment "Rust Query"
ufw allow from 203.0.113.10 to any port 28016 proto tcp comment "Rust RCON"
ufw allow 28082/tcp comment "Rust Companion"

Vervang 203.0.113.10 door uw eigen adres. Bij een wisselend adres loopt de weg via een SSH-tunnel.

Een waarschuwing die elk jaar servers kost: de volgorde waarin u een firewall scherp zet, bepaalt of u uzelf buitensluit. Die volgorde staat, inclusief de weg terug, in het artikel UFW-firewall instellen. Gebeurt het toch: bij KVM-rootservers en dedicated servers van KernelHost bereikt u de server via de VNC-console in het klantenpaneel. Die console hangt niet aan de netwerkstack van het gastsysteem en kan door een firewallregel binnen het gastsysteem niet worden geblokkeerd.

3. De query-poort beveiligen zonder uit de serverlijst te vallen

De voor de hand liggende reflex om de query-poort dicht te zetten, is de duurste fout binnen dit onderwerp. Zonder die poort verdwijnt uw server uit de serverbrowser, toont hij verkeerde spelersaantallen en staat hij op lijstsites als offline. U zou de aanval dan zelf hebben afgemaakt.

Juist is een ratelimiet per afzenderadres. Een echte client vraagt bij het doorbladeren van de lijst een paar keer per seconde iets op, een reflectietool duizenden keren. Met nftables in een eigen tabel die vóór de filterketen wordt geëvalueerd:

table inet rust {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 28017 meter rustquery { ip saddr limit rate over 15/second } drop
    }
}

Het bestand laadt u met nft -f. De prioriteit -10 zorgt ervoor dat de regel eerder werkt dan de filterketen die UFW met prioriteit 0 aanmaakt. Met klassiek iptables bereikt de module hashlimit hetzelfde:

iptables -A INPUT -p udp --dport 28017 -m hashlimit \
  --hashlimit-name rustquery --hashlimit-mode srcip \
  --hashlimit-above 15/sec --hashlimit-burst 30 -j DROP

Begin ruim en zet de grens pas strakker zodra aantoonbaar is dat legitieme opvragingen doorkomen. Een te krappe grens valt anders pas op de wipe-dag op.

4. De connection tracking ontlasten

Dit punt wordt bijna altijd over het hoofd gezien en verklaart uitval die op een volume-aanval lijkt, maar het niet is. De kernel maakt voor UDP-verkeer vermeldingen aan in de connection tracking (conntrack), en bij vervalste afzenderadressen levert elk nieuw adres een nieuwe vermelding op. Zit de tabel vol, dan verwerpt de kernel pakketten zonder onderscheid: de aanval en uw spelers vliegen er samen uit. In het logboek van het systeem staat dan nf_conntrack: table full, dropping packet. Controleren doet u zo:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg | grep -i conntrack

De meest effectieve stap is om het spelverkeer helemaal niet te laten volgen. Rust heeft daarvoor geen statusbewaking in de kernel nodig, het beheert zijn sessies zelf:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport 28015 notrack
    }
}

Met iptables luidt het equivalent:

iptables -t raw -A PREROUTING -p udp --dport 28015 -j NOTRACK

Pas daarna loont het om nf_conntrack_max te verhogen. Wie eerst de tabel vergroot, schuift het probleem slechts een paar minuten voor zich uit en verbruikt daarvoor geheugen.

5. Ontvangstbuffers en kernelparameters

Komen pakketten sneller binnen dan het Rust-proces ze ophaalt, dan loopt de ontvangstbuffer van de socket over. Voor de spelers ziet dat eruit als pakketverlies, terwijl de lijn helemaal vrij is:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Zet de waarden neer onder /etc/sysctl.d/ en activeer ze met sysctl -p. Of ze nodig zijn, verklapt de kernel: stijgt UdpRcvbufErrors in nstat -az, of staat er in ss -lunp permanent iets in de ontvangstwachtrij, dan hebben ze zin. Blijven beide op nul, dan verandert de aanpassing niets. Dit is reserve, geen bescherming.

6. RCON beveiligen

Een open RCON-poort met een zwak wachtwoord is geen DDoS-probleem, maar een overname: wie RCON heeft, kan bannen, ontbannen en het spel stoppen. Laat rcon.password nooit leeg staan en kies nooit iets wat te raden valt, een waarde uit openssl rand -base64 32 staat er binnen vijf seconden. En geef de poort niet publiek vrij, maar beperk hem tot uw eigen adres.

7. Maatregelen bij anticheat en plugins

Een aanzienlijk deel van de storingen die beheerders als DDoS melden, is dat helemaal niet. Het zijn crashes die één enkele client met een paar honderd pakketten uitlokt, omdat er in de serverbinary of in een plugin een gat openstaat. Daartegen helpt onderhoud, geen bandbreedte:

• Houd de serverbinary actueel. De maandelijkse update die de wipe afdwingt, is tegelijk een beveiligingsupdate. Wie hem uitstelt, blijft met de bekende fouten zitten.
• Houd het pluginframework actueel. Oxide/uMod en Carbon trekken na elke Rust-update bij. Een framework dat niet bij de serverversie past, is de meest voorkomende oorzaak van crashes op de wipe-avond.
• Minder plugins. Elke plugin is extra code in hetzelfde proces. Plugins met eigen webdiensten (kaartweergaven, statistiekpagina's) openen extra poorten en publiceren daarbij vaak precies het adres dat u wilde beschermen.
• Houd de banlijsten bij. Herhaalde verbindingspogingen van hetzelfde account zijn met de eigen middelen van Rust te blokkeren. Rust bewaart eigenaren en moderatoren in server/<identity>/cfg/users.cfg en blokkades in server/<identity>/cfg/bans.cfg. Een blokkade via banid overleeft de herstart.

Een whitelist zit niet standaard in Rust, die komt via het pluginframework. Voor een privéserver of een communityserver werkt dat prima. Voor een openbare wipe-server is het geen optie: een server die niemand kan betreden, is net zo leeg als een server die offline staat.

8. De serverlijst en uw eigen adres

Aan het openbare IP-adres van de gameserver valt niets te veranderen, aan alles eromheen des te meer. Vaak vindt een aanvaller meteen de hele omgeving: de webserver met de shop, de host van de Discord-bot, de back-upserver, de toegang tot het paneel. Die adressen horen niet in dezelfde aankondiging en ook niet in oude DNS-records. Controleer eens per kwartaal welk subdomein waarheen wijst.

9. Meten en vastleggen, zodat u tijdens de aanval niet hoeft te gokken

Tijdens een aanval telt één vraag: hoeveel komt er binnen en op welke poort. Drie commando's volstaan:

ip -s link show eth0
nstat -az | grep -i udp
journalctl -u rust-server -f

Het eerste commando toont pakketten, fouten en verworpen verkeer per interface. Voer het twee keer uit met tien seconden ertussen, dan hebt u een snelheid in plaats van een absolute waarde. De interface en de service-unit kunnen bij u anders heten, controleer beide met ip -br link en systemctl list-units --type=service. Hoe de pakketten eruitzien, laat een steekproef zien die kort moet blijven, want een opname kost onder belasting rekentijd:

tcpdump -ni eth0 -c 200 "udp port 28015"

Waar de eigen bescherming ophoudt

Nu het eerlijke deel. Alles wat tot hier is beschreven, werkt pas als de pakketten op uw netwerkkaart zijn aangekomen. Een server hangt doorgaans aan 1 Gbit/s of 10 Gbit/s. Bij de kleinst mogelijke pakketgrootte draagt een 1-Gbit/s-lijn ongeveer 1,49 miljoen pakketten per seconde, een 10-Gbit/s-lijn ongeveer 14,88 miljoen. Dat is de fysieke bovengrens, onafhankelijk van CPU, kernel en firewall.

Daartegenover staan echte aanvallen. Twee voorbeelden uit de praktijk bij KernelHost, beide in realtime gefilterd: een UDP-flood tegen een ARK-gameserver op poort 7777/UDP met meer dan 112,2 Gbit/s en meer dan 8,7 miljoen pakketten per seconde, en een multivectoraanval tegen een voiceserver op poort 9987/UDP met meer dan 473,4 Gbit/s en meer dan 41,5 miljoen pakketten per seconde.

Zet dat af tegen uw eigen lijn: 473,4 Gbit/s is ongeveer 470 keer zoveel als een aansluiting van 1 Gbit/s en nog altijd ongeveer 47 keer zoveel als een aansluiting van 10 Gbit/s. Uw regel kan nog zo correct zijn, hij wordt nooit uitgevoerd, want het verlies ontstaat al op de router ervoor. En ruim voordat de lijn vol zit, is de CPU op: elk pakket kost een interrupt en een gang door de netwerkstack, ook als het daarna wordt weggegooid.

Daarom voldoen de twee gangbare noodremmen allebei niet. Null-routing (blackholing) haalt het aangevallen IP-adres uit het netwerk en beëindigt weliswaar de aanval, maar ook uw server. En een reactieve omleiding naar een filtersysteem kost in de omschakeltijd precies de minuten waarin de raid wordt beslist. Effectief is alleen een filtering die permanent in het netwerk vóór de server draait.

Wat KernelHost daartegenover zet

De permanente bescherming die op elke server draait

De DDoS-bescherming van KernelHost is in twee lagen opgebouwd en permanent actief, zonder dat u iets hoeft in te schakelen. De eerste laag is een wereldwijd scrubbingnetwerk met 17 Tbps mitigatiecapaciteit, dat volumetrische aanvallen dicht bij hun bron opvangt voordat ze het datacenter bereiken. De tweede laag is een Arbor realtime filtering met 3,2 Tbps direct ter plaatse in Frankfurt am Main, die het protocolnabije fijne werk doet en complexe patronen op laag 3 tot en met 7 verwerpt.

Twee punten zijn doorslaggevend. Ten eerste draait de filtering permanent, er is dus geen herkennings- en omschakeltijd waarin uw spelers eruit vliegen. Ten tweede wordt er geen null-routing toegepast: het aangevallen IP-adres blijft in het netwerk, alleen de schadelijke pakketten vallen weg. De bescherming zit zonder meerprijs in elk serverpakket, zonder apart beschermingspakket en zonder installatie. De servers staan in het maincubes Premium Datacenter in Frankfurt am Main (Duitsland), TÜV TIER3+ gecertificeerd en direct aan de DE-CIX. Aanbieder is KernelHost GmbH, gevestigd in Wenen (Oostenrijk). Welke games en protocollen gedekt zijn, somt het artikel Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor projecten die permanent onder vuur liggen

Sommige Rust-projecten worden niet af en toe, maar wekenlang gericht aangevallen, met wisselende patronen en steeds precies op het moment van de wipe. Voor die gevallen is er de Advanced DDoS Protection vanaf € 50,00 per maand, PrePaid en zonder minimale looptijd. Die biedt drie dingen die de inbegrepen permanente bescherming zo niet heeft:

• Een eigen, dedicated beschermd IP-adres. Uw server wordt daarop omgezet binnen ons eigen netwerk, een verbouwing aan uw kant is niet nodig.
• Zelf te beheren beschermingsregels per poort en protocol. In het klantenpaneel bepaalt u welke poort met welk profiel wordt gefilterd, bijvoorbeeld 28015/UDP anders dan de query-poort. Wijzigingen werken in realtime, zonder ticket en zonder wachttijd.
• Een beschermingsprofiel dat bij het spel past. Voor Rust en net zo goed voor meer dan 40 andere games, diensten en protocollen, plus vrij in te vullen TCP- en UDP-profielen voor aangepaste servers.

Ook hier geldt het PrePaid-model: geen minimale looptijd, geen opzegtermijn, geen contract en geen installatiekosten. Is de aanvalsgolf voorbij, dan verlengt u gewoon niet.

De twee niveaus naast elkaar

Veelvoorkomende fouten en oplossingen

De server is uit de serverbrowser verdwenen, maar draait gewoon door: bijna altijd staat de query-poort dicht of is de ratelimiet te krap. Controleer met ss -lunp of hij luistert en verruim de limiet stap voor stap. Blijft Rust+ stil, dan staat meestal app.port dicht.

Alle spelers hebben een hoge ping en rubberbanding, terwijl de lijn niet vol zit: dat wijst op de pakketsnelheid en niet op volume. Bekijk de verworpen pakketten in ip -s link show en de UDP-tellers in nstat -az. Een volle ontvangstbuffer of een uitgeputte connection tracking geeft precies dit beeld.

De firewallregel klopt en werkt toch niet: dan zit de lijn vóór de server vol. Een regel die nooit wordt uitgevoerd, omdat het pakket al op de router ervoor sneuvelde, kan niets uitrichten. Vanaf dat punt helpt alleen nog filtering in het netwerk.

Na het scherp zetten van de firewall geen SSH-toegang meer: log in via de VNC-console in het klantenpaneel. Daarmee zet u de firewall uit en vult u de ontbrekende regel aan, ook als er via het netwerk niets meer werkt.

De aanval stopt na een IP-wissel en komt na een tot twee dagen terug: dat is het normale beeld. Uw server publiceert het nieuwe adres zelf in de serverlijst zodra hij weer online is. Een IP-wissel levert uren op, geen oplossing.

Er lopen vreemde beheerderscommando's op de server: geen DDoS, maar een gecompromitteerde RCON-toegang. Wijzig direct het wachtwoord, beperk de poort tot uw eigen adres en controleer de banlijst.

Als u op dit moment wordt aangevallen

Draait uw server al bij KernelHost, dan is de filtering permanent actief en hoeft u niets in te schakelen. Merkt u toch iets afwijkends, open dan een supportticket, zodat ons team de filterregels voor uw IP-adres bijstelt. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883.

Vermeld daarbij meteen vier gegevens: IP-adres, poort, periode in uw eigen tijdzone en kort wat u ziet (spelers vliegen eruit, server niet bereikbaar, hoge ping). Dat scheelt een ronde extra vragen, en die telt zodra de wipe loopt.