Proteggere un server RedM dagli attacchi DDoS

Un server RedM che la sera sparisce nel bel mezzo della sessione e ricompare dieci minuti dopo raramente ha un problema hardware. Nella maggior parte dei casi è in corso un attacco sulla porta 30120, e parte proprio quando è online il maggior numero di giocatori. Questo articolo mostra come proteggere un server RedM dagli attacchi DDoS: prima quello che puoi mettere in sicurezza da solo senza costi aggiuntivi, poi il limite fisico di queste misure e infine che cosa deve succedere nella rete, prima del server, quando l'attacco è più grande della tua linea.

Tutte le indicazioni si riferiscono a un FXServer con gamename rdr3 su Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS. I comandi sono scritti per root; se lavori come utente normale, anteponi sudo. RedM è la modifica di Red Dead Redemption 2 realizzata da Cfx.re e il progetto gemello di FiveM. Entrambi girano sullo stesso programma server, quindi una parte della tecnica di rete è davvero identica. Dove questo vale, qui lo trovi in una frase e la parte estesa nell'articolo Proteggere un server FiveM dagli attacchi DDoS. Tutto il resto di questo testo è specifico di RedM.

Se l'attacco è in corso proprio adesso: non modificare nulla nella server.cfg e non riavviare il server. Metti prima al sicuro i valori misurati (vedi il paragrafo "Raccogli i dati di misura"), perché dopo l'attacco non ci sono più.

Perché i server RedM diventano così spesso bersaglio di attacchi DDoS

Un server RedM è un bersaglio più conveniente di quanto il suo numero di giocatori lasci pensare. Il motivo è la dimensione della scena, non la sua piccolezza. A settembre 2026 i tracker pubblici delle liste server contavano circa 2.000 server RedM attivi con circa 12.400 giocatori in contemporanea, contro circa 39.000 server FiveM con circa 325.000 giocatori. Chi mette fuori uso uno dei 2.000 server RedM toglie dalla rete una quota nettamente maggiore dell'intera scena rispetto a chi colpisce uno dei 39.000 server FiveM. Per chi attacca e vuole danneggiare un progetto concorrente, la leva è quindi molto più grande.

A questo si aggiunge la struttura delle community. Il roleplay RedM vive di sessioni fisse a orari fissi, spesso con iscrizione e approvazione del personaggio. Un disservizio alle 20 non colpisce giocatori qualsiasi, ma esattamente quelli che si sono iscritti per quella serata. Molti progetti girano inoltre come hobby con un budget ridotto, dipendono da un singolo server economico e non hanno una seconda istanza su cui spostarsi. Casi documentati pubblicamente nella scena RedM descrivono serie di attacchi durate mesi con cadenza quasi quotidiana, che hanno colpito contemporaneamente il server di gioco e il server vocale separato.

Sul piano tecnico si aggiunge il fatto che il traffico di gioco passa da UDP. UDP è un protocollo di trasporto senza connessione: non esiste alcuna apertura di connessione che il server possa pretendere e gli indirizzi mittente si possono falsificare. Chi attacca non deve quindi né entrare nel tuo server RedM né interrogarlo in modo corretto per generare carico. Che cosa sia esattamente un attacco DDoS e come venga costruito lo spiega l'articolo Che cos'è un attacco DDoS?.

Le porte di cui si tratta davvero

Di serie un server RedM si lega a un'unica porta, e lo fa su entrambi i protocolli. Nel file server.cfg:

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

La riga set gamename rdr3 è l'unica che distingue un server RedM da un server FiveM. Se manca, lo stesso FXServer si registra come server GTA V e un client RedM non si collega. RedM non ha una porta di query propria né una porta RCON propria: interrogazione del server, apertura della connessione, traffico di gioco e RCON passano tutti dalle stesse due voci sulla 30120. Questi sono i numeri, senza giri di parole:

Delle quattro porte citate, esattamente due devono stare sulla rete aperta: 30120 TCP e 30120 UDP. La porta 40120 e la porta 3306 non ci devono stare, e SSH sulla porta 22 andrebbe limitata ai tuoi indirizzi. È l'errore evitabile più frequente sui server RedM, perché molti progetti partono da una ricetta txAdmin già pronta e poi non verificano mai che cosa il server offra verso l'esterno.

Che cosa puoi fare da solo prima di spendere soldi

Questa è la sezione più lunga, e non per caso. Un server RedM configurato bene regge con le proprie forze gli attacchi piccoli e medi, a prescindere da chi lo ospita. L'ordine è scelto di proposito: prima misuri, poi chiudi e solo dopo limiti.

1. Ricognizione: che cosa è davvero in ascolto?

Prima di scrivere anche una sola regola, guarda che cosa offre il tuo server verso l'esterno. Non tirare a indovinare, controlla:

ss -lntup

La colonna interessante è quella dell'indirizzo locale. 0.0.0.0:30120 e [::]:30120 significano "raggiungibile da tutta internet", 127.0.0.1:3306 significa "solo in locale" e non richiede alcuna regola firewall. Accanto all'FXServer, su un server RedM compaiono regolarmente anche txAdmin sulla 40120, MariaDB sulla 3306, un server web per la pagina del progetto e di tanto in tanto un servizio vocale. Il punto di vista di chi attacca te lo dà una scansione delle porte dall'esterno:

nmap -Pn -p- --min-rate 1000 IP.DEL.TUO.SERVER

2. Lascia aperte solo la 30120 TCP e la 30120 UDP

A RedM bastano due aperture verso l'esterno, tutto il resto va limitato oppure non pubblicato affatto. Con UFW la cosa si presenta così, e proprio in questo ordine, per non restare chiuso fuori dal tuo server:

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

Sostituisci 203.0.113.10 con il tuo indirizzo. Su una linea con indirizzo variabile la cosa risulta scomoda, e la strada migliore la trovi nel prossimo paragrafo dedicato a txAdmin. La guida completa, via di fuga compresa, è nell'articolo Configurare il firewall UFW senza bloccarsi fuori.

Il database non deve in nessun caso stare sulla rete aperta. VORP, RSGCore e RedEM:RP hanno tutti bisogno di MariaDB o MySQL, di solito tramite oxmysql con una stringa di connessione nella server.cfg. Questa connessione è locale, quindi la porta non deve essere raggiungibile dall'esterno. Verifica in /etc/mysql/mariadb.conf.d/50-server.cnf che ci sia scritto:

bind-address = 127.0.0.1

3. Metti in sicurezza gli endpoint HTTP dell'FXServer

Sulla parte TCP della 30120 l'FXServer risponde a richieste HTTP senza che nessuno debba avviare Red Dead Redemption 2. Guarda che cosa consegna lì il tuo server RedM:

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 elenca i giocatori collegati insieme ai loro identificatori, /info.json la configurazione del server e le risorse caricate, /dynamic.json l'occupazione attuale. Proprio questi tre endpoint sono la via di attacco Layer 7 documentata contro i server FiveM e RedM: sono raggiungibili senza autenticazione, si possono interrogare quante volte si vuole, ogni interrogazione costa lavoro al tuo server e il contenuto rivela a chi attacca quando conviene colpire. Due contromisure non costano nulla. Primo, gli endpoint dei giocatori non devono comparire nella risposta, e per questo basta una riga nella server.cfg:

sv_endpointPrivacy true

Questa impostazione nasconde gli indirizzi IP dei tuoi giocatori nelle uscite pubbliche del server. Secondo: se il tuo bot Discord o la pagina del progetto mostrano il numero di giocatori, non interrogare l'endpoint dal browser del visitatore, ma salva il risultato in cache a intervalli fissi. Così una pagina di stato molto visitata genera un'interrogazione per intervallo invece di una per visitatore. In una scena piccola come quella di RedM questo pesa il doppio, perché un singolo bot di stato può essere integrato contemporaneamente in più server Discord.

4. Togli txAdmin sulla porta 40120 dalla rete aperta

txAdmin è l'interfaccia di amministrazione compresa nella build dell'FXServer per FiveM e RedM, ed è in ascolto di serie sulla 40120 TCP. Dietro c'è l'accesso completo al tuo server: riavvii, lista dei ban, database dei giocatori, gestione delle risorse. Senza un indirizzo IP fisso da autorizzare, lascia la porta chiusa verso l'esterno e raggiungila con un inoltro di porta locale via SSH; poi apri nel browser http://127.0.0.1:40120:

ssh -N -L 40120:127.0.0.1:40120 root@IP.DEL.TUO.SERVER

Chi lascia txAdmin raggiungibile pubblicamente si ritrova due problemi in uno: una maschera di accesso contro cui si possono lanciare flood di login e un servizio che lavora a ogni richiesta, pur non avendo nulla a che fare con il gioco. Nel dubbio lega txAdmin direttamente in locale, facendolo ascoltare solo su 127.0.0.1.

5. Limita connessioni e frequenza dei pacchetti per indirizzo sorgente

Contro gli attacchi piccoli e i bot fatti male aiuta un limite massimo per indirizzo sorgente. Le due regole valgono per la 30120, quindi per entrambi i protocolli del gioco:

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

La prima regola scarta le nuove connessioni TCP non appena un indirizzo ne tiene aperte più di otto contemporaneamente, la seconda scarta i pacchetti UDP oltre i 500 pacchetti al secondo sostenuti dalla stessa sorgente. I valori di partenza sono qui un po' più bassi che su un server FiveM, perché un server RedM con 32 slot genera semplicemente meno connessioni legittime per indirizzo. I valori di partenza non sono però verità assolute: una serata RP piena produce molti più pacchetti di un server vuoto, e chi stringe troppo butta fuori i propri giocatori. Misura prima una settimana di funzionamento normale.

Due avvertenze in proposito. Le semplici regole iptables spariscono dopo un riavvio; su Debian e Ubuntu si salvano così:

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

Con UFW, invece, regole di questo tipo vanno in /etc/ufw/before.rules, altrimenti al prossimo ufw reload spariscono. Un collo di bottiglia spesso trascurato è poi il tracciamento delle connessioni del kernel: se si riempie, il server scarta anche i pacchetti legittimi e nel log compare "nf_conntrack: table full". Valore attuale e limite li mostra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. Metti in sicurezza i 32 slot contro i flood di ingressi

Un server RedM ha senza OneSync esattamente 32 slot. Con OneSync sono 48, e oltre serve un abbonamento Element Club per arrivare fino a 1.024 posti. Questo numero è rilevante per la sicurezza, perché è la soglia massima che chi attacca deve riempire: chi tiene aperti 32 tentativi di ingresso contemporanei occupa completamente un server standard, senza che un solo giocatore arrivi davvero nel gioco. In un progetto FiveM con 128 posti la stessa soglia è quattro volte più alta.

Un vantaggio specifico di RedM compensa in parte: RedM richiede una copia autentica di Red Dead Redemption 2, acquistata su Steam, Epic Games o Rockstar, più il launcher Rockstar. Un flood di ingressi con migliaia di account usa e getta, come è consueto nei giochi gratuiti, qui costa quindi soldi veri. Gli attacchi si spostano perciò sul livello di rete e sugli endpoint HTTP, dove non serve alcuna copia del gioco.

Contro tutto ciò che passa dalla normale via di ingresso, una whitelist funziona comunque. Si realizza lato server nell'evento playerConnecting, dove trattieni la connessione con le funzioni deferrals, verifichi l'identificatore e solo dopo dai il via libera. A questo si aggiungono un controllo severo dell'account e un limite realistico di giocatori:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

sv_authMaxVariance è un valore da 1 a 5 e indica quanto può cambiare l'identificatore di un giocatore presso un fornitore; 1 è l'impostazione più severa. sv_authMinTrust va anch'esso da 1 a 5 e descrive quanto deve essere improbabile un'identità falsificata; qui il valore più severo è 5. Imposta una password RCON solo se ti serve davvero RCON, perché quell'accesso si trova sulla stessa porta aperta 30120. E una cosa deve essere chiara: una whitelist protegge la tua logica di gioco, non la tua linea. Chi inonda il tuo server non ha alcuna intenzione di entrare. I suoi pacchetti vengono rifiutati, ma sono comunque arrivati, ed è esattamente questo il punto.

7. Valuta correttamente la voce nella lista dei server RedM

Qui conviene l'onestà invece dei desideri: il tuo indirizzo IP non si può tenere segreto. RedM usa la stessa infrastruttura di masterserver Cfx.re di FiveM, e la voce della lista contiene nel campo connectEndPoints l'endpoint di connessione in chiaro. Attraverso l'interfaccia pubblica su servers-frontend.fivem.net si può risalire dal codice cfx.re all'indirizzo corrispondente, per RedM esattamente come per FiveM. Chi non ha bisogno della voce pubblica, perché il progetto vive solo di Discord e connessione diretta, può tenere il server come privato con sv_master1 "": in quel caso non è più raggiungibile attraverso la lista dei server. Questo però costa tutta la visibilità verso i nuovi giocatori, e in una scena con 2.000 server la visibilità è il vero motore di crescita.

Più efficaci sono due abitudini. Non pubblicare tu stesso l'indirizzo IP grezzo da nessuna parte, quindi né nel canale Discord né sulla pagina del progetto. E fai collegare i tuoi giocatori tramite un hostname, così all'occorrenza puoi cambiare indirizzo senza rompere tutti i riferimenti. Il classico intoppo sono i vecchi record DNS: un record A dimenticato che punta all'indirizzo precedente rende inutile qualsiasi cambio.

8. Verifica lato server gli eventi di VORP, RSGCore e RedEM

Molti disservizi segnalati come attacco DDoS dipendono da un singolo script. Le risorse RedM comunicano attraverso eventi di rete, e un evento che il server esegue senza controlli è una porta aperta: chi dal client lancia un TriggerServerEvent con valori arbitrari può generare dollari, far comparire cavalli oppure scatenare interrogazioni al database in un ciclo, fino a fermare il server. Questo vale allo stesso modo per tutti e tre i framework diffusi: VORP Core, che dal 2020 ha la base di script più ampia, RSGCore e il più vecchio RedEM:RP.

Particolarmente esposte sono le risorse di inventario e personaggio, perché scrivono nel database a ogni chiamata. Un ciclo di eventi che salva dieci volte al secondo lo stato dell'inventario pesa su un server RedM più di qualche ondata di pacchetti, e arriva dall'interno, dove nessun firewall interviene.

Tre regole intercettano la maggior parte del problema. Registra con RegisterNetEvent soltanto gli eventi che devono arrivare davvero dal client. Non fidarti mai dei valori che il client manda insieme alla richiesta, ricava invece il giocatore lato server da source. E limita quante volte un giocatore può far scattare lo stesso evento, soprattutto in tutto ciò che interroga il database. Se il server va a scatti mentre la linea è tranquilla, resmon 1 nella console del client mostra il tempo di calcolo per ogni risorsa, e di solito il colpevole sta proprio in cima.

9. Raccogli i dati di misura prima di averne bisogno

Il passo più importante è quello che quasi nessuno compie in anticipo: creare una base di confronto mentre tutto funziona normalmente. Senza un valore di riferimento, dopo un incidente non puoi dire se 40.000 pacchetti al secondo fossero tanti oppure semplicemente un martedì sera molto frequentato. Con apt-get install -y vnstat sysstat la misurazione resta sempre attiva. Durante un incidente bastano quattro comandi: frequenza dei pacchetti al secondo, pacchetti scartati dall'interfaccia, messaggi del kernel e un breve campione del traffico.

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

Per tcpdump vale una regola: limita sempre con -c, perché una cattura a pieno carico appesantisce ancora di più un server già sovraccarico. Fai inoltre attenzione a capire se il carico sta sulla parte UDP o sulla parte TCP della 30120. Un carico UDP indica un'ondata di pacchetti contro il traffico di gioco, un carico TCP un'ondata contro gli endpoint HTTP, e le due cose richiedono contromisure diverse. Come interpretare i valori lo trovi in Riconoscere un attacco DDoS.

Dove queste misure si fermano

Adesso la parte che nessuna server.cfg può risolvere. Tutte le misure viste finora girano sul tuo server, quindi all'estremità della linea. Una regola firewall decide di un pacchetto che ha già percorso il cavo. Puoi scartarlo, ma non puoi fare in modo che non sia mai stato spedito.

Fai due conti. Un game server tipico ha una connettività da 1 Gbit/s, cioè 125 megabyte al secondo, e la linea è satura non appena qualcuno spedisce di più. Gli attacchi contro i progetti roleplay si collocano di solito fra 5 e 50 Gbit/s, quindi da cinque a cinquanta volte la tua linea. A quel punto non conta più quanto sia buona la tua regola iptables dietro, perché i pacchetti dei tuoi giocatori si fermano già prima.

La seconda grandezza è la frequenza dei pacchetti, e spesso colpisce prima della banda. Con pacchetti piccoli da 64 byte, in una linea da 1 Gbit/s entrano circa 1,49 milioni di pacchetti al secondo. Un normale kernel di server ne elabora, a seconda di CPU e scheda di rete, qualche centinaio di migliaia prima di cominciare a scartare. Un attacco che non riempie nemmeno un terzo della tua linea può quindi mettere comunque fuori gioco il tuo server RedM, perché il tempo di calcolo se ne va nello scartare. Chi gestisce un server lo vive così: "l'utilizzo non era nemmeno alto, eppure era sparito tutto". Proprio questi lag spike senza carico visibile sul server sono l'aspetto tipico di un attacco sulla frequenza dei pacchetti.

Per dare un ordine di grandezza reale: sui server di KernelHost sono stati filtrati, fra gli altri, un attacco da oltre 473,4 Gbit/s con oltre 41,5 milioni di pacchetti al secondo contro un server vocale e un UDP flood da oltre 112,2 Gbit/s contro un game server. Per casi del genere non esiste alcuna impostazione locale. Gli attacchi volumetrici devono finire nella rete, prima del server.

Che cosa cambia in RedM rispetto a FiveM

La risposta breve: la tecnica di rete è identica, il contesto no. Entrambi girano sullo stesso FXServer, entrambi usano la 30120 TCP e UDP, entrambi si amministrano con txAdmin sulla 40120. Tutto quello che leggi qui sopra su porte, frequenze ed endpoint vale per entrambi. Diverse sono le condizioni al contorno, e sono proprio quelle a decidere quanto in fretta un attacco fa effetto:

Tre punti di questa tabella sono decisivi per la difesa. Primo, la scena più piccola rende ogni singolo server RedM più prezioso come bersaglio, perché un disservizio riguarda una quota maggiore dei giocatori. Secondo, il limite standard di 32 slot abbassa la soglia oltre la quale un flood di ingressi chiude il server. E terzo, per RedM si trovano in rete meno ricette di protezione già pronte che per FiveM, motivo per cui molti progetti girano con una configurazione standard mai modificata. La difesa è la stessa, la situazione di partenza è peggiore.

Che cosa mette davanti KernelHost

La protezione permanente inclusa su ogni server

La protezione DDoS di KernelHost è costruita su due livelli ed è permanentemente attiva, senza che tu debba attivare, ordinare o configurare nulla:

• Livello 1: 17 Tbps di capacità di mitigazione nella rete di scrubbing globale. Gli attacchi volumetrici vengono ripuliti vicino alla loro origine, prima che raggiungano il datacenter.
• Livello 2: filtraggio Arbor in tempo reale da 3,2 Tbps a Francoforte sul Meno. Subito davanti al server vengono riconosciuti e scartati gli schemi specifici di protocollo, pacchetto per pacchetto.

Due caratteristiche sono decisive. La protezione è sempre attiva e non deve prima reagire a un attacco, quindi non ci sono minuti iniziali in cui il server RedM sparisce. E non viene usato il null-routing: il tuo indirizzo IP resta in rete e vengono scartati solo i pacchetti dannosi. Chi toglie l'indirizzo IP dalla rete ottiene per te lo stesso risultato di chi attacca. Il luogo del filtraggio è Francoforte sul Meno. Quali giochi e protocolli siano coperti lo elenca Protezione DDoS per game server in tempo reale.

Advanced DDoS Protection per progetti attaccati di continuo

Certi progetti non vengono colpiti ogni tanto, ma in modo mirato e per settimane. Per questi casi c'è la Advanced DDoS Protection a partire da 50,00 € al mese, PrePaid e senza durata minima. La differenza non sta in una capacità maggiore, ma nel controllo:

• IP di protezione dedicato dal core di Francoforte, sul quale il tuo server viene spostato all'interno della nostra rete. Dalla tua parte non serve alcuna modifica.
• Regole di protezione gestibili da te per porta e protocollo nell'area clienti: imposti separatamente che cosa è permesso sulla 30120 UDP e che cosa sulla 30120 TCP, senza dover aprire un ticket. Proprio su RedM questa separazione è utile, perché traffico di gioco ed endpoint HTTP stanno sullo stesso numero di porta e hanno schemi completamente diversi.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro anche durante un attacco in corso.
• Profilo di protezione adatto all'applicazione. Per i server Cfx.re sulla 30120 esiste un profilo adatto, così come per applicazioni modificate e proprie su porte TCP o UDP a piacere.

Entrambe le cose valgono per i server che stanno da KernelHost. Se il tuo progetto RedM gira attualmente altrove e viene buttato giù dalla rete con regolarità, la raccomandazione è il trasferimento, non un prodotto aggiuntivo.

I due livelli a confronto

Per la maggior parte dei progetti RedM basta la protezione permanente inclusa, insieme a una configurazione pulita del server. La Advanced DDoS Protection è la risposta al caso in cui qualcuno se la prenda sul personale.

Errori frequenti e soluzioni

"Il mio server non compare nella lista dei server RedM, sospetto un attacco": verifica prima la configurazione. Se manca set gamename rdr3, l'FXServer si registra come server GTA V e non compare nella lista RedM. Se la chiave di licenza da portal.cfx.re manca o non è corretta, nemmeno in quel caso la voce si crea. Un attacco ha un altro aspetto: la voce resta, è la connessione a fallire.

"Centinaia di giocatori ricevono un errore all'ingresso, sembra un'ondata": di solito è un problema di build di gioco. Se sv_enforceGameBuild non corrisponde a quello che le tue risorse si aspettano, il client segnala "server specified an invalid game enforcement". Imposta il valore richiesto dal tuo framework, di norma 1436 o 1491, e riavvia completamente il server.

"Ho cambiato indirizzo IP e due ore dopo ero di nuovo offline": chi attacca ha preso il nuovo indirizzo dalla stessa fonte del vecchio, di solito la voce nella lista, un bot Discord o un vecchio record DNS. Cambiare indirizzo fa guadagnare tempo, non risolve.

"Le mie regole iptables non funzionano": tre cause sono frequenti. Le regole stanno dopo le catene di UFW e non vengono mai raggiunte, oppure sono sparite con l'ultimo riavvio (allora servono netfilter-persistent save o una voce in /etc/ufw/before.rules), oppure l'attacco è volumetrico e la regola lavora correttamente su una linea che è già satura. Verifica con iptables -L INPUT -n -v se i contatori dei match salgono. Se restano a zero, la regola non viene raggiunta.

"Il server gira, ma tutti i giocatori hanno il rubber banding": più spesso si tratta di uno script che di un attacco. Guarda prima con resmon 1 se una risorsa si sta mangiando il tempo di calcolo, e controlla le risorse di inventario e personaggio del tuo framework. Se sar -n DEV 1 10 resta normale, non era un attacco DDoS.

"txAdmin mostra centinaia di tentativi di connessione falliti": è un flood di ingressi e colpisce la logica di gioco, non la linea. Contro questo funzionano la whitelist, il controllo dell'account tramite sv_authMinTrust e il limite di connessioni per indirizzo sorgente.

"Il mio provider precedente ha bloccato il mio indirizzo IP": quello è null-routing. Il provider protegge così la propria rete, mentre per te il risultato è identico a un attacco riuscito, di solito ancora per ore dopo. Nel dubbio chiedi se filtrano oppure se fanno null-routing. La risposta decide della tua disponibilità più di qualsiasi dato sull'hardware.

"In tcpdump non vedo nulla di anomalo": se il traffico viene già filtrato nella rete a monte, sul server come previsto non arriva nulla. È la situazione normale quando il filtraggio funziona. Vale però anche il contrario: se la linea è satura, può darsi che non ti raggiunga nemmeno la sessione SSH con cui volevi misurare. In quel caso usa la console VNC nell'area clienti, che funziona indipendentemente dalla rete del sistema ospite.

In breve

• Un server RedM ha bisogno di esattamente due porte aperte: 30120 TCP e 30120 UDP, impostate con endpoint_add_tcp e endpoint_add_udp. Una porta di query o una porta RCON proprie non esistono.
• txAdmin sulla 40120 TCP e il database sulla 3306 TCP non devono stare sulla rete aperta, ma rispettivamente sul tuo indirizzo e su 127.0.0.1.
• sv_endpointPrivacy true toglie gli indirizzi IP dei giocatori dalle uscite pubbliche, e uno stato del server salvato in cache toglie carico a /players.json, la via di attacco Layer 7 documentata contro i server Cfx.re.
• Un server RedM ha 32 slot senza OneSync, 48 con OneSync e fino a 1.024 con Element Club. Più piccolo è il numero di slot, più economico è un flood di ingressi, e più importanti diventano whitelist e controllo dell'account.
• RedM e FiveM girano sullo stesso FXServer, distinti soltanto da set gamename rdr3. La difesa di rete è quindi identica, il contesto no: circa 2.000 server RedM contro circa 39.000 server FiveM rendono ogni singolo progetto RedM un bersaglio più prezioso.
• Le regole firewall locali finiscono dove la linea è satura: 1 Gbit/s sono 125 megabyte al secondo, e con pacchetti da 64 byte ci entrano circa 1,49 milioni di pacchetti al secondo. Tutto quello che sta sopra deve finire nella rete, prima del server.
• Da KernelHost la protezione permanente a due livelli è compresa in ogni pacchetto server, attiva dalla consegna e senza null-routing. Chi vuole gestire da solo il filtraggio ottiene con la Advanced DDoS Protection, a partire da 50,00 € al mese, un IP di protezione dedicato e regole proprie per porta e protocollo.

Se il tuo progetto RedM gira già su KernelHost, il filtraggio è attivo senza che tu debba fare nulla. Se noti comunque delle anomalie, apri un ticket di supporto, così le regole di filtraggio per il tuo indirizzo IP vengono affinate. Durante un attacco in corso ci raggiungi anche tramite la chat WhatsApp di emergenza al numero +43 650 8209883.