DDoS-Schutz bei Gameservern: Was wirklich hilft, wenn dein Server angegriffen wird

Ein befreundeter Clan verliert knapp ein Rangliste-Match gegen deine CS2- oder Minecraft-Community, und ein paar Stunden später ist dein Server nicht mehr erreichbar. Nicht gehackt, nicht kaputt, einfach überflutet. DDoS-Angriffe auf Gameserver lassen sich heute teilweise über sogenannte Stresser- oder Booter-Dienste gegen vergleichsweise geringe Kosten beauftragen, tiefes technisches Fachwissen ist dafür oft nicht nötig. Für einen Angreifer reicht es dabei unter Umständen, die öffentliche IP-Adresse deines Servers zu kennen. Genau das macht das Thema für jeden relevant, der einen öffentlichen Server betreibt, nicht nur für große Netzwerke.

Was bei einem DDoS-Angriff auf einen Gameserver technisch passiert

DDoS steht für Distributed Denial of Service. Viele Systeme, oft ein gemietetes Botnetz, schicken gleichzeitig Anfragen oder Datenpakete an deinen Server, bis er entweder die Netzwerkbandbreite nicht mehr bewältigt oder unter der schieren Menge an Anfragen in die Knie geht. Wichtig ist die Unterscheidung nach Angriffsebene, weil sie bestimmt, welcher Schutz überhaupt greift:

• Volumetrische Angriffe (Layer 3/4). Hier geht es schlicht um Masse: UDP-Floods, SYN-Floods, oder Reflection-/Amplification-Angriffe. Dabei missbraucht der Angreifer öffentlich erreichbare Dienste (etwa DNS-, NTP- oder Memcached-Server) als Verstärker und fälscht die Absenderadresse seiner Anfrage (IP-Spoofing), sodass die deutlich größeren Antworten nicht bei ihm, sondern bei deinem Server ankommen. Der Server merkt davon oft wenig, weil bereits die Netzwerkanbindung davor verstopft.
• Protokoll-Angriffe. Hierbei nutzt der Angreifer Eigenheiten des Netzwerkstacks aus, etwa halboffene TCP-Verbindungen bei einem SYN-Flood, um Ressourcen der Verbindungstabelle zu erschöpfen.
• Anwendungs- bzw. protokollspezifische Angriffe. Hier nutzt der Angreifer gültige oder zumindest formal plausible Nachrichten des jeweiligen Spielprotokolls. Dazu können zum Beispiel massenhafte Server-Query-Anfragen gehören – beim Source-Engine-Query-Protokoll (CS2, TF2, Rust) etwa A2S_INFO-Anfragen – oder missbräuchlich erzeugte Verbindungs- und Authentifizierungsversuche, bei Minecraft also gehäufte Handshake- oder Login-Pakete. Solche Angriffe sind mit rein generischen Netzwerkfiltern schwerer zu erkennen, weil die einzelnen Pakete nicht zwangsläufig wie offensichtlich ungültiger Traffic aussehen.

Diese dritte Kategorie ist mit ein Grund, warum „DDoS-Schutz" bei einem Gameserver etwas anderes bedeuten kann als bei einer Webseite. Ein einfacher, generischer L3/L4-Filter ist primär auf Bandbreiten- und Paketmuster ausgelegt und kann protokollspezifische Angriffe unter Umständen nicht zuverlässig von legitimem Spielerverkehr unterscheiden. Spezialisierter Gameserver-Schutz setzt dagegen zusätzlich auf Protokoll- und Verhaltensinformationen, dazu gleich mehr.

Was dein Hoster bereits mitbringt, und wo die Grenze liegt

Vorab: Bei den meisten deutschen Hostern ist ein Basis-DDoS-Schutz automatisch dabei, ohne Aufpreis. Zwei Beispiele, die für Gameserver relevant sind:

• Hetzner filtert nach eigenen Angaben permanent den eingehenden Traffic und blockt bekannte Angriffsmuster wie DNS-Reflection, NTP-Reflection oder UDP-Floods, bevor sie den Server überhaupt erreichen. Das läuft automatisch, für alle Cloud- und Dedicated-Server-Kunden, ohne zusätzliche Kosten (Quelle: hetzner.com, Stand August 2026). Seit Anfang 2026 setzt Hetzner dafür zusätzlich auf KI-gestützte Erkennung über Nokia Deepfield Defender, um Angriffsmuster schneller zu erkennen (Quelle: Hetzner-Pressemitteilung, März 2026).
• Netcup bietet für Root-, Managed- und dedizierte Server einen kostenlosen Filter, der laut eigener Aussage bis zu 2 Tbit/s an Angriffsvolumen abfangen kann, betrieben über den Partner Anexia (Anexia DDoS Guard). Der Schutz greift automatisch, sobald ungewöhnlich viel Traffic ankommt, und deckt Angriffe bis einschließlich Layer 4 ab (Quelle: netcup.com, Stand August 2026).

Beide Zahlen (2 Tbit/s bei Netcup, die Filterkapazität bei Hetzner) beziehen sich in erster Linie auf generische Bandbreiten- und Paketmusterfilterung auf Netzwerkebene (L3/L4). Für den klassischen „jemand will mir eins auswischen"-Angriff mit gemietetem Booter-Service reicht das in der Praxis meistens locker.

Wie deutlich der Unterschied zwischen generischem und protokollspezifischem Schutz in der Praxis ist, zeigt OVHcloud besonders klar: Der Hoster unterscheidet auf seiner eigenen Produktseite ausdrücklich zwischen der allgemeinen „DDoS-Schutz-Infrastruktur" (nach eigener Beschreibung vor allem L3/L4, generische Bedrohungen) und einem separaten „Game DDoS-Schutz", der gezielt UDP-basierte Spielprotokolle analysiert und dafür eigene Schutzprofile pro Spiel anbietet, für Minecraft Java etwa ein eigenes Profil speziell für das Minecraft-Query-Protokoll (Quelle: ovhcloud.com/de/security/game-ddos-protection/, Stand August 2026). Das ist eine Anbieterangabe, keine unabhängige Messung, aber sie illustriert gut, dass „DDoS-Schutz inklusive" bei einem Hoster nicht automatisch heißt, dass auch das Spielprotokoll selbst mitanalysiert wird. Bei Hetzner und netcup ist aus den öffentlich verfügbaren Angaben nicht ersichtlich, dass eine vergleichbare, spielspezifische Zusatzebene existiert. Ihr Schutz bewegt sich, soweit beschrieben, auf der generischen Netzwerkebene.

Spezialisierter Schutz auf Protokollebene: Reverse-Proxy-Lösungen

Für Minecraft hat sich ein eigenes kleines Ökosystem an Diensten etabliert, die als Reverse-Proxy vor deinen Server geschaltet werden. TCPShield ist der bekannteste davon: Spieler verbinden sich nicht direkt mit deiner IP, sondern über einen CNAME-Eintrag mit dem TCPShield-Netzwerk, das den Traffic filtert und erst dann an deinen echten Server weiterleitet. Der kostenlose Basis-Tarif umfasst nach Angaben des Anbieters 1,0 TB Traffic im Monat und ist laut TCPShield für kleinere Server mit rund 20 bis 30 gleichzeitigen Spielern gedacht (Quelle: tcpshield.com/plans, Stand August 2026). NeoProtect ist eine europäische Alternative mit ähnlichem Funktionsprinzip.

Ein Punkt, der in Anleitungen regelmäßig unterschätzt wird: Der Schutz ist nur so gut wie die Geheimhaltung deiner echten Server-IP. Wenn ein Angreifer die tatsächliche IP hinter dem Proxy kennt, etwa weil sie mal in einem alten DNS-Eintrag, einem Forenpost oder den Logs eines Drittanbieter-Plugins aufgetaucht ist, kann er den Proxy komplett umgehen und direkt angreifen. Deshalb gehört zur Einrichtung zwingend dazu, den Spielport auf Firewall-Ebene nur noch für die IP-Bereiche des Proxy-Anbieters freizugeben, alle anderen Verbindungsversuche auf diesem Port zu blocken. Für Panel-/Backend-Kommunikation (Spieler-IPs im Ban-System, GeoIP-Plugins) brauchst du zusätzlich das Proxy-Protocol, damit dein Server statt der Proxy-IP weiterhin die echte Spieler-IP sieht.

Für Spiele außerhalb des Minecraft-Ökosystems läuft der vergleichbare Ansatz meist über einen GRE-Tunnel: Der Traffic wird zunächst zu einem spezialisierten Anti-DDoS-Anbieter geleitet (etwa über OVHcloud, das nach eigenen Angaben das Verkehrsverhalten populärer Spiele wie Counter-Strike, Team Fortress und Minecraft gezielt analysiert, um legitimen von bösartigem Traffic zu unterscheiden, Quelle: ovhcloud.com/de, Stand 2026), gefiltert, und erst dann per Tunnel an deinen eigentlichen Server weitergereicht, der bei einem ganz anderen Hoster stehen kann. Das klingt nach der eleganteren Lösung, hat aber einen relevanten Haken: In Foren wie Web Hosting Talk und LowEndTalk berichten Admins wiederholt von False-Positives, bei denen legitimer Traffic mitgefiltert wird, und von spürbarem Latenz-Zuwachs durch den zusätzlichen Umweg über den Tunnel. Das ist keine belastbare Statistik, aber ein Muster, das sich über Jahre in Erfahrungsberichten zieht, und deshalb erwähnenswert.

Hier der zentrale Trade-off: Jeder zusätzliche Hop zwischen Spieler und Server kostet Ping. Für ein rundenbasiertes Aufbauspiel ist das egal. Für ein wettkampforientiertes CS2- oder Valorant-artiges Setup mit einer Spielerschaft, die auf Millisekunden reagiert, kann ein GRE-Tunnel über einen weit entfernten Scrubbing-Standort spürbar werden. Bevor du dich für eine dieser Lösungen entscheidest, lohnt sich ein Blick darauf, wie kritisch niedrige Latenz für dein Spiel tatsächlich ist, und ob der Standort des Filterknotens überhaupt in der Nähe deiner Spielerbasis liegt.

Was du selbst auf dem Server konfigurierst

Neben dem Schutz durch Hoster und vorgeschaltete Dienste lässt sich auf dem Server selbst einiges tun, das zwar keinen großen volumetrischen Angriff aufhält, aber die Angriffsfläche reduziert und kleinere Wellen abfängt. Das BSI empfiehlt in seiner Sofortmaßnahmen-Publikation zu akuten DDoS-Angriffen unter anderem, TCP-SYN-Cookies zu aktivieren (Quelle: BSI / Allianz für Cyber-Sicherheit, BSI-CS 002). SYN-Cookies verhindern, dass ein SYN-Flood den TCP-Verbindungsaufbau bzw. die Backlog-Struktur des Servers durch eine große Zahl halboffener Verbindungen überlastet: der Server muss den Verbindungszustand dafür nicht mehr vollständig vorhalten, bevor der Handshake abgeschlossen ist. Auf vielen aktuellen Linux-Distributionen ist dieser Wert im Kernel bereits standardmäßig aktiviert, ein pauschales „das musst du erst einschalten" stimmt also nicht in jedem Fall. Zum Prüfen und, falls nötig, Setzen:

# Prüfen, ob SYN-Cookies bereits aktiv sind (1 = aktiv)
sysctl net.ipv4.tcp_syncookies

# Falls nicht (Wert 0), temporär aktivieren:
sudo sysctl -w net.ipv4.tcp_syncookies=1

# Dauerhaft aktivieren:
echo "net.ipv4.tcp_syncookies = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Zusätzlich lässt sich mit iptables die Anzahl neuer Verbindungen pro Zeiteinheit auf dem Spielport begrenzen, um Verbindungsfluten abzufangen, ein Ansatz, den auch das Hetzner-Community-Tutorial zum Thema beschreibt (Quelle: community.hetzner.com). Wichtig vorweg: Die konkrete Rate ist kein allgemeingültiger Wert, sondern muss an Spiel, Servergröße und erwartete gleichzeitige Spielerzahl angepasst werden. 60 neue Verbindungen pro Sekunde können für einen kleinen Server großzügig oder für einen belebten Server viel zu eng sein. Das folgende Beispiel nutzt den Standard-Minecraft-Port 25565 nur zur Veranschaulichung, für dein Setup den passenden Port eintragen:

# Beispiel: neue Verbindungen auf Port 25565/TCP drosseln
sudo iptables -A INPUT -p tcp --dport 25565 -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 25565 -m conntrack --ctstate NEW -j DROP

Auf Distributionen, die bereits auf nftables umgestellt haben, läuft iptables in der Regel nur noch als Kompatibilitätsschicht darüber. Die Regeln funktionieren trotzdem, aber wer ohnehin neu aufsetzt, kann das gleich nativ in nftables abbilden. Die inhaltlich gleiche Regel sieht dort etwa so aus, vorausgesetzt Tabelle filter und Chain input in der Familie inet existieren bereits:

# nftables: Drosselung neuer TCP-Verbindungen auf Port 25565
sudo nft add rule inet filter input tcp dport 25565 ct state new limit rate 60/second burst 20 packets accept
sudo nft add rule inet filter input tcp dport 25565 ct state new drop

Auch hier gilt dieselbe Einschränkung wie bei iptables: Die Rate ist kein Allgemeinwert, sondern an dein Setup anzupassen, und die Regel greift erst, wenn die Pakete den Server überhaupt erreichen.

Wer die grundlegende Härtung noch nicht gemacht hat (SSH-Key statt Passwort, Firewall, Fail2ban), sollte ohnehin zuerst dort ansetzen, das ist in der Server-Hardening-Checkliste im Detail beschrieben. Falls dir noch nicht klar ist, warum das überhaupt notwendig ist: Ein ungehärteter Server wird in der Regel zuerst automatisiert nach anderen Schwachstellen abgesucht, nicht per DDoS angegriffen. Dazu mehr in Warum ein ungesicherter Server früher oder später drankommt.

Lohnt sich der Aufwand überhaupt für deinen Server?

Nicht jeder Server braucht einen vorgeschalteten Proxy oder GRE-Tunnel. Ein privater Vanilla-Minecraft-Server für sechs Freunde ist selten ein attraktives Ziel, und der kostenlose Basis-Schutz des Hosters reicht dafür in aller Regel. Anders sieht es aus, sobald dein Server öffentlich beworben wird, eine Rangliste oder ein Wettkampfmodus mit rivalisierenden Gruppen existiert, oder du bereits mal angegriffen wurdest. Dann ist die Frage nicht mehr ob, sondern wann der nächste Versuch kommt.

Die Abwägung ist am Ende immer dieselbe: mehr Schutzebenen bedeuten mehr Komplexität, potenziell mehr Latenz und bei manchen Anbietern auch laufende Kosten, sobald du über kostenlose Kontingente hinauskommst. Der kostenlose Basis-Schutz eines generischen Hosters deckt volumetrische Angriffe auf Netzwerkebene gut ab, kann protokollspezifische Angriffe auf dein Spiel aber unter Umständen nicht zuverlässig von normalem Spielerverkehr unterscheiden. Ein Reverse-Proxy wie TCPShield schließt für Minecraft genau diese Lücke, kostet aber IP-Geheimhaltung als Voraussetzung und im Zweifel etwas Ping. Ein GRE-Tunnel zu einem spezialisierten Scrubbing-Anbieter oder ein Hoster mit eingebautem, spielprotokollspezifischem Schutz wie OVHclouds Game-DDoS-Angebot ist die breitere Lösung über verschiedene Spiele hinweg, bringt bei reinen Tunnel-Lösungen aber laut Erfahrungsberichten ein höheres Risiko für Latenz-Ärger und Fehlkonfiguration mit.

Wenn es bereits akut ist

Solltest du gerade mitten in einem Angriff stecken: Aktiviere, falls noch nicht geschehen, den Proxy- oder Tunnel-Schutz deines Hosters oder eines Drittanbieters, kontaktiere parallel den Support deines Hosters. Bei einem laufenden volumetrischen Angriff kann der oft mehr auf Netzwerkebene eingreifen als du selbst vom Server aus. Größere DDoS-Angriffe kannst du zudem dem BSI melden, das aus solchen Meldungen ein Lagebild der aktuellen Bedrohungslage in Deutschland erstellt (Quelle: BSI, Allianz für Cyber-Sicherheit, BSI-CS 002).

Wer sich noch nicht sicher ist, welcher Hoster für die eigene Situation überhaupt die passende Basis mitbringt, findet eine Einordnung im Hetzner, Netcup, Contabo & Co.? Server-Hoster im Vergleich. DDoS-Schutz ist dort ein Faktor unter mehreren, aber eben nicht der einzige.