Protezione DDoS per FiveM: quali attacchi arrivano e cosa li ferma

Come vengono attaccati i server FiveM

FXServer riceve il traffico di gioco su una sola porta, sia TCP sia UDP, 30120 per impostazione predefinita, come mostrano le righe endpoint_add_tcp e endpoint_add_udp nel server.cfg di esempio. La stessa porta serve anche endpoint HTTP come /info.json, /players.json e /dynamic.json: un client scarica /info.json prima di entrare, e la lista dei server di Cfx.re interroga periodicamente il server per dati come il numero di giocatori. txAdmin, il pannello web usato dalla maggior parte dei server, è in ascolto sulla 40120 per impostazione predefinita. Gli attacchi colpiscono queste superfici in tre modi.

1. Flood UDP volumetrici verso la 30120 o verso l'intero IP. L'obiettivo è saturare il collegamento di rete del server. Quando il collegamento è pieno, niente sul server può aiutarti, perché il traffico spazzatura arriva prima che qualsiasi impostazione possa intervenire.
2. Flood di connessioni: molte connessioni TCP o tentativi di connessione verso la 30120. Consumano slot di connessione, memoria e CPU mentre il collegamento in sé può sembrare tranquillo.
3. Flood HTTP (layer 7): richieste dall'aspetto valido verso gli endpoint .json o verso la pagina di login di txAdmin, spesso inviate tramite proxy aperti. Ogni richiesta è piccola, ma rispondere a migliaia di richieste al secondo tiene occupato il server.

Esiste un quarto tipo di abuso che non è un DDoS ma lo sembra: un client connesso che inonda il server di eventi di rete o di cambi di stato attraverso le tue risorse. Arriva tramite la normale connessione di gioco, quindi nessun filtro di rete lo vede.

Cosa fa e cosa non fa il filtraggio edge

Filtraggio DDoS sul bordo della rete significa che il traffico diretto al tuo IP passa attraverso una rete di scrubbing prima di raggiungere il server. Quella rete ha molta più capacità del collegamento di un singolo server, quindi può assorbire un flood volumetrico, scartare i pacchetti che non somigliano al protocollo usato su quella porta e inoltrare il resto.

Cosa gestisce bene

• Flood UDP e TCP volumetrici che saturerebbero il tuo collegamento.
• Pacchetti falsificati (spoofed) e malformati, e traffico verso porte che non usi.
• Grandi quantità di connessioni da una singola sorgente, nei limiti di ciò che il filtro riesce a riconoscere.

Cosa non può fare per te

• Proteggere un IP che l'attaccante raggiunge per un'altra strada, per esempio un secondo indirizzo dello stesso server o un proxy che inoltra il traffico all'origine senza filtrarlo.
• Distinguere ogni bot da un giocatore reale quando il bot parla correttamente il protocollo. Parte di quel carico arriva comunque al server, ed è per questo che esistono i limiti lato server descritti più avanti.
• Fermare gli abusi dei giocatori già connessi. Lo spam di eventi e gli exploit nelle risorse sono un problema di scripting.
• Proteggere i servizi che hai lasciato aperti: SSH, la porta di un database o txAdmin aperto a tutto il mondo.

Impostazioni in server.cfg

Queste righe vengono dal riferimento dei comandi del server. Non costano nulla e rendono meno pesante assorbire i flood di connessioni e HTTP che superano l'edge.

# game traffic on one port, TCP and UDP (the defaults)
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# concurrent TCP connections allowed per IP (default 16)
net_tcpConnLimit 16

# block IPs whose HTTP requests carry a 'Via' header
set sv_requestParanoia 1

# hide player IP addresses from public reports
set sv_endpointPrivacy true

# leave RCON off unless you use it
#set rcon_password ""

• net_tcpConnLimit limita le connessioni TCP simultanee per IP. Il valore predefinito è 16. Abbassalo solo se sai che nessun giocatore legittimo condivide un indirizzo; i giocatori dietro lo stesso router o dietro il NAT dell'operatore (carrier NAT) condividono un IP.
• sv_requestParanoia va da 0 (disattivato, il valore predefinito) a 3. Il livello 1 blocca gli IP che inviano un header Via, che i proxy aggiungono alle richieste che inoltrano. Il livello 2 blocca anche le richieste con un header Upgrade-Insecure-Requests, il che include chiunque apra un endpoint .json in un browser. Il livello 3 chiude anche il socket. Parti da 1.
• sv_endpointPrivacy true nasconde gli indirizzi IP dei giocatori nei report pubblici del server, così i tuoi giocatori non diventano il prossimo bersaglio.

I server su FiveM for GTAV Enhanced hanno anche limitatori di frequenza a token bucket per gli handshake, gli endpoint HTTP, gli eventi di rete, le state bag e RCON. Ognuno ha un rate (token al secondo) e un burst (numero massimo di token); una richiesta che non trova più token disponibili viene limitata. Tra i valori predefiniti ci sono 4 al secondo con un burst di 10 per http_info e http_players, e 50 al secondo con un burst di 200 per netEvent. Il riferimento indica questi comandi come esclusivi della build Enhanced.

# FiveM for GTAV Enhanced only
# set rateLimiter_<name>_rate  <tokens per second>
# set rateLimiter_<name>_burst <maximum tokens>
set rateLimiter_netEvent_rate 100
set rateLimiter_netEvent_burst 400

Modificali solo quando la console mostra un limitatore che scarta traffico che sai identificare. Alzare netEvent per far funzionare una risorsa molto attiva dà più margine anche a un client che fa spam.

Regole del firewall sul server

Chiudi tutto ciò che non serve ai giocatori. Ai giocatori serve la 30120 su TCP e UDP. A te servono SSH e txAdmin, e a nessun altro. Su Ubuntu o Debian con ufw, consenti la tua regola SSH prima di ufw enable, altrimenti resti chiuso fuori:

# replace 203.0.113.10 with your own public IP
ufw default deny incoming
ufw default allow outgoing
ufw allow from 203.0.113.10 to any port 22 proto tcp
ufw allow 30120/tcp
ufw allow 30120/udp
ufw allow from 203.0.113.10 to any port 40120 proto tcp
ufw enable
ufw status verbose

Non bloccare il backend di Cfx.re. La lista dei server interroga il tuo server dagli indirizzi pubblicati su static.cfx.re/ips.txt, e Cfx.re dice che un firewall rigido o un filtro DDoS deve consentirli tutti. I nuovi indirizzi vengono aggiunti almeno un mese prima che ne arrivi traffico, quindi sincronizza la lista a intervalli regolari.

La porta di txAdmin è la 40120, a meno che tu non la cambi con TXHOST_TXA_PORT, e non può essere la 30120, secondo il riferimento delle variabili d'ambiente di txAdmin. Se il tuo IP cambia spesso, tieni la 40120 completamente chiusa e raggiungi il pannello tramite un tunnel SSH:

# open txAdmin through SSH instead of the internet
ssh -L 40120:127.0.0.1:40120 root@your-server-ip
# then browse to http://localhost:40120

Su Windows Server le stesse regole vanno in Windows Defender Firewall: consenti 30120 TCP e UDP da qualsiasi indirizzo, e 3389 e 40120 solo dal tuo indirizzo.

Tenere nascosto l'IP di origine

Il filtraggio funziona solo se il traffico d'attacco è costretto a passarci attraverso. Quando la protezione sta sull'IP stesso del server, ogni pacchetto diretto a quell'IP viene filtrato e nasconderlo conta meno. Quando invece metti un proxy separato davanti al server, l'indirizzo reale (l'origine) deve restare segreto, perché un attaccante che lo conosce può aggirare il proxy.

La guida alla configurazione del proxy di Cfx.re descrive due proxy: un proxy HTTPS per l'endpoint di connessione e un proxy TCP e UDP grezzo, sulle stesse porte, per il traffico di gioco. Con entrambi attivi, queste convar impediscono a FXServer di pubblicizzare il proprio indirizzo:

# stop the server list from advertising the real IP
set sv_forceIndirectListing true

# the hostname the server list backend should query
set sv_listingHostOverride "play.example.com"

# your proxy addresses in CIDR notation (trusted for X-Real-IP)
set sv_proxyIPRanges "198.51.100.7/32"

# the UDP endpoint players are given: the proxy, not the origin
set sv_endpoints "198.51.100.7:30120"

A quel punto i giocatori entrano con connect "https://play.example.com/"; la guida fa notare che un host scritto da solo, come play.example.com, viene invece risolto in http://play.example.com:30120/. Poi chiudi le fughe di informazioni più comuni:

• Vecchi record DNS. Se un dominio ha mai puntato direttamente all'origine, considera l'indirizzo già noto e cambialo dopo che il proxy è attivo.
• Altri servizi sullo stesso IP: un sito web, un bot Discord, un database o un server di posta.
• Risorse che chiamano API o webhook esterni. Quelle richieste partono dall'IP di origine e sono visibili a chi gestisce l'altro capo.
• Indirizzi connect diretti pubblicati su Discord o nei forum prima che passassi dietro al proxy.

Cosa chiedere a un host prima di acquistare

1. Il filtraggio è sempre attivo o parte dopo che un attacco è stato rilevato? Se parte dopo, quanto tempo ci mette?
2. Copre l'UDP sulle porte di gioco o soprattutto il traffico web? FiveM ha bisogno che l'UDP sulla 30120 venga filtrato senza rompere l'handshake.
3. Qual è la capacità di filtraggio e cosa succede quando viene superata? Alcuni provider mettono l'IP in null-route, e questo manda offline il tuo server finché l'attacco non finisce.
4. C'è davanti al server un firewall che controlli tu, per porta e protocollo?
5. Puoi vedere quando è avvenuto un attacco e quanto era grande? Senza questi dati non puoi distinguere un attacco da un bug in una risorsa.
6. Restano abbastanza velocità della CPU in single-thread e RAM per il server stesso? La protezione non aiuta un server che è già al limite.

FiveM su Evorxa

I server Evorxa stanno dietro Shield, il filtraggio DDoS di Evorxa, con 3 Tbps di capacità di scrubbing. I server girano in una sola regione, Eygelshoven nei Paesi Bassi; le location edge della CDN di Shield sono separate da quella regione dei server. La pagina dell'hosting FiveM elenca piani con core condivisi (VPS) e con core dedicati ad alta frequenza (VDS), prepagati su base mensile, semestrale o annuale, con accesso root completo per le impostazioni descritte sopra.

Fonti

I fatti di questa guida provengono da queste pagine.

1. Documentazione Cfx.re: comandi del server (convar, limitatori di frequenza)
2. Documentazione Cfx.re: configurazione del proxy
3. Documentazione Cfx.re: IP statici (ips.txt)
4. Cfx.re: server.cfg di esempio
5. txAdmin: configurazione dell'ambiente