Proteggere un server FiveM dagli attacchi DDoS

Un server roleplay FiveM che ogni sera sparisce per qualche minuto raramente ha un problema hardware. Nella maggior parte dei casi è in corso un attacco, e per giunta proprio nel momento in cui è collegato il maggior numero di giocatori. Questo articolo mostra prima che cosa puoi mettere in sicurezza da solo senza spendere nulla, poi dove queste misure si fermano dal punto di vista tecnico e infine che cosa deve succedere nella rete, prima del server.

Tutte le indicazioni si riferiscono a un FXServer 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.

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

Perché proprio i server FiveM vengono attaccati così spesso

I progetti FiveM mettono insieme diverse caratteristiche che ne fanno un bersaglio comodo. Primo, un server RP pubblica il proprio indirizzo di sua iniziativa: la voce nella lista server di Cfx.re contiene indirizzo IP e porta in chiaro, altrimenti i giocatori non riuscirebbero a trovarlo. Secondo, il pubblico è legato a orari fissi, quindi un disservizio alle 20 è quello che si nota di più. Terzo, ci sono la concorrenza fra progetti, i giocatori bannati e i conflitti interni, e un attacco non costa a chi lo lancia né competenze né soldi degni di nota.

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

Le porte di cui si tratta davvero

Di serie un FXServer 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"

Queste due righe sono tutta la superficie di attacco del gioco vero e proprio:

• 30120 UDP trasporta il traffico di gioco in corso: dati di posizione, sincronizzazione, trasmissione vocale.
• 30120 TCP trasporta l'apertura della connessione e gli endpoint HTTP integrati nell'FXServer: /info.json, /players.json e /dynamic.json.
• 40120 TCP è il valore predefinito per l'interfaccia web di txAdmin.
• 3306 TCP appartiene al database di cui ha bisogno qualsiasi framework ESX o QBCore.
• 22 TCP è il tuo accesso SSH.

Di queste cinque porte, esattamente due devono stare sulla rete aperta. Le altre tre sono l'errore evitabile più frequente sui server FiveM.

Che cosa puoi fare da solo prima di spendere

Questa è la sezione più lunga, e non per caso. Un server configurato bene regge con le proprie forze gli attacchi piccoli e medi, a prescindere da chi lo ospita.

1. Inventario: che cosa è 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 al gioco spesso compaiono anche txAdmin, MariaDB, un server web e un servizio vocale dimenticato da tempo. 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 aperto solo ciò di cui il gioco ha davvero bisogno

A FiveM 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 '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

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 più avanti. 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. Verifica in /etc/mysql/mariadb.conf.d/50-server.cnf che ci sia scritto:

bind-address = 127.0.0.1

3. Metti in sicurezza la porta di query e gli endpoint HTTP

Sulla parte TCP della 30120 l'FXServer risponde a richieste HTTP senza che nessuno debba avviare il gioco. Guarda che cosa consegna lì:

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 elenca i giocatori collegati insieme ai loro identificatori. Comodo per le pagine di stato e per i bot Discord, ma anche un invito: l'endpoint si può 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 in server.cfg:

sv_endpointPrivacy true

Secondo: se il tuo bot Discord o il tuo sito 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.

4. Non esporre txAdmin sulla rete aperta

La porta 40120 è un'interfaccia web con accesso completo al tuo server. Se non hai un indirizzo IP fisso da autorizzare, lascia la porta chiusa verso l'esterno e raggiungila attraverso un tunnel SSH; poi apri in locale http://127.0.0.1:40120:

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

5. Limita connessioni e frequenza dei pacchetti

Contro gli attacchi piccoli e i bot fatti male aiuta un limite massimo per indirizzo sorgente:

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

La prima regola scarta le nuove connessioni TCP non appena un indirizzo ne tiene aperte più di dodici contemporaneamente; la seconda scarta i pacchetti UDP oltre i 600 pacchetti al secondo sostenuti dalla stessa sorgente. Entrambi i numeri sono valori di partenza, non verità assolute: un server RP pieno produce molti più pacchetti di uno 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. La voce nella lista server

Qui conviene l'onestà invece dei desideri: il tuo indirizzo IP non si può tenere segreto. Lo conosce ogni giocatore che si è collegato anche una sola volta, e la voce nella lista lo pubblica comunque. Chi non ha bisogno della voce pubblica, perché il progetto vive solo di Discord e connessione diretta, può disattivarla con sv_master1 "". Questo però costa tutta la visibilità verso i nuovi giocatori e serve soltanto contro il più pigro degli aggressori.

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.

7. Whitelist e controllo all'ingresso

Una whitelist funziona contro tutto ciò che passa dalla normale via di ingresso: troll, client con cheat, botnet fatte di account usa e getta. 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, un limite realistico di giocatori e lo ScriptHook disattivato:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 48
sv_scriptHookAllowed 0

Imposta una password RCON solo se ti serve davvero RCON, perché quell'accesso si trova sulla stessa porta aperta. 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.

8. Verifica gli eventi di rete lato server

Molti disservizi segnalati come attacco DDoS dipendono da un singolo script. Le risorse FiveM 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 denaro, far comparire veicoli oppure scatenare interrogazioni al database in un ciclo, fino a fermare il server.

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. Registrare i log, per avere dati in caso di emergenza

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. 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. Come interpretare i valori lo trovi in Riconoscere un attacco DDoS.

Dove queste misure si fermano

Adesso la parte che nessun file di configurazione 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 FiveM 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, 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".

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 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 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 datacenter è maincubes a Francoforte sul Meno, in Germania. Quali giochi e protocolli siano coperti lo elenca l'articolo Protezione DDoS per game server in tempo reale.

Advanced DDoS Protection per progetti sotto attacco 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 che cosa è permesso sulla 30120 UDP e che cosa sulla 30120 TCP, senza dover aprire un ticket.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro anche durante un attacco in corso.
• Profilo di protezione adatto al singolo gioco. Per FiveM esiste un profilo già pronto, così come per applicazioni modificate e proprie su porte TCP o UDP a piacere.

I due livelli a confronto

Per la maggior parte dei progetti FiveM 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

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

Chiudi tutto tranne la 30120 TCP e UDP, tieni txAdmin e il database fuori dalla rete aperta, limita connessioni e frequenza dei pacchetti per indirizzo sorgente, gestisci una whitelist e verifica gli eventi di rete lato server. Così sei attrezzato contro tutto ciò che non ha bisogno di banda degna di nota. Oltre quella soglia decide soltanto la rete davanti al server.

Se il tuo progetto 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.