RedM-server beschermen tegen DDoS-aanvallen

Een RedM-server die 's avonds midden in de sessie verdwijnt en tien minuten later weer opduikt, heeft zelden een hardwareprobleem. Meestal loopt er een aanval op poort 30120, en die loopt precies op het moment dat de meeste spelers online zijn. Dit artikel laat zien hoe u een RedM-server beschermt tegen DDoS-aanvallen: eerst wat u zonder extra kosten zelf kunt afschermen, daarna de fysieke grens van die maatregelen, en tot slot wat er in het netwerk vóór de server moet gebeuren wanneer de aanval groter is dan uw lijn.

Alle gegevens hier gaan uit van een FXServer met gamename rdr3 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. RedM is de Red-Dead-Redemption-2-modificatie van Cfx.re en het zusterproject van FiveM. Beide draaien op hetzelfde serverprogramma, waardoor een deel van de netwerktechniek werkelijk identiek is. Waar dat het geval is, staat het hier in één zin en het uitvoerige deel in het artikel FiveM-server beschermen tegen DDoS-aanvallen. Al het overige in deze tekst is RedM-specifiek.

Loopt de aanval op dit moment: verander nu niets aan de server.cfg en start de server niet opnieuw op. Leg eerst de meetwaarden vast (zie de paragraaf "Meetwaarden verzamelen"), na de aanval zijn ze verdwenen.

Waarom RedM-servers zo vaak het doelwit van DDoS-aanvallen worden

Een RedM-server is een lonender doelwit dan zijn spelersaantal doet vermoeden. De reden is juist de geringe omvang van de scene. In september 2026 telden openbare trackers van serverlijsten ongeveer 2.000 actieve RedM-servers met zo'n 12.400 gelijktijdige spelers, tegenover ongeveer 39.000 FiveM-servers met zo'n 325.000 spelers. Wie één van 2.000 RedM-servers platlegt, haalt daarmee een duidelijk groter deel van de hele scene uit de lucht dan iemand die één van 39.000 FiveM-servers treft. Voor een aanvaller die een concurrerend project wil schaden, is de hefboom dus ongelijk veel groter.

Daar komt de structuur van de communities bij. RedM-roleplay leeft van vaste sessies op vaste tijden, vaak met aanmelding en goedkeuring van het personage. Een uitval om 20 uur treft niet zomaar wat spelers, maar precies degenen die zich voor die avond hebben aangemeld. Veel projecten draaien bovendien als hobby met een klein budget, hangen aan één enkele goedkope server en hebben geen tweede instantie om naar over te schakelen. Openbaar gedocumenteerde gevallen uit de RedM-scene beschrijven aanvalsreeksen over maanden in een bijna dagelijks ritme, die de spelserver en de aparte voiceserver tegelijk hebben getroffen.

Technisch komt daarbij dat het spelverkeer over UDP loopt. UDP is een verbindingsloos transportprotocol: er is geen verbindingsopbouw die de server zou kunnen eisen, en afzenderadressen laten zich vervalsen. Een aanvaller hoeft uw RedM-server dus niet te betreden en hoeft hem ook niet correct aan te spreken om belasting te veroorzaken. Wat een DDoS-aanval precies is en hoe hij wordt opgebouwd, legt het artikel Wat is een DDoS-aanval? uit.

De poorten waar het werkelijk om gaat

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

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

De regel set gamename rdr3 is de enige die een RedM-server van een FiveM-server onderscheidt. Ontbreekt hij, dan meldt dezelfde FXServer zich aan als GTA-V-server en maakt een RedM-client geen verbinding. RedM heeft geen eigen querypoort en geen eigen RCON-poort: serveropvraging, verbindingsopbouw, spelverkeer en RCON lopen allemaal over dezelfde twee vermeldingen op 30120. Dit zijn de harde cijfers:

Van de vier genoemde poorten horen er precies twee op het open internet: 30120 TCP en 30120 UDP. Poort 40120 en poort 3306 horen daar niet, en SSH op poort 22 hoort beperkt te zijn tot de eigen adressen. Dat is de meest gemaakte vermijdbare fout op RedM-servers, omdat veel projecten met een kant-en-klaar txAdmin-recept starten en daarna nooit controleren wat de server naar buiten aanbiedt.

Wat u zelf kunt doen voordat u geld uitgeeft

Dit hoofdstuk is het langste, en dat met opzet. Een netjes geconfigureerde RedM-server houdt kleine en middelgrote aanvallen op eigen kracht uit, ongeacht bij wie hij staat. De volgorde is bewust gekozen: u meet eerst, sluit daarna en begrenst pas als laatste.

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 de FXServer duiken op een RedM-server regelmatig txAdmin op 40120, MariaDB op 3306, een webserver voor de projectpagina en af en toe een voicedienst op. Het beeld van de aanvaller levert een poortscan van buitenaf:

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

2. Alleen 30120 TCP en UDP openlaten

Voor RedM 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 'RedM'
ufw allow 30120/udp comment 'RedM'
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 in de volgende paragraaf over txAdmin. 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. VORP, RSGCore en RedEM:RP hebben alle drie een MariaDB of MySQL nodig, meestal via oxmysql met een verbindingstekenreeks in de server.cfg. Die verbinding loopt lokaal, de poort hoeft dus niet van buitenaf bereikbaar te zijn. Controleer in /etc/mysql/mariadb.conf.d/50-server.cnf of daar staat:

bind-address = 127.0.0.1

3. De HTTP-endpoints van de FXServer afschermen

De FXServer beantwoordt op het TCP-deel van 30120 HTTP-verzoeken, zonder dat iemand Red Dead Redemption 2 hoeft te starten. Bekijk wat uw RedM-server 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
curl -s http://127.0.0.1:30120/dynamic.json

/players.json somt de verbonden spelers op inclusief hun identificaties, /info.json de serverconfiguratie en de geladen resources, /dynamic.json de actuele bezetting. Precies deze drie endpoints vormen de gedocumenteerde aanvalsweg op Layer 7 tegen FiveM- en RedM-servers: ze zijn zonder aanmelding bereikbaar, laten 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

Deze instelling verbergt de IP-adressen van uw spelers in de openbare uitvoer van de server. Ten tweede: wanneer uw Discord-bot of uw projectpagina de spelersstand toont, vraag het endpoint dan niet vanuit de bezoeker op, 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. Bij een kleine scene als RedM weegt dat dubbel, omdat één enkele serverstatus-bot in meerdere Discord-servers tegelijk ingebouwd kan zijn.

4. txAdmin op poort 40120 van het open internet halen

txAdmin is de beheerinterface die in de FXServer-build voor FiveM en RedM zit, en hij luistert standaard op 40120 TCP. Daarachter ligt de volledige toegang tot uw server: herstarts, banlijst, spelersdatabase, resourcebeheer. Hebt u geen vast IP-adres voor de vrijgave, laat de poort dan van buitenaf dicht en bereik hem via een lokale poortdoorschakeling met SSH; daarna opent u in de browser http://127.0.0.1:40120:

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

Wie txAdmin openbaar laat staan, krijgt twee problemen tegelijk: een inlogscherm waartegen aanmeldfloods gereden kunnen worden, en een dienst die bij elk verzoek werk verricht, hoewel hij met het spel niets te maken heeft. Bind txAdmin bij twijfel meteen lokaal, door de dienst alleen op 127.0.0.1 te laten luisteren.

5. Verbindings- en pakketsnelheden per bronadres begrenzen

Tegen kleine aanvallen en slordige bots helpt een bovengrens per bronadres. De twee regels gelden voor 30120, dus voor beide protocollen van het spel:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

De eerste regel verwerpt nieuwe TCP-verbindingen zodra één adres er meer dan acht tegelijk open heeft staan, de tweede verwerpt UDP-pakketten zodra er blijvend meer dan 500 pakketten per seconde uit dezelfde bron komen. De startwaarden liggen hier iets lager dan bij een FiveM-server, omdat een RedM-server met 32 slots eenvoudigweg minder legitieme verbindingen per adres veroorzaakt. Startwaarden zijn echter geen waarheden: een volle RP-avond produceert duidelijk meer pakketten dan een lege server, 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 32 slots tegen joinfloods afschermen

Een RedM-server heeft zonder OneSync precies 32 slots. Met OneSync zijn het er 48, daarboven is een Element-Club-abonnement nodig voor maximaal 1.024 plaatsen. Dat getal is veiligheidsrelevant, want het is de bovengrens die een aanvaller moet vullen: wie 32 toetredingspogingen tegelijk open houdt, bezet een standaardserver volledig, zonder dat één enkele speler werkelijk in het spel aankomt. Bij een FiveM-project met 128 plaatsen ligt dezelfde drempel vier keer zo hoog.

Een RedM-specifiek voordeel compenseert dat gedeeltelijk: RedM veronderstelt een echte kopie van Red Dead Redemption 2, of die nu via Steam, Epic Games of Rockstar is gekocht, plus de Rockstar-launcher. Een joinflood met duizenden wegwerpaccounts, zoals bij gratis spellen gebruikelijk is, kost hier dus echt geld. Aanvallen verschuiven daardoor naar het netwerkniveau en naar de HTTP-endpoints, waar geen kopie van het spel nodig is.

Tegen alles wat de reguliere toetredingsweg gebruikt, werkt niettemin een whitelist. 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 en een realistische bovengrens voor het spelersaantal bij:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

sv_authMaxVariance is een waarde van 1 tot 5 en geeft aan hoe sterk de identificatie van een speler bij een aanbieder mag veranderen; 1 is de strengste instelling. sv_authMinTrust loopt eveneens van 1 tot 5 en beschrijft hoe onwaarschijnlijk een vervalste identiteit moet zijn; 5 is hier de strengste waarde. Een RCON-wachtwoord stelt u alleen in als u RCON werkelijk nodig hebt, want die toegang ligt op dezelfde open poort 30120. En één ding moet duidelijk zijn: een whitelist beschermt uw spellogica, niet uw lijn. Een aanvaller die uw server overspoelt, wil helemaal niet toetreden. Zijn pakketten worden geweigerd, maar ze zijn wel aangekomen, en precies daar gaat het om.

7. De vermelding in de RedM-serverlijst juist inschatten

Hier loont eerlijkheid meer dan wensdenken: uw IP-adres laat zich niet geheimhouden. RedM gebruikt dezelfde Cfx.re-masterserverinfrastructuur als FiveM, en de vermelding in de lijst bevat in het veld connectEndPoints het verbindingsendpoint in leesbare vorm. Via de openbare interface onder servers-frontend.fivem.net laat zich bij elke cfx.re-code het bijbehorende adres opvragen, voor RedM net zo goed als voor FiveM. Wie de openbare vermelding helemaal niet nodig heeft omdat het project puur via Discord en directe verbinding loopt, kan de server met sv_master1 "" als privé voeren: hij is dan via de serverlijst niet meer te betreden. Dat kost echter alle zichtbaarheid voor nieuwe spelers, en in een scene met 2.000 servers is zichtbaarheid de eigenlijke groeimotor.

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.

8. VORP-, RSGCore- en RedEM-events aan serverzijde controleren

Veel storingen die als DDoS-aanval worden gemeld, komen voort uit één enkel script. RedM-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 dollars aanmaken, paarden spawnen of in een lus databasequery's laten lopen totdat de server stilstaat. Dat treft alle drie de gangbare frameworks in gelijke mate: VORP Core, dat sinds 2020 de grootste scriptbasis heeft, RSGCore en het oudere RedEM:RP.

Bijzonder kwetsbaar zijn de inventaris- en personageresources, omdat ze bij elke aanroep naar de database schrijven. Een eventlus die tien keer per seconde een inventarisstand opslaat, belast een RedM-server zwaarder dan menige pakketvloed, en hij komt van binnenuit, waar geen firewall grijpt.

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. Meetwaarden verzamelen voordat u ze nodig 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 een goed bezochte dinsdagavond. Met apt-get install -y vnstat sysstat loopt de meting permanent mee. Tijdens een incident volstaan vier commando's: pakketsnelheden 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. Let er bovendien op of de belasting op het UDP- of op het TCP-deel van 30120 ligt. UDP-belasting wijst op een pakketvloed tegen het spelverkeer, TCP-belasting op een vloed tegen de HTTP-endpoints, en die twee vragen om verschillende tegenmaatregelen. Hoe u de waarden uitleest, staat in DDoS-aanval herkennen.

Waar deze maatregelen ophouden

Nu het deel dat geen enkele server.cfg 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 roleplayprojecten 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 RedM-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". Precies die lag-spikes zonder zichtbare serverbelasting zijn het typische beeld van een aanval op de pakketsnelheid.

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 bij RedM anders is dan bij FiveM

Het korte antwoord: de netwerktechniek is identiek, de omgeving niet. Beide draaien op dezelfde FXServer, beide gebruiken 30120 TCP en UDP, beide worden via txAdmin op 40120 beheerd. Alles wat u hierboven over poorten, snelheden en endpoints leest, geldt voor allebei. Verschillend zijn de randvoorwaarden, en juist die bepalen hoe snel een aanval werkt:

Drie punten uit deze tabel zijn voor de verdediging doorslaggevend. Ten eerste maakt de kleinere scene elke afzonderlijke RedM-server waardevoller als doelwit, omdat een uitval een groter deel van de spelers treft. Ten tweede verlaagt de standaardgrens van 32 slots de drempel waarboven een joinflood de server dichtzet. En ten derde zijn er voor RedM minder kant-en-klare beschermingsrecepten op het net te vinden dan voor FiveM, waardoor veel projecten met een ongewijzigde standaardconfiguratie draaien. De verdediging is dezelfde, de uitgangspositie is slechter.

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 RedM-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. De locatie van de filtering is Frankfurt am Main. 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 gescheiden in wat op 30120 UDP is toegestaan en wat op 30120 TCP, zonder daarvoor een ticket te schrijven. Juist bij RedM is die scheiding nuttig, omdat spelverkeer en HTTP-endpoints op hetzelfde poortnummer liggen en volkomen verschillende patronen hebben.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen.
• Een beschermingsprofiel dat bij de toepassing past. Voor Cfx.re-servers op 30120 bestaat een passend profiel, net zo goed als voor aangepaste en eigen applicaties op willekeurige TCP- of UDP-poorten.

Beide gelden voor servers die bij KernelHost staan. Draait uw RedM-project momenteel ergens anders en wordt het regelmatig uit de lucht geschoten, dan is de verhuizing de aanbeveling, niet een extra product.

De twee lagen naast elkaar

Voor de meeste RedM-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

"Mijn server duikt niet op in de RedM-serverlijst, ik vermoed een aanval": controleer eerst de configuratie. Ontbreekt set gamename rdr3, dan meldt de FXServer zich aan als GTA-V-server en verschijnt hij niet in de RedM-lijst. Ontbreekt de licentiesleutel uit portal.cfx.re of klopt hij niet, dan komt de vermelding evenmin tot stand. Een aanval ziet er anders uit: de vermelding blijft bestaan, de verbinding mislukt.

"Honderden spelers krijgen een fout bij het toetreden, dat lijkt op een vloed": meestal is het een probleem met de spelbuild. Past sv_enforceGameBuild niet bij wat uw resources verwachten, dan meldt de client "server specified an invalid game enforcement". Zet de waarde die uw framework verlangt, gewoonlijk 1436 of 1491, en start de server volledig opnieuw op.

"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, en controleer de inventaris- en personageresources van uw framework. 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 via sv_authMinTrust 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

• Een RedM-server heeft precies twee open poorten nodig: 30120 TCP en 30120 UDP, ingesteld via endpoint_add_tcp en endpoint_add_udp. Een eigen querypoort of RCON-poort bestaat niet.
• txAdmin op 40120 TCP en de database op 3306 TCP horen niet op het open internet, maar op het eigen adres respectievelijk op 127.0.0.1.
• sv_endpointPrivacy true haalt de IP-adressen van de spelers uit de openbare uitvoer, en een tussentijds opgeslagen serverstatus haalt belasting weg bij /players.json, de gedocumenteerde aanvalsweg op Layer 7 tegen Cfx.re-servers.
• Een RedM-server heeft zonder OneSync 32 slots, met OneSync 48 en met Element Club tot 1.024. Hoe kleiner het aantal slots, hoe goedkoper een joinflood, en hoe belangrijker whitelist en accountcontrole.
• RedM en FiveM draaien op dezelfde FXServer, alleen onderscheiden door set gamename rdr3. De netwerkverdediging is daarom identiek, de omgeving niet: ongeveer 2.000 RedM-servers tegenover ongeveer 39.000 FiveM-servers maken elk afzonderlijk RedM-project tot het waardevollere doelwit.
• Lokale firewallregels houden op waar de lijn vol is: 1 Gbit/s is 125 megabyte per seconde, en bij pakketten van 64 byte passen daar ongeveer 1,49 miljoen pakketten per seconde in. Alles daarboven moet in het netwerk vóór de server eindigen.
• Bij KernelHost is de permanente bescherming in twee lagen bij elk serverpakket inbegrepen, vanaf de oplevering actief en zonder null-routing. Wie de filtering zelf wil sturen, krijgt met de Advanced DDoS Protection vanaf 50,00 € per maand een dedicated beschermd IP-adres en eigen regels per poort en protocol.

Draait uw RedM-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.