MTA:SA sunucusunu DDoS saldırılarına karşı koruma

Multi Theft Auto: San Andreas için bir sunucu, bir DDoS saldırısı altında diğer bütün GTA çoklu oyuncu projelerinden farklı davranır, çünkü aynı anda üç ayrı ağ hizmeti sunar: 22003 UDP üzerinde oyun trafiği, 22005 TCP üzerinde tam donanımlı bir HTTP sunucusu ve 22126 UDP üzerinde ASE sorgusu. Bu üç hizmetin her birine ayrı ayrı saldırılabilir ve her biri farklı biçimde devre dışı kalır. Bu yazı önce ek maliyet olmadan kendiniz neleri güvene alabileceğinizi, ardından bu önlemlerin hattın fiziğinde nerede bittiğini, sonunda da MTA:SA için etkili bir DDoS korumasının sunucunun önündeki ağda neler yapması gerektiğini gösteriyor.

Saldırı şu anda sürüyorsa en önemli soru, üç hizmetten hangisinin vurulduğudur. Oyuncular bağlı kalıyor, ama katılırken artık kaynak indirmiyorsa 22005 üzerindeki HTTP sunucusu vuruluyordur. Bağlı oyuncular normal biçimde oynamayı sürdürürken sunucu tarayıcıdan kayboluyorsa 22126 üzerindeki ASE sorgusu vuruluyordur. Bütün bağlantılar aynı anda kopuyorsa hedef ya 22003'tür ya da hat doludur. Tüm bilgiler Debian 12, Debian 13, Ubuntu 22.04 LTS veya Ubuntu 24.04 LTS üzerinde çalışan bir MTA sunucusu içindir; komutlar root kullanıcısı için yazılmıştır, normal kullanıcı olarak başlarına sudo ekleyin.

MTA:SA sunucuları neden bu kadar sık DDoS saldırılarının hedefi olur

MTA:SA projeleri rahat hedeflerdir, çünkü adreslerini kendileri yayınlamak zorundadır. Bir sunucu, ancak ana sunucu listesine kaydolur ve ardından dışarıdan gelen sorguları yanıtlarsa sunucu tarayıcısında görünür. Liste IP adresi ile portu düz metin olarak içerir, yani bir saldırgan için önceden keşif yapmak gereksizdir.

Buna bir de sahnenin kendisi ekleniyor. Almanca konuşulan ülkelerdeki ve Brezilya'daki rol yapma sunucuları, drift sunucuları ve DayZ uyarlamaları aynı oyuncu kitlesi için yarışıyor ve ana oyun saatindeki bir kesinti mümkün olan en yüksek görünürlüğe sahip. Banlanmış bir oyuncu, dağılmış bir ekip ya da rakip bir proje, bir akşamı kullanılamaz hâle getirmek için ne beceriye ne de anlamlı bir paraya ihtiyaç duyuyor. Sahnede booter ya da stresser denilen kiralanabilir saldırı hizmetleri, ayda birkaç euroya tam olarak iki sonuç satıyor: MTA sunucusunu dakikalar boyunca çevrimdışı almak ya da onu lag sıçramalarıyla oynanamaz hâle getirmek. Bir DDoS saldırısının teknik olarak ne olduğunu ve hangi saldırı türlerinin bulunduğunu DDoS saldırısı nedir? yazısı anlatıyor.

Teknik olarak MTA:SA, saldırganların işini diğer çoklu oyuncu modifikasyonlarına göre iki noktada kolaylaştırıyor. Birincisi, sorgu kendine ait bir UDP portunda duruyor ve tek bir bayta karşılık birkaç kilobayt büyüklüğünde bir yanıt gönderiyor. İkincisi, her MTA sunucusuna, çalışan bütün kaynakların istemci tarafındaki dosyalarını dağıtan bir HTTP sunucusu ait ve bunu hiçbir oturum açma olmadan, isteyen herkese yapıyor.

Asıl mesele olan portlar

Bir MTA:SA sunucusu tam olarak üç porta ihtiyaç duyar: oyun için 22003 UDP, dahili HTTP sunucusu için 22005 TCP ve ASE sorgusu için 22126 UDP. Üçüncü port serbestçe seçilebilen bir ayar değildir, oyun portu artı 123'ten sabit biçimde türer. serverport değerini 22010 yapan kişi sorguyu 22133'te alır.

İki ayrıntı, birlikte gelen mtaserver.conf dosyasında tam olarak böyle durur ve düzenli olarak gözden kaçar. httpport ile serverport aynı sayısal değeri taşıyabilir, çünkü biri TCP, diğeri UDP portudur. Ve serverip değeri auto üzerindedir, orada da kalmalıdır: Sabit girilen bir değer ASE soketini tam olarak bu adrese bağlar ve adres değiştiği anda liste kaydını bozar.

ASE sorgu protokolü ve neden bir amplifikasyon aracı olduğu

ASE (All-Seeing Eye) saf bir UDP sorgu protokolüdür: Paketin ilk baytı yanıtı belirler, bir bağlantı kurulumu yoktur. MTA sunucusu beş sorgu tanır ve bunları 22126 üzerinde yanıtlar:

• s tam ASE sorgusudur. Yanıt EYE1 ile başlar ve sunucu adını, oyun türünü, harita adını, sürümü, parola durumunu, oyuncu sayısını, setRuleValue ile ayarlanmış bütün kuralların tam listesini ve ardından bağlı her oyuncuyu adı, puanı ve pingiyle içerir. Bu yanıtın bir boyut sınırı yoktur.
• b ve r, sunucu tarayıcısı için daha yalın sorgulardır. Yanıt EYE2 ile başlar ve parçalanmayı önlemek için kaynak kodda 1.340 baytta kesilir.
• x kısaltılmış bir durum bildirimi verir, v ise yalnızca ASE sürüm kimliğini.

Sorun buradan çıkar. Bir istek tek bir veri yükü baytından, yani kablo üzerinde 29 bayttan oluşur (20 bayt IP başlığı, 8 bayt UDP başlığı, 1 bayt veri yükü). 1.400 bayt veri yükü taşıyan bir yanıt ise kablo üzerinde 1.428 bayttır. Oran yaklaşık 49 kattır ve UDP bir bağlantı kurulumu tanımadığı için gönderen adresi sahte olabilir. Yani bir saldırgan, oyununuza hiç girmeden sunucunuzu üçüncü bir hedefe karşı amplifikasyon aracı olarak kullanabilir. Tam sorguda faktör, oyuncu sayısıyla ve gamemode'unuzun ayarladığı her kuralla birlikte büyür.

MTA buna karşı, bilinmesi gereken iki yerleşik fren getirir, çünkü bunlar bazı flood'ların neden etkili olduğunu, bazılarının neden olmadığını açıklar. Sunucu kaynak adres başına altı saniyede en fazla beş sorgu yanıtlar ve adresi ardından yedi saniye boyunca yok sayar. Ayrıca yanıtları her istekte yeniden oluşturmak yerine on saniye boyunca önbellekte tutar. Kaynak adres başına yapılan sayım ise, listede aynı anda 100'den fazla farklı gönderen adresi durduğu anda tamamen atlanır. Bir botnetten gelen ya da sahte göndereni olan dağıtık bir flood'da tam olarak bu durum normaldir ve bu yüzden yerleşik fren ciddi bir saldırıya karşı yardımcı olmaz.

Para harcamadan önce kendiniz neler yapabilirsiniz

Bu bölüm en uzunu ve bu bilinçli bir tercih. Düzgün yapılandırılmış bir MTA sunucusu, nerede barındırıldığından bağımsız olarak küçük ve orta ölçekli saldırılara kendi gücüyle dayanır.

1. Envanter: sunucuda ne dinliyor?

Önce sunucunuzun dışarıya ne sunduğuna bakın. Tahmin etmeyin, bakın:

ss -lntup

MTA sürecinden üç satır beklenir: UDP üzerinde 0.0.0.0:22003, TCP üzerinde 0.0.0.0:22005 ve UDP üzerinde 0.0.0.0:22126. Orada ek olarak 0.0.0.0:3306 üzerinde bir veritabanı, bir web sunucusu ya da unutulmuş bir ses hizmeti görünüyorsa bunun kapatılması gerekir. Saldırganın bakışını, dışarıdan yapılan bir port taraması verir:

nmap -Pn -sU -p 22003,22126 SUNUCU.IP.ADRESİNİZ
nmap -Pn -p 22005 SUNUCU.IP.ADRESİNİZ

Sunucu bunun için kendi konsol komutunu da beraberinde getirir. Sunucu konsolunda openports komutu, üç portun da dışarıdan erişilebilir olup olmadığını denetler.

2. Yalnızca MTA'nın gerçekten ihtiyaç duyduğu üç portu açık bırakma

UFW ile taşınabilir bir başlangıç yapılandırması şöyle görünür, hem de tam bu sırayla, ki kendinizi dışarıda bırakmayın:

ufw allow 22/tcp comment 'SSH'
ufw allow 22003/udp comment 'MTA oyun'
ufw allow 22005/tcp comment 'MTA HTTP'
ufw allow 22126/udp comment 'MTA ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Kurtarma yolu da dâhil tam rehber UFW güvenlik duvarı kurma yazısında. KernelHost'un KVM root sunucularında ve dedicated sunucularında, hat doyuma ulaşmış olsa bile acil durumda müşteri panelindeki VNC konsolu üzerinden sisteme ulaşırsınız.

Veritabanı açık ağa ait değildir. ss -lntp | grep 3306 komutu bir 0.0.0.0:3306 gösteriyorsa, /etc/mysql/mariadb.conf.d/50-server.cnf dosyasında bind-address = 127.0.0.1 satırını ayarlayın ve hizmeti yeniden başlatın.

3. Sunucu listesinden düşmeden ASE portunu sınırlama

SA-MP'den farklı olarak MTA:SA'da sorgu kendine ait bir portta durur, yani onu oyun işletiminden bağımsız olarak sınırlayabilirsiniz. Bu mimarinin en büyük pratik avantajı budur: 22126 üzerindeki bir kural tek bir oyuncuyu bile dışarı atmaz.

Kural seti UFW'nin yoluna girmesin diye, nftables ile kendine ait bir tabloda:

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

İlk kural her bir kaynak adresi, ikincisi portun tamamını sınırlar. İkisi birlikte önemlidir: Yalnızca adres başına sınırlama yapılırsa dağıtık bir flood, çok sayıda tek kaynak arasındaki boşluktan geçer. Değerler dar seçilmiştir ve bu burada savunulabilir, çünkü gerçek bir sunucu tarayıcısı sunucunuzu yalnızca birkaç saniyede bir sorgular. iptables ile aynı şeyi hashlimit modülü sağlar:

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

Portu tamamen kapatma denemesi bir denge kararıdır, gizli bir püf noktası değil: ASE olmadan sunucunuz sunucu tarayıcısından ve böylece organik oyuncu akışından kaybolur. Buna rağmen istiyorsanız <ase>0</ase> yetmez. Kaynak kodda port açılışı, internet modu ile LAN modunun mantıksal VEYA bağlantısına bağlıdır; yani <donotbroadcastlan>0</donotbroadcastlan> yazdığı sürece soket <ase>0</ase> ile de açık kalır. Portu gerçekten kapatmak isteyen kişi ikisini birlikte ayarlar:

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

Büyüyen bir proje için daha dürüst yol şudur: portu açık bırakmak, hızı sınırlamak ve amplifikasyon etkisini, gamemode'unuzun setRuleValue ile gereksiz kural yayınlamaması sayesinde küçük tutmak. Her kural tam sorguda yer alır ve yanıtı büyütür.

4. Dahili HTTP sunucusunu rahatlatma

22005 üzerindeki HTTP sunucusu MTA:SA'da kendine ait bir saldırı yüzeyidir, çünkü katılan her oyuncu çalışan bütün kaynakların istemci tarafındaki dosyalarının tamamını oradan indirir. Kendi modellerine sahip bir rol yapma projesinde bu, yüzlerce ayrı dosyaya dağılmış biçimde hızla birkaç yüz megabayt eder. Yerleşik sunucu bilinçli olarak yalın tutulmuştur: sıkıştırma yok, sabit bir iş parçacığı kotası var. Gerçek oyuncuların dakikalar boyunca yükleme ekranında kalması için birkaç düzine eş zamanlı çağrı yeter.

En etkili önlem, indirmeleri tamamen oyun sunucusundan çıkarmaktır. MTA dağıtılacak dosyaları bunun için kendisi hazır tutar: mods/deathmatch/resource-cache/http-client-files altında. Bu klasörü nginx ya da lighttpd üzerinden yayınlar ve adresi mtaserver.conf dosyasına yazarsınız:

<httpdownloadurl>http://cdn.alan-adiniz.tld/mta</httpdownloadurl>

Bu, tek seferde iki şey sağlar. İndirmeler bunun için yapılmış bir web sunucusu üzerinden gider ve artık oyun sunucunuzun adresi üzerinden gitmez. Web sunucusu başka bir makinedeyse ya da bir içerik dağıtım ağının arkasındaysa, indirmelere yapılan bir flood artık oyun işletimini vurmaz. Önemli olan şu: Dış adres yanlışsa ya da erişilebilir değilse MTA sessizce dahili sunucuya geri döner.

Dahili sunucu kullanımda kalıyorsa onun kendi sınırlarından yararlanın. mtaserver.conf dosyasında:

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

httpmaxconnectionsperclient, istemci başına eş zamanlı bağlantıları izin verilen 1 ila 8 aralığında 5 ile sınırlar. httpdosthreshold, tek bir IP adresinin kısa süre içinde kaç bağlantı kurabileceğini sınırlar, öntanımlı değer 20'dir. http_dos_exclude tek tek adresleri bunun dışında tutar, örneğin kendi durum sayfanızı. httpthreadcount iş parçacığı sayısını belirler, öntanımlı değer 1 ila 20 aralığında 8'dir. Daha yüksek bir değer çok sayıda küçük dosyada yardımcı olur, ama oyun işletiminden eksilen işlem zamanına mal olur.

Ayrıca aynı port üzerinde başka nelerin yayınlandığını düşünün. webadmin ve resourcebrowser kaynakları, birlikte gelen yapılandırmada başlatılmıştır ve 22005 üzerinden tarayıcıda erişilebilir. Bir yönetim arayüzü korumasız biçimde açık ağa ait değildir: acl.xml dosyasında düzgün yetkiler verin, uzun ve rastgele parolası olan kendi hesabınızı oluşturun ve ihtiyacınız yoksa kaynağı durdurun.

5. mtaserver.conf içindeki yerleşik sınırlardan yararlanma

MTA, projelerin çoğunun kullandığından daha fazla koruma sınırı getirir. Bir kısmı kaynak kodda sabittir, bir kısmı mtaserver.conf dosyasında durur. Bu tablo, bir saldırıda rol oynayanları topluyor:

Üç ayar bilinçli bir karar hak eder. maxplayers 32'dedir ve gerçeğe uymalıdır: Her ek slot tam sorguyu büyütür ve bir saldırganın doldurabileceği bağlantı sayısını artırır. bandwidth_reduction medium üzerindedir; maximum değeri giden yükü belirgin biçimde düşürür, ama senkronizasyon doğruluğuna mal olur. Ve <password></password>, liste kaydı yerinde kalırken sunucunuzu hiç zahmetsizce kapalı bir çevreye dönüştürür: süren bir katılım flood'unda en hızlı acil frendir.

6. Katılım flood'u ile olay flood'unu birbirinden ayırma

İki saldırı kalıbı hatta değil, oyun mantığına yöneliktir ve düzenli olarak birbirine karıştırılır.

Bir katılım flood'u, bütün slotlar dolana ya da sunucu bağlantı kurmaya yetişemez hâle gelene kadar hızlı bir sırayla gerçek bağlantılar kurar. MTA bunu kendiliğinden 30 saniyede kaynak adres başına dört bağlantıyla sınırlar ve adresi ardından 30 saniye boyunca yok sayar. Frenin o anda ne yaptığını debugjoinflood konsol komutu gösterir. Sınır adres başına işler, bin adresli bir botnet onun yanından geçer. Buna karşı bir sunucu parolası, gamemode içinde bir beyaz liste ve 22003 üzerinde bir hız sınırlaması yardımcı olur.

Bir olay flood'u ise hâlihazırda bağlı olan oyunculardan gelir: Değiştirilmiş bir istemci, sunucu işlem zamanını artık karşılayamayana kadar triggerServerEvent çağrısını bir döngü içinde gönderir. MTA bunun için fabrika ayarında oyuncu ve saniye başına 100 olay tanır ve bunun üzerindekileri olay flood'larına dair bir bildirimle reddeder. Gamemode'unuz çok sayıda küçük olay kullanıyorsa, değeri düşürmeden önce kontrol edin: Fazla dar ayarlandığında kendi oyuncularınızı dışarı atar.

Bundan bağımsız olarak sunucu tarafında her yerde geçerli olan aynı kural işler: İstemcinin birlikte gönderdiği değerlere asla güvenmeyin, oyuncuyu olayın göndereninden belirleyin ve bir veritabanı sorgusu başlatan her şeyi sınırlayın. Bir sorgu başlatan, denetlenmemiş tek bir olay, bir sunucuyu hiçbir ağ saldırısı olmadan durdurmaya yeter.

7. Sunucu listesi, IP adresi ve başka nelerin ele verdiği

IP adresinizi gizli tutamazsınız. Bir kez bağlanmış her oyuncu onu bilir ve ana sunucu listesindeki kayıt onu zaten yayınlar. Önüne bir alan adı koymak yardımcı olmaz: İstemci adı bir kez çözer ve ardından doğrudan adresle konuşur.

Bunun yerine adresinizi başka nelerin ele verdiğini kontrol edin. MTA projelerinde tipik sızıntılar şunlardır: DNS'teki eski A ve AAAA kayıtları, aynı makinedeki proje sayfası, ASE sorgusunu herkese açık biçimde okuyan durum göstergeli bir Discord botu, eski ana bilgisayar adlarını taşıyan TLS sertifikaları ve ilk dönemden kalma forum gönderileri. Bundan, birçok projenin geç öğrendiği bir kural çıkar: Korumalı bir adrese taşınırken eski adresi aynı anda değiştirin. Eski adres yerinde kalırsa her tarayıcı veritabanında durur ve saldırı korumanın yanından geçer.

mtaserver.conf dosyasındaki iki kayıt görünürlüğü doğrudan etkiler. <serverip>auto</serverip>, neden olmaması gerektiğini tam olarak bilmiyorsanız auto üzerinde kalır. Ve <owner_email_address> doldurulmalıdır: Kayıt eksikse ya da yanlışsa bu, ana sunucu listesindeki görünürlüğü olumsuz etkileyebilir.

8. Ciddi durumda elinizde veri olması için log tutma

En önemli adım, neredeyse hiç kimsenin önceden atmadığı adımdır: her şey normal çalışırken bir karşılaştırma temeli oluşturmak. Normal değer olmadan bir olaydan sonra saniyede 40.000 paketin çok mu olduğunu yoksa sadece cuma akşamı mı olduğunu söyleyemezsiniz. apt-get install -y vnstat sysstat ile ölçüm kalıcı olarak arka planda çalışır.

Bir olay sırasında önce üç portu birbirinden ayırırsınız. Şu dört komut yeter:

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

Değerlendirme göründüğünden daha basittir. CPU yükü düşükken arabellek hataları artıyorsa, sürecin işleyebileceğinden daha fazla trafik size ulaşıyordur. Trafik normal görünürken bir çekirdek sonuna kadar çalışıyorsa sorun ağda değil, gamemode'dadır. 22126 üzerindeki paket kaydı tek bir bayt veri yükü taşıyan çok sayıda paket gösteriyorsa bu bir ASE flood'udur. 22005 üzerindeki açık bağlantı sayısı kalıcı olarak dört haneli aralıktaysa HTTP sunucusu vuruluyordur. tcpdump için şu geçerlidir: her zaman -c ile sınırlayın; tam yük altında alınan bir paket kaydı, hâlihazırda aşırı yüklü bir sunucuya ek yük getirir. Değerleri ayrıntıda nasıl değerlendireceğinizi DDoS saldırısını tanıma yazısı anlatıyor.

Sunucu logunun kendisi logs/server.log altında, betik logu ise logs/scripts.log altında durur. İki yol da mtaserver.conf dosyasında yer alır ve başka bir yere alınabilir.

Bu önlemler nerede biter

Şimdi hiçbir yapılandırma dosyasının çözemeyeceği bölüm. Buraya kadarki tüm önlemler sizin sunucunuzda, yani hattın sonunda çalışır. Bir güvenlik duvarı kuralı, kabloyu çoktan geçmiş bir paket hakkında karar verir. Paketi düşürebilirsiniz, ama gönderilmemiş hâle getiremezsiniz.

Bir kez birlikte hesaplayalım. Tipik bir oyun sunucusu 1 Gbit/s'lik bir hatta bağlıdır, bu saniyede 125 megabayt eder ve 64 baytlık paketlerde saniyede yaklaşık 1,49 milyon paket demektir. Bu mertebedeki oyun sunucusu projelerine yapılan saldırılar genellikle 5 ila 50 Gbit/s arasındadır, yani hattınızın beş ila elli katı. O zaman arkadaki nftables kuralınızın iyi olup olmadığı artık bir rol oynamaz, çünkü oyuncularınızın paketleri daha öncesinde geçemez.

Paket hızı bu sırada sıklıkla bant genişliğinden önce vurur. Normal bir sunucu kernel'i, CPU ve ağ kartına bağlı olarak düşürmeye başlamadan önce saniyede birkaç yüz bin paket işler. Yani hattınızı üçte birine bile doldurmayan bir saldırı, düşürme işlemi için işlem zamanı harcandığı için sunucunuzu felç edebilir. İşletmeciler bunu “doluluk hiç de yüksek değildi, buna rağmen her şey gitti” biçiminde yaşar.

MTA:SA'da üçüncü bir sınır ekleniyor ve o en erken devreye giriyor. Sunucu ağ portlarını tek bir iş akışı içinde okur. 22126 üzerindeki bir sorgu flood'u bu akışı öyle meşgul eder ki, gerçek oyuncuların senkronizasyon paketleri hat dolmadan çok önce alma arabelleğinde ölür. Süreç bu sırada çökmez, yalnızca yavaşlar ve oyuncular lastik bandı etkisi görür. Aynısı HTTP sunucusu için de geçerlidir: İşlem zamanını oyun işletimiyle paylaşır.

Gerçekte hangi mertebelerin görüldüğünü sınıflandırmak için: KernelHost sunucularında bunlar arasında bir ses sunucusuna saniyede 41,5 milyondan fazla pakette 473,4 Gbit/s'nin üzerinde bir saldırı ve bir oyun sunucusuna saniyede 8,7 milyondan fazla pakette 112,2 Gbit/s'nin üzerinde bir UDP flood'u filtrelendi. İlk durum, 1 Gbit/s'lik bir hattın alabileceği bant genişliğinin yaklaşık 473 katı ve paket hızının yaklaşık 28 katıdır. Bunun için yerel bir ayar yoktur. Hacimsel saldırılar sunucunun önündeki ağda son bulmalıdır.

KernelHost buna karşı ne koyuyor

Her sunucuda dâhil olan sürekli koruma

KernelHost'taki her sunucu, kalıcı olarak etkin ve iki kademeli bir filtrelemenin arkasında durur:

• 1. kademe: küresel scrubbing ağında 17 Tbps mitigasyon kapasitesi. Hacimsel saldırılar, Frankfurt am Main'deki veri merkezine hiç ulaşmadan önce kaynaklarına yakın bir noktada temizlenir.
• 2. kademe: doğrudan yerinde, Frankfurt am Main'de 3,2 Tbps ile Arbor gerçek zamanlı filtreleme. Sunucunun hemen önünde protokole özgü kalıplar tanınır ve paket paket düşürülür.

Üç özellik belirleyicidir. Koruma kalıcı olarak etkindir, yani sunucunuzun çevrimdışı olduğu bir tanıma aşaması yoktur. Null routing kullanılmaz: Saldırılan adres ağda kalır, yalnızca zararlı paketler düşürülür, gerçek oyuncuların bağlantıları ise çalışmayı sürdürür. Ve ek bir ücreti yoktur; teslimden itibaren KVM root sunucusundan oyun sunucusuna ve dedicated sunucuya kadar her sunucu paketinde bulunur. Filtreleme her TCP ya da UDP portunda Layer 3, 4 ve 7 üzerinde yapılır, yani aynı anda 22003 UDP, 22005 TCP ve 22126 UDP üzerinde. Bu, Almanya'nın Frankfurt am Main şehrindeki maincubes veri merkezinde işletilir. Hangi oyunların ve protokollerin kendi profillerine sahip olduğunu Gerçek zamanlı oyun sunucusu DDoS koruması yazısı gösteriyor.

Kalıcı olarak ateş altındaki projeler için Advanced DDoS Protection

Bazı projeler ara sıra değil, haftalar boyunca hedefli biçimde vurulur. Bu durum için ayda 50,00 EUR'dan başlayan, PrePaid ve asgari süresi olmayan Advanced DDoS Protection var. Fark, daha fazla kapasitede değil, kontrolde:

• Frankfurt çekirdek ağından verilen dedicated bir koruma IP'si. Sunucunuz KernelHost ağı içinde bu adrese geçirilir, siz kendi tarafınızda hiçbir şeyi değiştirmezsiniz.
• Müşteri panelinde kendiniz yönetebileceğiniz, port ve protokol başına koruma kuralları. MTA:SA'da mesele tam olarak budur: Birbirinden çok farklı üç hizmeti aynı kefeye koymak yerine 22003 UDP, 22005 TCP ve 22126 UDP için ayrı kurallar ayarlarsınız.
• Değişiklikler gerçek zamanlı etki eder, talep açmadan ve bekleme süresi olmadan. Yani süren bir saldırının ortasında ince ayar yapabilirsiniz.
• Oyuna uygun bir koruma profili. Multi Theft Auto kendi profili olarak mevcuttur; aynı şekilde web sunucuları, ses sunucuları ve aynı koruma adresinin arkasına sığan kendi TCP veya UDP uygulamalarınız da.

İki kademenin karşılaştırması

MTA:SA projelerinin çoğu için, dâhil olan sürekli koruma düzgün bir sunucu yapılandırmasıyla birlikte yeterlidir. Advanced DDoS Protection ise birinin meseleyi kişisel almasına verilen yanıttır.

Sık yapılan hatalar ve çözümleri

“22126 portunu kapattım, sunucu buna rağmen hiçbir listede görünmüyor, ama sorgular gelmeye devam ediyor”: O hâlde soket hâlâ açıktır. <donotbroadcastlan>0</donotbroadcastlan> ayarlıyken <ase>0</ase> tek başına portu kapatmaz. ss -lnup | grep 22126 komutuyla gerçekten hiçbir şeyin dinlemediğini kontrol edin.

“Oyuncular yükleme ekranında kalıyor, oyunun kendisi normal çalışıyor”: Bu, 22003 üzerine bir saldırı değil, 22005 üzerindeki HTTP sunucusunun sınırına gelmesidir. İndirmeleri httpdownloadurl üzerinden dışarıya taşıyın ve httpmaxconnectionsperclient ile httpthreadcount değerlerini kontrol edin.

“Sunucu tarayıcıdan kayboldu, üzerindeki oyuncular bir şey fark etmiyor”: O hâlde yalnızca 22126 vuruluyor. Bağlı oyuncular için bu sonuçsuzdur, yeni oyuncu akışı için değil. Bu tek portta bir hız sınırlaması doğru yanıttır, oyun portundaki bir sınırlama değil.

“IP adresini değiştirdik ve iki saat sonra yine çevrimdışıydık”: Saldırgan yeni adresi eskisiyle aynı kaynaktan aldı; çoğunlukla liste kaydından, durum sorgusu yapan bir Discord botundan ya da eski bir DNS kaydından. Adres değişikliği zaman kazandırır, bir çözüm değildir.

“22003 üzerinde adres başına saniyede 20 paketlik bir hız sınırı koyduk”: Bu fazla dardır. Etkin senkronizasyonda tek bir oyuncu bile bunun üzerindedir ve aynı NAT adresinin arkasındaki birden fazla oyuncu aynı kotayı paylaşır. Böylece kendi oyuncularınızı dışarı atarsınız. 22126 üzerinde ise dar değerler sorun yaratmaz.

“Güvenlik duvarıyla kendimizi dışarıda bıraktık”: Yeniden başlatmak yardımcı olmaz, çünkü UFW kurallarını açılışta geri yükler. KernelHost'ta müşteri panelindeki VNC konsolunu açıp orada ufw disable komutunu çalıştırırsınız. VNC konsolu, konuk sistemin ağından bağımsız çalışır.

“Önceki sağlayıcım IP adresimi kapattı”: Bu null routing'dir. Sağlayıcı bununla kendi ağını korur; sizin için sonuç başarılı bir saldırıyla aynıdır, genellikle sonrasında saatlerce de sürer. Tereddüt ederseniz filtreleme mi yapıldığını yoksa null routing mi uygulandığını sorun. Yanıt, erişilebilirliğiniz hakkında herhangi bir donanım bilgisinden daha çok şey belirler.

“Saldırının geçmesini öylece bekliyoruz”: Etkili olan saldırılar yinelenir. Saat dilimiyle birlikte zamanı, süreyi, zirve değerleri ve vurulan portu belgeleyin. Filtrelemenin hedefli biçimde yeniden ayarlanması için bir destek talebinin de tam olarak bu bilgilere ihtiyacı vardır.

Kısaca özetle

• Bir MTA:SA sunucusu tam olarak üç porta ihtiyaç duyar: oyun için 22003 UDP, dahili HTTP sunucusu için 22005 TCP ve ASE sorgusu için 22126 UDP. Üçüncüsü oyun portu artı 123'ten sabit biçimde türer.
• ASE sorgusu kendine ait bir portta durur ve bu yüzden tek bir oyuncuyu dışarıda bırakmadan sınırlanabilir. Oyun ile sorgunun aynı portu paylaştığı SA-MP'ye göre en önemli fark budur.
• 22126 üzerindeki tek bir istek baytı, birkaç kilobayta kadar çıkan bir yanıt üretir ve gönderen adresi sahte olabilir. Frensiz bir ASE portu böylece aynı anda hem hedef hem amplifikasyon aracıdır.
• MTA'nın yerleşik frenleri kaynak adres başına işler: altı saniyede beş sorgu, 30 saniyede dört katılım. Aynı anda 100'den fazla kaynak adres olduğunda sorgu sayımı atlanır, yani dağıtık bir flood içinden geçer.
• 22005 üzerindeki dahili HTTP sunucusu kendine ait bir saldırı yüzeyidir. İndirmeleri httpdownloadurl üzerinden dış bir web sunucusuna taşıyan kişi, onları oyun işletiminin dışına çıkarır.
• Sunucuda çalışan her şey yalnızca küçük saldırılar hakkında karar verir. 1 Gbit/s'te saniyede yaklaşık 1,49 milyon pakette iş biter, kurallarınızın niteliğinden bağımsız olarak.
• KernelHost'taki iki kademeli sürekli koruma her sunucu paketinde ek ücret olmadan dâhildir ve null routing kullanmadan çalışır. Kuralları port başına kendisi yönetmek isteyen kişi buna ayda 50,00 EUR'dan başlayan Advanced DDoS Protection'ı ekler.

Projeniz hâlihazırda KernelHost'ta çalışıyorsa filtreleme kalıcı olarak etkindir, hiçbir şeyi açmanız gerekmez. Buna rağmen dikkat çekici bir durum fark ederseniz, adresiniz için kuralların yeniden ayarlanması amacıyla zaman aralığını, portu ve gözlemlediğiniz davranışı içeren bir destek talebi açın. Süren bir saldırı sırasında bize ek olarak +43 650 8209883 numarasındaki WhatsApp acil durum sohbeti üzerinden ulaşabilirsiniz. Hâlâ başka bir yerde barındırıyor ve düzenli olarak vuruluyorsanız, Frankfurt am Main'e taşınmak daha kısa çözümdür: Acil durum için diğer adımlar Ağır bir DDoS saldırısı: ne yapmalı? yazısında.