Gameserver unter Beschuss: was hilft und was nur so aussieht

Spielserver werden angegriffen, und zwar aus banalen Gründen: verlorene Runde, Streit in der Community, Erpressungsversuch. Die Werkzeuge dafür sind billig zu mieten, und die IP-Adresse eines öffentlich gelisteten Servers ist kein Geheimnis.

Was einen Spielserver dabei von einer Website unterscheidet, entscheidet über jede sinnvolle Maßnahme.

Warum Web-Schutz hier nicht greift#

	Website	Gameserver
Protokoll	TCP, HTTP, TLS	meist UDP, herstellereigen
Vorschaltung	Reverse-Proxy oder CDN üblich	kein CDN für UDP-Spielprotokolle
Prüfung möglich	Anfrage lesen, entscheiden	Paket ist undurchsichtig, Zeitbudget winzig
Verzögerung	100 ms fallen nicht auf	100 ms sind das Problem
Verbindungsaufbau	Handschlag, Zustand prüfbar	verbindungslos, Absender leicht gefälscht

Daraus folgt die unangenehme Wahrheit: Ein Filter, der genau prüft, ist zu langsam; ein Filter, der schnell ist, prüft grob. Deshalb passiert echte Abwehr oberhalb deines Servers, auf der Leitung, die noch nicht voll ist.

Die drei Angriffsarten, getrennt betrachtet#

1. Die Leitung volllaufen lassen. Viel Datenverkehr aus gefälschten Absendern, oft über Verstärkerdienste. Dagegen hilft auf deinem Server nichts. Wenn die Zuleitung voll ist, sind deine Pakete schon verloren, bevor der Kernel sie sieht. Nur der Anbieter kann filtern.

2. Zustandstabellen füllen. Kein großes Volumen, aber viele einzelne Absender, die Verbindungsverfolgung des Kernels läuft voll, und der Server wirft auch legitime Pakete weg.

3. Das Spiel selbst beschäftigen. Abfragepakete in Serie, Beitrittsversuche im Sekundentakt, absichtlich fehlerhafte Pakete. Kleines Volumen, große Wirkung, weil jedes Paket Rechenzeit in der Weltschleife kostet.

Gegen 2 und 3 kannst du etwas tun. Gegen 1 nur der Anbieter und danach fragst du vor dem Mieten, nicht während des Angriffs.

Was auf dem Server hilft#

Das Spiel aus der Verbindungsverfolgung nehmen#

Ein UDP-Spielport erzeugt für jeden Absender einen Eintrag in der Verbindungstabelle. Bei einem Angriff mit gefälschten Absendern ist die Tabelle in Sekunden voll und dann fällt auch alles andere aus, inklusive deiner SSH-Sitzung.

nft add table inet spiel
nft add chain inet spiel roh '{ type filter hook prerouting priority -300; policy accept; }'
nft add rule inet spiel roh udp dport 2456-2457 notrack

# Gegenprobe: wie voll ist die Tabelle gerade?
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

Der Spielserver braucht die Verfolgung nicht, er verwaltet seine Sitzungen selbst.

Pro Absender begrenzen#

nft add set inet spiel flut '{ type ipv4_addr; flags dynamic,timeout; timeout 10m; }'
nft add chain inet spiel eingang '{ type filter hook input priority -150; policy accept; }'

# Wer die Grenze reißt, landet für zehn Minuten im Set …
nft add rule inet spiel eingang udp dport 2456-2457 \
  add @flut { ip saddr limit rate over 400/second } drop
# … und wird ab dann sofort verworfen
nft add rule inet spiel eingang udp dport 2456-2457 ip saddr @flut drop

Die Zahl 400 ist ein Startwert, keine Empfehlung. Miss zuerst, was ein normaler Spieler erzeugt, und setze die Grenze darüber:

# Pakete pro Sekunde je Absender, während normal gespielt wird
timeout 30 tcpdump -nn -i any udp port 2456 2>/dev/null \
  | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head

Zu eng gesetzt sperrt die Regel echte Spieler aus und das sieht für dich genauso aus wie ein Angriff.

Den Abfrageport getrennt behandeln#

Der Port, über den Serverlisten den Status abfragen, ist der beliebteste Hebel: Er antwortet jedem, mit mehr Daten als die Anfrage groß war. Genau das macht ihn auch als Verstärker für Angriffe auf andere interessant.

# Deutlich strenger begrenzen als den Spielport
nft add rule inet spiel eingang udp dport 27015 limit rate 20/second accept
nft add rule inet spiel eingang udp dport 27015 drop

Wer keine öffentliche Listung braucht, schaltet die Abfrage im Spiel ganz ab. Das ist die wirksamste Maßnahme in diesem Abschnitt.

Trennen, was nicht zusammengehört#

Panel und Spiel nie auf derselben Adresse

Wenn Webpanel, SSH und Spielserver auf einer IP liegen, nimmt ein Angriff auf den Spielserver dir genau den Zugang, mit dem du reagieren wolltest. Getrennte Adresse für die Verwaltung, oder Verwaltung nur über einen Tunnel, dann bleibt sie erreichbar, während vorn gefiltert wird. Wie so ein Tunnel aussieht, steht in FritzBox über WireGuard an einen VPS; das Prinzip ist dasselbe.

Was nur so aussieht wie Schutz#

Den Port ändern. Reduziert Hintergrundrauschen, hält aber niemanden auf, der deinen Server sucht, die Adresse steht in der Serverliste.
Ganze Länder sperren. Trifft Spieler, nicht Angreifer; Angriffe kommen aus übernommenen Geräten überall.
Ein Web-CDN davorstellen. Für UDP-Spielprotokolle funktioniert das nicht. Es gibt kostenpflichtige Weiterleitungsdienste, die genau diese Lücke füllen, das ist ein anderes Produkt als der übliche kostenlose Webschutz.
fail2ban auf die Spielprotokolle. Reagiert erst nach Sekunden bis Minuten. Gegen einen Paketsturm ist das zu spät; gegen Anmeldeversuche im Panel dagegen sinnvoll.

Vorher klären, nicht nachher#

Drei Fragen an den Anbieter, bevor du mietest:

Gibt es Filterung, und ab wann greift sie? „DDoS-Schutz inklusive“ kann alles heißen zwischen ernsthafter Filterung und dem Abschalten deiner IP-Adresse.
Was passiert bei einem Angriff mit meiner IP? Manche Anbieter leiten dich für Stunden ins Nichts (Nullrouting). Das ist für sie günstig und für dich ein Totalausfall.
Bekomme ich eine zweite Adresse für die Verwaltung?

Und im eigenen Haus: Sicherungen liegen woanders (3-2-1), damit ein Vorfall nicht auch die Welt kostet.

Wenn es passiert#

# Läuft gerade etwas? Erst schauen, dann handeln.
nstat -az | grep -iE "udp|drop"
ss -s
tcpdump -nn -c 200 -i any udp port 2456

Nicht sofort neu starten. Ein Neustart hilft nicht und kostet dich die Weltdaten seit dem letzten Speichern.
Aufzeichnen, Uhrzeit, Zielport, Größenordnung. Das braucht der Anbieter.
Anbieter informieren, mit den Zahlen aus Schritt 2.
Nicht zurückschlagen. Gegenangriffe sind strafbar, und Erpressungsforderungen zu bezahlen finanziert den nächsten Angriff.

Häufige Fragen#

Reicht ein einfacher VPS, oder brauche ich teuren Schutz?#

Für einen privaten Server unter Freunden reicht ein VPS mit ordentlicher Anbieterfilterung. Sobald der Server öffentlich gelistet ist und eine Community hat, wird die Frage nach der Filterung zum Auswahlkriterium.

Hilft ein zweiter Server als Vorschaltung?#

Nur, wenn dessen Leitung besser gefiltert ist als deine. Sonst verschiebst du das Problem eine Maschine weiter.

Kann ich Angreifer identifizieren?#

Bei gefälschten Absendern praktisch nein. Bei Angriffen auf Spielebene manchmal, dort steht eine echte Adresse dahinter, weil eine Antwort ankommen muss.

Was ist mit Nullrouting?#

Der Anbieter wirft allen Verkehr zu deiner IP weg, bis der Angriff endet. Für ihn schützt das die anderen Kunden, für dich ist es ein Ausfall. Frag vorher, wie lange so etwas dauert.

Bringt IPv6 etwas?#

Es verschiebt nichts Grundsätzliches. Praktisch nutzen viele Spiele es noch nicht, und Filterregeln müssen ohnehin für beide Familien existieren (IPv6 auf dem VPS).

Kurz gesagt#

Volumen stoppt nur der Anbieter. Frag vor dem Mieten, nicht während des Angriffs.
notrack auf dem Spielport verhindert, dass die Verbindungstabelle den ganzen Server mitreißt.
Grenzwerte erst messen, dann setzen, zu eng sperrt Spieler aus.
Abfrageport strenger behandeln oder abschalten.
Verwaltung auf eine andere Adresse, sonst verlierst du im Ernstfall den Zugang.