Metin2 DDoS Koruma: Firewall, Proxy ve Saldırı Azaltma

Bir özel sunucuyu çökerten en sık nedenlerden biri teknik bir hata değil, dışarıdan gelen saldırılardır; bu yüzden sağlam bir Metin2 ddos koruma kurgusu, sunucu açılışından önce planlanması gereken bir konudur. DDoS (dağıtık hizmet engelleme) saldırısı, çok sayıda kaynaktan gelen sahte trafikle sunucunuzun hattını veya işlemcisini boğarak meşru oyuncuların bağlanamamasına yol açar. Metin2 mimarisi TCP üzerinde çalışan birden çok servisten (auth, game/channel core'ları, db) oluştuğu için, koruma da tek bir araçla değil katmanlı bir savunmayla kurulur: ağ seviyesinde temizleme, sunucu üzerinde firewall, gerçek IP'yi gizleyen bir proxy ve uygulama katmanında akış (flood) denetimi.

Tehdidi tanımak: Metin2'ye yönelik saldırı türleri

Doğru savunmayı kurmak için saldırının nereye vurduğunu bilmek gerekir. Metin2 sunucularına yönelik saldırılar kabaca üç gruba ayrılır:

• Hacim tabanlı (volumetric) saldırılar: UDP flood, amplifikasyon (DNS/NTP reflection) gibi yöntemlerle hattınızı Gbps mertebesinde doldurur. Bunlara karşı tek gerçekçi çözüm, sunucunun önünde yeterli kapasiteye sahip bir upstream temizleme (scrubbing) katmanıdır; tek bir VPS'in iptables'ı 50 Gbps'lik trafiği eleyemez, çünkü trafik hatta gelmeden zaten dolar.
• Protokol saldırıları: SYN flood, ACK flood gibi yöntemler bağlantı tablosunu (conntrack) ve TCP el sıkışmasını hedefler. Bunların önemli kısmı sunucu üzerinde firewall ile azaltılabilir.
• Uygulama katmanı saldırıları: Oyun veya auth portuna sürekli yeni TCP bağlantısı açıp kapatma, login/register spam'i. Bunlar düşük bant genişliğiyle bile game core'u meşgul edebildiği için ayrı bir denetim ister.

Altın kural: hacimsel saldırı yukarıda, sunucu dışında durdurulur; protokol ve uygulama saldırıları sunucu üzerinde inceltilir.

Mimariyi ayırın: auth ve db'yi asla dışarı açmayın

Saldırı yüzeyini küçültmenin en ucuz yolu, yalnızca gerçekten gerekli portları internete açmaktır. Metin2'de oyuncunun bağlanması için yalnızca game (channel) portları ve auth portu dışarıdan erişilebilir olmalıdır. db (database cache) servisi, MySQL ve GM/web panelleri kesinlikle dış dünyaya kapalı kalmalı; bunlar yalnızca yerel ağ ya da SSH tüneli üzerinden erişilmeli.

Pratikte bu, varsayılan politikayı "her şeyi reddet" yapıp yalnızca ihtiyaç duyulanı açmak demektir:

# Linux / iptables — temel beyaz liste yaklaşımı
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# SSH'i yalnızca kendi IP'nizden açın
iptables -A INPUT -p tcp -s 203.0.113.10 --dport 22 -j ACCEPT

# Oyuncuya açık portlar (örnek: auth + iki channel)
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

Port numaraları kendi CONFIG dosyalarınıza göre değişir; buradaki mantık portun kendisi değil, "gerekmedikçe açma" ilkesidir.

Firewall ile protokol saldırılarını azaltma

Sunucu üzerinde firewall, hacimsel saldırıyı durduramaz ama SYN flood ve bağlantı taşması gibi protokol saldırılarını ciddi şekilde inceltir. Linux'ta iptables ile başlıca tedbirler şunlardır:

# Geçersiz paketleri at
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# SYN flood'a karşı oran sınırı
iptables -A INPUT -p tcp --syn -m limit --limit 60/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# Tek IP'den eşzamanlı bağlantı sayısını sınırla (oyun portu)
iptables -A INPUT -p tcp --dport 13000 \
  -m connlimit --connlimit-above 30 --connlimit-mask 32 -j REJECT

Buna ek olarak çekirdek (kernel) seviyesinde SYN cookie'leri açmak el sıkışma flood'larına dayanıklılığı artırır: sysctl -w net.ipv4.tcp_syncookies=1. FreeBSD üzerinde çalışan klasik kurulumlarda aynı işi pf daha okunaklı bir sözdizimiyle yapar:

# FreeBSD / pf — oran ve bağlantı sınırı + otomatik kara liste
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)

Burada max-src-conn-rate 10/5, 5 saniyede 10'dan fazla yeni bağlantı açan IP'yi abusers tablosuna atar ve mevcut bağlantılarını da düşürür. Bu, art arda bağlanıp kopan basit flood botlarına karşı oldukça etkilidir.

Gerçek IP'yi gizleyin: proxy / tünel mimarisi

Saldırganlar çoğunlukla doğrudan sunucunuzun IP'sine vurur; o IP'yi öğrenmelerini engellerseniz hacimsel saldırının hedefi de kaybolur. Yaklaşım, oyuncuların gördüğü genel IP ile game core'un çalıştığı gerçek (origin) sunucuyu birbirinden ayırmaktır:

• Korumalı bir ön uç (proxy): DDoS temizlemesi yapan bir sağlayıcıda (örneğin OVH gibi anti-DDoS sunan hostlar) bir TCP proxy ya da GRE tüneli kurarsınız. Oyuncular yalnızca bu korumalı IP'ye bağlanır; proxy de trafiği arka uçtaki gerçek sunucuya iletir.
• Origin'i kilitleyin: Gerçek sunucunun firewall'ı, oyun portlarına yalnızca proxy IP'sinden gelen trafiği kabul etmelidir. Origin IP sızdığı an saldırı doğrudan oraya yönelebileceği için bu kural kritik.

Basit bir TCP yönlendirici için HAProxy sık tercih edilir:

# haproxy.cfg — auth ve bir channel'ı arka uca taşı
frontend ft_game
    mode tcp
    bind *:13000
    default_backend bk_game

backend bk_game
    mode tcp
    server core1 10.10.0.5:13000 check

Origin tarafında ise yalnızca proxy'ye güvenin:

# Origin firewall: oyun portuna sadece proxy IP'si girebilir
iptables -A INPUT -p tcp --dport 13000 -s 198.51.100.7 -j ACCEPT
iptables -A INPUT -p tcp --dport 13000 -j DROP

Önemli bir uyarı: TCP proxy arkasında oyuncunun gerçek IP'si arka uçta proxy IP'si gibi görünür. Eğer ban/log sisteminiz IP bazlıysa, gerçek IP'yi taşımak için PROXY protocol desteğini değerlendirin; aksi halde tüm oyuncular tek IP'den geliyormuş gibi görünür.

Uygulama katmanı: login ve bağlantı akışını sınırlayın

Firewall ve proxy ağ trafiğini eler, ama "geçerli görünen" ama kötü niyetli isteklere karşı game core'un kendisi de korunmalı. Pratik önlemler:

• Bağlantı başına hız: Aynı IP'den saniyeler içinde onlarca auth bağlantısı geliyorsa, bunu connlimit/recent modülüyle yavaşlatın.
• Login/register hız sınırı: Web kayıt formunda ve auth tarafında IP başına deneme sayısını sınırlayın; hesap denizini açan bir saldırganı erken durdurur.
• İzleme: ss -s, netstat -an | grep SYN_RECV | wc -l ve vnstat gibi araçlarla anormal bağlantı/bant artışını gözleyin; saldırıyı erken fark etmek tepki süresini kısaltır.

Son olarak iptables-save / pfctl ile kuralları kalıcı hale getirmeyi ve bir acil durum planı (saldırı anında channel portunu geçici kapatma, proxy IP'sini değiştirme) hazır tutmayı unutmayın.

Sık Sorulan Sorular

Tek bir VPS'te iptables ile büyük DDoS'u durdurabilir miyim?

Hayır. Hacimsel (Gbps düzeyinde) saldırılar hattınızı sunucuya ulaşmadan doldurur; iptables paketi ancak sunucuya geldiğinde işler. Bu tür saldırılar için sunucunun önünde upstream temizleme yapan bir sağlayıcı veya anti-DDoS proxy şarttır. iptables/pf, protokol ve bağlantı saldırılarını inceltmek için değerlidir.

Proxy kullanınca oyuncuların pingi artar mı?

Trafiği bir ara durağa yönlendirdiğiniz için küçük bir gecikme eklenmesi olağandır. Etkisini en aza indirmek için proxy'yi oyuncularınıza ve origin sunucuya coğrafi olarak yakın bir konumda seçin; iyi kurulmuş bir tünelde fark çoğu zaman birkaç milisaniyedir.

Gerçek IP'm sızarsa ne yapmalıyım?

Origin firewall'ı yalnızca proxy IP'sine açık tuttuysanız sızıntı tek başına saldırıyı kolaylaştırmaz, ama yine de en güvenlisi origin sunucunun IP'sini değiştirmek (hostta yeni IP almak) ve eski IP üzerinden gelen tüm trafiği reddetmektir.

Sunucunuzu saldırılara karşı baştan doğru kurmak ister misiniz? Firewall, proxy mimarisi ve Metin2 tarafı yapılandırmayı birlikte planlayalım — benimle iletişime geçin.