Proteggere un server Call of Duty dagli attacchi DDoS

Proteggere un server Call of Duty dagli attacchi DDoS è, nei titoli classici, un compito piacevolmente concreto: si tratta di una sola porta UDP, di una manciata di dvar nella server.cfg e di un vettore di amplificazione che l'engine si porta dietro dal 2003. Un server che la sera, nel bel mezzo della partita, perde tutti i giocatori nello stesso momento raramente ha invece un problema hardware. Di solito è in corso un attacco, e parte proprio nel momento in cui il server è pieno.

Questo articolo mostra prima per quali titoli vale davvero, poi che cosa puoi mettere in sicurezza da solo senza spese aggiuntive, quindi dove queste misure si fermano dal punto di vista tecnico e infine che cosa deve succedere nella rete, prima del server. I comandi sono scritti per Debian 12, Debian 13, Ubuntu 22.04 LTS e Ubuntu 24.04 LTS e presuppongono root; se lavori come utente normale, anteponi sudo.

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 "Registrare i log"), perché dopo l'attacco non ci sono più.

Per quali titoli Call of Duty puoi proteggere un server dal DDoS

Puoi proteggere un server Call of Duty dal DDoS soltanto nei titoli che permettono server dedicati propri. Sono le versioni originali di Call of Duty (2003), Call of Duty United Offensive, Call of Duty 2, Call of Duty 4 Modern Warfare e Call of Duty World at War, più le piattaforme della community Plutonium (World at War, Black Ops, Black Ops II, Modern Warfare 3), IW4x (Modern Warfare 2) e CoD4X (Call of Duty 4). Tutti questi titoli portano con sé lo stesso schema: una server.cfg, una porta UDP aperta e una voce in una lista pubblica di server.

Per i capitoli moderni questo articolo non vale, e va detto esplicitamente. Warzone, Modern Warfare (2019), Black Ops Cold War, Vanguard, Modern Warfare II, Modern Warfare III e Black Ops 6 non conoscono server dedicati da noleggiare: le partite girano sull'infrastruttura di matchmaking di Activision, non esiste alcuna server.cfg, nessun browser dei server e nessuna porta che tu possa aprire o proteggere. Le liste di porte che Activision pubblica per questi titoli (fra le altre TCP 3074 e da 27014 a 27050, oltre a UDP 3074, 3478 e da 27000 a 27031) descrivono porte di client e di piattaforma, non porte di server. Chi in Warzone subisce disconnessioni ha un problema sulla propria linea oppure uno dalla parte di Activision, ma non un problema che un server noleggiato risolverebbe.

Perché vengono attaccati proprio i server Call of Duty

I server Call of Duty mettono insieme quattro caratteristiche che ne fanno un bersaglio comodo. Primo, ogni server elencato pubblica il proprio indirizzo di sua iniziativa: la voce nella lista dei server contiene indirizzo IP e porta in chiaro, altrimenti nessuno potrebbe entrarci. Secondo, tutto il traffico passa da UDP, e UDP non prevede alcuna apertura di connessione da pretendere, mentre gli indirizzi mittente si possono falsificare. Terzo, l'engine risponde alle interrogazioni di stato di chiunque, senza che nessuno debba avviare il gioco. Quarto, la gestione remota RCON sta sulla stessa porta del gioco.

A questo si aggiunge la parte sociale: giocatori bannati, concorrenza fra clan, litigi in una community che si conosce da anni. Un attacco non costa a chi lo lancia né competenze né soldi degni di nota, i cosiddetti booter e stresser vengono venduti come abbonamento per pochi euro al mese, e gli attacchi di amplificazione attraverso i server di gioco fanno parte lì dell'offerta standard. Che cosa sia nel dettaglio un attacco DDoS lo spiega l'articolo Che cos'è un attacco DDoS?.

Le porte di cui si tratta davvero

Un server Call of Duty classico occupa esattamente una porta UDP, cioè la 28960. Su questa sola porta girano tre cose contemporaneamente: il traffico di gioco, le interrogazioni di stato della lista dei server e la gestione remota RCON. Una porta di query a sé e una porta RCON a sé non esistono. La riga di avvio di un server dedicato è uguale in tutti i titoli, cambia soltanto il nome del file eseguibile:

+set dedicated 2 +set net_ip 0.0.0.0 +set net_port 28960 +set sv_maxclients 32 +exec server.cfg +map_rotate

Le porte dei master server non devono comparire fra le tue aperture nel firewall. La 20810 e la 20800 sono porte di destinazione sull'altro capo, non porte in ascolto sulla tua macchina: è il tuo server a contattare la lista di sua iniziativa. Molte guide sull'apertura delle porte consigliano comunque di aprirle in ingresso. Questo allarga la superficie di attacco senza alcun vantaggio in cambio.

Ordini di grandezza abituali in Call of Duty

La seconda tabella è la più importante, se vuoi valutare se la situazione sia ancora gestibile da te. Mette a confronto il carico normale di un server pieno con i numeri di cui si parla quando c'è un attacco.

Perché gioco, query e RCON stanno sulla stessa porta

È questa la particolarità decisiva di Call of Duty. L'engine id Tech 3, su cui si basano tutti i titoli classici di Call of Duty, non conosce porte separate per gioco, interrogazione e gestione remota. Tutto passa dai cosiddetti pacchetti senza connessione su quell'unica porta UDP. Un pacchetto senza connessione è un pacchetto UDP che comincia con quattro byte 0xFF e che porta poi il nome del comando in chiaro: getstatus, getinfo, getchallenge, connect oppure rcon.

La conseguenza pratica è scomoda: non puoi separare RCON dal gioco tramite firewall senza bloccare anche il gioco. Una regola sulla porta 28960 colpisce sempre tutto. Chi vuole scartare in modo mirato i flood di query e gli attacchi RCON deve guardare dentro il contenuto del pacchetto e non solo al numero di porta. Proprio per questo in Call of Duty le regole firewall basate sulle porte arrivano al proprio limite prima che nei giochi con una porta di query separata.

Che cos'è la riflessione getstatus in Call of Duty?

La riflessione getstatus è un attacco di amplificazione in cui chi attacca manda piccole interrogazioni di stato con indirizzo mittente falsificato a molti server di gioco, perché le loro risposte, molto più grandi, finiscano sulla vittima vera. I server di gioco non sono il bersaglio, ma l'amplificatore. Questo vettore è documentato per l'engine id Tech 3 da oltre un decennio e riguarda Call of Duty esattamente come Quake 3 e i suoi altri derivati.

Ti colpisce doppiamente, da due direzioni. Come bersaglio ricevi una valanga di richieste getstatus, che consumano tempo di calcolo e banda in uscita, e i tuoi giocatori se ne accorgono sotto forma di lag spike. Come amplificatore involontario spedisci risposte a una vittima estranea, e la segnalazione di abuso arriva a te. Entrambe le cose accadono sulla stessa porta, con gli stessi pacchetti, ed entrambe all'inizio sembrano innocue nel grafico di utilizzo.

Come è fatto un pacchetto getstatus

La richiesta è composta da quattro byte 0xFF e dalla parola getstatus, in tutto 13 byte di carico utile. Con intestazione IP e UDP diventano 41 byte sulla linea. È esattamente a questo che punta il controllo di lunghezza nelle regole firewall che circolano da anni nei forum di Call of Duty:

iptables -A INPUT -p udp -m length --length 41:45 -m recent --set --name getstatus_cod
iptables -A INPUT -p udp -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

La risposta è incomparabilmente più grande. Una statusResponse contiene l'intera configurazione del server come stringa più una riga per ogni giocatore collegato, quindi diversi kilobyte a server pieno. La CISA indica per il protocollo di rete Quake, nella sua panoramica degli attacchi di amplificazione UDP (TA14-017A), un fattore di amplificazione di 63,9 e nomina espressamente come comando abusato lo scambio di informazioni sul server. Da 1 Mbit/s di richieste falsificate diventano così circa 64 Mbit/s presso la vittima. Per confronto: nella stessa panoramica il DNS sta fra 28 e 54, l'NTP a 556,9.

Il freno integrato: sv_queryIgnoreTime e sv_queryIgnoreMegs

Call of Duty 4 ha dalla versione server 1.7 un freno di query integrato. Si annota ogni indirizzo che ha mandato un'interrogazione di stato e ignora per un tempo impostabile le ulteriori interrogazioni dello stesso indirizzo. A governarlo sono quattro dvar, con questi valori predefiniti:

sv_queryIgnoreMegs        1
sv_queryIgnoreTime        2000
sv_queryBounceIgnoreTime  12000
sv_queryIgnoreDebug       0

sv_queryIgnoreMegs stabilisce quanta memoria di lavoro può occupare la lista degli indirizzi ignorati. 1 megabyte contiene circa 65.000 indirizzi, ogni megabyte in più circa 87.000 aggiuntivi. Il valore 0 disattiva completamente il freno, ed è esattamente quello che succede su molti server, perché la configurazione proviene da un vecchio modello. sv_queryIgnoreTime è il tempo di blocco in millisecondi. sv_queryBounceIgnoreTime entra in gioco quando torna indietro una risposta con "ICMP Port Unreachable", cioè proprio quando il tuo server viene usato come amplificatore contro una vittima estranea. sv_queryIgnoreDebug 1 scrive i casi rilevati nel log, così vedi se sta succedendo qualcosa.

Chi usa CoD4X ha in più limiti fissi nel codice del server: al massimo 20 risposte getstatus ogni 20 secondi, al massimo 100 risposte getinfo ogni 100 secondi e al massimo un messaggio di errore RCON ogni 100 millisecondi. Il commento nel codice sorgente dichiara chiaramente l'intenzione: il server può anche lasciarsi inondare, ma non deve sprecare banda in uscita mentre succede. È la priorità giusta, ma non sostituisce il filtraggio davanti al server.

Perché in Call of Duty RCON è storicamente un problema

RCON è la gestione remota del server, e in Call of Duty è un pacchetto UDP non cifrato sulla porta di gioco. Un comando RCON sulla linea si presenta così: quattro byte 0xFF, poi la parola rcon, poi la password in chiaro, poi il comando vero e proprio. Non c'è cifratura, non c'è sessione, non c'è account utente e non c'è secondo fattore. Da qui derivano tre problemi, tutti reali:

• Intercettazione. Chi vede il traffico in un punto qualsiasi del percorso legge la tua password RCON in chiaro. Questo vale per ogni rete fra te e il server e per ogni strumento a cui dai la password.
• Indovinare la password. Non esiste un accesso che si possa bloccare e non esiste il blocco dell'account dopo dieci tentativi falliti. Chi attacca prova le password alla velocità che vuole. Il server originale non lo frena affatto, CoD4X frena soltanto la risposta a un messaggio di errore ogni 100 millisecondi e registra il tentativo come "Bad rcon".
• Riflessione. Anche un messaggio di errore RCON è una risposta a un pacchetto falsificato. Chi bombarda il tuo server con pacchetti RCON falsificati lo usa come piccolo amplificatore, e il tuo server nel frattempo si riempie il log.

La conseguenza pratica: imposta rcon_password solo se ti serve davvero RCON. Se ti serve, allora lunga e casuale. CoD4X richiede almeno otto caratteri, che è un limite inferiore e non una raccomandazione. Nella gestione quotidiana amministra via SSH e dalla console del server, invece che via RCON dalla rete aperta. E se usi uno strumento di amministrazione come IW4MAdmin, che a sua volta parla via RCON, la sua interfaccia web sulla porta 1624 non deve stare sulla rete aperta.

Che cosa puoi fare da solo prima di spendere

Questa è la sezione più lunga, e non per caso. Un server Call of Duty 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:28960 e [::]:28960 significano "raggiungibile da tutta internet", 127.0.0.1:3306 significa "solo in locale" e non richiede alcuna regola firewall. Accanto al gioco compaiono spesso IW4MAdmin, un server web per il fast download, un database per le statistiche e una seconda istanza di gioco dimenticata. Il punto di vista di chi attacca te lo dà una scansione delle porte dall'esterno:

nmap -Pn -sU -p 28960-28970,4976,27016 IP.DEL.TUO.SERVER
nmap -Pn -p- --min-rate 1000 IP.DEL.TUO.SERVER

2. Lascia aperto solo ciò di cui il gioco ha davvero bisogno

Per un singolo server Call of Duty basta una sola apertura 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 28960/udp comment 'Call of Duty'
ufw allow from 203.0.113.10 to any port 1624 proto tcp comment 'IW4MAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sostituisci 203.0.113.10 con il tuo indirizzo. Con Plutonium T6 al posto di 28960/udp subentra 4976/udp, con Plutonium IW5 è 27016/udp. Se gestisci più istanze, apri esclusivamente l'intervallo effettivamente usato, quindi per esempio 28960:28962/udp e non genericamente da 28960 a 28970. Ogni porta su cui non è in ascolto nulla non è una via d'ingresso, ma in caso di attacco costa comunque lavoro al kernel. La guida completa, via di fuga compresa, la trovi in Configurare il firewall UFW senza bloccarsi fuori.

3. Attiva il freno di query nella server.cfg

Queste quattro righe devono stare nella server.cfg di ogni server Call of Duty 4 e non costano nulla se non qualche megabyte di memoria di lavoro:

set sv_queryIgnoreMegs "4"
set sv_queryIgnoreTime "2000"
set sv_queryBounceIgnoreTime "12000"
set sv_queryIgnoreDebug "0"

4 megabyte contengono circa 326.000 indirizzi, e bastano anche per un flood serio. Alza sv_queryIgnoreTime solo con prudenza oltre i 2000 millisecondi predefiniti: la lista dei server e ogni browser dei server interrogano il tuo server attraverso lo stesso meccanismo, e chi imposta un tempo di blocco troppo alto sparisce dalla lista. Metti sv_queryIgnoreDebug temporaneamente a 1 se vuoi sapere se il freno interviene davvero, e poi rimettilo a 0, così il log non ti riempie il disco.

4. Scarta i flood di query nel firewall

Il freno nell'engine agisce solo dopo che il pacchetto ha raggiunto il processo di gioco. Una regola firewall decide prima e costa meno. Queste due righe limitano getstatus per indirizzo sorgente:

iptables -A INPUT -p udp --dport 28960 -m length --length 41:45 -m recent --set --name cod_query --rsource
iptables -A INPUT -p udp --dport 28960 -m string --algo bm --string "getstatus" -m recent --update --seconds 2 --hitcount 4 --name cod_query --rsource -j DROP

La prima riga si annota ogni indirizzo sorgente che manda un pacchetto della lunghezza tipica di un'interrogazione di stato. La seconda scarta ogni ulteriore richiesta getstatus non appena lo stesso indirizzo ne ha mandate più di quattro nel giro di due secondi. Quattro richieste ogni due secondi bastano a qualsiasi browser dei server. Nei forum circolano anche varianti con 20 richieste al secondo, decisamente più generose, che funzionano più contro i bot grossolani che contro un'ondata di riflessione fatta bene.

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. Verifica poi con iptables -L INPUT -n -v se i contatori dei match salgono. Se restano a zero, la regola non viene raggiunta.

5. Disattiva RCON oppure tienilo stretto

L'accesso RCON più sicuro è quello che non esiste. Una rcon_password vuota rifiuta ogni pacchetto RCON:

set rcon_password ""

Tieni però conto di una sottigliezza: il server risponde comunque, e lo fa con un messaggio di errore, restando così un piccolo amplificatore. Chi vuole escludere anche questo e ha bisogno di RCON soltanto da un indirizzo fisso scarta prima i pacchetti:

iptables -A INPUT -p udp --dport 28960 ! -s 203.0.113.10 -m string --algo bm --string "rcon " -j DROP

Questa regola ha un effetto collaterale che è bene conoscere: la stringa rcon può in teoria comparire anche in un pacchetto di chat di un giocatore collegato, e quel pacchetto verrebbe scartato a sua volta. Nella pratica è sopportabile. Chi non vuole l'effetto collaterale lascia perdere la regola e lavora soltanto con una password vuota oppure molto lunga.

6. Respingi i flood di ingresso e l'esaurimento degli slot

Un flood di ingressi non punta alla linea, ma alla logica di gioco: chi attacca manda in rapida successione pacchetti getchallenge e connect, finché tutti gli slot sono occupati da connessioni a metà. I giocatori veri ricevono allora "Server is full", anche se nel gioco non c'è nessuno. Contro questo funzionano le seguenti impostazioni:

set sv_maxclients "32"
set sv_reconnectLimit "3"
set sv_floodProtect "1"
set sv_connectTimeout "30"
set sv_timeout "120"

sv_reconnectLimit limita quante volte di seguito lo stesso giocatore può ricollegarsi. sv_floodProtect limita quanti comandi di client il server elabora per ogni giocatore e impedisce così che un singolo client rallenti il server a forza di comandi. sv_connectTimeout e sv_timeout stabiliscono per quanto tempo una connessione a metà oppure una connessione muta blocchino uno slot: chi lascia qui i valori generosi di un vecchio modello rende facile a chi attacca l'esaurimento degli slot.

Su CoD4X si aggiunge sv_authorizemode. Il valore 1 fa entrare solo i giocatori con una copia valida, 0 solo i giocatori senza, e -1 entrambi. Chi imposta 1 tiene fuori gran parte dei client usa e getta, ma perde anche giocatori veri senza copia originale. Lo strumento più duro è una password del server impostata con g_password, che funziona contro tutto ciò che passa dalla normale via di ingresso. E una cosa deve essere chiara: una password 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. La voce nella lista dei server e il tuo indirizzo

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, porta compresa. Puoi disattivare la voce non impostando alcun master server nella server.cfg (le dvar si chiamano sv_master1, sv_master2 e così via). Questo però costa tutta la visibilità verso i nuovi giocatori e serve soltanto contro il più pigro degli aggressori.

Una nota sullo stato delle liste: i master server originali di Activision (codmaster.activision.com sulla 20510, cod2master.activision.com sulla 20710, cod4master.activision.com sulla 20810) per i vecchi titoli non rispondono più. Chi oggi vuole comparire in elenco usa le liste della community: CoD4X ne gestisce una propria e per questo richiede un token in sv_authtoken, Plutonium porta con sé una lista dei server propria. Alla sostanza questo non cambia nulla, l'indirizzo compare lì in chiaro esattamente allo stesso modo.

Due abitudini funzionano comunque. Non pubblicare tu stesso l'indirizzo IP grezzo da nessuna parte, quindi né nel canale Discord né sulla pagina del clan. E fai collegare i tuoi giocatori tramite un hostname, così all'occorrenza puoi cambiare indirizzo senza rompere tutti i riferimenti. Il classico intoppo è un record A dimenticato che punta al vecchio indirizzo: rende inutile qualsiasi cambio.

8. Togli dalla rete aperta interfacce web, database e fast download

Accanto al gioco, sulla maggior parte dei server Call of Duty gira dell'altro: IW4MAdmin con la sua interfaccia web sulla porta 1624, un server web per il fast download delle mappe, a volte un database per le statistiche. Ognuno di questi servizi è una superficie di attacco a sé, e nessuno di essi deve stare senza limiti sulla rete aperta.

Limita la 1624 al tuo indirizzo oppure raggiungi l'interfaccia attraverso un inoltro SSH; poi apri in locale http://127.0.0.1:1624:

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

Il database lo leghi a 127.0.0.1: sulla rete aperta non ha in nessun caso niente da fare. E metti il fast download su un server web a sé invece che dentro il processo di gioco: altrimenti un server web sotto carico toglie al gioco proprio il tempo di calcolo che gli serve per la simulazione.

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 venerdì sera. Con apt-get install -y vnstat sysstat la misurazione resta sempre attiva. Durante un incidente bastano quattro comandi:

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

Per Call of Duty ce n'è un quinto, che risponde alla domanda decisiva. Questa cattura mostra esclusivamente i pacchetti senza connessione, quindi esattamente getstatus, getinfo, getchallenge, connect e rcon:

tcpdump -ni eth0 'udp port 28960 and udp[8:4] = 0xffffffff' -c 200 -A

Se lì compare cento volte getstatus da indirizzi sempre nuovi, hai un flood di query. Se compare rcon, qualcuno sta provando a indovinare la tua password. Se compaiono solo getchallenge e connect, è un flood di ingressi. Per tcpdump vale sempre una regola: limita 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 server pieno da 32 slot produce in uscita circa 6,4 Mbit/s, cioè meno dell'uno per cento di una linea gigabit. La stessa linea è satura non appena qualcuno spedisce 125 megabyte al secondo, ed è esattamente su questo che sono tarati gli attacchi che si possono ordinare per dieci euro al mese. Che la tua regola iptables dietro sia buona a quel punto non conta più, perché i pacchetti dei tuoi giocatori si fermano già prima.

La seconda grandezza è la frequenza dei pacchetti, e in Call of Duty colpisce regolarmente 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. Una richiesta getstatus, con i suoi 41 byte, è ancora più piccola: un attacco che non riempie nemmeno un terzo della tua linea mette comunque fuori gioco il tuo server, perché tutto 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".

In Call of Duty si aggiunge una particolarità che peggiora il conto. Poiché gioco, query e RCON stanno sulla stessa porta, non puoi chiudere la 28960 in caso di emergenza: sarebbe la stessa cosa che spegnere il server. E poiché l'engine risponde a ogni interrogazione di stato con un multiplo della dimensione della richiesta, chi attacca consuma, a parità di effetto, meno banda propria che in altri giochi.

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. Quali giochi e protocolli siano coperti lo elenca Protezione DDoS per game server in tempo reale.

Advanced DDoS Protection per progetti sotto attacco continuo

Certi clan e certe community 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 28960 UDP senza dover aprire un ticket, e con più istanze in modo separato per ogni porta.
• 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, anche per applicazioni modificate e proprie su porte TCP o UDP a piacere. Per Plutonium e CoD4X è questo il punto rilevante, perché le loro porte possono discostarsi dai valori predefiniti.

La Advanced DDoS Protection si rivolge ai server che stanno su KernelHost. Se il tuo server Call of Duty gira al momento altrove e lì viene regolarmente tolto dalla rete, il trasloco su KernelHost è la strada che cambia qualcosa.

I due livelli a confronto

Per la maggior parte dei server Call of Duty basta la protezione permanente inclusa, insieme a una server.cfg pulita. 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, un bot Discord con indicatore di stato oppure un vecchio record DNS. Cambiare indirizzo fa guadagnare tempo, non risolve.

"Il mio provider mi manda una segnalazione di abuso, anche se la vittima sono io": allora il tuo server non è il bersaglio, ma l'amplificatore. Qualcuno manda richieste getstatus falsificate e il tuo server risponde diligentemente a una vittima estranea. Verifica prima se sv_queryIgnoreMegs sia a 0, e imposta le quattro dvar di query insieme alla regola firewall del paragrafo 4.

"Il server risulta pieno nella lista, ma è vuoto": è un flood di ingressi, e colpisce la logica di gioco, non la linea. Contro questo funzionano sv_reconnectLimit, valori più brevi per sv_connectTimeout e sv_timeout e, nel dubbio, una password del server.

"Il server sparisce dalla lista dei server durante l'attacco": è la conseguenza, non la causa. La lista dei server verifica attraverso le stesse interrogazioni di stato se il tuo server sia vivo. Se le risposte non passano oppure se sono state scartate dal tuo stesso freno, il server risulta offline. Verifica se sv_queryIgnoreTime sia troppo alto prima di sospettare del firewall.

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

"Il server gira, ma tutti i giocatori hanno lag spike": guarda prima la frequenza dei pacchetti dell'interfaccia, non il carico della CPU. Se sar -n DEV 1 10 resta normale e il gioco va comunque a scatti, di solito dipende da una mod, da una sv_maxRate esagerata oppure semplicemente da troppi bot nella partita.

"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 Call of Duty classico ha bisogno di esattamente una porta aperta: la 28960 UDP. Con Plutonium T6 è la 4976 UDP, con Plutonium IW5 la 27016 UDP.
• In Call of Duty gioco, interrogazione di stato e RCON stanno sulla stessa porta. Non puoi separare RCON dal gioco con una regola di porta, per farlo ti serve una regola che guardi dentro il contenuto del pacchetto.
• La riflessione getstatus è il vettore di amplificazione tipico del gioco: 41 byte di richiesta, secondo l'avviso CISA TA14-017A fattore 63,9 per il protocollo di rete Quake, quindi circa 2.600 byte di risposta.
• Attiva il freno di query: sv_queryIgnoreMegs 4, sv_queryIgnoreTime 2000, sv_queryBounceIgnoreTime 12000. Su molti server è a 0 e quindi spento.
• Imposta rcon_password solo se ti serve davvero RCON: la password viaggia non cifrata su UDP e si può provare a indovinare quante volte si vuole, senza alcun blocco dell'account.
• Le porte dei master server 20810 e 20800 sono porte di destinazione in uscita e non devono comparire fra le tue aperture in ingresso.
• Da circa 1 Gbit/s oppure da qualche centinaio di migliaia di pacchetti al secondo decide esclusivamente la rete davanti al server, non più la tua configurazione.

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