FiveM DDoS-bescherming: welke aanvallen er komen en wat ze tegenhoudt

Hoe FiveM-servers worden aangevallen

FXServer ontvangt gameverkeer op één poort voor zowel TCP als UDP, standaard 30120, zoals de regels endpoint_add_tcp en endpoint_add_udp in de voorbeeld-server.cfg laten zien. Dezelfde poort bedient ook HTTP-endpoints zoals /info.json, /players.json en /dynamic.json: een client haalt /info.json op voordat hij joint, en de serverlijst van Cfx.re vraagt de server regelmatig om gegevens zoals spelersaantallen. txAdmin, het webpaneel dat de meeste servers gebruiken, luistert standaard op 40120. Aanvallen richten zich op drie manieren op die onderdelen.

1. Volumetrische UDP-floods op 30120 of op het hele IP. Het doel is de netwerklijn van de server vol te trekken. Zodra de lijn vol is, kan niets op de server nog helpen, omdat de rommel binnenkomt voordat een instelling er iets over te zeggen heeft.
2. Verbindingsfloods: veel TCP-verbindingen of verbindingspogingen naar 30120. Ze verbruiken verbindingsslots, geheugen en CPU, terwijl de lijn zelf er rustig uit kan zien.
3. HTTP-floods (laag 7): geldig ogende verzoeken naar de .json-endpoints of naar de inlogpagina van txAdmin, vaak verstuurd via open proxy's. Elk verzoek is klein, maar er duizenden per seconde beantwoorden houdt de server bezig.

Er is een vierde soort misbruik die geen DDoS is maar wel zo aanvoelt: een verbonden client die via je resources netwerkevents of statuswijzigingen spamt. Dat komt binnen via de normale gameverbinding, dus geen enkel netwerkfilter ziet het.

Wat filtering aan de edge wel en niet doet

DDoS-filtering aan de rand van het netwerk (de edge) betekent dat verkeer voor je IP eerst door een scrubbingnetwerk gaat voordat het de server bereikt. Dat netwerk heeft veel meer capaciteit dan de lijn van één server, dus het kan een volumetrische flood opvangen, pakketten weggooien die niet lijken op het protocol van die poort, en de rest doorsturen.

Waar het goed in is

• Volumetrische UDP- en TCP-floods die je lijn zouden vullen.
• Gespoofte en misvormde pakketten, en verkeer naar poorten die je niet gebruikt.
• Grote aantallen verbindingen vanaf één bron, voor zover het filter die kan herkennen.

Wat het niet voor je kan doen

• Een IP beschermen dat de aanvaller via een andere route bereikt, bijvoorbeeld een tweede adres van dezelfde server of een proxy die zonder filtering doorstuurt naar de origin.
• Elke bot van een echte speler onderscheiden als de bot het protocol correct spreekt. Een deel van die belasting bereikt de server nog steeds, en daarom bestaan de limieten aan serverzijde hieronder.
• Misbruik stoppen van spelers die al verbonden zijn. Eventspam en exploits in resources zijn een scriptprobleem.
• Diensten beschermen die je open hebt laten staan: SSH, een databasepoort, of txAdmin open voor de hele wereld.

Instellingen in server.cfg

Deze regels komen uit de referentie van servercommando's. Ze kosten niets en maken de verbindings- en HTTP-floods die langs de edge komen goedkoper om op te vangen.

# game traffic on one port, TCP and UDP (the defaults)
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# concurrent TCP connections allowed per IP (default 16)
net_tcpConnLimit 16

# block IPs whose HTTP requests carry a 'Via' header
set sv_requestParanoia 1

# hide player IP addresses from public reports
set sv_endpointPrivacy true

# leave RCON off unless you use it
#set rcon_password ""

• net_tcpConnLimit begrenst het aantal gelijktijdige TCP-verbindingen per IP. De standaardwaarde is 16. Verlaag die alleen als je weet dat geen legitieme spelers een adres delen; spelers achter één router of achter carrier-NAT delen een IP.
• sv_requestParanoia loopt van 0 (uit, de standaard) tot 3. Niveau 1 blokkeert IP's die een Via-header sturen, die proxy's toevoegen aan de verzoeken die ze doorsturen. Niveau 2 blokkeert ook verzoeken met een Upgrade-Insecure-Requests-header, en daar valt iedereen onder die een .json-endpoint in een browser opent. Niveau 3 sluit daarnaast de socket. Begin op 1.
• sv_endpointPrivacy true verbergt de IP-adressen van spelers in de openbare rapporten van de server, zodat je spelers niet het volgende doelwit worden.

Servers op FiveM for GTAV Enhanced krijgen daarnaast token-bucket-ratelimiters voor handshakes, de HTTP-endpoints, net events, state bags en RCON. Elke limiter heeft een rate (tokens per seconde) en een burst (maximum aantal tokens); een verzoek waarvoor geen token meer over is, wordt door de limiter tegengehouden. De standaardwaarden zijn onder meer 4 per seconde met een burst van 10 voor http_info en http_players, en 50 per seconde met een burst van 200 voor netEvent. De referentie vermeldt deze commando's als exclusief voor de Enhanced-build.

# FiveM for GTAV Enhanced only
# set rateLimiter_<name>_rate  <tokens per second>
# set rateLimiter_<name>_burst <maximum tokens>
set rateLimiter_netEvent_rate 100
set rateLimiter_netEvent_burst 400

Pas ze alleen aan als je console laat zien dat een limiter verkeer weggooit dat je kunt benoemen. Wie netEvent verhoogt om een drukke resource te laten werken, geeft ook een spammende client meer ruimte.

Firewallregels op de server

Sluit alles wat spelers niet nodig hebben. Spelers hebben 30120 via TCP en UDP nodig. Jij hebt SSH en txAdmin nodig, en verder niemand. Op Ubuntu of Debian met ufw sta je je eigen SSH-regel toe voordat je ufw enable uitvoert, anders sluit je jezelf buiten:

# replace 203.0.113.10 with your own public IP
ufw default deny incoming
ufw default allow outgoing
ufw allow from 203.0.113.10 to any port 22 proto tcp
ufw allow 30120/tcp
ufw allow 30120/udp
ufw allow from 203.0.113.10 to any port 40120 proto tcp
ufw enable
ufw status verbose

Blokkeer de backend van Cfx.re niet. De serverlijst bevraagt je server vanaf de adressen die gepubliceerd staan op static.cfx.re/ips.txt, en Cfx.re zegt dat een strikte firewall of een DDoS-filter ze allemaal moet toestaan. Nieuwe adressen worden minstens een maand voordat er verkeer van komt aan de lijst toegevoegd, dus synchroniseer de lijst volgens een vast schema.

De poort van txAdmin is 40120, tenzij je die wijzigt met TXHOST_TXA_PORT, en volgens de omgevingsreferentie van txAdmin mag het geen 30120 zijn. Als je IP vaak verandert, houd 40120 dan helemaal dicht en bereik het paneel via een SSH-tunnel:

# open txAdmin through SSH instead of the internet
ssh -L 40120:127.0.0.1:40120 root@your-server-ip
# then browse to http://localhost:40120

Op Windows Server gaan dezelfde regels in Windows Defender Firewall: sta 30120 TCP en UDP toe vanaf elk adres, en 3389 en 40120 alleen vanaf je eigen adres.

Het origin-IP verborgen houden

Filtering werkt alleen als aanvalsverkeer erdoorheen moet. Als de bescherming op het eigen IP van de server zit, wordt elk pakket naar dat IP gefilterd en is verbergen minder belangrijk. Zet je in plaats daarvan een aparte proxy voor de server, dan moet het echte adres (de origin) geheim blijven, want een aanvaller die het kent, kan de proxy overslaan.

De handleiding voor de proxy-opzet van Cfx.re beschrijft twee proxy's: een HTTPS-proxy voor het connect-endpoint, en een kale TCP- en UDP-proxy op overeenkomende poorten voor het gameverkeer. Met beide op hun plek zorgen deze convars ervoor dat FXServer zijn eigen adres niet meer bekendmaakt:

# stop the server list from advertising the real IP
set sv_forceIndirectListing true

# the hostname the server list backend should query
set sv_listingHostOverride "play.example.com"

# your proxy addresses in CIDR notation (trusted for X-Real-IP)
set sv_proxyIPRanges "198.51.100.7/32"

# the UDP endpoint players are given: the proxy, not the origin
set sv_endpoints "198.51.100.7:30120"

Spelers verbinden dan met connect "https://play.example.com/"; de handleiding merkt op dat een losse host zoals play.example.com in plaats daarvan naar http://play.example.com:30120/ verwijst. Dicht daarna de gebruikelijke lekken:

• Oude DNS-records. Als een domein ooit direct naar de origin wees, ga er dan van uit dat het adres bekend is en wijzig het zodra de proxy live is.
• Andere diensten op hetzelfde IP: een website, een Discord-bot, een database of een mailserver.
• Resources die externe API's of webhooks aanroepen. Die verzoeken komen van het origin-IP en zijn zichtbaar voor wie de andere kant beheert.
• Directe connect-adressen die in Discord of op forums zijn gepost voordat je achter de proxy ging.

Wat je een host vraagt voordat je koopt

1. Staat filtering altijd aan, of begint het pas nadat een aanval is gedetecteerd? Als het later begint, hoe lang duurt dat dan?
2. Dekt het UDP op gamepoorten, of vooral webverkeer? FiveM heeft UDP op 30120 gefilterd nodig zonder dat de handshake breekt.
3. Wat is de filtercapaciteit, en wat gebeurt er daarboven? Sommige providers null-routen het IP, waardoor je server offline is tot de aanval stopt.
4. Staat er een firewall voor de server die je zelf beheert, per poort en protocol?
5. Kun je zien wanneer een aanval plaatsvond en hoe groot die was? Zonder dat kun je een aanval niet onderscheiden van een bug in een resource.
6. Blijft er genoeg single-thread-CPU-snelheid en RAM over voor de server zelf? Bescherming helpt niet bij een server die al aan zijn limiet zit.

FiveM bij Evorxa

Evorxa-servers staan achter Shield, de DDoS-filtering van Evorxa, met 3 Tbps scrubbingcapaciteit. Servers draaien in één regio, Eygelshoven in Nederland; de CDN-edgelocaties van Shield staan los van die serverregio. De FiveM-hostingpagina toont plannen met gedeelde cores (VPS) en toegewezen high-frequency cores (VDS), vooraf betaald per maand, voor zes maanden of per jaar, met volledige root-toegang voor de instellingen hierboven.

Bronnen

De feiten in deze gids komen van deze pagina's.

1. Cfx.re-docs: Servercommando's (convars, ratelimiters)
2. Cfx.re-docs: Proxy-opzet
3. Cfx.re-docs: Statische IP's (ips.txt)
4. Cfx.re: voorbeeld-server.cfg
5. txAdmin: omgevingsconfiguratie