İlk büyük DDoS saldırısı deneyimimi hâlâ saatine kadar hatırlıyorum: 2016 yılı, Cumartesi gecesi 23:47, müşterinin oyun sunucusu birden yanıt vermez oldu. Trafiği görmek için terminale baktığımda upstream link sıfır boşa çıkmıştı. O gece öğrendiğim ders bugün hâlâ geçerli: DDoS’a hazırlık olmadan, gerçek bir saldırı anında alınacak hiçbir aksiyon zamanında devreye giremez. Bu pillar sayfa, MikroTik üzerinde DDoS koruma stratejisi kurmak isteyen herkes için — küçük bir VPS’i ile büyüyen geliştiriciden, ulusal ölçekli operatöre kadar — başvurabileceğiniz bütüncül bir kaynak olarak hazırlandı.

Bu Rehber Kimler İçin Yazıldı?

DDoS koruma konusu, tek bir kullanıcı profiline hitap eden bir konu değil. Saldırılar boyut, vektör ve maliyet açısından muazzam çeşitlilik gösterdiği için, farklı ölçekteki organizasyonlar farklı katmanlara ihtiyaç duyar. Bu pillar sayfa şu okuyucu profillerine doğrudan değer üretecek şekilde planlandı:

• Oyun sunucusu operatörleri: SAMP, MTA, Metin2, CS:GO, Minecraft gibi platformlarda hedef alınma ihtimali yüksek olan, ve milisaniye gecikmenin oyuncu kaybına dönüştüğü ortamları işletenler.
• VPS/dedicated sunucu yöneticileri: Web uygulamaları, API sunucuları veya streaming altyapıları için bant genişliği bazlı saldırılara karşı kendi kenar koruma katmanını kurmak isteyenler.
• Hosting şirketleri ve veri merkezi mühendisleri: Çoklu müşteri ortamında, bir müşteriye gelen saldırının diğerlerini etkilememesi için segmentasyon ve mitigation tasarlayan altyapı sorumluları.
• ISS ve kurumsal ağ yöneticileri: Upstream provider seviyesinde başlayan, kenar router’a doğru inen kademeli savunma mimarisi kurmak zorunda olanlar.
• Siber güvenlik araştırmacıları: DDoS tehdit manzarasını izleyen, IoT botnet trendlerini ve modern amplifikasyon saldırılarını anlamak isteyenler.

Yıllar içinde gördüğüm en yaygın yanılgı şudur: “Cloudflare aldım, korunaklıyım.” Cloudflare ve benzeri CDN/scrubbing servisleri çok değerli koruma katmanlarıdır, ancak hiçbiri origin sunucunuza doğru bypass saldırılarını engellemez, hiçbiri TCP/UDP tabanlı oyun trafiğini doğal olarak korumaz, ve hiçbiri sizi origin IP’nizin sızdığı senaryolardan otomatik kurtarmaz. Kendi MikroTik kenar katmanınız, bu üst katmanların bıraktığı boşluğu doldurur.

DDoS Tehdit Manzarası: 2026 İtibarıyla Neye Bakıyoruz?

DDoS saldırı manzarası son beş yılda kökten değişti. IoT botnetlerinin yaygınlaşması (Mirai ve türevleri), saldırı bant genişliklerini terabit-saniye düzeyine çıkardı. Aynı zamanda, “DDoS-as-a-Service” platformları (booter/stresser servisleri) sayesinde saldırı satın alma maliyeti tarihsel olarak en düşük seviyede; bir saatlik 100 Gbps saldırı için ödenen ücret bazen 50 doların altına düşebiliyor. Bu, hedef olabilme eşiğini de düşürüyor: artık sadece bankalar ve hükümet siteleri değil, küçük oyun sunucuları veya bir tweetiniz sebebiyle hedef alınmış bir blog bile saldırıya uğrayabiliyor.

Bu manzaranın güncel haritasını, saldırgan motivasyonlarını, sektörel dağılımları ve korunma yatırımının nasıl önceliklendirilmesi gerektiğini detaylıca incelediğimiz 2026 DDoS tehdit manzarası yazımız, stratejik düşünmek isteyenler için zorunlu okumadır. BT bütçenizi savunurken bu içerikten alacağınız veriler, yöneticilerinize “neden bu yatırım gerekli?” sorusuna somut cevaplar vermenizi sağlayacaktır.

Genel MikroTik DDoS Koruma Yaklaşımı: Üç Katmanlı Savunma

Modern DDoS koruma mimarisi tek bir kuralın işi değil, birbirini tamamlayan üç katmandan oluşur: volumetric (hacimsel) saldırılar için bant genişliği koruması, protocol saldırıları için connection ve state limitleri, ve application-layer saldırıları için içerik bilinçli filtreleme. MikroTik’in her üç katmanda da güçlü olduğu yerler ve sınırlamaları vardır. Bunları net olarak bilmek, doğru beklenti yönetimi için kritiktir.

Bu üç katmanlı yaklaşımı uçtan uca anlatan MikroTik ile DDoS koruması: volumetric, protocol ve Layer-7 katmanlı savunma başlıklı yazımız, hangi vektöre karşı hangi RouterOS aracının çıkarılması gerektiğini örnek konfigürasyonlarla ortaya koyar. Bu yazı sayfa pillar’ımızın en önemli operasyonel referansıdır; sahaya inmeden önce mutlaka okuyun.

Genel mimari kararlardan biri de MikroTik’i nereye yerleştirdiğinizdir. Kenar router olarak mı, sunucunun hemen önünde dedicated mitigation cihazı olarak mı, yoksa upstream provider ile koordineli BGP blackhole mekanizmasının yerel ucu olarak mı? Bu konuyu, gerçek deployment senaryolarıyla işlediğimiz sunucu önünde MikroTik: DDoS mitigation, rate limit ve Geo-IP filtreleme yazımızda inceleyebilirsiniz.

Saldırı Vektörlerine Göre Derinlik: TCP, UDP ve Layer 7

“DDoS” tek bir saldırı türü değildir; onlarca farklı vektörün şemsiye terimidir. Her vektör farklı bir savunma yaklaşımı gerektirir, ve “tek tip” bir kural seti çalışmaz.

TCP tabanlı saldırılar — özellikle SYN flood, ACK flood ve TCP state-exhaustion — sunucunuzun connection table’ını doldurarak meşru kullanıcılara servis veremez hâle getirmeyi hedefler. MikroTik’in bu vektöre karşı üç katmanlı savunma stratejisini, TCP flood saldırıları ve MikroTik 3 katmanlı savunma yazımızda baştan sona açıklıyoruz. Bu yazı özellikle SYN cookie alternatiflerini, RAW table’ın TCP flag tabanlı erken-drop kullanımını ve connection-state ile birleştirilmiş hız sınırlandırmasını detaylıca işler.

UDP saldırıları ise hem oyun sunucularını hem de DNS amplifikasyonu gibi servisleri hedeflediğinde özellikle yıkıcıdır çünkü UDP’nin doğası gereği handshake yoktur — yani spoofed paketler kolayca üretilebilir ve büyük amplifikasyon oranlarıyla hedefe yönlendirilebilir. UDP flood saldırılarının anatomisi ve MikroTik ile aşırı düşük latency başlıklı yazımız, bu vektöre karşı RAW table optimizasyonlarını, conntrack bypass tekniklerini ve milisaniye altı reaksiyon süreleri için hardware offload kullanımını anlatır.

Sektörel Derinlik: Oyun Sunucuları

Oyun sunucuları DDoS saldırılarının en sık hedeflerinden biridir, ve kendine özgü zorluklar barındırır. Web sunucusu için 200ms gecikme tolere edilebilir; oyun sunucusu için 50ms bile felakettir. UDP tabanlı oyun protokolleri (Minecraft Bedrock, SAMP, MTA, CS:GO source engine) standart “block all UDP” yaklaşımına izin vermez; doğru paketleri tanıyıp yanlışları drop eden hassas filtrelemeye ihtiyaç duyarsınız.

Bu konuda referans niteliğindeki iki yazımız var. İlki, oyun sunucusu DDoS koruma: SAMP, MTA, CS:GO ve Minecraft için vaka analizleri, oyun türlerine göre özelleşmiş kural setlerini ve gerçek saldırı sonrası analizlerini içerir. İkincisi ise sahadan dokuz yıllık tek bir operatörün deneyimini damıttığımız Metin2 sunucu operatörü için DDoS koruma: 9 yıllık deneyim yazısı; bu içerik özellikle MMORPG/MMORTS operatörleri için altın değerinde bir referans niteliğindedir. İki yazıyı birlikte okumak, oyun sektöründe DDoS savunmasının kavramsal hem de pratik temelini oluşturmanızı sağlar.

Rate Limiting, Geo-IP ve Erken Filtreleme

Saldırı vektörü ne olursa olsun, ortak teknikler vardır. Rate limiting, connection limiting, Geo-IP tabanlı filtreleme bunların başında gelir. Türkiye odaklı bir oyun sunucusunun Çin’den gelen 50.000 connection isteğini reddetmesi tamamen meşrudur; saldırgan tarafının coğrafi imzasını bilmek savunmanızı çok güçlendirir. Ancak Geo-IP filtreleme yanlış kullanıldığında meşru CDN edge node’larını ya da VPN kullanan müşterilerinizi de bloklayabilir. Bu dengeyi anlamak gerekir.

Sunucu önü deploymentlarda kullanılacak rate limit, connection limit ve Geo-IP konularını derinlemesine işlediğimiz sunucu önünde MikroTik DDoS mitigation yazımız, bu pillar sayfanın operasyonel kalbidir. Bu içerikteki kural blokları kopyalanıp yapıştırılmak için değil, anlamlandırılarak adapte edilmek için yazılmıştır.

Olmazsa Olmaz: Görünürlük ve Erken Uyarı

Bir DDoS saldırısı, ancak fark edilirse müdahale edilebilir. MikroTik’in /tool traffic-monitor, /tool torch, /queue tree sayaçları ve SNMP ile dışa aktarılan istatistikler, erken uyarı için en güçlü araçlarınızdır. Bu sayaçları Zabbix, Grafana veya The Dude gibi platformlara aktararak eşik tabanlı alarmlar kurmak, gece 3’te saldırı başladığında telefonunuzun çalmasını sağlar. Bu küçük yatırım, saldırı süresince ortaya çıkacak hizmet kesintisini saatlerden dakikalara indirir.

Sıkça Sorulan Sorular

MikroTik tek başına 100 Gbps DDoS’u durdurabilir mi?

Hayır — ve bu MikroTik’in eksikliği değil, fiziğin sınırıdır. Eğer upstream link bant genişliğiniz 1 Gbps ise, 100 Gbps saldırı zaten siz fark etmeden ISS tarafında pipe’ı doldurmuştur. Volumetric saldırılarda gerçek çözüm upstream/scrubbing tabanlıdır (BGP blackhole, RTBH veya bir scrubbing servisi). MikroTik, hattınıza giren trafiği temizler ve protocol/application katmanı saldırılarını engeller; volumetric saldırılarda ISS ile koordinasyon şarttır.

Cloudflare yeterli değil mi, neden MikroTik’le uğraşayım?

Cloudflare HTTP/HTTPS trafiğini koruma konusunda mükemmeldir. Ancak: (1) origin IP’niz sızdığında doğrudan saldırıyı engelleyemez; (2) UDP tabanlı oyun trafiğini standart planlarla korumaz (Spectrum ayrı bir üründür ve ücretlidir); (3) TCP non-HTTP trafiğinde sınırlıdır. Kendi MikroTik kenar katmanınız bu boşlukları doldurur ve toplam savunmanızı çok daha sağlam hâle getirir.

RAW table ile filter table arasında ne fark var, hangi durumda hangisini kullanmalıyım?

RAW table connection tracking’den önce çalışır; bu, conntrack tablosunun saldırı altında dolup taşmasını engeller. DDoS savunmasında “ilk hat” RAW tablodur: bilinen kötü kaynaklar, hatalı paket türleri, brüt blacklisted IP’ler RAW’da drop edilmelidir. Filter table ise conntrack sonrası çalışır ve state tabanlı kararlar için kullanılır. Yüksek hacimli saldırılarda, drop kararının ne kadar erken alındığı CPU yükü açısından çok kritiktir.

FastTrack DDoS sırasında etkin tutulmalı mı, kapatılmalı mı?

Net cevap: FastTrack devredeyken connection-tracked paketler firewall filter zincirini büyük ölçüde bypass eder, yani bazı saldırı tespitleriniz çalışmayabilir. Üretimde dengeyi şöyle kurarım: normal koşulda FastTrack açık (performans için), ama saldırı anında otomatik olarak devre dışı bırakan bir tetikleyici script veya yapı bulunur. Bu, MikroTik’te scheduler ve scripting ile mümkündür. Tam otomasyona kadar gitmeyecekseniz, en azından el ile hızlıca kapatabileceğiniz bir prosedürünüz mutlaka olmalı.

Saldırı altında IP blacklisting’i otomatize etmenin riski nedir?

Risk: spoofed kaynak IP’lerle yapılan saldırılarda otomatik blacklisting meşru kullanıcıları engelleyebilir; saldırgan başkasının IP’sini kaynak göstererek “kollateral kayıp” yaratabilir. Bu sebeple otomatik blacklisting, address-list’lere kısa TTL (örneğin 1 saat) ile eklemeli, davranış pattern’i (paket sayısı, hız, çoklu hedef) gibi birden çok kriter sağlanmalı, ve mümkün olduğunda spoof-resistant vektörlere (TCP handshake tamamlanmış bağlantılar) öncelik vermelidir.

Sonuç ve Sonraki Adımlar

DDoS koruma, “bir kez kur, unut” bir sistem değildir. Saldırgan teknikleri her yıl evrildiği için, savunmanızın da evrilmesi gerekir. Bu pillar sayfa size konunun haritasını çıkardı — şimdi ölçeğinize ve riskinize göre öncelikleri belirleyin. Eğer yeni başlıyorsanız, başlangıç noktanız üç katmanlı savunma genel rehberimiz ve sunucu önü mitigation yazımız olmalıdır. Sektörünüze özel derinlik için oyun sunucusu vakaları ve Metin2 deneyim yazısı referans olacaktır.

Önemli bir hatırlatma: DDoS koruması, firewall stratejinizden ayrı bir disiplin değildir; onun içinde, ona entegre çalışır. DDoS kuralları yazarken connection tracking, chain mantığı, action öncelikleri gibi konularda derin bir firewall anlayışı şarttır. Bu sebeple sizi Firewall ve MikroTik Güvenlik Rehberi pillar sayfamıza da yönlendirmek istiyorum. İki pillar birlikte, MikroTik üzerinde modern ağ güvenliği mimarisi kurmak için ihtiyacınız olan haritayı oluşturur.

Son söz: hazırlığın değerini saldırı anında ödersiniz. Sakin bir Pazar günü oturup test ortamında saldırı simülasyonu yapan, yapılandırmalarını dökümante eden ve ekibinde “saldırı anı playbook’u” bulunan operatörler, gerçek olay anında soğukkanlı kararlar alır. Hazırlıksız olanlar ise panik içinde meşru trafiği de bloklayarak saldırıya katkıda bulunurlar. Hangi kategoride olacağınız, bugün yapacağınız hazırlıkla belirlenir.