Project-Zomboid-Server vor DDoS-Angriffen schützen

Wer seinen Project-Zomboid-Server vor DDoS-Angriffen schützen will, muss zuerst wissen, worauf ein Angreifer überhaupt schießt. Ein dedizierter Server belegt genau zwei UDP-Ports, 16261 und 16262, und beide müssen offen im Netz stehen, weil sonst niemand beitreten kann. Dieser Beitrag geht in der Reihenfolge vor, die im Ernstfall zählt: zuerst das, was Sie in den nächsten zehn Minuten ohne Zusatzkosten selbst tun können, danach die Stelle, an der diese Maßnahmen technisch aufhören, und zum Schluss das, was davor im Netz passieren muss.

Alle Angaben beziehen sich auf den dedizierten Server (Steam-App 380870) unter Debian 12, Debian 13, Ubuntu 22.04 LTS oder Ubuntu 24.04 LTS, für Build 41 wie für Build 42. Die Konfigurationsdatei heißt servertest.ini und liegt unter ~/Zomboid/Server/, die Weltdaten liegen unter ~/Zomboid/Saves/Multiplayer/. Die Befehle sind für root geschrieben, als normaler Benutzer stellen Sie sudo voran.

Wenn der Angriff gerade läuft: Ändern Sie jetzt nichts an der servertest.ini und starten Sie den Server nicht neu. Sichern Sie zuerst die Messwerte (Abschnitt 9), nach dem Angriff sind sie weg. Ein Neustart kostet zusätzlich die Zeit, die der Server zum Laden der Welt braucht, und genau die will der Angreifer Ihnen abnehmen.

Warum Project-Zomboid-Server zum Ziel von DDoS-Angriffen werden

Project Zomboid ist ein Spiel mit dauerhaftem Tod und einer Welt, die über Monate weiterläuft. Ein Verbindungsabbruch mitten in einer gefährlichen Situation kostet hier mehr als in fast jedem anderen Genre: Der Charakter ist weg, und die Welt erinnert sich daran. Genau das macht einen Ausfall zur Waffe. Ein Angriff um 20 Uhr trifft eine feste Community, und er trifft sie an der Stelle, an der sie am meisten zu verlieren hat.

Dazu kommt, dass der Angriff selbst nichts kostet und kein Können verlangt. Gebuchte Angriffsdienste, im Milieu Booter oder Stresser genannt, richten sich mit wenigen Klicks gegen eine IP-Adresse und einen Port, und bei Project Zomboid ist das Ziel immer dasselbe: 16261 UDP. Wer im Streit mit einem gebannten Spieler liegt oder eine konkurrierende Community betreibt, hat damit ein Werkzeug in der Hand, für das er weder Wissen noch nennenswertes Geld braucht.

Dazu kommt, dass ein Gameserver seine Adresse veröffentlichen muss. Steht Public=true in der servertest.ini, erscheint der Server im Browser des Spiels, und ein Server mit Steam-Anbindung ist ohnehin im Steam-Serverbrowser sichtbar. Die Frage lautet also nie, ob ein Angreifer Ihre IP-Adresse findet, sondern nur, was passiert, wenn er darauf schießt.

Technisch kommt der unangenehmste Teil zum Schluss: Der gesamte Spielverkehr läuft über UDP. UDP kennt keinen Verbindungsaufbau, den man verlangen könnte, jedes Paket steht für sich, und die Absenderadresse lässt sich fälschen. Ein Angreifer muss Ihren Server also weder betreten noch korrekt ansprechen, um Last zu erzeugen. Was ein DDoS-Angriff im Detail ist, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Welche Ports ein Project-Zomboid-Server wirklich braucht

Ein dedizierter Project-Zomboid-Server braucht genau zwei offene Ports: 16261 UDP und 16262 UDP. Die offizielle Portliste des Spiels nennt keinen dritten. In der servertest.ini stehen sie als zwei getrennte Direktiven, der zweite Port ergibt sich nicht automatisch aus dem ersten:

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

Die Aufgabenteilung ist eindeutig. 16261 UDP trägt den Spielverkehr und den Verbindungsaufbau und beantwortet die Abfragen des Serverbrowsers. 16262 UDP ist der Port für die Direktverbindung der Clients. Fehlt der erste, findet niemand den Server, fehlt der zweite, sehen Ihre Spieler den Eintrag und kommen trotzdem nicht herein. Genau daher stammt die bekannteste Fehlermeldung des Spiels, dass Port 16262 geschlossen sei.

Zwei Punkte, die regelmäßig Ärger machen. Erstens: Jede Serverinstanz braucht zwei freie UDP-Ports. Wer eine zweite Welt auf derselben Maschine betreibt, vergibt dafür ein zweites Paar, zum Beispiel 16274 und 16275, und trägt beide Werte in die servertest.ini der zweiten Instanz ein. Zweitens: SteamPort1 und SteamPort2 stehen mit 8766 und 8767 in der Konfigurationsdatei, gehören aber zur Steam-Anbindung und nicht zum Spielverkehr. Öffnen Sie sie nur, wenn Ihr Server ohne sie nicht in der Steam-Liste auftaucht, nicht vorsorglich.

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

Dieser Abschnitt ist der längste, und das mit Absicht. Ein sauber konfigurierter Server hält kleine und mittlere Angriffe aus eigener Kraft aus, unabhängig davon, bei wem er steht. Er nimmt Ihnen keinen volumetrischen Angriff ab, sorgt aber dafür, dass billige Angriffe wirkungslos bleiben und dass Sie im Ernstfall Zahlen haben statt Vermutungen.

1. Bestandsaufnahme: was lauscht wirklich

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:16261 und [::]:16261 bedeuten "aus dem ganzen Internet erreichbar", 127.0.0.1:27015 bedeutet "nur lokal" und braucht keine Freigabe. Gleichen Sie das Ergebnis mit Ihrer Konfiguration ab, statt sich auf Standardwerte zu verlassen:

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

Die Sicht des Angreifers liefert ein Portscan von außen. Weil Project Zomboid ausschließlich UDP verwendet, braucht es dafür den UDP-Scan, ein reiner TCP-Scan zeigt den Spielport gar nicht:

nmap -Pn -sU -p 16261,16262,8766,8767 IHRE.SERVER.IP.ADRESSE
nmap -Pn -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

2. Nur 16261 und 16262 offen lassen

Zwei Freigaben nach außen reichen, alles andere wird eingeschränkt oder gar nicht erst veröffentlicht. 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 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid Direktverbindung"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Ersetzen Sie 203.0.113.10 durch Ihre eigene Adresse. Die Reihenfolge beim Scharfschalten entscheidet darüber, ob Sie sich selbst aussperren. Sie steht samt Rückweg im Beitrag UFW-Firewall einrichten, ohne sich selbst auszusperren. Falls es doch passiert: Bei KVM-Rootservern und Dedicated Servern von KernelHost erreichen Sie das System über die VNC-Konsole im Kundenbereich, die unabhängig vom Netzwerk des Gastsystems arbeitet.

Ein Wort zu Datenbanken und Zusatzdiensten: Project Zomboid braucht keine. Was neben dem Spiel auf 0.0.0.0 lauscht, stammt aus einer früheren Installation oder von einem Verwaltungspanel und gehört entweder auf 127.0.0.1 gebunden oder abgeschaltet.

3. RCON auf Port 27015 aus dem Internet nehmen

RCON ist die Fernsteuerung des Servers und läuft bei Project Zomboid auf 27015 TCP. In der ausgelieferten servertest.ini steht RCONPassword= ohne Wert. Wer RCON benutzt, setzt ein langes Zufallspasswort, denn das Protokoll überträgt unverschlüsselt, und ein erreichbarer RCON-Port mit schwachem Passwort übergibt den Server vollständig, ohne dass dafür ein einziges Paket Angriffsverkehr nötig wäre.

Der sichere Weg ist, den Port gar nicht erst nach außen zu öffnen und ihn über eine Portweiterleitung per SSH zu erreichen. Danach sprechen Sie lokal mit 127.0.0.1:27015:

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

Wer RCON nicht braucht, lässt das Passwortfeld leer und den Port geschlossen. Ein Dienst, der nicht erreichbar ist, kann weder durchprobiert noch geflutet werden.

4. Paketraten je Quelladresse begrenzen

Gegen kleine Angriffe und unsaubere Bots hilft eine Obergrenze je Quelladresse. Weil beide Spielports nebeneinander liegen, genügt eine Regel für den Bereich:

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

Die Regel verwirft UDP-Pakete, sobald dieselbe Quelladresse dauerhaft mehr als 400 Pakete pro Sekunde schickt. Der Wert ist ein Startwert, keine Wahrheit: Ein Server mit 30 Spielern in derselben Stadt erzeugt deutlich mehr Verkehr als einer mit vier Spielern in verschiedenen Ecken der Karte, und wer zu eng einstellt, wirft seine eigenen Spieler heraus. Messen Sie erst eine Woche im Normalbetrieb, dann setzen Sie die Grenze auf ein Mehrfaches des Spitzenwerts.

Zwei Hinweise dazu. Reine iptables-Regeln sind nach einem Neustart weg, unter Debian und Ubuntu sichert man sie so:

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

Und unter UFW gehören solche Regeln in /etc/ufw/before.rules, weil sie sonst beim nächsten ufw reload verschwinden. Prüfen Sie mit den Trefferzählern aus iptables -L INPUT -n -v, ob die Regel überhaupt erreicht wird. Bleiben die Zähler bei null, steht sie an der falschen Stelle.

5. Die Verbindungsverfolgung entlasten

Ein oft übersehener Engpass sitzt im Kernel. Die Verbindungsverfolgung legt auch für UDP einen Eintrag je Quelladresse und Port an, und ein Flood mit gefälschten Absendern füllt diese Tabelle in Sekunden. Läuft sie voll, verwirft der Server auch legitime Pakete, und im Protokoll steht "nf_conntrack: table full". Stand und Obergrenze zeigt:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Der Spielverkehr von Project Zomboid braucht keine Zustandsverfolgung, weil UDP keinen Zustand hat. Sie können die beiden Spielports deshalb aus der Tabelle heraushalten:

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

Das entlastet den Kernel spürbar. Wichtig: Die Regel passt nur, solange der Server die Pakete direkt bekommt. Wer davor eine Adressumsetzung betreibt, etwa in einem Containeraufbau mit Port-Weitergabe, darf sie nicht setzen, weil die Rückrichtung dann nicht mehr zugeordnet wird.

6. Beitritt und Slots absichern

Die nächsten Zeilen kosten nichts und wirken gegen alles, was über den regulären Beitrittsweg kommt:

Password=EIN-LANGES-ZUFALLSPASSWORT
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password ist das gemeinsame Serverpasswort und vom Konto des einzelnen Spielers getrennt. Open=false bedeutet, dass nur Konten beitreten dürfen, die ein Administrator vorher angelegt hat, das ist die Whitelist des Spiels. MaxAccountsPerUser begrenzt, wie viele Konten ein einzelner Steam-Benutzer auf Ihrem Server anlegen darf, die Voreinstellung 0 bedeutet unbegrenzt. MaxPlayers steht ab Werk auf 32, und darüber warnt die Dokumentation ausdrücklich vor schlechtem Nachladen der Karte und Desynchronisation.

PingLimit ist an dieser Stelle die Falle. Die Direktive wirft Spieler ab einer Latenz in Millisekunden hinaus und steht ab Werk auf 0, also aus. Unter einem Angriff steigt die Latenz Ihrer eigenen Spieler zuerst, ein enger Wert kickt also genau die Leute, die Sie halten wollen. Lassen Sie die Grenze aus oder setzen Sie sie großzügig.

Und eines muss klar sein: Eine Whitelist schützt Ihre Spiellogik, nicht Ihre Leitung. Ein Angreifer, der Ihren Server flutet, will gar nicht beitreten. Seine Pakete werden abgelehnt, sind aber trotzdem angekommen, und genau das ist der Punkt.

7. Der Mod-Abgleich beim Verbinden ist die teuerste Sekunde Ihres Servers

Project Zomboid prüft beim Verbinden mehr als ein Passwort. Die Mod-Liste des Servers steht in zwei Zeilen der servertest.ini: WorkshopItems enthält die numerischen Workshop-IDs, Mods die Lade-IDs der Mods, beide mit Semikolon getrennt. Beim Beitritt gleicht der Client diese Liste ab, lädt fehlende Workshop-Inhalte automatisch über Steam nach und bekommt erst danach die Weltdaten gestreamt. Zusätzlich vergleicht der Server bei DoLuaChecksum=true die Prüfsummen der Spieldateien und wirft Clients hinaus, deren Dateien nicht zu seinen passen.

Für einen Angreifer ist genau das interessant, denn die Arbeit fällt vor der eigentlichen Spielteilnahme an. Jeder Verbindungsversuch kostet den Server Rechenzeit für Version, Prüfsumme, Modliste und Kartendaten, auch der Versuch, der am Ende abgelehnt wird. Eine lange Modliste macht jeden dieser Versuche teurer. Ein Beitritts-Flood ist auf einem stark modifizierten Server deshalb wirksamer als auf einem unveränderten, und er braucht dafür einen Bruchteil der Bandbreite eines volumetrischen Angriffs. Das Spiel bringt dagegen zwei eingebaute Bremsen mit:

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer weist neue Anmeldungen ab, solange der Server überlastet ist, statt die laufende Runde mit abzureißen. LoginQueueEnabled stellt Beitretende in eine Warteschlange, statt sie gleichzeitig abzuarbeiten, und LoginQueueConnectTimeout legt fest, wie lange ein Beitritt dauern darf, Voreinstellung 60 Sekunden, erlaubt sind 20 bis 1200.

Ein Detail gehört dazu, weil es häufig falsch gelöst wird: Auf Linux-Servern gibt es einen dokumentierten Fehler, bei dem DoLuaChecksum falschen Alarm schlägt und Spieler nicht hereinlässt. Betreiber schalten die Prüfung deshalb ab. Das ist nachvollziehbar, entfernt aber eine Kontrolle, die Clients mit veränderten Spieldateien fernhält. Wer sie abschalten muss, sollte Serverpasswort, Whitelist und Kontogrenze umso strenger setzen.

8. Serverliste, UPnP und die eigene Adresse

Hier lohnt sich Ehrlichkeit statt Wunschdenken: Ihre IP-Adresse lässt sich nicht geheim halten. Public=true zeigt den Server im Browser des Spiels, und ein Server mit Steam-Anbindung ist laut Dokumentation ohnehin im Steam-Serverbrowser sichtbar. Public=false nimmt Ihnen also die Sichtbarkeit für neue Spieler, ohne Sie unsichtbar zu machen.

Public=true
PublicName=Mein Zomboid-Server
UPnP=false
server_browser_announced_ip=

UPnP steht ab Werk auf true und lässt den Server versuchen, an einem Internet-Gateway selbst eine Portfreigabe einzurichten. Auf einem gemieteten Server gibt es kein solches Gateway, der Versuch geht ins Leere und gehört abgeschaltet. server_browser_announced_ip bleibt leer, außer Ihr Server hat mehrere Adressen und soll gezielt unter einer davon auftauchen. Genau dieses Feld brauchen Sie später wieder, wenn Sie auf eine dedizierte Schutz-IP umstellen.

Zwei Gewohnheiten helfen mehr als jede Einstellung. Veröffentlichen Sie die rohe IP-Adresse nirgends selbst, also weder im Discord-Kanal noch auf der Projektseite, und geben Sie Ihren Spielern einen Hostnamen. Der Klassiker beim Adresswechsel sind alte DNS-Einträge: Ein vergessener A-Eintrag auf die vorherige Adresse macht jeden Wechsel wirkungslos.

9. Messen, solange alles normal läuft

Der wichtigste Schritt ist der, den fast niemand vorher macht: eine Vergleichsbasis anlegen, solange alles ruhig ist. Ohne Normalwert können Sie nach einem Vorfall nicht sagen, ob 40.000 Pakete pro 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
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

Die ersten beiden zeigen Paketrate und Verwurfszähler der Schnittstelle, der dritte eine kurze Stichprobe des Verkehrs, der vierte die Meldungen des Servers, sofern er als systemd-Dienst läuft (Name des Dienstes anpassen). Bei tcpdump gilt: immer mit -c begrenzen, ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Wie Sie die Werte 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 sind 125 Megabyte pro Sekunde, und die Leitung ist voll, sobald jemand mehr schickt. 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 1 Gbit/s rund 1,49 Millionen Pakete pro Sekunde, während ein normaler Serverkernel je nach CPU und Netzwerkkarte nur einige hunderttausend davon verarbeitet, bevor er anfängt zu verwerfen. Ein Angriff, der Ihre Leitung nicht einmal zu einem Drittel füllt, kann Ihren Server also lahmlegen. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem war alles weg".

Übliche Angriffe gegen Gameserver-Communities liegen zwischen 5 und 50 Gbit/s, also beim Fünf- bis Fünfzigfachen einer normalen Leitung. Dafür gibt es keine lokale Einstellung. Volumetrische Angriffe müssen im Netz vor dem Server enden.

Was KernelHost gegen DDoS-Angriffe auf Gameserver stellt

Der Dauerschutz, der auf jedem Server inklusive 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. Welche Spiele und Protokolle abgedeckt sind, listet Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen. Dafür gibt es die Advanced DDoS Protection ab 50,00 € 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, die neue Adresse tragen Sie lediglich dort ein, wo Ihre Spieler den Server finden.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich: Sie legen fest, was auf 16261 und 16262 UDP erlaubt ist, und alles andere bleibt zu, ohne dafür ein Ticket zu schreiben.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren.
• Passendes Schutzprofil. Für gängige Spiele gibt es fertige Profile, für modifizierte und eigene Anwendungen setzen Sie die Regeln je Port und Protokoll selbst. Project Zomboid lässt sich dabei besonders genau eingrenzen, weil der gesamte Spielverkehr über zwei benachbarte UDP-Ports läuft.

Die beiden Stufen im Vergleich

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

Häufige Fehler und Lösungen

"Meine Spieler bekommen die Meldung, Port 16262 sei geschlossen": Das ist kein Angriff, sondern eine fehlende Freigabe. Der Server braucht beide Ports, 16261 UDP und 16262 UDP, und zwar als UDP-Regel. Eine TCP-Freigabe auf denselben Nummern bewirkt nichts. Prüfen Sie mit ufw status verbose und einem UDP-Scan von außen, ob wirklich beide offen sind.

"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, meist dem Listeneintrag, einem Discord-Bot mit Statusanzeige oder einem alten DNS-Eintrag. Bei Project Zomboid kostet der Wechsel zusätzlich: Die Clients legen die Kartendaten lokal unter Adresse und Port ab, in einem Ordner nach dem Muster 123.45.0.12_16261_... unter Zomboid/Saves. Nach einem Wechsel lädt jeder Spieler die erkundete Karte neu vom Server. Ein Adresswechsel ist also Zeitgewinn mit Zusatzkosten, keine Lösung.

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

"Spieler fliegen beim Beitritt raus, der Server läuft aber normal weiter": Das ist fast immer der Abgleich, nicht ein Angriff. Ursachen sind ein Versionsunterschied zwischen Client und Server, ein fehlender oder veralteter Workshop-Eintrag oder eine Prüfsumme, die nicht passt. Der Client nennt in der Regel die Mods, die nicht übereinstimmen. Gleichen Sie WorkshopItems und Mods Zeile für Zeile ab.

"Alle paar Minuten Lag-Spitzen, dann läuft es wieder": Das ist das übliche Muster kurzer Angriffe, die nur so lange laufen, bis die Spieler entnervt aufhören. Sehen Sie zuerst auf die Netzwerkzähler, nicht auf die CPU-Last. Bleiben sar -n DEV 1 10 und die Verwurfszähler unauffällig, war es kein Angriff, sondern Last: zu viele Spieler in derselben Zelle, ein teurer Mod oder zu wenig Arbeitsspeicher für die Java-Instanz.

"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": Wird der Verkehr bereits im Netz davor gefiltert, 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.

Kurz zusammengefasst

• Ein dedizierter Project-Zomboid-Server braucht genau zwei offene Ports: 16261 UDP (DefaultPort) und 16262 UDP (UDPPort). Beide stehen als getrennte Direktiven in der servertest.ini.
• RCON läuft auf 27015 TCP und ist ab Werk ohne Passwort eingetragen. Der Port gehört nicht ins offene Internet, sondern auf die eigene Adresse beschränkt oder geschlossen.
• Der Mod-Abgleich beim Verbinden ist die teuerste Stelle: Version, Prüfsumme, Workshop-Liste und Kartendaten kosten Rechenzeit, auch bei jedem abgelehnten Versuch. DenyLoginOnOverloadedServer und die Beitritts-Warteschlange sind dagegen die eingebauten Bremsen.
• Serverpasswort, Open=false und MaxAccountsPerUser=1 schützen die Spiellogik. Gegen eine gesättigte Leitung wirkt keine dieser Einstellungen.
• Die physikalische Grenze steht fest: 1 Gbit/s sind 125 Megabyte pro Sekunde und bei 64 Byte großen Paketen rund 1,49 Millionen Pakete pro Sekunde. Übliche Angriffe gegen Gameserver liegen bei 5 bis 50 Gbit/s.
• Volumetrische Angriffe müssen im Netz vor dem Server enden. Bei KernelHost sind das 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk und eine Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main, ohne Aufpreis und ohne Nullrouting.
• Wer dauerhaft beschossen wird, steuert die Filterung mit der Advanced DDoS Protection selbst: dedizierte Schutz-IP, Regeln je Port und Protokoll, Änderungen in Echtzeit, ab 50,00 € im Monat.

Läuft Ihr 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.