Minecraft Sunucusunda Bot Saldırısı ve Korunma

Minecraft bot saldırısı, sahte istemcilerin sunucunuza arka arkaya bağlanarak giriş kuyruğunu, ana tick döngüsünü ve ağ katmanını boğmasıdır. Klasik bir DDoS’tan ayrılan yanı şu: gelen trafiğin hacmi çok düşüktür, hattınız dolmaz, sunucu dışarıdan bakınca çalışıyor görünür. İçeride ise hiçbir şey yürümez. Bu yüzden hacimsel saldırıları temizleyen filtreler bot selini çoğu zaman meşru trafik sanıp geçirir.

Bu sayfa baştan sona savunma tarafındadır. Saldırının hangi biçimlerde geldiğini, loglarda nasıl göründüğünü ve hangi katmanda hangi ayarla durdurulacağını anlatır. Saldırı aracı adı, saldırı yöntemi tarifi ya da "nasıl yapılır" içeriği burada yok.

Destek taleplerinde en sık gördüğümüz tablo şu: sunucuya bot giriyor, yönetici saatlerce eklenti deniyor, ama giriş hızı hiçbir katmanda sınırlanmamış durumda. Tek bir ayar çoğu zaman yükün yarısını alıyor.

Bot Saldırısı Neden Sizi Hedef Alır?#

Sebep neredeyse hiçbir zaman teknik değildir. Minecraft sunucularına yönelik bot saldırılarının kaynağı üç yerden birindir: banlanan bir oyuncu, rakip bir sunucu ya da sunucunuzun adresini bir yerde görüp "denemek" isteyen biri. Ölçek de buna göre küçüktür; genellikle birkaç yüz sahte bağlantıdan ibarettir.

Bu kötü haber değil aslında. Küçük ölçekli olması, doğru yapılandırılmış bir sunucunun bu saldırıları oyuncular fark etmeden savuşturabileceği anlamına gelir. Sorun, çoğu sunucunun varsayılan ayarlarla çalışıyor olması. Vanilla ve Paper varsayılanları normal bir topluluk için ayarlanmıştır, kötü niyetli bir bağlantı seli için değil.

Bir diğer nokta: sunucunuz offline-mode (cracked) çalışıyorsa hedef olma ihtimaliniz belirgin şekilde yüksektir. Oturum doğrulaması olmadığı için sahte istemci üretmenin maliyeti neredeyse sıfırdır.

Bot Saldırısının Dört Tipik Biçimi#

Hepsine "bot saldırısı" deniyor ama davranışları farklı, dolayısıyla savunmaları da farklı. Ayırt etmek müdahalenin yarısıdır.

Giriş-çıkış seli (join flood)#

En yaygın olanı. Rastgele kullanıcı adlarıyla yüzlerce bağlantı açılır, her biri giriş sürecini tetikler ve saniyeler içinde kopar. Sunucu her bağlantı için oyuncu verisi okur, spawn chunk’larını hazırlar, entity oluşturur ve olay dinleyicilerini çalıştırır. Tick süresi uzar, TPS düşer, gerçek oyuncular "Connecting to the server..." ekranında bekler.

Sohbet spam botu#

Bağlanan sahte hesaplar sohbet kanalını doldurur. Yük olarak join flood kadar ağır değildir ama topluluğu doğrudan rahatsız eder; ayrıca sohbet dinleyicisi olan her eklenti (Discord köprüsü, log eklentisi, sohbet biçimlendirici) her mesaj için çalışır ve zincirleme bir maliyet doğar.

Sunucu listesi sorgu seli#

Burada bağlantı hiç kurulmaz. Sunucunun durum (status) yanıtı ya da GameSpy query portu arka arkaya sorgulanır. Sunucu her sorguda MOTD’yi, oyuncu listesini ve favicon’u paketleyip yollar. Belirtisi tuhaftır: oyuncu sayısı normaldir, TPS iyidir, ama sunucu listelerinde adresiniz yavaş yanıt verir veya hiç görünmez.

Ping flood#

Bağlantı el sıkışmasının en ucuz aşamasında kalan, sürekli tekrarlanan yoklama trafiğidir. Ağ iş parçacığını meşgul eder. Genelde tek başına gelmez; join flood’un yanında bir gürültü katmanı olarak görülür.

Loglarda Nasıl Görünür?#

Teşhis için logs/latest.log dosyasına bakmak yeterlidir. Join flood’un imzası çok belirgindir: anlamsız kullanıcı adları, saniyeler içinde tekrarlanan giriş-çıkış çiftleri ve genellikle aynı ya da yakın IP blokları.

[21:14:07] [Server thread/INFO]: qZ7xKp11[/45.12.0.0:51122] logged in with entity id 3418 at (120.5, 68.0, -230.5)
[21:14:07] [Server thread/INFO]: qZ7xKp11 lost connection: Disconnected
[21:14:07] [Server thread/INFO]: qZ7xKp11 left the game
[21:14:08] [Server thread/INFO]: mB2vTr49[/45.12.0.0:51139] logged in with entity id 3419 at (120.5, 68.0, -230.5)
[21:14:08] [Server thread/INFO]: mB2vTr49 lost connection: Disconnected
[21:14:08] [Server thread/INFO]: mB2vTr49 left the game
[21:14:09] [Server thread/WARN]: Can't keep up! Is the server overloaded? Running 4212ms or 84 ticks behind

Dikkat edilecek üç işaret var. Birincisi, kullanıcı adlarının rastgele karakter dizisi olması. İkincisi, giriş ile çıkış arasında hiç oyun etkinliği bulunmaması. Üçüncüsü, Can’t keep up! uyarısının bu selle aynı saniyelerde başlaması. Log okumanın tamamı için sunucu logu okuma rehberimize bakın.

Kaç farklı IP’den geldiğini görmek isterseniz, Linux tarafında hızlı bir sayım yeterli olur:

grep "logged in with entity id" logs/latest.log \
  | grep -o '/[0-9.]\+:' | tr -d '/:' | sort | uniq -c | sort -rn | head -20

ss -tn state established '( sport = :25565 )' \
  | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Katman 1: Proxy Tarafında Bağlantı Hız Sınırı#

Bir sunucu ağı işletiyorsanız savunmanın en verimli yeri proxy’dir. Velocity, aynı IP adresinden gelen giriş denemeleri arasında zorunlu bir bekleme süresi uygular; bu değeri yükseltmek join flood’un maliyetini doğrudan artırır.

# velocity.toml
online-mode = true
player-info-forwarding-mode = "modern"
kick-existing-players = false
ping-passthrough = "DISABLED"

[advanced]
login-ratelimit = 8000
connection-timeout = 5000
read-timeout = 20000
compression-threshold = 256

[query]
enabled = false

login-ratelimit milisaniye cinsindendir ve varsayılanı 3000’dir. Saldırı altında 8000–10000 aralığına çekmek makul bir tepkidir; normal oyuncular bunu fark etmez çünkü kimse saniyede birkaç kez giriş denemez. ping-passthrough değerini DISABLED tutmak da önemlidir: proxy kendi ping yanıtını verir, arka uç sunucular sorgu selinden hiç etkilenmez.

Proxy mimarisini kurarken arka uç portlarının dışarıya kapalı olduğunu mutlaka doğrulayın. Kurulumun tamamı BungeeCord ve Velocity rehberinde.

Katman 2: Paper Tarafında Giriş ve Paket Sınırları#

Proxy kullanmıyorsanız bu katman sizin ilk savunmanız. Paper’ın config/paper-global.yml dosyası, tick başına kaç oyuncunun sunucuya alınacağını ve bir istemcinin kaç paket gönderebileceğini belirler.

misc:
  max-joins-per-tick: 2

packet-limiter:
  all-packets:
    action: KICK
    interval: 7.0
    max-packet-rate: 350.0
  kick-message: "&cCok fazla paket gonderildi."
  overrides:
    ServerboundPlaceRecipePacket:
      action: DROP
      interval: 4.0
      max-packet-rate: 5.0

max-joins-per-tick varsayılanı 5’tir. 2’ye düşürdüğünüzde bot bağlantıları kuyruğa girer ve zaman aşımına uğrar; gerçek oyuncular ise en fazla birkaç yüz milisaniye fazladan bekler. Sohbet spam’i için config/paper-world-defaults.yml tarafındaki sınırlayıcıyı sıkılaştırın:

spam-limiter:
  tab-spam-increment: 2
  tab-spam-limit: 300
  recipe-spam-increment: 2
  recipe-spam-limit: 20
  incoming-packet-threshold: 200

server.properties tarafında da birkaç anahtar doğrudan bu konuyla ilgilidir:

online-mode=true
prevent-proxy-connections=true
enable-query=false
enable-status=true
rate-limit=500
network-compression-threshold=256
player-idle-timeout=15

rate-limit varsayılan olarak 0’dır, yani kapalıdır. Bir değer verdiğinizde aşan istemci atılır. prevent-proxy-connections=true ise oturum doğrulamasındaki ağ bilgisiyle bağlantının geldiği ağ uyuşmuyorsa girişi reddeder — VPN üzerinden gelen meşru oyuncuları da etkileyebileceğini bilerek açın. Tüm liste server.properties ayarları sayfasında.

Katman 3: Anti-Bot Eklentileri ve Doğrulama Adımları#

Eklenti tabanlı savunmanın mantığı basit: bağlanan istemciden, gerçek bir oyuncunun kolayca yapabileceği ama otomatik bir istemcinin yapmakta zorlanacağı bir şey istemek. Uygulamada üç yaklaşım görüyoruz.

Eklenti seçerken tek bir kurala uyun: 26.2 uyumluluğunu kendi gözünüzle doğrulayın. 26.1 ile birlikte Mojang obfuscated sunucu jar’ı yayınlamayı bıraktı ve bu bir ABI kırılması yarattı; NMS kullanan eski eklentiler yeniden derlenmeden çalışmaz. Anti-bot eklentileri paket katmanına dokunduğu için bu kırılmadan en çok etkilenen grupta yer alıyor. Hangar veya SpigotMC’deki sürüm etiketine bakın, "çalışıyor herhalde" diyerek üretim sunucusuna atmayın.

Katman 4: IP Başına Bağlantı Limiti ve Firewall Kuralı#

Buraya kadar anlatılanlar bağlantı sunucuya ulaştıktan sonra devreye giriyordu. Güvenlik duvarı katmanı ise paketin Java sürecine hiç uğramadan düşmesini sağlar; bu yüzden en ucuz savunmadır.

Linux tarafında iki kural işi büyük ölçüde çözer: aynı IP’den açılabilecek eşzamanlı bağlantı sayısını sınırlamak ve yeni bağlantı hızına tavan koymak.

# Aynı IP'den en fazla 3 eşzamanlı bağlantı
sudo iptables -A INPUT -p tcp --syn --dport 25565 \
  -m connlimit --connlimit-above 3 --connlimit-mask 32 -j REJECT --reject-with tcp-reset

# Aynı IP'den dakikada en fazla 6 yeni bağlantı (10'luk tolerans ile)
sudo iptables -A INPUT -p tcp --syn --dport 25565 \
  -m hashlimit --hashlimit-name mcjoin --hashlimit-mode srcip \
  --hashlimit-above 6/minute --hashlimit-burst 10 -j DROP

sudo iptables-save | sudo tee /etc/iptables/rules.v4

Aile içinde ya da aynı okul ağında oynayan oyuncuların tek IP’den geleceğini unutmayın. --connlimit-above 3 küçük bir topluluk için uygundur; kalabalık bir sunucuda 5–8 arası daha güvenlidir. Değeri düşürüp bırakmak, saldırı geçtikten sonra "neden bazı oyuncular giremiyor" sorusunun en sık cevabıdır.

Windows tarafında Gelişmiş Güvenlik Duvarı üzerinden kaynak IP kısıtlaması yapılabilir, ancak bağlantı sayısına göre sınırlama seçeneği yoktur. Windows sunucularda bu işi genellikle sağlayıcının filtresi ya da önde duran bir proxy üstlenir. Kural yazımının tamamı firewall yapılandırma rehberinde.

Tekrarlayan saldırılarda log tabanlı otomatik engelleme de işe yarar: bir dakika içinde çok sayıda bağlantı kesme kaydı üreten IP’leri Fail2Ban ile geçici olarak engelleyebilirsiniz.

Katman 5: Sağlayıcının Filtreleme Katmanı#

Bot trafiği düşük hacimlidir, bu doğru. Ama saldırgan hedefine ulaşamadığında genellikle bir üst tura çıkar ve hacimsel trafik eklenir. O noktada sunucunuzun içindeki hiçbir ayarın hükmü kalmaz; paketin makineye ulaşmadan temizlenmesi gerekir.

Bu yüzden sunucu sağlayıcısı seçerken filtreleme katmanı bir yan özellik değil, temel gerekliliktir. Bakılacak noktalar: filtrenin otomatik devreye girip girmediği, oyun protokolünü tanıyıp tanımadığı ve saldırı bittiğinde normal profile dönüp dönmediği. Batihost’un Minecraft sunucu paketlerinde filtreleme altyapı seviyesinde çalışır ve ek ücret istemez.

Saldırı sürüyorsa ve elinizdeki katmanlar yetmiyorsa destek talebi açarken şunları ekleyin: saldırının başlangıç saati, latest.log dosyasından bir kesit, bağlantı sayımı çıktısı ve varsa tekrarlayan IP blokları. Bu bilgilerle filtre profili çok daha isabetli ayarlanır.

Beş katmanı bir arada görmek işi kolaylaştırıyor:

Acil Fren: Beyaz Liste#

Saldırı devam ederken en hızlı ve en kesin çözüm beyaz listedir. Kayıtlı olmayan bağlantı, oyuncu verisi yüklenmeden reddedilir; yani sunucu neredeyse hiç iş yapmaz.

whitelist on
whitelist add OyuncuAdi
whitelist reload
whitelist list

Beyaz liste açıkken mevcut oyuncularınız oynamaya devam eder, yeni kayıt duraklar. Saldırı bitene kadar açık tutun, ardından kapatın. Bu süreyi boşa harcamayın: kalıcı katmanları tam da bu aralıkta kurun. Ayrıntı için beyaz liste rehberine bakın.

Bir de şu var: sunucunuzun adresi ne kadar açıkta duruyorsa hedef olma ihtimali o kadar yüksektir. Ham IP paylaşmayı bırakıp alan adına geçmek, saldırı anında IP değiştirme seçeneğini de masaya koyar. Yöntemler IP gizleme ve koruma sayfasında.

Yanlış Pozitifler ve Saldırı Sonrası Normale Dönüş#

Sıkılaştırılmış ayarlar, saldırı bittikten sonra unutulursa kendi oyuncularınızı vurmaya başlar. Sunucusu aylardır "yavaş yavaş oyuncu kaybediyor" diyen yöneticilerin bir kısmında sorun tam olarak budur: bir yıl önceki saldırıda konulan agresif limitler hala yerinde duruyor.

Saldırıdan sonra şu listeyi geçin:

• Beyaz listeyi kapatın. Yeni oyuncu alımı durmuş olmasın.
• max-joins-per-tick değerini geri alın. Yoğun saatte giriş kuyruğu oluşuyorsa 2 çok düşüktür.
• connlimit değerini gözden geçirin. Aynı evden oynayan kardeşler ve internet kafeler tek IP’den gelir.
• Görsel doğrulamayı kapatın. Kalıcı captcha, yeni oyuncu kaybının sessiz sebebidir.
• Fail2Ban engel listesini temizleyin. Haksız yere engellenmiş oyuncu olabilir.
• Notlarınızı saklayın. Saldırı saati, süresi, hangi önlemin işe yaradığı. Tekrarlayan saldırılarda kalıp çıkar.

Yanlış pozitifi anlamanın en pratik yolu, kendi oyuncularınızdan gelen "giremiyorum" mesajlarını ciddiye almaktır. Bir oyuncu adresi doğru yazdığı hâlde bağlanamıyorsa, atlanmış birşey vardır ve bu genellikle sizin koyduğunuz limittir.

Özetle#

Bot saldırısı, az trafikle çok iş yaptırma sanatıdır; savunması da az ayarla çok iş engellemekten geçer. Önce biçimini teşhis edin: giriş seli mi, sohbet spam’i mi, sorgu seli mi? Sonra doğru katmana müdahale edin. Giriş seli için proxy’de login-ratelimit ve Paper’da max-joins-per-tick, sohbet için spam-limiter, sorgu seli için enable-query=false, hepsinin altında güvenlik duvarında IP başına bağlantı limiti.

Tek bir katmana güvenmeyin. Anti-bot eklentisi harika çalışabilir ama bir sürüm geçişinde bozulur; firewall kuralı sağlamdır ama aynı IP’den gelen meşru oyuncuyu da etkiler; beyaz liste kesindir ama büyümeyi durdurur. Üst üste dizildiklerinde biri düştüğünde diğeri tutar — savunmanın işi zaten bu. Genel sunucu sertleştirme adımları için güvenlik rehberimize, hile ve istismar tarafı için anticheat eklentileri sayfasına göz atın.