Metin2 DDoS-bescherming: firewall, proxy en mitigatie

Een van de meest voorkomende redenen waarom een private server uitvalt is geen codefout maar een aanval van buitenaf; daarom is een degelijke Metin2 ddos-bescherming iets dat je vóór de lancering plant, niet na de eerste storing. Een DDoS-aanval (distributed denial of service) overspoelt je lijn of processor met nepverkeer uit vele bronnen, zodat legitieme spelers niet meer kunnen verbinden. Omdat de Metin2-architectuur uit meerdere TCP-services bestaat (auth, game/channel cores, db), is bescherming nooit één enkel hulpmiddel maar een gelaagde verdediging: scrubbing op netwerkniveau, een firewall op de host, een proxy die het echte IP verbergt en floodbeheersing op applicatieniveau.

Ken de dreiging: aanvalstypen gericht op Metin2

Om de juiste verdediging te bouwen moet je weten waar de aanval landt. Aanvallen op Metin2-servers vallen ruwweg in drie groepen:

• Volumetrische aanvallen: UDP-floods en amplificatie (DNS/NTP-reflectie) vullen je lijn op Gbps-schaal. Het enige realistische antwoord is een upstream scrubbing-laag vóór de server; de iptables van één enkele VPS kan geen 50 Gbps filteren, want de lijn is verzadigd voordat het verkeer de machine zelfs bereikt.
• Protocolaanvallen: SYN-floods en ACK-floods richten zich op de verbindingstabel (conntrack) en de TCP-handshake. Een groot deel hiervan is met een firewall op de host te beperken.
• Aanvallen op applicatieniveau: voortdurend TCP-verbindingen openen en sluiten op de game- of auth-poort, en login/register-spam. Deze kunnen de game core zelfs bij lage bandbreedte bezighouden en vragen dus om aparte controle.

De gulden regel: volumetrische aanvallen worden upstream gestopt, buiten de server; protocol- en applicatieaanvallen worden op de host weggefilterd.

Scheid de architectuur: stel auth en db nooit bloot

De goedkoopste manier om je aanvalsoppervlak te verkleinen is alleen de poorten openzetten die je echt nodig hebt richting internet. In Metin2 hoeven alleen de game- (channel-)poorten en de auth-poort van buitenaf bereikbaar te zijn om een speler te laten verbinden. De db-service (database cache), MySQL en de GM/web-panelen moeten gesloten blijven voor de buitenwereld; benader ze alleen via het lokale netwerk of een SSH-tunnel.

In de praktijk betekent dit dat je het standaardbeleid op "alles weigeren" zet en alleen opent wat je nodig hebt:

# Linux / iptables — basale whitelist-aanpak
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Open SSH alleen vanaf je eigen IP
iptables -A INPUT -p tcp -s 203.0.113.10 --dport 22 -j ACCEPT

# Poorten open voor spelers (voorbeeld: auth + twee 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

De poortnummers variëren met je eigen CONFIG-bestanden; het gaat hier niet om de poort zelf maar om het principe: "open hem niet tenzij je hem nodig hebt."

Protocolaanvallen beperken met de firewall

Een host-firewall kan een volumetrische aanval niet stoppen, maar dunt protocolaanvallen zoals SYN-floods en connection floods sterk uit. Op Linux zijn de belangrijkste maatregelen met iptables:

# Ongeldige pakketten droppen
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# Rate limit tegen 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

# Beperk gelijktijdige verbindingen per IP (game-poort)
iptables -A INPUT -p tcp --dport 13000 \
  -m connlimit --connlimit-above 30 --connlimit-mask 32 -j REJECT

Daarnaast verbetert het inschakelen van SYN cookies op kernelniveau de weerbaarheid tegen handshake-floods: sysctl -w net.ipv4.tcp_syncookies=1. Op klassieke FreeBSD-installaties doet pf hetzelfde werk met een leesbaardere syntaxis:

# FreeBSD / pf — rate- en verbindingslimiet + 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 verplaatst max-src-conn-rate 10/5 elk IP dat meer dan 10 nieuwe verbindingen in 5 seconden opent naar de abusers-tabel en verbreekt ook zijn bestaande verbindingen. Dit is zeer effectief tegen eenvoudige floodbots die snel achter elkaar verbinden en de verbinding verbreken.

Verberg het echte IP: proxy- / tunnelarchitectuur

Aanvallers slaan meestal direct het IP van je server aan; als je verhindert dat ze dat IP achterhalen, verliest de volumetrische aanval zijn doelwit. De aanpak is om het publieke IP dat spelers zien te scheiden van de echte (origin) server waar de game core draait:

• Een beschermde front-end (proxy): je zet een TCP-proxy of een GRE-tunnel op bij een provider die DDoS scrubt (bijvoorbeeld hosts die anti-DDoS bieden zoals OVH). Spelers verbinden alleen met dit beschermde IP, en de proxy stuurt het verkeer door naar de echte backend-server.
• Vergrendel de origin: de firewall van de echte server mag verkeer naar de game-poorten alleen vanaf het proxy-IP accepteren. Deze regel is cruciaal, want zodra het origin-IP lekt, kan de aanval er direct op gericht worden.

Voor een eenvoudige TCP-forwarder is HAProxy een gangbare keuze:

# haproxy.cfg — auth en één channel naar de backend doorsturen
frontend ft_game
    mode tcp
    bind *:13000
    default_backend bk_game

backend bk_game
    mode tcp
    server core1 10.10.0.5:13000 check

Aan de origin-kant vertrouw je alleen de proxy:

# Origin-firewall: alleen het proxy-IP mag de game-poort bereiken
iptables -A INPUT -p tcp --dport 13000 -s 198.51.100.7 -j ACCEPT
iptables -A INPUT -p tcp --dport 13000 -j DROP

Een belangrijke kanttekening: achter een TCP-proxy verschijnt het echte IP van een speler bij de backend als het proxy-IP. Als je ban-/logsysteem op IP gebaseerd is, overweeg dan PROXY protocol-ondersteuning om het echte IP door te geven; anders lijkt het alsof alle spelers van één IP komen.

Applicatieniveau: beperk login- en verbindingssnelheid

Firewall en proxy filteren netwerkverkeer, maar de game core zelf moet ook beschermd worden tegen verzoeken die "geldig lijken" maar kwaadaardig zijn. Praktische maatregelen:

• Verbindingen per seconde: als binnen seconden tientallen auth-verbindingen van hetzelfde IP binnenkomen, vertraag ze dan met de connlimit/recent-module.
• Login-/register-limiet: beperk het aantal pogingen per IP op het webregistratieformulier en aan de auth-kant; dit stopt een aanvaller die een zee aan accounts aanmaakt vroegtijdig.
• Monitoring: let op afwijkende pieken in verbindingen/bandbreedte met tools als ss -s, netstat -an | grep SYN_RECV | wc -l en vnstat; een aanval vroeg opmerken verkort je reactietijd.

Maak tot slot je regels persistent met iptables-save / pfctl en houd een noodplan klaar (tijdelijk een channel-poort sluiten tijdens een aanval, het proxy-IP wisselen).

Veelgestelde vragen

Kan ik een grote DDoS stoppen met iptables op één enkele VPS?

Nee. Volumetrische aanvallen (op Gbps-schaal) vullen je lijn voordat ze de server bereiken, terwijl iptables een pakket pas verwerkt zodra het op de machine aankomt. Voor zulke aanvallen heb je een provider nodig die upstream scrubbing doet vóór de server, of een anti-DDoS-proxy. iptables/pf zijn waardevol om protocol- en verbindingsaanvallen uit te dunnen.

Verhoogt een proxy de ping van spelers?

Omdat je verkeer via een tussenstap routeert, is een kleine toegevoegde latentie normaal. Om die te minimaliseren plaats je de proxy geografisch dicht bij zowel je spelers als de origin-server; op een goed gebouwde tunnel is het verschil meestal slechts een paar milliseconden.

Wat moet ik doen als mijn echte IP lekt?

Als je de origin-firewall alleen voor het proxy-IP open hebt gehouden, maakt een lek op zich een aanval niet eenvoudig, maar het veiligst is nog steeds om het IP van de origin-server te wijzigen (een nieuw IP bij de host nemen) en al het verkeer dat via het oude binnenkomt te weigeren.

Wil je je server vanaf dag één goed beveiligen tegen aanvallen? Laten we samen de firewall, de proxyarchitectuur en de Metin2-zijdige configuratie plannen — neem contact met me op.