Proteggere un server Left 4 Dead 2 dagli attacchi DDoS

Un server Left 4 Dead 2 cade di rado nel momento comodo. Cade nell'ultimo capitolo di una campagna, nel secondo giro di un match Versus oppure esattamente quando un giocatore bannato viene respinto per la terza volta. Chi in quel momento è sotto attacco non ha bisogno di una discussione di principio sulle reti, ma di un ordine di priorità. Questo articolo mostra prima come proteggere un server Left 4 Dead 2 dagli attacchi DDoS finché si può fare con gli strumenti di bordo, poi dove queste possibilità finiscono dal punto di vista fisico, e infine che cosa deve succedere prima, nella rete.

Tutte le indicazioni si riferiscono a un server dedicato (srcds), installato con SteamCMD tramite l'App-ID 222860, 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. Un punto va detto subito, perché decide l'ordine delle cose: durante un attacco in corso non modificare nulla alla cieca e non riavviare il server prima di aver messo al sicuro i valori misurati. Dopo l'attacco non ci sono più.

Perché i server Left 4 Dead 2 sono un bersaglio DDoS conveniente

La differenza rispetto a uno sparatutto con 64 posti sta nella dimensione della partita. Una campagna cooperativa ha quattro posti per i sopravvissuti, un match Versus otto posti per entrambe le squadre insieme. Un disservizio non colpisce quindi mai singoli giocatori, colpisce sempre l'intera partita: chi interrompe una campagna al terzo capitolo su cinque ha chiuso la serata a tutti i presenti. È esattamente questo a rendere l'attacco attraente per chi lo lancia, perché non gli costa né competenze né soldi degni di nota, mentre dall'altra parte distrugge un'ora di gioco.

A questo si aggiunge il modo in cui è costruito il gioco. Left 4 Dead 2 gira sull'engine Source, e un server Source è individuabile pubblicamente con indirizzo IP e porta. È un requisito, non una svista: un server che non risponde a nessuna query non compare in nessuna lista e non viene trovato da nessuna lobby. La domanda non è quindi mai se chi attacca conosce il tuo indirizzo, ma soltanto che cosa succede quando lo prende di mira. Il traffico di gioco passa da UDP, e UDP non prevede alcuna apertura di connessione da pretendere, oltre al fatto che gli indirizzi mittente si possono falsificare. Che cosa succeda sul piano tecnico lo spiega l'articolo Che cos'è un attacco DDoS?.

Un terzo punto è tipico di Left 4 Dead 2 e non ha equivalenti in Counter-Strike, Garry's Mod o Team Fortress 2: la maggior parte dei giocatori non arriva dal browser dei server, ma dal sistema delle lobby. Una lobby composta da un massimo di quattro giocatori viene indirizzata dal matchmaking di Steam su un server dedicato, che per questo riceve una prenotazione. Quel meccanismo è allo stesso tempo il tuo filtro di accesso più efficace e una superficie di attacco in più. Entrambi gli aspetti sono descritti più avanti nel dettaglio.

Le porte di cui si tratta davvero

Un server Left 4 Dead 2 occupa esattamente una porta UDP per tutto ciò che riguarda il gioco. Lo standard è la 27015, fissata con -port oppure con +hostport nella riga di avvio:

./srcds_run -game left4dead2 -console -nohltv \
  -port 27015 \
  +ip 203.0.113.10 \
  +maxplayers 4 \
  +exec server.cfg \
  +map c1m1_hotel

La prima riga di questa tabella è il nocciolo del problema. Traffico di gioco e query del server condividono la 27015/UDP, perché su Left 4 Dead 2 una porta di query separata non esiste. Chi blocca quella porta in blocco o le applica un limite di frequenza grossolano butta fuori con lo stesso gesto i propri giocatori e porta a termine l'attacco nell'interesse di chi lo ha lanciato.

Una richiesta A2S è un pacchetto di poche decine di byte, la risposta è un multiplo di quella dimensione. Con UDP l'indirizzo del mittente si può falsificare, e così il tuo server diventa non solo vittima, ma anche amplificatore: chi attacca interroga server altrui con l'indirizzo del proprio bersaglio e dirotta lì le loro risposte. Nel dicembre 2020 Valve ha aggiunto ad A2S_INFO una richiesta preliminare (S2C_CHALLENGE) che chi interroga deve rimandare indietro prima di ricevere la risposta. Questo attenua la reflection, ma non la chiude, perché i programmi di query più vecchi continuano a essere serviti.

Che cosa puoi fare da solo prima di spendere

La parte che segue non costa nulla e vale la pena a prescindere da dove si trovi il tuo server. Non ti toglie di mezzo un attacco volumetrico, ma fa svanire nel nulla gli attacchi piccoli e medi, ed elimina i disservizi che vengono segnalati come attacco DDoS pur non essendolo.

1. Ricognizione: che cosa è davvero in ascolto

Prima di scrivere una regola, chiarisci quali servizi sono raggiungibili. Su un server Left 4 Dead 2 cresciuto nel tempo sono quasi sempre più di quanti te ne aspetti, perché accanto a srcds girano anche un webserver per le campagne, un database di statistiche e a volte un secondo server per il Versus:

ss -lntup

Tutto quello che è associato a 127.0.0.1 o a ::1 non ha bisogno di nessuna apertura. Tutto quello che è in ascolto su 0.0.0.0 o su [::] è raggiungibile da internet. Il punto di vista di chi attacca te lo dà una scansione delle porte dall'esterno, e per esperienza quella scansione si discosta da ciò che ti aspetti:

nmap -Pn -sU -sT -p 27000-27050,80,443,3306 IP.DEL.TUO.SERVER

Se la base è appena stata installata oppure vuoi ricostruirne i passaggi, l'articolo Installare un game server con SteamCMD descrive la strada da SteamCMD fino a srcds in funzione.

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

Una porta UDP verso l'esterno, una porta TCP per il tuo indirizzo, niente di più. RCON non ha nulla da fare su internet aperto, perché chi ha RCON cambia la mappa, banna tutti i giocatori e ferma il server:

ufw allow 27015/udp comment "Porta di gioco L4D2 e A2S"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

Sostituisci 203.0.113.10 con il tuo indirizzo. Se cambia di frequente, la strada giusta è un inoltro di porta SSH invece di un'apertura permanente. L'ordine con cui attivi il firewall decide se ti chiudi fuori da solo; quell'ordine, con la relativa via di ritorno, sta nell'articolo 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 raggiungi la macchina tramite la console VNC nell'area clienti, e quella console non dipende dallo stack di rete del sistema ospite.

3. Frenare la query A2S senza sparire dalla ricerca delle lobby

Qui sta l'errore più costoso di tutta la materia. Dato che traffico di gioco e query del server occupano la stessa porta, il freno deve distinguere fra le due categorie di pacchetti, non fra le porte.

Dopo le modifiche del dicembre 2020 la base Steam del game server porta con sé un limite proprio, che si imposta come variabile d'ambiente prima dell'avvio. STEAM_GAMESERVER_RATE_LIMIT_200MS=N scarta i pacchetti senza connessione (A2S_INFO, A2S_RULES, A2S_PLAYERS) di un indirizzo mittente non appena in una finestra di 200 millisecondi ne arrivano più di N. Valve indica da 25 a 75 come intervallo utilizzabile; di serie il limite è disattivato:

export STEAM_GAMESERVER_RATE_LIMIT_200MS=50
./srcds_run -game left4dead2 -console -port 27015 +exec server.cfg +map c1m1_hotel

In una unit systemd lo stesso valore va come Environment=STEAM_GAMESERVER_RATE_LIMIT_200MS=50 nella sezione [Service], altrimenti dopo il prossimo riavvio non c'è più. Questo freno interviene solo se la tua build del server porta con sé la base Steamworks aggiornata, e protegge il tempo di calcolo del tuo server, non la tua linea: i pacchetti sono comunque già arrivati.

Un livello più in basso lo stesso traffico si separa nel kernel. Tutti i pacchetti senza connessione dell'engine Source, quindi le query del server e l'apertura della connessione, iniziano con quattro byte impostati a uno (0xffffffff), mentre il traffico dei giocatori già collegati non ha questa intestazione. È su questo che con nftables si può applicare un limite di frequenza per indirizzo mittente:

table inet l4d2 {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/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. Parti generoso e stringi il limite solo quando hai la prova che le query legittime passano: da quello dipende la tua stessa voce nella lista dei server.

4. Usare il sistema delle lobby come filtro di accesso

Questa è la leva che hanno soltanto Left 4 Dead 2 e il suo predecessore. Il server decide da sé se accettare o meno connessioni al di fuori del matchmaking. Lo stabiliscono quattro direttive in server.cfg:

sv_allow_lobby_connect_only 1
sv_search_key "la-tua-chiave"
sv_steamgroup "103582791400000000"
sv_steamgroup_exclusive 2

• sv_allow_lobby_connect_only 1 ammette esclusivamente gli ingressi da una lobby di matchmaking. Un connect 203.0.113.10:27015 nella console per sviluppatori e un invito Steam vengono respinti. Il valore 0 permette entrambi.
• sv_search_key è una chiave di ricerca a tua scelta. Trova il server attraverso il matchmaking soltanto una lobby in cui sia impostata la stessa chiave. Senza quella chiave il server non compare nella ricerca pubblica.
• sv_steamgroup lega il server a un gruppo Steam e lo fa comparire fra i server di quel gruppo.
• sv_steamgroup_exclusive conosce tre livelli: 0 ammette chiunque, 1 si comporta come 0 ma richiede l'ingresso tramite una lobby, e 2 lascia passare soltanto i membri del gruppo e l'accesso diretto tramite l'indirizzo IP.

Per una community stabile la combinazione di chiave di ricerca e sv_steamgroup_exclusive 2 è il filtro di accesso gratuito più efficace che il gioco conosca. Un server pubblico non può usarla, perché un server che nessuno trova è vuoto quanto uno offline.

E adesso la parte che i testi pubblicitari lasciano volentieri fuori: queste direttive proteggono la tua logica di gioco, non la tua linea. Chi inonda la 27015/UDP non ha alcuna intenzione di entrare. I suoi pacchetti vengono rifiutati, ma sono comunque arrivati, hanno consumato banda e costato un passaggio attraverso lo stack di rete. Contro un flood di ingressi fatto di account usa e getta sv_allow_lobby_connect_only 1 funziona benissimo, contro un booter non funziona affatto.

5. La prenotazione della lobby e quando sv_force_unreserved è la scelta migliore

Una prenotazione della lobby è un'occupazione a tempo limitato del tuo server da parte di una lobby di matchmaking. Finché dura, il server risulta assegnato per le altre lobby, e scade da sé soltanto dopo un po'. Per un server con quattro posti è una risorsa scarsa: a differenza di uno sparatutto con 32 o 64 posti, basta pochissimo per bloccare una partita.

Chi non gestisce il proprio server attraverso il matchmaking toglie del tutto questa superficie:

sv_force_unreserved 1
sv_allow_lobby_connect_only 0

sv_force_unreserved 1 fa sì che il server non risponda più alle richieste di prenotazione del sistema delle lobby e rifiuti gli ingressi con un contrassegno di prenotazione. La stessa impostazione ti serve comunque se con L4DToolZ gestisci più di quattro posti cooperativi, perché altrimenti la lobby ottiene una prenotazione appena i primi quattro posti sono occupati, e i posti restanti rimangono irraggiungibili. Il rovescio della medaglia è chiaro: i tuoi giocatori entrano allora soltanto dal browser dei server oppure con connect.

Scegli consapevolmente una delle due modalità di funzionamento. Il misto fra matchmaking a metà aperto e ingresso diretto a metà aperto è la variante che riunisce gli svantaggi di entrambe.

6. Mettere in sicurezza RCON

Una porta RCON aperta con una password debole non è un problema di DDoS, è una presa di controllo. Non lasciare mai rcon_password vuota e non inventartela a caso, basta un valore generato con openssl rand -base64 32. I titoli Source portano in più un freno contro i tentativi di accesso:

rcon_password "QUI_UN_VALORE_CASUALE"
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; find sv_rcon nella console del server mostra quali di queste variabili conosce la tua build. La restrizione del firewall del punto 2 resta comunque più efficace, perché non lascia arrivare il tentativo fino all'applicazione. Se RCON non ti serve, lascia la password vuota: in quel caso la parte TCP della 27015 non è in ascolto.

7. Spostare le campagne custom invece di servirle dalla porta di gioco

Le campagne custom sono il motivo per cui Left 4 Dead 2 si gioca ancora dopo quindici anni, e insieme una fonte di carico che in questa forma su Counter-Strike non esiste. Una campagna è un pacchetto VPK con mappe, modelli, texture e suoni, quindi un multiplo di quanto pesa una singola mappa competitiva.

La strada comoda per i giocatori è il Workshop di Steam: il pacchetto arriva allora da Steam e non dal tuo server, e non ti costa banda. Se invece distribuisci tu file sciolti, la distribuzione va su un webserver e non sulla porta di gioco:

sv_allowdownload 1
sv_allowupload 0
sv_downloadurl "https://cdn.example.org/l4d2/"
sv_consistency 1

I file per sv_downloadurl vanno sul webserver come archivio bzip2, quindi da miamappa.bsp si passa a miamappa.bsp.bz2. Senza sv_downloadurl srcds manda i file da sé attraverso la connessione di gioco, e allora vale questo: ogni tentativo di connessione di un nuovo giocatore ti costa il download completo, e ogni interruzione a metà download pure. È un modo estremamente economico di riempire una linea, e in nessuna statistica assomiglia a un attacco.

Tre punti in proposito, di quelli che nella pratica fanno male. sv_allowupload 0 va impostato, perché gli upload dal client al server non ti servono. Se il webserver per sv_downloadurl sta sullo stesso host del gioco, download e traffico di gioco condividono la stessa linea e lo stesso indirizzo IP, e un attacco sulla 443/TCP colpisce allora anche la partita in corso. E sv_consistency 1 non è una protezione contro gli attacchi, ma contro i file client difformi; disattivalo soltanto se una campagna altrimenti non parte in modo dimostrabile.

8. SourceMod, Metamod e le estensioni

Una parte consistente dei disservizi segnalati come DDoS non lo è affatto. Sono crash e picchi di carico che un singolo client provoca, perché nel binario del server o in un'estensione c'è una falla aperta. Contro questo non serve banda, serve manutenzione:

• Tieni Metamod:Source e SourceMod allineati alla versione dell'engine. Left 4 Dead 2 continua a ricevere aggiornamenti, e un'estensione non compatibile è il motivo più frequente dei crash subito dopo un update.
• Usa Left4DHooks invece di interventi tuoi. Gli eventi tipici di L4D2 sono raccolti in questa estensione. Interventi propri nelle stesse funzioni sono la strada più rapida verso un binario del server che si arrende a certe sequenze di pacchetti.
• Usa L4DToolZ solo in modo consapevole. L'estensione alza i limiti di posti fissati nel gioco. Ogni posto in più è un giocatore in più che produce tempo di calcolo, e insieme al sistema delle lobby richiede sv_force_unreserved 1.
• Meno estensioni. Ogni plugin è codice nello stesso processo. Le estensioni con servizi web propri aprono altre porte e spesso pubblicano proprio l'indirizzo che vuoi proteggere.

I ban vanno salvati in modo permanente, altrimenti dopo il riavvio spariscono. Per questo i titoli Source hanno banid con writeid e addip con writeip, e i file prodotti vengono riletti con exec banned_user.cfg ed exec banned_ip.cfg.

9. Alleggerire il tracciamento delle connessioni e il buffer di ricezione

Questo punto viene spesso trascurato e spiega 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. Stato e limite li mostra un'occhiata:

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 notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport 27015 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 i pacchetti arrivano più in fretta di quanto srcds riesca a prelevarli, va in overflow anche il buffer di ricezione, 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

Il file lo metti sotto /etc/sysctl.d/ e lo attivi con sysctl -p. Se quei valori 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.

10. Misurare, per non dover tirare a indovinare durante l'attacco

Durante un attacco la domanda più importante è: quanto arriva, su quale porta, ed è traffico di query oppure di gioco. Bastano quattro comandi:

ip -s link show eth0
nstat -az | grep -i udp
sar -n DEV 1 10
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"

Il primo comando eseguilo due volte a dieci secondi di distanza, così ottieni una frequenza invece di un valore assoluto. L'ultima 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. Tieni la cattura breve, perché sotto carico consuma a sua volta tempo di calcolo. Come interpretare i valori sta nell'articolo Riconoscere un attacco DDoS sul server.

Il passo più importante è però quello che quasi nessuno compie in anticipo: creare una base di confronto finché tutto funziona normalmente. Senza un valore di riferimento, dopo un incidente non puoi dire se 40.000 pacchetti al secondo fossero tanti oppure semplicemente venerdì sera con il server Versus pieno.

Dove queste misure si fermano

Ora la parte onesta. Tutto quello descritto finora entra in funzione soltanto quando i pacchetti sono arrivati sulla tua scheda di rete. 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. Con la dimensione di pacchetto più piccola possibile, questa linea trasporta circa 1,49 milioni di pacchetti al secondo, una linea da 10 Gbit/s circa 14,88 milioni. È il limite fisico superiore, indipendente da CPU, kernel e firewall. Un normale kernel di server elabora, a seconda del processore e della scheda di rete, qualche centinaio di migliaia di pacchetti al secondo 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 era sparito tutto".

Di fronte a questo ci sono gli attacchi reali. Due esempi dall'esercizio quotidiano di KernelHost, entrambi filtrati in tempo reale: un UDP flood contro un game server sulla 7777/UDP con oltre 112,2 Gbit/s e oltre 8,7 milioni di pacchetti al secondo, e un attacco multivettore contro un server voice sulla 9987/UDP con oltre 473,4 Gbit/s e oltre 41,5 milioni di pacchetti al secondo. Fai il confronto con la tua linea: 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 i due freni d'emergenza più diffusi non sono soddisfacenti. Il null-routing (blackholing) toglie dalla rete l'indirizzo IP attaccato e chiude sì l'attacco, ma chiude anche il tuo server: per i tuoi giocatori il risultato è identico a un attacco riuscito. Una deviazione reattiva del traffico consuma, nel tempo di commutazione, esattamente i minuti in cui si decide la campagna. L'unica cosa efficace è un filtraggio che giri in modo permanente nella rete, davanti al 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, molto 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 dal layer 3 al 7, pacchetto per pacchetto.

Due caratteristiche sono decisive. Primo, il filtraggio gira in modo permanente, quindi non esiste un tempo di commutazione durante il quale i tuoi giocatori vengono espulsi. Secondo, non viene usato il null-routing: l'indirizzo IP attaccato resta in rete e vengono scartati soltanto i pacchetti dannosi. La protezione è inclusa in ogni pacchetto server senza sovrapprezzo, senza un pacchetto di protezione separato e senza configurazione, ed è attiva dalla consegna. I server si trovano nel maincubes Premium Datacenter di Francoforte sul Meno. Quali giochi e protocolli siano coperti lo elenca l'articolo Protezione DDoS in tempo reale per server di gioco.

Advanced DDoS Protection per progetti sotto attacco continuo

Certi progetti non vengono colpiti ogni tanto, ma in modo mirato e per settimane, con schemi sempre diversi e sempre esattamente nella serata concordata per la campagna. 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:

• Un IP di protezione dedicato. Il tuo server viene spostato su quell'indirizzo all'interno della nostra rete, senza che tu debba modificare nulla dalla tua parte.
• Regole di protezione gestibili da te per porta e protocollo. Nell'area clienti stabilisci quale porta viene filtrata con quale profilo, quindi la 27015/UDP in modo diverso dal webserver che distribuisce le tue campagne.
• Le modifiche hanno effetto in tempo reale, senza ticket e senza attese. Puoi quindi correggere il tiro anche durante un attacco in corso.
• Un profilo di protezione adatto al singolo gioco. Per Left 4 Dead 2 e gli altri titoli Source come per oltre 40 altri giochi e protocolli, più profili TCP e UDP liberi per i server modificati.

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.

I due livelli a confronto

Per la maggior parte dei progetti Left 4 Dead 2 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 è sparito dalla ricerca delle lobby ma continua a girare: di solito la 27015/UDP è stata bloccata in blocco oppure limitata in modo troppo stretto, e dato che traffico di gioco e query condividono la stessa porta, una regola grossolana colpisce entrambi. Lavora invece con un confronto sui pacchetti senza connessione. Se la porta è raggiungibile e il server resta comunque invisibile, controlla sv_search_key, sv_steamgroup_exclusive, sv_lan 0 e sv_region 255, e verifica se l'avvio è avvenuto per errore con -nomaster.

Nella console del server compare di continuo "Invalid split packet length": non è un attacco volumetrico, è un pacchetto di rete composto male, spedito in rapida successione. Il traffico resta minuscolo, eppure il server lagga. Verifica prima di tutto se la banda è davvero anomala e porta il binario del server e le estensioni all'ultima versione. Qui la banda non serve a nulla.

Tutti i giocatori hanno ping alto ma la linea non è satura: questo indica frequenza dei pacchetti e non volume. Guarda i pacchetti scartati in ip -s link show e i contatori UDP in nstat -az. Se nel log di sistema compare nf_conntrack: table full, togli la porta di gioco con notrack.

La regola del firewall è corretta e non ha comunque effetto: verifica con iptables -L INPUT -n -v se i contatori dei match salgono. Se restano a zero, la regola non viene raggiunta, perché sta dietro le catene di UFW oppure è andata persa con l'ultimo riavvio. Se salgono e non cambia nulla, la linea davanti al server è satura, e da lì in poi serve soltanto il filtraggio nella rete.

Il server non accetta più giocatori anche se ci sono posti liberi: di solito è rimasta appesa una prenotazione della lobby. O gestisci il server in modo coerente attraverso il matchmaking, oppure imposti sv_force_unreserved 1 e fai entrare i tuoi giocatori dal browser dei server. Con più di quattro posti cooperativi e L4DToolZ questa impostazione è comunque obbligatoria.

I nuovi giocatori caricano all'infinito e intanto la linea è satura: allora srcds distribuisce da sé i file delle campagne attraverso la porta di gioco. Imposta sv_downloadurl su un webserver e metti lì i file come archivio bzip2, oppure indirizza i tuoi giocatori al Workshop di Steam.

L'attacco si ferma dopo un cambio di IP e torna dopo uno o due giorni: è la norma, perché il tuo server pubblica da sé il nuovo indirizzo appena torna registrato, e un record DNS dimenticato o un bot Discord con indicatore di stato fanno il resto. Un cambio di IP regala qualche ora, non una soluzione.

Sul server girano comandi di amministrazione altrui: non è un attacco DDoS, è un accesso RCON compromesso. Cambia subito la password e limita la parte TCP della 27015 al tuo indirizzo.

In breve

• Un server Left 4 Dead 2 ha bisogno di esattamente una porta aperta verso l'esterno: la 27015/UDP. Traffico di gioco e query A2S se la dividono, una porta di query separata non esiste.
• La 27015/TCP è RCON e va riservata esclusivamente al tuo indirizzo. Chi non usa RCON lascia rcon_password vuota.
• Il sistema delle lobby è il filtro di accesso gratuito più efficace che il gioco conosca: sv_allow_lobby_connect_only 1, una sv_search_key tua e sv_steamgroup_exclusive 2 escludono tutto ciò che non passa dal matchmaking. Filtra gli ingressi, non i pacchetti.
• Le campagne custom vanno nel Workshop di Steam oppure dietro sv_downloadurl, mai sulla porta di gioco. Altrimenti ogni tentativo di connessione interrotto si paga con la tua banda.
• Il limite di frequenza deve distinguere fra i pacchetti senza connessione (che iniziano con 0xffffffff) e il traffico di gioco. Una regola grossolana sulla 27015/UDP butta fuori i tuoi stessi giocatori.
• Con pacchetti da 64 byte una linea da 1 Gbit/s trasporta circa 1,49 milioni di pacchetti al secondo. Oltre quella soglia decide soltanto la rete davanti al server, nessuna impostazione sul server stesso.
• Da KernelHost filtrano in modo permanente e senza sovrapprezzo 17 Tbps di scrubbing globale e un filtraggio Arbor in tempo reale da 3,2 Tbps a Francoforte sul Meno, senza null-routing e senza tempo di commutazione.

Se il tuo progetto gira già da KernelHost, il filtraggio è attivo senza che tu debba fare nulla. Se noti comunque delle anomalie, apri un ticket di supporto, così il nostro team ritara le regole di filtraggio per il tuo indirizzo IP. Durante un attacco in corso ci raggiungi anche tramite la chat WhatsApp di emergenza al numero +43 650 8209883. 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 nella ricerca delle lobby, ping alto). Così eviti un giro di domande di chiarimento, e quel giro pesa mentre una campagna è in corso.

Se ospiti altrove e vieni preso di mira di frequente, il trasferimento a KernelHost è la strada più breve rispetto a qualsiasi altra regola su un server la cui linea finisce prima. La protezione permanente fa parte di ogni pacchetto server, non è un extra da acquistare solo quando serve.