Proteggere un server MTA:SA dagli attacchi DDoS

Un server per Multi Theft Auto: San Andreas si comporta sotto un attacco DDoS in modo diverso da qualsiasi altro progetto multigiocatore di GTA, perché offre contemporaneamente tre servizi di rete separati: il traffico di gioco sulla 22003 UDP, un server HTTP a tutti gli effetti sulla 22005 TCP e la query ASE sulla 22126 UDP. Ognuno di questi tre servizi si può attaccare singolarmente, e ognuno cade in modo diverso. Questo articolo mostra prima che cosa puoi mettere in sicurezza da solo senza costi aggiuntivi, poi dove queste misure finiscono contro la fisica della linea e infine che cosa deve fare nella rete davanti al server una protezione DDoS efficace per MTA:SA.

Se l'attacco è in corso proprio adesso, la domanda più importante è quale dei tre servizi viene colpito. Se i giocatori restano collegati ma all'ingresso non caricano più le risorse, a essere colpito è il server HTTP sulla 22005. Se il server sparisce dal browser mentre i giocatori collegati continuano a giocare normalmente, a essere colpita è la query ASE sulla 22126. Se tutte le connessioni cadono nello stesso momento, o il bersaglio è la 22003 oppure la linea è satura. Tutte le indicazioni si riferiscono a un server MTA 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.

Perché i server MTA:SA finiscono così spesso nel mirino degli attacchi DDoS

I progetti MTA:SA sono bersagli comodi, perché devono pubblicare il proprio indirizzo di loro iniziativa. Un server compare nel browser di gioco soltanto se si registra presso la lista dei master server e poi risponde alle richieste dall'esterno. La lista contiene indirizzo IP e porta in chiaro, quindi per chi attacca una ricognizione preliminare è superflua.

A questo si aggiunge la scena stessa. Server di ruolo di lingua tedesca e brasiliana, server drift e conversioni in stile DayZ si contendono lo stesso pubblico, e un disservizio nell'orario di punta è visibile al massimo grado. A un giocatore bannato, a un team in lite o a un progetto concorrente non servono né competenze né soldi degni di nota per rendere inutilizzabile una serata. I servizi di attacco a pagamento, che nella scena si chiamano booter o stresser, vendono per pochi euro al mese esattamente due risultati: mettere offline il server MTA per qualche minuto oppure renderlo ingiocabile con picchi di lag. Che cosa sia tecnicamente un attacco DDoS e quali tipi di attacco esistano lo spiega l'articolo Che cos'è un attacco DDoS?.

Sul piano tecnico MTA:SA facilita il compito di chi attacca in due punti più di altre modifiche multigiocatore. Primo, la query sta su una porta UDP propria che, a fronte di un singolo byte, spedisce una risposta di diversi kilobyte. Secondo, a ogni server MTA appartiene un server HTTP che consegna i file lato client di tutte le risorse, e lo fa senza autenticazione a chiunque lo chieda.

Le porte di cui si tratta davvero

Un server MTA:SA ha bisogno di esattamente tre porte: 22003 UDP per il gioco, 22005 TCP per il server HTTP interno e 22126 UDP per la query ASE. La terza porta non è un'impostazione a scelta libera, ma risulta in modo fisso dalla porta di gioco più 123. Chi imposta serverport su 22010 ottiene la query sulla 22133.

Due dettagli stanno così nella mtaserver.conf fornita di serie e vengono regolarmente trascurati. httpport può avere lo stesso valore numerico di serverport, perché una porta è TCP e l'altra UDP. E serverip sta su auto e lì deve restare: un valore fisso lega il socket ASE esattamente a quell'indirizzo e rompe la voce in lista non appena l'indirizzo cambia.

Il protocollo di query ASE e perché è un amplificatore

ASE (All-Seeing Eye) è un puro protocollo di query su UDP: il primo byte del pacchetto determina la risposta, un'apertura di connessione non esiste. Il server MTA conosce cinque richieste e le risponde sulla 22126:

• s è la query ASE completa. La risposta comincia con EYE1 e contiene nome del server, tipo di gioco, nome della mappa, versione, stato della password, numero di giocatori, l'elenco completo di tutte le regole impostate con setRuleValue e poi ogni giocatore collegato con nome, punteggio e ping. Questa risposta non ha alcun limite di dimensione.
• b e r sono le richieste più snelle per il browser di gioco. La risposta comincia con EYE2 e nel codice sorgente viene troncata a 1.340 byte, per evitare la frammentazione.
• x fornisce un messaggio di stato abbreviato, v soltanto l'identificativo di versione di ASE.

Da qui nasce il problema. Una richiesta consiste in un unico byte di carico utile, quindi sul filo in 29 byte (20 byte di intestazione IP, 8 byte di intestazione UDP, 1 byte di carico utile). Una risposta di 1.400 byte di carico utile sul filo sono 1.428 byte. Il rapporto è di circa 49 volte, e poiché UDP non conosce apertura di connessione, l'indirizzo mittente si può falsificare. Chi attacca può quindi usare il tuo server come amplificatore contro un terzo bersaglio, senza mai entrare nel tuo gioco. Nella query completa il fattore cresce con il numero di giocatori e con ogni regola che il tuo gamemode imposta.

Contro questo MTA porta con sé due freni integrati, che conviene conoscere perché spiegano perché certe ondate funzionano e altre no. Il server risponde al massimo a cinque richieste in sei secondi per indirizzo sorgente e poi ignora quell'indirizzo per sette secondi. Inoltre tiene le risposte in cache per dieci secondi, invece di ricomporle a ogni richiesta. Il conteggio per indirizzo sorgente viene però saltato del tutto non appena più di 100 indirizzi mittente diversi stanno contemporaneamente nella lista. È esattamente quello che accade in un'ondata distribuita da una botnet o con mittenti falsificati, e per questo il freno integrato non serve contro un attacco serio.

Che cosa puoi fare da solo prima di spendere

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

1. Inventario: che cosa è in ascolto?

Guarda prima di tutto che cosa offre il tuo server verso l'esterno. Non tirare a indovinare, controlla:

ss -lntup

Prevedibili sono tre righe del processo MTA: 0.0.0.0:22003 su UDP, 0.0.0.0:22005 su TCP e 0.0.0.0:22126 su UDP. Se lì compare anche un database su 0.0.0.0:3306, un server web oppure un servizio vocale dimenticato, quella roba va spenta. Il punto di vista di chi attacca te lo dà una scansione delle porte dall'esterno:

nmap -Pn -sU -p 22003,22126 IP.DEL.TUO.SERVER
nmap -Pn -p 22005 IP.DEL.TUO.SERVER

Per questo il server porta con sé anche un comando di console proprio. Nella console del server, openports verifica se tutte e tre le porte sono raggiungibili dall'esterno.

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

Con UFW una configurazione di partenza solida si presenta così, e proprio in questo ordine, per non restare chiuso fuori dal tuo server:

ufw allow 22/tcp comment 'SSH'
ufw allow 22003/udp comment 'MTA gioco'
ufw allow 22005/tcp comment 'MTA HTTP'
ufw allow 22126/udp comment 'MTA ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

La guida completa, via di fuga compresa, sta nell'articolo Configurare il firewall UFW. Con i server root KVM e i server dedicati di KernelHost, in caso di emergenza arrivi al sistema attraverso la console VNC nell'area clienti, anche quando la linea è satura.

Il database non deve stare sulla rete aperta. Se ss -lntp | grep 3306 mostra un 0.0.0.0:3306, imposta in /etc/mysql/mariadb.conf.d/50-server.cnf la riga bind-address = 127.0.0.1 e riavvia il servizio.

3. Limitare la porta ASE senza sparire dalla lista dei server

A differenza di SA-MP, su MTA:SA la query sta su una porta propria, quindi la puoi limitare indipendentemente dal gioco. È il maggiore vantaggio pratico di questa architettura: una regola sulla 22126 non butta fuori un solo giocatore.

Con nftables in una tabella propria, così che il set di regole non vada a intralciare UFW:

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

La prima regola limita ogni singolo indirizzo sorgente, la seconda l'intera porta. Entrambe insieme sono importanti: un'ondata distribuita passa attraverso la fessura fra molte sorgenti singole, se si limita soltanto per indirizzo. I valori sono scelti stretti, e qui è accettabile, perché un browser dei server vero interroga il tuo server solo ogni pochi secondi. Con iptables il modulo hashlimit ottiene lo stesso risultato:

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

Il tentativo di chiudere del tutto la porta è una scelta da ponderare e non un consiglio segreto: senza ASE il tuo server sparisce dal browser di gioco e quindi dall'afflusso organico. Se lo vuoi fare lo stesso, <ase>0</ase> non basta. Nel codice sorgente l'apertura della porta dipende dall'unione logica fra modalità internet e modalità LAN, quindi con <ase>0</ase> il socket resta aperto finché c'è <donotbroadcastlan>0</donotbroadcastlan>. Chi vuole davvero chiudere la porta imposta entrambi i valori:

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

La strada più onesta per un progetto in crescita è questa: lasciare la porta aperta, limitare la frequenza e tenere piccolo l'effetto di amplificazione facendo in modo che il tuo gamemode non pubblichi regole inutili con setRuleValue. Ogni regola sta nella query completa e ingrandisce la risposta.

4. Alleggerire il server HTTP interno

Il server HTTP sulla 22005 è su MTA:SA una superficie di attacco a sé, perché ogni giocatore in ingresso scarica da lì tutti i file lato client di tutte le risorse in esecuzione. In un progetto di ruolo con modelli propri diventano in fretta diverse centinaia di megabyte, distribuiti su centinaia di file singoli. Il server integrato è tenuto volutamente semplice: nessuna compressione, un contingente fisso di thread di lavoro. Bastano qualche decina di richieste contemporanee perché i giocatori veri restino appesi per minuti nella schermata di caricamento.

La misura più efficace è togliere del tutto i download dal server di gioco. MTA prepara da sé i file da consegnare, sotto mods/deathmatch/resource-cache/http-client-files. Questa cartella la pubblichi con nginx o lighttpd e inserisci l'indirizzo nella mtaserver.conf:

<httpdownloadurl>http://cdn.tuo-dominio.tld/mta</httpdownloadurl>

Questo porta due cose in una volta sola. I download passano da un server web costruito per quello, e non passano più dall'indirizzo del tuo server di gioco. Se il server web sta su un'altra macchina oppure dietro una content delivery network, un'ondata contro i download non colpisce più il gioco. Importante: se l'indirizzo esterno è sbagliato o non raggiungibile, MTA torna in silenzio al server interno.

Se il server interno resta in uso, sfrutta i suoi limiti propri. Nella mtaserver.conf:

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

httpmaxconnectionsperclient limita a 5 le connessioni contemporanee per client, nell'intervallo ammesso da 1 a 8. httpdosthreshold limita quante connessioni un singolo indirizzo IP può aprire in poco tempo, valore predefinito 20. http_dos_exclude esclude singoli indirizzi, per esempio la tua pagina di stato. httpthreadcount determina il numero di thread di lavoro, valore predefinito 8 nell'intervallo da 1 a 20. Un valore più alto aiuta con molti file piccoli, ma costa tempo di calcolo che poi manca al gioco.

Pensa inoltre a che cos'altro viene consegnato sulla stessa porta. Le risorse webadmin e resourcebrowser sono avviate nella configurazione fornita di serie e raggiungibili dal browser attraverso la 22005. Un'interfaccia di amministrazione non deve stare senza protezione sulla rete aperta: assegna permessi puliti nella acl.xml, crea un account proprio con una password lunga e casuale, e ferma la risorsa quando non ti serve.

5. Sfruttare i limiti integrati in mtaserver.conf

MTA porta con sé più limiti di protezione di quanti la maggior parte dei progetti ne usi. Alcuni sono fissi nel codice sorgente, altri stanno nella mtaserver.conf. Questa tabella riassume quelli che hanno un ruolo durante un attacco:

Tre impostazioni meritano una decisione consapevole. maxplayers sta su 32 e dovrebbe corrispondere alla realtà: ogni slot in più ingrandisce la query completa e aumenta il numero di connessioni che chi attacca può occupare. bandwidth_reduction sta su medium, il valore maximum abbassa sensibilmente il carico in uscita, ma costa precisione di sincronizzazione. E <password></password> trasforma il tuo server senza fatica in un circolo chiuso, mentre la voce in lista resta: è il freno di emergenza più rapido durante un'ondata di ingressi in corso.

6. Distinguere le ondate di ingressi dalle ondate di eventi

Due schemi di attacco non puntano alla linea, ma alla logica di gioco, e vengono regolarmente confusi.

Un'ondata di ingressi apre in rapida successione connessioni vere, finché tutti gli slot sono occupati oppure il server non riesce più a star dietro all'apertura. MTA lo limita di suo a quattro connessioni per indirizzo sorgente in 30 secondi e poi ignora quell'indirizzo per 30 secondi. Che cosa stia facendo il freno lo mostra il comando di console debugjoinflood. Il limite agisce per indirizzo, una botnet con mille indirizzi gli passa accanto. Contro questo aiutano una password del server, una whitelist nel gamemode e una limitazione di frequenza sulla 22003.

Un'ondata di eventi arriva invece da giocatori già collegati: un client manipolato lancia triggerServerEvent in un ciclo, finché il server non riesce più a fornire il tempo di calcolo. MTA consente di fabbrica 100 eventi per giocatore e per secondo e oltre quel valore segnala le ondate di eventi. Se il tuo gamemode usa molti eventi piccoli, verifica il valore prima di abbassarlo: impostato troppo stretto, butta fuori i tuoi stessi giocatori.

Indipendentemente da questo, lato server vale la stessa regola di sempre: non fidarti mai dei valori che il client manda insieme alla richiesta, ricava il giocatore dal mittente dell'evento e limita tutto ciò che fa scattare una interrogazione al database. Un singolo evento non verificato che avvia un'interrogazione basta a fermare un server senza alcun attacco di rete.

7. Lista dei server, indirizzo IP e che cos'altro rivela

Il tuo indirizzo IP non si può tenere segreto. Lo conosce ogni giocatore che si è collegato anche una sola volta, e la voce nella lista dei master server lo pubblica comunque. Un dominio davanti non aiuta: il client risolve il nome una volta e poi parla direttamente con l'indirizzo.

Verifica piuttosto che cos'altro rivela il tuo indirizzo. Le fughe tipiche nei progetti MTA sono vecchi record A e AAAA nel DNS, la pagina del progetto sulla stessa macchina, un bot Discord con indicatore di stato che legge pubblicamente la query ASE, certificati TLS con vecchi hostname e messaggi nei forum dei primi tempi. Ne deriva una regola che molti progetti imparano troppo tardi: se ti sposti su un indirizzo protetto, cambia contemporaneamente il vecchio indirizzo. Se resta in piedi, sta in ogni database di scanner, e l'attacco passa accanto alla protezione.

Due voci della mtaserver.conf riguardano direttamente la visibilità. <serverip>auto</serverip> resta su auto, a meno che tu non sappia con precisione perché no. E <owner_email_address> va compilato: se la voce manca o è sbagliata, questo può compromettere la visibilità nella lista dei master server.

8. Registrare i log, per avere dati in caso di emergenza

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 venerdì sera. Con apt-get install -y vnstat sysstat la misurazione resta sempre attiva.

Durante un incidente separa prima di tutto le tre porte fra loro. Bastano questi quattro comandi:

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

L'interpretazione è più semplice di quanto sembri. Se gli errori di buffer salgono con la CPU poco carica, ti arriva più traffico di quanto il processo riesca a smaltire. Se un core gira al massimo mentre il traffico sembra normale, il problema sta nel gamemode e non nella rete. Se la cattura sulla 22126 mostra molti pacchetti con un solo byte di carico utile, è un'ondata ASE. Se il numero di connessioni aperte sulla 22005 resta stabilmente nell'ordine delle migliaia, a essere colpito è il server HTTP. Per tcpdump vale sempre: limita con -c, perché una cattura a pieno carico appesantisce ancora di più un server già sovraccarico. Come interpretare i valori nel dettaglio lo descrive l'articolo Riconoscere un attacco DDoS sul server.

Il log del server si trova sotto logs/server.log, quello degli script sotto logs/scripts.log. Entrambi i percorsi stanno nella mtaserver.conf e si possono spostare.

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 con pacchetti da 64 byte circa 1,49 milioni di pacchetti al secondo. Gli attacchi contro progetti di game server di questo ordine di grandezza si collocano di solito fra 5 e 50 Gbit/s, quindi da cinque a cinquanta volte la tua linea. A quel punto non conta più quanto sia buona la tua regola nftables dietro, perché i pacchetti dei tuoi giocatori si fermano già prima.

La frequenza dei pacchetti colpisce spesso prima della banda. Un normale kernel di server elabora, a seconda di CPU e scheda di rete, qualche centinaio di migliaia di pacchetti al secondo prima di cominciare a scartare. Un attacco che non riempie nemmeno un terzo della tua linea può quindi mettere 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 era sparito tutto".

Con MTA:SA si aggiunge un terzo limite, ed è quello che scatta per primo. Il server legge le porte di rete in un unico flusso di lavoro. Un'ondata di query sulla 22126 impegna questo flusso al punto che i pacchetti di sincronizzazione dei giocatori veri scadono nel buffer di ricezione, molto prima che la linea sia satura. Il processo non va in crash, diventa solo lento, e i giocatori vedono effetti elastici. Lo stesso vale per il server HTTP: condivide il tempo di calcolo con il gioco.

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 con oltre 8,7 milioni di pacchetti al secondo contro un game server. Il primo caso è circa 473 volte la banda e circa 28 volte la frequenza dei pacchetti che una linea da 1 Gbit/s riesce in assoluto ad accogliere. Per casi del genere non esiste alcuna impostazione locale. Gli attacchi volumetrici devono finire nella rete, prima del server.

Che cosa mette in campo KernelHost

La protezione permanente inclusa su ogni server

Ogni server su KernelHost sta dietro un filtraggio a due livelli, permanentemente attivo:

• 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 di Francoforte sul Meno.
• Livello 2: filtraggio Arbor in tempo reale da 3,2 Tbps direttamente in loco a Francoforte sul Meno. Immediatamente davanti al server vengono riconosciuti gli schemi specifici di protocollo e scartati pacchetto per pacchetto.

Tre caratteristiche sono decisive. La protezione è permanentemente attiva, quindi non c'è alcuna fase di rilevamento in cui il tuo server va offline. Non viene usato alcun null-routing: l'indirizzo attaccato resta in rete e vengono scartati solo i pacchetti dannosi, mentre le connessioni dei giocatori veri proseguono. E non costa nulla in più, ma è inclusa dalla consegna in ogni pacchetto server, dal server root KVM al game server fino al server dedicato. Il filtraggio avviene sui livelli 3, 4 e 7 su ogni porta TCP o UDP, quindi contemporaneamente sulla 22003 UDP, sulla 22005 TCP e sulla 22126 UDP. Il tutto è gestito nel datacenter maincubes a Francoforte sul Meno, in Germania. Quali giochi e protocolli abbiano profili propri lo mostra l'articolo 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 questo caso 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:

• Un IP di protezione dedicato dal core di Francoforte. Il tuo server viene spostato su di esso all'interno della rete di KernelHost, e dalla tua parte non modifichi nulla.
• Regole di protezione gestibili da te per porta e protocollo nell'area clienti. È esattamente questo il punto con MTA:SA: imposti regole separate per la 22003 UDP, la 22005 TCP e la 22126 UDP, invece di fare di tre servizi molto diversi un fascio unico.
• Le modifiche hanno effetto in tempo reale, senza ticket e senza attesa. Puoi quindi correggere il tiro nel bel mezzo di un attacco in corso.
• Un profilo di protezione adatto al gioco. Multi Theft Auto è presente come profilo proprio, così come server web, server vocali e applicazioni TCP o UDP proprie che stiano dietro lo stesso indirizzo protetto.

I due livelli a confronto

Per la maggior parte dei progetti MTA:SA 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 bloccato la 22126, il server comunque non compare in nessuna lista, ma continuano ad arrivare richieste": allora il socket è ancora aperto. <ase>0</ase> da solo non chiude la porta finché è impostato <donotbroadcastlan>0</donotbroadcastlan>. Verifica con ss -lnup | grep 22126 se davvero non c'è più nulla in ascolto.

"I giocatori restano appesi nella schermata di caricamento, il gioco in sé funziona normalmente": non è un attacco alla 22003, ma il server HTTP sulla 22005 al limite. Sposta i download con httpdownloadurl e verifica httpmaxconnectionsperclient e httpthreadcount.

"Il server è sparito dal browser, i giocatori che ci sono sopra non notano nulla": allora a essere colpita è esclusivamente la 22126. Per i giocatori collegati è senza conseguenze, per l'afflusso di nuovi giocatori no. Una limitazione di frequenza su questa singola porta è la risposta giusta, non una sulla porta di gioco.

"Abbiamo cambiato indirizzo IP e due ore dopo eravamo di nuovo offline": chi attacca ha preso il nuovo indirizzo dalla stessa fonte del vecchio, di solito la voce in lista, un bot Discord con richiesta di stato oppure un vecchio record DNS. Cambiare indirizzo fa guadagnare tempo, non è una soluzione.

"Abbiamo impostato un rate limit di 20 pacchetti al secondo per indirizzo sulla 22003": è troppo stretto. Già un singolo giocatore con la sincronizzazione attiva sta sopra quel valore, e più giocatori dietro lo stesso indirizzo NAT si dividono lo stesso contingente. Così butti fuori i tuoi stessi giocatori. Sulla 22126, invece, i valori stretti non sono un problema.

"Ci siamo bloccati fuori con il firewall": un riavvio non aiuta, perché UFW ripristina le proprie regole all'avvio. Su KernelHost apri la console VNC nell'area clienti ed esegui lì ufw disable. La console VNC lavora indipendentemente dalla rete del sistema ospite.

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

"Aspettiamo semplicemente che l'attacco passi": gli attacchi che funzionano vengono ripetuti. Documenta il momento con il fuso orario, la durata, i valori di picco e la porta colpita. Sono esattamente queste indicazioni che servono anche a un ticket di supporto, perché il filtraggio venga affinato in modo mirato.

In breve

• Un server MTA:SA ha bisogno di esattamente tre porte: 22003 UDP per il gioco, 22005 TCP per il server HTTP interno e 22126 UDP per la query ASE. La terza risulta in modo fisso dalla porta di gioco più 123.
• La query ASE sta su una porta propria e si può quindi limitare senza escludere un solo giocatore. È la differenza più importante rispetto a SA-MP, dove gioco e query condividono la stessa porta.
• Un singolo byte di richiesta sulla 22126 genera una risposta che arriva a diversi kilobyte, e l'indirizzo mittente si può falsificare. Una porta ASE senza freni è quindi bersaglio e amplificatore allo stesso tempo.
• I freni integrati di MTA agiscono per indirizzo sorgente: cinque query in sei secondi, quattro ingressi in 30 secondi. Con più di 100 indirizzi sorgente contemporanei il conteggio delle query viene saltato, quindi un'ondata distribuita passa.
• Il server HTTP interno sulla 22005 è una superficie di attacco a sé. Chi sposta i download su un server web esterno con httpdownloadurl li toglie dal gioco.
• Tutto ciò che gira sul server decide soltanto degli attacchi piccoli. Con 1 Gbit/s si finisce a circa 1,49 milioni di pacchetti al secondo, indipendentemente dalla qualità delle tue regole.
• La protezione permanente a due livelli su KernelHost è inclusa in ogni pacchetto server senza sovrapprezzo e lavora senza null-routing. Chi vuole gestire da sé le regole per porta aggiunge la Advanced DDoS Protection a partire da 50,00 € al mese.

Se il tuo progetto gira già su KernelHost, il filtraggio è permanentemente attivo e non devi attivare nulla. Se noti comunque delle anomalie, apri un ticket di supporto con periodo, porta e comportamento osservato, così le regole per il tuo indirizzo vengono affinate. Durante un attacco in corso ci raggiungi anche tramite la chat WhatsApp di emergenza al numero +43 650 8209883. Se ospiti ancora altrove e vieni colpito con regolarità, il trasferimento a Francoforte sul Meno è la soluzione più breve: altri passi per il caso acuto stanno nell'articolo Attacco DDoS grave: che cosa fare adesso.