Proteggere un server DayZ dagli attacchi DDoS

Un server DayZ che di sera, nel bel mezzo della partita, espelle tutti i giocatori e poi sparisce per minuti dal browser dei server raramente ha un problema hardware. Di solito è in corso un attacco, e parte esattamente quando sono online più giocatori oppure quando è previsto il riavvio programmato. Chi vuole proteggere il proprio server DayZ dagli attacchi DDoS ha quindi bisogno di entrambe le cose: aperture di porte pulite sul server e un filtraggio nella rete davanti. Questo articolo mostra prima che cosa puoi mettere in sicurezza da solo senza costi aggiuntivi, poi dove queste misure si fermano dal punto di vista tecnico e infine che cosa deve succedere davanti al server.

Tutte le indicazioni si riferiscono a un server DayZ dedicato proprio, con serverDZ.cfg, sia che giri su Windows Server sia che giri su Debian e Ubuntu attraverso uno strato di compatibilità. Bohemia Interactive non distribuisce un programma server nativo per Linux pronto alla produzione per il ramo stable, e la build sperimentale per Linux accetta esclusivamente client sperimentali. I comandi Linux sono scritti per root; se lavori come utente normale, anteponi sudo.

Se l'attacco è in corso proprio adesso: non modificare nulla nella serverDZ.cfg e non riavviare il server. Un riavvio di DayZ ricarica le mod e l'economia centrale e ti costa diversi minuti in cui il server è offline di sicuro. Metti prima al sicuro i valori misurati (vedi il paragrafo "Registrare i log"), perché dopo l'attacco non ci sono più.

Perché i server DayZ sono così spesso bersaglio di attacchi DDoS

DayZ mette insieme diverse caratteristiche che fanno di un server un bersaglio comodo. Primo, un server della community pubblica il proprio indirizzo di sua iniziativa: per comparire nel browser dei server del gioco e nel DZSA Launcher deve rispondere alle richieste Steam, e quella risposta contiene indirizzo IP e porta in chiaro. Chi attacca non deve quindi scoprire nulla, deve solo leggere una lista.

Secondo, la giornata tipo di un server DayZ è pubblica. Praticamente tutti i progetti si riavviano automaticamente ogni tre o quattro ore, lo annunciano con un messaggio in chat e scrivono il piano nel Discord. Un attacco che cade esattamente in quella finestra ha un effetto doppio: il server è comunque già irraggiungibile, e i giocatori che restano appesi nell'area di attesa vanno altrove.

Terzo, la posta in gioco per i giocatori è alta. In DayZ un disservizio nel minuto sbagliato non significa solo frustrazione, ma equipaggiamento perso, raid interrotti e una base che resta senza difesa nel mondo. Proprio per questo i committenti più frequenti sono giocatori bannati, gruppi rivali e progetti concorrenti. Un attacco tramite uno dei soliti servizi booter non costa a chi lo lancia né competenze né soldi degni di nota.

Quarto, tutto il traffico di DayZ passa da UDP. UDP non prevede alcuna apertura di connessione da pretendere e l'indirizzo mittente si può falsificare. Chi attacca non deve quindi né entrare nel tuo server né interrogarlo in modo corretto per generare carico. Che il fenomeno tocchi persino il produttore lo ha mostrato il febbraio 2025: i servizi online di Bohemia Interactive per DayZ e Arma Reforger sono rimasti sotto attacco DDoS per oltre una settimana, confermato il 3 febbraio 2025 e ancora non terminato il 6 febbraio 2025, e i server della community ne sono stati coinvolti. Che cosa sia nel dettaglio un attacco DDoS lo spiega l'articolo Che cos'è un attacco DDoS?.

Le porte di un server DayZ: tabella dei fatti

Un server DayZ parla esclusivamente UDP. Non esiste una porta di gioco TCP. L'unico valore davvero fisso in DayZ è la 2302/UDP come porta di gioco, tutto il resto è configurabile e cambia a seconda dell'hoster. Guarda quindi nella tua riga di avvio e nella tua serverDZ.cfg invece di affidarti a un valore predefinito.

Due valori creano confusione con regolarità, quindi ecco la spiegazione. Lo Steam Query Port: la configurazione di esempio fornita da Bohemia imposta steamQueryPort = 2305;, mentre buona parte degli hoster usa la 27016/UDP. Entrambi i valori sono validi, conta solo quello che sta nel tuo file. Il BattlEye RCon Port: qui non esiste proprio nessuno standard vincolante. La regola empirica diffusa è porta di gioco più tre, quindi 2305, altri hoster impostano 2310. Da DayZ 1.13 BattlEye valuta in modo affidabile il parametro RConPort nella BEServer_x64.cfg, prima la porta era difficile da prevedere.

Da qui deriva una trappola in cui cadono molti operatori: non impostare mai steamQueryPort e RConPort sullo stesso valore. Se la tua configurazione prevede 2305 per la richiesta Steam, RCon va su un'altra porta, per esempio 2310.

Perché lo Steam Query Port è la porta più delicata

Lo Steam Query Port risponde alle tre richieste A2S_INFO, A2S_PLAYERS e A2S_RULES. A2S_INFO fornisce nome del server, mappa, numero di giocatori e versione, A2S_PLAYERS i nomi dei giocatori collegati, A2S_RULES le variabili del server impostate. Ognuna di queste risposte è nettamente più grande della richiesta che l'ha provocata, ed è proprio questo a rendere la porta pericolosa due volte.

Per te come bersaglio significa: chi attacca può tenere occupata la tua porta di query con pochi byte per richiesta, mentre il tuo server ogni volta compone e spedisce una risposta completa. Per i terzi significa: chi attacca può interrogare il tuo server con un indirizzo mittente falsificato e dirigere le risposte sul proprio vero obiettivo. Il tuo server non è allora solo vittima, ma amplificatore. Nel dicembre 2020 Valve ha perciò aggiunto ad A2S_INFO una richiesta di challenge: il server risponde prima con un numero casuale che chi interroga deve rimandare indietro. Questo attenua l'amplificazione, ma non la elimina, perché non tutte le richieste passano da quella strada.

DayZ ha qui una particolarità che altri giochi non hanno: a interrogarti sono due liste di server separate, il browser dei server della community integrato nel gioco e il diffusissimo DZSA Launcher. Chiudere semplicemente la porta di query non è quindi un'opzione, perché così il tuo progetto sparisce da entrambe le liste, anche se la connessione diretta continua a funzionare. Limitare invece di chiudere è la risposta giusta.

Che cosa puoi fare da solo prima di spendere

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

1. Inventario: quali porte apre davvero il tuo server DayZ

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

ss -lnup
ss -lntup

Su Windows Server il prompt dei comandi restituisce lo stesso quadro:

netstat -ano -p UDP | findstr "2302 2303 2304 2305 27016"

Interessante è la colonna con l'indirizzo locale. 0.0.0.0:2302 significa "raggiungibile da tutta internet", 127.0.0.1:2310 significa "solo in locale" e non richiede alcuna apertura. Poi leggi i valori reali direttamente dai tuoi file di configurazione, invece di affidarti a una guida:

grep -iE "steamQueryPort|maxPlayers|password|enableWhitelist|verifySignatures" serverDZ.cfg
grep -iE "RConPort|RestrictRCon" battleye/BEServer_x64.cfg

Il punto di vista di chi attacca lo dà una scansione delle porte UDP dall'esterno, eseguita da un altro computer:

nmap -Pn -sU -p 2302-2310,27015-27020 IP.DEL.TUO.SERVER

2. Aprire solo ciò di cui hanno davvero bisogno la riga di avvio e la serverDZ.cfg

A DayZ bastano due aperture verso l'esterno: il blocco della porta di gioco e la porta di query. Tutto il resto viene limitato al tuo indirizzo oppure non viene proprio pubblicato. 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 2302:2305/udp comment 'DayZ porta di gioco'
ufw allow 27016/udp comment 'DayZ Steam Query'
ufw allow from 203.0.113.10 to any port 2310 proto udp comment 'BattlEye RCon'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sostituisci 203.0.113.10 con il tuo indirizzo e la 27016 con il valore che sta davvero nella tua riga steamQueryPort. La guida completa, via di fuga compresa, la trovi in Configurare il firewall UFW senza bloccarsi fuori. Su un server Windows vale lo stesso principio: una regola in ingresso per ogni gruppo di porte, desktop remoto limitato al tuo indirizzo, tutto il resto bloccato.

3. Limitare lo Steam Query Port invece di chiuderlo

Un limite massimo per indirizzo sorgente separa le liste di server vere dai flood di richieste. Un browser dei server ti interroga al ritmo di un secondo, chi attacca al ritmo di un millisecondo:

iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name dayz_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name dayz_game --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

La prima regola scarta le richieste Steam oltre le dieci al secondo sostenute dalla stessa sorgente, la seconda i pacchetti di gioco oltre i 600 al secondo. Entrambi i numeri sono valori di partenza, non verità assolute. Un server pieno con 60 giocatori produce molti più pacchetti di uno vuoto, e chi stringe troppo butta fuori i propri giocatori oppure sparisce dalla lista dei server. Misura prima una settimana di funzionamento normale.

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 regole di questo tipo vanno in /etc/ufw/before.rules, altrimenti al prossimo ufw reload spariscono. In più la libreria server di Steam conosce un freno proprio per i pacchetti senza connessione: la variabile d'ambiente STEAM_GAMESERVER_RATE_LIMIT_200MS scarta tutti i pacchetti A2S di un indirizzo non appena in una finestra di 200 millisecondi ne arrivano più del valore impostato.

Il terzo punto non costa nulla: se il tuo bot Discord o la pagina del tuo progetto mostrano il numero di giocatori, non interrogare il server dal visitatore, ma salva il risultato in cache a intervalli fissi. Così una pagina di stato molto visitata genera un'interrogazione per intervallo invece di una per visitatore.

4. Togliere BattlEye RCon dalla rete aperta

BattlEye è la componente anti-cheat di DayZ e si attiva nella serverDZ.cfg con BattlEye = 1;. L'amministrazione remota sta invece in un file a parte, la BEServer_x64.cfg nella directory di BattlEye accanto a BEServer_x64.dll, che la riga di avvio imposta con -BEpath=:

RConPassword UnaPasswordLungaECasuale
RConPort 2310
RestrictRCon 0

Tre regole in proposito. Primo: la porta RCon è UDP, non TCP. Una regola firewall che per sbaglio dice proto tcp non filtra nulla e allo stesso tempo manda a vuoto gli strumenti di amministrazione. Secondo: limita la porta agli indirizzi dei tuoi amministratori. Chi non ha un indirizzo fisso chiude del tutto la porta dall'esterno e avvia lo strumento di amministrazione direttamente sul server, raggiungibile via SSH o desktop remoto. Terzo: RestrictRCon 1 limita i comandi eseguibili via RCon ed è l'impostazione giusta non appena più di una persona ha accesso.

Una porta RCon aperta è due cose insieme: un invito a provare password una dopo l'altra e un'ulteriore porta UDP che si può inondare. Entrambe spariscono non appena l'apertura vale solo per una manciata di indirizzi.

5. Coda di accesso, whitelist ed esaurimento degli slot

DayZ non elabora le connessioni tutte contemporaneamente, ma attraverso una coda. A governarla sono cinque valori nella serverDZ.cfg:

maxPlayers = 60;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 100;
guaranteedSlots = 10;
maxPing = 200;

loginQueueConcurrentPlayers stabilisce quanti giocatori vengono fatti entrare contemporaneamente (valore predefinito 5), loginQueueMaxPlayers limita la coda stessa (valori usuali fra 100 e 500). È esattamente qui che si innesta l'esaurimento degli slot: chi attacca non ha bisogno di banda, gli bastano abbastanza account o tentativi di connessione per occupare la coda. I giocatori veri non passano più, anche se il server dal punto di vista tecnico funziona perfettamente. guaranteedSlots riserva posti per il tuo team, così in quella situazione riesci ancora a entrare sul server.

Contro questo aiuta la whitelist integrata. Si attiva con enableWhitelist = 1; e poi legge il file profiles/whitelist.txt, un ID Steam64 per riga. Ogni ID non elencato viene respinto al momento della connessione. Il file viene letto all'avvio del server, quindi le modifiche richiedono un riavvio. Una password aggiuntiva nella serverDZ.cfg ha un effetto simile, ma è più debole, perché una password passa di mano in mano e un ID Steam64 no.

Una cosa però deve essere chiara: una whitelist protegge i tuoi posti giocatore, non la tua linea. Chi inonda il tuo server non vuole affatto entrare. I suoi pacchetti vengono respinti, ma sono comunque arrivati, ed è esattamente questo il punto.

6. Mod, verifica delle firme e la finestra dopo il riavvio

In DayZ le mod non sono solo una questione di comodità, sono parte della superficie di attacco. Quattro impostazioni nella serverDZ.cfg vanno messe in ogni caso:

verifySignatures = 2;
forceSameBuild = 1;
allowFilePatching = 0;
BattlEye = 1;

verifySignatures = 2 verifica ogni file PBO contro la firma .bisign corrispondente e per farlo ha bisogno dei file .bikey giusti nella cartella keys. forceSameBuild = 1 pretende esattamente la stessa versione del gioco che gira sul server. allowFilePatching = 0 respinge i client che partono con file di gioco modificati. Nessuna di queste impostazioni ferma un attacco volumetrico, ma tutte e tre chiudono la strada attraverso cui un client manipolato manda fuori giri il tuo server.

Il secondo punto è il più importante e viene quasi sempre trascurato: la fase di avvio. All'avvio un server DayZ carica prima la lista delle mod dalla riga di avvio e poi l'economia centrale con tutte le tabelle del loot. Su un server molto modificato sono facilmente diversi minuti in cui il server non risponde a una sola richiesta Steam:

./DayZServer -config=serverDZ.cfg -port=2302 -profiles=./profiles -BEpath=./battleye -mod=@CF;@IlTuoMod;@UnAltroMod -cpuCount=4 -dologs -adminlog -netlog -freezecheck

Poiché praticamente ogni progetto si riavvia ogni tre o quattro ore e per giunta annuncia il piano, la finestra temporale è banale da centrare per chi attacca. Tre contromisure sono efficaci e non costano nulla. Tieni la lista delle mod più corta possibile, perché ogni mod in più allunga proprio quella finestra. Metti gli orari di riavvio su valori sfalsati invece che sull'ora esatta. E misura una volta quanto dura davvero il tuo avvio, invece di stimarlo: con timeStampFormat = "Full"; e un logFile impostato la durata resta poi scritta nel log.

7. Tracciamento delle connessioni, buffer di ricezione e parametri del kernel

Un collo di bottiglia spesso trascurato è il tracciamento delle connessioni del kernel. UDP non conosce connessioni, ma il kernel crea comunque una voce per ogni coppia di indirizzo sorgente e destinazione. Se la tabella si riempie, il server scarta anche i pacchetti legittimi e nel log compare "nf_conntrack: table full". Valore attuale e limite li mostra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Per un game server puro la soluzione pulita è non far tracciare affatto il traffico di gioco, e insieme aumentare i buffer di ricezione e la coda della scheda di rete:

iptables -t raw -A PREROUTING -p udp --dport 2302 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 2302 -j NOTRACK
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=1048576
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.netfilter.nf_conntrack_max=524288

Attenzione: NOTRACK e le regole con stato si escludono a vicenda. Chi esclude la porta di gioco dal tracciamento non può più usare per quella porta alcuna regola con -m conntrack --ctstate, altrimenti l'apertura non funziona più. Per renderli permanenti i valori di sysctl vanno in /etc/sysctl.d/, altrimenti dopo il prossimo riavvio spariscono.

8. Il tuo indirizzo IP è nel browser dei server

Qui conviene l'onestà invece dei desideri: l'indirizzo IP di un server DayZ pubblico non si può tenere segreto. Lo conosce ogni giocatore che si è collegato anche una sola volta, il browser dei server lo pubblica e il DZSA Launcher lo tiene in cache. Cambiare indirizzo ti fa guadagnare ore, raramente giorni.

Più efficaci sono due abitudini. Non pubblicare in aggiunta l'indirizzo IP grezzo da nessuna parte, quindi né nel messaggio Discord fissato in alto né sulla pagina del progetto. E fai ordine nei tuoi record DNS: un record A dimenticato che punta all'indirizzo precedente rende inutile qualsiasi cambio, ed è proprio lì che la maggior parte dei cambi fallisce. Chi lascia ancora girare un servizio di stato sul vecchio server rivela insieme anche il nuovo indirizzo.

9. Registrare i log, per non dover indovinare durante un attacco

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 sabato sera. Sul lato server per questo attivi i log integrati:

timeStampFormat = "Short";
logAverageFps = 300;
logPlayers = 300;
logFile = "server_console.log";

logAverageFps è il valore più onesto che DayZ fornisce. Se la frequenza dei fotogrammi del server crolla mentre il numero di giocatori resta uguale, è un problema di mod o di economia. Se la frequenza resta stabile mentre i giocatori vengono espulsi, è la rete. Sul lato sistema le misurazioni restano sempre attive con apt-get install -y vnstat sysstat, e 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 2302 -c 200 -q

Per tcpdump vale una regola: limita sempre 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.

Dove finisce l'autodifesa: 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.

In DayZ la frequenza dei pacchetti colpisce spesso prima della banda, e il motivo è semplice: il traffico di gioco è fatto di molti pacchetti UDP piccoli, non di pochi grandi. Un attacco che non riempie nemmeno un terzo della tua linea può quindi mettere comunque 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 e volavano fuori uno dopo l'altro".

Gli attacchi volumetrici devono finire nella rete, prima del server. Non è un'affermazione di prodotto, è fisica.

Protezione DDoS per DayZ: che cosa mette davanti KernelHost

La protezione permanente che gira su ogni server

La protezione DDoS di KernelHost è costruita su due livelli ed è permanentemente attiva, senza che tu debba accendere, 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 progetti 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 separatamente che cosa è permesso sulla 2302/UDP, che cosa sulla porta di query e che cosa sulla porta RCon. In DayZ è proprio questa separazione a fare la differenza, perché traffico di gioco e traffico di richieste hanno un aspetto completamente diverso.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro durante un attacco in corso invece di aspettare un ticket.
• Profilo di protezione adatto al gioco, anche per server molto modificati e per applicazioni proprie su porte TCP o UDP a piacere.

I due livelli a confronto

Per la maggior parte dei progetti DayZ 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. Chi al momento fa girare il proprio server DayZ da un'altra parte non può aggiungere la protezione a posteriori: fa parte della rete e vale per i server che si trovano da KernelHost. La strada è un trasloco, non un prodotto aggiuntivo.

Errori frequenti e soluzioni

"Il mio server è sparito dal DZSA Launcher e dal browser dei server, ma con la connessione diretta ci entro": nella maggior parte dei casi non è un attacco, è la porta di query. O in steamQueryPort sta un valore diverso da quello nel firewall, oppure un limite di frequenza troppo stretto scarta le richieste della lista dei server. Confronta i due valori prima di sospettare un attacco.

"RCon non si collega più da quando ho filtrato le porte": BattlEye RCon passa da UDP. Un'apertura con proto tcp sulla stessa porta non serve a nulla. Verifica inoltre se RConPort e steamQueryPort stanno per sbaglio sullo stesso valore.

"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 il browser dei server, un bot Discord con indicatore di stato oppure un vecchio record DNS. Cambiare indirizzo fa guadagnare tempo, non risolve.

"L'attacco arriva ogni giorno esattamente al riavvio": non è un caso. Il piano dei riavvii sta nel Discord e viene annunciato nel gioco, e mentre le mod e l'economia caricano il server non risponde comunque. Una lista di mod più corta, orari di riavvio sfalsati e un filtraggio che gira in permanenza invece di reagire solo a un attacco tolgono efficacia a questo schema.

"Tutti i giocatori hanno picchi di lag, ma la rete è tranquilla": allora non era un attacco DDoS. Guarda prima in logAverageFps se la frequenza dei fotogrammi del server è crollata, e poi nell'economia centrale e nella lista delle mod. Se sar -n DEV 1 10 resta normale, non dipende dalla rete.

"Le mie regole iptables non funzionano": tre cause sono frequenti. Le regole stanno dopo le catene di UFW e non vengono mai raggiunte, 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. Se restano a zero, la regola non viene raggiunta.

"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

• Verso l'esterno un server DayZ ha bisogno esattamente di due cose: il blocco della porta di gioco a partire dalla 2302/UDP e lo Steam Query Port che sta nella tua riga steamQueryPort. Tutto il resto va limitato o chiuso.
• La porta BattlEye RCon non ha uno standard vincolante, passa da UDP e si imposta nella BEServer_x64.cfg con RConPort. Non deve mai stare sulla rete aperta e mai sullo stesso valore della porta di query.
• La porta di query si limita invece di chiuderla: chi la chiude sparisce dal browser dei server e dal DZSA Launcher, anche se la connessione diretta continua a funzionare.
• Whitelist, guaranteedSlots e la coda di accesso proteggono i tuoi posti giocatore dall'esaurimento degli slot, ma non la tua linea dalla banda.
• La finestra temporale più pericolosa di un server DayZ è il riavvio programmato ogni tre o quattro ore, perché le mod e l'economia centrale caricano per minuti e il momento è pubblicamente noto.
• Da circa 1 Gbit/s di volume di attacco oppure da qualche centinaio di migliaia di pacchetti al secondo decide esclusivamente la rete davanti al server, non più il tuo firewall.
• Da KernelHost la protezione permanente a due livelli è inclusa in ogni pacchetto server, senza sovrapprezzo e senza null-routing. La Advanced DDoS Protection a partire da 50,00 € al mese si aggiunge quando vuoi gestire tu stesso le regole per singola porta.

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