İlk Siparişe Özel %20 İndirim Kodu:
DDoS Koruması

A2S Cache Nedir? Oyun Sunucularında A2S DDoS Saldırılarını Önleme

Source ve CS2 oyun sunucularında A2S sorgu yapısı, UDP amplification saldırıları ve TRSHIELD A2S önbelleği (A2S cache) ile CPU koruma mimarisi.

6 dk okuma

İçindekiler

Counter-Strike 2, Rust, Team Fortress 2 ve Garry's Mod gibi çok oyunculu oyun sunucuları, oyuncuların sunucu listelerinde (server browser) sunucuyu bulabilmesi ve anlık durumunu görebilmesi için Valve Source sorgu protokolünü (A2S) kullanır. Bu protokol üzerinden gelen paketler sunucu adını, haritayı, aktif oyuncu sayısını ve sunucu kurallarını sorgulayan istemcilere yanıt verir. Ancak bağlantısız (stateless) UDP yapısı nedeniyle A2S sorguları, oyun sunucularını hedef alan DDoS saldırılarının ve yansıtma (reflection/amplification) yöntemlerinin başında gelir.

A2S sorgu trafiği doğru yönetilmediğinde sunucunun işlemci (vCore) çekirdeklerini kilitleyebilir, oyun içi gecikmeyi (ping) yükseltebilir ve sunucunun listede zaman aşımına (timeout) uğrayarak kaybolmasına neden olabilir. Bu sorunu engellemenin temel yolu, sorgu paketlerini doğrudan oyun sürecine göndermek yerine ağ kenarında çalışan bir A2S önbellekleme (A2S Cache) katmanıyla yanıtlamaktır.

A2S protokolünün çalışma mantığı: A2S_INFO, A2S_PLAYER ve A2S_RULES paket anatomisi

Valve Source motoru tabanlı oyunlarda istemciler ve üçüncü taraf izleme platformları sunucuyla UDP üzerinden belirli başlık baytları taşıyan paketlerle haberleşir. Bu yapıda üç temel sorgu türü öne çıkar:

  1. A2S_INFO (0x54 / 'T'): İstemcinin sunucu hakkında temel meta verileri istediği pakettir. İstek paketi yalnızca 25 bayt civarındadır; sunucunun döndürdüğü yanıt ise sunucu adı, harita, oyun dizini, oyuncu sayısı, maksimum kapasite, bot sayısı, şifre durumu ve VAC koruması gibi alanları içerir (yaklaşık 200 ile 400 bayt).
  2. A2S_PLAYER (0x55 / 'U'): Sunucuda o an bağlı bulunan oyuncuların listesini, skorlarını ve bağlantı sürelerini talep eder. Sahte IP adresleriyle kötüye kullanımı önlemek amacıyla bu sorguda bir meydan okuma (challenge token) mekanizması kullanılır. Sunucu ilk isteğe 4 baytlık tek kullanımlık bir anahtar içeren 0x41 ('A') yanıtı döner; istemci aynı anahtarla ikinci bir paket yolladığında gerçek oyuncu listesi iletilir.
  3. A2S_RULES (0x56 / 'V'): Sunucuda aktif olan oyun değişkenlerini (mp_friendlyfire, sv_cheats, tickrate, mod ayarları) listeler. Tıpkı oyuncu sorgusunda olduğu gibi meydan okuma anahtarı gerektirir. Özellikle Rust gibi yüzlerce kural değişkeni barındıran oyunlarda bu liste tek bir UDP paketinin maksimum iletim birimini (MTU) aşar ve birden fazla parçaya (multi-packet) bölünerek gönderilir.

Aşağıdaki şema, istemcinin gönderdiği küçük bir sorgu paketinin sunucudan nasıl daha büyük bir veri paketiyle döndüğünü özetler:

İstemci (Browser / İzleme)                 Oyun Sunucusu (udp/27015)
        |                                             |
        |--- A2S_INFO İstek Paketi (~25 bayt) ------->|
        |    [0xFF 0xFF 0xFF 0xFF 'T' Source Engine]  | (İşlemci payload hazırlar)
        |                                             |
        |<-- A2S_INFO Yanıt Paketi (~300 bayt) -------|
             [0xFF 0xFF 0xFF 0xFF 'I' Sunucu, Harita, Oyuncular]

A2S Query Flood ve UDP Amplification saldırıları sunucuyu nasıl etkiler?

A2S sorgularının asimetrik yapısı saldırganlar için iki farklı istismar kapısı aralar: sunucu işlemcisini tüketmek (kaynak tüketimi) ve başka hedeflere trafik yansıtmak (yansıtma ve büyütme saldırısı).

1. İşlemci ve oyun döngüsü kilitlenmesi (CPU Exhaustion)

Bir oyun sunucusunun temel görevi fizik hesaplamalarını, oyuncu hareketlerini, mermi kayıtlarını ve çarpışma testlerini sabit bir döngüde (tickrate) çalıştırmaktır. Birçok oyun motorunda gelen UDP sorgu paketleri doğrudan oyun sürecinin soket dinleyicisine düşer.

Saniyede on binlerce sahte A2S sorgusu gönderildiğinde (A2S Query Flood), sunucu süreci her paketi ayrıştırmak, bellekten güncel oyuncu listesini ve kuralları okumak ve yanıt paketini diziselleştirip (serialize) ağ soketine yazmak zorunda kalır. Bu durum şu sonuçları doğurur:

  • Tickrate Düşüşü ve Mikro Takılmalar: İşlemci zamanı sorgu paketlerini yanıtlamaya ayrıldığından ana oyun döngüsü gecikir; oyuncular oyun içinde ışınlanma (rubberbanding), mermi gitmeme ve gecikme dalgalanması yaşar.
  • Sunucu Listesinde Kaybolma: Aşırı işlemci yükü altındaki sunucu yeni gelen sorgu paketlerini düşürmeye başlar. Steam sunucu tarayıcısı sunucuyu yanıt vermiyor (Timed Out) olarak işaretler ve sunucu listeden düşer.

2. UDP Yansıtma ve Büyütme (Reflection & Amplification)

UDP protokolünde kaynak IP doğrulaması bulunmadığından, saldırganlar sahte (spoofed) IP adresleri üreterek hedef kurbanın IP'sini kaynak olarak gösterir ve binlerce açık oyun sunucusuna A2S_INFO veya A2S_RULES paketleri yollar.

Sunucular gelen 25 baytlık isteğe karşılık kurbanın IP adresine 300 ile 1.500 bayt arasında yanıt gönderir. Bu durum 10 ile 60 kat arasında bir büyüme (amplification) çarpanı oluşturur. Sunucunuz doğrudan hedef alınmasa bile, saldırganlar tarafından yansıtıcı (reflector) olarak kullanıldığında giden hat kapasiteniz (upload bandwith) tamamen kilitlenebilir. Ağ katmanındaki bu etki hakkında daha ayrıntılı bilgi için DDoS saldırısı nedir rehberimizi inceleyebilirsiniz.

A2S önbellekleme (A2S Cache) mimarisi ve kenar ağda filtreleme

A2S saldırılarını ve sorgu yükünü engellemenin temel yöntemi, gelen sorguları doğrudan oyun sürecine ulaştırmadan önce ağ kenarında karşılamaktır. Bu yaklaşım A2S önbellekleme (A2S Cache) olarak adlandırılır.

İstemci Sorguları                  Kenar Ağ / Filtreleme (Anycast PoP)             Oyun Sunucusu (VDS)
       |                                           |                                      |
       |--- A2S_INFO (Binlerce sorgu/sn) --------->|                                      |
       |                                           | [Bellekten Otonom Yanıt]             | (Sorgu yükü binmez)
       |<-- Önbellekten Anlık Yanıt (<1 ms) -------|                                      | (Tickrate: Sabit)
       |                                           |                                      |
       |                                           |--- Arka Planda Durum Sorgusu ------->|
       |                                           |    (Birkaç saniyede bir kontrol)     |
       |                                           |<-- Güncel Harita / Oyuncu Sayısı ----|

Kenar önbellekleme katmanı şu adımlarla çalışır:

  1. Durum Öğrenme (State Polling): Ağ kenarındaki güvenlik katmanı, arka plandaki oyun sunucusuna belirli aralıklarla (örneğin birkaç saniyede bir) kontrollü bir sorgu göndererek güncel harita adını, oyuncu sayısını ve kural değişkenlerini hafızasına alır.
  2. Bellekten Otonom Yanıt (In-Memory Response): Dış dünyadan, tarayıcılardan veya botnet ağlarından gelen tüm A2S_INFO ve A2S_PLAYER sorguları doğrudan kenar ağ düğümünün belleğinden (RAM) yanıtlanır. Sorgu paketleri sunucunun bulunduğu fiziksel porta veya sanal makineye hiç iletilmez.
  3. Meydan Okuma ve Hız Sınırlama (Challenge Validation & Rate Limit): Çok parçalı veya derin kural sorgularında istemcinin IP adresi ve gönderdiği meydan okuma anahtarları kenar katmanda doğrulanır. Sahte IP ile yapılan yansıtma girişimleri doğrudan ağ girişinde düşürülür.
  4. İşlemcinin Korunması: Oyun sunucusunun işlemcisi saniyede on binlerce paketi hesaplamak zorunda kalmaz; tüm vCore gücü doğrudan oyun mantığına ayrılır.

Sunucu içi koruma ile ağ katmanı korumasının sınırları

A2S sorgu saldırılarına karşı sunucu içinde iptables, nftables veya ufw kuralları yazmak sık başvurulan ancak teknik sınırları olan bir yöntemdir. Aşağıdaki karşılaştırma tablosu iki yaklaşım arasındaki farkı özetler:

Koruma KriteriSunucu İçi Güvenlik Duvarı (iptables / UFW)Kenar Ağda A2S Önbelleği (Anycast Süzme)
Erişim hattı doygunluğuKoruyamaz; hat dolduğunda paketler sunucuya varmadan düşerKorur; trafik üst ağda ve dağıtık PoP noktalarında karşılanır
İşlemci (CPU) tüketimiKısmi; işletim sistemi çekirdeği paketleri incelerken CPU harcarYük binmez; paketler sunucuya ulaşmadan kenarda yanıtlanır
Sunucu listesinde görünürlükAgresif limit konulursa gerçek oyuncular da zaman aşımına uğrarSürekli görünür; önbellek sayesinde tarayıcıda ping ve durum anında döner
Büyütme (Amplification) engeliSunucudan dışarıya yanıt çıkmasını sınırlasa da gelen yükü kesemezSahte sorgular kenarda düşürülür, sunucu yansıtıcı olarak kullanılamaz
Gecikme etkisiKurallar arttıkça çekirdek paket işleme süresi uzayabilirAnycast mimarisi sayesinde 1 ms altı ek gecikmeyle çalışır

TRSHIELD altyapısında oyun protokolü koruması

TREAS altyapısında sunulan sanal ve fiziksel sunucular, şirketin kendi geliştirdiği anycast tabanlı DDoS koruması TRSHIELD ile korunur. TRSHIELD, standart web trafiğinin yanı sıra oyun sunucularının kullandığı özel UDP protokolleri için optimize edilmiş kurallar barındırır:

  • 12 Tbps Koruma Kapasitesi: Anycast ağ mimarisi sayesinde gelen yüksek hacimli UDP taşkınları hedef sunucuya ulaşmadan dağıtık filtreleme merkezlerinde emilir.
  • Counter-Strike 2 Profili: udp/27015 portunda CS2'ye özel paket doğrulama ve A2S önbellekleme desteği sunar. Bu profil, oyun içi paketleri meşru tutarken sahte A2S sorgularını kenar katmanda yanıtlar.
  • Source ve GoldSrc Desteği: CS:GO, Team Fortress 2, Garry's Mod ve CS 1.6 gibi motorlar için A2S doğrulaması ve isteğe bağlı A2S önbellekleme imkanı sağlar.
  • Rust Profili: 28015 oyun trafiği, 28017 A2S ve büyük RULES önbelleği, 28016 WebRCON ve 28082 Rust+ trafiğini tek bir güvenlik şablonunda ayrıştırarak korur.
  • Sürekli Geliştirme: TRSHIELD bilinen bütün saldırı vektörlerine karşı koruma sağlar ve sürekli geliştirilir. Hazır profili bulunmayan oyun veya uygulamalar için müşterinin talebine göre özel koruma geliştirmesi yapılır.

Yüksek tickrate ve yoğun oyuncu sayısına sahip rekabetçi oyun sunucuları için Counter-Strike 2 sunucu kiralama sayfalarımızda yer alan AMD Ryzen 9 9950X işlemcili Ekstrem VDS paketlerimizi inceleyebilir, oyun projelerinizde ayrılmış vCore performansından yararlanabilirsiniz.

Sık sorulan sorular

A2S sorgusu ile normal oyun trafiği arasındaki temel fark nedir?

Oyun içi hareket, vuruş ve etkileşim paketleri oyuncu ile sunucu arasında kurulan sürekli oturum üzerinden taşınır. A2S sorguları ise sunucu tarayıcısının veya izleme servislerinin harita, oyuncu sayısı ve kural gibi genel durum bilgilerini almak için gönderdiği durumsuz (stateless) UDP paketleridir. Bu sorgular oyuncu olmayan harici kaynaklar tarafından da serbestçe tetiklenebilir.

Sunucu içi bir güvenlik duvarı A2S DDoS saldırılarını tek başına engelleyebilir mi?

Hayır. Gelen A2S istekleri sunucunun ağ arayüzüne kadar ulaştığında, paketlerin ayrıştırılması ve güvenlik duvarı tablolarının yönetilmesi sunucunun işlemci kaynaklarını tüketmeye devam eder. Ayrıca sahte kaynak IP adresleriyle yapılan yansıtma ve büyütme saldırılarında hat kapasitesi dolduğunda sunucu içindeki kurallar gelen saldırı trafiğini azaltamaz. Trafiğin sunucuya varmadan önce anycast ağ katmanında süzülmesi gerekir.

A2S önbelleği (A2S cache) sunucudaki canlı oyuncu sayısının gecikmeli görünmesine yol açar mı?

A2S önbellekleme mekanizması sunucu verilerini çok kısa zaman aralıklarıyla (birkaç saniyelik mikro aralıklarla) günceller. Oyuncu sayısı, harita değişimi veya sunucu durumu tarayıcıda neredeyse anlık olarak güncellenmeye devam ederken, sunucu işlemcisi saniyede binlerce tekrarlayan sorgu paketini hesaplama yükünden korunur.

Yeni sistem yönetimi ve ağ rehberlerimizi arama sonuçlarında öncelikli görmek için:Google'da tercih edilen kaynaklara ekle (dış bağlantı)