Team Fortress 2: proteggere un server TF2 dagli attacchi DDoS

Un server community di Team Fortress 2 che la sera, nel mezzo del round, perde tutti i giocatori insieme e poi sparisce per minuti dal browser dei server raramente ha un problema hardware. Nella maggior parte dei casi è in corso un attacco sulla 27015/UDP. Questo articolo mostra come proteggere un server TF2 dagli attacchi DDoS: prima quello che puoi fare da solo nei prossimi dieci minuti senza costi aggiuntivi, poi il punto in cui queste misure si fermano dal punto di vista fisico, e infine che cosa deve succedere prima, nella rete.

Tutte le indicazioni si riferiscono a un Source Dedicated Server installato con SteamCMD (srcds_run -game tf) 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. Se l'attacco è in corso proprio adesso: non modificare prima nulla e non riavviare il server, ma metti al sicuro i valori misurati della sezione 9. Dopo l'attacco non ci sono più.

Perché i server Team Fortress 2 hanno bisogno di protezione DDoS

Team Fortress 2 è giocabile gratuitamente dal 2011, e proprio questo sposta l'economia degli attacchi. Chi attacca ha a disposizione un numero illimitato di account usa e getta, non paga per nessuno di essi e in caso di ban non rischia nulla. Quello che in un gioco a pagamento costa denaro, qui costa un minuto.

A questo si aggiunge una particolarità che distingue TF2 dalla maggior parte degli altri giochi: dall'aggiornamento "Meet Your Match" del luglio 2016 non esiste più il Quickplay, che distribuiva automaticamente i nuovi giocatori sui server community. I nuovi giocatori finiscono in modalità Casual sui server di Valve. I server community si trovano esclusivamente attraverso il browser dei server. Chi esce da quella lista per i nuovi giocatori non esiste praticamente più, anche se il processo del server gira senza problemi. Un attacco che si limita a spingere il tuo server fuori dalla lista ha quindi già raggiunto il suo scopo.

Gli obiettivi tipici sono di conseguenza: server community attivi in permanenza con giocatori abituali (2Fort ventiquattro ore su ventiquattro, Trade, Jailbreak, Surf, Dodgeball, Mann vs. Machine), server di lega con un orario di match fisso nei circuiti di ETF2L, RGL e ozfortress, e server il cui gestore ha appena bannato qualcuno. Il motivo scatenante non è quasi mai tecnico. Che cosa sia nel dettaglio un attacco DDoS lo spiega l'articolo Che cos'è un attacco DDoS?.

Le porte di cui si tratta davvero su un server TF2

Un server TF2 ha bisogno di esattamente una porta verso l'esterno: 27015/UDP. Tutto il resto o si può disattivare, oppure va limitato, oppure lavora comunque solo in uscita. Questa tabella è la base di ogni regola firewall più avanti:

Con più istanze sulla stessa macchina i numeri salgono: 27016, 27017 e così via per il gioco, 27021 e 27022 per SourceTV. Il file di configurazione si trova in tf/cfg/server.cfg e viene riletto a ogni cambio di mappa.

Perché la porta condivisa 27015 è il punto più delicato

Su TF2 il traffico di gioco e la query al server condividono la stessa porta UDP, una porta di query separata non esiste. Una richiesta A2S_INFO è lunga esattamente 25 byte: quattro byte FF FF FF FF, un byte 0x54 e la stringa di 20 byte "Source Engine Query" con lo zero finale. La risposta, con nome del server, mappa, numero di giocatori e tag, è un multiplo di quella dimensione. L'agenzia statunitense CISA quantifica in 5,5 il fattore di amplificazione del protocollo Steam nell'alert TA14-017A.

Poiché UDP non prevede alcuna apertura di connessione e gli indirizzi mittente si possono falsificare, per anni questa è stata una falla di amplificazione aperta: chi attaccava interrogava server Source altrui indicando come mittente l'indirizzo della propria vittima, e quei server spedivano le loro risposte alla vittima. A2S_PLAYER e A2S_RULES hanno sempre richiesto una challenge ritirata in precedenza, A2S_INFO no. Solo nel dicembre 2020 Valve ha aggiunto una challenge anche per A2S_INFO: al posto della risposta il server può rispedire un S2C_CHALLENGE che chi interroga deve ripetere, dimostrando così di non avere falsificato l'indirizzo mittente.

Questo disinnesca l'amplificazione, ma non mette fine al problema. Ogni pacchetto di query continua ad arrivare da te e costa tempo di calcolo prima di essere risposto o scartato. E chi inonda direttamente il tuo server non ha comunque bisogno di alcuna amplificazione.

Che cosa puoi fare da solo prima di spendere

Questa è la sezione più lunga, e non per caso. Un server TF2 configurato bene regge con le proprie forze gli attacchi piccoli e medi, a prescindere da chi lo ospita.

1. Inventario: che cosa è in ascolto, e con quale riga di avvio

Prima di scrivere anche una sola regola, guarda che cosa offre il tuo server verso l'esterno. Non tirare a indovinare, controlla:

ss -lntup

Tutto ciò che è legato a 127.0.0.1 o a ::1 non richiede alcuna apertura. Tutto ciò che sta su 0.0.0.0 o su [::] è raggiungibile da internet, compresi il database MySQL che si è portato dietro un plugin di statistiche e il server web su cui si trovano i tuoi file FastDL. Confronta il risultato con la tua riga di avvio:

./srcds_run -game tf -console \
  -port 27015 -steamport 26901 -nohltv \
  +maxplayers 24 +map ctf_2fort +sv_pure 1 \
  +sv_setsteamaccount IL_TUO_TOKEN_GSLT

Ogni porta in quella riga è una decisione consapevole. Come si installa la base è spiegato in Installare un game server con SteamCMD.

2. Lasciare aperte solo le porte di cui TF2 ha davvero bisogno

Un server TF2 pubblico ha bisogno di esattamente un'apertura verso l'esterno, più RCON per il tuo indirizzo. Con UFW, e proprio in questo ordine, per non restare chiuso fuori dal tuo server:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'TF2 gioco 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 qui non compare di proposito: chi non trasmette avvia con -nohltv e non occupa affatto la 27020/UDP. Questo dimezza la superficie UDP di un server TF2 raggiungibile dall'esterno. Se trasmetti le partite di lega si aggiunge ufw allow 27020/udp, e allora va impostata anche una tv_password.

La guida completa, via di fuga compresa, è in Configurare il firewall UFW senza bloccarsi fuori. Se dovesse capitare comunque: sui root server KVM e sui server dedicati di KernelHost arrivi tramite la console VNC nell'area clienti, che lavora indipendentemente dalla rete del sistema ospite.

3. Limitare le query A2S senza uscire dal browser dei server

Qui si nasconde l'errore più costoso di tutto l'argomento: bloccare del tutto la 27015/UDP oppure limitarne la frequenza in modo grossolano butta fuori i tuoi stessi giocatori e chiude l'attacco nel senso voluto da chi attacca. Poiché il traffico di gioco e la query occupano la stessa porta, il confine deve passare fra i tipi di pacchetto, non sulla porta.

Per questo l'engine mette a disposizione tre variabili di console, che vanno nel file tf/cfg/server.cfg:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

La prima limita le query a cui si risponde per ogni indirizzo sorgente, la seconda la somma su tutti gli indirizzi, la terza fissa in secondi la finestra di media. Proteggono la CPU dal generare risposte inutili. I valori predefiniti cambiano a seconda del gioco e della build: find sv_max_queries nella console del server mostra quali valori conosce il tuo server.

Su TF2 il secondo valore è quello delicato: mette un tetto alle risposte su tutti gli indirizzi insieme. Se lo imposti troppo basso, durante un flood di query il tuo server smette di rispondere anche ai servizi di listing e sparisce dal browser dei server, cioè dall'unica strada per cui i nuovi giocatori ti trovano. Parti largo e stringi solo quando puoi misurare che le query legittime passano.

Un livello più in basso lo stesso traffico si può separare in modo pulito. Tutti i pacchetti senza connessione della Source Engine cominciano con quattro byte impostati (0xffffffff), il traffico dei giocatori già connessi non ha quell'intestazione. Su questo si può applicare un limite di frequenza senza toccare il traffico di gioco:

table inet tf2 {
    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 in modo che la regola agisca prima della catena di filtro di UFW, e @th,64,32 legge i primi quattro byte dopo l'intestazione UDP.

4. Intercettare i flood di pacchetti frammentati, che nel log compaiono come NET_GetLong

Questo attacco è una particolarità della Source Engine e colpisce TF2 in modo specifico, perché TF2 gira ancora oggi sul vecchio ramo dell'engine. Oltre ai normali pacchetti senza connessione, l'engine conosce i pacchetti frammentati: cominciano con FE FF FF FF invece che con FF FF FF FF e annunciano che seguirà un messaggio più grande in più parti. Il server deve tenere in memoria le parti e aspettare il resto.

Ed è proprio questo che si può sfruttare. Chi attacca spedisce in massa pacchetti parziali annunciati ma mai completi, con indirizzi mittente falsificati. Il carico della CPU sale, il gioco va a scatti e nel log del server si accumulano righe con NET_GetLong. Per farlo basta una sola macchina, di banda ne serve pochissima. I gestori lo segnalano regolarmente come attacco DDoS, anche se la linea è quasi vuota.

Poiché un client TF2 regolare ha ben pochi motivi per mandare al server pacchetti frammentati, qui un limite stretto è accettabile:

udp dport 27015 @th,64,32 0xfffffffe \
    meter tf2split { ip saddr limit rate over 5/second burst 10 packets } drop

La riga va nella stessa catena della regola della sezione 3. Uno dei pochi motivi legittimi di invio dal client lo togli inoltre di mezzo con sv_allowupload 0 (vedi sezione 7).

5. Togliere RCON dalla rete aperta

Il protocollo RCON della Source Engine trasmette la password in chiaro via TCP. Chi può leggere il percorso fra te e il server ha poi la tua password RCON, e chi ha RCON può cambiare mappa, bannare tutti i giocatori e fermare il server. Non è un problema di DDoS, è una presa di possesso, ma viene segnalata regolarmente come attacco.

Non lasciare mai rcon_password vuota e non sceglierla indovinabile: basta un valore preso da openssl rand -base64 32. A questo si aggiunge un freno contro i tentativi di accesso:

rcon_password "IL_TUO_VALORE_CASUALE"
sv_rcon_maxfailures 3
sv_rcon_minfailures 3
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Così il server blocca un indirizzo per 24 ore dopo tre tentativi falliti nell'arco di 30 secondi; find sv_rcon mostra quali variabili conosce la tua build. Resta comunque più efficace la regola firewall della sezione 2, perché non lascia arrivare il tentativo fino all'applicazione. Per l'accesso da connessioni variabili configura un inoltro locale via SSH e parla poi con RCON su 127.0.0.1:

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

6. Mettere un tetto ai rate e lasciare accesa l'ibernazione

Team Fortress 2 gira a 66,67 tick al secondo, valore fisso. Quanto traffico ne esca non lo decide il tick, ma quello che un singolo client può richiedere. Senza un tetto ogni giocatore si prende quanto il suo client pretende, e lo paghi tu con la tua banda in uscita:

sv_minrate 50000
sv_maxrate 100000
sv_mincmdrate 40
sv_maxcmdrate 66
sv_minupdaterate 40
sv_maxupdaterate 66

Fai il conto una volta: con sv_maxrate 100000 ogni giocatore può ricevere 100 kilobyte al secondo, su 24 posti sono 2,4 megabyte al secondo, cioè circa 19 Mbit/s in uscita. Se imposti sv_maxrate 0 non c'è alcun tetto. I server di lega lo fanno di proposito, un server pubblico con molti posti non dovrebbe farlo. I plugin che sbloccano il tickrate moltiplicano la frequenza dei pacchetti per giocatore e con essa lo stesso conto.

Il secondo punto viene sbagliato spesso. TF2 si addormenta non appena nessuno è connesso e in quello stato non consuma quasi CPU. Molti gestori lo disattivano perché il server "sembri sveglio". Su una macchina con più istanze questo significa che la CPU è già carica a vuoto e che un attacco colpisce un sistema già pieno. Lascia stare i valori predefiniti:

sv_hibernate_when_empty 1
sv_hibernate_postgame_delay 5
tf_allow_server_hibernation 1

7. Separare il FastDL e disattivare gli invii dai client

I server community vivono di mappe proprie, e proprio da lì nasce una seconda superficie di attacco. Senza sv_downloadurl ogni giocatore scarica i contenuti attraverso il canale di rete del gioco, quindi attraverso la stessa porta e lo stesso processo che nel frattempo calcola il match. Sono pochi kilobyte al secondo e un file dopo l'altro, e con una raccolta di mappe da 200 megabyte questo blocca il tuo server per minuti a ogni giocatore:

sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64
sv_downloadurl "https://fastdl.example.org/tf/"

net_maxfilesize vale 15 di default e si può alzare fino a un massimo di 64 megabyte. sv_allowupload 0 impedisce ai client di mandare al server file propri (per esempio gli spray) e toglie così uno dei pochi motivi legittimi per i pacchetti frammentati della sezione 4.

Decisivo è dove si trova l'host FastDL. Se sta sullo stesso indirizzo IP del server di gioco, basta un flood HTTP contro la 443/TCP per riempire la linea e soffocare con essa anche la 27015/UDP. Metti il download veloce su un altro host oppure dietro una rete di distribuzione dei contenuti: così un attacco ai file non colpisce il gioco.

8. Limitare il sistema di voto, i flood di ingressi e i plugin

Non ogni disservizio è banda. Poiché TF2 è gratuito, un attacco alla logica di gioco non costa nulla se non account: flood di ingressi che occupano ogni posto, spam vocale e in chat, e votazioni abusate che buttano fuori i giocatori regolari. I valori predefiniti di TF2 qui sono già ragionevoli, ma vengono spesso ammorbiditi:

sv_allow_votes 1
sv_vote_issue_kick_allowed 0
sv_vote_allow_spectators 0
sv_vote_creation_timer 150
sv_vote_failure_timer 300
sv_vote_quorum_ratio 0.6

Questi sono i valori standard: le votazioni sono permesse, quelle di espulsione no, gli spettatori non votano, fra due votazioni passano 150 secondi, dopo una fallita 300, e una votazione ha bisogno del 60 per cento di consensi. Chi imposta sv_vote_issue_kick_allowed 1 dovrebbe sapere che apre uno strumento di cui su un server pubblico si abusa con affidabilità.

Tutto ciò che va oltre, su TF2 arriva da SourceMod e Metamod:Source. Entrambi stanno sotto tf/addons/ e si presentano in console con meta version e sm version. A differenza di Counter-Strike 2, qui la base è matura, e i plugin per liste di ban, controllo all'ingresso e limitazione della chat sono la strada consueta. Due regole in proposito: ogni plugin è codice nello stesso processo, e un plugin che va in crash si porta dietro il server. E i plugin che portano con sé servizi web propri aprono altre porte e talvolta pubblicano proprio l'indirizzo che vuoi proteggere. sm plugins list mostra che cosa gira davvero.

Quanto vada presa sul serio la parte engine lo mostra l'aprile 2020: dopo la fuga di vecchi stati del codice sorgente di TF2 e CS:GO, grandi gestori community come Creators.TF e Red Sun hanno spento temporaneamente i loro server per timore di exploit. Tieni aggiornato il binario del server e le estensioni allineate alla versione dell'engine.

9. Misurare e registrare prima che scoppi il problema

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. Durante un incidente bastano quattro comandi:

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

Il primo comando mostra pacchetti, errori e scarti per ogni interfaccia; eseguilo due volte a dieci secondi di distanza e avrai una frequenza invece di un valore assoluto. Le due catture separano il flood di query dal flood di pacchetti frammentati e rispondono così alla domanda su quale delle due regole, quella della sezione 3 o quella della sezione 4, debba davvero agire. Limitale sempre con -c, perché una cattura a pieno carico costa a sua volta tempo di calcolo.

All'interno del server il comando di console stats fornisce in una riga il carico della CPU, il carico di rete in entrata e in uscita in kilobyte al secondo, gli FPS del server e il numero di giocatori. Se gli FPS del server scendono nettamente sotto il valore del tick mentre il numero di giocatori è normale, il server sta lavorando a qualcosa che non è il gioco. Come inquadrare i valori lo trovi in Riconoscere un attacco DDoS sul server.

Dove queste misure si fermano: banda e frequenza dei pacchetti

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.

Metti il funzionamento normale di un server TF2 pieno accanto a un attacco reale e la proporzione diventa evidente:

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 è la frequenza dei pacchetti, e colpisce di solito prima della banda: ogni pacchetto costa un passaggio attraverso lo stack di rete, anche quando subito dopo viene scartato. Un attacco che non riempie nemmeno un terzo della tua linea mette quindi comunque fuori gioco il tuo server. Chi gestisce un server lo vive così: "l'utilizzo non era nemmeno alto, eppure era sparito tutto".

Per dare un ordine di grandezza reale: sui server di KernelHost sono stati filtrati in tempo reale, fra gli altri, un UDP flood contro un game server con oltre 112,2 Gbit/s e oltre 8,7 milioni di pacchetti al secondo, e un attacco multi vettore contro un server vocale con oltre 473,4 Gbit/s e oltre 41,5 milioni di pacchetti al secondo. 473,4 Gbit/s sono circa 470 volte una connettività da 1 Gbit/s. Per questo non esiste alcuna impostazione locale.

I due freni di emergenza più diffusi non aiutano. Il null-routing toglie dalla rete l'indirizzo IP attaccato e chiude l'attacco, ma anche il tuo server. Una deviazione reattiva costa, nel tempo di commutazione, esattamente i minuti in cui si decide il match. Efficace è soltanto un filtraggio che gira in modo permanente nella rete, prima del server.

Che cosa mette KernelHost contro gli attacchi ai server TF2

La protezione permanente inclusa in ogni pacchetto server

La protezione DDoS di KernelHost è costruita su due livelli ed è attiva in permanenza dal momento della consegna, senza che tu debba ordinare, attivare 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 per un server TF2. Il filtraggio è permanente e non deve prima reagire a un attacco, quindi non c'è alcun tempo di commutazione in cui i tuoi giocatori volano fuori e il tuo server cade dal browser dei server. E non viene usato il null-routing: il tuo indirizzo IP resta in rete e vengono scartati solo i pacchetti dannosi. Quali giochi e protocolli siano coperti lo elenca Protezione DDoS per game server in tempo reale.

Advanced DDoS Protection per server sotto attacco continuo

Certi progetti non vengono colpiti ogni tanto, ma in modo mirato e per settimane, con schemi che cambiano e sempre esattamente all'orario del match. 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 separatamente che cosa è permesso sulla 27015/UDP, che cosa sulla 27020/UDP e che cosa sulla 27015/TCP, senza dover aprire un ticket.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro anche durante un attacco in corso, invece di aspettare la fine del match.
• Profilo di protezione adatto al gioco, per Team Fortress 2 e gli altri titoli Source come pure profili TCP e UDP liberi per applicazioni proprie.

L'offerta si rivolge ai server che girano presso KernelHost. Se il tuo server TF2 al momento sta altrove e viene colpito regolarmente, il trasferimento è la strada verso questa protezione.

I due livelli a confronto

Per la maggior parte dei server community TF2 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 non compare più nel browser dei server": controlla per prima cosa il Game Server Login Token. Per l'inserimento pubblico i server TF2 hanno bisogno di un token, impostato con sv_setsteamaccount e generato per l'app ID 440. Steam ritira i token che non vengono usati per 30 giorni. Un server che sparisce dopo una pausa lunga ha quindi spesso solo bisogno di un token nuovo e non viene affatto attaccato. Solo dopo entrano in gioco un sv_max_queries_sec_global troppo basso oppure una regola firewall troppo grossolana sulla 27015/UDP.

"La CPU è al 100 per cento, la linea è quasi vuota": è l'immagine tipica di un flood di query o di pacchetti frammentati. Cerca nel log del server le righe con NET_GetLong e misura con le due righe tcpdump della sezione 9 quale tipo di pacchetto sta arrivando.

"Le mie regole nftables o iptables non agiscono": tre cause sono frequenti. La regola sta dietro le catene di UFW e non viene mai raggiunta (per questo la priorità -10), oppure è sparita con l'ultimo riavvio, oppure l'attacco è volumetrico e la regola lavora correttamente su una linea che è già satura. Verifica con nft list ruleset se i contatori salgono. Se restano a zero, la regola non viene raggiunta.

"Ho cambiato indirizzo IP e il giorno dopo ero di nuovo offline": chi attacca trova il nuovo indirizzo dalla stessa fonte del vecchio. Il tuo server lo pubblica da sé non appena torna nel browser dei server, e vecchi record DNS e bot Discord con indicatore di stato fanno il resto. Cambiare indirizzo fa guadagnare ore, non è una soluzione.

"Il server va in crash in modo riproducibile senza che la banda dia nell'occhio": di solito non è un attacco DDoS, ma un plugin che non si adatta alla versione dell'engine oppure un binario del server obsoleto. sm plugins list e un confronto delle versioni sono qui più rapidi di qualsiasi regola di filtraggio.

"Dopo il periodo di inattività il server reagisce in ritardo": è l'ibernazione e non è un errore. Abbassa il carico della CPU quasi a zero finché nessuno è connesso, ed è esattamente lo stato in cui vuoi avere riserve.

"Sul server girano comandi amministrativi estranei": non è un attacco DDoS, è un accesso RCON compromesso. Cambia subito la password, limita la porta al tuo indirizzo e ricorda che la password viaggia in chiaro sulla linea.

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

• Un server TF2 ha bisogno verso l'esterno esattamente della 27015/UDP. RCON sulla 27015/TCP va limitato al tuo indirizzo, SourceTV sulla 27020/UDP si disattiva con -nohltv se non trasmetti.
• Traffico di gioco e query A2S condividono la stessa porta. Chi blocca o limita in blocco la 27015/UDP butta fuori i propri giocatori. Il confine deve passare fra i tipi di pacchetto, riconoscibili dai primi quattro byte dopo l'intestazione UDP.
• I flood di pacchetti frammentati con l'intestazione FE FF FF FF generano carico di CPU invece che banda e nel log compaiono come NET_GetLong. Su TF2 un limite stretto per questo tipo di pacchetto è accettabile.
• Da "Meet Your Match" i nuovi giocatori trovano i server community solo attraverso il browser dei server. Ogni misura che ti spinge fuori da quella lista agisce come l'attacco stesso.
• Un server pieno da 24 posti elabora circa 1.600 pacchetti in ingresso al secondo. Gli attacchi contro i game server community si collocano di norma fra 5 e 50 Gbit/s e diversi milioni di pacchetti al secondo.
• 1 Gbit/s trasporta, con i pacchetti più piccoli, circa 1,49 milioni di pacchetti al secondo. Sopra quella soglia decide esclusivamente la rete davanti al server, non una regola sul server.
• Da KernelHost la protezione permanente a due livelli è inclusa in ogni pacchetto server senza sovrapprezzo ed è attiva dalla consegna, senza null-routing. La Advanced DDoS Protection si aggiunge a partire da 50,00 € al mese, se vuoi gestire tu stesso le regole per ogni porta.

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. Indica subito quattro dati: indirizzo IP, porta, intervallo di tempo nel tuo fuso orario e che cosa vedi. Così si evita un giro di domande, e quello conta quando è in corso un match.