Schützen Sie Gameserver mit gehärteter Firewall auf Basis von nftables, Reverse Proxy, anbieterseitigem DDoS Schutz und Überwachung.
Setzen Sie auf Defense-in-Depth: eine gehärtete Host-Firewall mit nftables, ein Reverse-Proxy oder Provider-Mitigation gegen volumetrische Angriffe und laufendes Monitoring der Netzwerkwerte. Diese drei Ebenen zusammen bilden die minimale Firewall für Gameserver, die heute Bestand hat. UDP-Spiele wie Rust oder FiveM brauchen dabei andere Rate-Limits als TCP-basierte Server wie Minecraft. Die konkreten Regeln und Testschritte folgen in den nächsten Abschnitten.
Kurz gesagt:
- Eine effektive Verteidigung gegen volumetrische Angriffe erfordert eine Kombination aus Firewall, Reverse-Proxy und Provider-Mitigation, um auch große Angriffe abzuwehren.
- nftables ist für regelbasierte Abwehrmaßnahmen bei Gameservern unerlässlich, da es bei vielen Einträgen konstant arbeitet und schnell auch bei großen Threats reagiert.
- Die Konfiguration sollte vorab einen sicheren Rettungsweg enthalten, um bei Fehlregeln niemals ausgesperrt zu werden, und immer einen Backup-IP-Plan einschließen.
- Bei großen Volumen reichen lokale nftables-Regeln allein nicht aus, es braucht Schutz auf Provider-Ebene durch BGP FlowSpec oder Scrubbing-Center.
- Managed Hosting mit bereits integrierter DDoS-Abwehr ist besonders sinnvoll, wenn der Fokus auf Spielspaß und Community liegt, statt auf Firewall-Wartung.
Eine Firewall auf Layer 3/4 filtert nach IP, Port und Protokoll. Sie hält den groben Datenmüll fern, kann aber nicht erkennen, ob ein UDP-Paket ein echter Spielbefehl ist oder ein manipuliertes Angriffspaket mit gültigem Header. Genau dafür braucht es eine zweite Ebene: Layer-7-Mechanismen prüfen den Inhalt und erkennen spielspezifische Muster, etwa fehlerhafte Query-Anfragen oder Login-Floats.
Für Gameserver hat sich eine Architektur mit Proxy-Frontend und privatem Backend bewährt. Der Reverse-Proxy nimmt den gesamten öffentlichen Verkehr an, die eigentliche Spiel-Engine läuft auf einer IP, die niemand kennt. Verbunden werden beide Seiten über ein Tunnelprotokoll wie WireGuard oder GRE.
Vor- und Nachteile der gängigen Optionen:
Bevor Sie eine einzige Regel schreiben, brauchen Sie einen Rettungsweg. Ohne Out-of-Band-Zugriff über die Server-Konsole riskieren Sie, sich mit einer fehlerhaften Default-Grob-Regel selbst auszusperren. Das ist der häufigste Fehler bei der ersten Firewall-Einrichtung überhaupt.
So gehen Sie strukturiert vor:
Profi-Tipp: Legen Sie sich immer eine zweite, unveröffentlichte IP als Backup zurück. Bei einem laufenden Angriff können Sie so den Betrieb auf die Aus weich-IP verlegen, während die alte Adresse noch im Fokus des Angreifers steht.
nftables hat iptables als Standard weitgehend abgelöst und aus gutem Grund. Es arbeitet mit nativen Sets und Maps, die auch bei tausenden IP-Einträgen mit konstanter Geschwindigkeit arbeiten, während iptables bei langen Regelketten linear langsamer wird. Für eine Whitelist mit hunderten Proxy-Adressen ist das kein nice-von-Dave, sondern notwendig.
Ein einfacher, praxistauglicher Regelsatz für einen Gameserver hinter einem Proxy sieht so aus:
| Regel | Zweck |
|---|---|
ct state established,related accept |
Bestehende Verbindungen ohne erneute Prüfung durchlassen |
ip saddr @proxy_set tcp dport Port_for_Fivem accept |
Nur gelistete Proxy-IPs auf den Spielport lassen |
udp dport Port_for_Fivem limit rate rate_per_second burst burst_packets accept |
UDP-Pakete pro Sekunde begrenzen |
tcp dport Port_for_SSH ct state new limit rate rate_limit accept |
SEE-Flut auf SSH eindämmen |
policy drop |
Alles andere grundsätzlich verwerfen |
Die Rate-Lifting-Syntax von nftables arbeitet mit den Schlüsselwörtern limit, rate, burst und over, mit denen sich Pakete oberhalb eines Schwellwerts gezielt verwerfen lassen. Für Minecraft-Server, die auf TCP laufen, lohnt sich zusätzlich ein SEE-Limit über Conntrack, weil das die klassischen Connection-Floats abfängt. Bei UDP-Spielen wie Rust oder FiveM sind feinere Per-Source-Limits nötig, sonst blockieren Sie am Ende reguläre Spieler mit.
Fail2Ban ergänzt die statischen Regeln, indem es wiederholte Fehlversuche auf Admin-Panels oder COM-Ports automatisch temporär sperrt. Wichtig bei containerisierten Setups: nftables- oder ip6tables-Regeln müssen in die DOCKER-USER-Chain, sonst umgeht Docker Ihre Firewall komplett und leitet Pakete direkt weiter.
policy drop-Änderung zuerst über die Konsole, nie ausschließlich über SSH.Profi-Tipp: Rollen Sie neue Regelsätze nie direkt auf dem Live-Server aus. Ein kurzer Test auf einem zweiten VPS zeigt Fehler, bevor echte Spieler betroffen sind.
Ihre nftables-Regeln laufen im Kernel und sind schnell, aber sie wirken erst, wenn das Paket bereits bei Ihrem Server angekommen ist. Bei einem großen volumetrischen Angriff ist die Leitung selbst das Problem, nicht die CPU. Sobald der Uplink gesättigt ist, helfen lokale Droh-Regeln nicht mehr weiter, weil der Datenmüll die Bandbreite schon vor Ihrem Server verstopft.
Ab diesem Punkt braucht es Mitigation auf Provider-Ebene. Ein Reverse-Proxy-Konzept nach dem Vorbild bekannter Game-Helds filtert den Verkehr, bevor er überhaupt Ihr Rechenzentrum erreicht. Sinnvoll ist eine automatisierte Eskalationskette:
Automatisierte Eskalation zahlt sich aus, weil zwischen Erkennung und manueller Reaktion oft zu viel Zeit verloren geht, gerade nachts oder am Wochenende. Ergänzend nutzen größere Setups GRE-Tunnel zu Scrubbing-Anbietern, mehrere IP-Pools zur Lastverteilung und DNS-Rotation, um bei einem laufenden Angriff schnell auf eine unbelastete Adresse zu wechseln. Für einen Rust-Server mit öffentlicher Community ist diese Eskalationskette oft schon ab dem ersten Monat relevant, nicht erst bei tausenden Spielern.
Eine Firewall ohne Monitoring ist nur die halbe Absicherung. Beobachten Sie mindestens vier Werte kontinuierlich: Pakete pro Sekunde, tatsächliche Bandbreitennutzung, Anzahl offener Conntrack-Einträge und Fehlerraten bei Spielerverbindungen. Ein plötzlicher Sprung bei der PPS-Zahl ohne entsprechenden Spielerzuwachs ist fast immer ein frühes Warnsignal.
So testen Sie eine neue Konfiguration, bevor sie produktiv geht:
Nach jedem Vorfall lohnt sich ein kurzes Post-Mortem: Was hat ausgelöst, welche Regel hat gegriffen, was fehlte. Die BSI-Grundschutzempfehlungen zu Firewalls verlangen genau diese dokumentierte Verantwortlichkeit für jede Regel, und das ist keine reine Bürokratie, sondern der einzige Weg, nach einem Angriff nachvollziehen zu können, was passiert ist.
Nach Jahren mit Gameserver-Setups zeigt sich ein Muster: Die meisten Betreiber überschätzen ihre Host-Firewall und unterschätzen den Uplink. Ein perfekt konfigurierter nftables-Regelsatz nützt wenig, wenn die Leitung vorher verstopft. Viele Community-Admins investieren Stunden in Regel-Feinschliff, während die eigentliche Schwachstelle die fehlende Provider-Mitigation ist.
Einige Hosting-Anbieter bieten DDoS-Schutz und verwaltete Gameserver an, damit Betreiber sich nicht selbst um GRE-Tunnel oder BGP FlowSpec kümmern müssen. Sinnvoll ist Managed Hosting vor allem dann, wenn Sie Zeit lieber ins Spielerlebnis stecken als in Firewall-Wartung um Mitternacht. Wer die volle Kontrolle über eigene Regeln behalten will, findet auf einem VPS genug Spielraum, um beide Welten zu verbinden.
— Erik
Es gibt gute Gründe, jede Firewall-Regel selbst zu schreiben, aber nicht jeder Betreiber hat dafür Zeit oder Nerven. Es gibt Anbieter, die Server mit inkludiertem DDoS-Schutz ohne Mehrkosten bereitstellen, die in deutschen Rechenzentren laufen und sich über übersichtliche Control Panels verwalten lassen, statt jede Regel manuell zu pflegen. Der Support arbeitet oft direkt im Team und nicht in einer anonymen Warteschlange.
Für Minecraft, FiveM oder Garry’s Mod bedeutet das: Sie starten den Server, die grundlegende Absicherung läuft mit, und Sie kümmern sich um Ihre Community statt um Conntrack-Tabellen. Wer stattdessen volle Kontrolle über eigene nftables-Regeln braucht, findet auf einem VPS Standard die passende Basis dafür. Schauen Sie sich die verfügbaren Gameserver-Pakete an und starten Sie in wenigen Minuten mit einem abgesicherten Setup.
Man unterscheidet meist Paketfilter-Firewalls, die nach IP und Port entscheiden, zustandsbehaftete Firewalls, die den Verbindungsstatus verfolgen, und Application-Layer-Firewalls, die den Inhalt eines Pakets prüfen. Für Gameserver ist eine Kombination aus zustandsbehaftetem Host-Filter und Layer-7-Schutz die gängige Praxis, wie auch OVHcloud in seiner Game-Firewall-Dokumentation beschreibt.
Eine zu restriktive Konfiguration kann legitime Spieler blockieren, besonders bei UDP-Spielen mit vielen kurzen Paketen. Zudem schützt eine Host-Firewall allein nicht vor volumetrischen Angriffen, die den Uplink sättigen, wofür dann Provider-Mitigation nötig wird.
Ja, eine Host-Firewall ist die Grundlage jeder Absicherung und lässt sich mit nftables direkt auf dem Server konfigurieren. Sie ersetzt bei größeren Angriffsvolumen jedoch keine Mitigation auf Provider-Ebene.
Sie blockiert typischerweise unbekannte IP-Adressen außerhalb einer Proxy-Whitelist, überhöhte Paketraten pro Sekunde und wiederholte Fehlversuche auf Admin-Ports. Eine gut konfigurierte policy drop-Regel verwirft zudem grundsätzlich jeden Verkehr, der nicht explizit erlaubt wurde.
Bei kleinen Community-Servern reicht oft eine solide Host-Firewall aus. Sobald der Server öffentlich beworben wird oder eine größere Spielerbasis hat, lohnt sich zusätzlicher Schutz, wie ihn etwa Nexthosting bei seinen Gameserver-Paketen bereits inkludiert.