Skydda RedM-server mot DDoS-attacker

En RedM-server som försvinner mitt i sessionen på kvällen och dyker upp igen tio minuter senare har sällan ett hårdvaruproblem. Oftast pågår en attack mot port 30120, och den pågår precis när flest spelare är online. Det här inlägget visar hur du skyddar en RedM-server mot DDoS-attacker: först det du kan säkra själv utan extra kostnad, därefter den fysiska gränsen för de åtgärderna, och till sist vad som måste hända i nätet framför servern när attacken är större än din ledning.

Alla uppgifter gäller en FXServer med gamename rdr3 under Debian 12, Debian 13, Ubuntu 22.04 LTS eller Ubuntu 24.04 LTS. Kommandona är skrivna för root, som vanlig användare sätter du sudo framför. RedM är Cfx.re:s modifikation av Red Dead Redemption 2 och systerprojektet till FiveM. Båda kör på samma serverprogram, och därför är en del av nätverkstekniken verkligen identisk. Där det gäller står det här i en mening, och den utförliga delen finns i inlägget Skydda FiveM-servern mot DDoS-attacker. Allt övrigt i den här texten är RedM-specifikt.

Om attacken pågår just nu: ändra ingenting i server.cfg nu och starta inte om servern. Säkra först mätvärdena (se avsnittet "Samla mätvärden"), efter attacken är de borta.

Varför RedM-servrar så ofta blir mål för DDoS-attacker

En RedM-server är ett mer lönande mål än spelarantalet låter ana. Skälet är just scenens ringa storlek. I september 2026 räknade offentliga serverlisttrackare runt 2 000 aktiva RedM-servrar med omkring 12 400 samtidiga spelare, mot runt 39 000 FiveM-servrar med omkring 325 000 spelare. Den som slår ut en av 2 000 RedM-servrar tar därmed en betydligt större andel av hela scenen ur nätet än den som träffar en av 39 000 FiveM-servrar. För en angripare som vill skada ett konkurrerande projekt är hävstången alltså ojämförligt större.

Till det kommer communityernas struktur. RedM-roleplay lever på fasta sessioner vid fasta tider, ofta med anmälan och godkännande av karaktären. Ett avbrott klockan 20 träffar inte vilka spelare som helst, utan precis dem som har anmält sig för den kvällen. Många projekt drivs dessutom som hobby med liten budget, hänger på en enda billig server och har ingen andra instans att växla över till. Offentligt dokumenterade fall ur RedM-scenen beskriver attackserier över månader i närmast daglig takt, som har träffat spelservern och den separata voiceservern samtidigt.

Tekniskt tillkommer att speltrafiken går över UDP. UDP är ett anslutningslöst transportprotokoll: det finns ingen uppkoppling som servern skulle kunna kräva, och avsändaradresser går att förfalska. En angripare måste alltså varken gå in på din RedM-server eller tilltala den korrekt för att skapa last. Vad en DDoS-attack är exakt och hur den byggs upp förklarar inlägget Vad är en DDoS-attack?.

Portarna som det faktiskt handlar om

En RedM-server binder sig som standard till en enda port, och det på båda protokollen. I server.cfg står det för det:

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

Raden set gamename rdr3 är den enda som skiljer en RedM-server från en FiveM-server. Saknas den anmäler sig samma FXServer som GTA V-server, och en RedM-klient ansluter inte. RedM har ingen egen query-port och ingen egen RCON-port: serverförfrågan, uppkoppling, speltrafik och RCON löper alla över samma två poster på 30120. Det är den hårda sifferbilden:

Av de fyra nämnda portarna hör exakt två hemma i det öppna nätet: 30120 TCP och 30120 UDP. Port 40120 och port 3306 hör inte hemma där, och SSH på port 22 bör vara begränsad till de egna adresserna. Det är det vanligaste undvikbara felet på RedM-servrar, eftersom många projekt startar med ett färdigt txAdmin-recept och därefter aldrig kontrollerar vad servern erbjuder utåt.

Vad du kan göra själv innan du lägger ut pengar

Det här avsnittet är det längsta, och det är avsiktligt. En rent konfigurerad RedM-server klarar små och medelstora attacker av egen kraft, oavsett hos vem den står. Ordningen är medvetet vald: du mäter först, stänger sedan och begränsar först därefter.

1. Inventering: vad lyssnar egentligen?

Innan du skriver en enda regel tittar du efter vad din server erbjuder utåt. Inte gissa, titta efter:

ss -lntup

Intressant är kolumnen med den lokala adressen. 0.0.0.0:30120 och [::]:30120 betyder "nåbar från hela internet", 127.0.0.1:3306 betyder "bara lokalt" och behöver ingen brandväggsregel. Vid sidan av FXServer dyker det på en RedM-server regelbundet upp txAdmin på 40120, MariaDB på 3306, en webbserver för projektsidan och emellanåt en voicetjänst. Angriparens vy får du med en portskanning utifrån:

nmap -Pn -p- --min-rate 1000 DIN.SERVER.IP.ADRESS

2. Lämna bara 30120 TCP och UDP öppna

För RedM räcker två öppningar utåt, allt annat begränsas eller publiceras inte alls. Med UFW ser det ut så här, och då i exakt den ordningen så att du inte låser ute dig själv:

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

Ersätt 203.0.113.10 med din egen adress. Vid en anslutning med växlande adress är det opraktiskt, den bättre vägen står i nästa avsnitt om txAdmin. Den fullständiga anvisningen inklusive räddningsvägen hittar du i Sätta upp UFW-brandväggen utan att låsa ute dig själv.

Databasen hör under inga omständigheter hemma i det öppna nätet. VORP, RSGCore och RedEM:RP behöver alla en MariaDB eller MySQL, oftast via oxmysql med en anslutningssträng i server.cfg. Den anslutningen går lokalt, porten måste alltså inte vara nåbar utifrån. Kontrollera i /etc/mysql/mariadb.conf.d/50-server.cnf att det står:

bind-address = 127.0.0.1

3. Säkra FXServerns HTTP-slutpunkter

FXServer besvarar HTTP-förfrågningar på TCP-delen av 30120, utan att någon behöver starta Red Dead Redemption 2. Titta efter vad din RedM-server levererar ut där:

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 listar de anslutna spelarna inklusive deras kännetecken, /info.json serverkonfigurationen och de laddade resurserna, /dynamic.json den aktuella beläggningen. Just de tre slutpunkterna är den dokumenterade angreppsvägen på lager 7 mot FiveM- och RedM-servrar: de är nåbara utan inloggning, går att fråga hur ofta som helst, varje förfrågan kostar din server arbete, och innehållet avslöjar för en angripare när en attack lönar sig. Två motåtgärder kostar ingenting. För det första hör spelarnas slutpunkter inte hemma i svaret, och för det räcker en rad i server.cfg:

sv_endpointPrivacy true

Den inställningen döljer dina spelares IP-adresser i serverns publika utdata. För det andra: om din Discord-bot eller din projektsida visar spelarläget, fråga inte slutpunkten från besökaren, utan mellanlagra resultatet med fasta intervall. Därmed skapar en välbesökt statussida en förfrågan per intervall i stället för en per besökare. Vid en liten scen som RedM väger det dubbelt, eftersom en enda serverstatusbot kan vara inbunden i flera Discord-servrar samtidigt.

4. Ta bort txAdmin på port 40120 ur det öppna nätet

txAdmin är det administrationsgränssnitt som ingår i FXServer-bygget för FiveM och RedM, och det lyssnar som standard på 40120 TCP. Bakom det ligger full åtkomst till din server: omstarter, bannlista, spelardatabas, resurshantering. Utan fast IP-adress för öppningen lämnar du porten stängd utifrån och når den via en lokal portvidarebefordran med SSH, därefter öppnar du http://127.0.0.1:40120 i webbläsaren:

ssh -N -L 40120:127.0.0.1:40120 root@DIN.SERVER.IP.ADRESS

Den som lämnar txAdmin öppet publikt får två problem på en gång: en inloggningsruta som det går att köra inloggningsfloder mot, och en tjänst som utför arbete vid varje förfrågan trots att den inte har något med spelet att göra. Vid tveksamhet binder du txAdmin direkt lokalt genom att låta tjänsten bara lyssna på 127.0.0.1.

5. Begränsa anslutnings- och paketfrekvens per källadress

Mot små attacker och orena bottar hjälper en övre gräns per källadress. De två reglerna gäller 30120, alltså båda spelets protokoll:

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

Den första regeln förkastar nya TCP-anslutningar så snart en adress har mer än åtta av dem öppna samtidigt, den andra UDP-paket från varaktigt mer än 500 paket per sekund ur samma källa. Startvärdena ligger här något lägre än på en FiveM-server, eftersom en RedM-server med 32 platser helt enkelt skapar färre legitima anslutningar per adress. Startvärden är dock inga sanningar: en fullsatt RP-kväll skapar betydligt fler paket än en tom server, och den som ställer in för snävt kastar ut sina egna spelare. Mät först en vecka i normal drift.

Två anmärkningar till det. Rena iptables-regler är borta efter en omstart, under Debian och Ubuntu säkrar man dem så här:

apt-get install -y iptables-persistent
netfilter-persistent save

Och under UFW hör sådana regler hemma i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload. En ofta förbisedd flaskhals är dessutom kärnans anslutningsspårning: går den full förkastar servern även legitima paket, och i loggen står "nf_conntrack: table full". Läge och övre gräns visar:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. Säkra de 32 platserna mot anslutningsfloder

En RedM-server har utan OneSync exakt 32 platser. Med OneSync är det 48, därutöver krävs ett Element Club-abonnemang för upp till 1 024 platser. Den siffran är säkerhetsrelevant, för den är den övre gräns som en angripare måste fylla: den som håller 32 anslutningsförsök öppna samtidigt upptar en standardserver fullständigt, utan att en enda spelare faktiskt kommer in i spelet. Hos ett FiveM-projekt med 128 platser ligger samma tröskel fyra gånger så högt.

En RedM-specifik fördel väger delvis upp det: RedM förutsätter en äkta kopia av Red Dead Redemption 2, oavsett om den är köpt via Steam, Epic Games eller Rockstar, dessutom Rockstar-launchern. En anslutningsflod med tusentals engångskonton, som är vanlig vid gratisspel, kostar alltså riktiga pengar här. Attackerna förskjuts därmed till nätverksnivån och till HTTP-slutpunkterna, där ingen spelkopia behövs.

Mot allt som använder den reguljära anslutningsvägen verkar ändå en vitlista. Den genomförs på serversidan i händelsen playerConnecting, där du håller tillbaka anslutningen med deferrals-funktionerna, kontrollerar kännetecknet och först därefter släpper igenom. Till det kommer en sträng kontokontroll och en realistisk övre gräns för antalet spelare:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

sv_authMaxVariance är ett värde från 1 till 5 och anger hur mycket en spelares kännetecken får ändra sig hos en leverantör; 1 är den strängaste inställningen. sv_authMinTrust löper likaså från 1 till 5 och beskriver hur osannolik en förfalskad identitet måste vara; 5 är här det strängaste värdet. Ett RCON-lösenord sätter du bara om du verkligen behöver RCON, för åtkomsten ligger på samma öppna port 30120. Och en sak måste stå klar: en vitlista skyddar din spellogik, inte din ledning. En angripare som översvämmar din server vill inte ansluta alls. Hans paket avvisas, men de har ändå kommit fram, och det är precis poängen.

7. Bedöm posten i RedM-serverlistan rätt

Här lönar sig ärlighet i stället för önsketänkande: din IP-adress går inte att hålla hemlig. RedM använder samma Cfx.re-masterserverinfrastruktur som FiveM, och listposten innehåller anslutningsändpunkten i klartext i fältet connectEndPoints. Via det publika gränssnittet under servers-frontend.fivem.net går det att fråga fram den tillhörande adressen till varje cfx.re-kod, för RedM likaväl som för FiveM. Den som inte behöver den publika posten alls, eftersom projektet enbart går via Discord och direktanslutning, kan föra servern som privat med sv_master1 "": den går då inte längre att ansluta till via serverlistan. Det kostar dock all synlighet för nya spelare, och i en scen med 2 000 servrar är synligheten den egentliga tillväxtmotorn.

Verksammare är två vanor. Publicera aldrig den råa IP-adressen själv, alltså inte i Discord-kanalen och inte på projektsidan. Och anslut dina spelare via ett värdnamn, så att du i nödfall kan byta adress utan att alla hänvisningar bryts. Klassikern är därvid gamla DNS-poster: en bortglömd A-post mot den tidigare adressen gör varje byte verkningslöst.

8. Kontrollera VORP-, RSGCore- och RedEM-händelser på serversidan

Många avbrott som rapporteras som DDoS-attack går tillbaka på ett enda skript. RedM-resurser kommunicerar via nätverkshändelser, och en händelse som servern utför okontrollerat är en öppen dörr: den som i klienten skickar ett TriggerServerEvent med godtyckliga värden kan skapa dollar, spawna hästar eller i en slinga utlösa databasförfrågningar tills servern står stilla. Det träffar alla tre utbredda ramverken lika: VORP Core, som sedan 2020 har den största skriptbasen, RSGCore och det äldre RedEM:RP.

Särskilt utsatta är inventarie- och karaktärsresurserna, eftersom de skriver till databasen vid varje anrop. En händelseslinga som sparar ett inventarieläge tio gånger per sekund belastar en RedM-server hårdare än mången paketflod, och den kommer inifrån, där ingen brandvägg griper.

Tre regler fångar upp merparten av det. Registrera med RegisterNetEvent uteslutande händelser som verkligen ska komma från klienten. Lita aldrig på värden som klienten skickar med, utan fastställ spelaren på serversidan ur source. Och begränsa hur ofta en spelare får utlösa samma händelse, just vid allt med databasförfrågan. Hackar servern medan ledningen är lugn visar resmon 1 i klientkonsolen beräkningstiden per resurs, och oftast står den skyldige överst.

9. Samla mätvärden innan du behöver dem

Det viktigaste steget är det som nästan ingen gör i förväg: att lägga upp en jämförelsegrund så länge allt går normalt. Utan normalvärde kan du efter en händelse inte säga om 40 000 paket per sekund var mycket eller helt enkelt en välbesökt tisdagskväll. Med apt-get install -y vnstat sysstat löper mätningen varaktigt med. Under en händelse räcker fyra kommandon: paketfrekvens per sekund, gränssnittets andel kasserade paket, kärnmeddelanden och ett kort stickprov på trafiken.

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

Vid tcpdump gäller: begränsa alltid med -c, en inspelning under full last belastar en redan överbelastad server ytterligare. Se dessutom efter om lasten ligger på UDP-delen eller på TCP-delen av 30120. UDP-last tyder på en paketflod mot speltrafiken, TCP-last på en flod mot HTTP-slutpunkterna, och båda behöver olika motåtgärder. Hur du tolkar värdena står i Känna igen en DDoS-attack.

Var de här åtgärderna tar slut

Nu den del som ingen server.cfg kan lösa. Alla åtgärder hittills körs på din server, alltså i änden av ledningen. En brandväggsregel beslutar om ett paket som redan har färdats över kabeln. Du kan förkasta det, men du kan inte göra det osänt.

Räkna efter en gång. En typisk spelserver hänger på 1 Gbit/s, det är 125 megabyte per sekund, och ledningen är full så snart någon skickar mer. Attacker mot roleplayprojekt ligger vanligtvis mellan 5 och 50 Gbit/s, alltså på fem till femtio gånger din ledning. Om din iptables-regel bakom är bra spelar då ingen roll längre, eftersom dina spelares paket redan dessförinnan inte kommer fram.

Den andra storheten är paketfrekvensen, och den slår ofta till tidigare än bandbredden. Vid små paket på 64 byte får runt 1,49 miljoner paket per sekund plats i en ledning på 1 Gbit/s. En normal serverkärna bearbetar beroende på processor och nätverkskort några hundratusen av dem innan den börjar förkasta. En attack som inte ens fyller en tredjedel av din ledning kan alltså ändå slå ut din RedM-server, eftersom beräkningstiden går åt till att förkasta. Serverägare upplever det som "belastningen var ju inte ens hög, ändå var allt borta". Just de laggspikarna utan synlig serverlast är den typiska bilden av en attack mot paketfrekvensen.

För att sätta storleksordningarna i sammanhang: på KernelHost-servrar har bland annat en attack med över 473,4 Gbit/s vid över 41,5 miljoner paket per sekund mot en voiceserver och en UDP-flood med över 112,2 Gbit/s mot en spelserver filtrerats bort. För detta finns ingen lokal inställning. Volymetriska attacker måste ta slut i nätet framför servern.

Vad som skiljer RedM från FiveM

Det korta svaret: nätverkstekniken är identisk, omgivningen inte. Båda kör på samma FXServer, båda använder 30120 TCP och UDP, båda förvaltas via txAdmin på 40120. Allt du läser ovan om portar, frekvenser och slutpunkter gäller för båda. Olika är förutsättningarna, och det är just de som avgör hur snabbt en attack verkar:

Tre punkter ur den tabellen är avgörande för försvaret. För det första gör den mindre scenen varje enskild RedM-server värdefullare som mål, eftersom ett avbrott berör en större andel av spelarna. För det andra sänker standardgränsen på 32 platser tröskeln för när en anslutningsflod stänger servern. Och för det tredje finns det färre färdiga skyddsrecept på nätet för RedM än för FiveM, varför många projekt kör med en oförändrad standardkonfiguration. Försvaret är detsamma, utgångsläget är sämre.

Vad KernelHost ställer emot

Det permanenta skyddet som ingår i varje server

KernelHosts DDoS-skydd är uppbyggt i två steg och permanent aktivt, utan att du behöver slå på, beställa eller konfigurera någonting:

• Steg 1: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket. Volymetriska attacker rensas nära sin källa, innan de når datacentret.
• Steg 2: Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main. Direkt framför servern känns protokollspecifika mönster igen och förkastas, paket för paket.

Två egenskaper är avgörande. Skyddet löper permanent och behöver inte först reagera på en attack, det finns alltså inga minuter i början där RedM-servern är borta. Och ingen null-routing används: din IP-adress stannar i nätet, bara de skadliga paketen förkastas. Den som tar bort IP-adressen ur nätet uppnår för din del samma resultat som angriparen. Platsen för filtreringen är Frankfurt am Main. Vilka spel och protokoll som täcks listar DDoS-skydd för spelservrar i realtid.

Advanced DDoS Protection för projekt under ständig beskjutning

Vissa projekt angrips inte tillfälligtvis, utan målinriktat och under flera veckor. För det finns Advanced DDoS Protection från 50,00 EUR i månaden, PrePaid och utan bindningstid. Skillnaden ligger inte i mer kapacitet, utan i kontrollen:

• Dedikerad skydds-IP ur Frankfurt-kärnan, som din server ställs om till inom vårt eget nät. På din sida krävs ingen ombyggnad.
• Skyddsregler per port och protokoll som du hanterar själv i kundportalen: du ställer in separat vad som är tillåtet på 30120 UDP och vad som gäller på 30120 TCP, utan att skriva ett ärende för det. Just hos RedM är den uppdelningen nyttig, eftersom speltrafik och HTTP-slutpunkter ligger på samma portnummer och har helt olika mönster.
• Ändringar slår igenom i realtid, du kan alltså justera under en pågående attack.
• Skyddsprofil som passar applikationen. För Cfx.re-servrar på 30120 finns en passande profil, likaså för modifierade och egna applikationer på valfria TCP- eller UDP-portar.

Båda gäller för servrar som står hos KernelHost. Om ditt RedM-projekt för närvarande körs någon annanstans och regelbundet skjuts ur nätet är flytten rekommendationen, inte en ytterligare produkt.

De två stegen i jämförelse

För de flesta RedM-projekt räcker det inkluderade permanenta skyddet tillsammans med en ren serverkonfiguration. Advanced DDoS Protection är svaret på att någon tar det personligt.

Vanliga fel och lösningar

"Min server dyker inte upp i RedM-serverlistan, jag misstänker en attack": kontrollera först konfigurationen. Saknas set gamename rdr3 anmäler sig FXServer som GTA V-server och syns inte i RedM-listan. Saknas licensnyckeln från portal.cfx.re eller stämmer den inte, kommer posten likaså inte till stånd. En attack ser annorlunda ut: posten ligger kvar, anslutningen misslyckas.

"Hundratals spelare får ett fel vid anslutningen, det ser ut som en flod": oftast är det ett problem med spelversionen. Passar sv_enforceGameBuild inte till det som dina resurser förväntar sig, meddelar klienten "server specified an invalid game enforcement". Sätt det värde som ditt ramverk kräver, vanligtvis 1436 eller 1491, och starta om servern fullständigt.

"Jag bytte IP-adress och var offline igen två timmar senare": angriparen har den nya adressen ur samma källa som den gamla, oftast listposten, en Discord-bot eller en gammal DNS-post. Ett adressbyte är tidsvinst, ingen lösning.

"Mina iptables-regler griper inte": tre orsaker är vanliga. Reglerna står bakom UFW-kedjorna och nås aldrig, de var borta efter den senaste omstarten (då hjälper netfilter-persistent save eller en post i /etc/ufw/before.rules), eller så är attacken volymetrisk och regeln arbetar korrekt vid en ledning som redan är full. Kontrollera med iptables -L INPUT -n -v om träffräknarna stiger. Stannar de på noll nås regeln inte.

"Servern körs, men alla spelare har gummibandseffekter": det är oftare ett skript än en attack. Se först efter med resmon 1 om en resurs äter upp beräkningstiden, och kontrollera ditt ramverks inventarie- och karaktärsresurser. Förblir sar -n DEV 1 10 oanmärkningsvärt var det ingen DDoS-attack.

"txAdmin visar hundratals misslyckade anslutningsförsök": det är en anslutningsflod och den träffar spellogiken, inte ledningen. Mot det verkar vitlista, kontokontroll via sv_authMinTrust och den övre gränsen för anslutningar per källadress.

"Min tidigare leverantör spärrade min IP-adress": det är null-routing. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i ytterligare timmar efteråt. Fråga vid tveksamhet efter om det filtreras eller null-routas. Svaret avgör mer om din tillgänglighet än någon hårdvaruuppgift.

"I tcpdump ser jag inget anmärkningsvärt": om trafiken redan filtreras i nätet framför kommer det som väntat ingenting fram till servern. Det är normalfallet vid fungerande filtrering. Omvänt gäller: är ledningen mättad når du under vissa omständigheter inte ens SSH-sessionen som du ville mäta med. Använd då VNC-konsolen i kundportalen, som fungerar oberoende av gästsystemets nätverk.

Kort sammanfattat

• En RedM-server behöver exakt två öppna portar: 30120 TCP och 30120 UDP, satta via endpoint_add_tcp och endpoint_add_udp. Någon egen query-port eller RCON-port finns inte.
• txAdmin på 40120 TCP och databasen på 3306 TCP hör inte hemma i det öppna nätet, utan på den egna adressen respektive på 127.0.0.1.
• sv_endpointPrivacy true tar bort spelarnas IP-adresser ur de publika utdata, och ett mellanlagrat serverläge tar last från /players.json, den dokumenterade angreppsvägen på lager 7 mot Cfx.re-servrar.
• En RedM-server har utan OneSync 32 platser, med OneSync 48 och med Element Club upp till 1 024. Ju färre platser, desto billigare är en anslutningsflod, och desto viktigare är vitlista och kontokontroll.
• RedM och FiveM kör på samma FXServer, åtskilda enbart av set gamename rdr3. Nätverksförsvaret är därför identiskt, omgivningen inte: runt 2 000 RedM-servrar mot runt 39 000 FiveM-servrar gör varje enskilt RedM-projekt till det värdefullare målet.
• Lokala brandväggsregler tar slut där ledningen är full: 1 Gbit/s är 125 megabyte per sekund, och vid paket på 64 byte får runt 1,49 miljoner paket per sekund plats i den. Allt däröver måste ta slut i nätet framför servern.
• Hos KernelHost ingår det permanenta skyddet i två steg i varje serverpaket, aktivt från leveransen och utan null-routing. Den som vill styra filtreringen själv får med Advanced DDoS Protection från 50,00 EUR i månaden en dedikerad skydds-IP och egna regler per port och protokoll.

Körs ditt RedM-projekt redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå avvikelser öppnar du ett supportärende, så att filterreglerna för din IP-adress justeras. Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883.