FiveM-server beschermen tegen DDoS-aanvallen

Een FiveM-roleplayserver die 's avonds telkens een paar minuten verdwijnt, heeft zelden een hardwareprobleem. Meestal loopt er een aanval, en wel precies op het moment dat de meeste spelers online zijn. Dit artikel laat eerst zien wat u zonder extra kosten zelf kunt afschermen, daarna waar die maatregelen technisch ophouden, en tot slot wat er dan in het netwerk vóór de server moet gebeuren.

Alle informatie hier gaat uit van een FXServer 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. Leg eerst de meetwaarden vast (zie de paragraaf "Vastleggen"), na de aanval zijn ze verdwenen.

Waarom juist FiveM-servers zo vaak worden aangevallen

FiveM-projecten verenigen een aantal eigenschappen die ze tot een gemakkelijk doelwit maken. Ten eerste publiceert een RP-server zijn adres uit zichzelf: de vermelding in de Cfx.re-serverlijst bevat het IP-adres en de poort leesbaar, omdat spelers de server anders niet zouden vinden. Ten tweede zit de spelersgroep vast aan vaste tijden, waardoor een uitval om 20 uur maximaal zichtbaar is. 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 daarbij dat het spelverkeer over UDP loopt. 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. Wat een DDoS-aanval technisch gezien precies is, legt het artikel Wat is een DDoS-aanval? uit.

De poorten waar het werkelijk om gaat

Een FXServer bindt zich standaard aan één enkele poort, en wel op beide protocollen. In de server.cfg:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

Deze twee regels vormen het volledige aanvalsoppervlak van het spel zelf:

• 30120 UDP draagt het lopende spelverkeer: positiegegevens, synchronisatie, spraakoverdracht.
• 30120 TCP draagt de verbindingsopbouw en de ingebouwde HTTP-endpoints van de FXServer: /info.json, /players.json en /dynamic.json.
• 40120 TCP is de standaardinstelling voor de webinterface van txAdmin.
• 3306 TCP hoort bij de database die elk ESX- of QBCore-framework nodig heeft.
• 22 TCP is uw SSH-toegang.

Van deze vijf poorten horen er precies twee op het open internet. De andere drie vormen de meest gemaakte vermijdbare fout op FiveM-servers.

Wat u zelf kunt doen voordat u geld uitgeeft

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

1. Inventarisatie: wat luistert er eigenlijk?

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:30120 en [::]:30120 betekenen "vanaf het hele internet bereikbaar", 127.0.0.1:3306 betekent "alleen lokaal" en heeft geen firewallregel nodig. Naast het spel duiken daar vaak ook txAdmin, MariaDB, een webserver en een allang vergeten voicedienst op. Het beeld van de aanvaller levert een poortscan van buitenaf:

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

2. Alleen openlaten wat het spel echt nodig heeft

Voor FiveM volstaan twee openstellingen naar buiten, al het andere wordt beperkt of helemaal niet gepubliceerd. Met UFW ziet dat er zo uit, en wel precies in deze volgorde, zodat u zichzelf niet buitensluit:

ufw allow 22/tcp comment 'SSH'
ufw allow 30120/tcp comment 'FiveM'
ufw allow 30120/udp comment 'FiveM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Vervang 203.0.113.10 door uw eigen adres. Bij een aansluiting met een wisselend adres is dat onpraktisch; de betere weg staat verderop. De volledige handleiding inclusief reddingsweg vindt u onder UFW-firewall instellen zonder uzelf buiten te sluiten.

De database hoort in geen geval op het open internet. Controleer in /etc/mysql/mariadb.conf.d/50-server.cnf of daar staat:

bind-address = 127.0.0.1

3. De querypoort en de HTTP-endpoints afschermen

De FXServer beantwoordt op het TCP-deel van 30120 HTTP-verzoeken, zonder dat iemand het spel hoeft te starten. Bekijk wat hij daar uitlevert:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600

/players.json somt de verbonden spelers op, inclusief hun identificaties. Dat is handig voor statuspagina's en Discord-bots, maar ook een uitnodiging: het endpoint laat zich onbeperkt vaak opvragen, elke opvraag kost uw server werk, en de inhoud verraadt een aanvaller wanneer een aanval loont. Twee tegenmaatregelen kosten niets. Ten eerste horen de endpoints van de spelers niet in het antwoord thuis, en daarvoor volstaat één regel in de server.cfg:

sv_endpointPrivacy true

Ten tweede: laat uw Discord-bot of uw website de spelersstand niet vanuit de bezoeker opvragen, maar sla het resultaat op vaste intervallen tussentijds op. Daarmee veroorzaakt een druk bezochte statuspagina één opvraag per interval in plaats van één per bezoeker.

4. txAdmin niet op het open internet zetten

Poort 40120 is een webinterface met volledige toegang tot uw server. Hebt u geen vast IP-adres voor de vrijgave, laat de poort dan van buitenaf dicht en bereik hem via een SSH-tunnel; daarna opent u lokaal http://127.0.0.1:40120:

ssh -N -L 40120:127.0.0.1:40120 root@UW.SERVER.IP.ADRES

5. Verbindings- en pakketsnelheden begrenzen

Tegen kleine aanvallen en slordige bots helpt een bovengrens per bronadres:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 12 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name fivem_udp --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

De eerste regel verwerpt nieuwe TCP-verbindingen zodra één adres er meer dan twaalf tegelijk open heeft staan, de tweede verwerpt UDP-pakketten zodra er blijvend meer dan 600 pakketten per seconde uit dezelfde bron komen. Beide getallen zijn startwaarden, geen waarheden: een volle RP-server produceert duidelijk meer pakketten dan een lege, 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

En 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: 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

6. De vermelding in de serverlijst

Hier loont eerlijkheid meer dan wensdenken: uw IP-adres laat zich niet geheimhouden. Iedere speler die ooit verbonden is geweest, kent het, en de vermelding in de lijst publiceert het sowieso. Wie de openbare vermelding niet nodig heeft omdat het project puur via Discord en directe verbinding loopt, kan die met sv_master1 "" uitschakelen. Dat kost echter alle zichtbaarheid voor nieuwe spelers en helpt alleen tegen de meest gemakzuchtige aanvaller.

Werkzamer zijn twee gewoonten. Publiceer het kale IP-adres nergens zelf, dus niet in het Discord-kanaal en niet op de projectpagina. En laat uw spelers via een hostnaam verbinden, zodat u in geval van nood het adres kunt wisselen zonder dat alle verwijzingen breken. De klassieker daarbij zijn oude DNS-records: een vergeten A-record naar het vorige adres maakt elke wissel zinloos.

7. Whitelist en controle bij het verbinden

Een whitelist werkt tegen alles wat de reguliere weg naar binnen gebruikt: trollen, cheatclients en botnets van wegwerpaccounts. U bouwt hem aan serverzijde in het event playerConnecting, waar u de verbinding met de deferrals-functies vasthoudt, de identificatie controleert en pas daarna vrijgeeft. Daar komen een strenge accountcontrole, een realistische bovengrens voor het spelersaantal en een uitgeschakelde ScriptHook bij:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 48
sv_scriptHookAllowed 0

Een RCON-wachtwoord stelt u alleen in als u RCON werkelijk nodig hebt, want die toegang ligt op dezelfde open poort. En één ding moet duidelijk zijn: een whitelist beschermt uw spellogica, niet uw lijn. Een aanvaller die uw server overspoelt, wil helemaal niet meedoen. Zijn pakketten worden geweigerd, maar ze zijn wel aangekomen, en precies daar gaat het om.

8. Netwerkevents aan serverzijde controleren

Veel storingen die als DDoS-aanval worden gemeld, komen voort uit één enkel script. FiveM-resources communiceren via netwerkevents, en een event dat de server ongecontroleerd uitvoert, is een open deur: wie in de client een TriggerServerEvent met willekeurige waarden afvuurt, kan geld aanmaken, voertuigen spawnen of in een lus databasequery's laten lopen totdat de server stilstaat.

Drie regels vangen het grootste deel daarvan af. Registreer met RegisterNetEvent uitsluitend events die werkelijk van de client horen te komen. Vertrouw nooit op waarden die de client meestuurt, maar bepaal de speler aan serverzijde uit source. En begrens hoe vaak een speler hetzelfde event mag afvuren, zeker bij alles met een databasequery. Hapert de server terwijl de lijn rustig is, dan toont resmon 1 in de clientconsole de rekentijd per resource, en meestal staat de schuldige bovenaan.

9. Vastleggen, zodat u in geval van nood cijfers hebt

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 dinsdagavond. Met apt-get install -y vnstat sysstat loopt de meting permanent mee. Tijdens een incident volstaan vier commando's: pakketten per seconde, het aantal verworpen pakketten op de interface, kernelmeldingen en een korte steekproef van het verkeer.

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 port 30120 -c 200 -q

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.

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. Aanvallen op FiveM-projecten liggen doorgaans tussen 5 en 50 Gbit/s, dus op het vijf- tot vijftigvoudige van uw lijn. Of uw iptables-regel daarachter goed is, doet dan niet meer ter zake, want de pakketten van uw spelers komen al eerder niet door.

De tweede grootheid is de pakketsnelheid, en die slaat vaak eerder toe dan de bandbreedte. 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. Een aanval die uw lijn nog niet eens voor een derde vult, kan uw server dus toch platleggen, omdat de rekentijd opgaat aan het verwerpen. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch was alles weg".

Ter oriëntatie, welke ordes van grootte werkelijk voorkomen: op KernelHost-servers zijn onder meer een aanval met meer dan 473,4 Gbit/s bij meer dan 41,5 miljoen pakketten per seconde op een voiceserver en een UDP-flood met meer dan 112,2 Gbit/s op een gameserver weggefilterd. Daarvoor bestaat geen lokale instelling. 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, dus er zijn 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. Het datacenter is maincubes in Frankfurt am Main, Duitsland. 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. Daarvoor is er de Advanced DDoS Protection vanaf € 50,00 per maand, PrePaid en zonder minimale looptijd. 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 in wat op 30120 UDP is toegestaan en wat op 30120 TCP, zonder daarvoor een ticket te schrijven.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen.
• Een beschermingsprofiel dat bij het betreffende spel past. Voor FiveM is er een kant-en-klaar profiel, net zo goed als voor aangepaste en eigen applicaties op willekeurige TCP- of UDP-poorten.

De twee lagen naast elkaar

Voor de meeste FiveM-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 het IP-adres gewisseld en was twee uur later weer offline": de aanvaller haalt het nieuwe adres uit dezelfde bron als het oude, meestal de vermelding in de lijst, een Discord-bot of een oud DNS-record. Een adreswissel levert tijd op, geen oplossing.

"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.

"De server draait, maar alle spelers hebben rubberbanding": dat is vaker een script dan een aanval. Kijk eerst met resmon 1 of een resource de rekentijd opvreet. Blijft sar -n DEV 1 10 onopvallend, dan was het geen DDoS-aanval.

"txAdmin toont honderden mislukte verbindingspogingen": dat is een joinflood, en die raakt de spellogica, niet de lijn. Daartegen werken de whitelist, de accountcontrole en de bovengrens voor verbindingen per bronadres.

"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

Sluit alles behalve 30120 TCP en UDP, houd txAdmin en de database van het open internet weg, begrens verbindingen en pakketsnelheden per bronadres, voer een whitelist en controleer netwerkevents aan serverzijde. Daarmee bent u opgewassen tegen alles wat het zonder noemenswaardige bandbreedte redt. Daarboven beslist uitsluitend het netwerk vóór de server.

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.