Proteggere un server Palworld dagli attacchi DDoS

Un server Palworld che la sera, nel bel mezzo della partita, butta fuori tutti i giocatori insieme, resta offline per qualche minuto e poi torna raggiungibile da solo, raramente ha un problema hardware. Di norma è in corso un attacco. Questo articolo mostra come proteggere un server Palworld dagli attacchi DDoS: prima quello che puoi configurare da solo senza costi aggiuntivi, poi il punto in cui queste misure si fermano dal punto di vista tecnico e infine che cosa deve succedere nella rete davanti al server perché il server resti raggiungibile.

Tutte le indicazioni si riferiscono al server dedicato ufficiale di Pocketpair (ID app Steam 2394010) su Debian 12, Debian 13, Ubuntu 22.04 LTS oppure Ubuntu 24.04 LTS. I comandi sono scritti per root; se lavori come utente normale, anteponi sudo. Se l'attacco è in corso proprio adesso, vale un ordine preciso: prima misurare, poi modificare. Un riavvio forzato sotto carico butta via tutto quello che è successo nel mondo dopo l'ultimo salvataggio automatico, e anche i valori misurati durante l'incidente spariscono.

Perché i server Palworld vengono messi fuori uso con attacchi DDoS mirati

Un server Palworld è un pubblico piccolo e stabile a un indirizzo fisso. Il server dedicato è limitato a 32 giocatori, regolati tramite ServerPlayerMaxNum con l'intervallo valido da 1 a 32. Chi invece ospita dal menu del gioco arriva a quattro giocatori, e soltanto finché il padrone di casa resta online. Da questi 32 posti discende tutto il resto: il gruppo gioca in orari serali fissi, si conosce, e un disservizio alle 20 non colpisce una frazione dei giocatori, ma tutti.

L'indirizzo del server, in tutto questo, non è un segreto. Palworld non prevede alcuna intermediazione tramite un servizio del produttore: i giocatori inseriscono indirizzo IP e porta nel campo della connessione diretta, e chi vuole vedere il proprio server anche nella lista dei server della community lo avvia con -publiclobby e lascia rispondere la porta di query. Chiunque si sia collegato anche una sola volta conosce quindi il bersaglio. Un servizio booter che bombarda questo indirizzo per pochi euro al mese non chiede al committente né competenze né fatica.

Sul piano tecnico si aggiunge il fatto che tutto il traffico di gioco passa da 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 server né interrogarlo in modo corretto per generare carico. Che cosa succeda tecnicamente durante un attacco del genere lo spiega l'articolo Che cos'è un attacco DDoS?.

Le porte di cui si tratta davvero su un server Palworld

Un server Palworld ha bisogno esattamente di una porta aperta: 8211 UDP. Tutto il resto è facoltativo e, a seconda del compito, persino dannoso se sta su internet. Ne deriva una distinzione utile: un attacco DDoS sulla porta 8211 colpisce sempre il traffico di gioco vero e proprio, mentre un attacco sulla porta 27015 UDP colpisce soltanto la voce nella lista dei server.

Tutti i relativi interruttori stanno in un unico file: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, su Windows corrispondentemente Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. Comincia con la riga di sezione [/Script/Pal.PalGameWorldSettings], seguita da un'unica riga OptionSettings=(...) che contiene come elenco tutte le impostazioni. Un a capo dentro la parentesi rende non valida l'intera configurazione, e il server torna ai valori standard senza dire nulla. Il modello DefaultPalWorldSettings.ini nella cartella del server non va modificato, perché viene sovrascritto a ogni aggiornamento.

Il server Palworld in cifre

I valori che seguono sono la base di ogni decisione su regole di filtraggio e soglie.

Perché la porta di query 27015 è il punto più delicato

La porta di query risponde alle richieste di stato nel formato Steam A2S, cioè la stessa interrogazione che servono anche i server di Counter-Strike e di ARK. Una richiesta A2S_INFO è un pacchetto UDP senza connessione di poche decine di byte, mentre la risposta con nome del server, mondo, numero di giocatori e stato della partita è un multiplo di quella dimensione. Siccome in UDP l'indirizzo mittente si può falsificare, chi attacca può interrogare porte di query altrui e dirigere le risposte più grandi verso il proprio vero bersaglio. In questo caso il tuo server non è la vittima, ma l'amplificatore, e a pagare il conto è la sua connettività.

Per questo motivo l'8 dicembre 2020 Valve ha aggiunto ad A2S_INFO una challenge preliminare: il server risponde prima con S2C_CHALLENGE, chi interroga deve rimandare indietro il token e dimostra così di non falsificare il proprio indirizzo mittente. Questo attenua l'amplificazione, ma non la elimina, e contro una semplice ondata di interrogazioni uguali provenienti da indirizzi reali non serve a nulla.

Per Palworld ne deriva un vantaggio importante rispetto al motore Source: traffico di gioco e interrogazione del server stanno su porte separate. In Counter-Strike 2 entrambi si dividono la porta 27015, e lì un limite di frequenza grossolano butta fuori anche i propri giocatori. Su Palworld puoi limitare duramente la 27015 UDP oppure chiuderla del tutto senza toccare un solo pacchetto di traffico di gioco in corso sulla 8211 UDP. Chi non ha bisogno della voce nella lista toglie -publiclobby e la porta di query senza sostituirli, e in questo modo rimuove dalla rete un'intera superficie di attacco.

Che cosa puoi fare da solo prima di spendere

I passi che seguono non fermano un attacco volumetrico: nessun software sul server può farlo. Ripuliscono però tutto ciò che sta al di sotto: scansioni delle porte, ondate di query, tentativi di presa di controllo tramite le porte di amministrazione e l'occupazione di tutti i 32 posti da parte di estranei. È la maggior parte di ciò che disturba un server Palworld nella vita di tutti i giorni, e costa mezz'ora.

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

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

ss -lntup

La colonna interessante è quella dell'indirizzo locale. 0.0.0.0:8211 significa "raggiungibile da tutta internet", 127.0.0.1:8212 significa "solo in locale" e non richiede alcuna regola firewall. Accanto al processo di gioco, su un server cresciuto nel tempo spesso compaiono anche un pannello di gestione, un server web per la visualizzazione della mappa e un database. Il punto di vista di chi attacca te lo dà una scansione delle porte dall'esterno:

nmap -Pn -sU -p 8211,27015 IP.DEL.TUO.SERVER
nmap -Pn -p- --min-rate 1000 IP.DEL.TUO.SERVER

2. Aprire solo ciò di cui Palworld ha davvero bisogno

Bastano due aperture, e la seconda è facoltativa. 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 8211/udp comment 'Palworld traffico di gioco'
ufw allow 27015/udp comment 'Palworld query Steam'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

La terza riga la lasci perdere se il tuo server non deve comparire nella lista dei server della community. I tuoi giocatori si collegano allora come sempre tramite indirizzo IP e porta 8211, il server sparisce soltanto dall'elenco pubblico. La guida completa, via di fuga compresa, è in Configurare il firewall UFW senza bloccarsi fuori.

3. Togliere da internet RCON sulla 25575 e la REST API sulla 8212

Entrambe le porte sono accessi amministrativi con pieno controllo sul server, ed entrambe sono disattivate di serie: RCONEnabled=False e RESTAPIEnabled=False. Chi le attiva dovrebbe sapere che cosa sta pubblicando.

La REST API sulla 8212 TCP si autentica tramite HTTP Basic Auth con il nome utente fisso admin e il valore di AdminPassword, e lo fa via HTTP non cifrato. La password di amministrazione passa quindi sulla linea in forma reversibile a ogni singola richiesta. RCON sulla 25575 TCP è un protocollo testuale altrettanto non cifrato, e Pocketpair lo ha indicato come obsoleto a favore della REST API. Per le nuove installazioni la scelta giusta è la REST API; per entrambe vale la stessa regola: non sulla rete aperta.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="un valore lungo e casuale"

L'interfaccia la rendi raggiungibile con un inoltro di porta via SSH, dopodiché lavori in locale contro 127.0.0.1:8212:

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

Non lasciare mai AdminPassword vuota, perché vuota è l'impostazione predefinita. Basta un valore da openssl rand -base64 32. Lo stesso vale per ServerPassword, e fra poco vediamo perché.

4. Limitare la porta di query 27015 senza perdere la voce nella lista

I pacchetti Steam senza connessione iniziano con quattro byte impostati (0xffffffff), mentre il normale traffico di gioco non ha questa intestazione. Su questo si può appoggiare un limite di frequenza per indirizzo sorgente che frena le interrogazioni e conserva la voce nella lista. Con nftables, caricato tramite nft -f:

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

La priorità -10 fa in modo che la regola agisca prima della catena di filtraggio di UFW, e @th,64,32 legge i primi quattro byte dopo l'intestazione UDP. Con il classico iptables la stessa separazione si ottiene confrontando la firma di A2S_INFO:

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Dieci interrogazioni al secondo per indirizzo sono una misura generosa: un servizio di elenco interroga di solito ogni pochi minuti, non più volte al secondo. L'unica cosa che conta è che questa regola stia sulla 27015 e non sulla 8211, altrimenti colpisci i tuoi stessi giocatori.

5. Limitare la frequenza dei pacchetti sulla 8211 UDP

Sulla porta di gioco vera e propria un tetto massimo per indirizzo sorgente aiuta contro le piccole ondate da poche sorgenti. Su Palworld questo limite si imposta con un rischio relativamente basso, perché al massimo 32 giocatori sono collegati insieme e ognuno di loro occupa esattamente un indirizzo sorgente:

iptables -I INPUT -p udp --dport 8211 \
  -m hashlimit --hashlimit-name palworld_udp --hashlimit-mode srcip \
  --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

Il numero è un valore di partenza, non una verità assoluta. Un server pieno con 32 giocatori e molte basi genera nettamente più pacchetti di una partita in quattro, e chi stringe troppo butta fuori i propri giocatori. Misura prima una settimana di funzionamento normale, poi imposta il limite al doppio del picco misurato.

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 inoltre in /etc/ufw/before.rules, altrimenti al prossimo ufw reload spariscono. Se una regola venga effettivamente raggiunta lo mostra iptables -L INPUT -n -v: se i contatori dei match restano a zero, non sta agendo.

6. Password del server, lista dei ban e i 32 posti contro l'esaurimento degli slot

L'esaurimento degli slot è l'attacco più economico contro un server Palworld e non richiede banda. Un server dedicato ha al massimo 32 posti, quindi bastano 32 connessioni contemporanee per chiudere fuori l'intera comunità. Un attacco volumetrico costa denaro al committente, 32 sessioni non gli costano nulla. Questo rende quella strada più attraente di qualsiasi ondata, soprattutto contro i server piccoli.

Palworld non ha una whitelist integrata. Gli strumenti di moderazione sono l'espulsione, il ban e una password del server, e proprio la password del server è la singola misura più efficace contro l'esaurimento degli slot:

ServerPassword="un valore che conosce solo il tuo gruppo"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword è vuota di serie, quindi chiunque abbia indirizzo IP e porta entra. BanListURL punta in modo predefinito alla lista gestita da Pocketpair e si può dirottare su un file di testo tuo, se vuoi tenere blocchi specifici del progetto. ServerPlayerMaxNum non impostarla sopra 32: i valori più alti non sono supportati e si ritorcono contro al più tardi al prossimo aggiornamento. E una cosa deve essere chiara: una password del server protegge i tuoi posti, non la tua linea. Chi inonda il tuo server non ha alcuna intenzione di entrare.

7. Alleggerire il tracciamento delle connessioni e ingrandire i buffer

Questo punto spiega disservizi che sembrano un attacco volumetrico ma non lo sono. Il kernel crea voci nel tracciamento delle connessioni (conntrack) anche per il traffico UDP, e con indirizzi mittente falsificati ogni indirizzo significa una voce nuova. Quando la tabella è piena, il kernel scarta pacchetti senza distinzione, l'attacco e i tuoi giocatori volano fuori insieme 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 passo più efficace è non far tracciare affatto il traffico di gioco, perché Palworld gestisce da sé le proprie sessioni:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

Con iptables l'equivalente è iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK e la stessa riga per OUTPUT con --sport. Le porte hanno poi bisogno di un'apertura esplicita, perché senza tracciamento non funziona più nessuna regola che verifichi uno stato esistente. Se i pacchetti arrivano più in fretta di quanto il processo del server li raccolga, va in overflow anche il buffer di ricezione. Per i giocatori sembra perdita di pacchetti, benché la linea sia libera. Un file aggiuntivo sotto /etc/sysctl.d/, attivato con sysctl -p:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Se questi valori siano necessari lo dice il kernel stesso: se UdpRcvbufErrors in nstat -az sale, allora servono. Se il contatore resta a zero, la modifica non cambia nulla.

8. Raccogliere valori misurati prima che la situazione si faccia seria

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 quattro comandi:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 -c 200 "udp port 8211 or udp port 27015"

Per tcpdump vale una regola: limita sempre con -c, perché una cattura a pieno carico appesantisce ancora di più un server già sovraccarico. Palworld offre in più una grandezza di misura che nessun altro strumento ha. Se la REST API è attiva, l'endpoint delle metriche restituisce fra le altre cose la frequenza dei fotogrammi del server, il numero attuale di giocatori e il tempo di esecuzione:

curl -s -u admin:LA_TUA_PASSWORD_ADMIN http://127.0.0.1:8212/v1/api/metrics

Questo unico numero separa con precisione le due cause più frequenti. Se la frequenza dei fotogrammi del server crolla mentre le frequenze dei pacchetti restano normali, non è un attacco, ma carico oppure il noto aumento di memoria del processo del server. Se la frequenza dei fotogrammi resta stabile mentre i pacchetti in ingresso salgono ben oltre il valore normale, è un attacco. Come interpretare nel dettaglio i valori di rete 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ù. Gli attacchi contro i progetti di game server 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 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 del processore e della 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, 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". Su Palworld la cosa si manifesta prima come picchi di lag e solo dopo come caduta della connessione.

Su un server Palworld si aggiunge un rapporto sfavorevole. Un server pieno con 32 giocatori occupa solo una frazione di una linea da 1 Gbit/s. L'attacco non deve quindi essere grande per raggiungere un multiplo del funzionamento normale, ed è esattamente per questo che qui bastano già attacchi che su una grande piattaforma non si noterebbero.

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 in ogni pacchetto 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. Palworld è fra i giochi con un profilo di protezione dedicato; quali altri titoli e protocolli siano coperti lo elenca Protezione DDoS per game server in tempo reale.

Advanced DDoS Protection per progetti Palworld 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.
• Regole di protezione gestibili da te per porta e protocollo nell'area clienti: stabilisci separatamente che cosa è permesso sulla 8211 UDP e che cosa sulla 27015 UDP, 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 limitando temporaneamente in modo più duro la porta di query e lasciando intatta la porta di gioco.
• Profilo di protezione adatto al gioco, per Palworld così come per applicazioni proprie su porte TCP o UDP a piacere.

La Advanced DDoS Protection si rivolge ai server che stanno presso KernelHost. Chi gestisce il proprio progetto Palworld altrove e viene attaccato in modo continuativo lo trasferisce a KernelHost, e allora entrambi i livelli sono attivi dal momento della consegna.

I due livelli a confronto

Per la maggior parte dei server Palworld 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 sui server Palworld e loro soluzione

"Ho bloccato la 27015 e adesso il server è sparito dalla lista della community": è il comportamento previsto, perché è la porta di query a portare la voce nella lista. Non bloccarla in blocco, ma limita i pacchetti senza connessione per indirizzo sorgente come nel passo 4. Se la voce nella lista non ti serve comunque, lascia la porta chiusa, togli -publiclobby e dai ai tuoi giocatori indirizzo IP e porta 8211 per la connessione diretta.

"Ho cambiato indirizzo IP e due ore dopo ero di nuovo offline": chi attacca ha preso il nuovo indirizzo dalla stessa fonte del vecchio. Su Palworld è quasi sempre una di tre strade: un giocatore che ha comunque l'indirizzo nel campo della connessione diretta, un bot Discord con indicatore di stato che lo ripubblica oppure un vecchio record A nel DNS che punta all'indirizzo precedente. Cambiare indirizzo fa guadagnare tempo, non risolve.

"Il server ha picchi di lag, ma la linea è tranquilla": su Palworld è più spesso carico che attacco. Il processo del server occupa sempre più memoria con il passare del tempo di esecuzione, ed è per questo che un riavvio pianificato fa parte del normale funzionamento e non va inteso come rimedio d'emergenza. Controlla la frequenza dei fotogrammi del server tramite l'endpoint delle metriche e il consumo di memoria del processo. Se nel frattempo sar -n DEV 1 10 resta normale, non era un attacco DDoS.

"Tutti i 32 posti sono occupati, ma nel gioco non si vede nessuno": è esaurimento degli slot e colpisce la logica di gioco, non la linea. Imposta una ServerPassword, blocca gli account sospetti tramite la lista dei ban e limita i pacchetti per indirizzo sorgente sulla 8211 UDP.

"La REST API è rimasta raggiungibile dall'esterno per qualche giorno": allora la tua password di amministrazione è compromessa, perché HTTP Basic Auth su HTTP non cifrato la trasmette in forma reversibile a ogni richiesta. Cambia AdminPassword, chiudi la 8212 TCP verso l'esterno e raggiungi l'interfaccia solo tramite un inoltro di porta via SSH.

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

"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 Palworld ha bisogno esattamente di una porta aperta: 8211 UDP. La porta di query 27015 UDP serve solo per la voce nella lista dei server della community.
• RCON sulla 25575 TCP e la REST API sulla 8212 TCP non devono mai stare sulla rete aperta, perché entrambe trasmettono le proprie credenziali senza cifratura. RCON è inoltre indicato da Pocketpair come obsoleto.
• Siccome su Palworld traffico di gioco e interrogazione del server stanno su porte separate, la 27015 UDP si può limitare duramente senza toccare il traffico di gioco in corso sulla 8211 UDP.
• Il server dedicato è limitato a 32 posti, quindi l'esaurimento degli slot è l'attacco più economico. Una ServerPassword impostata è la singola misura più efficace, perché Palworld non ha una whitelist integrata.
• Le misure locali finiscono alla linea: 1 Gbit/s sono 125 megabyte al secondo, e con pacchetti da 64 byte lì dentro entrano circa 1,49 milioni di pacchetti al secondo. Tutto ciò che sta sopra deve finire nella rete, prima del server.
• Presso KernelHost la protezione permanente a due livelli è inclusa senza sovrapprezzo in ogni pacchetto server ed è attiva dalla consegna, senza null-routing. La Advanced DDoS Protection, con IP di protezione dedicato e regole per porta gestibili da te, parte da 50,00 € al mese.

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