Hytale-Server vor DDoS-Angriffen schützen

Ein Hytale-Server, der abends mitten im Spiel alle Verbindungen gleichzeitig verliert, für ein paar Minuten nicht erreichbar ist und danach von selbst wieder läuft, hat selten ein Hardwareproblem. In aller Regel läuft ein Angriff. Dieser Beitrag zeigt, wie Sie einen Hytale-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 Hypixel Studios, also auf HytaleServer.jar zusammen mit Assets.zip unter Java 25, betrieben auf 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. Hytale ist im Early Access und bewegt sich schnell: Deshalb trägt in diesem Beitrag jede Aussage über das Spiel ein Datum, und alles, was nicht offiziell belegt ist, ist ausdrücklich als Erwartung oder als Community-Quelle gekennzeichnet. Wenn der Angriff gerade läuft, gilt außerdem eine Reihenfolge: erst messen, dann ändern. Ein harter Neustart unter Last verwirft alles, was seit dem letzten Speicherpunkt in der Welt passiert ist, und die Messwerte des Vorfalls sind danach ebenfalls weg.

Warum Hytale-Server gezielt mit DDoS-Angriffen lahmgelegt werden

Ein Hytale-Server ist ein Publikum an einer festen Adresse, und dieses Publikum ist ersetzbar. Wer abends dreimal hintereinander nicht auf seinen Stammserver kommt, sucht sich einen anderen. Genau das ist das Geschäftsmodell hinter Angriffen auf Community-Server: Es geht nicht um Daten und nicht um Erpressung, sondern um Spieler, die weiterziehen. Ein Booter-Dienst, der eine Adresse für ein paar Euro im Monat beschießt, verlangt vom Auftraggeber weder Können noch Aufwand, und der Schaden entsteht bei jedem Ausfall neu.

Dazu kommt bei Hytale eine Besonderheit: Der Servercode ist öffentlich. Hypixel Studios hat im Juni 2026 das Programm Hytale Shared Source angekündigt und stellt darüber den vollständigen Servercode, das Netzwerkprotokoll und die Assets über GitHub bereit, zugänglich für jeden mit gültiger Spiellizenz. Für Serverbetreiber ist das ein Gewinn, weil Plugins gegen echte Schnittstellen entstehen. Für die Angriffsseite bedeutet es, dass das Protokoll niemand mehr erraten muss. Wer wissen will, an welcher Stelle der Verbindungsaufbau Rechenzeit kostet, kann es nachlesen. Was bei einem solchen Angriff technisch passiert, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Der Stand zu Hytale am 27. September 2026

Hytale ist seit dem 13. Januar 2026 im Early Access, erhältlich für Windows, macOS und Linux, und hat in den Tagen nach dem Start über eine Million Spieler erreicht. Der Weg dahin war ungewöhnlich, und er erklärt, warum ältere Artikel über Hytale oft nicht mehr stimmen.

Die praktische Folge dieser Chronologie: Ein Hytale-Server von heute ist kein Server von Januar. Mit Update 6 hat sich das Netzwerkprotokoll von hytale/2 auf hytale/3 geändert, und laut den offiziellen Patch Notes vom 27. August 2026 müssen Server und Plugins neu gebaut werden, bevor sie sich verbinden. Wer seine Verfügbarkeit plant, plant deshalb nicht nur gegen Angriffe, sondern auch gegen Protokollwechsel.

Warum der 12. Oktober 2026 der kritische Termin ist

Große Inhaltsupdates wirken wie ein zweiter Verkaufsstart. Sie bringen alte Spieler zurück, ziehen neue an, und für ein paar Tage entscheidet die Erreichbarkeit darüber, welcher Community-Server aus dieser Welle wächst und welcher sie verpasst. Dieses Muster ist bei anderen Spielen belegt: Palworld erreichte im Januar 2024 innerhalb weniger Tage Millionen Spieler, und die Community-Server dieser Startphase waren genau in dem Moment am meisten angegriffen, in dem sie am meisten zu verlieren hatten. Die Mechanik dahinter ist bei Palworld-Servern vor DDoS-Angriffen schützen ausführlich beschrieben und lässt sich eins zu eins auf Hytale übertragen.

Daraus folgt eine unbequeme Wahrheit über den Zeitplan: Schutz, der am 12. Oktober bestellt wird, ist zu spät. Eine Leitung, eine Schutz-IP, ein Regelwerk je Port und ein Messwert für den Normalbetrieb brauchen Vorlauf, weil sie ohne Vergleichsdaten nicht sinnvoll eingestellt werden können. Wer zwei Wochen vor einem großen Update anfängt, hat genug Zeit. Wer am Tag des Updates anfängt, justiert im Blindflug.

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

Ein Hytale-Server braucht genau einen offenen Port: 5520 UDP. Der Spielverkehr läuft über QUIC, also über UDP, und TCP wird für den Spielverkehr nicht benötigt. Wer nur TCP freigibt, sieht dasselbe Bild wie bei einer geschlossenen Firewall: Die Spieler laufen in eine Zeitüberschreitung. Die Standardbindung lautet 0.0.0.0:5520, ein anderer Port wird beim Start mit --bind gesetzt.

Diese Tabelle ist kürzer als bei den meisten anderen Spielen, und das ist der wichtigste Unterschied. Ein Counter-Strike-Server beantwortet Statusabfragen im Steam-Format A2S, ein Minecraft-Bedrock-Server antwortet auf einen Unconnected Ping, ein Palworld-Server hält einen eigenen Abfrageport offen. Für Hytale ist in der öffentlichen Dokumentation neben 5520 UDP kein weiterer Port beschrieben: kein Abfrageport, kein RCON-Port, keine REST-Schnittstelle im Auslieferungszustand. Alles, was ein Hytale-Server nach außen anbietet, liegt auf einem einzigen UDP-Port.

Hytale-Server in Zahlen

Die folgenden Werte sind die Grundlage für jede Entscheidung über Filterregeln und Grenzwerte. Die Herkunft steht jeweils dabei, weil sie über die Belastbarkeit entscheidet.

Was QUIC an der Angriffsfläche verändert

QUIC ist ein Transportprotokoll, das gesicherte Verbindungen über UDP herstellt und den Verschlüsselungsaufbau nach TLS 1.3 fest eingebaut hat. Es gibt kein unverschlüsseltes QUIC. Für einen Serverbetreiber bedeutet das zwei Dinge, die sich widersprechen, und beide sind wichtig.

Das Erste ist eine echte Verbesserung. Weil UDP keinen Verbindungsaufbau erzwingt und Absenderadressen gefälscht werden können, sind verbindungslose UDP-Dienste die klassischen Verstärker für Angriffe auf Dritte. QUIC begrenzt das im Standard. RFC 9000 schreibt in Abschnitt 8.1 vor, dass ein Server vor der Prüfung der Absenderadresse höchstens die dreifache Menge der empfangenen Byte senden darf, und Abschnitt 14.1 verlangt, dass ein Client sein erstes Datagramm auf mindestens 1200 Byte auffüllt. Zusammen heben diese beiden Regeln den Verstärkungsfaktor eines QUIC-Dienstes auf maximal drei, während ein Steam-Abfrageport oder ein Bedrock-Unconnected-Ping auf ein Vielfaches davon kommt. Ein korrekt arbeitender Hytale-Server ist deshalb als Reflexionsverstärker praktisch uninteressant. Das ist ein struktureller Vorteil gegenüber fast allen anderen Spielen mit UDP-Verkehr, und beim Vergleich mit Minecraft-Bedrock-Servern fällt er deutlich auf.

Das Zweite ist der Preis dafür. Ein QUIC-Verbindungsaufbau kostet den Server Rechenzeit, denn er umfasst eine TLS-1.3-Aushandlung mit asymmetrischer Kryptografie. Ein einzelnes gefälschtes Paket kann keinen Aufbau erzwingen, aber eine Flut echter Verbindungsversuche aus einem Botnetz kann. Der Angreifer zahlt dabei ebenfalls Rechenzeit, und genau dieses Verhältnis entscheidet: Solange der Server pro Verbindungsversuch mehr Arbeit leistet als der Angreifer, ist der Angriff wirtschaftlich. Eine Flut von Verbindungsversuchen belastet deshalb nicht die Leitung, sondern den Prozessor, und sie sieht in der Bandbreitenstatistik nach nichts aus. Das ist derselbe Mechanismus, der bei Minecraft als Nullping und Handshake-Flut bekannt ist und im Beitrag Minecraft-DDoS-Schutz und Nullping-Schutz im Detail beschrieben wird.

Praktisch verwertbar ist daran vor allem die 1200-Byte-Regel. Ein neuer Verbindungsversuch muss als Datagramm von mindestens 1200 Byte ankommen, sonst ist er nach dem Standard kein gültiger Verbindungsaufbau. Laufender Spielverkehr besteht dagegen überwiegend aus kleinen Paketen. Diese Unterscheidung lässt sich in eine Filterregel gießen, und dazu kommen wir gleich.

Was zu Hytale nicht öffentlich dokumentiert ist

Diese Liste gehört in einen ehrlichen Artikel, weil sie festlegt, wo Sie sich nicht auf Zahlen verlassen dürfen. Alles Folgende ist Stand 27. September 2026 nicht offiziell belegt:

• Ob der Server QUIC-Retry zur Adressprüfung einsetzt. RFC 9000 erlaubt in Abschnitt 8.1.2 ein Retry-Paket mit Token, mit dem ein Server die Absenderadresse prüft, bevor er Ressourcen bindet. Ob und ab welcher Last Hytale das tut, ist nicht dokumentiert. Nehmen Sie an, dass Sie sich darauf nicht verlassen können.
• Die Vorgabewerte der Blöcke RateLimit und ConnectionTimeouts in config.json. Dass beide Blöcke existieren, ist über mehrere Quellen konsistent. Die genannten Zahlen widersprechen sich jedoch: Eine Quelle nennt konkrete Grenzwerte, eine andere beschreibt die Blöcke als vorhanden, aber ohne Wirkung. Deshalb steht in diesem Beitrag keine dieser Zahlen, und deshalb sollten Sie diese Blöcke nicht als Ihre Verteidigung einplanen.
• Die Namen und Vorgaben der Authentifizierungsmodi. Die Community-Dokumentation zum veröffentlichten Servercode beschreibt drei Modi, gesetzt über --auth-mode, mit authenticated als Vorgabe sowie offline und insecure für private Umgebungen und Entwicklung. Offiziell bestätigt ist das nicht. Die daraus abgeleitete Regel ist trotzdem eindeutig: Ändern Sie den Modus für einen öffentlichen Server nicht.
• Einzelheiten des TLS-Aufbaus. Die Community-Protokolldokumentation, die auf dem veröffentlichten Servercode beruht, beschreibt ein beidseitiges Zertifikat, ein beim Start erzeugtes selbst ausgestelltes Serverzertifikat, dessen SHA-256-Fingerabdruck über den Sitzungsdienst an die Clients gelangt, sowie ein abgeschaltetes 0-RTT. Das ist plausibel und passt zu TLS 1.3, ist aber nicht offiziell bestätigt, und es ändert nichts an den Maßnahmen weiter unten.
• Angriffsgrößen speziell gegen Hytale-Server. Es gibt dazu keine öffentlichen Zahlen. Die in der Tabelle genannten 5 bis 50 Gbit/s sind ein Erfahrungswert über Gameserver-Projekte hinweg und ausdrücklich keine Hytale-Statistik.
• Paketraten im Normalbetrieb je Spieler. Auch dafür gibt es keine belastbare Veröffentlichung. Deshalb steht in diesem Beitrag kein Grenzwert, den Sie ungeprüft übernehmen könnten, sondern eine Anleitung, wie Sie ihn selbst messen.

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, Fluten von Verbindungsversuchen aus wenigen Quellen, Übernahmeversuche über zusätzlich installierte Verwaltungsoberflächen und die Belegung aller Plätze durch Fremde. Das ist der Großteil dessen, was einen Hytale-Server im Alltag stört, und es kostet eine gute 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:5520 bedeutet "aus dem ganzen Internet erreichbar", 127.0.0.1:8080 bedeutet "nur lokal" und braucht keine Freigabe. Neben dem Java-Prozess des Servers tauchen auf einer gewachsenen Maschine oft 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 5520 IHRE.SERVER.IP.ADRESSE
nmap -Pn -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

Der zweite Aufruf ist der wichtigere. Er zeigt, was sonst noch offen steht, und in der Praxis ist das fast immer mehr als erwartet.

2. Nur 5520 UDP offen lassen, alles andere schließen

Zwei Freigaben reichen. 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 5520/udp comment 'Hytale QUIC'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Eine TCP-Freigabe auf 5520 brauchen Sie nicht. Wenn Sie den Server auf einem abweichenden Port betreiben, muss die Freigabe zum Wert aus --bind passen, sonst läuft der Start durch und die Spieler kommen trotzdem nicht an. Die vollständige Anleitung samt Rettungsweg steht in UFW-Firewall einrichten, ohne sich selbst auszusperren.

Für alles, was Sie zur Verwaltung zusätzlich installiert haben, gilt dieselbe Regel wie bei jedem anderen Spiel: nicht ins offene Netz, sondern über eine SSH-Portweiterleitung erreichbar machen und danach lokal gegen 127.0.0.1 arbeiten:

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

3. Den Server starten, wie er gedacht ist

Der Start besteht aus einem einzigen Befehl. Die Serverdateien beziehen Sie über den offiziellen Hytale-Downloader oder aus Ihrer eigenen Spielinstallation:

java -Xms2G -Xmx4G -jar HytaleServer.jar --assets Assets.zip --bind 0.0.0.0:5520

Beim ersten Start legt der Server config.json, das Verzeichnis logs/ und das Weltverzeichnis universe/ an. Danach melden Sie ihn einmalig an seinem Konto an, damit die Authentifizierung der Spieler funktioniert. Das läuft über einen Gerätecode in der Serverkonsole:

/auth login device
/auth status

Setzen Sie -Xmx nicht auf den gesamten Arbeitsspeicher der Maschine. Das Betriebssystem, der Dateisystemcache und der Java-Laufzeitaufwand außerhalb des Heaps brauchen ebenfalls Platz, und ein Server, der unter Last in den Auslagerungsspeicher läuft, sieht für Ihre Spieler genau wie ein Angriff aus.

4. Whitelist, Serverpasswort und Spielerobergrenze gegen Slot-Erschöpfung

Slot-Erschöpfung ist der billigste Angriff auf einen Community-Server und braucht keine Bandbreite. Wer genügend gleichzeitige Verbindungen aufbaut, belegt alle Plätze und sperrt damit die eigentliche Gemeinschaft aus, ohne ein einziges Gigabit zu kaufen. Hytale hat dafür im Gegensatz zu manch anderem Spiel die passenden Werkzeuge im Auslieferungszustand: eine Whitelist in whitelist.json, eine Sperrliste in bans.json, Rechte in permissions.json und in config.json die Schlüssel Password und MaxPlayers.

{
  "ServerName": "Mein Hytale-Server",
  "MOTD": "",
  "Password": "ein Wert, den nur Ihre Gruppe kennt",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password ist ab Werk leer, jeder mit Adresse und Port kommt also hinein. Für einen geschlossenen Server ist ein gesetztes Passwort die wirksamste Einzelmaßnahme gegen Slot-Erschöpfung, für einen öffentlichen Server ist es die Whitelist während einer Angriffswelle. 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.

Bearbeiten Sie diese Dateien nur bei gestopptem Server. Der laufende Serverprozess hält seinen eigenen Stand im Speicher und kann Änderungen, die Sie währenddessen in die Datei schreiben, beim Herunterfahren kommentarlos überschreiben. Für Änderungen im laufenden Betrieb nutzen Sie die Konsolenbefehle statt des Editors.

5. Die Authentifizierung auf dem Standardwert lassen

Der Standardmodus verlangt von jedem Spieler ein gültiges Hytale-Konto. Das ist mehr als eine Lizenzprüfung: Es ist ein Zugangsfilter, der Massenkonten teuer macht. Ein Angreifer, der Plätze belegen will, braucht dafür gültige Konten, und die kosten Geld. Nehmen Sie diesen Filter nicht heraus.

Die Community-Dokumentation beschreibt neben dem Standard zwei weitere Modi für private Umgebungen und für Entwicklung, mit denen ohne Kontoprüfung beigetreten werden kann. Für einen öffentlichen Server sind sie die schlechteste erreichbare Einstellung, weil sie die Slot-Erschöpfung von einer Geldfrage zu einer Skriptfrage machen. Wenn Sie zum Testen umschalten, dann auf einer Maschine, die nicht im Internet steht, und Sie schalten danach zurück.

6. Neue Verbindungsversuche begrenzen, und zwar mit der 1200-Byte-Regel

Jetzt wird der strukturelle Vorteil von QUIC praktisch. Ein gültiger Verbindungsaufbau kommt nach RFC 9000 als Datagramm von mindestens 1200 Byte an. Laufender Spielverkehr ist deutlich kleiner. Mit Verbindungsverfolgung können Sie deshalb neue Datenströme von bestehenden unterscheiden und alles verwerfen, was neu und zu klein ist. Mit nftables, geladen über nft -f:

table inet hytale {
    chain input {
        type filter hook input priority -10; policy accept;

        ct state new udp dport 5520 udp length < 1208 drop

        ct state new udp dport 5520 \
            meter hyconn { ip saddr limit rate over 5/second burst 10 packets } drop
    }
}

Die erste Regel arbeitet auf der UDP-Länge, also 8 Byte Kopf plus 1200 Byte Nutzlast, zusammen 1208. Sie trifft ausschließlich Pakete, die einen neuen Datenstrom eröffnen wollen und dafür zu klein sind, und sie kann verbundene Spieler nicht treffen. Die zweite Regel begrenzt, wie viele neue Verbindungen eine einzelne Quelladresse je Sekunde eröffnen darf. Fünf je Sekunde sind großzügig: Ein echter Spieler baut eine Verbindung auf und behält sie. Die Priorität -10 sorgt dafür, dass beide Regeln vor der Filterkette von UFW greifen.

Eine Obergrenze für die Paketrate je Quelladresse auf dem Spielport selbst ist die dritte sinnvolle Regel, und hier gilt ausdrücklich: Der Zahlenwert ist ein Startwert, keine Wahrheit.

iptables -I INPUT -p udp --dport 5520 \
  -m hashlimit --hashlimit-name hytale_udp --hashlimit-mode srcip \
  --hashlimit-above 800/sec --hashlimit-burst 1200 -j DROP

Messen Sie erst eine Woche im Normalbetrieb, dann setzen Sie die Grenze auf das Doppelte des gemessenen Spitzenwerts. Für Hytale gibt es dafür keine veröffentlichte Referenzzahl, und die Werte hängen stark von Spielerzahl und Sichtweite ab. Wer zu eng einstellt, wirft die eigenen Spieler heraus, und zwar zuerst die mit der schlechtesten Leitung.

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.

7. Die Verbindungsverfolgung des Kernels richtig einstellen

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

Bei den meisten Spielen ist die beste Antwort darauf, den Spielverkehr gar nicht verfolgen zu lassen. Bei Hytale ist das eine echte Abwägung, denn die 1200-Byte-Regel aus Schritt 6 braucht die Verbindungsverfolgung. Ohne sie weiß der Filter nicht, welches Paket einen neuen Datenstrom eröffnet. Die Empfehlung lautet deshalb: Verfolgung behalten, Tabelle vergrößern, Zeitüberschreitung für UDP kurz halten. Ein Aufschlag unter /etc/sysctl.d/, aktiviert mit sysctl --system:

net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Wer die Verfolgung trotzdem abschalten will, etwa auf einer Maschine mit sehr vielen gleichzeitigen Spielern, setzt udp dport 5520 notrack in der raw-Tabelle und verzichtet damit auf die 1200-Byte-Regel. Beides zusammen geht nicht. Für einen einzelnen Hytale-Server ist die Regel mehr wert als die gesparten Tabelleneinträge.

Kommen Pakete schneller an, als der Java-Prozess sie abholt, läuft zusätzlich der Empfangspuffer über. Für die Spieler sieht das wie Paketverlust aus, obwohl die Leitung frei ist. Ob die Puffereinstellungen oben 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. Sichtweite und Spielerzahl zur Leitung passend wählen

Dieser Schritt ist keine Sicherheitsmaßnahme, er entscheidet aber darüber, wie viel Angriff Sie überhaupt vertragen. Hypixel Studios hat es in den offiziellen Hardware-Anforderungen vom 1. Dezember 2025 klar formuliert: Wenn Sie die Sichtweite verdoppeln, vervierfachen Sie die Menge Welt um den Spieler. Die offizielle Empfehlung liegt bei höchstens 12 Chunks, also 384 Blöcken, gesetzt über MaxViewRadius. Auf der Clientseite nennen dieselben Anforderungen 2 Mbit/s als Minimum und 8 Mbit/s als Empfehlung je Spieler für das Mehrspielerspiel.

Rechnen Sie das für Ihren Server einmal durch. Ein Server mit 40 Spielern bei großzügiger Sichtweite bewegt im Normalbetrieb einen niedrigen dreistelligen Megabit-Bereich. Das ist der Wert, an dem sich Ihre Leitung messen muss, und es ist gleichzeitig der Wert, den ein Angriff überschreiten muss, um aufzufallen. Wer eine Leitung mit 1 Gbit/s zu einem Drittel im Normalbetrieb füllt, hat weniger Reserve als jemand, der bei fünf Prozent liegt. Eine kleinere Sichtweite ist deshalb nicht nur eine Leistungsfrage, sondern auch eine Frage der Robustheit.

9. Mods, Plugins und Protokollwechsel im Blick behalten

Hytale ist serverseitig moddbar: Mods liegen als .zip oder .jar im Verzeichnis mods/, und Plugins sprechen die Server-Schnittstelle direkt an. Das ist bequem, weil Spieler nichts installieren müssen, und es ist zugleich ein Verfügbarkeitsrisiko, das nichts mit Angriffen zu tun hat. Ein Plugin, das pro Netzwerkereignis teuer arbeitet, ist ein Verstärker in Ihrem eigenen Haus.

Dazu kommt der Protokollwechsel. Mit Update 6 hat sich das Netzwerkprotokoll laut den offiziellen Patch Notes vom 27. August 2026 von hytale/2 auf hytale/3 geändert, und Server und Plugins müssen neu gebaut werden, bevor sie sich verbinden. Für die Verfügbarkeit heißt das: Führen Sie eine Liste Ihrer Mods samt Version, prüfen Sie sie vor jedem Update auf einer zweiten Instanz, und planen Sie vor dem 12. Oktober 2026 ein Wartungsfenster ein. Ein Server, der nach einem Update nicht startet, ist für Ihre Spieler von einem Angriff nicht zu unterscheiden.

10. 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 conntrack läuft die Messung dauerhaft mit. Während eines Vorfalls genügen fünf Befehle:

sar -n DEV 1 10
ip -s link show eth0
conntrack -C
nstat -az | grep -i -E 'udp|drop'
tcpdump -ni eth0 -c 200 "udp port 5520"

Bei tcpdump gilt: immer mit -c begrenzen, ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Weil der Hytale-Server auf Java läuft, brauchen Sie eine zweite Probe, die den häufigsten Fehlalarm ausschließt. Eine Pause der Speicherbereinigung sieht für Spieler genauso aus wie ein Angriff: Alle stehen gleichzeitig, danach läuft es weiter. Der Unterschied steht in den Zahlen.

jcmd $(pgrep -f HytaleServer.jar) GC.heap_info
tail -n 200 logs/latest.log

Die Auswertung ist einfach. Steigen die Eingangspakete weit über den Normalwert, während der Java-Prozess kaum arbeitet, ist es ein Angriff. Bleibt die Paketrate unauffällig, während der Heap voll läuft oder das Protokoll lange Pausen zeigt, ist es Last. Wie Sie die Netzwerkwerte im Einzelnen auswerten, steht in DDoS-Angriff am Server erkennen.

11. Backup, Rückfallplan und ein Probelauf vor dem großen Termin

Ein Schutzkonzept, das nie getestet wurde, ist eine Vermutung. Vor einem Termin wie dem 12. Oktober 2026 gehören vier Dinge erledigt: ein Backup des Verzeichnisses universe/ samt config.json, das außerhalb der Maschine liegt, eine geprüfte Rückkehr zur vorherigen Serverversion, eine zweite Instanz, auf der Sie das Update zuerst einspielen, und ein einmaliger Lasttest, der Ihre eigenen Filterregeln auslöst.

Der Lasttest ist der Punkt, an dem die meisten Betreiber aufhören, und er ist der wichtigste. Prüfen Sie nicht, ob Ihre Regeln Angriffe abwehren, sondern ob sie Ihre eigenen Spieler durchlassen. Dafür genügt es, die Trefferzähler zu beobachten, während zwanzig echte Spieler gleichzeitig beitreten. Steigen die Zähler der Verwurfsregeln dabei an, ist Ihre Grenze zu eng gesetzt, und Sie hätten es am Tag des Updates unter den schlechtesten Bedingungen erfahren.

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

Bei Hytale kommt eine dritte Größe hinzu, die es bei den meisten Spielen nicht gibt: die Rechenzeit für den Verbindungsaufbau. Eine Flut gültiger Verbindungsversuche aus einem Botnetz füllt keine Leitung und erzeugt keine auffällige Paketrate, sie beschäftigt den Prozessor mit Kryptografie. Solche Angriffe sind in der Bandbreitenstatistik unsichtbar und in der Prozessorlast des Java-Prozesses deutlich, und weder eine Ratenbegrenzung je Quelladresse noch ein größerer Empfangspuffer hilft dagegen, wenn die Quellen zahlreich genug sind.

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 gegen DDoS-Angriffe auf Hytale-Server 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. Welche Titel und Protokolle mit eigenen Schutzprofilen abgedeckt sind, listet Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Hytale-Projekte

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen, und bei einem Spiel im Early Access trifft das besonders die Server, die gerade wachsen. 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.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich: Sie legen fest, was auf 5520 UDP erlaubt ist, getrennt von allem anderen, und brauchen dafür kein Ticket.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, etwa neue Verbindungen kurzzeitig härter begrenzen und den laufenden Spielverkehr unberührt lassen.
• Regelwerk passend zum Protokoll, für QUIC über UDP 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 Hytale-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 Hytale-Server reicht der inkludierte Dauerschutz zusammen mit einer sauberen Serverkonfiguration. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt.

Was sich aus anderen Spielen auf Hytale übertragen lässt

Weil Hytale noch jung ist und es zu Angriffen auf Hytale-Server keine öffentlichen Zahlen gibt, ist der schnellste Weg zu belastbarem Wissen der Blick auf vergleichbare Spiele. Übertragbar ist dabei nicht die Portnummer, sondern das Muster.

• Der explosive Start und was er auslöst: Palworld zeigt, wie sich eine Welle neuer Spieler und eine Welle von Angriffen zeitlich überlagern und warum gerade wachsende Server Ziel werden.
• Der Unterschied zwischen Abfrage und Spielverkehr: Minecraft Bedrock erklärt am Unconnected Ping, wie Verstärkung über UDP funktioniert. Genau diesen Angriffsweg hat Hytale durch QUIC nicht, und daran lässt sich der Unterschied am besten verstehen.
• Verbindungsaufbau als Angriffsziel: Minecraft-DDoS-Schutz und Nullping-Schutz beschreibt Handshake-Fluten, die mit fast keiner Bandbreite auskommen. Das ist das nächste Verwandte zur QUIC-Verbindungsflut.
• Kleine Spielerzahlen und Slot-Erschöpfung: Project Zomboid und Conan Exiles zeigen, wie wenig Aufwand nötig ist, um eine feste Gruppe auszusperren, und welche Rolle Whitelist und Passwort dabei spielen.
• Betrieb unter Dauerlast: Terraria zeigt, wie ein einzelner Serverprozess mit Einzelkernlast auf Angriffe reagiert. Der Hytale-Server ist ein Java-Prozess, das Grundproblem ist vergleichbar.

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

"Ich habe Port 5520 TCP freigegeben und die Spieler kommen trotzdem nicht rein": Der Spielverkehr läuft über QUIC, also über UDP. Eine TCP-Freigabe bringt für den Spielverkehr nichts. Geben Sie 5520 UDP frei und prüfen Sie es von außen mit nmap -Pn -sU -p 5520. Wenn Sie den Server mit --bind auf einen anderen Port gelegt haben, muss die Freigabe diesen Port nennen.

"Der Server läuft, aber niemand kann beitreten, und im Protokoll steht nichts von Angriffen": Prüfen Sie die Anmeldung des Servers an seinem Konto mit /auth status. Ein Server, dessen Anmeldung abgelaufen ist, läuft weiter und weist Spieler dennoch ab. Das ist kein Netzwerkproblem und keine Filterregel.

"Nach dem Update startet nichts mehr": Das ist kein Angriff, sondern der Protokollwechsel. Mit Update 6 hat sich das Netzwerkprotokoll von hytale/2 auf hytale/3 geändert, und Server sowie Plugins brauchen einen neuen Bau. Spielen Sie Updates zuerst auf einer zweiten Instanz ein, bevor Sie sie auf den Produktivserver lassen.

"Alle Spieler stehen gleichzeitig für zwei Sekunden, dann läuft es weiter": Das ist mit hoher Wahrscheinlichkeit die Speicherbereinigung der Java-Laufzeit und kein Angriff. Prüfen Sie jcmd ... GC.heap_info und das Serverprotokoll. Bleibt sar -n DEV 1 10 dabei unauffällig, war kein Angriff im Spiel, sondern zu knapp bemessener Heap oder zu große Sichtweite.

"Meine Regel gegen kleine Pakete hat die Spieler ausgesperrt": Dann steht die 1200-Byte-Bedingung ohne ct state new in der Kette. Laufender Spielverkehr besteht überwiegend aus kleinen Paketen, und eine Längenbedingung ohne Zustandsprüfung trifft genau die. Die Bedingung gilt ausschließlich für neu eröffnete Datenströme.

"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 Hytale sind das meist ein alter A-Eintrag im DNS, ein Discord-Bot mit Statusanzeige oder ein Eintrag in einer der vielen Server-Listen von Drittanbietern. Seit Update 6 sind Serveradressen in der offiziellen Serverliste ab Werk verborgen, was den bequemsten Weg schließt, aber nicht alle. Ein Adresswechsel ist Zeitgewinn, keine Lösung.

"Meine Filterregeln 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 Hytale-Server braucht genau einen offenen Port: 5520 UDP für QUIC. TCP wird für den Spielverkehr nicht benötigt, und in der öffentlichen Dokumentation ist kein weiterer Port für Abfragen, RCON oder Fernsteuerung beschrieben.
• Weil QUIC nach RFC 9000 vor der Adressprüfung höchstens die dreifache empfangene Byte-Menge senden darf und ein erster Verbindungsversuch mindestens 1200 Byte groß sein muss, ist ein Hytale-Server als Reflexionsverstärker praktisch uninteressant. Das unterscheidet ihn von Servern mit Steam-Abfrage oder Bedrock-Unconnected-Ping.
• Dieselbe 1200-Byte-Regel ist die beste lokale Filterregel: Was einen neuen Datenstrom auf 5520 UDP eröffnen will und kleiner ist, kann kein gültiger Verbindungsaufbau sein und lässt sich verwerfen, ohne verbundene Spieler zu treffen.
• Der teure Teil eines QUIC-Aufbaus ist die Kryptografie, nicht die Bandbreite. Eine Flut gültiger Verbindungsversuche ist in der Bandbreitenstatistik unsichtbar und nur in der Prozessorlast und in den Zählern für neue Verbindungen zu sehen.
• Der Standardmodus mit Kontopflicht ist ein Zugangsfilter, der Massenkonten teuer macht. Für einen öffentlichen Server bleibt er unangetastet, dazu kommen whitelist.json, bans.json und ein gesetzter Wert in Password gegen Slot-Erschöpfung.
• 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.
• Hytale ist seit dem 13. Januar 2026 im Early Access, Chapter 1 ist für den 12. Oktober 2026 angekündigt. Große Termine sind Angriffstermine, und Schutz, der am Termin bestellt wird, kommt zu spät.
• 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 € im Monat.

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

Dieser Beitrag hat den Stand vom 27. September 2026. Hytale ist im Early Access, und das Netzwerkprotokoll hat sich in diesem Jahr bereits einmal geändert. Er wird nach Chapter 1 und nach jedem Update fortgeschrieben, das den Verbindungsaufbau, die Ports oder die Serverliste betrifft.