Metin2 DDoS-Schutz: Firewall, Proxy und Mitigation

Einer der häufigsten Gründe, warum ein privater Server ausfällt, ist kein Code-Fehler, sondern ein Angriff von außen; deshalb ist ein solider Metin2 ddos-Schutz ein Thema, das man vor dem Start plant und nicht erst nach dem ersten Ausfall. Ein DDoS-Angriff (Distributed Denial of Service) überflutet deine Leitung oder CPU mit gefälschtem Datenverkehr aus vielen Quellen, sodass legitime Spieler keine Verbindung mehr herstellen können. Da die Metin2-Architektur aus mehreren TCP-Diensten besteht (Auth, Game/Channel-Cores, db), ist Schutz nie ein einzelnes Werkzeug, sondern eine mehrschichtige Verteidigung: Scrubbing auf Netzwerkebene, eine Firewall auf dem Host, ein Proxy, der die echte IP verbirgt, und Flood-Kontrolle auf Anwendungsebene.

Die Bedrohung kennen: Angriffstypen gegen Metin2

Um die richtige Verteidigung aufzubauen, musst du wissen, wo der Angriff einschlägt. Angriffe auf Metin2-Server lassen sich grob in drei Gruppen einteilen:

• Volumetrische Angriffe: UDP-Floods und Amplification (DNS/NTP-Reflection) füllen deine Leitung im Gbps-Bereich. Die einzige realistische Antwort ist eine Upstream-Scrubbing-Schicht vor dem Server; die iptables eines einzelnen VPS können keine 50 Gbps filtern, weil die Leitung gesättigt ist, bevor der Verkehr die Maschine überhaupt erreicht.
• Protokollangriffe: SYN-Floods und ACK-Floods zielen auf die Verbindungstabelle (conntrack) und den TCP-Handshake. Ein großer Teil davon lässt sich mit einer Firewall auf dem Host abschwächen.
• Angriffe auf Anwendungsebene: ständiges Öffnen und Schließen von TCP-Verbindungen am Game- oder Auth-Port sowie Login-/Register-Spam. Sie können den Game Core schon bei geringer Bandbreite beschäftigen und erfordern daher eine eigene Kontrolle.

Die goldene Regel: Volumetrische Angriffe werden upstream gestoppt, außerhalb des Servers; Protokoll- und Anwendungsangriffe werden auf dem Host herausgefiltert.

Architektur trennen: Auth und db niemals nach außen öffnen

Der günstigste Weg, deine Angriffsfläche zu verkleinern, ist, nur die wirklich benötigten Ports ins Internet zu öffnen. In Metin2 müssen nur die Game- (Channel-)Ports und der Auth-Port von außen erreichbar sein, damit ein Spieler verbinden kann. Der db-Dienst (Database Cache), MySQL und die GM-/Web-Panels müssen für die Außenwelt geschlossen bleiben; erreiche sie nur über das lokale Netz oder einen SSH-Tunnel.

In der Praxis heißt das, die Standardrichtlinie auf „alles ablehnen" zu setzen und nur das Nötige zu öffnen:

# Linux / iptables — grundlegender Whitelist-Ansatz
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# SSH nur von deiner eigenen IP öffnen
iptables -A INPUT -p tcp -s 203.0.113.10 --dport 22 -j ACCEPT

# Für Spieler offene Ports (Beispiel: Auth + zwei Channels)
iptables -A INPUT -p tcp --dport 11002 -j ACCEPT   # auth
iptables -A INPUT -p tcp --dport 13000 -j ACCEPT   # ch1
iptables -A INPUT -p tcp --dport 13001 -j ACCEPT   # ch2

Die Portnummern hängen von deinen eigenen CONFIG-Dateien ab; entscheidend ist hier nicht der Port selbst, sondern das Prinzip: „öffne ihn nicht, solange du ihn nicht brauchst".

Protokollangriffe mit der Firewall abschwächen

Eine Host-Firewall kann einen volumetrischen Angriff nicht stoppen, aber sie dünnt Protokollangriffe wie SYN-Floods und Connection-Floods stark aus. Unter Linux sind die wichtigsten Maßnahmen mit iptables:

# Ungültige Pakete verwerfen
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# Ratenbegrenzung gegen SYN-Flood
iptables -A INPUT -p tcp --syn -m limit --limit 60/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# Gleichzeitige Verbindungen pro IP begrenzen (Game-Port)
iptables -A INPUT -p tcp --dport 13000 \
  -m connlimit --connlimit-above 30 --connlimit-mask 32 -j REJECT

Zusätzlich verbessert das Aktivieren von SYN-Cookies auf Kernel-Ebene die Widerstandsfähigkeit gegen Handshake-Floods: sysctl -w net.ipv4.tcp_syncookies=1. Auf klassischen FreeBSD-Installationen erledigt pf dieselbe Aufgabe mit lesbarerer Syntax:

# FreeBSD / pf — Raten- und Verbindungslimit + automatische Blacklist
table <abusers> persist
block in quick from <abusers>

pass in proto tcp to port 13000 keep state \
  (max-src-conn 30, max-src-conn-rate 10/5, \
   overload <abusers> flush global)

Hier verschiebt max-src-conn-rate 10/5 jede IP, die mehr als 10 neue Verbindungen in 5 Sekunden öffnet, in die Tabelle abusers und kappt auch ihre bestehenden Verbindungen. Das ist sehr wirksam gegen einfache Flood-Bots, die in schneller Folge verbinden und trennen.

Die echte IP verbergen: Proxy- / Tunnel-Architektur

Angreifer treffen meist direkt die IP deines Servers; verhinderst du, dass sie diese IP herausfinden, verliert der volumetrische Angriff sein Ziel. Der Ansatz besteht darin, die öffentliche IP, die Spieler sehen, vom echten (Origin-)Server zu trennen, auf dem der Game Core läuft:

• Ein geschütztes Front-End (Proxy): du richtest einen TCP-Proxy oder einen GRE-Tunnel bei einem Anbieter ein, der DDoS scrubbt (zum Beispiel Hoster mit Anti-DDoS wie OVH). Spieler verbinden nur mit dieser geschützten IP, und der Proxy leitet den Verkehr an den echten Backend-Server weiter.
• Sperre die Origin ab: die Firewall des echten Servers darf Verkehr zu den Game-Ports nur von der Proxy-IP akzeptieren. Diese Regel ist entscheidend, denn sobald die Origin-IP durchsickert, kann der Angriff direkt darauf zielen.

Für einen einfachen TCP-Forwarder ist HAProxy eine gängige Wahl:

# haproxy.cfg — Auth und einen Channel ans Backend weiterleiten
frontend ft_game
    mode tcp
    bind *:13000
    default_backend bk_game

backend bk_game
    mode tcp
    server core1 10.10.0.5:13000 check

Auf der Origin-Seite vertraue nur dem Proxy:

# Origin-Firewall: nur die Proxy-IP darf den Game-Port erreichen
iptables -A INPUT -p tcp --dport 13000 -s 198.51.100.7 -j ACCEPT
iptables -A INPUT -p tcp --dport 13000 -j DROP

Ein wichtiger Hinweis: Hinter einem TCP-Proxy erscheint die echte IP eines Spielers am Backend als die Proxy-IP. Ist dein Ban-/Log-System IP-basiert, ziehe PROXY protocol-Unterstützung in Betracht, um die echte IP durchzureichen; sonst sieht es so aus, als kämen alle Spieler von einer einzigen IP.

Anwendungsebene: Login- und Verbindungsrate begrenzen

Firewall und Proxy filtern Netzwerkverkehr, aber auch der Game Core selbst muss vor Anfragen geschützt werden, die „gültig aussehen", aber bösartig sind. Praktische Maßnahmen:

• Verbindungen pro Sekunde: kommen innerhalb von Sekunden Dutzende Auth-Verbindungen von derselben IP, bremse sie mit dem connlimit/recent-Modul.
• Login-/Register-Ratenlimit: begrenze die Anzahl der Versuche pro IP im Web-Registrierungsformular und auf der Auth-Seite; das stoppt einen Angreifer, der eine Flut von Accounts erzeugt, frühzeitig.
• Monitoring: achte mit Tools wie ss -s, netstat -an | grep SYN_RECV | wc -l und vnstat auf abnormale Verbindungs-/Bandbreitenspitzen; einen Angriff früh zu erkennen verkürzt deine Reaktionszeit.

Denke schließlich daran, deine Regeln mit iptables-save / pfctl persistent zu machen und einen Notfallplan bereitzuhalten (während eines Angriffs einen Channel-Port vorübergehend schließen, die Proxy-IP wechseln).

Häufige Fragen

Kann ich einen großen DDoS mit iptables auf einem einzelnen VPS stoppen?

Nein. Volumetrische Angriffe (im Gbps-Bereich) füllen deine Leitung, bevor sie den Server erreichen, während iptables ein Paket erst verarbeitet, sobald es an der Maschine ankommt. Für solche Angriffe brauchst du einen Anbieter, der Upstream-Scrubbing vor dem Server durchführt, oder einen Anti-DDoS-Proxy. iptables/pf sind wertvoll, um Protokoll- und Verbindungsangriffe auszudünnen.

Erhöht ein Proxy den Ping der Spieler?

Da du den Verkehr über einen Zwischenschritt leitest, ist eine kleine zusätzliche Latenz normal. Um sie zu minimieren, platziere den Proxy geografisch nah an deinen Spielern und am Origin-Server; bei einem gut aufgebauten Tunnel beträgt der Unterschied meist nur wenige Millisekunden.

Was soll ich tun, wenn meine echte IP durchsickert?

Wenn du die Origin-Firewall nur für die Proxy-IP offen gehalten hast, erleichtert ein Leck allein keinen Angriff, aber am sichersten ist es trotzdem, die IP des Origin-Servers zu ändern (eine neue IP beim Hoster nehmen) und den gesamten Verkehr über die alte abzuweisen.

Möchtest du deinen Server von Tag eins an richtig gegen Angriffe aufstellen? Lass uns die Firewall, die Proxy-Architektur und die Metin2-seitige Konfiguration gemeinsam planen — nimm Kontakt mit mir auf.