Oyun Sunucuları için DDoS Koruması: 10 Dakikalık Saldırı Çağı Runbook'u

Matchmaking kuyruğunuz saat 21:14'te takılıyor. 21:19'da geri geliyor. Grafiğe baktığınızda altı dakika genişliğinde 620 Mbps'lik bir ani yükseliş görüyorsunuz; telefonunuza uyarı düşmeden çoktan kaybolmuş. İki kişilik ekibinizden kimse bunu canlı izlemedi ve oyuncularınız bunu "lag" olarak kaydetti.

Bu saldırı biçimi artık varsayılan durum. Cloudflare'ın 2026 Q3 DDoS Tehdit Raporu, çeyrekte engellenen 18,2 milyon ağ katmanı saldırısı kaydetti — kabaca saatte 8.226, yani her 0,44 saniyede bir. Bunların %96'sı 10 dakikanın altında bitti ve %98'i 1 Gbps altında kaldı. 1 Tbps üzeri hiper-volumetrik saldırılar Q2'de 805'ten Q3'te 251'e düştü; rapor bu ~%69'luk düşüşü Aisuru, KimWolf, JackSkid ve Mossad IoT botnetlerine yönelik kolluk kuvveti operasyonlarına bağlıyor.

Daha az dev. Daha çok sürü. Ve sürü, küçük bir oyun backend'inin en kötü hazırlandığı tehdit modelidir; çünkü aynı anda sağlayıcınızın azaltma katmanını tetikleyemeyecek kadar küçük ve tek bir oyun instance'ını doyuracak kadar büyük.

Bu, o bant genişliği aralığı için bir runbook.

2026 Q3 aslında neyi değiştirdi

Oyun sunucusu işletiyorsanız üç değişim önemli. İlki süre. Kısa patlamalı, düşük bant genişlikli saldırılardaki yıllık %208'lik artış, kiralık DDoS "booter" hizmetlerinin operasyonel imzasıdır: ucuz, tekrarlanabilir ve seri halinde ateşlenir. Bir akşam boyunca tek saldırı değil, 40 saldırı bekleyin.

İkincisi vektör değişimi. CLDAP reflection — UDP 389 üzerindeki istismar edilen genel domain controller'lar — H1 boyunca yoğun çalıştıktan sonra çeyreklik bazda %99,5 düşerek saldırıların yalnızca %0,05'ine geriledi. Saldırganlar durmadı; rotasyon yaptı. DNS amplification %215 artışla ağ katmanı saldırılarının %3,43'üne yükselirken, genel UDP flood'ları %14,06'dan %31,31'e çıktı.

Üçüncüsü hedeflerin genişlemesi. Medya en çok saldırıya uğrayan sektör olmayı sürdürdü ancak Q2'deki payının yaklaşık dörtte üçünü kaybetti. İnternet altyapısı ilk 10 dışından 6. sıraya yükseldi; Tüketici Hizmetleri ve Yetişkin Eğlence 8. ve 9. sıradan girdi. Oyunlar, tüketiciye dönük ve gecikmeye duyarlı hedeflerin tam ortasında duruyor.

Savunmacılar için ders: playbook'unuzu geçen çeyreğin vektörüne göre kurmayın. Onu dört kategori etrafında kurun — UDP flood, DNS amplification, reflection istismarı ve SYN tükenmesi — ve ağırlıkların hareket etmeye devam ettiğini varsayın.

Bir oyun backend'inde ilk ne bozulur

Her şey aynı anda çökmez; sıralamayı bilmek sizi yanlış yangınla savaşmaktan kurtarır.

• Oyun portu. Otoritatif sunucu portunuza yönelik bir UDP flood, CPU'dan önce NIC kuyruklarını tüketir. Süreç canlı olduğu için sunucunuz orkestratör sağlık kontrolüne "ayakta" görünür, ancak paketler çekirdekte düşürülüyordur.
• Oturum ve giriş endpoint'leri. HTTP flood'lar kimlik doğrulamayı vurur. Patlama sırasında bağlantısı kopan oyuncular geri giremez; zaten oyunda olanlar, yeniden bağlanma döngüsü başarısız olduğu için oyundan çıkar.
• Leaderboard okumaları. Bunlar çoğu oyun backend'inde en çok amplifiye edilen okuma yoludur: tek bir istemci isteği veritabanında aralık taramasına yayılır. Saniyede 5.000 istek göndermek önemsizdir, sunmak pahalıdır.
• Telemetri alımı. Genellikle kimlik doğrulamasız veya gevşek rate-limit'lidir; çoğu zaman vurmak için en ucuz endpoint'tir.
• Conntrack tablosu. Doldurulması, SSH erişiminiz dahil ana makinedeki her hizmeti çökertir; dört dakikalık bir saldırı böylece dört saatlik bir kesintiye dönüşür.

Reflection saldırıları özel bir notu hak ediyor: trafik meşru DNS çözücülerinden ve diğer üçüncü taraf sunuculardan gelir; bu nedenle IP itibarı engellemesi tasarım gereği başarısız olur. Masum altyapı tarafından vuruluyorsunuz.

Tespit: grafiklerden önce tetiklenen sinyaller

Panolarınız gecikir. Çekirdek sayaçları gecikmez. En önemli ön gösterge paket/saniye ile bit/saniye oranıdır. Meşru 300 Mbps oyun trafiği, tipik yük boyutlarında kabaca saniyede 25.000-40.000 pakettir. 64 baytlık paketlerle 300 Mbps'lik bir UDP flood, saniyede 500.000 pps'ye yakındır. Aynı bant genişliği, 15 kat fazla paket; ve bant genişliği grafiğiniz normal görünürken ana makineyi öldürür.

Şüpheli makinede şunları çalıştırın:

# socket and memory pressure summary
ss -s

# per-protocol counters and the ones that predict a lockup
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|TcpExtListenDrops|TcpExtTCPReqQFullDrop'

# current conntrack table occupancy vs max
conntrack -C && sysctl net.netfilter.nf_conntrack_max

# what is actually arriving on the wire
tcpdump -nn -i eth0 'udp and not port 7777' -c 200

Bunları şöyle okuyun:

• UdpInDatagrams yükseliyor ve oyun döngünüz daha düşük oyuncu sayısı bildiriyorsa = flood.
• UdpNoPorts artıyorsa = port aralığınızı tarayan bir scanner, genellikle öncü sinyal.
• TcpExtTCPReqQFullDrop sıfır değilse = SYN kuyruğu taşması, yani meşru el sıkışmalarını kaybediyorsunuz demektir.
• conntrack -C, nf_conntrack_max değerinin %70'inin üzerindeyse = yalnızca oyun sunucusu çökmesine değil, ana makinenin tamamen çökmesine dakikalar kalmış demektir.

Çekirdek görünümü yerine endpoint bazlı görünüm istiyorsanız, UEFN sunucu çökmesi tanılama protokolü ağ katmanı kaynaklı bir durmayı motor katmanı kaynaklı olandan ayırmayı adım adım anlatır; bu, her triyajda verilen ilk karardır.

Geçmeyi başaran çöplere karşı süreç içi savunma için, soket katmanında kaynak başına token bucket ucuz ve etkilidir. Bu C# örneği, gelen paketleri simülasyon tick'inize ulaşmadan önce kapıda kontrol eder:

using System.Diagnostics;
using System.Net;

public sealed class PacketGate
{
    private readonly Dictionary<IPAddress, Bucket> _buckets = new();
    private readonly int _ratePerSecond;
    private readonly int _burst;

    // A legit client at 30 Hz sends ~30 packets/s. 120/s allows
    // headroom for retransmits without letting a flood through.
    public PacketGate(int ratePerSecond = 120, int burst = 240)
    {
        _ratePerSecond = ratePerSecond;
        _burst = burst;
    }

    public bool Allow(IPAddress source)
    {
        long now = Stopwatch.GetTimestamp();

        if (!_buckets.TryGetValue(source, out var bucket))
        {
            bucket = new Bucket { Tokens = _burst, LastRefill = now };
            _buckets[source] = bucket;
        }

        double elapsed = (now - bucket.LastRefill) / (double)Stopwatch.Frequency;
        bucket.Tokens = Math.Min(_burst, bucket.Tokens + elapsed * _ratePerSecond);
        bucket.LastRefill = now;

        if (bucket.Tokens < 1.0) return false;
        bucket.Tokens -= 1.0;
        return true;
    }

    private sealed class Bucket
    {
        public double Tokens;
        public long LastRefill;
    }
}

Bunun ne yapıp ne yapmadığı konusunda net olun. Mevcut bant genişliğinize sığan kaynak başına çöpü filtreler. Hat tamamen dolduğunda hiçbir şey yapmaz — o noktada paketler, kodunuz ne karar verirse versin sürecinizin üst kısmında düşürülür.

İyileştirme runbook'u: ilk on dakika

Saldırıların %96'sı bir insan müdahale edemeden bittiği için runbook'un işi saldırıyı sizin düzeltmenizi sağlamak değildir. Saldırı sönerken kanıt toplamanızı ve patlama yarıçapını küçültmenizi sağlamaktır.

T+0 ile T+2 dakika arası — doğrulayın, ölçeklendirmeyin. Instance ekleme refleksine direnin. Bir flood'un içine ölçeklenmek faturanızı ve saldırı yüzeyinizi katlar. Vektörü yukarıdaki sayaçlarla doğrulayın, pps ve bant genişliğini not edin ve conntrack tablosunun dolup dolmadığını kontrol edin. Doluyorsa, hemen T+0 acil ana makine korumasına geçin.

T+2 ile T+5 dakika arası — zorunlu olmayan yükü atın. Oyun olmayan her şeyi devre dışı bırakın: telemetri toplama, leaderboard yenileme, mağaza yoklama, sosyal akışlar. Backend'iniz uzaktan yapılandırmayı destekliyorsa bu, deploy yerine tek bir bayrak değişimidir.

T+5 ile T+10 dakika arası — ana makine düzeyinde hız sınırları uygulayın. Çekirdek filtreleme, uygulama filtrelemesinden kat kat daha ucuzdur:

table inet gameguard {
    set udp_flood {
        type ipv4_addr
        flags dynamic, timeout
        timeout 60s
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        tcp dport { 22, 443 } accept
        tcp dport 7777-7800 accept
        udp dport 7777-7800 accept

        # drop fragmented UDP - your game protocol should never need it
        ip frag-off & 0x1fff != 0 udp drop

        # per-source UDP cap well above a real client's send rate
        udp dport 7777-7800 update @udp_flood \
            { ip saddr limit rate over 200/second burst 400 packets } drop
    }
}

nft -f gameguard.nft ile yükleyin. nft list ruleset ve nft list set inet gameguard udp_flood ile doğrulayın. Bunu yanlış yapıp kendinizi dışarıda bırakırsanız, ağ olayını fiziksel erişim olayına dönüştürmüş olursunuz — önce staging'de test edin ve kuralları sürüm kontrolünde tutun.

T+10 dakika ve sonrası — üst sağlayıcınıza iletin. Ana makinede değil, ağ ucunda temizleme veya blackhole kapasitesine ihtiyacınız var. Çoğu yönetilen oyun barındırma sağlayıcısı bunu sunar; sunmuyorsa bu, bir sonraki saldırıdan önce çözmeniz gereken bir tedarik sorunudur. Özellikle 1 Gbps altı UDP azaltma eşiklerini sorun; çünkü yayınlanan SLA'ların çoğu asla görmeyeceğiniz terabit saldırılar için yazılmıştır.

Boyunca: zaman damgalı bir günlük tutun. Saldırı başlangıcı, vektör, tepe pps, tepe Gbps, neyi ne zaman değiştirdiğiniz. Postmortem, azaltmanın kendisinden daha değerlidir.

Vektör playbook'u: yanıtı saldırının şekline göre eşleştirmek

UDP flood (saldırıların %31,31'i). Rastgele veya hedefli portlar; ana makineyi dinleyici olup olmadığını kontrol etmeye ve ICMP unreachable üretmeye zorlar. Ağ katmanı yedeklilik mimarisi makalesi, birincil taşıyıcı dövülürken düşük kaliteli ama oynanabilir bir modu nasıl ayakta tutacağınızı anlatıyor. Yanıt: nftables kaynak başına hız sınırı, oyun portunuz olmayan tüm UDP portlarını kapatın ve ana makinede ICMP unreachable üretimini devre dışı bırakın.

DNS amplification (%3,43, %215 artış). Açık çözücülere sahte kaynaklı sorgular, size yönlendirilen büyük yanıtlar. Yanıt: kaynağa göre engelleyemezsiniz, çünkü kaynaklar meşru çözücülerdir. Yalnızca yanıt boyutuna ve hızına göre emebilir veya filtreleyebilirsiniz. Kendinizin açık bir çözücü çalıştırmadığınızı dig +short txt chaos version.bind @your.ip ile doğrulayın — yanıt veriyorsa bugün kapatın.

CLDAP (%0,05'e geriledi). Şu an sessiz, tarihsel olarak devasa. Hatırlatma şu: CLDAP amplification UDP 389 üzerinde çalışır; LDAP'e ihtiyacınız yoksa hem ana makine hem bulut güvenlik duvarında filtreli tutun. Saldırganlar rotasyon yaptıklarında korunmasız portlara geri döner.

SYN flood. Nadiren hacim, her zaman tükenme. SYN çerezlerini etkinleştirin (sysctl -w net.ipv4.tcp_syncookies=1), net.core.somaxconn değerini yükseltin ve conntrack tablosunun varsayılan yerine en kötü gerçekçi senaryonuza göre boyutlandırıldığından emin olun.

Önleme: dört dakikalık bir patlamaya dayanan mimari

Önce kapasite hesabı, çünkü birçok temenni düşüncesini öldürür. 64 oyunculu, 100 tick'lik bir sunucu, oyuncu başına kabaca 15-20 KB/s taşır — buna 1,2 MB/s veya instance başına yaklaşık 10 Mbps diyelim. 400 Mbps'lik bir saldırı, o instance'ın meşru trafiğinin 40 katıdır. Saldırıların %98'i 1 Gbps altında olduğundan, mevcut dağılımdaki neredeyse her saldırı tek bir oyun instance'ını dümdüz edecek kadar büyükken, tier-1 temizleme sağlayıcısının otomatik azaltmasını ilgilendirmeyecek kadar küçüktür.

Bu, mimarinizi üç şekilde kısıtlar.

Hesap düzlemini oyun düzleminden ayırın. Giriş endpoint'iniz, leaderboard okumalarınız ve oyuncu kayıtlarınız oyun sunucularınızla aynı ana makinede çalışıyorsa, oyun portuna yönelik bir flood hesapları da çökertir ve oyuncular "birazdan döneceğiz" ekranına bile ulaşamaz. Bu hesap bağlantılı hizmetleri horizOn üzerinde çalıştırmak — kimlik doğrulama, Cloud Save ve leaderboard'lar orada yönetilir — oyun portunuza yönelik bir patlamanın oynanışı düşürmesini, ancak her oyuncunun profiline erişimini kilitlememesini sağlar.

Özellik kısmayı bir deploy değil, bir yapılandırma değişikliği yapın. Flood geldiğinde saniyeleriniz vardır. Uzaktan yapılandırma, pahalı okuma yollarını anında kapatmanızı sağlar. Tek seçeneğiniz build göndermekse, bunu kullanmazsınız.

Sağlık kontrolünü ağ arızasını görecek şekilde kurun. Süreç kontrolü, çekirdek paketlerin %90'ını düşürürken "sağlıklı" raporlar. Gerçek oynanış erişilebilirliğini yoklayın — gerçek bir el sıkışması yapan ve 250ms içinde yanıt bekleyen sentetik bir istemci — ve failover'ı buna göre yönlendirin.

En iyi uygulamalar: bu hafta yayınlamaya değer beş değişiklik

1. Yalnızca bant genişliğine değil, paket hızına da alarm ver. Eşiği, 95. yüzdelik pps değerinizin 2,5 katına ayarlayın. Yalnızca bant genişliği alarmları kısa patlamaları tamamen kaçırır; pps anomali tespiti, hiçbir bant genişliği grafiğinin işaretlemeyeceği 1 Gbps bağlantıya sahip bir ana makinedeki 300 Mbps flood'u yakalar.
2. Conntrack tablosunu bilinçli boyutlandırın. net.netfilter.nf_conntrack_max değerini dağıtım varsayılanına göre değil, tepe eşzamanlı oturum sayısına göre ayarlayın ve %70 dolulukta alarm verin. Bu tek değişiklik, en yaygın "saldırı kesintiye dönüştü" tırmanışını önler.
3. nftables kural setini önceden yazın ve üç ayda bir test edin. Repo'nuzda deploy yapılandırmasının yanında saklayın. Bir olay sırasında uygulanan test edilmemiş güvenlik duvarı kuralı, ikinci bir olaydır.
4. Oyuncularınıza kısıtlı mod sözleşmesi yayınlayın. Azaltma sırasında leaderboard'lar ve sohbet on dakika kararırsa, bunu yama notlarında ve durum sayfasında belirtin. Sessizlik, ölü oyun gibi algılanır. Bunun için bir model istiyorsanız, güvenlik ihlali sonrası backend mimarisi analizindeki dayanıklılık desenleri doğrudan kullanılabilirlik olaylarına uyarlanabilir.
5. Her saldırıyı yapılandırılmış bir olay olarak günlüğe kaydedin. Zaman damgası, vektör, tepe pps, tepe Gbps, süre, uygulanan azaltma. Beş saldırıdan sonra kendi deseninizi görürsünüz — çoğu indie backend, aynı hafta içi gününde, aynı saatte, aynı booter tarafından vurulur.

Sonuç

2026 tehdit profili, terabit saldırıları için plan yapıp 400 Mbps'lik altı dakikalık patlamayı görmezden gelen ekiplere düşmanca. Devler %69 düştü; sürüler %208 arttı. Azaltmanız otomatik, ucuz ve çekirdekte olmak zorunda; çünkü hiçbir insan, uyarı okunmadan biten bir saldırının içinde harekete geçemez.

Sayaçlarla başlayın, panolarla değil. Kaynak başına hız sınırını ekleyin, conntrack tablosunu boyutlandırın, hesap düzleminizi oyun düzleminizden ayırın ve on dakikalık runbook'u sıkıcı hale gelene kadar prova edin.

Bu ayrımın bir kısmı sahiplenmek istemeyeceğiniz gösterişsiz bir işse — oyuncu kimlik doğrulama, revizyon destekli Cloud Save, leaderboard'lar, olay sırasında çevirebileceğiniz uzaktan yapılandırma — bu kısmı horizOn halleder; böylece nöbet süreniz bunun yerine oyun sunucularına gider. Ücretsiz deneyin veya bir sonraki lansman pencerenizden önce dokümanları okuyun.

---

Kaynak: Cloudflare DDoS Tehdit Raporu 2026 Q3: Daha çok sürü, daha az dev