Proteggere un server Terraria dagli attacchi DDoS

Chi vuole proteggere il proprio server Terraria dagli attacchi DDoS ha a che fare con un caso particolare: Terraria parla esclusivamente TCP. Il traffico di gioco passa da una sola porta, la 7777 TCP, e una porta UDP il gioco non la apre affatto. Quasi tutti i consigli che circolano in rete sulla protezione dei game server sono scritti per giochi UDP e qui cadono nel vuoto oppure colpiscono nel punto sbagliato.

Questo articolo mostra prima che cosa puoi mettere in sicurezza da solo senza costi aggiuntivi, poi dove queste misure si fermano dal punto di vista tecnico e infine che cosa deve succedere nella rete, prima del server. Tutte le indicazioni si riferiscono a un server dedicato Terraria (vanilla, TShock o tModLoader) 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 per prima cosa nulla nella configurazione e non riavviare il server: metti al sicuro i valori misurati (vedi il paragrafo "Registra i log"), perché dopo l'attacco non ci sono più.

Perché proprio i server Terraria vengono colpiti da attacchi DDoS

I server Terraria sono un bersaglio comodo, perché il loro indirizzo è per forza pubblico. Terraria vanilla non ha un browser dei server integrato: i giocatori si collegano tramite "Multiplayer" e "Join via IP", quindi attraverso un indirizzo che qualcuno deve aver reso noto prima. Chi vuole nuovi giocatori iscrive il server su siti di liste come terraria-servers.com, tserverweb.com o topg.org, oppure distribuisce l'indirizzo via Discord. Ognuna di queste strade consegna a chi attacca esattamente quello che consegna al giocatore: indirizzo IP e porta in chiaro.

Se un server Terraria va offline di continuo, pur non essendo cambiato nulla in hardware, mondo e lista dei mod, un attacco è quindi la spiegazione più probabile. A questo si aggiunge la costellazione tipica di un progetto: orari di gioco fissi, server concorrenti, giocatori bannati e liti nella community. Un attacco non costa a chi lo commissiona né competenze né soldi degni di nota, un Terraria Server Booter viene venduto come abbonamento per pochi euro al mese. Che cosa sia tecnicamente un attacco DDoS e come venga costruito lo spiega l'articolo Che cos'è un attacco DDoS?.

Terraria gira su TCP, non su UDP

Questa è la differenza più importante rispetto a praticamente ogni altro game server. Il server dedicato di Terraria accetta le connessioni con un listener TCP (nel motore di gioco la classe Terraria.Net.Sockets.TcpSocket) e non apre alcun socket UDP. Questo ha quattro conseguenze che determinano tutta la tua difesa:

• Una connessione TCP completamente stabilita non si può falsificare. Chi attacca deve ricevere il SYN-ACK del server per portare a termine l'handshake. Chi è davvero collegato arriva quindi da un indirizzo reale. I blocchi per IP e i limiti di connessione funzionano su Terraria nettamente meglio che su un gioco UDP.
• Un SYN flood si può invece benissimo falsificare, perché non porta mai a termine l'handshake. Contro questo tipo non serve alcun blocco per IP, ma soltanto i SYN cookie e il filtraggio a monte.
• Ogni connessione TCP accettata sulla porta 7777 occupa risorse nel processo di gioco, non solo nel kernel. Questo rende l'esaurimento degli slot l'attacco più efficace con la banda più bassa.
• Un UDP flood colpisce comunque il tuo server. I pacchetti non devono essere accettati per riempire la tua linea. Il fatto che Terraria non parli UDP non protegge la linea, impedisce soltanto che sia il processo di gioco a elaborare quei pacchetti.

Un'eccezione c'è: se avvii il server dedicato con -steam e -lobby friends oppure -lobby private, la connessione passa dalla rete Steam e quindi da porte UDP nell'intervallo da 27000 a 27100. Quella è una modalità di funzionamento diversa e non il classico server raggiungibile tramite indirizzo IP.

Le porte di cui si tratta davvero

Un server Terraria ha bisogno di una sola porta sulla rete aperta: la 7777 TCP. Tutto il resto in questa tabella non va su internet oppure va soltanto sul tuo indirizzo.

Il fatto che Terraria non conosca né una porta di query né RCON è una buona notizia per la messa in sicurezza: i due endpoint che su Counter-Strike, Rust o ARK vengono regolarmente sfruttati per attacchi di reflection qui semplicemente non esistono. In compenso la superficie di attacco è tanto più concentrata sulla porta 7777, e chi usa TShock si porta in casa con la porta 7878 una seconda superficie.

Che cosa puoi fare da solo prima di spendere soldi

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

1. Ricognizione: 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:7777 significa "raggiungibile da tutta internet", 127.0.0.1:7878 significa "solo in locale" e non richiede alcuna regola firewall. Se in questo elenco compare una voce UDP per il tuo processo Terraria, il server sta girando in modalità Steam. Il punto di vista di chi attacca te lo dà una scansione delle porte dall'esterno:

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

2. Lascia aperta solo la 7777 TCP e chiudi tutto il resto

A Terraria basta una sola apertura verso l'esterno. Una regola UDP non ti serve, e una regola UDP per la 7777 sarebbe semplicemente sbagliata: lascia passare traffico su una porta dove non è in ascolto nulla. 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/tcp comment 'Terraria'
ufw allow from 203.0.113.10 to any port 7878 proto tcp comment 'TShock REST'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sostituisci 203.0.113.10 con il tuo indirizzo. La guida completa, via di fuga compresa, è nell'articolo Configurare il firewall UFW senza bloccarsi fuori. Chi gestisce un pannello limita anche la 8080 e la 2022 al proprio indirizzo.

3. serverconfig.txt: impostare bene password, maxplayers e secure

Il file di configurazione centrale del server Terraria si chiama serverconfig.txt e viene passato all'avvio con -config serverconfig.txt. Quattro direttive sono decisive per la messa in sicurezza:

port=7777
maxplayers=16
password=UnaPasswordLungaECasuale
secure=1
upnp=0
banlist=banlist.txt

password= è la misura gratuita più efficace contro i flood di ingressi che passano dalla via regolare. Il motivo sta nel protocollo: un client manda per primo il messaggio 1 con il proprio identificativo di versione (per esempio Terraria279), con una password impostata il server risponde con il messaggio 37, il client deve rispondere correttamente con il messaggio 38, e solo dopo il server manda con il messaggio 3 il via libera insieme allo slot giocatore. Senza la password giusta, chi attacca non arriva quindi mai al trasferimento del mondo, che è la parte costosa di un ingresso.

maxplayers accetta valori da 1 a 255, l'impostazione predefinita è 16 (prima della versione 1.4.0.1 erano 8). Il limite massimo di 255 non è un numero arbitrario: Terraria indirizza i giocatori con un singolo byte. Non impostare maxplayers più alto di quanto ti serva davvero, perché ogni slot è una risorsa che chi attacca può occupare. secure=1 attiva il controllo anti-cheat integrato (da riga di comando -secure), upnp=0 impedisce che il server apra di sua iniziativa delle porte su un router.

4. Mettere in sicurezza TShock: REST API sulla 7878 e flood di login

TShock è l'estensione server più diffusa per Terraria e con la REST API si porta dietro una seconda superficie di attacco a tutti gli effetti. Sta di serie sulla porta 7878 TCP ed è configurata in tshock/config.json, quindi non nella serverconfig.txt. Allo stato di consegna è disattivata ("RestApiEnabled": false), e così dovrebbe restare finché non ti serve.

Se ti serve, questi sono i valori rilevanti:

"RestApiEnabled": true,
"RestApiPort": 7878,
"EnableTokenEndpointAuthentication": true,
"LogRest": true,
"RESTMaximumRequestsPerInterval": 5,
"RESTRequestBucketDecreaseIntervalMinutes": 1

Due cose sono importanti. Primo, l'endpoint /status consegna senza token il nome del server, la porta, il numero di giocatori e i nomi dei giocatori, finché EnableTokenEndpointAuthentication resta su false. È comodo per pagine di stato e bot Discord e allo stesso tempo è ricognizione gratuita per chiunque voglia sapere quando conviene attaccare. Secondo, l'endpoint /v2/token/create genera da nome utente e password un token di accesso, ed è raggiungibile dall'esterno non appena la porta 7878 è aperta: un attacco per indovinare la password del tuo account amministratore che, per giunta, costa tempo di calcolo. Il bucket formato da RESTMaximumRequestsPerInterval e RESTRequestBucketDecreaseIntervalMinutes lo frena, ma non sostituisce una regola firewall.

Per l'accesso al gioco vero e proprio valgono altri valori di TShock. MaximumLoginAttempts sta su 3 e butta fuori un giocatore dopo tre tentativi falliti. RequireLogin (predefinito false) richiede un account per ogni giocatore. EnableIPBans (predefinito true) e KickProxyUsers (predefinito true) sono particolarmente efficaci in un gioco TCP, perché l'indirizzo sorgente di una connessione stabilita non può essere falsificato. Contro il griefing, che viene spesso segnalato come attacco, funzionano le soglie TileKillThreshold (60), TilePlaceThreshold (20), TileLiquidThreshold (15) e ProjectileThreshold (50), ciascuna riferita alle azioni al secondo.

5. Limita le connessioni per indirizzo sorgente e verifica i SYN cookie

Poiché Terraria gira su TCP, la regola locale più efficace è un limite massimo di connessioni contemporanee per indirizzo sorgente. Un giocatore reale ne ha bisogno di esattamente una:

iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m hashlimit --hashlimit-name terraria_syn --hashlimit-mode srcip --hashlimit-above 10/min --hashlimit-burst 20 -j DROP

La prima regola scarta le nuove connessioni non appena un indirizzo ne tiene aperte più di tre contemporaneamente. La seconda limita a dieci al minuto, con un margine di 20, la frequenza dei tentativi di connessione della stessa sorgente. Entrambi i numeri sono valori di partenza, non verità assolute: un server dietro una linea condivisa (appartamento condiviso, rete scolastica, operatore mobile) vede più giocatori legittimi sotto lo stesso indirizzo. Misura prima una settimana di funzionamento normale.

Le semplici regole iptables spariscono dopo un riavvio; su Debian e Ubuntu si salvano così:

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

Con UFW regole di questo tipo vanno in /etc/ufw/before.rules, altrimenti al prossimo ufw reload spariscono. Contro i pacchetti SYN falsificati, che non portano mai a termine l'handshake, non serve nessuna di queste regole, ma il kernel stesso. Verifica i tre valori:

sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn

net.ipv4.tcp_syncookies deve stare su 1, e su Debian e Ubuntu di norma è già così. I SYN cookie rinunciano alla coda delle connessioni semiaperte e ricostruiscono lo stato dalla risposta del client: un SYN flood finisce così nel vuoto, finché la linea non è satura. net.core.somaxconn vale 4096 da Linux 5.4 e prima 128: se il valore è basso, il kernel scarta connessioni già stabilite prima che il processo di gioco possa accettarle.

6. Impedisci l'esaurimento degli slot: perché una scansione delle porte ti riempie il server

L'esaurimento degli slot è l'attacco efficace più economico contro un server Terraria: chi attacca apre verso la porta 7777 tante connessioni TCP quanti sono gli slot giocatore del server e le tiene aperte. Gli costa quasi zero banda, ma riempie il server. I giocatori veri vedono "Server is full" e non entrano più, pur non succedendo nulla di anomalo sulla tua linea. È esattamente il motivo per cui su Terraria chi gestisce un server spesso non si accorge di essere sotto attacco.

La causa sta nel modo di contare: una connessione viene accettata prima ancora che il client abbia mandato il proprio identificativo di versione. Storicamente queste connessioni fantasma restavano occupate finché la sessione TCP non scadeva. La serie 1.4.5 ha attenuato la cosa: lì per i client che si scollegano subito non vengono più riservati slot. Nelle prime versioni di 1.4.5.7 e 1.4.5.8 il server dedicato andava però in crash con una ObjectDisposedException non gestita non appena una connessione TCP veniva aperta senza portare a termine l'handshake. Bastava un nc -z o un controllo di raggiungibilità di un sistema di monitoraggio. Il difetto è stato corretto in silenzio nel giro di poche settimane, e in alcune immagini container più vecchie è ancora presente. Tieni quindi aggiornata la versione del tuo server: qui non è un luogo comune, ma una questione concreta di disponibilità.

Due impostazioni aiutano in aggiunta. Chi usa TShock imposta MaxSlots sul numero di giocatori desiderato e maxplayers nella serverconfig.txt due posti più in alto: così TShock scarta le connessioni in eccesso con un messaggio pulito, invece che sia il processo di gioco a farle entrare nell'ultimo posto libero. E il limite di connessioni del paragrafo precedente è proprio la regola che impedisce a un singolo indirizzo di occupare tutti gli slot in una volta.

7. Disattiva UPnP e non pubblicare tu stesso l'indirizzo

Il server Terraria cerca di serie di aprire la propria porta su un router tramite UPnP. Su un server noleggiato è inutile, in una rete domestica apre porte di cui più avanti non saprai più nulla. Disattivalo con upnp=0 nella serverconfig.txt oppure con -noupnp da riga di comando.

Qui conviene inoltre l'onestà invece dei desideri: il tuo indirizzo IP non si può tenere segreto. Lo conosce ogni giocatore che si è collegato anche una sola volta, e una voce su un sito di liste lo pubblica comunque. Efficaci sono due abitudini. Non pubblicare tu stesso l'indirizzo IP grezzo da nessuna parte, ma fai collegare i tuoi giocatori tramite un hostname: il client Terraria risolve un hostname, quindi all'occorrenza puoi cambiare indirizzo senza rompere tutti i riferimenti. E fai pulizia dei vecchi record DNS, perché un record A dimenticato che punta all'indirizzo precedente rende inutile qualsiasi cambio.

8. Salva in cache le interrogazioni di stato invece di inoltrarle

Poiché Terraria non ha un protocollo di interrogazione, pagine di stato, bot Discord e siti di liste rilevano lo stato del tuo server in uno di due modi: aprono una vera connessione TCP alla 7777 e si spacciano per client, oppure interrogano la REST API di TShock. Entrambe le strade costano lavoro al tuo server, ed entrambe crescono con il numero di chi interroga.

La contromisura non costa nulla: non interrogare mai dal browser del visitatore. Fai prelevare lo stato a un singolo servizio a intervalli fissi (30 o 60 secondi bastano), salva il risultato in cache e consegna a tutti i visitatori lo stato memorizzato. Così una pagina di stato molto visitata genera un'interrogazione per intervallo invece di una per visitatore. Chi usa la REST API per questo scopo limita la porta 7878 all'indirizzo di quell'unico servizio.

9. Registra 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 un sabato sera. Con apt-get install -y vnstat sysstat la misurazione resta sempre attiva. Durante un incidente bastano cinque comandi:

sar -n DEV 1 10
ss -s
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 tcp port 7777 -c 200 -q

Il terzo comando è quello specifico di Terraria: conta le connessioni semiaperte. Un valore a due cifre è normale, uno a quattro o cinque cifre è un SYN flood. ss -s mostra accanto il numero complessivo delle connessioni TCP, e se questo numero corrisponde grosso modo al tuo maxplayers mentre nel gioco non c'è nessuno, stai vedendo un esaurimento degli slot. 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.

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ù. Gli attacchi contro progetti di game server di questa dimensione 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 connlimit dietro, perché i pacchetti dei tuoi giocatori si fermano già prima. È esattamente così che nascono i lag spike dei server Terraria, in cui l'utilizzo della CPU sembra normale.

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. Con un SYN flood la soglia è ancora più bassa, perché ogni pacchetto SYN comporta una decisione di stato: bastano già alcune decine di migliaia di pacchetti SYN al secondo per bloccare l'accettazione delle connessioni di un Linux standard, molto prima che la linea sia satura. Chi gestisce un server lo vive così: "l'utilizzo non era nemmeno alto, eppure era sparito tutto".

E il terzo punto è quello che su Terraria viene trascurato più spesso: chi attacca non si regola sul tuo protocollo. Manda ondate UDP e traffico di reflection al tuo indirizzo, pur non essendoci nulla in ascolto su alcuna porta UDP. Il tuo server scarta correttamente questi pacchetti, ma essi hanno già occupato la tua linea, e il tuo server Terraria va offline senza che un solo pacchetto abbia raggiunto il processo di 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 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. Per Terraria questo significa in concreto: le ondate di SYN e di connessioni contro la 7777 TCP finiscono qui, non sulla tua scheda di rete.

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. La sede è Francoforte sul Meno. Quali giochi e protocolli siano coperti lo elenca Protezione DDoS per game server in tempo reale.

Advanced DDoS Protection per progetti attaccati di 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.
• Regole di protezione gestibili da te per porta e protocollo nell'area clienti: imposti che cosa è permesso sulla 7777 TCP e puoi chiudere tutto il resto, senza dover aprire un ticket.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro anche durante un attacco in corso, per esempio stringere la frequenza di connessione ammessa per indirizzo sorgente.
• Profilo di protezione adatto all'applicazione. Per i giochi TCP come Terraria e per applicazioni proprie o modificate su porte TCP o UDP a piacere esistono profili adatti.

I due livelli a confronto

Per la maggior parte dei progetti Terraria basta la protezione permanente inclusa, insieme a una configurazione pulita del server. La Advanced DDoS Protection è la risposta al caso in cui qualcuno se la prenda sul personale. Chi gestisce il proprio server attualmente altrove non ottiene la protezione come aggiunta, ma attraverso il trasferimento a KernelHost: il filtraggio è parte della rete, non un supplemento sul server.

Errori frequenti e soluzioni

"Il server è pieno, ma non c'è dentro nessuno": è un esaurimento degli slot. Verifica con ss -tn dst :7777 | wc -l quante connessioni sono davvero aperte e confronta il dato con la lista dei giocatori (console del server: playing). Se i numeri non coincidono, sono connessioni estranee a occupare gli slot. I rimedi sono il limite di connessioni per indirizzo sorgente, una password del server e una versione aggiornata del server.

"Ho aperto la 7777 UDP e non cambia nulla": corretto, perché sulla 7777 UDP non è in ascolto nulla. Terraria usa esclusivamente TCP. L'apertura UDP non fa danni diretti, ma è un'apertura inutile e un segnale sicuro che è stata copiata una guida per un altro gioco.

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

"I giocatori vengono buttati fuori anche se non c'è alcun attacco": se stringi troppo il tuo limite connlimit, colpisci i giocatori dietro linee condivise. Su TCP succede più in fretta che nei giochi UDP, perché una riconnessione dopo un'interruzione crea subito una nuova connessione mentre la vecchia è ancora in TIME_WAIT. Alza il valore un passo alla volta e osserva i contatori dei match.

"Il server va a scatti, la linea è tranquilla": più spesso si tratta di un mod o di un plugin che di un attacco. Con tModLoader ogni mod in più costa tempo di calcolo nello stesso processo, e un mondo con molte entità satura un core senza che arrivi un pacchetto di troppo. Se sar -n DEV 1 10 resta normale, non era un attacco DDoS.

"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 Terraria ha bisogno di esattamente una porta aperta: la 7777 TCP. Il gioco non apre alcun socket UDP, non ha un protocollo di interrogazione e non ha RCON.
• La REST API di TShock sulla porta 7878 TCP è la seconda superficie di attacco. Lascia RestApiEnabled su false oppure limita la porta al tuo indirizzo.
• Una password del server nella serverconfig.txt è la misura gratuita più efficace, perché senza la risposta corretta al messaggio 37 chi attacca non arriva mai al trasferimento del mondo.
• Su Terraria l'esaurimento degli slot è l'attacco più economico: ogni connessione TCP accettata sulla 7777 occupa un posto, senza banda degna di nota. Contro questo funzionano un limite per indirizzo sorgente, una password e una versione aggiornata del server.
• Poiché Terraria usa TCP, l'indirizzo sorgente di una connessione stabilita non si può falsificare: i blocchi per IP funzionano qui meglio che nei giochi UDP. Contro le ondate di SYN falsificate aiutano solo i SYN cookie e il filtraggio a monte.
• Un UDP flood mette fuori uso il tuo server Terraria anche se non parla UDP, perché riempie la linea prima che il processo di gioco veda qualcosa.
• Più o meno dalla dimensione della tua banda di uplink in su, decide esclusivamente la rete davanti al server. Da KernelHost questo filtraggio è a due livelli, permanentemente attivo e compreso senza sovrapprezzo in ogni pacchetto server.

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.