DayZ-Server vor DDoS-Angriffen schützen

Ein DayZ-Server, der abends mitten im Spiel alle Spieler auswirft und danach für Minuten aus dem Serverbrowser verschwindet, hat selten ein Hardwareproblem. Meistens läuft ein Angriff, und zwar genau dann, wenn die meisten Spieler online sind oder der geplante Neustart ansteht. Wer seinen DayZ-Server vor DDoS-Angriffen schützen will, braucht deshalb beides: eine saubere Portfreigabe auf dem Server und eine Filterung im Netz davor. Dieser Beitrag zeigt zuerst, was Sie ohne Zusatzkosten selbst absichern können, danach, wo diese Maßnahmen technisch aufhören, und zum Schluss, was dann vor dem Server passieren muss.

Alle Angaben beziehen sich auf einen eigenen DayZ-Dedicated-Server mit serverDZ.cfg, gleich ob er unter Windows Server läuft oder unter Debian und Ubuntu über eine Kompatibilitätsschicht. Ein produktionsreifes natives Linux-Serverprogramm für den Stable-Zweig liefert Bohemia Interactive nicht aus, der experimentelle Linux-Build nimmt ausschließlich experimentelle Clients an. Die Linux-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 serverDZ.cfg und starten Sie den Server nicht neu. Ein DayZ-Neustart lädt Mods und die zentrale Ökonomie neu und kostet Sie mehrere Minuten, in denen der Server garantiert offline ist. Sichern Sie zuerst die Messwerte (siehe Abschnitt "Protokollieren"), nach dem Angriff sind sie weg.

Warum DayZ-Server so oft Ziel von DDoS-Angriffen sind

DayZ vereint mehrere Eigenschaften, die einen Server zu einem bequemen Ziel machen. Erstens veröffentlicht ein Community-Server seine Adresse von sich aus: Damit er im Serverbrowser des Spiels und im DZSA-Launcher auftaucht, muss er auf Steam-Abfragen antworten, und diese Antwort enthält IP-Adresse und Port im Klartext. Ein Angreifer muss also nichts herausfinden, er muss nur eine Liste lesen.

Zweitens ist der Tagesablauf eines DayZ-Servers öffentlich. Praktisch alle Projekte starten alle drei bis vier Stunden automatisch neu, kündigen das per Chatnachricht an und schreiben den Plan in den Discord. Ein Angriff, der genau in dieses Zeitfenster fällt, wirkt doppelt: Der Server ist ohnehin gerade nicht erreichbar, und die Spieler, die im Wartebereich hängen, gehen woanders hin.

Drittens ist der Einsatz für die Spieler hoch. Ein Ausfall zur falschen Minute bedeutet in DayZ nicht nur Frust, sondern verlorene Ausrüstung, abgebrochene Raids und eine Basis, die ungeschützt in der Welt steht. Genau deshalb sind gebannte Spieler, verfeindete Gruppen und konkurrierende Projekte die häufigsten Auftraggeber. Ein Angriff über einen der üblichen Booter-Dienste kostet den Auslöser weder Können noch nennenswertes Geld.

Viertens läuft der gesamte DayZ-Verkehr über UDP. UDP kennt keinen Verbindungsaufbau, den man verlangen könnte, und die Absenderadresse lässt sich fälschen. Ein Angreifer muss Ihren Server also weder betreten noch korrekt ansprechen, um Last zu erzeugen. Dass selbst der Hersteller davon betroffen ist, zeigte der Februar 2025: Die Onlinedienste von Bohemia Interactive für DayZ und Arma Reforger lagen über eine Woche unter DDoS-Beschuss, am 3. Februar 2025 bestätigt und am 6. Februar 2025 noch immer nicht beendet, und Community-Server waren mit betroffen. Was ein DDoS-Angriff im Detail ist, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Die Ports eines DayZ-Servers: Fakten-Tabelle

Ein DayZ-Server spricht ausschließlich UDP. Es gibt keinen TCP-Spielport. Der einzige Wert, der bei DayZ wirklich feststeht, ist 2302/UDP als Spielport, alles andere ist konfigurierbar und unterscheidet sich je nach Hoster. Sehen Sie deshalb in Ihrer eigenen Startzeile und Ihrer eigenen serverDZ.cfg nach, statt sich auf einen Standardwert zu verlassen.

Zwei Werte stiften regelmäßig Verwirrung, deshalb hier die Auflösung. Der Steam-Query-Port: Die von Bohemia mitgelieferte Beispielkonfiguration setzt steamQueryPort = 2305;, während ein großer Teil der Hoster 27016/UDP verwendet. Beide Werte sind gültig, entscheidend ist allein der Wert in Ihrer Datei. Der BattlEye-RCon-Port: Hier gibt es überhaupt keinen verbindlichen Standard. Die verbreitete Faustregel ist Spielport plus drei, also 2305, andere Hoster setzen 2310. Seit DayZ 1.13 wertet BattlEye den Parameter RConPort in der BEServer_x64.cfg zuverlässig aus, vorher war der Port schwer vorhersagbar.

Daraus folgt eine Falle, die viele Betreiber trifft: Setzen Sie steamQueryPort und RConPort niemals auf denselben Wert. Wenn Ihre Konfiguration 2305 für die Steam-Abfrage vorsieht, gehört RCon auf einen anderen Port, zum Beispiel 2310.

Warum der Steam-Query-Port der empfindlichste Port ist

Der Steam-Query-Port beantwortet die drei Abfragen A2S_INFO, A2S_PLAYERS und A2S_RULES. A2S_INFO liefert Servername, Karte, Spielerzahl und Version, A2S_PLAYERS die Namen der verbundenen Spieler, A2S_RULES die gesetzten Servervariablen. Jede dieser Antworten ist deutlich größer als die Anfrage, die sie ausgelöst hat, und genau das macht den Port doppelt gefährlich.

Für Sie als Ziel bedeutet es: Ein Angreifer kann Ihren Query-Port mit wenigen Byte pro Anfrage beschäftigen, während Ihr Server jedes Mal eine vollständige Antwort zusammenbaut und versendet. Für Dritte bedeutet es: Ein Angreifer kann Ihren Server mit gefälschter Absenderadresse abfragen und die Antworten auf sein eigentliches Ziel lenken. Ihr Server ist dann nicht nur Opfer, sondern Verstärker. Valve hat A2S_INFO im Dezember 2020 deshalb um eine Challenge-Abfrage ergänzt: Der Server antwortet zuerst mit einer Zufallszahl, die der Anfragende zurückschicken muss. Das entschärft die Verstärkung, beendet sie aber nicht, weil längst nicht jede Abfrage diesen Weg geht.

DayZ hat hier eine Besonderheit, die andere Spiele nicht haben: Es fragen zwei getrennte Serverlisten bei Ihnen an, der eingebaute Community-Serverbrowser und der weit verbreitete DZSA-Launcher. Den Query-Port einfach zu schließen ist deshalb keine Option, denn dann ist Ihr Projekt in beiden Listen verschwunden, obwohl die Direktverbindung weiter funktioniert. Begrenzen statt schließen ist die richtige Antwort.

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

Dieser Abschnitt ist der längste, und das mit Absicht. Ein sauber konfigurierter DayZ-Server hält kleine und mittlere Angriffe aus eigener Kraft aus, unabhängig davon, bei wem er steht.

1. Bestandsaufnahme: welche Ports Ihr DayZ-Server wirklich öffnet

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

ss -lnup
ss -lntup

Unter Windows Server liefert die Eingabeaufforderung dasselbe Bild:

netstat -ano -p UDP | findstr "2302 2303 2304 2305 27016"

Interessant ist die Spalte mit der lokalen Adresse. 0.0.0.0:2302 bedeutet "aus dem ganzen Internet erreichbar", 127.0.0.1:2310 bedeutet "nur lokal" und braucht keine Freigabe. Danach lesen Sie die tatsächlichen Werte direkt aus Ihren Konfigurationsdateien, statt sich auf eine Anleitung zu verlassen:

grep -iE "steamQueryPort|maxPlayers|password|enableWhitelist|verifySignatures" serverDZ.cfg
grep -iE "RConPort|RestrictRCon" battleye/BEServer_x64.cfg

Die Sicht des Angreifers liefert ein UDP-Portscan von außen, ausgeführt von einem anderen Rechner:

nmap -Pn -sU -p 2302-2310,27015-27020 IHRE.SERVER.IP.ADRESSE

2. Nur freigeben, was Startzeile und serverDZ.cfg wirklich brauchen

Für DayZ reichen zwei Freigaben nach außen: der Spielportblock und der Query-Port. Alles andere wird auf Ihre eigene Adresse 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 2302:2305/udp comment 'DayZ Spielport'
ufw allow 27016/udp comment 'DayZ Steam Query'
ufw allow from 203.0.113.10 to any port 2310 proto udp comment 'BattlEye 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 und 27016 durch den Wert, der wirklich in Ihrer steamQueryPort-Zeile steht. Die vollständige Anleitung samt Rettungsweg finden Sie unter UFW-Firewall einrichten, ohne sich selbst auszusperren. Auf einem Windows-Server gilt dasselbe Prinzip: eine eingehende Regel je Portgruppe, Remotedesktop auf die eigene Adresse begrenzt, alles Übrige blockiert.

3. Den Steam-Query-Port begrenzen, statt ihn zu schließen

Eine Obergrenze je Quelladresse trennt echte Serverlisten von Abfrage-Floods. Ein Serverbrowser fragt Sie im Sekundentakt an, ein Angreifer im Millisekundentakt:

iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name dayz_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name dayz_game --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

Die erste Regel verwirft Steam-Abfragen ab dauerhaft mehr als zehn pro Sekunde aus derselben Quelle, die zweite Spielpakete ab mehr als 600 pro Sekunde. Beide Zahlen sind Startwerte, keine Wahrheiten. Ein voller Server mit 60 Spielern erzeugt deutlich mehr Pakete als ein leerer, und wer zu eng einstellt, wirft eigene Spieler heraus oder fliegt aus der Serverliste. Messen Sie erst eine Woche im Normalbetrieb.

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

Unter UFW gehören solche Regeln in /etc/ufw/before.rules, weil sie sonst beim nächsten ufw reload verschwinden. Zusätzlich kennt die Steam-Serverbibliothek eine eigene Bremse für verbindungslose Pakete: Die Umgebungsvariable STEAM_GAMESERVER_RATE_LIMIT_200MS verwirft alle A2S-Pakete einer Adresse, sobald in einem Fenster von 200 Millisekunden mehr als der gesetzte Wert eintrifft.

Der dritte Punkt kostet gar nichts: Wenn Ihr Discord-Bot oder Ihre Projektseite den Spielerstand anzeigt, fragen Sie den Server nicht vom Besucher aus ab, sondern speichern Sie das Ergebnis in festen Abständen zwischen. Damit erzeugt eine viel besuchte Statusseite eine Abfrage pro Intervall statt einer pro Besucher.

4. BattlEye-RCon aus dem offenen Netz nehmen

BattlEye ist die Anti-Cheat-Komponente von DayZ und wird in der serverDZ.cfg mit BattlEye = 1; eingeschaltet. Die Fernverwaltung liegt dagegen in einer eigenen Datei, der BEServer_x64.cfg im BattlEye-Verzeichnis neben BEServer_x64.dll, das die Startzeile mit -BEpath= setzt:

RConPassword EinLangesZufallspasswort
RConPort 2310
RestrictRCon 0

Drei Regeln dazu. Erstens: Der RCon-Port ist UDP, nicht TCP. Eine Firewall-Regel, die versehentlich proto tcp sagt, filtert nichts und lässt gleichzeitig die Verwaltungswerkzeuge ins Leere laufen. Zweitens: Beschränken Sie den Port auf die Adressen Ihrer Administratoren. Wer keine feste Adresse hat, lässt den Port von außen komplett zu und startet das Verwaltungswerkzeug direkt auf dem Server, erreichbar über SSH oder Remotedesktop. Drittens: RestrictRCon 1 begrenzt die per RCon ausführbaren Befehle und ist die richtige Einstellung, sobald mehr als eine Person Zugang hat.

Ein offener RCon-Port ist zwei Dinge auf einmal: eine Einladung zum Durchprobieren von Passwörtern und ein weiterer UDP-Port, den man fluten kann. Beides fällt weg, sobald die Freigabe nur noch für eine Handvoll Adressen gilt.

5. Login-Warteschlange, Whitelist und Slot-Erschöpfung

DayZ arbeitet Verbindungen nicht alle gleichzeitig ab, sondern über eine Warteschlange. Fünf Werte in der serverDZ.cfg steuern sie:

maxPlayers = 60;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 100;
guaranteedSlots = 10;
maxPing = 200;

loginQueueConcurrentPlayers legt fest, wie viele Spieler gleichzeitig eingeladen werden (Voreinstellung 5), loginQueueMaxPlayers begrenzt die Warteschlange selbst (übliche Werte zwischen 100 und 500). Genau hier setzt die Slot-Erschöpfung an: Ein Angreifer braucht keine Bandbreite, er braucht nur genügend Konten oder Verbindungsversuche, um die Warteschlange zu belegen. Echte Spieler kommen dann nicht mehr durch, obwohl der Server technisch einwandfrei läuft. guaranteedSlots reserviert Plätze für Ihr Team, damit Sie in genau dieser Lage noch selbst auf den Server kommen.

Dagegen hilft die eingebaute Whitelist. Sie wird mit enableWhitelist = 1; aktiviert und liest anschließend die Datei profiles/whitelist.txt, eine Steam64-ID je Zeile. Jede nicht gelistete ID wird bei der Verbindung abgewiesen. Die Datei wird beim Serverstart eingelesen, Änderungen brauchen also einen Neustart. Ein zusätzliches password in der serverDZ.cfg wirkt ähnlich, ist aber schwächer, weil ein Passwort weitergegeben wird und eine Steam64-ID nicht.

Eines muss dabei klar sein: Eine Whitelist schützt Ihre Spielerplätze, nicht Ihre Leitung. Ein Angreifer, der Ihren Server flutet, will gar nicht beitreten. Seine Pakete werden abgewiesen, sind aber trotzdem angekommen, und genau das ist der Punkt.

6. Mods, Signaturprüfung und das Zeitfenster nach dem Neustart

Mods sind bei DayZ nicht nur ein Komfortthema, sie sind ein Teil der Angriffsfläche. Vier Einstellungen in der serverDZ.cfg gehören auf jeden Fall gesetzt:

verifySignatures = 2;
forceSameBuild = 1;
allowFilePatching = 0;
BattlEye = 1;

verifySignatures = 2 prüft jede PBO-Datei gegen die zugehörige .bisign-Signatur und braucht dafür die passenden .bikey-Dateien im Ordner keys. forceSameBuild = 1 verlangt exakt dieselbe Spielversion wie auf dem Server. allowFilePatching = 0 weist Clients ab, die mit veränderten Spieldateien starten. Keine dieser Einstellungen stoppt einen volumetrischen Angriff, aber alle drei schließen den Weg, auf dem ein manipulierter Client Ihren Server aus dem Tritt bringt.

Der zweite Punkt ist der wichtigere und wird fast immer übersehen: die Startphase. Ein DayZ-Server lädt beim Start zuerst seine Modliste aus der Startzeile und danach die zentrale Ökonomie mit allen Loot-Tabellen. Bei einem stark modifizierten Server sind das leicht mehrere Minuten, in denen der Server auf keine einzige Steam-Abfrage antwortet:

./DayZServer -config=serverDZ.cfg -port=2302 -profiles=./profiles -BEpath=./battleye -mod=@CF;@IhrMod;@NochEinMod -cpuCount=4 -dologs -adminlog -netlog -freezecheck

Weil praktisch jedes Projekt alle drei bis vier Stunden neu startet und diesen Plan auch noch ankündigt, ist das Zeitfenster für einen Angreifer trivial zu treffen. Drei Gegenmaßnahmen sind wirksam und kosten nichts. Halten Sie die Modliste so kurz wie möglich, jeder zusätzliche Mod verlängert genau dieses Fenster. Legen Sie die Neustartzeiten auf krumme Werte statt auf die volle Stunde. Und messen Sie einmal nach, wie lange Ihr Start wirklich dauert, statt zu schätzen: Mit timeStampFormat = "Full"; und einem gesetzten logFile steht die Dauer anschließend im Protokoll.

7. Verbindungsverfolgung, Empfangspuffer und Kernel-Parameter

Ein oft übersehener Engpass ist die Verbindungsverfolgung des Kernels. UDP kennt zwar keine Verbindungen, der Kernel legt trotzdem für jedes Paar aus Quell- und Zieladresse einen Eintrag an. Läuft die Tabelle 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

Für einen reinen Gameserver ist die saubere Lösung, den Spielverkehr gar nicht erst verfolgen zu lassen, und zusätzlich Empfangspuffer und Warteschlange der Netzwerkkarte zu vergrößern:

iptables -t raw -A PREROUTING -p udp --dport 2302 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 2302 -j NOTRACK
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=1048576
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.netfilter.nf_conntrack_max=524288

Achtung: NOTRACK und zustandsbehaftete Regeln schließen einander aus. Wer den Spielport von der Verfolgung ausnimmt, darf für diesen Port keine Regel mit -m conntrack --ctstate mehr verwenden, sonst greift die Freigabe nicht mehr. Dauerhaft gehören die sysctl-Werte nach /etc/sysctl.d/, sonst sind sie nach dem nächsten Neustart weg.

8. Ihre IP-Adresse steht im Serverbrowser

Hier lohnt sich Ehrlichkeit statt Wunschdenken: Die IP-Adresse eines öffentlichen DayZ-Servers lässt sich nicht geheim halten. Jeder Spieler, der einmal verbunden war, kennt sie, der Serverbrowser veröffentlicht sie, und der DZSA-Launcher speichert sie zwischen. Ein Adresswechsel verschafft Ihnen Stunden, selten Tage.

Wirksamer sind zwei Gewohnheiten. Veröffentlichen Sie die rohe IP-Adresse nirgends zusätzlich, also nicht im angehefteten Discord-Beitrag und nicht auf der Projektseite. Und räumen Sie Ihre DNS-Einträge auf: Ein vergessener A-Eintrag auf die vorherige Adresse macht jeden Wechsel wirkungslos, und genau daran scheitern die meisten Wechsel. Wer auf dem alten Server noch einen Statusdienst laufen lässt, verrät die neue Adresse gleich mit.

9. Protokollieren, damit Sie im Angriff nicht raten müssen

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 pro Sekunde viel waren oder einfach Samstagabend. Auf der Serverseite schalten Sie dafür die eingebauten Protokolle ein:

timeStampFormat = "Short";
logAverageFps = 300;
logPlayers = 300;
logFile = "server_console.log";

logAverageFps ist dabei der ehrlichste Wert, den DayZ liefert. Bricht die Server-Bildrate ein, während die Spielerzahl gleich bleibt, ist das ein Mod- oder Ökonomieproblem. Bleibt die Bildrate stabil, während Spieler herausfliegen, liegt es am Netz. Auf der Systemseite laufen die Messungen mit apt-get install -y vnstat sysstat dauerhaft mit, und 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 udp port 2302 -c 200 -q

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 der Eigenschutz aufhört: 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.

Die Paketrate schlägt bei DayZ oft früher zu als die Bandbreite, und das hat einen einfachen Grund: Der Spielverkehr besteht aus vielen kleinen UDP-Paketen, nicht aus wenigen großen. Ein Angriff, der Ihre Leitung nicht einmal zu einem Drittel füllt, kann Ihren Server deshalb trotzdem lahmlegen, weil die Rechenzeit für das Verwerfen draufgeht. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem hatten alle Lag-Spikes und flogen der Reihe nach raus".

Volumetrische Angriffe müssen im Netz vor dem Server enden. Das ist keine Produktaussage, sondern Physik.

DayZ-DDoS-Schutz: was KernelHost dagegen stellt

Der Dauerschutz, der auf jedem Server läuft

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 und ohne Mindestlaufzeit. 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 stellen getrennt ein, was auf 2302/UDP erlaubt ist, was auf dem Query-Port und was auf dem RCon-Port. Genau diese Trennung ist bei DayZ der Hebel, weil Spielverkehr und Abfrageverkehr völlig verschieden aussehen.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, statt auf ein Ticket zu warten.
• Schutzprofil passend zum Spiel, auch für stark modifizierte Server und eigene Anwendungen auf beliebigen TCP- oder UDP-Ports.

Die beiden Stufen im Vergleich

Für die meisten DayZ-Projekte reicht der inkludierte Dauerschutz zusammen mit einer sauberen Serverkonfiguration. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt. Wer seinen DayZ-Server derzeit woanders betreibt, kann den Schutz nicht nachrüsten: Er ist Teil des Netzes und gilt für Server, die bei KernelHost stehen. Der Weg dahin ist ein Umzug, kein Zusatzprodukt.

Häufige Fehler und Lösungen

"Mein Server ist aus dem DZSA-Launcher und dem Serverbrowser verschwunden, per Direktverbindung komme ich aber drauf": Das ist in den meisten Fällen kein Angriff, sondern der Query-Port. Entweder steht in steamQueryPort ein anderer Wert als in der Firewall, oder eine zu enge Ratenbegrenzung verwirft die Abfragen der Serverliste. Prüfen Sie beide Werte gegeneinander, bevor Sie einen Angriff vermuten.

"RCon verbindet nicht mehr, seit ich die Ports gefiltert habe": BattlEye-RCon läuft über UDP. Eine Freigabe mit proto tcp auf denselben Port bewirkt nichts. Prüfen Sie außerdem, ob RConPort und steamQueryPort versehentlich auf demselben Wert stehen.

"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 Serverbrowser, einem Discord-Statusbot oder einem alten DNS-Eintrag. Ein Adresswechsel ist Zeitgewinn, keine Lösung.

"Der Angriff kommt jeden Tag exakt zum Neustart": Das ist kein Zufall. Der Neustartplan steht im Discord und wird im Spiel angekündigt, und während Mods und Ökonomie laden, antwortet der Server ohnehin nicht. Kürzere Modliste, krumme Neustartzeiten und eine Filterung, die permanent läuft statt erst auf einen Angriff zu reagieren, nehmen diesem Muster die Wirkung.

"Alle Spieler haben Lag-Spikes, das Netz ist aber ruhig": Dann war es kein DDoS-Angriff. Sehen Sie zuerst in logAverageFps nach, ob die Server-Bildrate eingebrochen ist, und danach in die zentrale Ökonomie und die Modliste. Bleibt sar -n DEV 1 10 unauffällig, liegt es nicht am Netz.

"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. Bleiben sie bei null, wird die Regel nicht erreicht.

"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 DayZ-Server braucht nach außen genau zwei Dinge: den Spielportblock ab 2302/UDP und den Steam-Query-Port aus Ihrer steamQueryPort-Zeile. Alles andere gehört eingeschränkt oder geschlossen.
• Der BattlEye-RCon-Port hat keinen verbindlichen Standard, läuft über UDP und wird in der BEServer_x64.cfg mit RConPort gesetzt. Er gehört niemals ins offene Netz und niemals auf denselben Wert wie der Query-Port.
• Den Query-Port begrenzen statt schließen: Wer ihn zumacht, verschwindet aus dem Serverbrowser und aus dem DZSA-Launcher, obwohl die Direktverbindung weiter funktioniert.
• Whitelist, guaranteedSlots und die Login-Warteschlange schützen Ihre Spielerplätze gegen Slot-Erschöpfung, aber nicht Ihre Leitung gegen Bandbreite.
• Das gefährlichste Zeitfenster eines DayZ-Servers ist der geplante Neustart alle drei bis vier Stunden, weil Mods und zentrale Ökonomie minutenlang laden und der Zeitpunkt öffentlich bekannt ist.
• Ab etwa 1 Gbit/s Angriffsvolumen oder einigen hunderttausend Paketen pro Sekunde entscheidet ausschließlich das Netz vor dem Server, nicht mehr Ihre Firewall.
• Bei KernelHost ist der zweistufige Dauerschutz in jedem Serverpaket enthalten, ohne Aufpreis und ohne Nullrouting. Die Advanced DDoS Protection ab 50,00 € im Monat kommt dann dazu, wenn Sie die Regeln je Port selbst steuern wollen.

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