Team Fortress 2: TF2 sunucusunu DDoS saldırılarına karşı koruma
Bir Team Fortress 2 sunucusunun gerçekten hangi portlara ihtiyaç duyduğu, sunucu tarayıcısından düşmeden A2S sorgularını, parçalanmış paketleri, RCON'u ve hızları nasıl sınırlayacağınız ve hangi saldırı büyüklüğünden sonra yalnızca sunucunun önündeki ağda yapılan filtrelemenin işe yaradığı.
Akşam turun tam ortasında bütün oyuncularını aynı anda kaybeden ve ardından dakikalar boyunca sunucu tarayıcısından kaybolan bir Team Fortress 2 topluluk sunucusunun donanım sorunu yaşaması nadirdir. Çoğu durumda 27015/UDP portuna bir saldırı yapılıyordur. Bu yazı bir TF2 sunucusunu DDoS saldırılarına karşı nasıl koruyacağınızı gösteriyor: önce önümüzdeki on dakika içinde ek maliyet olmadan kendiniz neler yapabileceğinizi, ardından bu önlemlerin fiziksel olarak bittiği noktayı, sonunda da öncesinde ağda neler olması gerektiğini.
Tüm bilgiler Debian 12, Debian 13, Ubuntu 22.04 LTS veya Ubuntu 24.04 LTS üzerinde SteamCMD ile kurulmuş bir Source dedicated sunucusu (srcds_run -game tf) içindir. Komutlar root kullanıcısı için yazılmıştır, normal kullanıcı olarak başlarına sudo ekleyin. Saldırı şu anda sürüyorsa: Önce hiçbir şeyi değiştirmeyin ve sunucuyu yeniden başlatmayın, 9. bölümdeki ölçüm değerlerini kaydedin. Saldırıdan sonra bu değerler kaybolur.
Team Fortress 2 sunucuları neden DDoS koruması gerektirir
Team Fortress 2, 2011'den bu yana ücretsiz oynanabiliyor ve saldırı ekonomisini tam olarak bu kaydırıyor. Bir saldırganın sınırsız sayıda tek kullanımlık hesabı vardır, bunların hiçbiri için para ödemez ve bir yasaklamada hiçbir şeyi riske atmaz. Satın alınan bir oyunda paraya mal olan şey, burada bir dakikaya mal olur.
Buna, TF2'yi diğer oyunların çoğundan ayıran bir özellik ekleniyor: Temmuz 2016'daki “Meet Your Match” güncellemesinden bu yana, yeni oyuncuları otomatik olarak topluluk sunucularına dağıtan Quickplay yok. Yeni oyuncular Casual kipinde Valve sunucularına düşüyor. Topluluk sunucuları yalnızca sunucu tarayıcısı üzerinden bulunabilir. Bu listeden düşen kişi, sunucu süreci kusursuz çalışsa bile yeni oyuncular için pratikte artık var değildir. Bu yüzden sunucunuzu yalnızca listeden çıkaran bir saldırı, hedefine çoktan ulaşmıştır.
Tipik hedefler buna göre şunlardır: sabit oyuncuları olan, kalıcı çalışan topluluk sunucuları (günün her saatinde 2Fort, Trade, Jailbreak, Surf, Dodgeball, Mann vs. Machine), ETF2L, RGL ve ozfortress lig işletiminde sabit maç saati olan lig sunucuları ve az önce birini yasaklamış olan işletmecilerin sunucuları. Tetikleyen neden neredeyse hiç teknik değildir. Bir DDoS saldırısının aslında ne olduğunu DDoS saldırısı nedir? yazısı anlatıyor.
Bir TF2 sunucusunda asıl mesele olan portlar
Bir TF2 sunucusu dışarıya tam olarak tek bir porta ihtiyaç duyar: 27015/UDP. Geri kalan her şey ya kapatılabilir, ya sınırlanmaya aittir ya da zaten yalnızca giden yönde çalışır. Bu tablo, aşağıdaki her güvenlik duvarı kuralının temelidir:
| Port | Protokol | Ne için | Dışarıdan erişilebilir mi? |
|---|---|---|---|
| 27015 | UDP | Oyun trafiği ve A2S sunucu sorgusu aynı port üzerinde, -port ile belirlenir |
evet, zorunlu |
| 27015 | TCP | RCON, sunucunun rcon_password üzerinden uzaktan yönetimi |
hayır, yalnızca kendi adresinizden |
| 27020 | UDP | SourceTV (STV), tv_port ile belirlenir, -nohltv ile kapatılabilir |
yalnızca gerçekten yayın yapıyorsanız |
| 27005 | UDP | Oyuncunun giden yönde kullandığı istemci portu (+clientport) |
hayır, sunucuda izin gerekmez |
| 26900 ve yukarısı | UDP | Sunucu sürecinin Steam portu (-steamport), her ek örnekte bir artar |
hayır, yalnızca Steam'e giden yönde |
| 80 ve 443 | TCP | Haritalar ve içerikler için FastDL (sv_downloadurl), aynı ana makinede duruyorsa |
yalnızca indirme orada duruyorsa |
Aynı makinede birden fazla örnek olduğunda numaralar artar: oyun için 27016, 27017 ve devamı, SourceTV için 27021 ve 27022. Yapılandırma dosyası tf/cfg/server.cfg yolundadır ve her harita değişiminde yeniden okunur.
Paylaşılan 27015 portu neden en hassas noktadır
TF2'de oyun trafiği ve sunucu sorgusu aynı UDP portunu paylaşır, ayrı bir sorgu portu yoktur. Bir A2S_INFO isteği bu arada tam olarak 25 bayt uzunluğundadır: dört bayt FF FF FF FF, bir bayt 0x54 ve sonunda bir sıfır bulunan, 20 bayt uzunluğundaki “Source Engine Query” karakter dizisi. Sunucu adı, harita, oyuncu sayısı ve etiketleri içeren yanıt ise bunun katlarıdır. ABD kurumu CISA, TA14-017A uyarısında Steam protokolünün amplifikasyon faktörünü 5,5 olarak veriyor.
UDP bir bağlantı kurulumu tanımadığı ve gönderen adresleri sahte olabildiği için bu, yıllarca açık bir amplifikasyon boşluğuydu: Bir saldırgan, kurbanının adresini gönderen olarak kullanarak yabancı Source sunucularını sorguluyordu ve sunucular yanıtlarını kurbana gönderiyordu. A2S_PLAYER ve A2S_RULES her zaman önceden alınmış bir challenge istiyordu, A2S_INFO ise istemiyordu. Valve ancak Aralık 2020'de A2S_INFO için de bir challenge ekledi: Sunucu, yanıt yerine bir S2C_CHALLENGE geri gönderebilir; sorgulayanın bunu yinelemesi gerekir ve böylece gönderen adresini sahte kullanmadığını kanıtlar.
Bu, yansıtmayı hafifletir, ama sıkıntıyı bitirmez. Her sorgu paketi size ulaşmaya devam eder ve yanıtlanmadan ya da düşürülmeden önce işlem zamanı tüketir. Sunucunuzu doğrudan flood'layan bir saldırganın ise zaten amplifikasyona ihtiyacı yoktur.
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 TF2 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: ne dinliyor ve hangi başlatma satırıyla
Tek bir kural yazmadan önce sunucunuzun dışarıya ne sunduğuna bakın. Tahmin etmeyin, bakın:
ss -lntup
127.0.0.1 ya da ::1 adresine bağlı olan her şey izne ihtiyaç duymaz. 0.0.0.0 ya da [::] üzerindeki her şey internetten erişilebilirdir; bir istatistik eklentisinin yanında getirdiği MySQL veritabanı ve FastDL dosyalarınızın durduğu web sunucusu da buna dâhildir. Sonucu başlatma satırınızla karşılaştırın:
./srcds_run -game tf -console \
-port 27015 -steamport 26901 -nohltv \
+maxplayers 24 +map ctf_2fort +sv_pure 1 \
+sv_setsteamaccount GSLT_TOKENİNİZ
Bu satırdaki her port bilinçli bir karardır. Altyapının nasıl kurulduğu SteamCMD ile oyun sunucusu kurma yazısında.
2. Yalnızca TF2'nin gerçekten ihtiyaç duyduğu portları açık bırakma
Herkese açık bir TF2 sunucusu dışarıya tam olarak tek bir izne, buna ek olarak kendi adresiniz için RCON'a ihtiyaç duyar. UFW ile, hem de tam bu sırayla, ki kendinizi dışarıda bırakmayın:
ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'TF2 oyun ve A2S'
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment 'RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose
203.0.113.10 adresini kendi adresinizle değiştirin. SourceTV burada bilinçli olarak görünmüyor: Yayın yapmayan kişi -nohltv ile başlatır ve 27020/UDP portunu hiç kullanmaz. Bu, bir TF2 sunucusunun dışarıdan erişilebilir UDP yüzeyini yarıya indirir. Lig maçlarını yayınlıyorsanız buna ufw allow 27020/udp eklenir ve o zaman bir tv_password ayarlanmalıdır.
Kurtarma yolu da dâhil tam rehber Kendinizi dışarıda bırakmadan UFW güvenlik duvarı kurma yazısında. Buna rağmen olursa: KernelHost'un KVM root sunucularına ve dedicated sunucularına, konuk sistemin ağından bağımsız çalışan müşteri panelindeki VNC konsolu üzerinden ulaşırsınız.
3. Sunucu tarayıcısından düşmeden A2S sorgularını sınırlama
Bu konu alanındaki en pahalı hata buradadır: 27015/UDP portunu topluca kapatmak ya da kabaca hız sınırına almak, kendi oyuncularınızı dışarı atar ve saldırıyı saldırganın istediği anlamda bitirir. Oyun trafiği ve sorgu aynı portu kullandığı için sınır, portta değil paket türleri arasında geçmelidir.
Motor bunun için, tf/cfg/server.cfg dosyasına ait olan üç konsol değişkeni getirir:
sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30
İlki gönderen adres başına yanıtlanan sorguları, ikincisi bütün adreslerin toplamını sınırlar, üçüncüsü ise ortalama alma penceresini saniye cinsinden belirler. Bunlar CPU'yu anlamsızca yanıt üretmekten korur. Fabrika değerleri oyuna ve derlemeye göre farklılık gösterir; sunucu konsolunda find sv_max_queries, sunucunuzun hangi değerleri tanıdığını gösterir.
TF2'de hassas olan, ikinci değerdir: Yanıtları bütün adresler üzerinden üst sınıra alır. Onu fazla düşük ayarlarsanız sunucunuz bir sorgu flood'u sırasında liste hizmetlerinin isteklerini de artık yanıtlamaz ve sunucu tarayıcısından, yani yeni oyuncuların sizi bulduğu tek yoldan kaybolur. Cömert başlayın ve ancak meşru sorguların geçtiğini ölçebildiğinizde sıkılaştırın.
Bir kat aşağıda aynı trafik düzgün biçimde ayrılabilir. Source motorunun bütün bağlantısız paketleri dört dolu baytla (0xffffffff) başlar, çoktan bağlanmış oyuncuların trafiğinde ise bu başlık yoktur. Buna, oyun trafiğine dokunmadan bir hız sınırlaması konabilir:
table inet tf2 {
chain input {
type filter hook input priority -10; policy accept;
udp dport 27015 @th,64,32 0xffffffff \
meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
}
}
Dosyayı nft -f ile yüklersiniz. -10 önceliği, kuralın UFW'nin filtre zincirinden önce etki etmesini sağlar ve @th,64,32 UDP başlığının arkasındaki ilk dört baytı okur.
4. Logda NET_GetLong olarak görünen parçalanmış paket flood'larını yakalama
Bu saldırı Source motorunun bir özelliğidir ve TF2'yi özellikle vurur, çünkü TF2 bugüne kadar eski motor dalı üzerinde çalışıyor. Motor, normal bağlantısız paketlerin yanında parçalanmış paketleri de tanır: Bunlar FF FF FF FF yerine FE FF FF FF ile başlar ve daha büyük bir mesajın birkaç parça hâlinde geleceğini bildirir. Sunucunun parçaları önbelleğe alıp geri kalanını beklemesi gerekir.
Tam olarak bu kötüye kullanılabilir. Bir saldırgan, sahte gönderen adresleriyle bildirilen ama asla tamamlanmayan parça paketleri kitleler hâlinde gönderir. CPU yükü artar, oyun takılır ve sunucu logunda NET_GetLong içeren satırlar birikir. Bunun için tek bir bilgisayar yeter, bant genişliği neredeyse hiç gerekmez. İşletmeciler bunu, hat neredeyse boş olduğu hâlde düzenli olarak DDoS saldırısı diye bildirir.
Normal bir TF2 istemcisinin sunucuya parçalanmış paket gönderme nedeni neredeyse olmadığı için burada sıkı bir sınırlama savunulabilir:
udp dport 27015 @th,64,32 0xfffffffe \
meter tf2split { ip saddr limit rate over 5/second burst 10 packets } drop
Bu satır, 3. bölümdeki kuralla aynı zincire aittir. İstemci yüklemeleri için var olan az sayıdaki meşru nedenden birini ayrıca sv_allowupload 0 ile oyundan çıkarırsınız (bakınız 7. bölüm).
5. RCON'u açık ağdan çekme
Source motorunun RCON protokolü parolayı TCP üzerinden düz metin olarak aktarır. Sizinle sunucu arasındaki yolu okuyabilen kişide bundan sonra RCON parolanız olur ve RCON'a sahip olan kişi haritayı değiştirebilir, bütün oyuncuları yasaklayabilir ve sunucuyu durdurabilir. Bu bir DDoS sorunu değil, bir devralmadır, ama düzenli olarak saldırı diye bildirilir.
rcon_password değerini asla boş ve asla tahmin edilebilir bırakmayın; openssl rand -base64 32 komutundan gelen bir değer yeter. Buna, giriş denemelerine karşı bir fren eşlik eder:
rcon_password "BURAYA_RASTGELE_DEĞER"
sv_rcon_maxfailures 3
sv_rcon_minfailures 3
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440
Böylece sunucu, 30 saniye içindeki üç başarısız denemeden sonra bir adresi 24 saat boyunca yasaklar; find sv_rcon, derlemenizin hangi değişkenleri tanıdığını gösterir. Buna rağmen daha etkili olan, 2. bölümdeki güvenlik duvarı kuralıdır, çünkü denemeyi uygulamaya kadar hiç geçirmez. Değişen bağlantılardan erişim için SSH üzerinden yerel bir yönlendirme kurun ve RCON'a bundan sonra 127.0.0.1 üzerinden seslenin:
ssh -N -L 27015:127.0.0.1:27015 root@SUNUCU.IP.ADRESİNİZ
6. Hızlara üst sınır koyma ve hibernation'ı açık bırakma
Team Fortress 2 sabit biçimde saniyede 66,67 tick ile çalışır. Bundan ne kadar trafik çıkacağına tick değil, tek bir istemcinin ne talep edebileceği karar verir. Bir üst sınır olmadan her oyuncu istemcisinin istediği kadarını alır ve bunu giden bant genişliğinizle ödersiniz:
sv_minrate 50000
sv_maxrate 100000
sv_mincmdrate 40
sv_maxcmdrate 66
sv_minupdaterate 40
sv_maxupdaterate 66
Bunu bir kez hesaplayın: sv_maxrate 100000 ile her oyuncu saniyede 100 kilobayt alabilir, 24 slotta bu saniyede 2,4 megabayt ya da giden yönde yaklaşık 19 Mbit/s eder. sv_maxrate 0 ayarlarsanız bir üst sınır olmaz. Lig sunucuları bunu bilinçli yapar, çok slotu olan herkese açık bir sunucu ise yapmamalıdır. Tick hızını serbest bırakan eklentiler, oyuncu başına paket hızını ve böylece aynı hesabı katlar.
İkinci nokta sıkça yanlış yapılır. TF2, kimse bağlı olmadığı anda uykuya geçer ve bu durumda neredeyse hiç CPU kullanmaz. Birçok işletmeci, sunucu “uyanık” hissettirsin diye bunu kapatır. Birden fazla örneğin bulunduğu bir makinede bu, CPU'nun boştayken bile dolu olması ve bir saldırının zaten dolu bir sisteme gelmesi anlamına gelir. Fabrika ayarını olduğu gibi bırakın:
sv_hibernate_when_empty 1
sv_hibernate_postgame_delay 5
tf_allow_server_hibernation 1
7. FastDL'yi ayırma ve yüklemeleri kapatma
Topluluk sunucuları kendi haritalarıyla yaşar ve ikinci bir saldırı yüzeyi tam olarak bundan doğar. sv_downloadurl olmadan her oyuncu içerikleri oyunun ağ kanalı üzerinden, yani aynı anda maçı hesaplayan aynı port ve aynı süreç üzerinden indirir. Bu, saniyede birkaç kilobayt ve birbiri ardına tek tek dosya demektir; 200 megabaytlık bir harita koleksiyonunda bu, sunucunuzu oyuncu başına dakikalarca meşgul eder:
sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64
sv_downloadurl "https://fastdl.example.org/tf/"
net_maxfilesize fabrika ayarında 15'tedir ve en fazla 64 megabayta yükseltilebilir. sv_allowupload 0, istemcilerin kendi dosyalarını (örneğin sprey resimlerini) sunucuya göndermesini engeller ve böylece 4. bölümdeki parçalanmış paketler için var olan az sayıdaki meşru nedenden birini ortadan kaldırır.
Belirleyici olan, FastDL ana makinesinin nerede durduğudur. Oyun sunucusuyla aynı IP adresinde duruyorsa, hattı doldurmak ve böylece 27015/UDP portunu da boğmak için 443/TCP portuna gelen bir HTTP flood'u yeter. Hızlı indirmeyi başka bir ana makineye ya da bir içerik ağının arkasına koyun; o zaman dosyalara yapılan bir saldırı oyunu vurmaz.
8. Oylama sistemini, katılım flood'larını ve eklentileri sınırlama
Her kesinti bant genişliği değildir. TF2 ücretsiz olduğu için oyun mantığına yapılan bir saldırı hesaptan başka hiçbir şeye mal olmaz: her yeri işgal eden katılım flood'ları, sesli ve chat spam'i ve normal oyuncuları dışarı atan, kötüye kullanılmış oylamalar. TF2'nin fabrika ayarları burada zaten makuldür, ama sıkça gevşetilir:
sv_allow_votes 1
sv_vote_issue_kick_allowed 0
sv_vote_allow_spectators 0
sv_vote_creation_timer 150
sv_vote_failure_timer 300
sv_vote_quorum_ratio 0.6
Bunlar standart değerlerdir: Oylamalara izin verilir, kick oylamalarına verilmez, izleyiciler oy kullanmaz, iki oylama arasında 150 saniye vardır, başarısız bir oylamadan sonra 300 saniye ve bir oylama %60 onay gerektirir. sv_vote_issue_kick_allowed 1 ayarlayan kişi, bununla herkese açık bir sunucuda güvenilir biçimde kötüye kullanılan bir aracı açtığını bilmelidir.
Bunun ötesindeki her şey TF2'de SourceMod ve Metamod:Source'tan gelir. İkisi de tf/addons/ altında durur ve konsolda meta version ile sm version komutlarına yanıt verir. Counter-Strike 2'nin tersine buradaki altyapı olgunlaşmıştır ve yasak listeleri, katılım denetimi ve chat sınırlaması için eklentiler olağan yoldur. Buna dair iki kural: Her eklenti aynı süreçte koddur, çöken bir eklenti sunucuyu da beraberinde götürür. Ve kendi web hizmetlerini yanında getiren eklentiler başka portlar açar ve zaman zaman tam olarak korumak istediğiniz adresi yayınlar. sm plugins list, gerçekte neyin çalıştığını gösterir.
Motor tarafının ne kadar ciddiye alınması gerektiğini Nisan 2020 gösteriyor: TF2 ve CS:GO'nun eski kaynak kod sürümlerinin sızmasından sonra Creators.TF ve Red Sun gibi büyük topluluk işletmecileri, istismar kaygısıyla sunucularını geçici olarak kapattı. Sunucu ikili dosyasını güncel ve eklentileri motor sürümüne uygun tutun.
9. Yangın çıkmadan ölçme ve kayıt 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. Bir olay sırasında dört komut yeter:
ip -s link show eth0
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xfffffffe"
İlk komut arayüz başına paketleri, hataları ve düşürülenleri gösterir; onu on saniye arayla iki kez çalıştırın, o zaman kesin bir değer yerine bir hız elde edersiniz. İki paket kaydı, sorgu flood'unu parçalanmış paket flood'undan ayırır ve böylece 3. ile 4. bölümdeki iki kuraldan hangisinin etki etmesi gerektiği sorusunu yanıtlar. Onları her zaman -c ile sınırlayın; tam yük altında alınan bir kayıt kendisi de işlem zamanı tüketir.
Sunucunun içinde stats konsol komutu tek bir satırda CPU yükünü, saniyede kilobayt cinsinden gelen ve giden ağ yükünü, sunucu FPS'sini ve oyuncu sayısını verir. Oyuncu sayısı normalken sunucu FPS'si tick değerinin belirgin biçimde altına düşüyorsa sunucu oyundan başka bir şeyle uğraşıyordur. Değerleri nasıl sınıflandıracağınız Sunucuda DDoS saldırısını tanıma yazısında.
Bu önlemler nerede biter: bant genişliği ve paket hızı
Ş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.
Dolu bir TF2 sunucusunun normal işletimini gerçek bir saldırının yanına koyun, o zaman oran belirginleşir:
| Gösterge | Dolu TF2 sunucusu, 24 slot, 66,67 tick | Saldırı |
|---|---|---|
| Gelen paketler | saniyede yaklaşık 1.600 (24 oyuncu çarpı 66 komut) | saniyede birkaç milyon |
| Gelen bant genişliği | 2 Mbit/s'nin belirgin biçimde altında | topluluk oyun sunucularına karşı yaygın olarak 5 ila 50 Gbit/s |
| Giden bant genişliği | sv_maxrate 100000 ile yaklaşık 19 Mbit/s |
sorun değil |
| A2S sorguları | liste hizmeti başına dakikada birkaç tane | saniyede birkaç bin |
| Fiziksel üst sınır | 1 Gbit/s saniyede yaklaşık 1,49 milyon en küçük paketi taşır | 10 Gbit/s yaklaşık 14,88 milyon taşır |
Tipik bir oyun sunucusu 1 Gbit/s'lik bir hatta bağlıdır, bu saniyede 125 megabayt eder ve biri bundan fazlasını gönderdiği anda hat dolar. İkinci büyüklük paket hızıdır ve çoğunlukla bant genişliğinden önce vurur: Her paket, sonrasında düşürülse bile ağ yığınından bir geçişe mal olur. Bu yüzden hattınızı üçte birine bile doldurmayan bir saldırı, buna rağmen sunucunuzu felce uğratır. İşletmeciler bunu “doluluk hiç de yüksek değildi, buna rağmen her şey gitti” biçiminde yaşar.
Gerçekte hangi büyüklüklerin görüldüğünü sınıflandırmak için: KernelHost sunucularında başka şeylerin yanı sıra bir oyun sunucusuna saniyede 8,7 milyondan fazla pakette 112,2 Gbit/s'nin üzerinde bir UDP flood'u ve bir ses sunucusuna saniyede 41,5 milyondan fazla pakette 473,4 Gbit/s'nin üzerinde çok vektörlü bir saldırı gerçek zamanlı olarak filtrelendi. 473,4 Gbit/s, 1 Gbit/s'lik bir bağlantının yaklaşık 470 katıdır. Bunun için yerel bir ayar yoktur.
Yaygın iki imdat freni işe yaramaz. Null routing, saldırıya uğrayan IP adresini ağdan çeker ve saldırıyı bitirir, ama sunucunuzu da bitirir. Tepkisel bir yönlendirme ise geçiş süresinde tam olarak maçın karara bağlandığı dakikalara mal olur. Etkili olan yalnızca, sunucunun önündeki ağda kalıcı olarak çalışan bir filtrelemedir.
KernelHost, TF2 sunucularına yapılan saldırılara karşı ne koyuyor
Her sunucu paketinde bulunan sürekli koruma
KernelHost'un DDoS koruması iki kademeli kuruludur ve siz herhangi bir şeyi sipariş etmek, açmak veya yapılandırmak zorunda kalmadan teslimden itibaren kalıcı olarak etkindir:
- 1. kademe: küresel scrubbing ağında 17 Tbps mitigasyon kapasitesi. Hacimsel saldırılar, veri merkezine ulaşmadan önce kaynaklarına yakın bir noktada temizlenir.
- 2. kademe: Frankfurt am Main'de 3,2 Tbps ile Arbor gerçek zamanlı filtreleme. Doğrudan sunucunun önünde protokole özgü kalıplar tanınır ve paket paket düşürülür.
İki özellik bir TF2 sunucusu için belirleyicidir. Filtreleme kalıcı olarak çalışır ve önce bir saldırıya tepki vermek zorunda değildir; yani oyuncularınızın dışarı atıldığı ve sunucunuzun sunucu tarayıcısından düştüğü bir geçiş süresi yaşanmaz. Ayrıca null routing kullanılmaz: IP adresiniz ağda kalır, yalnızca zararlı paketler düşürülür. Hangi oyunların ve protokollerin kapsandığını Gerçek zamanlı oyun sunucusu DDoS koruması listeliyor.
Sürekli ateş altındaki sunucular için Advanced DDoS Protection
Bazı projelere ara sıra değil, hedefli biçimde ve haftalar boyunca, değişen kalıplarla ve her zaman tam maç saatinde saldırılır. Bunun 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:
- Dedicated koruma IP'si: Frankfurt çekirdek ağından verilir ve sunucunuz bizim ağımız içinde bu adrese geçirilir. Sizin tarafınızda hiçbir değişiklik gerekmez.
- Kendiniz yönetebileceğiniz, port ve protokol başına koruma kuralları: Müşteri panelinde 27015/UDP'de, 27020/UDP'de ve 27015/TCP'de neye izin verildiğini, bunun için bir talep yazmak zorunda kalmadan ayrı ayrı ayarlarsınız.
- Değişiklikler gerçek zamanlı etki eder, yani maçın sonunu beklemek yerine süren bir saldırı sırasında ince ayar yapabilirsiniz.
- Oyuna uygun koruma profili: Team Fortress 2 ve diğer Source oyunları için, aynı şekilde kendi uygulamalarınız için serbest TCP ve UDP profilleri.
Bu teklif KernelHost'ta çalışan sunuculara yöneliktir. TF2 sunucunuz şu anda başka bir yerde duruyorsa ve düzenli olarak ateş altındaysa, bu korumaya giden yol taşınmaktır.
İki kademenin karşılaştırması
| Özellik | Dâhil olan sürekli DDoS koruması | Advanced DDoS Protection |
|---|---|---|
| Fiyat | her sunucu paketinde dâhil, ek ücret olmadan | ayda 50,00 EUR'dan başlar, PrePaid |
| Etkinleştirme | teslimden itibaren etkin, kurulacak bir şey yok | sipariş edilir, koruma IP'si alınır, sunucu geçirilir |
| Filtreleme kapasitesi | 17 Tbps küresel scrubbing artı Frankfurt am Main'de 3,2 Tbps ile Arbor gerçek zamanlı filtreleme | aynı iki kademeli filtreleme |
| IP adresi | sunucunuzun IP adresi | ek dedicated koruma IP'si |
| Kural seti | otomatik profiller, ince ayar destek talebiyle | müşteri panelinde port ve protokol başına kendi kurallarınız |
| Değişiklikler | otomatik olarak birlikte ilerler | gerçek zamanlı etki eder, bir saldırı sırasında da |
| Oyun profili | Team Fortress 2 dâhil, yaygın oyunlar için optimize edilmiş profiller | port başına profil seçilebilir, değiştirilmiş sunucular için de |
| Null routing | hayır | hayır |
| Süre | sunucu paketine bağlı | PrePaid, asgari süre yok, fesih bildirim süresi yok, kurulum ücreti yok |
TF2 topluluk sunucularının ç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
“Sunucu çalışıyor, ama artık sunucu tarayıcısında görünmüyor”: Önce Game Server Login Token'ı denetleyin. TF2 sunucuları herkese açık kayıt için bir token'a ihtiyaç duyar; bu, sv_setsteamaccount ile ayarlanır ve 440 uygulama kimliği için üretilir. Steam, 30 gün boyunca kullanılmamış token'ları geri çeker. Yani uzun bir aradan sonra kaybolan bir sunucuya çoğunlukla yalnızca yeni bir token gerekir ve o sunucu hiç saldırıya uğramıyordur. Ancak bundan sonra fazla düşük bir sv_max_queries_sec_global ya da 27015/UDP üzerindeki fazla kaba bir güvenlik duvarı kuralı söz konusu olur.
“CPU %100'de, hat neredeyse boş”: Bu, bir sorgu ya da parçalanmış paket flood'unun tipik görüntüsüdür. Sunucu logunda NET_GetLong içeren satırlara bakın ve 9. bölümdeki iki tcpdump satırıyla hangi paket türünün geldiğini ölçün.
“nftables ya da iptables kurallarım etki etmiyor”: Üç neden sıktır. Kural UFW zincirlerinin arkasında duruyor ve hiç ulaşılmıyordur (bu yüzden -10 önceliği), son yeniden başlatmadan sonra kaybolmuştur ya da saldırı hacimseldir ve kural, zaten dolu olan bir hatta doğru biçimde çalışıyordur. nft list ruleset komutuyla sayaçların artıp artmadığını denetleyin. Sayaçlar sıfırda kalıyorsa kurala ulaşılmıyor.
“IP adresini değiştirdim ve ertesi gün yine çevrimdışıydım”: Saldırgan yeni adresi eskisiyle aynı kaynaktan bulur. Sunucunuz onu, sunucu tarayıcısında yeniden yer aldığı anda kendisi yayınlar; eski DNS kayıtları ve Discord durum botları da gerisini yapar. Bir adres değişikliği saat kazandırır, çözüm getirmez.
“Sunucu, bant genişliği dikkat çekmeden yinelenebilir biçimde çöküyor”: Çoğunlukla bir DDoS saldırısı değil, motor sürümüne uymayan bir eklenti ya da eski bir sunucu ikili dosyası. sm plugins list ve sürüm durumlarının karşılaştırılması burada her filtreleme kuralından daha hızlıdır.
“Sunucu boşta kaldıktan sonra gecikmeli tepki veriyor”: Bu hibernation'dır ve bir hata değildir. Kimse bağlı olmadığı sürece CPU yükünü neredeyse sıfıra indirir ve bu, tam olarak yedeğe sahip olmak istediğiniz durumdur.
“Sunucuda yabancı yönetim komutları çalışıyor”: Bu bir DDoS saldırısı değil, ele geçirilmiş bir RCON erişimidir. Parolayı hemen yeniden ayarlayın, portu kendi adresinize sınırlayın ve parolanın hat üzerinden düz metin olarak gittiğini göz önünde bulundurun.
“Ö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.
Kısaca özetle
- Bir TF2 sunucusu dışarıya tam olarak 27015/UDP portuna ihtiyaç duyar. 27015/TCP üzerindeki RCON kendi adresinize sınırlanmaya aittir, 27020/UDP üzerindeki SourceTV ise yayın yapmıyorsanız
-nohltvile kapatılır. - Oyun trafiği ve A2S sorgusu aynı portu paylaşır. 27015/UDP portunu topluca kapatan ya da hız sınırına alan kişi kendi oyuncularını dışarı atar. Sınır, UDP başlığının arkasındaki ilk dört bayttan tanınabilen paket türleri arasında geçmelidir.
FE FF FF FFbaşlığını taşıyan parçalanmış paket flood'ları bant genişliği yerine CPU yükü üretir ve logdaNET_GetLongolarak görünür. Bu paket türünün sıkı biçimde sınırlanması TF2'de savunulabilir.- “Meet Your Match” güncellemesinden bu yana yeni oyuncular topluluk sunucularını yalnızca sunucu tarayıcısı üzerinden buluyor. Sizi listeden çıkaran her önlem, saldırının kendisi gibi etki eder.
- Dolu bir 24 slotluk sunucu saniyede yaklaşık 1.600 gelen paketi işler. Topluluk oyun sunucularına yapılan saldırılar genellikle 5 ila 50 Gbit/s ve saniyede birkaç milyon pakettir.
- 1 Gbit/s, en küçük paketlerde saniyede yaklaşık 1,49 milyon paket taşır. Bu sınırın üzerinde yalnızca sunucunun önündeki ağ belirleyicidir, sunucudaki hiçbir kural değil.
- KernelHost'ta iki kademeli sürekli koruma her sunucu paketinde ek ücret olmadan bulunur, teslimden itibaren etkindir ve null routing kullanmaz. Kuralları port başına kendiniz yönetmek istiyorsanız buna ayda 50,00 EUR'dan başlayarak Advanced DDoS Protection eklenir.
Sunucunuz hâlihazırda KernelHost'ta çalışıyorsa filtreleme, siz hiçbir şey yapmak zorunda kalmadan etkindir. Buna rağmen dikkat çekici bir durum fark ederseniz, IP adresiniz için filtreleme kurallarının yeniden ayarlanması amacıyla 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. Bu arada dört bilgiyi hemen belirtin: IP adresi, port, kendi saat diliminizdeki zaman aralığı ve ne gördüğünüz. Bu, bir soru turunu ortadan kaldırır ve bir maç sürerken o tur önem taşır.
Sıkça sorulan sorular
TF2 sunucum şu anda çevrimdışı. Bunun bir DDoS saldırısı olup olmadığını nasıl anlarım?
Bir Team Fortress 2 sunucusu için hangi portları açık bırakmam gerekir?
27015 portunu öylece kapatabilir ya da hız sınırına alabilir miyim?
Sunucu logundaki NET_GetLong içeren satırlar ne anlama gelir?
Sunucum çalışıyor, ama artık sunucu tarayıcısında görünmüyor. Saldırıya mı uğruyorum?
Şimdi hızlıca IP adresini değiştirmek işe yarar mı?
TF2 sunucum hangi saldırı büyüklüğünden sonra bunu tek başına başaramaz?
KernelHost'taki sunucum bir saldırı sırasında çevrimdışı olur mu?
KernelHost'ta DDoS koruması ek ücretli mi ve Advanced DDoS Protection'a ne zaman ihtiyaç duyarım?
2026 KernelHost GmbH. Tüm hakları saklıdır. Bu rehber telif hakkıyla korunmaktadır. Yazının başka web sitelerinde tamamen, kısmen ya da düzenlenmiş biçimde yayımlanması, yazılı iznimiz olmadan serbest değildir. Kaynak belirtilerek ve bağlantı verilerek yapılan alıntılar ise memnuniyetle karşılanır.

