Proteggere un server Garry's Mod dagli attacchi DDoS

Un server Garry's Mod che alle otto di sera sparisce per tre minuti e poi torna raramente ha un problema hardware. Nella grande maggioranza dei casi è in corso un attacco, ed è in corso proprio quando sono collegati più giocatori. Protezione DDoS per Garry's Mod significa quindi prima di tutto sapere quali pacchetti possono davvero arrivare sul tuo server. Questo articolo mostra, in quest'ordine, che cosa puoi mettere in sicurezza da solo nei prossimi dieci minuti senza spendere un centesimo, dove queste misure si fermano dal punto di vista fisico, e che cosa deve succedere dopo nella rete, prima del server.

Tutte le indicazioni si riferiscono a un server srcds su Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS. Il file di configurazione si trova in garrysmod/cfg/server.cfg, i comandi sono scritti per root; se lavori come utente normale, anteponi sudo. Si parla sempre di un server root o dedicato tuo, non di uno slot preso da un fornitore di game server.

Se l'attacco è in corso proprio adesso: non modificare nulla in server.cfg e non riavviare srcds. Metti prima al sicuro i valori misurati (paragrafo 9), perché dopo l'attacco non ci sono più. Un riavvio ti costa i contatori e riporta il server nella stessa piena.

Perché un server Garry's Mod ha bisogno di protezione DDoS

Un server Garry's Mod pubblica da sé il proprio indirizzo IP e la propria porta. Non è una svista, è un requisito: chi non compare nel browser dei server non riceve nuovi giocatori. La voce nasce perché il server si registra presso il master server di Steam e da quel momento risponde a ogni query A2S che arriva dall'esterno. La domanda non è quindi mai se chi attacca troverà il tuo indirizzo, ma soltanto che cosa succede quando lo prende di mira.

A questo si aggiunge il tipo di community. Garry's Mod non si gioca prevalentemente a round, ma in mondi permanenti: una community DarkRP tiene in un database gli account dei giocatori, i possedimenti, i lavori e i progressi per mesi. Un disservizio il venerdì sera costa quindi più di una partita persa, costa giocatori abituali. Proprio per questo le tre cause più frequenti sono le community concorrenti, i giocatori bannati e i server booter comprati (servizi che per pochi euro al mese lanciano attacchi contro un indirizzo qualsiasi). A chi attacca non servono né competenze né soldi degni di nota.

Sul piano tecnico si sommano tre particolarità. Il traffico di gioco passa da UDP, e UDP non prevede alcuna apertura di connessione da pretendere: gli indirizzi mittente si possono falsificare. La query del server sta sulla stessa porta del gioco, quindi un blocco grossolano colpisce sempre entrambi. E sopra tutto questo c'è Lua: ogni addon del Workshop porta codice proprio nello stesso processo, e basta un singolo evento di rete senza protezione perché un unico client freni il server senza alcuna banda. Che cosa sia in generale un attacco DDoS lo spiega l'articolo Che cos'è un attacco DDoS?.

Le porte di cui si tratta davvero su Garry's Mod

Un server Garry's Mod parte di serie sulla porta 27015, e lo fa su UDP per il gioco insieme alla query del server e su TCP per RCON. Il numero si cambia all'avvio con -port; con più istanze si conta in avanti (27016, 27017 e così via). Una riga di avvio tipica è questa:

./srcds_run -game garrysmod -console \
  -port 27015 \
  +maxplayers 64 \
  +gamemode darkrp \
  +map rp_downtown_v4c_v2 \
  +sv_setsteamaccount IL_TUO_TOKEN_GSLT \
  +host_workshop_collection 123456789 \
  -authkey LA_TUA_CHIAVE_STEAM_WEB_API

Da qui deriva l'intera superficie di attacco. La tabella che segue è la base di ogni regola firewall più avanti:

Di queste otto voci esattamente una va sulla rete aperta senza restrizioni: la 27015/UDP. Tutto il resto viene limitato al tuo indirizzo, associato a 127.0.0.1 oppure non avviato affatto. L'errore di ragionamento più costoso in questa materia è dare per scontato che su Garry's Mod esista una porta di query separata da chiudere. Non esiste.

Che cosa puoi fare da solo prima di spendere

Questa è la sezione più lunga, e non per caso. Un server Garry's Mod configurato bene regge con le proprie forze gli attacchi piccoli e medi, a prescindere da dove si trovi. Niente di tutto questo costa denaro, e la maggior parte si fa in un quarto d'ora.

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:27015 e [::]:27015 significano "raggiungibile da tutta internet", 127.0.0.1:3306 significa "solo in locale" e non richiede alcuna regola firewall. Su un server DarkRP cresciuto nel tempo si trovano quasi sempre più servizi del previsto: MySQL, un webserver per FastDL, un pannello, un bot Discord, un secondo server di prova sulla 27016 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 -sU -sT -p- --min-rate 1000 IP.DEL.TUO.SERVER

2. Lascia aperte solo le porte che a srcds servono davvero

A Garry's Mod basta una sola apertura verso l'esterno, più SSH e l'accesso RCON limitato. 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 27015/udp comment 'Gioco Garrys Mod e A2S'
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment 'RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sostituisci 203.0.113.10 con il tuo indirizzo. SourceTV sulla 27020/UDP la apri soltanto se trasmetti davvero. La guida completa, via di fuga compresa, sta in Configurare il firewall UFW senza bloccarsi fuori. Se dovesse succedere comunque: i server root KVM e i server dedicati di KernelHost non hanno IPMI né iDRAC, quindi torni dentro tramite la console VNC nell'area clienti. Quella console non dipende dallo stack di rete del sistema ospite, e nessuna regola firewall dentro il sistema ospite può bloccarla.

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. Limitare la query A2S senza sparire dalla lista dei server

Qui sta l'errore che costa la maggior parte dei server Garry's Mod. Dato che traffico di gioco e query del server occupano la stessa porta, un blocco indiscriminato o un limite di frequenza troppo stretto sulla 27015/UDP butta fuori i propri giocatori e porta a termine l'attacco al posto di chi lo ha lanciato. Il punto giusto su cui intervenire è la distinzione fra pacchetti di query e pacchetti di gioco.

L'engine mette a disposizione tre variabili di console, da scrivere in server.cfg. I loro valori predefiniti sono prudenti, ma ci sono:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

sv_max_queries_sec limita le query a cui viene data risposta per ogni indirizzo mittente (valore predefinito 3 al secondo), sv_max_queries_sec_global mette un tetto alla somma su tutti gli indirizzi (valore predefinito 60 al secondo), sv_max_queries_window fissa la finestra di media (valore predefinito 30 secondi). Questi valori proteggono la CPU dal generare risposte inutili. Non impediscono ai pacchetti di arrivare, e chi stringe molto il valore globale sparisce dal browser dei server durante l'attacco, perché restano senza risposta anche le query dei siti che elencano i server.

Un livello più in basso il traffico di query si separa in modo pulito. Tutti i pacchetti senza connessione dell'engine Source iniziano con quattro byte impostati a uno (0xffffffff), mentre il traffico dei giocatori già collegati non ha questa intestazione. È esattamente su questo che con nftables si può applicare un limite di frequenza per indirizzo sorgente:

table inet gmod {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 8/second burst 20 packets } drop
    }
}

Il file si carica con nft -f. La priorità -10 fa sì che la regola intervenga prima della catena di filtro di UFW, e @th,64,32 legge i primi quattro byte dopo l'intestazione UDP. Con iptables classico lo stesso lavoro lo svolge un confronto u32:

iptables -A INPUT -p udp --dport 27015 \
  -m u32 --u32 "0>>22&0x3C@8=0xFFFFFFFF" \
  -m hashlimit --hashlimit-name gmod_a2s --hashlimit-mode srcip \
  --hashlimit-above 8/sec --hashlimit-burst 20 -j DROP

Un punto che quasi ogni guida in rete tralascia: non è senza connessione soltanto la query del server, lo è anche l'apertura della connessione. Un giocatore che entra invia diversi pacchetti con la stessa intestazione prima di essere in partita. Un limite troppo stretto chiude quindi fuori i nuovi giocatori, anche se il server resta raggiungibile. Parti generoso (da 8 a 15 pacchetti al secondo per indirizzo) e stringi il limite soltanto dopo aver misurato una settimana di funzionamento normale.

4. Mettere in sicurezza RCON oppure spegnerlo del tutto

Sui server Source RCON è un bersaglio ambito, e lo è per tre motivi insieme. Primo, sta sullo stesso numero di porta del gioco, solo su TCP, quindi si trova senza doverlo cercare. Secondo, il protocollo Source RCON trasmette la password in chiaro, senza TLS e senza scambio di chiavi: chi intercetta il traffico se la prende. Terzo, il guadagno è massimo, perché chi ha RCON cambia la mappa, banna tutti i giocatori, modifica la configurazione e ferma il server. Chi si impadronisce di RCON non ha più bisogno di alcuna banda.

Non lasciare mai rcon_password vuota e non inventartela a caso, basta un valore generato con openssl rand -base64 32. Contro i tentativi di accesso l'engine porta con sé un freno:

rcon_password "QUI_UNA_PASSWORD_CASUALE_LUNGA"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Così un indirizzo viene bloccato per un giorno dopo tre tentativi falliti nell'arco di 30 secondi. Due avvertenze in proposito. Primo, proprio questo meccanismo chiude fuori anche il tuo pannello di amministrazione, se lì è salvata una vecchia password: quello che chi gestisce un server segnala come "RCON di colpo non funziona più" è quasi sempre il proprio blocco. Secondo, la restrizione del firewall del punto 2 resta più efficace, perché non lascia arrivare il tentativo fino all'applicazione. Chi usa RCON solo ogni tanto lascia la porta chiusa e lavora attraverso un inoltro di porta SSH:

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

5. Limitare i messaggi di rete Lua, il disservizio autoprodotto più frequente

Una parte consistente dei disservizi di Garry's Mod segnalati come DDoS non lo è affatto. Sono sovraccarichi Lua, provocati da un singolo client collegato con pochi kilobit al secondo. Il motivo sta nella costruzione della libreria net: appena un addon registra un evento di rete con util.AddNetworkString e lo ascolta con net.Receive, qualsiasi client può far scattare quell'evento in un ciclo. Senza un limite scritto da te, il server esegue ogni singolo messaggio. Facepunch lo ha documentato più volte nelle proprie segnalazioni di errore e non ha previsto alcuna soluzione nell'engine: il limite è dichiaratamente compito di chi scrive l'addon.

Controlla quindi ogni addon, tuo o acquistato, su tre punti: un tetto per giocatore e per secondo, una verifica della lunghezza del messaggio, e che il giocatore venga ricavato lato server dal secondo parametro invece che dal contenuto del messaggio. Uno schema solido si presenta così:

util.AddNetworkString("khrp_buy")

local budget = {}

net.Receive("khrp_buy", function(len, ply)
    if not IsValid(ply) then return end
    if len > 256 then return end

    local now = CurTime()
    local b = budget[ply]

    if not b or now - b.start >= 1 then
        b = { start = now, count = 0 }
        budget[ply] = b
    end

    b.count = b.count + 1
    if b.count > 10 then return end

    KHRP.HandleBuy(ply, net.ReadString())
end)

hook.Add("PlayerDisconnected", "khrp_budget_cleanup", function(ply)
    budget[ply] = nil
end)

A questo si aggiungono due righe in server.cfg. sv_allowcslua su Garry's Mod vale 1 di serie e permette ai client di eseguire codice proprio con lua_run_cl e lua_openscript_cl: su un server pubblico quel valore va portato a 0. E sv_kickerrornum espelle i client che producono più errori lato client del numero indicato (valore predefinito 0, quindi disattivato):

sv_allowcslua 0
sv_kickerrornum 25

6. Separare i contenuti del Workshop e FastDL dal server di gioco

Su Garry's Mod gli addon del Workshop non sono un tema di contorno, sono la norma: una community DarkRP collega la propria raccolta con +host_workshop_collection e i client scaricano quei contenuti direttamente da Steam. Questo non pesa sulla tua linea. La chiave di -authkey è una chiave Steam Web API e va trattata come una password: nello script di avvio, non in un repository pubblico e non in un canale Discord.

La banda la consuma la seconda strada. Tutto ciò che non arriva dal Workshop (mappe, suoni e materiali tuoi) passa dal canale di download. Senza sv_downloadurl quel canale passa dalla porta di gioco stessa ed entra in concorrenza diretta con il traffico di gioco. Con FastDL passa invece da HTTP. Se quel webserver sta sullo stesso host e sullo stesso indirizzo IP, i due condividono la stessa linea: un'ondata di ingressi o un attacco sulla 80/TCP colpisce quindi anche il gioco. Questi valori hanno senso:

sv_downloadurl "https://fastdl.tuo-dominio.it/garrysmod/"
sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64

sv_allowupload 0 toglie ai client la possibilità di mandare file propri al server e chiude così una strada che non serve e non viene controllata. net_maxfilesize limita in megabyte la dimensione dei file trasferiti attraverso il canale di gioco. Metti FastDL, se puoi, su un altro host oppure dietro un nome proprio, così il carico non finisce sullo stesso indirizzo della porta di gioco.

7. Intercettare il flood di ingressi e l'esaurimento degli slot

L'esaurimento degli slot è un attacco che non ha bisogno di banda: chi attacca occupa tutti i posti liberi con connessioni automatiche, così i giocatori veri trovano il server pieno. Su Garry's Mod c'è un aggravante: ogni ingresso costa lavoro al server, perché lista delle risorse e gamemode vengono negoziati molto prima che il giocatore sia in partita.

Contro tutto questo funzionano quattro cose. Primo, un tetto realistico: impostare +maxplayers più in alto di quanto il tuo gamemode regga non fa che allargare la superficie di attacco. Secondo, sv_timeout, che stabilisce dopo quanti secondi senza messaggi un client viene disconnesso (nelle configurazioni diffuse 120): chi vuole liberarsi più in fretta delle mezze connessioni appese abbassa il valore. Terzo, il limite di frequenza sui pacchetti senza connessione del punto 3, perché l'apertura della connessione passa esattamente di lì. Quarto, per i gruppi chiusi, una password del server:

sv_password "gruppo_abituale_2026"
sv_timeout 90
sv_filterban 1
sv_region 3

Una whitelist vera Garry's Mod non la porta con sé: arriva tramite estensioni come ULX oppure tramite una verifica tua nell'hook CheckPassword. 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. Alleggerire il kernel: tracciamento delle connessioni e buffer di ricezione

Questo passaggio spiega i disservizi che sembrano un attacco volumetrico senza esserlo. Per il traffico UDP il kernel crea voci nel tracciamento delle connessioni (conntrack), e con indirizzi mittente falsificati ogni indirizzo significa una voce nuova. Quando la tabella è piena, il kernel scarta i pacchetti senza distinzione: l'attacco e i tuoi giocatori volano fuori insieme, e nel log di sistema compare "nf_conntrack: table full". Stato e limite li mostra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Il passo più efficace è non far tracciare affatto il traffico di gioco, perché l'engine gestisce da sé le proprie sessioni:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 27015, 27020 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 27015, 27020 } notrack
    }
}

Con iptables l'equivalente è iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK più la stessa riga per OUTPUT con --sport. Dopo questa modifica la porta ha bisogno di un'apertura esplicita, perché senza tracciamento non funziona più nessuna regola che verifichi uno stato esistente. Se poi i pacchetti arrivano più in fretta di quanto srcds riesca a prelevarli, il buffer di ricezione va in overflow, e per i giocatori sembra perdita di pacchetti su una linea libera:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Le righe vanno in un file sotto /etc/sysctl.d/ e diventano attive con sysctl --system. Se servano davvero lo dice il kernel stesso: se UdpRcvbufErrors cresce in nstat -az, allora hanno effetto. Se il contatore resta a zero, la modifica non cambia niente. È una riserva, non una protezione.

9. Mettere al sicuro i valori misurati finché tutto è normale

Il passo più importante è quello che quasi nessuno compie in anticipo: creare una base di confronto. Senza un valore di riferimento, dopo un incidente non puoi dire se 40.000 pacchetti al secondo fossero tanti oppure semplicemente sabato sera. Calcola una volta il valore normale del tuo server: 64 giocatori con cl_cmdrate 66 producono circa 4.200 pacchetti in ingresso al secondo, e tutto quello che sta ben sopra richiede una spiegazione. 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
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"

Il primo mostra pacchetti e byte al secondo, il secondo i contatori dei pacchetti scartati dall'interfaccia, il terzo i contatori di errore UDP del kernel. La quarta riga mostra soltanto i pacchetti senza connessione, cioè proprio la categoria di cui abusa un flood di query: se il contatore si riempie in pochi secondi mentre non c'è quasi nessuno collegato, hai la tua risposta. Limita sempre tcpdump 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 sul server.

Che cos'è la falla A2S reflection e mi riguarda ancora

A2S reflection è un attacco in cui il tuo server non è il bersaglio, ma lo strumento. Chi attacca invia una piccola query con indirizzo mittente falsificato a migliaia di game server, e le loro risposte, molto più grandi, confluiscono tutte sulla vittima vera. Storicamente una richiesta A2S_INFO era grande 25 byte (4 byte 0xFFFFFFFF, 1 byte 0x54, più 20 byte per la stringa "Source Engine Query"), mentre la risposta era di diverse centinaia di byte. Lo US-CERT elenca il protocollo Steam fra gli attacchi di amplificazione con un fattore di 5,5, il che significa: da un gigabit di chi attacca nascono 5,5 gigabit sulla vittima.

Valve ha chiuso questa falla a partire da novembre 2020, e lo ha fatto per due strade. Da allora i pacchetti di query senza connessione devono essere riempiti dal mittente fino a 1.200 byte, così la richiesta è più grande della risposta e il fattore di amplificazione scende sotto 1. Durante il passaggio chi gestiva un server poteva imporre in anticipo il comportamento più severo con la variabile d'ambiente STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200. In più, su A2S_PLAYER e A2S_RULES il server non risponde subito con i dati, ma con una challenge (S2C_CHALLENGE) che chi interroga deve rimandare indietro in una seconda richiesta. Chi falsifica l'indirizzo mittente quella challenge non la vede mai.

Per te ne derivano due cose. Tieni aggiornato il binario del server, perché la protezione sta nella base Steam del game server e non nella tua configurazione. E non confondere la reflection con un flood di query contro di te: contro la seconda forma funzionano soltanto il limite di frequenza del punto 3 e, oltre quello, il filtraggio nella rete davanti al server.

Dove queste misure si fermano: banda e frequenza dei pacchetti

Adesso la parte che nessun file di configurazione può risolvere. Tutto quello descritto finora gira 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ù. La seconda grandezza colpisce di solito prima: con i pacchetti più piccoli possibili, da 64 byte, in 1 Gbit/s entrano circa 1,49 milioni di pacchetti al secondo, in 10 Gbit/s circa 14,88 milioni. 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 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 tutti avevano picchi di lag".

Per dare un ordine di grandezza reale: sui server di KernelHost sono stati filtrati, fra gli altri, un UDP flood con oltre 112,2 Gbit/s e oltre 8,7 milioni di pacchetti al secondo contro un game server e un attacco multivettore con oltre 473,4 Gbit/s e oltre 41,5 milioni di pacchetti al secondo contro un server voice. 473,4 Gbit/s sono circa 470 volte un collegamento da 1 Gbit/s e restano circa 47 volte un collegamento da 10 Gbit/s. Per questo non esiste alcuna impostazione locale. Gli attacchi volumetrici devono finire nella rete, prima del server.

Che cosa mette davanti KernelHost

La protezione permanente inclusa in ogni pacchetto 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 ancora 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 esiste un tempo di commutazione durante il quale i tuoi giocatori vengono espulsi. 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. La sede è Francoforte sul Meno. Quali giochi e protocolli siano coperti lo elenca Protezione DDoS in tempo reale per server di gioco.

Advanced DDoS Protection per community sotto attacco continuo

Certi progetti non vengono colpiti ogni tanto, ma in modo mirato e per settimane, con schemi sempre diversi e sempre esattamente nell'ora di punta. 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: stabilisci che cosa è permesso sulla 27015/UDP e che cosa sulla 27015/TCP, senza dover aprire un ticket.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro durante un attacco in corso invece di aspettare la prossima finestra di manutenzione.
• Profilo di protezione adatto al singolo gioco, per Garry's Mod e per gli altri titoli Source come per profili TCP e UDP liberi per server modificati e applicazioni proprie.

Vale anche qui il modello PrePaid: nessuna durata minima, nessun preavviso di disdetta, nessun contratto e nessun costo di attivazione. Quando l'ondata di attacchi è passata, ti basta non rinnovare. Chi finora gestisce il proprio server Garry's Mod altrove ottiene questa protezione trasferendosi a KernelHost, perché il filtraggio avviene nella nostra rete e non su infrastruttura altrui.

I due livelli di protezione a confronto

Per la maggior parte delle community Garry's Mod 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 server gira, ma è sparito dal browser dei server": di solito la 27015/UDP è stata bloccata in blocco oppure limitata in modo troppo stretto. Dato che traffico di gioco e query condividono la stessa porta, una regola grossolana colpisce entrambi. Lavora invece con il confronto sui pacchetti senza connessione. Se il server resta invisibile nonostante la porta sia raggiungibile, controlla sv_setsteamaccount: senza un Game Server Login Token valido un server Garry's Mod viene fortemente penalizzato nella lista, e ogni server ha bisogno di un token proprio.

"La mia regola iptables è corretta e non ha comunque effetto": tre cause sono frequenti. La regola sta dietro le catene di UFW e non viene mai raggiunta, oppure è sparita con l'ultimo riavvio (allora servono apt-get install -y iptables-persistent e netfilter-persistent save oppure 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 mio server DarkRP va a scatti per tutti, ma la linea è libera": è quasi sempre Lua e non un attacco alla linea. Guarda nel log del server quale evento di rete arriva con frequenza anomala e controlla se l'addon relativo ha un limite per giocatore. Se sar -n DEV 1 10 e i contatori dei pacchetti scartati restano normali, non era un attacco DDoS.

"RCON di colpo non funziona più": non è un DDoS, è quasi sempre il tuo stesso blocco. Un pannello di amministrazione con una vecchia password fa scattare sv_rcon_minfailures, e sv_rcon_banpenalty blocca l'indirizzo per il numero di minuti impostato. Correggi la password, togli il blocco e poi limita la porta al tuo indirizzo.

"Ho cambiato indirizzo IP e due giorni dopo ero di nuovo offline": è la norma. Il tuo server pubblica da sé il nuovo indirizzo appena torna registrato presso il master server, e un game server senza indirizzo pubblico non ha giocatori. Un cambio di indirizzo regala da qualche ora a qualche giorno, non è una soluzione.

"Il mio fornitore precedente ha bloccato il mio indirizzo IP": quello è null-routing. Il fornitore 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.

In breve

• Un server Garry's Mod ha bisogno di esattamente una porta aperta: la 27015/UDP. Traffico di gioco e query A2S passano insieme di lì, una porta di query separata non esiste.
• RCON sta sulla 27015/TCP, trasmette la password in chiaro e va aperto esclusivamente al tuo indirizzo oppure raggiunto attraverso un inoltro di porta SSH.
• Non limitare la porta, limita i pacchetti senza connessione con l'intestazione 0xffffffff. Un blocco indiscriminato sulla 27015/UDP butta fuori i tuoi giocatori.
• Il disservizio più frequente su Garry's Mod non è un attacco DDoS, è un evento di rete senza limite: ogni evento registrato con util.AddNetworkString ha bisogno di un tetto per giocatore e per secondo.
• Con pacchetti da 64 byte una linea da 1 Gbit/s trasporta circa 1,49 milioni di pacchetti al secondo. Oltre quella soglia la perdita nasce sul router a monte e ogni regola locale diventa inefficace.
• Da KernelHost la protezione permanente a due livelli è inclusa in ogni pacchetto server senza sovrapprezzo: 17 Tbps di capacità di mitigazione nella rete di scrubbing globale e filtraggio Arbor in tempo reale da 3,2 Tbps a Francoforte sul Meno, senza null-routing.
• Chi viene preso di mira in modo continuo aggiunge la Advanced DDoS Protection a partire da 50,00 € al mese: IP di protezione dedicato, regole gestibili da te per porta e protocollo, efficaci in tempo reale.

Se il tuo server gira già da 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 ritarate. Indica subito quattro informazioni: indirizzo IP, porta, intervallo di tempo nel tuo fuso orario e che cosa vedi (i giocatori vengono espulsi, il server non compare nel browser, picchi di lag). Durante un attacco in corso ci raggiungi anche tramite la chat WhatsApp di emergenza al numero +43 650 8209883.

Chi oltre a Garry's Mod gestisce altri titoli Source trova le basi comuni in Proteggere i server CS2 e Source dagli attacchi DDoS, e come si prepara la base in modo pulito sta in Installare un game server con SteamCMD.