RAGE MP en alt:V servers beschermen tegen DDoS-aanvallen

Een GTA-multiplayerserver is voor aanvallers een dankbaar doelwit: hij hangt aan één enkel IP-adres, zijn poort staat in een openbare serverlijst, en elke hapering is voor alle spelers tegelijk zichtbaar. Dit artikel laat eerst zien wat u op de eigen server werkelijk kunt bereiken, en daarna net zo duidelijk waar die mogelijkheden ophouden.

Weet u nog niet zeker of er werkelijk een aanval loopt, meet dat dan eerst: DDoS-aanval herkennen beschrijft de diagnose stap voor stap. De technische basis staat in Wat is een DDoS-aanval.

Waarom juist RAGE MP en alt:V zo vaak worden getroffen

De rollenspelscene rond GTA V is klein, openbaar en fel omstreden. Een server leeft van zijn vaste spelersgroep, en die zit bij langere haperingen al snel in een andere Discord. Dat maakt aanvallen aantrekkelijk: het hoeft niet urenlang te lukken, een paar minuten op de drukste speeltijd volstaan, op de openingsavond of tijdens een aangekondigde wipe.

Daar komt bij dat niemand lang hoeft te zoeken. Beide platformen melden uw server desgewenst aan bij een openbare serverlijst, RAGE MP via announce in de conf.json, alt:V via announce en token in de server.toml. Wie daarin staat, publiceert daarmee zijn IP-adres en poort. Een vers ingeschreven server krijgt de eerste geautomatiseerde verbindingspogingen daarom vaak al in het eerste uur, lang voordat de eerste echte speler er is.

De derde reden is technisch van aard: het spelverkeer loopt via UDP. UDP kent geen verbindingsopbouw waar een afzender op moet wachten, dus laat het afzenderadres zich vervalsen. Wie uw poort kent, kan die bestoken zonder ooit een antwoord te krijgen en zonder het eigen adres te tonen.

De poorten waar het om draait

Voordat u de eerste regel schrijft, moet u weten welke poort waarvoor dient. Beide platformen hebben er meer dan één nodig.

Twee eigenaardigheden zijn daarbij belangrijk. Bij RAGE MP is de HTTP-poort vast gekoppeld aan de spelpoort, hij is altijd de eerstvolgende hogere: verschuift u de spelpoort naar 22015, dan gaat de bestandspoort mee naar 22016. Bij alt:V delen spelverkeer en bestandsuitlevering hetzelfde poortnummer, één keer via UDP en één keer via TCP. Wie de clientbestanden via een content delivery network laat uitleveren (de opties useCdn en cdnUrl in de server.toml), haalt het TCP-deel uit de eigen lijn. Het spelverkeer via UDP blijft daarbij onaangeroerd.

Wat u zelf kunt doen voordat u geld uitgeeft

De volgende stappen houden geen volumetrische aanval tegen, dat kan geen enkele software op de server. Ze ruimen wel alles op wat daaronder ligt: poortscans, verbindingsfloods uit een handvol bronnen, aanvallen op de database in plaats van op het spel, en misbruik van uw eigen bestandspoort. Dat is het grootste deel van wat een kleine server in het dagelijks gebruik hindert, en het kost maar een half uur.

Stap 1: inventarisatie, wat luistert er naar buiten

ss -tulnp

Interessant is de kolom met het lokale adres. Alles wat daar op 0.0.0.0 of [::] staat, is vanaf het internet bereikbaar, alles op 127.0.0.1 alleen lokaal. Op een typische rollenspelserver staan naast het spel al snel een database, een cache, een webpaneel en soms een voiceserver. Elk van die diensten is een eigen aanvalsoppervlak, en geen enkele daarvan hoeft open te staan alleen omdat hij draait.

Stap 2: de firewall beperken tot de werkelijk benodigde poorten

Voor een RAGE-MP-server zijn dat drie vrijgaven: SSH, spelpoort en bestandspoort. Sta in elk geval eerst uw SSH-poort toe, anders sluit u zichzelf met de laatste regel buiten:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 22005/udp
ufw allow 22006/tcp
ufw enable

Voor alt:V luiden de twee regels voor het spel in plaats daarvan:

ufw allow 7788/udp
ufw allow 7788/tcp

Controleer daarna met ufw status verbose of werkelijk alleen deze poorten open staan, en herhaal ss -tulnp. De uitgebreide inrichting inclusief IPv6 en de bekende valkuilen rond buitensluiten staat in UFW-firewall instellen.

Stap 3: database en cache van het netwerk halen

MariaDB en Redis draaien bij de meeste gamemodes op dezelfde machine als de gameserver en hebben dan geen adres op het internet nodig. In de MariaDB-configuratie (onder Debian en Ubuntu /etc/mysql/mariadb.conf.d/50-server.cnf) hoort daarvoor deze regel:

bind-address = 127.0.0.1

En in de /etc/redis/redis.conf:

bind 127.0.0.1 ::1
protected-mode yes

Start daarna beide diensten opnieuw op en doe de tegenproef met ss -tulnp. Een open cache zonder wachtwoord is geen DDoS-probleem, maar een inbraakweg, en er wordt dag en nacht naar gescand.

Stap 4: het aantal verbindingen op de bestandspoort begrenzen

De TCP-poort voor de clientbestanden is de plek waar rate limiting op de server wel zinvol ingrijpt, want hier is er een echte verbindingsopbouw en daarmee een afzenderadres dat u enigszins kunt vertrouwen. Twee regels volstaan, hier voor RAGE MP op poort 22006:

iptables -A INPUT -p tcp --dport 22006 --syn -m connlimit --connlimit-above 20 --connlimit-mask 32 -j DROP
iptables -A INPUT -p tcp --dport 22006 --syn -m hashlimit --hashlimit-name gtahttp --hashlimit-mode srcip --hashlimit-above 30/sec --hashlimit-burst 60 -j DROP

De eerste regel begrenst het aantal gelijktijdig open verbindingen per bronadres, de tweede het aantal verbindingspogingen per seconde. Voor alt:V vult u op beide plekken 7788 in. Drie opmerkingen daarbij: ufw limit is hier te grof en kent alleen TCP, de getalswaarden stemt u af op de omvang van uw clientbestanden, en de regels overleven een herstart alleen met iptables-persistent of als vermelding in /etc/ufw/before.rules.

Op de UDP-spelpoort levert dezelfde techniek daarentegen weinig op, omdat de afzenders daar vervalst zijn: een blokkade op bronadres treft dan niemand, behalve toevallig een echte speler. Wat u in plaats daarvan in de gaten moet houden, is de connection tracking van de kernel:

cat /proc/sys/net/netfilter/nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

Komt de eerste waarde in de buurt van de tweede, dan verwerpt de kernel pakketten ongeacht of ze bij een aanval of bij een speler horen. In het logboek van het systeem staat dan nf_conntrack: table full, dropping packet.

Stap 5: de eigen middelen van beide platformen benutten

Beide serverkernen brengen instellingen mee die precies tegen verbindingsmisbruik bedoeld zijn en standaard op de meest tolerante waarde staan. Bij RAGE MP gaat het om drie sleutels in de conf.json:

{
    "bind": "0.0.0.0",
    "port": 22005,
    "announce": true,
    "maxplayers": 200,
    "disallow-multiple-connections-per-ip": true,
    "limit-time-of-connections-per-ip": 1000,
    "enable-http-security": true
}

Dit is een uitsnede, de overige sleutels blijven ongewijzigd. disallow-multiple-connections-per-ip verhindert meerdere gelijktijdige verbindingen vanaf hetzelfde adres, limit-time-of-connections-per-ip dwingt een minimale tussenpauze tussen twee verbindingspogingen af (0 schakelt de begrenzing uit), en enable-http-security activeert de extra controles van de ingebouwde HTTP-server. Vergelijk de tijdseenheid van de middelste waarde met de documentatie van uw serverversie voordat u die verhoogt. En houd er rekening mee dat de eerste optie medespelers achter dezelfde aansluiting buitensluit, dus studentenhuizen, gezinnen en bedrijfsnetwerken.

Bij alt:V staan de bijbehorende opties in de server.toml:

host = '0.0.0.0'
port = 7788
players = 200
announce = true
duplicatePlayers = 4
connectionQueue = true
useEarlyAuth = true

duplicatePlayers begrenst hoeveel spelers met hetzelfde IP-adres tegelijk verbonden mogen zijn. De standaardwaarde is 4096 en daarmee praktisch geen grens. connectionQueue zet verbindingspogingen in een wachtrij in plaats van ze allemaal tegelijk af te handelen. useEarlyAuth plaatst een login vóór de gameserver: de client moet inloggen voordat hij in uw spelwereld komt, wat eenvoudige verbindingsfloods meteen wegfiltert. Het adres van de inlogpagina staat in earlyAuthUrl.

Stap 6: whitelist als noodmaatregel

Loopt een aanval via de spelmechaniek, dus via massale verbindingspogingen in plaats van via pure bandbreedte, dan is een whitelist het meest effectieve middel op korte termijn. Bij alt:V volstaat voor gesloten gebruik al een password in de server.toml. In code ziet de eenvoudigste vorm er zo uit, hier voor RAGE MP:

const whitelist = new Set(['SpelerEen', 'SpelerTwee']);

mp.events.add('playerJoin', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('De server is momenteel gesloten.');
    }
});

En dezelfde logica voor alt:V:

import * as alt from 'alt-server';

const whitelist = new Set(['SpelerEen', 'SpelerTwee']);

alt.on('playerConnect', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('De server is momenteel gesloten.');
    }
});

Beide zijn bewust eenvoudig gehouden en hebben een duidelijke grens: de weergavenaam is geen sterk kenmerk. Wie een whitelist permanent inzet, controleert beter tegen de identificatie uit de voorgeschakelde login of tegen een eigen accountbeheer. Bovenal geldt: een kick gebeurt pas nadat de verbinding de server heeft bereikt. Tegen pakketten die de lijn al vullen, helpt hij niet.

Stap 7: vermelding in de serverlijst en IP-hygiëne

De vermelding in de serverlijst uitschakelen (announce op false) klinkt als een snelle oplossing en is dat meestal niet. Wie uw IP-adres al heeft, bereikt u nog steeds, en uw spelers vinden u niet meer. Zinvol is die stap alleen samen met een wissel van IP-adres, want pas dan raakt de aanvaller zijn doelwit kwijt.

Op de lange termijn levert netheid meer op, juist op de plekken waar het adres terloops bekend wordt: website en forum op een andere machine draaien, oude DNS-records verwijderen (ook mail, ftp en testnamen uit de begintijd), Discord-bots en statusweergaven niet vanaf de gameserver laten draaien, de voiceserver scheiden. Volledig verbergen laat het adres van een gameserver zich echter niet: het spelverkeer via UDP moet rechtstreeks bij u aankomen, en een voorgeschakeld content delivery network voor websites verandert daar niets aan. Wat hier helpt, is geen verhulling, maar een adres waarachter filtering zit.

Stap 8: meetwaarden verzamelen voordat het menens wordt

Als het erop aankomt, telt wat u kunt aantonen. Leg vooraf de commando's klaar waarmee u de inkomende pakketsnelheid en de verbindingssituatie in seconden vastlegt:

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) pakketten/s inkomend op $IF"
ss -s

Noteer deze waarden één keer tijdens normaal bedrijf op de drukste speeltijd, want zonder vergelijkingswaarde is elk getal bij een aanval waardeloos. Draait uw gameserver als systemd-dienst, dan hoort journalctl -u <dienstnaam> -n 200 erbij: verbindingsfloods laten daar meestal een duidelijk spoor achter. Eén beperking moet u daarbij kennen: op de server meet u alleen wat is doorgekomen. Zit er filtering voor, dan staat het betrouwbare getal in de verkeersgrafiek in het klantenpaneel en niet in /proc.

Waar deze maatregelen ophouden

Elke regel op de server grijpt pas in nadat het pakket is aangekomen. Dat is de doorslaggevende zin. Een firewall beslist over pakketten die al door uw lijn zijn gegaan, en juist die lijn is het doelwit van een volumetrische aanval.

De ordes van grootte daarbij: een enkele server hangt doorgaans aan 1 Gbit/s. Bij de kleinste pakketten komt dat neer op ongeveer 1,5 miljoen pakketten per seconde, meer past er fysiek niet doorheen. Om die lijn dicht te zetten heeft niemand een recordaanval nodig, 2 tot 5 Gbit/s volstaan daarvoor. Ter vergelijking een werkelijk gemeten aanval uit het Frankfurtse netwerk van KernelHost: ruim 473,4 Gbit/s en ruim 41,5 miljoen pakketten per seconde op één enkele dienst. Dat is ongeveer 470 keer een gigabitlijn, en ook een aansluiting van 10 Gbit/s zit daar nog een factor 47 vandaan.

Zit de lijn vol, dan verwerpt de router ervoor de pakketten al, en dat gebeurt zonder naar het afzonderlijke pakket te kijken. Uw spelers staan dan in dezelfde wachtrij als de aanval. Geen iptables, geen plug-in en geen sterkere CPU verandert daar iets aan, omdat het knelpunt vóór de server ligt. Daar komt bij dat de afzenderadressen bij UDP-floods vervalst zijn: er is simpelweg niemand die u zinvol zou kunnen blokkeren.

Effectief is daarom alleen filtering die in het netwerk vóór uw lijn zit en daar zo veel capaciteit heeft dat de aanval haar niet verzadigt.

Wat KernelHost daartegenover zet

De permanente bescherming die op elke server al draait

Bij KernelHost (KernelHost GmbH, gevestigd in Wenen, Oostenrijk) is op elke server een tweelaagse DDoS-bescherming permanent actief, zonder bestelling, zonder configuratie en zonder meerprijs:

• Laag 1: globaal scrubbing-netwerk met 17 Tbps mitigatiecapaciteit. Volumetrische aanvallen worden dicht bij hun bron opgevangen, nog voordat ze het datacenter bereiken.
• Laag 2: Arbor realtime filtering met 3,2 Tbps. Die staat ter plaatse in het maincubes-datacenter in Frankfurt am Main (Duitsland) en doet direct vóór uw server het fijne werk, pakket voor pakket.

Net zo belangrijk is wat er niet gebeurt: er wordt geen null-routing toegepast. Uw IP-adres blijft tijdens een aanval in het netwerk, alleen de schadelijke pakketten vallen weg. Voor een rollenspelserver is dat verschil aanzienlijk, want een adres dat via null-routing uit het netwerk is gehaald, is voor uw spelers niet te onderscheiden van een geslaagde aanval. Komt u tijdens een incident via SSH niet meer door, dan bereikt u het systeem nog steeds via de VNC-console in het klantenpaneel, die los van de netwerkverbinding van de server werkt.

Advanced DDoS Protection voor permanent aangevallen projecten

Sommige projecten worden niet één keer getroffen, maar wekenlang. Voor dat geval is er de Advanced DDoS Protection vanaf € 50,00 per maand, PrePaid en zonder minimale looptijd, zonder opzegtermijn, zonder contract en zonder installatiekosten. Inbegrepen zijn:

• een dedicated beschermd IP-adres uit de Frankfurtse kern, waarop uw server wordt overgezet, zonder aanpassingen aan uw kant,
• beschermingsregels die u zelf beheert, per poort en protocol, rechtstreeks in het klantenpaneel,
• wijzigingen die in realtime van kracht worden, zonder ticket en zonder wachttijd,
• een beschermingsprofiel dat past bij het betreffende spel, uit meer dan 40 profielen voor spellen, diensten en protocollen, waaronder RageMP en alt:V, plus algemene profielen voor eigen TCP- en UDP-toepassingen.

Het praktische verschil zit in de controle: u bepaalt zelf welk profiel op 22005 UDP draait en welke regel voor 22006 TCP geldt, ook midden in een aanval.

De twee lagen vergeleken

Veelgemaakte fouten en oplossingen

Alle poorten open, omdat er anders iets niet werkt: dat is bijna altijd een verkeerde diagnose. Noteer met ss -tulnp welke dienst welke poort nodig heeft, en open precies die. Ontbreekt er daarna iets, dan ligt het meestal aan een dienst die toch al alleen lokaal gebonden is.

De IP-adressen van de aanvallers worden geblokkeerd: bij een UDP-flood zijn de afzenders vervalst. U blokkeert daarmee onbetrokken adressen en in het ergste geval uw eigen spelers. Zinvol is dat alleen bij TCP-verbindingen met een volledige verbindingsopbouw, dus op de bestandspoort.

Alleen announce op false gezet: de server verdwijnt uit de lijst, maar het IP-adres blijft hetzelfde. Een lopende aanval gaat onveranderd door, alleen vinden uw spelers de server niet meer. Zonder wissel van adres levert die stap niets op.

Rate limiting op de UDP-spelpoort: mobiele netwerken en bedrijfsaansluitingen bundelen veel spelers achter één adres. Een begrenzing per bronadres gooit daar echte spelers uit het spel, terwijl de vervalste afzenders van de flood ongemoeid blijven.

Meer CPU en meer RAM als antwoord op DDoS: beide helpen tegen een overbelaste gamemode, niet tegen een volle lijn. Het knelpunt ligt vóór de server, en daar verandert sterkere hardware niets aan.

Herstart midden in de aanval: die wist alle tellers die u voor een onderbouwde melding nodig had, en de aanval loopt daarna onveranderd door. Verzamel eerst de meetwaarden, handel pas daarna.

Database open op het internet, omdat het webpaneel op een andere machine draait: laat de verbinding via een SSH-tunnel of een privénetwerk lopen. Kan dat niet, beperk de toegang dan op zijn minst tot dat ene bronadres dat hem werkelijk nodig heeft.

Als het op dit moment gebeurt

Verzamel eerst de meetwaarden uit stap 8, zodat uw melding onderbouwd is: tijdstip met tijdzone, betrokken IP-adres en betrokken poort, gemeten pakketsnelheid met vermelding van de richting. Open daarna een supportticket. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883. Het aanbiederonafhankelijke overzicht van de vervolgstappen geeft Server tegen DDoS-aanvallen beschermen.