Proteggere i server RAGE MP e alt:V dagli attacchi DDoS

Un server multiplayer di GTA è un bersaglio comodo per chi attacca: è raggiungibile su un unico indirizzo IP, la sua porta compare in una lista server pubblica e ogni interruzione è visibile a tutti i giocatori nello stesso momento. Questo articolo mostra prima che cosa puoi ottenere davvero sul tuo server, poi con la stessa chiarezza dove finiscono queste possibilità.

Se non sei ancora sicuro che sia davvero in corso un attacco, misuralo per prima cosa: Riconoscere un attacco DDoS descrive la diagnosi passo dopo passo. Le basi tecniche le trovi in Che cos'è un attacco DDoS.

Perché proprio RAGE MP e alt:V vengono colpiti così spesso

La scena roleplay attorno a GTA V è piccola, pubblica e molto competitiva. Un server vive dei suoi giocatori abituali, e con interruzioni prolungate quei giocatori finiscono in fretta su un altro Discord. Questo rende gli attacchi appetibili: non serve avere successo per ore, bastano pochi minuti nella fascia oraria di punta, la sera dell'apertura oppure durante un wipe annunciato.

A questo si aggiunge che nessuno deve cercare a lungo. Entrambe le piattaforme, se lo vuoi, annunciano il tuo server a una lista server pubblica: RAGE MP tramite announce nel file conf.json, alt:V tramite announce e token nel file server.toml. Chi compare lì pubblica indirizzo IP e porta. Per questo un server appena registrato riceve spesso i primi tentativi di connessione automatizzati già nella prima ora, molto prima che arrivi il primo giocatore vero.

Il terzo motivo è di natura tecnica: il traffico di gioco passa su UDP. UDP non prevede l'apertura di una connessione che il mittente debba attendere, quindi l'indirizzo del mittente si può falsificare. Chi conosce la tua porta può bersagliarla senza ricevere mai una risposta e senza mostrare il proprio indirizzo.

Le porte di cui stiamo parlando

Prima di scrivere la prima regola dovresti sapere quale porta serve a che cosa. Entrambe le piattaforme ne usano più di una.

Due particolarità qui contano. In RAGE MP la porta HTTP è legata in modo fisso alla porta di gioco, è sempre quella immediatamente successiva: se sposti la porta di gioco su 22015, la porta dei file si sposta su 22016. In alt:V il traffico di gioco e la distribuzione dei file condividono lo stesso numero di porta, una volta su UDP e una volta su TCP. Chi fa distribuire i file del client da una rete di distribuzione dei contenuti (opzioni useCdn e cdnUrl nel file server.toml) toglie la parte TCP dalla propria linea. Il traffico di gioco su UDP resta invece invariato.

Che cosa puoi fare da solo prima di spendere soldi

I passaggi che seguono non fermano un attacco volumetrico, non ci riesce nessun software installato sul server. Ripuliscono però tutto quello che sta sotto: scansioni di porte, ondate di connessioni da poche sorgenti, attacchi al database invece che al gioco e l'abuso della tua stessa porta dei file. È la maggior parte di ciò che disturba un server piccolo nella vita di tutti i giorni, e costa solo mezz'ora.

Passo 1: fai l'inventario di ciò che è in ascolto verso l'esterno

ss -tulnp

La colonna interessante è quella con l'indirizzo locale. Tutto ciò che lì riporta 0.0.0.0 oppure [::] è raggiungibile da internet, tutto ciò che riporta 127.0.0.1 soltanto in locale. Su un tipico server roleplay, oltre al gioco compaiono in fretta un database, una cache, un pannello web e a volte un server voce. Ognuno di questi servizi è una superficie di attacco a sé, e nessuno di loro deve per forza essere esposto solo perché è in esecuzione.

Passo 2: limita il firewall alle porte davvero necessarie

Per un server RAGE MP si tratta di tre aperture: SSH, porta di gioco e porta dei file. Autorizza in ogni caso per prima la tua porta SSH, altrimenti con l'ultima riga ti chiudi fuori da solo:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 22005/udp
ufw allow 22006/tcp
ufw enable

Per alt:V le due regole di gioco diventano invece:

ufw allow 7788/udp
ufw allow 7788/tcp

Verifica poi con ufw status verbose che siano aperte davvero solo queste porte e ripeti ss -tulnp. La configurazione completa, IPv6 e le classiche trappole che ti chiudono fuori compresi, la trovi in Configurare il firewall UFW.

Passo 3: togli database e cache dalla rete

Nella maggior parte dei gamemode MariaDB e Redis girano sulla stessa macchina del server di gioco e non hanno quindi bisogno di un indirizzo su internet. Nella configurazione di MariaDB (su Debian e Ubuntu /etc/mysql/mariadb.conf.d/50-server.cnf) va inserita questa riga:

bind-address = 127.0.0.1

E in /etc/redis/redis.conf:

bind 127.0.0.1 ::1
protected-mode yes

Poi riavvia entrambi i servizi e ricontrolla con ss -tulnp. Una cache esposta e senza password non è un problema di DDoS, è una via d'ingresso per un'intrusione, e viene scansionata 24 ore su 24.

Passo 4: limita la frequenza delle connessioni sulla porta dei file

La porta TCP dei file del client è il punto in cui una limitazione della frequenza sul server ha davvero effetto, perché qui la connessione viene aperta per intero e quindi esiste un indirizzo mittente di cui ci si può fidare almeno in parte. Bastano due regole, qui per RAGE MP sulla porta 22006:

iptables -A INPUT -p tcp --dport 22006 --syn -m connlimit --connlimit-above 20 --connlimit-mask 32 -j DROP
iptables -A INPUT -p tcp --dport 22006 --syn -m hashlimit --hashlimit-name gtahttp --hashlimit-mode srcip --hashlimit-above 30/sec --hashlimit-burst 60 -j DROP

La prima regola limita le connessioni aperte contemporaneamente per ogni indirizzo sorgente, la seconda i tentativi di connessione al secondo. Per alt:V metti 7788 in entrambi i punti. Tre avvertenze: ufw limit qui è troppo grossolano e conosce solo il TCP, i valori numerici li adatti alla dimensione dei tuoi file del client, e le regole sopravvivono a un riavvio soltanto con iptables-persistent oppure come voce in /etc/ufw/before.rules.

Sulla porta di gioco UDP la stessa tecnica serve invece a poco, perché lì i mittenti sono falsificati: un blocco per indirizzo sorgente non colpisce nessuno, tranne per caso un giocatore vero. Quello che invece dovresti tenere d'occhio è il connection tracking del kernel:

cat /proc/sys/net/netfilter/nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

Se il primo valore si avvicina al secondo, il kernel scarta i pacchetti senza distinguere se appartengono a un attacco o a un giocatore. Nel log di sistema compare allora nf_conntrack: table full, dropping packet.

Passo 5: usa gli strumenti già presenti nelle due piattaforme

Entrambi i core dei server integrano impostazioni pensate proprio contro l'abuso delle connessioni, e di fabbrica stanno sul valore più permissivo. In RAGE MP riguardano tre chiavi nel file conf.json:

{
    "bind": "0.0.0.0",
    "port": 22005,
    "announce": true,
    "maxplayers": 200,
    "disallow-multiple-connections-per-ip": true,
    "limit-time-of-connections-per-ip": 1000,
    "enable-http-security": true
}

Questo è solo un estratto, le altre chiavi restano invariate. disallow-multiple-connections-per-ip impedisce più connessioni contemporanee dallo stesso indirizzo, limit-time-of-connections-per-ip impone una distanza minima tra due tentativi di connessione (0 disattiva il limite) e enable-http-security attiva i controlli aggiuntivi del server HTTP integrato. Confronta l'unità di tempo del valore centrale con la documentazione della tua versione del server prima di aumentarlo. E metti in conto che la prima opzione taglia fuori i compagni di gioco che stanno dietro alla stessa linea, quindi coinquilini, familiari e reti aziendali.

In alt:V le opzioni corrispondenti stanno nel file server.toml:

host = '0.0.0.0'
port = 7788
players = 200
announce = true
duplicatePlayers = 4
connectionQueue = true
useEarlyAuth = true

duplicatePlayers limita quanti giocatori con lo stesso indirizzo IP possono essere collegati nello stesso momento. Il valore predefinito è 4096, quindi in pratica non è un limite. connectionQueue mette i tentativi di connessione in coda invece di elaborarli tutti insieme. useEarlyAuth antepone un accesso al server di gioco: il client deve autenticarsi prima di entrare nel tuo mondo di gioco, il che scarta in partenza le ondate di connessioni più semplici. L'indirizzo della pagina di accesso sta in earlyAuthUrl.

Passo 6: una whitelist finché dura l'emergenza

Se un attacco passa dalla meccanica di gioco, cioè da tentativi di connessione di massa invece che dalla pura banda, una whitelist è la misura a breve termine più efficace. In alt:V, per far girare il server a porte chiuse, basta già un password nel file server.toml. In codice la forma più semplice è questa, qui per RAGE MP:

const whitelist = new Set(['GiocatoreUno', 'GiocatoreDue']);

mp.events.add('playerJoin', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('Il server è attualmente chiuso.');
    }
});

E la stessa logica per alt:V:

import * as alt from 'alt-server';

const whitelist = new Set(['GiocatoreUno', 'GiocatoreDue']);

alt.on('playerConnect', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('Il server è attualmente chiuso.');
    }
});

Entrambi gli esempi sono volutamente semplici e hanno un limite chiaro: il nome visualizzato non è un identificativo affidabile. Chi gestisce una whitelist in modo permanente fa meglio a verificare l'identificativo dell'accesso anteposto oppure una propria gestione degli account. Soprattutto però vale questo: un kick avviene solo dopo che la connessione ha raggiunto il server. Contro i pacchetti che stanno già riempiendo la linea non serve a niente.

Passo 7: la voce nella lista server e l'igiene dell'indirizzo IP

Disattivare la voce nella lista server (announce su false) sembra una soluzione rapida e quasi mai lo è. Chi ha già il tuo indirizzo IP continua a raggiungerti, mentre i tuoi giocatori non ti trovano più. Il passaggio ha senso solo insieme a un cambio di indirizzo IP, perché solo allora chi attacca perde il suo bersaglio.

Sul lungo periodo rende di più fare ordine nei punti in cui l'indirizzo si viene a sapere di rimbalzo: tieni sito e forum su un'altra macchina, cancella i vecchi record DNS (anche mail, ftp e i nomi di prova dei primi tempi), non far girare bot di Discord e indicatori di stato sul server di gioco, separa il server voce. L'indirizzo di un server di gioco non si può però nascondere del tutto: il traffico di gioco su UDP deve arrivare direttamente da te, e una rete di distribuzione dei contenuti anteposta ai siti web non cambia niente. Qui non aiuta il mascheramento, ma un indirizzo dietro al quale c'è un filtraggio.

Passo 8: raccogli le misure prima che la cosa si faccia seria

Quando la situazione si fa critica conta soltanto quello che puoi dimostrare. Prepara in anticipo i comandi con cui rilevi in pochi secondi la frequenza dei pacchetti in entrata e lo stato delle connessioni:

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) pacchetti/s in entrata su $IF"
ss -s

Annota questi valori una volta durante il funzionamento normale, nella fascia di gioco di punta, perché senza un valore di riferimento ogni numero durante un attacco non vale niente. Se il tuo server di gioco gira come servizio systemd, aggiungi anche journalctl -u <nome-del-servizio> -n 200: le ondate di connessioni lasciano lì quasi sempre una traccia evidente. C'è però un limite da conoscere: sul server misuri solo quello che è riuscito a passare. Se davanti c'è un filtraggio, il numero attendibile sta nel grafico del traffico nell'area clienti e non in /proc.

Dove finiscono queste misure

Ogni regola sul server ha effetto solo dopo che il pacchetto è arrivato. È la frase decisiva. Un firewall decide su pacchetti che hanno già attraversato la tua linea, ed è proprio quella linea il bersaglio di un attacco volumetrico.

Gli ordini di grandezza sono questi: un singolo server è collegato tipicamente a 1 Gbit/s. Con i pacchetti più piccoli fanno circa 1,5 milioni di pacchetti al secondo, fisicamente non ne passano di più. Per tappare quella linea non serve un attacco da record, bastano 2-5 Gbit/s. Per confronto, un attacco misurato realmente sulla rete di KernelHost a Francoforte: oltre 473,4 Gbit/s e oltre 41,5 milioni di pacchetti al secondo contro un singolo servizio. È circa 470 volte la capacità di una linea da gigabit, e anche un collegamento da 10 Gbit/s ne resta lontano di un fattore 47.

Se la linea è piena, scarta già il router che sta davanti, e lo fa senza guardare il singolo pacchetto. I tuoi giocatori finiscono allora nella stessa coda dell'attacco. Non ci possono fare niente iptables, un plugin o una CPU più potente, perché il collo di bottiglia sta davanti al server. A questo si aggiunge che nelle ondate UDP gli indirizzi mittente sono falsificati: semplicemente non c'è nessuno che avrebbe senso bloccare.

Efficace è quindi soltanto un filtraggio che si trova nella rete davanti alla tua linea e che lì ha abbastanza capacità perché l'attacco non riesca a saturarla.

Che cosa mette in campo KernelHost

La protezione permanente già attiva su ogni server

In KernelHost (KernelHost GmbH, sede a Vienna, Austria) su ogni server è permanentemente attiva una protezione DDoS a due livelli, senza ordinarla, senza configurarla e senza sovrapprezzo:

• Livello 1: rete globale di scrubbing con 17 Tbps di capacità di mitigazione. Gli attacchi volumetrici vengono intercettati vicino alla loro origine, prima ancora che raggiungano il datacenter.
• Livello 2: filtraggio Arbor in tempo reale con 3,2 Tbps. Si trova in loco nel datacenter maincubes di Francoforte sul Meno (Germania) e si occupa del lavoro fine subito davanti al tuo server, pacchetto per pacchetto.

Altrettanto importante è ciò che non succede: non viene applicato alcun null-routing. Il tuo indirizzo IP resta in rete durante un attacco, cadono soltanto i pacchetti dannosi. Per un server roleplay questa differenza pesa parecchio, perché per i tuoi giocatori un indirizzo messo in null-routing è indistinguibile da un attacco riuscito. Se durante un incidente non riesci più a entrare via SSH, raggiungi comunque il sistema tramite la console VNC nell'area clienti, che funziona indipendentemente dal collegamento di rete del server.

Advanced DDoS Protection per progetti sotto attacco continuo

Alcuni progetti non vengono colpiti una volta sola, ma per settimane. Per questi casi c'è la Advanced DDoS Protection da 50,00 € al mese, PrePaid e senza durata minima, senza preavviso di disdetta, senza contratto e senza costi di attivazione. Comprende:

• un IP di protezione dedicato preso dal core di Francoforte, su cui il tuo server viene spostato senza che tu debba modificare niente,
• regole di protezione che gestisci tu stesso, per porta e protocollo, direttamente nell'area clienti,
• modifiche che hanno effetto in tempo reale, senza ticket e senza attese,
• un profilo di protezione adatto al gioco specifico, scelto tra oltre 40 profili per giochi, servizi e protocolli, fra cui RageMP e alt:V, più profili generici per le tue applicazioni TCP e UDP.

La differenza pratica sta nel controllo: decidi tu quale profilo gira su 22005 UDP e quale regola vale per 22006 TCP, anche nel bel mezzo di un attacco.

I due livelli a confronto

Errori frequenti e soluzioni

Tutte le porte aperte perché altrimenti qualcosa non funziona: quasi sempre è una diagnosi sbagliata. Annota con ss -tulnp quale servizio ha bisogno di quale porta e apri esattamente quelle. Se dopo manca qualcosa, di solito dipende da un servizio che comunque è in ascolto solo in locale.

Bloccare gli IP di chi attacca: in un'ondata UDP i mittenti sono falsificati. Così blocchi indirizzi che non c'entrano niente e, nel caso peggiore, i tuoi stessi giocatori. Ha senso solo con connessioni TCP aperte per intero, quindi sulla porta dei file.

Mettere soltanto announce su false: il server sparisce dalla lista, ma l'indirizzo IP resta lo stesso. Un attacco in corso prosegue invariato, solo che i tuoi giocatori non trovano più il server. Senza un cambio di indirizzo questo passaggio non serve a niente.

Limitare la frequenza sulla porta di gioco UDP: le reti mobili e le linee aziendali raggruppano molti giocatori dietro un solo indirizzo. Un limite per indirizzo sorgente butta fuori giocatori veri, mentre i mittenti falsificati dell'ondata restano indisturbati.

Più CPU e più RAM come risposta al DDoS: entrambi aiutano contro un gamemode sovraccarico, non contro una linea piena. Il collo di bottiglia sta davanti al server, e lì un hardware più potente non cambia niente.

Riavviare nel bel mezzo dell'attacco: il riavvio azzera tutti i contatori che ti sarebbero serviti per una segnalazione solida, e l'attacco dopo prosegue invariato. Raccogli prima le misure, poi agisci.

Database esposto su internet perché il pannello web gira su un'altra macchina: fai passare la connessione da un tunnel SSH o da una rete privata. Se non è possibile, limita almeno l'accesso all'unico indirizzo sorgente che ne ha davvero bisogno.

Se sta succedendo proprio adesso

Raccogli prima le misure del passo 8, così la tua segnalazione è solida: momento con fuso orario, indirizzo IP e porta interessati, frequenza dei pacchetti misurata con l'indicazione della direzione. Poi apri un ticket di supporto. Con un attacco in corso ci raggiungi anche tramite la chat di emergenza WhatsApp al numero +43 650 8209883. La panoramica indipendente dal provider sui passi successivi la trovi in Proteggere il server dagli attacchi DDoS.