Proteggere un server Arma 3 dagli attacchi DDoS

Chi vuole proteggere un server Arma 3 dagli attacchi DDoS ha a che fare con esattamente cinque porte UDP: dalla 2302 alla 2306. Un server dedicato che la sera, nel bel mezzo della missione, sparisce per tutti i giocatori nello stesso momento raramente ha un problema hardware. Di solito è in corso un attacco proprio contro questo blocco di porte, e per giunta nel momento in cui la lista dei server mostra il numero di giocatori più alto. Questo articolo mostra prima che cosa puoi mettere in sicurezza da solo senza spese aggiuntive, poi dove queste misure si fermano dal punto di vista tecnico e infine che cosa deve succedere nella rete, prima del server.

Tutte le indicazioni si riferiscono a un server Arma 3 dedicato (applicazione SteamCMD 233780) 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 nulla nella configurazione e non riavviare il server, ma metti prima al sicuro i valori misurati del paragrafo "Registrare i log". Dopo l'attacco non ci sono più.

Perché i server Arma 3 vengono attaccati e quando serve una protezione DDoS

Arma 3 mette insieme diverse caratteristiche che fanno di un server un bersaglio comodo. Primo, il server pubblica il proprio indirizzo di sua iniziativa: si registra sulla porta 2304 UDP presso il master server di Steam e sulla porta 2303 UDP risponde alle interrogazioni con nome, mappa, numero di giocatori e lista delle mod. Senza queste due porte non ti trova nessuno, con queste due porte il tuo indirizzo IP compare in ogni browser dei server e in ogni pagina di stato che interroga il browser dei server.

Secondo, il pubblico è legato a orari fissi. I progetti di roleplay Life su Altis e Tanoa, Exile, Antistasi e King of the Hill si riempiono la sera e nel fine settimana, quindi un disservizio alle 20 è quello che si nota di più. Terzo, ci sono la concorrenza fra progetti, i giocatori bannati e i conflitti interni, e un attacco non costa a chi lo lancia né competenze né soldi degni di nota.

Sul piano tecnico si aggiunge il punto decisivo: Arma 3 passa interamente da UDP, per il funzionamento del gioco il TCP non serve. UDP non prevede alcuna apertura di connessione da pretendere e gli indirizzi mittente si possono falsificare. Chi attacca non deve quindi né entrare nel tuo server né interrogarlo in modo corretto per generare carico. A questo si aggiunge che il ciclo di simulazione di un server Arma 3 gira in sostanza su un solo core: chi manda abbastanza pacchetti consuma il tempo di calcolo di quell'unico core, a prescindere da quanti core abbia per il resto la macchina. Che cosa sia nel dettaglio un attacco DDoS lo spiega l'articolo Che cos'è un attacco DDoS?.

Le porte di cui si tratta davvero

Di serie un server Arma 3 occupa il blocco dalla 2302 alla 2306 UDP. Il parametro di avvio -port=2302 fissa soltanto la prima porta, le altre quattro ne discendono in modo rigido, cioè come porta di gioco più 1 fino a più 4. Chi gestisce più istanze sulla stessa macchina lascia quindi almeno 100 porte di distanza (2302, 2402, 2502), altrimenti le istanze si portano via a vicenda le porte successive.

Di queste otto righe, esattamente tre devono stare su internet aperto: 2302, 2303 e 2304 UDP. Tutto il resto è amministrazione, e le porte di amministrazione aperte sono l'errore evitabile più frequente sui server Arma 3.

Che cosa puoi fare da solo prima di spendere

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

1. Inventario: che cosa è in ascolto sul server?

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:2302 significa "raggiungibile da tutta internet", 127.0.0.1:3306 significa "solo in locale" e non richiede alcuna regola firewall. Accanto al gioco, su un server Life compaiono regolarmente MariaDB, un server web per la pagina delle fazioni, un servizio TeamSpeak o vocale e un pannello dimenticato da tempo. Il punto di vista di chi attacca te lo dà una scansione delle porte dall'esterno:

nmap -Pn -sU -p 2300-2320 IP.DEL.TUO.SERVER
nmap -Pn -p- --min-rate 1000 IP.DEL.TUO.SERVER

Il primo comando mostra il blocco UDP del gioco, il secondo tutto ciò che è aperto su TCP. Per il funzionamento del gioco un server Arma 3 non ha bisogno di una sola porta TCP aperta.

2. Lascia aperte solo le porte di cui Arma 3 ha davvero bisogno

Bastano tre porte UDP verso l'esterno, tutto il resto va limitato. Con UFW la cosa si presenta così, e proprio in questo ordine, per non restare chiuso fuori dal tuo server:

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH'
ufw allow 2302:2304/udp comment 'Arma 3 gioco, query Steam, master Steam'
ufw allow from 203.0.113.10 to any port 2306 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. La porta 2305 resta chiusa, perché Bohemia la indica come riservata e attualmente non utilizzata. Importante è la riga ufw default allow outgoing: BattlEye apre dal server una connessione verso arma31.battleye.com e per farlo ha bisogno in uscita della 2344 su TCP e UDP e della 2345 su TCP. Chi blocca in uscita senza distinzioni blocca il proprio anti-cheat. Dopo la modifica verifica con un ingresso reale che BattlEye continui a far passare i tuoi giocatori. La guida completa, via di fuga compresa, è nell'articolo Configurare il firewall UFW senza bloccarsi fuori.

Il database non deve in nessun caso stare sulla rete aperta. Altis Life e gli altri framework Life parlano con un database MySQL attraverso l'estensione extDB3, e le credenziali stanno in chiaro in @extDB3/extdb3-conf.ini. Verifica in /etc/mysql/mariadb.conf.d/50-server.cnf che ci sia scritto:

bind-address = 127.0.0.1

3. Disinnesca la porta di query Steam senza sparire dal browser dei server

La porta 2303 UDP è il punto più delicato di un server Arma 3 pubblico. Risponde alle richieste A2S, cioè all'interrogazione standard del browser dei server di Steam: A2S_INFO consegna nome, mappa e numero di giocatori, A2S_PLAYERS la lista dei giocatori, A2S_RULES la lista delle mod e delle firme. Una richiesta è un piccolo pacchetto UDP, la risposta è un multiplo di quella dimensione. US-CERT indica per il protocollo Steam, nell'alert TA14-017A, un fattore di amplificazione della banda pari a 5,5, e in Arma 3 la risposta risulta particolarmente grande, perché contiene anche l'intera lista delle mod.

Da qui derivano due cose. Primo, il tuo server può essere usato come amplificatore contro terzi, se chi attacca manda richieste con indirizzo mittente falsificato. Secondo, e per te è più importante, ogni richiesta costa tempo di calcolo su quell'unico core che porta avanti la simulazione. Bohemia tiene aperto dal 2015 un ticket in proposito (T83469): pacchetti UDP falsificati verso la porta di gioco o verso la porta di query Steam portavano la CPU al 100 per cento e congelavano il server, e per un attacco riuscito attraverso la porta di query bastavano già 4 Mbit/s. È questo il motivo per cui in Arma 3 la frequenza dei pacchetti è più pericolosa della banda.

La prima leva è la dimensione della risposta. La direttiva steamProtocolMaxDataSize nella server.cfg stabilisce quanti byte il server può mettere nella sua risposta di query. Chi gestisce liste di mod estese la alza a 2048 o più, perché altrimenti nel log compare l'avviso "Query data overflow, Mods/Signatures will not be correctly received by clients". Ogni aumento però ingrandisce esattamente la risposta che chi attacca sfrutta come amplificazione. Imposta quindi il valore tanto basso quanto la tua lista delle mod ancora consente, e togli dal comando di avvio le mod che non usi:

steamProtocolMaxDataSize = 2048;

La seconda leva è una limitazione della frequenza per indirizzo sorgente, che colpisce soltanto la porta di query. Non bloccare la 2303 UDP in modo generalizzato: senza risposta di query il tuo server sparisce dal browser dei server e da ogni pagina di stato, e i nuovi giocatori non lo trovano più. Un browser dei server legittimo interroga qualche volta al minuto, non centinaia di volte al secondo.

4. Togli BattlEye RCon dalla rete aperta

BattlEye è l'anti-cheat di Arma 3 e si attiva nella server.cfg con BattlEye = 1;. La gestione remota che lo accompagna, BattlEye RCon, è un protocollo UDP a sé e si configura in BattlEye/beserver_x64.cfg (il file con il suffisso _x64 vale per arma3server_x64, il server usato oggi):

RConPassword TuaPasswordAlfanumerica
RConPort 2306
RConIP 127.0.0.1
MaxPing 350
RestrictRCon 0

Tre punti sono decisivi. La password RCon deve essere puramente alfanumerica: i caratteri speciali mandano fuori strada in silenzio il parser di protocollo di BattlEye, e un accesso RCon che fallisce in silenzio è un accesso che al momento del bisogno non hai. RConIP stabilisce su quale indirizzo RCon resta in ascolto: se c'è 127.0.0.1, l'interfaccia è raggiungibile solo in locale e il tuo strumento RCon la raggiunge attraverso un inoltro SSH. E RConPort deve stare sopra il blocco del gioco, di norma è la porta di gioco più 4, quindi 2306. Chi deve aprire RCon verso l'esterno rende raggiungibile la porta soltanto per l'indirizzo fisso del proprio team di amministrazione.

Una cosa deve essere chiara: BattlEye è un anti-cheat, non una protezione DDoS. Verifica i giocatori che sono collegati. Chi inonda il tuo server non ha alcuna intenzione di entrare.

5. Lega l'headless client a un indirizzo fisso

Un headless client è una seconda istanza di Arma 3 senza grafica, che si collega al server come un giocatore e gli toglie il calcolo dell'intelligenza artificiale. Nelle missioni grandi è il guadagno di prestazioni più importante in assoluto, perché altrimenti l'intelligenza artificiale sta sullo stesso core della simulazione. Lo si abilita nella server.cfg:

headlessClients[] = {"127.0.0.1"};
localClient[] = {"127.0.0.1"};

Senza queste voci il server non accetta alcuna connessione di headless client, e questa è la buona notizia. La cattiva: localClient[] concede all'indirizzo inserito banda illimitata e praticamente nessun controllo di latenza. Inserisci lì esclusivamente 127.0.0.1 oppure l'indirizzo fisso del tuo server headless client, mai un intero intervallo di indirizzi. Il client si avvia con -client -connect=127.0.0.1 -port=2302 -password=... e occupa uno slot di maxPlayers. Mettilo quindi in conto, altrimenti i tuoi giocatori si trovano davanti a un server pieno.

6. Irrigidisci ingresso, firme e votazioni

Queste impostazioni non proteggono la tua linea, ma chiudono tutto ciò che arriva dalla normale via di ingresso: client manipolati, esecuzione di script nel gioco e abuso delle votazioni. Le righe che seguono devono stare nella server.cfg di ogni server pubblico:

verifySignatures = 2;
BattlEye = 1;
kickDuplicate = 1;
allowedFilePatching = 0;
maxPlayers = 64;
disconnectTimeout = 30;
maxPing = 200;
maxDesync = 150;
maxPacketLoss = 50;
kickClientsOnSlowNetwork[] = {1, 1, 1, 1};
voteThreshold = 1.5;
voteMissionPlayers = 100;
onUnsignedData = "kick (_this select 0)";
onHackedData = "kick (_this select 0)";

verifySignatures = 2 impone il controllo delle firme in versione 2 per tutti gli addon ed è il requisito minimo per ogni server pubblico con mod. allowedFilePatching = 0 nega l'ingresso ai client avviati con -filePatching (il valore 1 lo consente solo agli headless client, il valore 2 a tutti). kickDuplicate = 1 butta fuori la seconda connessione con lo stesso identificatore. kickClientsOnSlowNetwork[] decide voce per voce se le quattro soglie di maxPing, maxPacketLoss, maxDesync e disconnectTimeout vengano soltanto registrate nel log (0) oppure applicate (1). disconnectTimeout accetta valori da 5 a 90 secondi. Un voteThreshold superiore a 1 rende le votazioni irraggiungibili e chiude così il modo più diffuso di disturbare un server senza un solo pacchetto di attacco: il cambio di missione tramite votazione.

7. Limita la frequenza di pacchetti e connessioni per indirizzo sorgente

Contro gli attacchi piccoli e i bot fatti male aiuta un limite massimo per indirizzo sorgente. Poiché Arma 3 va di solo UDP, si lavora con hashlimit, e la porta di query riceve un limite nettamente più stretto della porta di gioco:

iptables -I INPUT -p udp --dport 2303 -m hashlimit --hashlimit-name a3_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name a3_game --hashlimit-mode srcip --hashlimit-above 900/sec --hashlimit-burst 1200 -j DROP
iptables -I INPUT -p udp --dport 2302:2306 -m length --length 0:27 -j DROP

La prima regola scarta le richieste di query dalla stessa sorgente oltre le dieci al secondo sostenute, la seconda i pacchetti di gioco oltre i 900 al secondo sostenuti, la terza i pacchetti UDP senza carico utile sfruttabile. Tutti e tre i numeri sono valori di partenza, non verità assolute: un server Life pieno con 80 giocatori produce molti più pacchetti di una partita Antistasi in sei, e chi stringe troppo butta fuori i propri giocatori. Misura prima una settimana di funzionamento normale.

Due avvertenze in proposito. Le semplici regole iptables spariscono dopo un riavvio; su Debian e Ubuntu si salvano così:

apt-get install -y iptables-persistent
netfilter-persistent save

Con UFW, invece, regole di questo tipo vanno in /etc/ufw/before.rules, altrimenti al prossimo ufw reload spariscono. Un collo di bottiglia spesso trascurato è poi il tracciamento delle connessioni del kernel: anche UDP vi crea voci, e un flood di query da molti indirizzi falsificati riempie la tabella in pochi secondi. Se 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

8. basic.cfg: banda, dimensioni dei pacchetti e file aggiuntivi

Il secondo file di configurazione di un server Arma 3 si chiama basic.cfg e viene caricato con -cfg=, mentre -config= carica la server.cfg. Governa il comportamento di rete e contiene esattamente un valore che riguarda direttamente la sicurezza:

MaxMsgSend = 1024;
MaxSizeGuaranteed = 512;
MaxSizeNonguaranteed = 256;
MinBandwidth = 15000000;
MaxBandwidth = 100000000;
MinErrorToSend = 0.001;
MinErrorToSendNear = 0.01;
MaxCustomFileSize = 0;
class sockets { maxPacketSize = 1400; };

MaxCustomFileSize è la dimensione massima in byte per i file di volto e di suono che i giocatori portano con sé e che il server distribuisce a tutti gli altri. Il valore 0 disattiva questa distribuzione. Viene così a mancare una strada su cui un singolo client occupa la banda del tuo server senza alcuna infrastruttura di attacco. MinBandwidth è la banda che il server dà per garantita, il valore indicativo è il numero di giocatori per 256 kbit/s, quindi circa 16 Mbit/s per 64 slot. Valori troppo ottimistici aumentano carico e desincronizzazione, perché il server produce messaggi che poi scarta. MaxMsgSend limita i pacchetti per passo di simulazione ed è la prima leva contro la desincronizzazione; il valore predefinito 128 è impostato troppo in basso per i server moderni.

9. Registrare i log, per non dover tirare a 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. Con apt-get install -y vnstat sysstat la misurazione resta sempre attiva, e logFile = "arma3server.log"; nella server.cfg ti aggiunge il punto di vista del server. Durante un incidente bastano quattro comandi:

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

Illuminante è il confronto fra le porte. Se il carico sta quasi tutto sulla 2303, è un flood di query e colpisce il tempo di calcolo. Se si distribuisce in modo uniforme dalla 2302 alla 2306 con indirizzi mittente sempre nuovi, è un UDP flood falsificato e colpisce la linea. 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. Come si installa e si aggiorna il server in modo pulito lo trovi in Installare un server di gioco con SteamCMD.

Dove queste misure si fermano

Adesso la parte che nessun file di configurazione può risolvere. Tutte le misure viste finora girano sul tuo server, quindi all'estremità della linea. Una regola firewall decide di un pacchetto che ha già percorso il cavo. Puoi scartarlo, ma non puoi fare in modo che non sia mai stato spedito.

Fai due conti. Un 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 in Arma 3 colpisce quasi sempre per prima. Con pacchetti piccoli da 64 byte, in una linea da 1 Gbit/s entrano circa 1,49 milioni di pacchetti al secondo. Un normale kernel di server ne elabora, a seconda di CPU e scheda di rete, qualche centinaio di migliaia prima di cominciare a scartare, e la simulazione di Arma 3 dipende in più da un solo core.

La riga dei 4 Mbit/s è la più spiacevole. In Arma 3 un attacco non deve essere grande per funzionare: deve solo mandare abbastanza pacchetti alla porta giusta. Chi gestisce un server lo vive così: "l'utilizzo non era nemmeno alto, eppure era sparito tutto". Al contrario, per gli attacchi volumetrici vale la fisica più semplice: a 473,4 Gbit/s qualsiasi impostazione locale è irrilevante, perché i pacchetti dei tuoi giocatori si fermano già prima. Gli attacchi volumetrici devono finire nella rete, prima del server.

Che cosa mette davanti KernelHost

La protezione permanente inclusa su ogni server

La protezione DDoS di KernelHost è costruita su due livelli ed è permanentemente attiva, senza che tu debba attivare, ordinare o configurare nulla:

• Livello 1: 17 Tbps di capacità di mitigazione nella rete di scrubbing globale. Gli attacchi volumetrici vengono ripuliti vicino alla loro origine, prima che raggiungano il datacenter.
• Livello 2: filtraggio Arbor in tempo reale da 3,2 Tbps a Francoforte sul Meno. Subito davanti al server vengono riconosciuti e scartati gli schemi specifici di protocollo, pacchetto per pacchetto.

Due caratteristiche sono decisive. La protezione è sempre attiva e non deve prima reagire a un attacco, quindi non ci sono minuti iniziali in cui il server sparisce. E non viene usato il null-routing: il tuo indirizzo IP resta in rete e vengono scartati solo i pacchetti dannosi. Chi toglie l'indirizzo IP dalla rete ottiene per te lo stesso risultato di chi attacca. Quali giochi e protocolli siano coperti lo elenca Protezione DDoS per game server in tempo reale.

Advanced DDoS Protection per progetti sotto attacco continuo

Certi progetti non vengono colpiti ogni tanto, ma in modo mirato e per settimane. Un server Life con un pubblico stabile e una scena di concorrenti è in questo il caso normale, non l'eccezione. Per questi casi c'è la Advanced DDoS Protection a partire da 50,00 € al mese, PrePaid, senza durata minima e senza costi di attivazione. 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 e che cosa sulla 2303 UDP, e puoi quindi tenere la porta di query molto più stretta della porta di gioco.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro durante un attacco in corso invece di aspettare una finestra di manutenzione.
• Profilo di protezione adatto al singolo gioco, così come per applicazioni modificate e proprie su porte TCP o UDP a piacere.

I due livelli a confronto

Per la maggior parte dei progetti Arma 3 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

"Ho spostato la porta dalla 2302 alla 2402 e l'attacco è andato avanti": è quello che ci si deve aspettare. Il server registra da sé la nuova porta presso il master server di Steam, e la lista dei server la pubblica subito di nuovo. Cambiare porta aiuta soltanto contro chi usa un vecchio indirizzo preso da un vecchio screenshot.

"Ho bloccato del tutto la 2303 e adesso non ci trova più nessuno": succede esattamente questo. Senza risposta sulla porta di query Steam manca la voce nel browser dei server, e ogni pagina di stato e ogni bot Discord mostrano il server come offline. La strada giusta è una limitazione della frequenza per indirizzo sorgente, non un blocco.

"Nel log compare NetServer::SendMsg: cannot find channel": questo messaggio arriva quando il server vuole scrivere a una connessione che non esiste più. Di regola accompagna connessioni di giocatori che cadono e cali di prestazioni (Bohemia lo segue sotto T83936), non per forza un attacco. Verifica prima se la frequenza dei pacchetti dell'interfaccia sia davvero anomala.

"Le mie regole iptables non funzionano": tre cause sono frequenti. Le regole stanno dopo le catene di UFW e non vengono mai raggiunte, oppure sono sparite con l'ultimo riavvio (allora servono netfilter-persistent save o una voce in /etc/ufw/before.rules), oppure l'attacco è volumetrico e la regola lavora correttamente su una linea che è già satura. Verifica con iptables -L INPUT -n -v se i contatori dei match salgono. Se restano a zero, la regola non viene raggiunta.

"Da quando c'è il nuovo firewall BattlEye espelle tutti i giocatori": il server non raggiunge più arma31.battleye.com. Le porte in uscita 2344 su TCP e UDP e la 2345 su TCP devono restare aperte, altrimenti cade la connessione anti-cheat del server.

"Il mio provider precedente ha bloccato il mio indirizzo IP": quello è null-routing. Il provider protegge così la propria rete, mentre per te il risultato è identico a un attacco riuscito, di solito ancora per ore dopo. Nel dubbio chiedi se filtrano oppure se fanno null-routing. La risposta decide della tua disponibilità più di qualsiasi dato sull'hardware.

"In tcpdump non vedo nulla di anomalo": se il traffico viene già filtrato nella rete a monte, sul server come previsto non arriva nulla. È la situazione normale quando il filtraggio funziona. Vale però anche il contrario: se la linea è satura, può darsi che non ti raggiunga nemmeno la sessione SSH con cui volevi misurare. In quel caso usa la console VNC nell'area clienti, che funziona indipendentemente dalla rete del sistema ospite.

In breve

• Un server Arma 3 ha bisogno verso l'esterno di esattamente tre porte UDP: la 2302 per gioco e voce, la 2303 per la query Steam e la 2304 per la registrazione presso il master server di Steam. Il TCP al gioco non serve.
• La porta 2306 UDP porta BattlEye e l'interfaccia RCon e va riservata esclusivamente ai tuoi indirizzi di amministrazione, impostati con RConPort e RConIP in beserver_x64.cfg.
• La porta di query Steam 2303 è il punto più delicato: secondo US-CERT TA14-017A il protocollo Steam ha un fattore di amplificazione di 5,5, e ogni richiesta costa tempo di calcolo sul core che porta avanti la simulazione. Limitare invece di bloccare.
• Tieni steamProtocolMaxDataSize tanto basso quanto la lista delle mod consente e imposta MaxCustomFileSize = 0; nella basic.cfg: entrambe le cose riducono la quantità di dati che il tuo server consegna di sua iniziativa.
• In Arma 3 decide la frequenza dei pacchetti, non la banda. Bohemia documenta dal 2015 sotto T83469 che già 4 Mbit/s sulla porta di query bastavano a congelare un server.
• Le misure locali finiscono alla linea. Da 1 Gbit/s di volume di attacco oppure da qualche centinaio di migliaia di pacchetti al secondo decide esclusivamente il filtraggio nella rete prima del server.
• Su 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 la completa a partire da 50,00 € al mese con un IP di protezione dedicato e regole per porta gestibili da te.

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.