Minecraft Bedrock sunucusunu DDoS saldırılarına karşı koruma

Akşamları birkaç dakika boyunca sunucu listesinden kaybolan ve sonra geri dönen bir Minecraft Bedrock sunucusunun donanım sorunu yaşaması nadirdir. Çoğunlukla bir saldırı sürüyordur, hem de tam olarak oyuncuların çoğunun çevrimiçi olduğu anda. Bu yazı bir Minecraft Bedrock sunucusunu DDoS saldırılarına karşı nasıl koruyacağınızı gösteriyor: önce ek maliyet olmadan kendiniz neleri güvene alabileceğinizi, ardından bu önlemlerin fiziksel olarak nerede bittiğini, sonunda da sunucunun önündeki ağda neler olması gerektiğini.

Tüm bilgiler Debian 12, Debian 13, Ubuntu 22.04 LTS veya Ubuntu 24.04 LTS üzerinde çalışan bir Bedrock Dedicated Server, PocketMine-MP ya da Nukkit içindir. Komutlar root kullanıcısı için yazılmıştır, normal kullanıcı olarak başlarına sudo ekleyin. Java Edition işletenler, orada tipik olan protokol saldırılarını Minecraft DDoS koruması ve nullping koruması yazısında bulur. Bir Bedrock sunucusunun salt kurulumunu ise Nukkit ile Minecraft Bedrock sunucusu kurma yazısı anlatıyor.

Saldırı şu anda sürüyorsa: Yapılandırmada şimdi hiçbir şey değiştirmeyin ve sunucuyu yeniden başlatmayın. Önce ölçüm değerlerini kaydedin (“Patlamadan önce ölçüm değerleri toplama” bölümü), saldırıdan sonra bu değerler geri getirilemez biçimde kaybolur.

Minecraft Bedrock sunucuları neden bu kadar sık DDoS saldırılarının hedefi oluyor

Bedrock Edition, konsollarda, akıllı telefonlarda, tabletlerde ve Windows üzerinde çalışan sürümdür ve Minecraft'ın en büyük oyuncu kitlesini barındırır. Çok sayıda sunucunun bulunduğu yerde saldırı için en büyük dürtü de oluşur: rakip ağlar, banlanmış oyuncular, iç çatışmalar. Bir saldırı ise tetikleyen kişiye ne beceri ne de anlamlı bir para harcaması getirir, bir sunucu booter'ı abonelik olarak satılır.

Teknik neden daha derinde. Bir Bedrock sunucusu TCP değil UDP konuşur ve herhangi bir oturum açma gerçekleşmeden çok önce soran herkese yanıt verir. Tam olarak bu iki özellik 19132 UDP portunu rahat bir hedefe dönüştürür. Bir DDoS saldırısının temelde ne olduğunu DDoS saldırısı nedir? yazısı anlatıyor.

RakNet: kimse oturum açmadan önce yanıt veren bir UDP protokolü

RakNet, Minecraft Bedrock Edition'ın bütün oyun trafiğini üzerinden yürüttüğü UDP ağ kütüphanesidir. UDP'de bir sunucunun talep edebileceği bağlantı kurulumu yoktur ve gönderen adresleri bu yüzden sahte olabilir. RakNet kendi güvenilirlik katmanını bunun üzerine kurar: sıra numaraları, onaylar (ACK) ve bir istemcinin kayıp paketleri yeniden isteyebildiği olumsuz onaylar (NAK).

Bağlantı kurulumu yedi paketten oluşur, dördü istemciden ve üçü sunucudan:

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

İstemci ancak bundan sonra Xbox Live belgeleriyle giriş paketini gönderir. Bedrock sunucusunu güvene almak isteyen herkes için belirleyici cümle budur: Sunucu, kapıyı kimin çaldığını öğrenmeden önce yedi paketi işlemiş, işlem zamanı ile bellek harcamış ve birkaç kez yanıt vermiştir. Yani oturum açmaya tutunan her önlem, yük çoktan oluştuktan sonra etki eder.

Buna ikinci ve daha da erken bir giriş noktası ekleniyor. Bir sunucunun bir oyuncunun sunucu listesinde adıyla, sürümüyle ve oyuncu sayısıyla görünmesi için, sunucu Unconnected Ping paketini (paket kimliği 0x01) bir Unconnected Pong ile (paket kimliği 0x1C) yanıtlar. Bu alışveriş asıl bağlantı kurulumundan önce gerçekleşir, hiçbir belge talep etmez ve Bedrock Dedicated Server'da, sunucuyu her sunucu listesinden çıkarmadan kapatılamaz.

Amplifikasyon aracı olarak Unconnected Ping: sayılar

Bir amplifikasyon saldırısı, saldırganın sahte gönderen adresiyle yabancı sunuculara küçük istekler göndermesi ve bu sunucuların daha büyük yanıtlarının kurbanda toplanması anlamına gelir. Bedrock sunucusu bu sırada saldırıya uğramaz, kullanılır. Unconnected Ping'de hesap şöyle görünür:

Bundan doğrudan iki şey çıkar. Birincisi: Uzun bir sunucu adı yanıtı ve böylece yabancı saldırganların kullanımına sunduğunuz amplifikasyon faktörünü büyütür. Kısa bir ad kozmetik değil, bir koruma önlemidir. İkincisi: Standart yapılandırmanın 4 faktörü, sunucunuzun yansıtıcı olarak ilgi çekici kalmayacağı kadar küçük, ama bir ping selinin kendi çıkış hattınızı gelenin dört katıyla yükleyeceği kadar büyüktür.

2024'ün amplifikasyon hatası, güvenilirlik katmanının kendisi kötüye kullanıldığında durumun ne kadar kötüleşebileceğini gösteriyor. O sırada kullanılan RakNet kütüphanesinde Connection Request Accepted paketi güvenilir olarak işaretlenmişti. Bir saldırgan bağlantı kurulumunu sahte gönderen adresiyle bu noktaya kadar oynayabiliyor ve ardından 0 ila 8191 aralığıyla tek bir olumsuz onay gönderebiliyordu. Sunucu bunun üzerine, saldırganın başka hiçbir şey yapması gerekmeden sahte adrese binlerce paket gönderiyordu. Sorun üç adımla giderildi: paket güvenilmez olarak değiştirildi, Open Connection Reply 1 içinde gerçek bir istemcinin geri yansıttığı bir cookie gönderilmeye başlandı ve paket sınırları getirildi: 10 milisaniyelik aralık başına kaynak adres başına 120 paket, aralık başına toplam 1.000 paket.

Bedrock Edition ile Java Edition: DDoS korumasında ne farklıdır

Daha önce bir Java sunucusunu güvene almış olan kişi neredeyse her şeyi yanlış aktarır. İki edition adı paylaşır, ağ protokolünü ise paylaşmaz:

SYN cookie satırı en önemlisidir. Java Edition'da Linux kernel'i bir SYN flood'unu, Minecraft süreci bunu fark etmeden savuşturur. Bedrock Edition'da bu yardım yoktur: Her tek UDP paketi sunucu sürecine kadar geçirilir ve orada değerlendirilir. Bir Bedrock sunucusunun 19132 portuna gelen bir flood'a karşı işletim sisteminde yerleşik hiçbir koruması yoktur, çünkü UDP böyle bir şey tanımaz.

Eksik SRV kaydı satırının, birçok kişiyi şaşırtan pratik bir sonucu var: Bedrock Edition'da portu bir DNS kaydının arkasına saklayamazsınız. Oyuncular adres ile portu elle girer. Portu taşıyan kişi yeni portu her oyuncuya bildirmek zorundadır.

Asıl mesele olan portlar

Bir Bedrock Dedicated Server kendini tam olarak iki porta bağlar, hem de her ikisinde UDP üzerinden. server.properties dosyasında:

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

Bunlar Microsoft'un fabrika ayarlarıdır, Bedrock Dedicated Server referansında okunabilir. Bu iki portun çevresinde, sunucu yazılımına göre birlikte çalışan başka hizmetler durur:

Üçüncü ve dördüncü satır, Bedrock sunucularında önlenebilir hataların en sık görülenidir. Nukkit ve PocketMine-MP'de enable-query fabrika ayarında açıktır ve Nukkit'te yanlışlıkla açılmış bir RCON 19132 TCP portunda, yani oyunla aynı port numarasında durur. Yalnızca “19132 açık, tamamdır” diye bakan kişi bunu gözden kaçırır.

Resmî Bedrock Dedicated Server'ın bir özelliği de buraya aittir: server-ip diye bir direktif tanımaz. PocketMine-MP ile Nukkit'te bu vardır (server-ip, PocketMine'da ek olarak server-ipv6), resmî sunucuda yoktur. Yani her zaman sistemin bütün adreslerinde dinler ve güvenlik duvarı bunu kısıtlamak için tek olanağınızdır.

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 Bedrock 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: 19132 portunda ne dinliyor?

Tek bir kural yazmadan önce sunucunuzun dışarıya ne sunduğuna bakın. Tahmin etmeyin, bakın:

ss -lntup
ss -lnup sport = :19132

İlgi çekici olan, yerel adresi gösteren sütundur. 0.0.0.0:19132 ve [::]:19133 “bütün internetten erişilebilir” anlamına gelir. Bunların yanında aynı port numarasında bir TCP kaydı görünüyorsa RCON çalışıyordur. Saldırganın bakışını dışarıdan yapılan bir port taraması verir, UDP için -sU ile:

nmap -Pn -sU -p 19132,19133 SUNUCU.IP.ADRESİNİZ
nmap -Pn -p- --min-rate 1000 SUNUCU.IP.ADRESİNİZ

2. Yalnızca 19132 UDP'yi açık bırakma, geri kalan her şeyi kapatma

Bir Bedrock sunucusu için dışarıya tek bir izin yeter, IPv6 ile iki. UFW ile bu şö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 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

IPv6 oyuncularınız yoksa 19133 satırını bırakın ve PocketMine-MP'de ek olarak enable-ipv6=false ayarlayın. İzin vermediğiniz her port, savunmak zorunda olmadığınız bir porttur. Kurtarma yolu da dâhil tam rehber Kendinizi dışarıda bırakmadan UFW güvenlik duvarı kurma yazısında.

3. LAN görünürlüğünü kapatma, yoksa 19132 açık kalır

Bu, portu taşımak isteyen hemen herkesin düştüğü tuzaktır. enable-lan-visibility direktifi fabrika ayarında true değerindedir ve sunucunun yerel ağdaki arama isteklerine yanıt vermesini sağlar. Microsoft bu konuda, sunucunun bu nedenle server-port ile server-portv6 başka değerlere sahip olsa bile ek olarak 19132 ve 19133 standart portlarına bağlandığını ayrıca yazıyor.

Yani portu 19140'a taşıyıp kendini güvende sanan kişi 19132'de dinlemeye devam eder. Bu yüzden internetteki bir sunucu için server.properties dosyasına şu ayar aittir:

enable-lan-visibility=false

Ardından ss -lnup ile 19132'nin gerçekten kaybolduğunu doğrulayın. Bu arada aynı ayar, aynı makinedeki iki Bedrock sunucusunun birbirinin portunu kapması sorununu da çözer.

4. Query ve RCON'u kapatma

PocketMine-MP ve Nukkit, UT3 protokolünün kalıbına göre çalışan bir UDP sunucu sorgusu olan GS4 query'i beraberinde getirir ve bu sorguları oyunun çalıştığı aynı 19132 portunda yanıtlar. Ayrıntılı yanıt sunucu adını, sürümü, dünya adını, beyaz listenin durumunu, adres ile portu, oyuncu sayısını, bağlı bütün oyuncuların adlarını ve PocketMine-MP'de istenirse eklentilerin tam listesini içerir. Bu durum sayfaları ile Discord botları için kullanışlıdır, ama bir saldırgana bir saldırının tam olarak ne zaman kazançlı olacağını söyler ve her sorgu başına işlem zamanına mal olur.

enable-query=off
enable-rcon=off

PocketMine-MP'de değerler off yerine false biçimindedir ve eklenti listesini pocketmine.yml dosyasında settings.query-plugins: false ile kapatırsınız. Nadiren okunan bir sınıflandırma: PocketMine-MP'nin GS4 query'i, gönderen adresiyle tuzlanmış bir token'ı denetler. Böylece büyük yanıt sahte bir adrese yansıtılamaz. Sorgu buna rağmen işlem zamanına mal olur ve yayınlanan veriler saldırgana hedef seçiminde yardım eder. Resmî Bedrock Dedicated Server ne query ne de RCON tanır, orada bu madde ortadan kalkar.

RCON'a gerçekten ihtiyacınız varsa Nukkit'te rcon.port değerini mutlaka kendine ait bir değere ayarlayın ve yalnızca kendi adresiniz için açın. Aksi hâlde server-port değerine geri düşmek, sunucunuzun bir uzaktan yönetiminin 19132 TCP portunda dinlediği anlamına gelir, yani zaten her yerde “açık” olarak kaydettiğiniz aynı sayıda.

5. Xbox Live kimlik doğrulamasını zorunlu kılma

Xbox Live kimlik doğrulaması, katılan bir oyuncunun Microsoft tarafından imzalanmış gerçek bir hesaba sahip olup olmadığının denetlenmesidir. Üç sunucu yazılımının hepsinde fabrika ayarında açıktır ve orada da kalmalıdır.

Bedrock Dedicated Server'da direktifin adı online-mode, PocketMine-MP ile Nukkit'te ise xbox-auth biçimindedir. Her iki durumda da true fabrika durumu ve doğru değerdir:

online-mode=true
xbox-auth=true

Microsoft bu konuda önemli bir kısıtlama belirtiyor: Yerel ağın dışındaki bir sunucuya bağlanan istemciler, bu ayardan bağımsız olarak Xbox Live kimlik doğrulamasına her hâlükârda ihtiyaç duyar. Belge, Xbox kimliği (XUID) ve görünen adla birlikte imzalı bir token zinciri olarak giriş paketinde iletilir.

Ve şimdi yanlış anlamalara karşı yardımcı olan kısım: Xbox Live kimlik doğrulaması oyun mantığınızı korur, hattınızı korumaz. Giriş paketinde gerçekleşir, yani RakNet bağlantı kurulumunun tamamlanmasından sonra. Sunucunuzu flood ile dolduran bir saldırgan katılmak istemiyordur. Paketleri reddedilir, ama buna rağmen ulaşmıştır ve mesele tam olarak budur.

6. Allowlist ve oyuncu üst sınırı, ve bunların yapamadıkları

Allowlist (eskiden whitelist), katılmasına izin verilen oyuncuların listesidir. Bedrock Dedicated Server'da onu allow-list=true ile açarsınız, kayıtlar ad, XUID ve ignoresPlayerLimit alanıyla birlikte allowlist.json dosyasında durur. Nukkit ile PocketMine-MP'de direktifin adı hâlâ white-list biçimindedir.

allow-list=true
max-players=60
player-idle-timeout=15

player-idle-timeout üzerinden kısa bir boşta kalma süresi slot tükenmesine karşı etkilidir: Yalnızca bir yer işgal eden oyuncular, belirtilen dakika sayısından sonra dışarı atılır. 0 değeri hiç kimsenin hareketsizlik nedeniyle asla koparılmaması anlamına gelir ve gerçek hesaplarla yerlerinizi bloke eden bir saldırgan tam olarak bunu kullanır.

Burada da önceki bölümdeki sınır geçerlidir ve bu, hepsinin içinde en sık gözden kaçan noktadır: Allowlist ancak giriş paketi işlendiğinde denetlenir. Katılımları engeller, paketleri engellemez.

7. Kaynak adres başına paket hızlarını sınırlama

Küçük saldırılara ve özensiz botlara karşı kaynak adres başına bir üst sınır işe yarar. UDP için connlimit ile değil hashlimit ile çalışılır, çünkü UDP bağlantı tanımaz:

iptables -I INPUT -p udp --dport 19132 -m hashlimit --hashlimit-name bedrock_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

Kural, aynı kaynak adresin saniyede kalıcı olarak 400'den fazla paket göndermesi durumunda UDP paketlerini düşürür. Değer bir başlangıç değeridir, kesin doğru değil: 60 oyuncusu ve geniş görüş mesafesi olan dolu bir sunucu, boş bir sunucudan belirgin biçimde daha fazla paket üretir ve fazla sıkı ayarlayan kişi kendi oyuncularını dışarı atar. Önce normal işletimde bir hafta ölçün.

Unconnected Ping'de belirgin biçimde daha sıkı ayarlayabilirsiniz, çünkü gerçek bir istemci sunucu durumunu yalnızca sunucu listesi açık olduğu sürece ve o zaman da saniyelik aralıkla sorar. nftables ile tam olarak bu tek paketi yakalamak mümkündür, çünkü paket kimliği UDP başlığının ardındaki ilk bayttır:

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

@th,64,8 ifadesi, taşıma başlığının 64. bitinden itibaren sekiz bit okur, yani UDP veri yükünün ilk baytını. 0x01 değeri Unconnected Ping'in paket kimliğidir. Herhangi bir şeyi düşürmeden önce aynı yeri gözlem için kullanabilirsiniz:

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

İlk satır gelen durum sorgularını sayar, ikincisi kendi yanıtlarınızı. Neredeyse hiç kimse oynamıyorken ikisi de saniyelik aralıkla binlere çıkıyorsa, oyuncularınızı değil bir ping selini görüyorsunuz.

Kalıcılığa dair iki not. Salt iptables kuralları bir yeniden başlatmadan sonra kaybolur; Debian ve Ubuntu'da şöyle kaydedilir:

apt-get install -y iptables-persistent
netfilter-persistent save

UFW altında ise bu tür kurallar /etc/ufw/before.rules dosyasına aittir, çünkü aksi hâlde bir sonraki ufw reload komutunda kaybolurlar.

8. Kernel'in bağlantı izlemesini rahatlatma

UDP oyunlarında TCP'ye göre çok daha erken devreye giren bir darboğaz: Kernel her UDP paket çifti için bağlantı izlemede bir kayıt oluşturur. Sahte gönderen adresleriyle yapılan bir selde her paket yeni bir kaynak adres ve böylece yeni bir kayıttır. Tablo dolduğunda sunucu meşru paketleri de düşürür ve logda “nf_conntrack: table full, dropping packet” satırı görünür.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Sayaç kalıcı olarak üst sınıra yakın duruyorsa oyun trafiğini izlemenin dışında tutabilirsiniz. Bu etkilidir, ama sonuçsuz değildir; bu yüzden her iki yönde ve ardından bir bağlantı testiyle:

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

Bundan sonra bu trafik için duruma dayalı kurallar artık etki etmez. Yani 19132 UDP için verdiğiniz izin gerçek bir port izni olmalı ve ESTABLISHED durumuna güvenmemelidir. Ayarladıktan sonra conntrack -L | grep 19132 ile artık kayıt oluşmadığını doğrulayın ve kuralları kalıcı olarak kaydetmeden önce bir kez oyunla bağlanın.

9. Geyser ve Floodgate'i düzgün işletme

Geyser, Bedrock istemcilerinin bir Java Edition sunucusunda oynamasını sağlayan bir köprüdür: 19132 UDP portunda Bedrock bağlantılarını kabul eder, protokolü çevirir ve diğer tarafta Java sunucusuyla 25565 TCP üzerinde konuşur. Floodgate ise bu Bedrock oyuncularının Java hesabı olmadan katılmasına izin veren ektir. DDoS koruması açısından bu üç şey anlamına gelir.

Birincisi: Geyser'i güncel tutun. Tam olarak bu köprü iki kez belgelenmiş saldırıların nedeni oldu. Mart 2024'te RakNet kütüphanesindeki, yukarıda anlatılan amplifikasyon hatası geniş ölçekte kullanıldı, build 478'den itibaren giderildi. Temmuz 2025'te ikinci bir vaka geldi: Kaynak paketlerinin onaylanması için tekrar tekrar gönderilen bir paket, oyuncu başına birden fazla oturum oluşturuyordu ve kopmuş istemciler, ağ kanalı kapatılmadığı için paket göndermeye devam edebiliyordu. Build 897'den itibaren giderildi. İki vaka da projenin kendisi tarafından zaman çizelgesiyle yayınlandı.

İkincisi: Java sunucusu açık ağa ait değildir. Geyser yapılandırmasında remote.address auto ya da 127.0.0.1 değerine, remote.port ise 25565'e işaret eder. Java sunucusunu buna uygun biçimde yerel olarak bağlayın ve 25565 TCP portunu dışarıya açmayın. Aksi hâlde bir yerine iki saldırı yüzeyiniz olur ve ikincisi, hiç kural düşünmediğiniz olandır.

Üçüncüsü: key.pem dosyası bir sırdır. Floodgate'in Bedrock hesapları için Java kimlik doğrulamasını atlamasını sağlayan anahtardır. Onu herkese açık bir depoya koyan, bir destek talebine kopyalayan ya da bir ekran görüntüsünde gösteren kişi sunucusunun oturum açmasını bağışlamış olur. Proje bu konuda açıkça uyarıyor.

10. Patlamadan önce ölçüm değerleri toplama

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 cumartesi akşamı mı olduğunu söyleyemezsiniz. apt-get install -y vnstat sysstat conntrack ile ölçüm kalıcı olarak arka planda çalışır.

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

Bu değerlerden üçü bir Bedrock sunucusunda özellikle aydınlatıcıdır. 19132 portunun UDP soketinde kalıcı olarak sıfırdan farklı bir Recv-Q, sunucu sürecinin gelen paketleri artık yeterince hızlı almadığı anlamına gelir. UdpRcvbufErrors tam olarak bu nedenle düşürülen paketleri sayar ve darboğazın hat değil süreç olduğunun en sağlam kanıtıdır. UdpNoPorts ise biri hiçbir şeyin dinlemediği portlara ateş ettiğinde artar; asıl saldırıdan önce geniş biçimde yayılmış bir port taramasında görülen tipik bir tablodur.

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 nasıl yorumlayacağınız 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.

Bir kez birlikte hesaplayalım. Biri saniyede 125 megabayttan fazlasını gönderdiği anda hattınız dolar. 5 ila 50 Gbit/s'lik bir saldırı bunun beş ila elli katıdır. O zaman arkadaki hashlimit kuralınızın iyi olup olmadığı artık bir rol oynamaz, çünkü oyuncularınızın paketleri daha öncesinde geçemez.

İkinci büyüklük paket hızıdır ve bir Bedrock sunucusunda neredeyse her zaman önce o vurur. Oyun trafiğinin tamamı çok sayıda küçük UDP paketinden oluşur ve bir saldırgan tam bu dalda en ucuz yolla hareket eder. Hattınızı üçte birine bile doldurmayan bir saldırı, değerlendirme ve düşürme işlemi için işlem zamanı harcandığı için sunucunuzu buna rağmen felç edebilir. İşletmeciler bunu “doluluk hiç de yüksek değildi, buna rağmen herkes dışarıdaydı” biçiminde yaşar. Oyunda ise aynı şey lag sıçramaları, lastik bandı etkileri ve inşaatın ortasında kopan bağlantılar olarak kendini gösterir.

Bunun için yerel bir ayar yoktur. Hacimsel saldırılar sunucunun önündeki ağda son bulmalıdır.

KernelHost, Bedrock sunucularına yapılan DDoS saldırılarına karşı ne koyuyor

Her sunucuda dâhil olan sürekli koruma

KernelHost'un DDoS koruması iki kademeli kuruludur ve siz herhangi bir şeyi açmak, sipariş etmek veya yapılandırmak zorunda kalmadan 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. Buna 19132 portunda RakNet davranışı göstermeyen UDP kalıpları da dâhildir.

İki özellik belirleyicidir. Koruma kalıcı olarak çalışır ve önce bir saldırıya tepki vermek zorunda değildir; yani başlangıçta sunucunun kayıp olduğu dakikalar yaşanmaz. Ayrıca null routing kullanılmaz: IP adresiniz ağda kalır, yalnızca zararlı paketler düşürülür. IP adresini ağdan çeken kişi, sizin açınızdan saldırganla aynı sonuca ulaşır. Konum Frankfurt am Main'dir. Hangi oyunların ve protokollerin kapsandığını Gerçek zamanlı oyun sunucusu DDoS koruması yazısı listeliyor.

Sürekli ateş altındaki projeler için Advanced DDoS Protection

Bazı projelere ara sıra değil, hedefli biçimde ve haftalar boyunca 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:

• Frankfurt çekirdek ağından verilen ve sunucunuzun kendi ağı içinde geçirildiği dedicated koruma IP'si. Sizin tarafınızda hiçbir değişiklik gerekmez.
• Müşteri panelinde kendiniz yönetebileceğiniz, port ve protokol başına koruma kuralları: 19132 UDP'de neye izin verildiğini, 19133 UDP'de neye izin verildiğini ve sunucunuzu taşıdıysanız farklı bir portta neye izin verildiğini ayarlarsınız.
• Değişiklikler gerçek zamanlı etki eder, yani bir bakım penceresini beklemek yerine süren bir saldırı sırasında ince ayar yapabilirsiniz.
• Her oyuna uygun koruma profili. Minecraft için hazır profiller var, aynı şekilde herhangi bir TCP veya UDP portunda çalışan değiştirilmiş ve kendi uygulamalarınız için de, yani Nukkit, PocketMine-MP ya da kendi seçtiğiniz bir portta çalışan bir Geyser örneği için de.

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

Bedrock 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. Sunucusunu şu anda başka bir yerde işleten kişi sorunu en iyi bir taşınmayla çözer: Filtreleme sunucunun önündeki ağda etki eder ve bu ağın bize ait olması gerekir.

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

“Portu 19140 yaptım, 19132 buna rağmen açık”: Bu enable-lan-visibility=true demektir. Bedrock Dedicated Server o zaman, server-port değerinde ne yazıyor olursa olsun ek olarak 19132 ve 19133'e bağlanır. false yapın, sunucuyu yeniden başlatın, ss -lnup ile doğrulayın.

“allowlist.json dosyasını düzenledim ve kendim de artık giremiyorum”: İki neden sıktır. Dizinde hâlâ eski bir whitelist.json duruyor ve sunucu onun yerine onu okuyordur ya da XUID kaydı eksiktir veya yanlıştır. Xbox Live kimlik doğrulaması etkinken tek başına ad güvenilir biçimde yetmez.

“Saldırıya uğrayan ben olmama rağmen barındırıcım sunucumu kapattı”: Sunucunuzun kendisinin paket gönderip göndermediğini kontrol edin. 2024'ün RakNet amplifikasyon hatasında tam olarak bu oluyordu: Etkilenen sunucular yabancı adreslere binlerce paket gönderiyordu ve kötüye kullanım bildirimlerinde kaynak olarak 19132 portu yazıyordu. tcpdump -ni eth0 'udp src port 19132' -c 200 -q ile sunucunuzun nereye yanıt verdiğini görürsünüz. Güncel bir build nedeni ortadan kaldırır.

“iptables kurallarım etki etmiyor”: Üç neden sıktır. Kurallar UFW zincirlerinin arkasında duruyor ve hiç ulaşılmıyordur, son yeniden başlatmadan sonra kaybolmuşlardır (o zaman netfilter-persistent save komutu veya /etc/ufw/before.rules dosyasındaki bir kayıt yardımcı olur) ya da saldırı hacimseldir ve kural, zaten dolu olan bir hatta doğru biçimde çalışıyordur. iptables -L INPUT -n -v komutuyla eşleşme sayaçlarının artıp artmadığını kontrol edin. Sayaçlar sıfırda kalıyorsa kurala ulaşılmıyor.

“Sunucu listede duruyor, ama kimse içeri giremiyor”: Kayıt adı ve oyuncu sayısını gösteriyorsa Unconnected Pong çalışıyor, yani port temelde erişilebilir. Katılım buna rağmen başarısız oluyorsa sorun çoğunlukla Xbox Live oturum açmasında ya da allowlist'tedir. Tersine yalnızca IPv6 oyuncuları giremiyorsa 19133 UDP izni eksiktir.

“Sunucu çalışıyor, ama herkeste lag sıçramaları var”: Bu bir saldırıdan çok bir eklenti olur. Önce UDP soketinde Recv-Q değerinin büyüyüp büyümediğine ve UdpRcvbufErrors değerinin artıp artmadığına bakın. İkisi de sakin kalıyor ve sar -n DEV 1 10 dikkat çekmiyorsa bu bir DDoS saldırısı değil, sunucu sürecinin kendisiydi. Bedrock Dedicated Server'da o zaman betik watchdog'ları yardımcı olur; eşikleri server.properties dosyasında script-watchdog-hang-threshold ve script-watchdog-slow-threshold altında durur.

“Ö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.

“tcpdump çıktısında dikkat çekici bir şey görmüyorum”: Trafik zaten önündeki ağda filtreleniyorsa sunucuya beklendiği gibi hiçbir şey ulaşmaz. Filtreleme çalışırken normal durum budur. Tersi de geçerlidir: Hat doyuma ulaştığında, ölçüm yapmak istediğiniz SSH oturumu bile size ulaşmayabilir. O durumda müşteri panelindeki, konuk sistemin ağından bağımsız çalışan VNC konsolunu kullanın.

Kısaca özetle

• Bir Minecraft Bedrock sunucusunun dışarıya tam olarak bir açık porta ihtiyacı vardır: 19132 UDP, buna ek olarak yalnızca IPv6 oyuncuları için 19133 UDP. Query, RCON, 19144 TCP'deki betik hata ayıklayıcısı ve Geyser'in arkasında 25565 TCP'deki bir Java sunucusu açık ağa ait değildir.
• Portu taşıyan kişi enable-lan-visibility=false ayarlamak zorundadır, yoksa Bedrock Dedicated Server ek olarak 19132 ve 19133'e bağlanmaya devam eder.
• Xbox Live kimlik doğrulaması ile allowlist ancak giriş paketinde, yani RakNet bağlantı kurulumunun tamamlanmasından sonra etki eder. Oyun mantığınızı ve yerlerinizi korur, hattınızı korumaz.
• Unconnected Ping 33 baytla sorulur ve yaklaşık 131 baytla yanıtlanır, yani yaklaşık dört amplifikasyon faktörü. Kısa bir sunucu adı bu faktörü küçük tutar.
• UDP'de connlimit yerine hashlimit yardımcı olur ve kernel'in bağlantı izlemesi, sahte gönderen adreslerinde ilk olarak dolar. İkisini de ilk saldırıdan önce ölçmüş olmanız gerekir.
• Yaklaşık 1 Gbit/s'den sonra hattınız dolar ve 64 baytlık paketlerde oraya saniyede yaklaşık 1,49 milyon paket sığar. Bunun üzerinde yalnızca sunucunun önündeki ağda yapılan filtreleme belirleyicidir.
• KernelHost'ta iki kademeli sürekli koruma her sunucu paketinde dâhildir, teslimden itibaren etkindir ve null routing kullanmaz. Advanced DDoS Protection ise buna dedicated bir koruma IP'si ve port başına kendiniz yönetebileceğiniz kurallar ekler.

Projeniz 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.