Proteggere un server Mordhau dagli attacchi DDoS

Un server Mordhau che nel bel mezzo di un round Frontline perde tutti i giocatori in una volta sola, resta offline per qualche minuto e non compare più nella lista dei server raramente ha un problema hardware. Nella stragrande maggioranza dei casi è in corso un attacco contro una delle quattro porte UDP che un server dedicato Mordhau deve tenere aperte verso l'esterno. Questo articolo mostra prima che cosa puoi fare da solo per la protezione DDoS di Mordhau senza costi aggiuntivi, poi dove queste misure si fermano dal punto di vista fisico e infine che cosa deve succedere nella rete, prima del server.

Tutte le indicazioni si riferiscono al server dedicato ufficiale di Mordhau (Steam App ID 629800, Unreal Engine 4) 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 (paragrafo 9), perché dopo l'attacco non ci sono più. Con Mordhau si aggiunge un secondo motivo, che molti operatori imparano a proprie spese: il processo del server, quando si chiude, riscrive nella Game.ini lo stato che tiene in memoria. Chi modifica il file a server acceso perde le proprie modifiche al prossimo arresto.

Perché i server Mordhau hanno bisogno di una protezione DDoS e chi li attacca

I server Mordhau vengono attaccati perché il loro indirizzo è pubblico, tutto il traffico di gioco passa da UDP e un disservizio diventa subito visibile a tutti. La voce nel browser dei server contiene indirizzo IP e porta di gioco in chiaro, altrimenti i giocatori non riuscirebbero a trovare il server. Le liste server pubbliche di terze parti e i tracker prelevano gli stessi dati attraverso la porta di query Steam e li pubblicano una seconda volta. Il tuo indirizzo non è quindi un segreto, ma un dato di prodotto.

A questo si aggiunge la tecnica del gioco. Unreal Engine 4 trasmette movimenti, colpi e parate via UDP. UDP non prevede alcuna apertura di connessione da pretendere e l'indirizzo mittente di un pacchetto UDP si può falsificare. Chi attacca non deve quindi né entrare nel tuo server né interrogarlo in modo corretto per generare carico. Con Mordhau questo pesa più che con molti altri giochi: uno scambio di colpi si decide nell'ordine di pochi decimi di secondo, e già 200 millisecondi di ritardo in più rendono il corpo a corpo ingiocabile, molto prima che il server si fermi davvero. Proprio per questo basta un attacco piccolo per rovinare un round. Che cosa sia nel dettaglio un attacco DDoS lo spiega l'articolo Che cos'è un attacco DDoS?.

Le cause tipiche non hanno nulla di spettacolare: concorrenza fra community, giocatori bannati, duelli persi, litigi su Discord. Un attacco non costa a chi lo commissiona né competenze né soldi degni di nota, perché il lavoro lo fanno i servizi booter a noleggio. Chi gestisce un server racconta con regolarità che gli attacchi partono esattamente quando il server è pieno e si fermano appena si svuota. Non è un caso, ma l'indizio che qualcuno osserva la tua voce nel browser dei server e usa il numero di giocatori come innesco.

Le porte di cui si tratta davvero su Mordhau

Un server dedicato Mordhau ha bisogno di esattamente quattro porte UDP verso l'esterno: 7777, 7778, 15000 e 27015. Tutto il resto è opzionale oppure non deve stare sulla rete aperta. Le porte vengono passate come parametri all'avvio:

./MordhauServer.sh FFA_ThePit -log -Port=7777 -QueryPort=27015 -BeaconPort=15000 -RconPort=27020

Due cose vengono regolarmente fraintese. Primo: la porta beacon 15000 non è un accessorio. Il beacon riserva lo slot nel momento in cui un giocatore entra, così dopo il caricamento della mappa non viene buttato fuori di nuovo. Se la 15000 è bloccata o sovraccarica, i giocatori non riescono più a entrare, anche se la porta 7777 risponde. Secondo: su Mordhau RCON non è preconfigurato. Si attiva solo quando imposti RconPassword e RconPort, e passa poi da TCP, non da UDP.

I dati principali di un server Mordhau in sintesi:

Gli schemi di attacco che si incontrano su Mordhau

Quattro schemi coprono praticamente tutto ciò che viene lanciato contro un server Mordhau, e ognuno colpisce una porta diversa.

• UDP flood sulla porta di gioco 7777. È l'attacco standard di un booter: il maggior numero possibile di pacchetti falsificati contro la porta che compare nel browser dei server. Punta a banda e frequenza dei pacchetti, non a una vulnerabilità, e si manifesta prima di tutto come picchi di lag, molto prima che qualcuno perda la connessione.
• Flood di query sulla porta 27015. Una richiesta A2S_INFO è grande 25 byte, la risposta con nome del server, mappa, modalità di gioco e numero di giocatori è un multiplo. Chi attacca investe quindi poco e impone a te lavoro di calcolo e traffico in uscita.
• Reflection attraverso la tua stessa porta di query. Qui il tuo server non è il bersaglio, ma lo strumento: chi attacca invia richieste con indirizzo mittente falsificato e il tuo server risponde alla vittima. Te ne accorgi come traffico in uscita inspiegabilmente alto sulla 27015 e come segnalazione di abuso del tuo provider.
• Esaurimento degli ingressi e degli slot attraverso la porta beacon 15000. Invece di bruciare banda, ingressi automatizzati occupano gli slot riservati. Il server continua a girare, ma risulta pieno, e i giocatori veri non entrano più.

A questi si aggiunge un quinto schema, non appena RCON sta aperto sulla rete: tentativi di accesso al ritmo di uno al secondo contro la porta RCON. Raramente è volumetrico, ma costa tempo di calcolo, ed è l'unico dei cinque casi in cui un colpo a segno ti toglie del tutto il server dalle mani.

Che cosa puoi fare da solo prima di spendere

Questa è la sezione più lunga, e non per caso. Un server Mordhau 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 firewall, 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:7777 e [::]:7777 significano "raggiungibile da tutta internet", 127.0.0.1:27020 significa "solo in locale" e non richiede alcuna regola firewall. Accanto al gioco spesso compaiono anche un pannello web, un servizio di database e un servizio vocale dimenticato da tempo. Il punto di vista di chi attacca te lo dà una scansione dall'esterno, per UDP con una breve lista di porte, perché una scansione UDP completa è molto lenta:

nmap -Pn -sU -p 7777,7778,15000,27015 IP.DEL.TUO.SERVER
nmap -Pn -p- --min-rate 1000 IP.DEL.TUO.SERVER

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

A Mordhau bastano quattro aperture UDP 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 7777/udp comment 'Mordhau gioco'
ufw allow 7778/udp comment 'Mordhau Steam'
ufw allow 15000/udp comment 'Mordhau Beacon'
ufw allow 27015/udp comment 'Mordhau Query'
ufw allow from 203.0.113.10 to any port 27020 proto tcp comment 'Mordhau RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sostituisci 203.0.113.10 con il tuo indirizzo. Conta soprattutto ciò che qui non compare: nessuna apertura per un pannello web, nessuna per un database, nessuna per un file server. Ogni porta aperta in più è un bersaglio in più che non ha nulla a che vedere con il gioco. La guida completa, via di fuga compresa, la trovi in Configurare il firewall UFW senza bloccarsi fuori.

3. Limitare la porta di query 27015 senza sparire dalla lista dei server

La porta di query la puoi limitare, ma non chiudere. Se la 27015 UDP viene bloccata, il tuo server sparisce dal browser dei server, perché numero di giocatori, nome della mappa e nome del server vengono letti esattamente attraverso questa porta. Un limite massimo per indirizzo sorgente risolve il problema senza costare visibilità:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name mh_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Un browser dei server regolare interroga il tuo server qualche volta al minuto, non qualche volta al secondo. Dieci richieste al secondo per indirizzo sorgente sono quindi generose per ogni giocatore e strette per ogni bot. Verifica poi sul contatore dei match se la regola ha davvero effetto:

iptables -L INPUT -n -v | head -20
tcpdump -ni eth0 udp port 27015 -c 200 -q

Qui sta anche la risposta alla questione della reflection. In una reflection il tuo server non viene attaccato, ma abusato come amplificatore: le richieste arrivano con indirizzo mittente falsificato e le tue risposte colpiscono una vittima terza. Una limitazione di frequenza per indirizzo sorgente è la misura locale più efficace, perché un indirizzo mittente falsificato serve soltanto finché il tuo server risponde volentieri e senza limiti.

4. Togliere RCON dalla rete aperta

Su Mordhau RCON non deve in nessun caso stare su internet senza limiti. L'accesso si attiva nella Game.ini, nella sezione [/Script/Mordhau.MordhauGameSession]:

[/Script/Mordhau.MordhauGameSession]
ServerName=Il mio server Mordhau
MaxSlots=64
ServerPassword=
AdminPassword=UnaPasswordLungaCasuale
RconPassword=UnAltraPasswordLungaCasuale
RconPort=27020

Mordhau parla il protocollo Source RCON, quindi TCP, e funziona perciò con qualsiasi strumento RCON diffuso. È esattamente questo che sfruttano anche gli script che provano credenziali a ripetizione. Tre regole coprono il caso. Primo: RconPassword e AdminPassword sono due password diverse, lunghe e casuali, non variazioni del nome del server. Secondo: l'apertura per la porta RCON la limiti al tuo indirizzo, come nel blocco UFW qui sopra. Terzo, se non hai un indirizzo fisso: lascia la porta chiusa verso l'esterno e raggiungila attraverso un inoltro di porta SSH, poi collegati in locale a 127.0.0.1:27020:

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

Se RCON deve comunque restare aperto, limita almeno le connessioni contemporanee per indirizzo sorgente. Uno strumento RCON ha bisogno di una connessione, uno script di forza bruta di centinaia:

iptables -I INPUT -p tcp --dport 27020 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

5. Proteggere la porta beacon 15000 dalle ondate di ingressi

La porta beacon è il punto di attacco sottovalutato di un server Mordhau. Attraverso di essa il gioco riserva lo slot di un giocatore in ingresso, finché questo sta ancora caricando. Un bot che avvia ingressi in rapida successione occupa così gli slot senza mai arrivare in partita. Il server resta online e sembra comunque pieno. Un limite massimo per indirizzo sorgente intercetta il fenomeno, perché un giocatore vero manda un beacon una volta sola per ingresso e non venti volte al secondo:

iptables -I INPUT -p udp --dport 15000 -m hashlimit --hashlimit-name mh_beacon --hashlimit-mode srcip --hashlimit-above 20/sec --hashlimit-burst 40 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name mh_game --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

La seconda regola riguarda la porta di gioco e richiede buon senso. Con una tickrate di 60 il server scambia con ogni giocatore collegato nell'ordine di 60 pacchetti al secondo per direzione. Un valore limite di 400 pacchetti al secondo per indirizzo sorgente lascia quindi molta aria a ogni giocatore vero e colpisce comunque ogni sorgente che sta chiaramente inondando. Misura prima una settimana di funzionamento normale, prima di stringere: chi imposta valori troppo stretti butta fuori i propri giocatori e poi lo scambia per un attacco.

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.

6. Game.ini ed Engine.ini: che cosa serve davvero

Mordhau ha due file di configurazione, ed entrambi si trovano su Linux in Mordhau/Saved/Config/LinuxServer/, su Windows in Mordhau\Saved\Config\WindowsServer\. La Game.ini regola nome del server, slot, password, lista degli amministratori, rotazione delle mappe e gli identificativi delle mod da mod.io, la Engine.ini il comportamento di rete. Modificale esclusivamente a server fermo, altrimenti il processo del server, quando si chiude, sovrascrive le tue modifiche con lo stato che tiene in memoria.

Tre impostazioni sono davvero rilevanti per la superficie di attacco. Primo, una ServerPassword: tiene lontano chiunque non sia invitato, ma costa la reperibilità pubblica e contro un'ondata sulla porta 7777 non serve a nulla, perché chi attacca non vuole affatto entrare. Secondo, un numero realistico in MaxSlots: Mordhau è pensato per un massimo di 64 giocatori, e ogni slot in più è una sorgente di pacchetti in più che la tua CPU deve servire. Terzo, la tickrate nella Engine.ini:

[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=60
LanServerMaxTickRate=60

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

La tickrate predefinita di un server Mordhau è 60. Un aumento a 120 raddoppia la frequenza dei pacchetti per giocatore e il carico della CPU, ed è quindi esattamente ciò di cui non hai bisogno sotto attacco. Un server da 64 slot con tickrate 120 genera già in funzionamento normale nell'ordine di 8.000 pacchetti al secondo per direzione. Chi viene colpito di continuo va nettamente più stabile con 60 che con 120.

7. Alleggerire il tracciamento delle connessioni e i buffer di ricezione

Un collo di bottiglia spesso trascurato è il tracciamento delle connessioni del kernel. Tiene una voce propria per ogni flusso UDP, e un'ondata proveniente da decine di migliaia di indirizzi mittente 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". Stato e limite li mostra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack | tail -20

Contro questo aiutano due cose. Puoi alzare il limite, oppure escludere del tutto le porte di gioco dal tracciamento. Su un game server la seconda strada è di solito la migliore, perché UDP non ha comunque uno stato da tracciare:

iptables -t raw -I PREROUTING -p udp --dport 7777 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 15000 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 27015 -j NOTRACK

Sono utili anche buffer di ricezione più grandi e una coda più profonda della scheda di rete, così che i picchi brevi non portino subito a scarti:

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=4194304
sysctl -w net.core.netdev_max_backlog=5000

In modo permanente questi valori vanno in un file sotto /etc/sysctl.d/, per esempio 99-gameserver.conf. Importante per capirsi: buffer più grandi non aumentano la tua resistenza a un attacco grande, evitano solo che un picco breve costi già dei pacchetti.

8. Il tuo indirizzo è nella lista dei server, e questo non si può cambiare

Qui conviene l'onestà invece dei desideri: l'indirizzo IP di un server Mordhau pubblico non si può tenere segreto. Sta nella voce del browser dei server, sta nelle liste server pubbliche di terze parti che leggono regolarmente la porta di query, e lo conosce ogni giocatore che si è collegato anche una sola volta. Un cambio di indirizzo fa quindi guadagnare ore, raramente giorni, perché chi attacca trova il nuovo indirizzo per la stessa via del vecchio.

Efficaci sono invece tre abitudini. Non pubblicare tu stesso l'indirizzo IP grezzo da nessuna parte, quindi né nel canale Discord né sulla pagina del progetto. Fai collegare i tuoi giocatori tramite un hostname, così all'occorrenza un cambio di indirizzo non rompe tutti i riferimenti. E fai piazza pulita dei vecchi record DNS, perché un record A dimenticato che punta all'indirizzo precedente rende inutile qualsiasi cambio. Lo stesso vale per i server di prova: ogni secondo server raggiungibile pubblicamente sulla stessa macchina rivela l'indirizzo del server principale.

9. Misurare finché tutto funziona normalmente

Il passo più importante è quello che quasi nessuno compie in anticipo: creare una base di confronto mentre il server gira tranquillo. Senza un valore di riferimento, dopo un incidente non puoi dire se 40.000 pacchetti al secondo fossero tanti oppure semplicemente 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
dmesg -T | tail -50
tcpdump -ni eth0 'udp port 7777 or udp port 15000 or udp port 27015' -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. Presta particolare attenzione ai contatori di scarto di ip -s link. Valori dropped in crescita con la CPU tranquilla sono l'indizio più chiaro che il problema è la frequenza dei pacchetti e non la potenza di calcolo. Come interpretare i valori lo trovi in Riconoscere un attacco DDoS. Come installare e tenere aggiornato il server in modo pulito con SteamCMD lo descrive Installare un game server con SteamCMD.

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ù. Un server Mordhau pieno con 64 slot ne usa solo una frazione: con tickrate 60 il traffico di gioco si colloca nell'ordine di 4.000 pacchetti al secondo per direzione. Un booter a noleggio fornisce invece senza difficoltà da 5 a 50 Gbit/s, quindi da cinque a cinquanta volte la tua linea. A quel punto non conta più quanto sia buona la tua regola iptables dietro, perché i pacchetti dei tuoi giocatori si fermano già prima.

La seconda grandezza è la frequenza dei pacchetti, e spesso colpisce prima della banda. 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. Un attacco che non riempie nemmeno un terzo della tua linea può quindi mettere comunque fuori gioco il tuo server Mordhau, perché il tempo di calcolo se ne va nello scartare. Chi gestisce un server lo vive così: "l'utilizzo non era nemmeno alto, eppure era sparito tutto".

Per dare un ordine di grandezza reale: sui server di KernelHost sono stati filtrati, fra gli altri, un attacco da oltre 473,4 Gbit/s con oltre 41,5 milioni di pacchetti al secondo contro un server vocale e un UDP flood da oltre 112,2 Gbit/s contro un game server. Per casi del genere non esiste alcuna impostazione locale. 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. Il sito è Francoforte sul Meno. Quali giochi e protocolli siano coperti lo elenca Protezione DDoS per game server in tempo reale.

Advanced DDoS Protection per server Mordhau sotto attacco continuo

Certi server 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.
• Regole di protezione gestibili da te per porta e protocollo nell'area clienti: stabilisci separatamente che cosa è permesso sulla 7777 UDP, che cosa sulla 15000 UDP e che cosa sulla 27015 UDP, senza dover aprire un ticket.
• 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 gioco. Per i game server su Unreal Engine in UDP e per le porte di query Steam esistono profili già pronti, così come per applicazioni modificate e proprie su porte TCP o UDP a piacere.

La Advanced DDoS Protection si rivolge ai server che girano su KernelHost. Se il tuo server Mordhau al momento sta altrove e viene regolarmente buttato fuori dalla rete, il trasferimento è la strada per arrivare a questo filtraggio.

I due livelli a confronto

Per la maggior parte dei server Mordhau 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

"Ho chiuso la porta 27015 e adesso il mio server non compare più nella lista": è la conseguenza prevedibile. La porta di query Steam fornisce nome, mappa e numero di giocatori al browser dei server. Senza di essa il tuo server non appare più oppure viene indicato come non raggiungibile. La strada giusta è una limitazione di frequenza per indirizzo sorgente, non un blocco.

"I giocatori non riescono a entrare, anche se il server gira": controlla prima la porta 15000 UDP. Il beacon riserva lo slot durante il caricamento. Se è bloccata, filtrata troppo strettamente o sovraccarica, l'ingresso resta appeso, anche se la porta 7777 risponde e il server compare nel browser.

"Le mie modifiche nella Game.ini dopo il riavvio sono di nuovo sparite": hai modificato il file a server acceso. Il processo del server Mordhau, quando si chiude, riscrive lo stato che tiene in memoria e sovrascrive così la tua versione. Fermare il server, modificare, avviare, in questo ordine.

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

"Il server gira, ma tutti hanno picchi di lag e i colpi arrivano in ritardo": guarda prima se la frequenza dei pacchetti in ingresso sale mentre la CPU resta tranquilla. È esattamente lo schema di un attacco. Se la frequenza dei pacchetti resta normale e la CPU sta al 100 percento, non è un attacco DDoS, ma di solito una tickrate troppo alta, troppi slot o una mod.

"Il mio provider segnala abuso in uscita dalla porta 27015": il tuo server è stato abusato come amplificatore per una reflection. Le richieste arrivavano con indirizzo mittente falsificato e il tuo server ha risposto a una vittima terza. Una limitazione di frequenza sulla 27015 UDP per indirizzo sorgente mette fine alla cosa.

"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 dedicato Mordhau ha bisogno di esattamente quattro porte UDP verso l'esterno: 7777 (gioco), 7778 (Steam), 15000 (beacon) e 27015 (query Steam). Tutto il resto resta chiuso.
• Su Mordhau RCON passa da TCP secondo il protocollo Source RCON e si attiva solo con RconPassword e RconPort nella Game.ini. Limita la porta al tuo indirizzo.
• La porta 27015 UDP la puoi limitare, ma non chiudere: senza di essa il tuo server sparisce dal browser dei server, perché numero di giocatori, mappa e nome vengono richiesti attraverso questa porta.
• La porta 15000 UDP è la porta beacon e riserva lo slot durante il caricamento. Se è bloccata o sovraccarica, i giocatori non entrano, anche se il server gira.
• Modifica Game.ini ed Engine.ini solo a server fermo, perché il processo del server, quando si chiude, riscrive lo stato che tiene in memoria.
• Le regole firewall locali finiscono contro la banda: 1 Gbit/s sono 125 megabyte al secondo e, con pacchetti da 64 byte, circa 1,49 milioni di pacchetti al secondo. Oltre quella soglia decide soltanto la rete davanti al server.
• Su KernelHost la protezione permanente a due livelli è inclusa in ogni pacchetto server senza sovrapprezzo ed è attiva dalla consegna, senza null-routing. Chi vuole gestire da sé il filtraggio lo ottiene con la Advanced DDoS Protection a partire da 50,00 € al mese.

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