Palworld-Server vor DDoS-Angriffen schützen

Ein Palworld-Server, der abends mitten im Spiel alle Spieler gleichzeitig herauswirft, für ein paar Minuten offline geht und danach von selbst wieder erreichbar ist, hat selten ein Hardwareproblem. In aller Regel läuft ein Angriff. Dieser Beitrag zeigt, wie Sie einen Palworld-Server vor DDoS-Angriffen schützen: zuerst das, was Sie ohne Zusatzkosten selbst konfigurieren können, danach die Stelle, an der diese Maßnahmen technisch enden, und zum Schluss, was im Netz vor dem Server passieren muss, damit der Server erreichbar bleibt.

Alle Angaben beziehen sich auf den offiziellen dedizierten Server von Pocketpair (Steam-App-ID 2394010) unter Debian 12, Debian 13, Ubuntu 22.04 LTS oder Ubuntu 24.04 LTS. Die Befehle sind für root geschrieben, als normaler Benutzer stellen Sie sudo voran. Wenn der Angriff gerade läuft, gilt eine Reihenfolge: erst messen, dann ändern. Ein harter Neustart unter Last verwirft alles, was seit dem letzten automatischen Speicherpunkt in der Welt passiert ist, und die Messwerte des Vorfalls sind danach ebenfalls weg.

Warum Palworld-Server gezielt mit DDoS-Angriffen lahmgelegt werden

Ein Palworld-Server ist ein kleines, festes Publikum an einer festen Adresse. Der dedizierte Server ist auf 32 Spieler begrenzt, gesteuert über ServerPlayerMaxNum mit dem gültigen Bereich 1 bis 32. Wer statt dessen über das Spielmenü hostet, kommt auf vier Spieler und nur so lange, wie der Gastgeber selbst online ist. Aus diesen 32 Plätzen folgt alles Weitere: Die Gruppe spielt zu festen Abendzeiten, kennt sich untereinander, und ein Ausfall um 20 Uhr trifft nicht einen Bruchteil der Spieler, sondern alle.

Die Adresse des Servers ist dabei kein Geheimnis. Palworld kennt keine Vermittlung über einen Anbieterdienst: Spieler tragen IP-Adresse und Port im Direktverbindungsfeld ein, und wer den Server zusätzlich in der Community-Serverliste führen will, startet ihn mit -publiclobby und lässt den Abfrageport beantworten. Jeder, der einmal verbunden war, kennt damit das Ziel. Ein Booter-Dienst, der diese Adresse für ein paar Euro im Monat beschießt, verlangt vom Auftraggeber weder Können noch Aufwand.

Technisch kommt hinzu, dass der gesamte Spielverkehr über UDP läuft. UDP kennt keinen Verbindungsaufbau, den man verlangen könnte, und die Absenderadresse eines UDP-Pakets lässt sich fälschen. Ein Angreifer muss den Server also weder betreten noch korrekt ansprechen, um Last zu erzeugen. Was bei einem solchen Angriff technisch passiert, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Die Ports, um die es bei einem Palworld-Server tatsächlich geht

Ein Palworld-Server braucht genau einen offenen Port: 8211 UDP. Alles andere ist optional und je nach Aufgabe sogar schädlich, wenn es im Internet steht. Daraus folgt eine nützliche Unterscheidung: Ein DDoS-Angriff auf Port 8211 trifft immer den Spielverkehr selbst, ein Angriff auf Port 27015 UDP dagegen nur den Eintrag in der Serverliste.

Alle Schalter dazu stehen in einer einzigen Datei: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, unter Windows entsprechend Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. Sie beginnt mit der Abschnittszeile [/Script/Pal.PalGameWorldSettings], danach folgt eine einzige Zeile OptionSettings=(...), die sämtliche Einstellungen als Liste enthält. Ein Zeilenumbruch innerhalb der Klammer macht die gesamte Konfiguration ungültig, und der Server fällt kommentarlos auf die Standardwerte zurück. Die Vorlage DefaultPalWorldSettings.ini im Serververzeichnis bearbeiten Sie nicht, denn sie wird bei jedem Update überschrieben.

Palworld-Server in Zahlen

Die folgenden Werte sind die Grundlage für jede Entscheidung über Filterregeln und Grenzwerte.

Warum der Abfrageport 27015 der empfindlichste Punkt ist

Der Abfrageport beantwortet Statusanfragen im Steam-Format A2S, also dieselbe Abfrage, die auch Counter-Strike- und ARK-Server bedienen. Eine A2S_INFO-Anfrage ist ein verbindungsloses UDP-Paket von wenigen Dutzend Byte, die Antwort mit Servername, Welt, Spielerzahl und Spielstand ist ein Vielfaches davon. Weil sich bei UDP die Absenderadresse fälschen lässt, kann ein Angreifer fremde Abfrageports ansprechen und die größeren Antworten auf sein eigentliches Ziel lenken. Ihr Server ist in diesem Fall nicht das Opfer, sondern der Verstärker, und sein Anschluss zahlt die Rechnung.

Valve hat A2S_INFO deshalb am 8. Dezember 2020 um eine vorgeschaltete Challenge ergänzt: Der Server antwortet zuerst mit S2C_CHALLENGE, der Anfragende muss das Token zurückschicken und beweist damit, dass er seine Absenderadresse nicht fälscht. Das entschärft die Verstärkung, beendet sie aber nicht, und gegen eine schlichte Flut gleichartiger Abfragen aus echten Adressen wirkt sie überhaupt nicht.

Für Palworld folgt daraus ein wichtiger Vorteil gegenüber der Source-Engine: Spielverkehr und Serverabfrage liegen auf getrennten Ports. Bei Counter-Strike 2 teilen sich beide den Port 27015, eine grobe Ratenbegrenzung wirft dort die eigenen Spieler mit heraus. Bei Palworld können Sie 27015 UDP hart begrenzen oder ganz schließen, ohne einen einzigen laufenden Spielverkehr auf 8211 UDP zu berühren. Wer den Listeneintrag nicht braucht, streicht -publiclobby und den Abfrageport ersatzlos und nimmt damit eine vollständige Angriffsfläche aus dem Netz.

Was Sie selbst tun können, bevor Sie Geld ausgeben

Die folgenden Schritte halten keinen volumetrischen Angriff auf, das kann keine Software auf dem Server leisten. Sie räumen aber alles ab, was darunter liegt: Portscans, Abfragefluten, Übernahmeversuche über die Administrationsports und die Belegung aller 32 Plätze durch Fremde. Das ist der Großteil dessen, was einen Palworld-Server im Alltag stört, und es kostet eine halbe Stunde.

1. Bestandsaufnahme: was lauscht auf dem Server?

Bevor Sie eine einzige Regel schreiben, sehen Sie nach, was Ihr Server nach außen anbietet. Nicht raten, nachsehen:

ss -lntup

Interessant ist die Spalte mit der lokalen Adresse. 0.0.0.0:8211 bedeutet "aus dem ganzen Internet erreichbar", 127.0.0.1:8212 bedeutet "nur lokal" und braucht keine Firewall-Regel. Neben dem Spielprozess tauchen dort auf einem gewachsenen Server oft noch ein Verwaltungspanel, ein Webserver für die Kartenanzeige und eine Datenbank auf. Die Sicht des Angreifers liefert ein Portscan von außen:

nmap -Pn -sU -p 8211,27015 IHRE.SERVER.IP.ADRESSE
nmap -Pn -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

2. Nur öffnen, was Palworld wirklich braucht

Zwei Freigaben reichen, und die zweite ist optional. Mit UFW sieht das so aus, und zwar genau in dieser Reihenfolge, damit Sie sich nicht selbst aussperren:

ufw allow 22/tcp comment 'SSH'
ufw allow 8211/udp comment 'Palworld Spielverkehr'
ufw allow 27015/udp comment 'Palworld Steam-Abfrage'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Die dritte Zeile lassen Sie weg, wenn Ihr Server nicht in der Community-Serverliste stehen soll. Ihre Spieler verbinden sich dann weiterhin über IP-Adresse und Port 8211, der Server verschwindet lediglich aus der öffentlichen Liste. Die vollständige Anleitung samt Rettungsweg steht in UFW-Firewall einrichten, ohne sich selbst auszusperren.

3. RCON auf 25575 und die REST-API auf 8212 aus dem Internet nehmen

Beide Ports sind Administrationszugänge mit voller Kontrolle über den Server, und beide sind ab Werk abgeschaltet: RCONEnabled=False und RESTAPIEnabled=False. Wer sie einschaltet, sollte wissen, was er damit veröffentlicht.

Die REST-API auf 8212 TCP authentifiziert über HTTP Basic Auth mit dem festen Benutzernamen admin und dem Wert aus AdminPassword, und zwar über unverschlüsseltes HTTP. Das Administrationspasswort läuft damit bei jeder einzelnen Anfrage in umkehrbarer Form über die Leitung. RCON auf 25575 TCP ist ein ebenso unverschlüsseltes Textprotokoll, und Pocketpair hat es zugunsten der REST-API als veraltet gekennzeichnet. Für neue Installationen ist die REST-API die richtige Wahl, für beide gilt dieselbe Regel: nicht ins offene Netz.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="ein langer zufaelliger Wert"

Erreichbar machen Sie die Oberfläche über eine SSH-Portweiterleitung, danach arbeiten Sie lokal gegen 127.0.0.1:8212:

ssh -N -L 8212:127.0.0.1:8212 root@IHRE.SERVER.IP.ADRESSE

Setzen Sie AdminPassword niemals leer, denn leer ist die Voreinstellung. Ein Wert aus openssl rand -base64 32 genügt. Dasselbe gilt für ServerPassword, dazu gleich mehr.

4. Den Abfrageport 27015 begrenzen, ohne den Listeneintrag zu verlieren

Verbindungslose Steam-Pakete beginnen mit vier gesetzten Byte (0xffffffff), regulärer Spielverkehr hat diesen Kopf nicht. Darauf lässt sich eine Ratenbegrenzung je Quelladresse legen, die Abfragen bremst und den Listeneintrag erhält. Mit nftables, geladen über 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
    }
}

Die Priorität -10 sorgt dafür, dass die Regel vor der Filterkette von UFW greift, und @th,64,32 liest die ersten vier Byte hinter dem UDP-Kopf. Mit klassischem iptables erreicht dieselbe Trennung ein Abgleich auf die Kennung von 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

Zehn Abfragen je Sekunde und Adresse sind großzügig bemessen: Ein Listendienst fragt üblicherweise alle paar Minuten, nicht mehrmals je Sekunde. Wichtig ist nur, dass diese Regel auf 27015 steht und nicht auf 8211, sonst treffen Sie Ihre eigenen Spieler.

5. Paketraten auf 8211 UDP begrenzen

Auf dem Spielport selbst hilft eine Obergrenze je Quelladresse gegen kleine Fluten aus wenigen Quellen. Bei Palworld ist diese Grenze vergleichsweise ungefährlich zu setzen, weil höchstens 32 Spieler gleichzeitig verbunden sind und jeder von ihnen genau eine Quelladresse belegt:

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

Die Zahl ist ein Startwert, keine Wahrheit. Ein voller Server mit 32 Spielern und vielen Basen erzeugt deutlich mehr Pakete als eine Runde zu viert, und wer zu eng einstellt, wirft die eigenen Spieler heraus. Messen Sie erst eine Woche im Normalbetrieb, dann setzen Sie die Grenze auf das Doppelte des gemessenen Spitzenwerts.

Reine iptables-Regeln sind nach einem Neustart weg. Unter Debian und Ubuntu sichern Sie sie so:

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

Unter UFW gehören solche Regeln zusätzlich in /etc/ufw/before.rules, weil sie sonst beim nächsten ufw reload verschwinden. Ob eine Regel überhaupt erreicht wird, zeigt iptables -L INPUT -n -v: Bleiben die Trefferzähler bei null, greift sie nicht.

6. Serverpasswort, Ban-Liste und die 32 Plätze gegen Slot-Erschöpfung

Slot-Erschöpfung ist der billigste Angriff auf einen Palworld-Server und braucht keine Bandbreite. Ein dedizierter Server hat höchstens 32 Plätze, also genügen 32 gleichzeitige Verbindungen, um die gesamte Gemeinschaft auszusperren. Ein volumetrischer Angriff kostet den Auftraggeber Geld, 32 Sitzungen kosten ihn nichts. Das macht diesen Weg für kleine Server attraktiver als jede Flut.

Palworld hat keine eingebaute Whitelist. Die Moderationswerkzeuge sind Kick, Bann und ein Serverpasswort, und genau das Serverpasswort ist gegen Slot-Erschöpfung die wirksamste Einzelmaßnahme:

ServerPassword="ein Wert, den nur Ihre Gruppe kennt"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword ist ab Werk leer, jeder mit IP-Adresse und Port kommt also hinein. BanListURL zeigt standardmäßig auf die von Pocketpair gepflegte Liste und lässt sich auf eine eigene Textdatei umbiegen, wenn Sie projekteigene Sperren führen wollen. ServerPlayerMaxNum setzen Sie nicht über 32: Höhere Werte sind nicht unterstützt und fallen spätestens beim nächsten Update auf die Füße. Und eines muss klar sein: Ein Serverpasswort schützt Ihre Plätze, nicht Ihre Leitung. Ein Angreifer, der Ihren Server flutet, will gar nicht beitreten.

7. Die Verbindungsverfolgung entlasten und Puffer vergrößern

Dieser Punkt erklärt Ausfälle, die wie ein Volumenangriff aussehen, aber keiner sind. Der Kernel legt für UDP-Verkehr Einträge in der Verbindungsverfolgung (conntrack) an, und bei gefälschten Absenderadressen bedeutet jede Adresse einen neuen Eintrag. Ist die Tabelle voll, verwirft der Kernel Pakete ohne Unterschied, der Angriff und Ihre Spieler fliegen gemeinsam heraus, und im Protokoll steht "nf_conntrack: table full". Stand und Obergrenze zeigt:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Der wirksamste Schritt ist, den Spielverkehr gar nicht erst verfolgen zu lassen, denn Palworld verwaltet seine Sitzungen selbst:

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
    }
}

Mit iptables lautet die Entsprechung iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK und dieselbe Zeile für OUTPUT mit --sport. Die Ports brauchen danach eine ausdrückliche Freigabe, denn ohne Verfolgung greift keine Regel mehr, die auf einen bestehenden Zustand prüft. Kommen Pakete schneller an, als der Serverprozess sie abholt, läuft zusätzlich der Empfangspuffer über. Für die Spieler sieht das wie Paketverlust aus, obwohl die Leitung frei ist. Ein Aufschlag unter /etc/sysctl.d/, aktiviert mit sysctl -p:

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

Ob die Werte nötig sind, verrät der Kernel selbst: Steigt UdpRcvbufErrors in nstat -az an, dann greifen sie. Bleibt der Zähler bei null, ändert die Anpassung nichts.

8. Messwerte sammeln, bevor es ernst wird

Der wichtigste Schritt ist der, den fast niemand vorher macht: eine Vergleichsbasis anlegen, solange alles normal läuft. Ohne Normalwert können Sie nach einem Vorfall nicht sagen, ob 40.000 Pakete je Sekunde viel waren oder einfach Samstagabend. Mit apt-get install -y vnstat sysstat läuft die Messung dauerhaft mit. Während eines Vorfalls genügen vier Befehle:

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"

Bei tcpdump gilt: immer mit -c begrenzen, ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Palworld liefert zusätzlich eine Messgröße, die kein anderes Werkzeug hat. Ist die REST-API aktiviert, gibt der Metrik-Endpunkt unter anderem die Bildrate des Servers, die aktuelle Spielerzahl und die Laufzeit zurück:

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

Diese eine Zahl trennt die beiden häufigsten Ursachen sauber voneinander. Bricht die Serverbildrate ein, während die Paketraten unauffällig bleiben, ist es kein Angriff, sondern Last oder der bekannte Speicheranstieg des Serverprozesses. Bleibt die Bildrate stabil, während die Eingangspakete weit über den Normalwert steigen, ist es ein Angriff. Wie Sie die Netzwerkwerte im Einzelnen auswerten, steht in DDoS-Angriff am Server erkennen.

Wo diese Maßnahmen aufhören: Bandbreite und Paketrate

Jetzt der Teil, den keine Konfigurationsdatei lösen kann. Alle bisherigen Maßnahmen laufen auf Ihrem Server, also am Ende der Leitung. Eine Firewall-Regel entscheidet über ein Paket, das bereits über das Kabel gelaufen ist. Sie können es verwerfen, aber nicht ungesendet machen.

Rechnen Sie einmal mit. Ein typischer Gameserver hängt an 1 Gbit/s, das entspricht 125 Megabyte je Sekunde, und die Leitung ist voll, sobald jemand mehr schickt. Angriffe gegen Gameserver-Projekte liegen üblicherweise zwischen 5 und 50 Gbit/s, also beim Fünf- bis Fünfzigfachen Ihrer Leitung. Ob Ihre iptables-Regel dahinter gut ist, spielt dann keine Rolle mehr, denn die Pakete Ihrer Spieler kommen schon vorher nicht durch.

Die zweite Größe ist die Paketrate, und sie schlägt oft früher zu als die Bandbreite. Bei kleinen Paketen von 64 Byte passen in eine Leitung mit 1 Gbit/s rund 1,49 Millionen Pakete je Sekunde. Ein normaler Serverkernel verarbeitet je nach Prozessor und Netzwerkkarte einige hunderttausend davon, bevor er anfängt zu verwerfen. Ein Angriff, der Ihre Leitung nicht einmal zu einem Drittel füllt, kann Ihren Server also trotzdem lahmlegen, weil die Rechenzeit für das Verwerfen draufgeht. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem war alles weg", und bei Palworld äußert es sich zuerst als Lagspitzen und erst danach als Verbindungsabbruch.

Bei einem Palworld-Server kommt ein ungünstiges Verhältnis dazu. Ein voll besetzter Server mit 32 Spielern lastet nur einen Bruchteil einer Leitung mit 1 Gbit/s aus. Der Angriff muss also nicht groß sein, um ein Vielfaches des Normalbetriebs zu erreichen, und genau deshalb reichen hier schon Angriffe, die auf einer großen Plattform nicht auffallen würden.

Zur Einordnung, welche Größenordnungen real vorkommen: Auf KernelHost-Servern wurden unter anderem ein Angriff mit über 473,4 Gbit/s bei über 41,5 Millionen Paketen je Sekunde auf einen Voice-Server und ein UDP-Flood mit über 112,2 Gbit/s auf einen Gameserver gefiltert. Dafür gibt es keine lokale Einstellung. Volumetrische Angriffe müssen im Netz vor dem Server enden.

Was KernelHost dagegen stellt

Der Dauerschutz, der in jedem Serverpaket enthalten ist

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und dauerhaft aktiv, ohne dass Sie etwas einschalten, bestellen oder konfigurieren müssen:

• Stufe 1: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk. Volumetrische Angriffe werden nah an ihrer Quelle bereinigt, bevor sie das Rechenzentrum erreichen.
• Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster erkannt und verworfen, Paket für Paket.

Zwei Eigenschaften sind entscheidend. Der Schutz läuft permanent und muss nicht erst auf einen Angriff reagieren, es gibt also keine Minuten am Anfang, in denen der Server weg ist. Und es wird kein Nullrouting eingesetzt: Ihre IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Wer die IP-Adresse aus dem Netz nimmt, erreicht für Sie dasselbe Ergebnis wie der Angreifer. Palworld gehört zu den Spielen mit eigenem Schutzprofil, welche weiteren Titel und Protokolle abgedeckt sind, listet Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Palworld-Projekte

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen. Dafür gibt es die Advanced DDoS Protection ab 50,00 EUR im Monat, PrePaid, ohne Mindestlaufzeit und ohne Einrichtungsgebühr. Der Unterschied liegt nicht in mehr Kapazität, sondern in der Kontrolle:

• Dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server im eigenen Netz umgestellt wird. Auf Ihrer Seite ist kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich: Sie legen getrennt fest, was auf 8211 UDP erlaubt ist und was auf 27015 UDP, ohne dafür ein Ticket zu schreiben.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, etwa den Abfrageport vorübergehend härter begrenzen und den Spielport unberührt lassen.
• Schutzprofil passend zum Spiel, für Palworld ebenso wie für eigene Anwendungen auf beliebigen TCP- oder UDP-Ports.

Die Advanced DDoS Protection richtet sich an Server, die bei KernelHost stehen. Wer sein Palworld-Projekt derzeit woanders betreibt und dauerhaft angegriffen wird, verlegt es dafür zu KernelHost, dann greifen beide Stufen ab der Bereitstellung.

Die beiden Stufen im Vergleich

Für die meisten Palworld-Server reicht der inkludierte Dauerschutz zusammen mit einer sauberen Serverkonfiguration. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt.

Häufige Fehler bei Palworld-Servern und ihre Lösung

"Ich habe 27015 gesperrt und jetzt ist der Server aus der Community-Liste verschwunden": Das ist das erwartete Verhalten, denn der Abfrageport trägt den Listeneintrag. Sperren Sie ihn nicht pauschal, sondern begrenzen Sie die verbindungslosen Pakete je Quelladresse wie in Schritt 4. Wenn Sie den Listeneintrag ohnehin nicht brauchen, lassen Sie den Port geschlossen, streichen Sie -publiclobby und geben Sie Ihren Spielern IP-Adresse und Port 8211 für die Direktverbindung.

"Ich habe die IP-Adresse gewechselt und war zwei Stunden später wieder offline": Der Angreifer hat die neue Adresse aus derselben Quelle wie die alte. Bei Palworld ist das fast immer einer von drei Wegen: ein Spieler, der die Adresse ohnehin im Direktverbindungsfeld stehen hat, ein Discord-Bot mit Statusanzeige, der sie neu veröffentlicht, oder ein alter A-Eintrag im DNS, der auf die vorherige Adresse zeigt. Ein Adresswechsel ist Zeitgewinn, keine Lösung.

"Der Server hat Lagspitzen, aber die Leitung ist ruhig": Das ist bei Palworld häufiger Last als Angriff. Der Serverprozess belegt über die Laufzeit hinweg stetig mehr Arbeitsspeicher, weshalb ein geplanter Neustart zum Normalbetrieb gehört und nicht als Notbehelf zu verstehen ist. Prüfen Sie die Serverbildrate über den Metrik-Endpunkt und den Speicherverbrauch des Prozesses. Bleibt sar -n DEV 1 10 dabei unauffällig, war es kein DDoS-Angriff.

"Alle 32 Plätze sind belegt, aber im Spiel ist niemand zu sehen": Das ist Slot-Erschöpfung und trifft die Spiellogik, nicht die Leitung. Setzen Sie ein ServerPassword, sperren Sie die auffälligen Konten über die Ban-Liste und begrenzen Sie die Pakete je Quelladresse auf 8211 UDP.

"Die REST-API war ein paar Tage offen erreichbar": Dann ist Ihr Administrationspasswort kompromittiert, denn HTTP Basic Auth über unverschlüsseltes HTTP überträgt es bei jeder Anfrage in umkehrbarer Form. Ändern Sie AdminPassword, schließen Sie 8212 TCP nach außen und erreichen Sie die Schnittstelle nur noch über eine SSH-Portweiterleitung.

"Meine iptables-Regeln greifen nicht": Drei Ursachen sind häufig. Die Regeln stehen hinter den UFW-Ketten und werden nie erreicht, sie waren nach dem letzten Neustart weg (dann helfen netfilter-persistent save oder ein Eintrag in /etc/ufw/before.rules), oder der Angriff ist volumetrisch und die Regel arbeitet korrekt an einer Leitung, die schon voll ist. Prüfen Sie mit iptables -L INPUT -n -v, ob die Trefferzähler steigen.

"Mein bisheriger Anbieter hat meine IP-Adresse gesperrt": Das ist Nullrouting. Der Anbieter schützt damit sein eigenes Netz, für Sie ist das Ergebnis identisch mit einem erfolgreichen Angriff, meist noch für Stunden danach. Fragen Sie im Zweifel nach, ob gefiltert oder nullgeroutet wird. Die Antwort entscheidet mehr über Ihre Verfügbarkeit als jede Hardwareangabe.

"Im tcpdump sehe ich nichts Auffälliges": Wenn der Verkehr schon im Netz davor gefiltert wird, kommt auf dem Server erwartungsgemäß nichts an. Das ist der Normalfall bei funktionierender Filterung. Umgekehrt gilt: Ist die Leitung gesättigt, erreicht Sie unter Umständen nicht einmal mehr die SSH-Sitzung, mit der Sie messen wollten. Nutzen Sie dann die VNC-Konsole im Kundenbereich, die unabhängig vom Netzwerk des Gastsystems funktioniert.

Kurz zusammengefasst

• Ein Palworld-Server braucht genau einen offenen Port: 8211 UDP. Der Abfrageport 27015 UDP ist nur für den Eintrag in der Community-Serverliste nötig.
• RCON auf 25575 TCP und die REST-API auf 8212 TCP gehören niemals ins offene Netz, denn beide übertragen ihre Zugangsdaten unverschlüsselt. RCON ist von Pocketpair zusätzlich als veraltet gekennzeichnet.
• Weil Spielverkehr und Serverabfrage bei Palworld auf getrennten Ports liegen, lässt sich 27015 UDP hart begrenzen, ohne den laufenden Spielverkehr auf 8211 UDP zu berühren.
• Der dedizierte Server ist auf 32 Plätze begrenzt, deshalb ist Slot-Erschöpfung der billigste Angriff. Ein gesetztes ServerPassword ist dagegen die wirksamste Einzelmaßnahme, denn Palworld hat keine eingebaute Whitelist.
• Lokale Maßnahmen enden an der Leitung: 1 Gbit/s sind 125 Megabyte je Sekunde, und bei 64 Byte großen Paketen passen dort rund 1,49 Millionen Pakete je Sekunde hinein. Alles darüber muss im Netz vor dem Server enden.
• Bei KernelHost ist der zweistufige Dauerschutz in jedem Serverpaket ohne Aufpreis enthalten und ab Bereitstellung aktiv, ohne Nullrouting. Die Advanced DDoS Protection mit dedizierter Schutz-IP und selbst verwaltbaren Regeln je Port beginnt bei 50,00 EUR im Monat.

Läuft Ihr Palworld-Server bereits bei KernelHost, ist die Filterung aktiv, ohne dass Sie etwas tun müssen. Bemerken Sie trotzdem Auffälligkeiten, eröffnen Sie ein Support-Ticket, damit die Filterregeln für Ihre IP-Adresse nachjustiert werden. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfallchat unter +43 650 8209883.