Proteggere un server Project Zomboid dagli attacchi DDoS

Chi vuole proteggere il proprio server Project Zomboid dagli attacchi DDoS deve prima sapere su che cosa spara davvero chi attacca. Un server dedicato occupa esattamente due porte UDP, la 16261 e la 16262, ed entrambe devono stare aperte sulla rete, perché altrimenti nessuno può entrare. Questo articolo procede nell'ordine che conta nell'emergenza: 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 tecnico e infine quello che deve succedere prima, nella rete.

Tutte le indicazioni si riferiscono al server dedicato (app Steam 380870) su Debian 12, Debian 13, Ubuntu 22.04 LTS oppure Ubuntu 24.04 LTS, tanto per la build 41 quanto per la build 42. Il file di configurazione si chiama servertest.ini e si trova sotto ~/Zomboid/Server/, i dati del mondo stanno sotto ~/Zomboid/Saves/Multiplayer/. I comandi sono scritti per root; se lavori come utente normale, anteponi sudo.

Se l'attacco è in corso proprio adesso: non modificare adesso nulla nella servertest.ini e non riavviare il server. Metti prima al sicuro i valori misurati (sezione 9), perché dopo l'attacco non ci sono più. Un riavvio costa in più il tempo che il server impiega a caricare il mondo, ed è esattamente quello che chi attacca vuole sottrarti.

Perché i server Project Zomboid diventano bersaglio di attacchi DDoS

Project Zomboid è un gioco con morte permanente e un mondo che va avanti per mesi. Qui una caduta di connessione nel mezzo di una situazione pericolosa costa più che in quasi ogni altro genere: il personaggio è perso, e il mondo se ne ricorda. È proprio questo a rendere un disservizio un'arma. Un attacco alle 20 colpisce una community stabile, e la colpisce nel punto in cui ha più da perdere.

Si aggiunge il fatto che l'attacco in sé non costa nulla e non richiede competenze. I servizi di attacco a pagamento, chiamati nell'ambiente booter oppure stresser, si puntano con pochi clic contro un indirizzo IP e una porta, e su Project Zomboid il bersaglio è sempre lo stesso: 16261 UDP. Chi è in lite con un giocatore bannato oppure gestisce una community concorrente ha così in mano uno strumento per cui non gli servono né conoscenze né soldi degni di nota.

Si aggiunge inoltre che un game server deve pubblicare il proprio indirizzo. Se nella servertest.ini c'è Public=true, il server compare nel browser del gioco, e un server con collegamento a Steam è comunque visibile nel server browser di Steam. La domanda non è quindi mai se chi attacca troverà il tuo indirizzo IP, ma solo che cosa succede quando ci spara contro.

Sul piano tecnico la parte più sgradevole arriva alla fine: tutto il traffico di gioco passa da UDP. UDP non prevede alcuna apertura di connessione da pretendere, ogni pacchetto sta per conto proprio 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 cosa sia nel dettaglio un attacco DDoS lo spiega l'articolo Che cos'è un attacco DDoS?.

Di quali porte ha davvero bisogno un server Project Zomboid

Un server Project Zomboid dedicato ha bisogno esattamente di due porte aperte: 16261 UDP e 16262 UDP. L'elenco ufficiale delle porte del gioco non ne cita una terza. Nella servertest.ini compaiono come due direttive separate, e la seconda porta non deriva automaticamente dalla prima:

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

La divisione dei compiti è netta. 16261 UDP trasporta il traffico di gioco e l'apertura della connessione e risponde alle interrogazioni del server browser. 16262 UDP è la porta per la connessione diretta dei client. Se manca la prima, nessuno trova il server; se manca la seconda, i tuoi giocatori vedono la voce nella lista e non riescono comunque a entrare. Da qui nasce proprio il messaggio di errore più noto del gioco, quello secondo cui la porta 16262 sarebbe chiusa.

Due punti che creano problemi con regolarità. Primo: ogni istanza del server ha bisogno di due porte UDP libere. Chi gestisce un secondo mondo sulla stessa macchina ne assegna una seconda coppia, per esempio 16274 e 16275, e inserisce entrambi i valori nella servertest.ini della seconda istanza. Secondo: SteamPort1 e SteamPort2 stanno nel file di configurazione con 8766 e 8767, ma appartengono al collegamento con Steam e non al traffico di gioco. Aprile solo se senza di esse il tuo server non compare nella lista di Steam, non per precauzione.

Che cosa puoi fare da solo prima di spendere

Questa sezione è la più lunga, e non per caso. Un server configurato in modo pulito regge con le proprie forze gli attacchi piccoli e medi, a prescindere da chi lo ospita. Non ti toglie un attacco volumetrico, ma fa in modo che gli attacchi a buon mercato restino senza effetto e che nell'emergenza tu abbia numeri invece di supposizioni.

1. Inventario: che cosa è davvero in ascolto

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

ss -lntup

La colonna interessante è quella dell'indirizzo locale. 0.0.0.0:16261 e [::]:16261 significano "raggiungibile da tutta internet", 127.0.0.1:27015 significa "solo in locale" e non richiede alcuna apertura. Confronta il risultato con la tua configurazione invece di fidarti dei valori standard:

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

Il punto di vista di chi attacca te lo dà una scansione delle porte dall'esterno. Siccome Project Zomboid usa esclusivamente UDP, serve la scansione UDP: una scansione puramente TCP non mostra affatto la porta di gioco:

nmap -Pn -sU -p 16261,16262,8766,8767 IP.DEL.TUO.SERVER
nmap -Pn -p- --min-rate 1000 IP.DEL.TUO.SERVER

2. Lasciare aperte solo la 16261 e la 16262

Bastano due aperture verso l'esterno, tutto il resto va limitato oppure non pubblicato affatto. 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 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid connessione diretta"
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. L'ordine con cui attivi il firewall decide se resti chiuso fuori oppure no. Lo trovi, via di ritorno compresa, nell'articolo Configurare il firewall UFW senza bloccarsi fuori. Se dovesse comunque succedere: sui root server KVM e sui Dedicated Server di KernelHost raggiungi il sistema tramite la console VNC nell'area clienti, che lavora indipendentemente dalla rete del sistema ospite.

Una parola su database e servizi accessori: Project Zomboid non ne ha bisogno. Quello che oltre al gioco è in ascolto su 0.0.0.0 proviene da un'installazione precedente oppure da un pannello di gestione, e va legato a 127.0.0.1 oppure spento.

3. Togliere da internet RCON sulla porta 27015

RCON è il controllo remoto del server e su Project Zomboid gira sulla 27015 TCP. Nella servertest.ini fornita di serie c'è RCONPassword= senza valore. Chi usa RCON imposta una password casuale lunga, perché il protocollo trasmette senza cifratura, e una porta RCON raggiungibile con una password debole consegna il server per intero, senza che serva un solo pacchetto di traffico di attacco.

La strada sicura è non aprire affatto la porta verso l'esterno e raggiungerla con un inoltro di porta via SSH. Dopodiché parli in locale con 127.0.0.1:27015:

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

Chi non ha bisogno di RCON lascia vuoto il campo della password e la porta chiusa. Un servizio che non è raggiungibile non può essere né provato a tentativi né inondato.

4. Limitare la frequenza dei pacchetti per indirizzo sorgente

Contro gli attacchi piccoli e i bot fatti male aiuta un tetto massimo per indirizzo sorgente. Siccome le due porte di gioco sono vicine, basta una regola per l'intervallo:

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

La regola scarta i pacchetti UDP non appena lo stesso indirizzo sorgente invia stabilmente più di 400 pacchetti al secondo. Il valore è un punto di partenza, non una verità assoluta: un server con 30 giocatori nella stessa città genera nettamente più traffico di uno con quattro giocatori in angoli diversi della mappa, e chi stringe troppo butta fuori i propri giocatori. Misura prima una settimana di funzionamento normale, poi imposta il limite a un multiplo del picco.

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, regole di questo tipo vanno in /etc/ufw/before.rules, altrimenti al prossimo ufw reload spariscono. Verifica con i contatori dei match di iptables -L INPUT -n -v se la regola viene effettivamente raggiunta. Se i contatori restano a zero, si trova nel posto sbagliato.

5. Alleggerire il tracciamento delle connessioni

Un collo di bottiglia spesso trascurato sta nel kernel. Il tracciamento delle connessioni crea una voce per indirizzo sorgente e porta anche per UDP, e un flood con mittenti falsificati riempie questa 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

Il traffico di gioco di Project Zomboid non ha bisogno di alcun tracciamento di stato, perché UDP non ha stato. Puoi quindi tenere le due porte di gioco fuori da quella tabella:

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

Questo alleggerisce il kernel in modo percepibile. Attenzione: la regola va bene soltanto finché il server riceve i pacchetti direttamente. Chi davanti ha una traduzione degli indirizzi, per esempio in una struttura a container con inoltro di porte, non deve impostarla, perché il percorso di ritorno non viene più associato.

6. Mettere in sicurezza l'accesso e gli slot

Le righe che seguono non costano nulla e agiscono contro tutto ciò che arriva dalla normale via di ingresso:

Password=UNA-PASSWORD-CASUALE-LUNGA
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password è la password comune del server ed è separata dall'account del singolo giocatore. Open=false significa che possono entrare solo gli account creati prima da un amministratore: è la whitelist del gioco. MaxAccountsPerUser limita quanti account un singolo utente Steam può creare sul tuo server, e il valore predefinito 0 significa illimitato. MaxPlayers è di serie a 32, e oltre quella soglia la documentazione avverte esplicitamente di un cattivo caricamento della mappa e di desincronizzazione.

PingLimit è la trappola di questa sezione. La direttiva butta fuori i giocatori oltre una certa latenza in millisecondi ed è di serie a 0, quindi disattivata. Sotto attacco la latenza a salire per prima è quella dei tuoi stessi giocatori, quindi un valore stretto espelle proprio le persone che vuoi tenere. Lascia il limite disattivato oppure impostalo in modo generoso.

E una cosa deve essere chiara: una whitelist protegge la tua logica di gioco, non la tua linea. Chi inonda il tuo server non ha alcuna intenzione di entrare. I suoi pacchetti vengono rifiutati, ma sono comunque arrivati, ed è esattamente questo il punto.

7. Il confronto delle mod alla connessione è il secondo più costoso del tuo server

Project Zomboid verifica alla connessione più di una password. La lista delle mod del server sta in due righe della servertest.ini: WorkshopItems contiene gli ID numerici del Workshop, Mods gli ID di caricamento delle mod, entrambe separate da punto e virgola. All'ingresso il client confronta questa lista, scarica automaticamente da Steam i contenuti Workshop mancanti e solo dopo riceve in streaming i dati del mondo. In più, con DoLuaChecksum=true, il server confronta le somme di controllo dei file di gioco e butta fuori i client i cui file non corrispondono ai suoi.

Per chi attacca è proprio questo il punto interessante, perché il lavoro si svolge prima della partecipazione vera e propria alla partita. Ogni tentativo di connessione costa al server tempo di calcolo per versione, somma di controllo, lista delle mod e dati della mappa, anche il tentativo che alla fine viene rifiutato. Una lista di mod lunga rende più costoso ognuno di questi tentativi. Un flood di accessi è quindi più efficace su un server fortemente modificato che su uno non modificato, e per riuscirci gli serve una frazione della banda di un attacco volumetrico. Il gioco porta con sé due freni integrati:

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer respinge le nuove connessioni finché il server è sovraccarico, invece di far cadere anche la partita in corso. LoginQueueEnabled mette chi entra in una coda invece di elaborare tutti insieme, e LoginQueueConnectTimeout stabilisce quanto può durare un ingresso: valore predefinito 60 secondi, valori ammessi da 20 a 1200.

Un dettaglio va aggiunto, perché viene spesso risolto in modo sbagliato: sui server Linux esiste un errore documentato per cui DoLuaChecksum dà falsi allarmi e non fa entrare i giocatori. Per questo i gestori disattivano il controllo. È comprensibile, ma toglie una verifica che tiene lontani i client con file di gioco modificati. Chi deve disattivarla dovrebbe impostare in modo tanto più severo password del server, whitelist e limite degli account.

8. Lista dei server, UPnP e il proprio indirizzo

Qui conviene l'onestà invece dei desideri: il tuo indirizzo IP non si può tenere segreto. Public=true mostra il server nel browser del gioco, e un server con collegamento a Steam è comunque visibile, secondo la documentazione, nel server browser di Steam. Public=false ti toglie quindi la visibilità verso i nuovi giocatori senza renderti invisibile.

Public=true
PublicName=Il mio server Zomboid
UPnP=false
server_browser_announced_ip=

UPnP è di serie su true e fa sì che il server provi a creare da sé un'apertura di porta su un gateway internet. Su un server noleggiato un gateway del genere non esiste, il tentativo cade nel vuoto e va disattivato. server_browser_announced_ip resta vuoto, a meno che il tuo server non abbia più indirizzi e debba comparire proprio sotto uno di essi. È esattamente questo campo che ti serve di nuovo più avanti, quando passi a un IP di protezione dedicato.

Due abitudini aiutano più di qualsiasi impostazione. Non pubblicare tu stesso l'indirizzo IP grezzo da nessuna parte, quindi né nel canale Discord né sulla pagina del progetto, e dai ai tuoi giocatori un hostname. Il classico intoppo quando si cambia indirizzo sono i vecchi record DNS: un record A dimenticato che punta all'indirizzo precedente rende inutile qualsiasi cambio.

9. Misurare mentre tutto funziona normalmente

Il passo più importante è quello che quasi nessuno compie in anticipo: creare una base di confronto mentre è tutto tranquillo. 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. Durante un incidente bastano quattro comandi:

sar -n DEV 1 10
ip -s link show eth0
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

I primi due mostrano frequenza dei pacchetti e contatori dei pacchetti scartati dell'interfaccia, il terzo un breve campione del traffico, il quarto i messaggi del server, ammesso che giri come servizio systemd (adatta il nome del servizio). 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 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.

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 spesso colpisce prima della banda: con pacchetti piccoli da 64 byte, in 1 Gbit/s entrano circa 1,49 milioni di pacchetti al secondo, mentre un normale kernel di server, a seconda della CPU e della scheda di rete, ne elabora solo qualche centinaio di migliaia prima di cominciare a scartare. Un attacco che non riempie nemmeno un terzo della tua linea può quindi mettere fuori gioco il tuo server. Chi gestisce un server lo vive così: "l'utilizzo non era nemmeno alto, eppure era sparito tutto".

Gli attacchi abituali contro le community di game server si collocano fra 5 e 50 Gbit/s, quindi da cinque a cinquanta volte una linea normale. Per questo non esiste alcuna impostazione locale. Gli attacchi volumetrici devono finire nella rete, prima del server.

Che cosa mette KernelHost contro gli attacchi DDoS ai game server

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. 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: il nuovo indirizzo lo inserisci soltanto là dove i tuoi giocatori trovano il server.
• Regole di protezione gestibili da te per porta e protocollo nell'area clienti: stabilisci che cosa è permesso sulla 16261 e sulla 16262 UDP, e tutto il resto resta chiuso, senza dover aprire un ticket.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro anche durante un attacco in corso.
• Profilo di protezione adatto. Per i giochi più diffusi esistono profili già pronti, mentre per le applicazioni modificate e proprie imposti tu stesso le regole per porta e protocollo. Project Zomboid si lascia delimitare con particolare precisione, perché tutto il traffico di gioco passa da due porte UDP vicine.

I due livelli a confronto

Per la maggior parte dei server Project Zomboid basta la protezione permanente inclusa, insieme a una configurazione pulita. La Advanced DDoS Protection è la risposta al caso in cui qualcuno se la prenda sul personale.

Errori frequenti e soluzioni

"I miei giocatori ricevono il messaggio che la porta 16262 è chiusa": non è un attacco, ma un'apertura mancante. Il server ha bisogno di entrambe le porte, 16261 UDP e 16262 UDP, e proprio come regola UDP. Un'apertura TCP sugli stessi numeri non serve a nulla. Verifica con ufw status verbose e con una scansione UDP dall'esterno se siano davvero aperte entrambe.

"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 la voce nella lista dei server, un bot Discord con indicatore di stato oppure un vecchio record DNS. Su Project Zomboid il cambio costa in più: i client salvano i dati della mappa in locale sotto indirizzo e porta, in una cartella secondo lo schema 123.45.0.12_16261_... dentro Zomboid/Saves. Dopo un cambio ogni giocatore scarica di nuovo dal server la mappa esplorata. Cambiare indirizzo è quindi tempo guadagnato con costi aggiuntivi, non una soluzione.

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

"I giocatori vengono espulsi all'ingresso, ma il server continua a funzionare normalmente": quasi sempre è il confronto, non un attacco. Le cause sono una differenza di versione fra client e server, una voce Workshop mancante o superata oppure una somma di controllo che non torna. Di norma il client indica le mod che non coincidono. Confronta WorkshopItems e Mods riga per riga.

"Picchi di lag ogni pochi minuti, poi torna a funzionare": è lo schema abituale degli attacchi brevi, che durano solo finché i giocatori non smettono per esasperazione. Guarda prima i contatori di rete, non il carico della CPU. Se sar -n DEV 1 10 e i contatori dei pacchetti scartati restano normali, non era un attacco, ma carico: troppi giocatori nella stessa cella, una mod costosa oppure troppa poca memoria per l'istanza Java.

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

In breve

• Un server Project Zomboid dedicato ha bisogno esattamente di due porte aperte: 16261 UDP (DefaultPort) e 16262 UDP (UDPPort). Entrambe stanno come direttive separate nella servertest.ini.
• RCON gira sulla 27015 TCP ed è registrato di serie senza password. Quella porta non deve stare su internet aperto, ma va limitata al proprio indirizzo oppure chiusa.
• Il confronto delle mod alla connessione è il punto più costoso: versione, somma di controllo, lista Workshop e dati della mappa costano tempo di calcolo, anche a ogni tentativo rifiutato. DenyLoginOnOverloadedServer e la coda di accesso sono i freni integrati contro questo.
• Password del server, Open=false e MaxAccountsPerUser=1 proteggono la logica di gioco. Contro una linea satura nessuna di queste impostazioni ha effetto.
• Il limite fisico è fissato: 1 Gbit/s sono 125 megabyte al secondo e, con pacchetti da 64 byte, circa 1,49 milioni di pacchetti al secondo. Gli attacchi abituali contro i game server si collocano fra 5 e 50 Gbit/s.
• Gli attacchi volumetrici devono finire nella rete, prima del server. Presso KernelHost sono 17 Tbps di capacità di mitigazione nella rete di scrubbing globale e un filtraggio Arbor in tempo reale da 3,2 Tbps a Francoforte sul Meno, senza sovrapprezzo e senza null-routing.
• Chi viene colpito di continuo gestisce il filtraggio da sé con la Advanced DDoS Protection: IP di protezione dedicato, regole per porta e protocollo, modifiche in tempo reale, da 50,00 € al mese.

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.