DDoS savunması yapmak için önce bir DDoS saldırısı düşünmek zorundasınız. Ben kariyerimde ofansif güvenlik tarafından geldim; CEH ve OSCP eğitimlerinden sonra ilk yıllarımı pentest ve kırmızı takım operasyonlarında geçirdim. O dönem, “bir hedefi nasıl çökertirim” sorusunu binlerce kez sordum. Bugün masanın diğer tarafındayım: hizmet sağlayıcılara, oyun sunucusu operatörlerine ve e-ticaret platformlarına MikroTik tabanlı DDoS mitigation mimarileri kuruyorum. Bu yazı, o iki perspektifi tek bir savunma reçetesinde birleştirme girişimimdir. Hedef, MikroTik üzerinde volumetric, protocol ve uygulama katmanı (Layer-7) saldırılara karşı katmanlı bir savunma kurmak ve her katmanın neden orada olduğunu yapısal nedenlerle açıklamaktır.

Saldırı Tipolojisini Yeniden Tanımlamak

Endüstride “DDoS” kelimesi son derece kötü kullanılıyor. Birisi web sitesi yavaşlayınca “saldırıya uğradık” derken aslında bant genişliğinin tıkandığını, başka birisi “DDoS yedik” derken sadece TCP bağlantı havuzunun tükendiğini kastedebilir. Etkili bir savunma için saldırıyı üç ana kategoriye ayırmalısınız:

• Volumetric saldırılar: Hattı tıkamayı hedefler. Saniyede 50 Gbps UDP flood, hattınız 10 Gbps ise, anlamlıdır. Saldırgan amaç olarak bant genişliğinizi sömürür.
• Protocol saldırıları: TCP, ICMP, UDP gibi katman 3/4 protokollerinin zayıflıklarını sömürür. SYN flood, ACK flood, fragmented packet saldırıları bu kategoridedir. Saldırgan amaç olarak işletim sisteminizin veya firewall’unuzun state tablosunu tüketir.
• Layer-7 saldırıları: HTTP, DNS, TLS gibi uygulama protokollerini kullanarak az veri ile çok kaynak tüketmeyi hedefler. Slowloris, HTTP flood, RUDY saldırıları örnektir. Saldırgan amaç olarak uygulama sunucusunun CPU ve thread havuzunu çökertir.

Her kategori farklı bir savunma katmanı ister. MikroTik, ilk iki kategoride mükemmel, üçüncü kategoride sınırlı ama kritik bir rol oynar. Mimarinizin bu gerçeği yansıtması gerekir.

Volumetric Saldırılar: Hattınız Ne Kadar Tıkanabilir?

Saldırgan açısından volumetric saldırı en ucuz olanı: stresser servislerinden 50 dolara saatlik 100 Gbps trafik kiralayabilirsiniz. UDP amplification (DNS, NTP, Memcached, CLDAP) kullanılarak saldırgan birkaç yüz Mbps gerçek trafikle hedefte yüzlerce Gbps üretebilir. Geçen yıl analiz ettiğim bir vakada, oyun sunucusu operatörü müşterimiz 47 saniye boyunca 78 Gbps Memcached amplification saldırısına uğradı. Üst akış sağlayıcısı 10 Gbps üzeri trafiği zaten karaya alıyordu, dolayısıyla hattınızdan önce trafik elenmişti, ancak hattan içeri sızan 9.4 Gbps bile MikroTik CCR2116’nın packet processing kapasitesini önemli ölçüde zorladı.

Burada anlaşılması gereken kritik nokta şudur: MikroTik kendi başına 100 Gbps gelen volumetric saldırıyı duramaz. Hattınız zaten 10 Gbps ise, 100 Gbps gelirse hattınız tıkanır ve MikroTik kuralları yazsa bile fark yaratamaz çünkü trafik ona ulaşamadan upstream’de tıkanmıştır. Bu nedenle volumetric savunmanın ilk katmanı upstream provider ile yapılan anlaşmadır. ISP’nizden BGP RTBH (Remotely Triggered Black Hole) veya FlowSpec desteği isteyin; bu sayede saldırı sırasında belirli IP’lere veya port:protokol kombinasyonlarına gelen trafiği ISP omurgasında karaya aldırabilirsiniz.

MikroTik tarafında volumetric saldırılara karşı ilk savunma raw chain’idir. Raw chain, connection tracking devreye girmeden önce paketleri elemenize izin verir; bu, CPU başına işlenen paket sayısını ciddi şekilde azaltır. Tipik bir raw konfigürasyonu:

/ip firewall raw
add chain=prerouting action=drop src-address-list=bogon_list comment="Drop bogon sources"
add chain=prerouting action=drop protocol=udp src-port=11211 comment="Memcached amplification"
add chain=prerouting action=drop protocol=udp src-port=389 comment="CLDAP amplification"
add chain=prerouting action=drop protocol=udp src-port=19 comment="Chargen amplification"
add chain=prerouting action=drop protocol=udp src-port=1900 comment="SSDP amplification"
add chain=prerouting action=drop protocol=udp src-port=123 dst-port=!123 comment="NTP reflection"
add chain=prerouting action=drop protocol=udp src-port=53 dst-port=!53 comment="DNS reflection"
add chain=prerouting action=drop protocol=udp src-port=27015 dst-port=!27015 comment="Source Engine amplification"

Bu kurallar, en yaygın UDP amplification vektörlerinin kaynak portlarından gelen trafiği daha conntrack işlemeden düşürür. Gerçek bir Memcached amplification paketinin anatomisini açayım: saldırgan 200 byte’lık spoofed UDP isteği gönderir, kaynak port olarak 11211 (Memcached) görünür. Hedef sunucu, daha önce cache’lenmiş bir veri varsa 50 KB – 1 MB arası yanıt döndürür, bu da 250x’e varan amplifikasyon oranı demektir. Eğer iç ağınızda Memcached sunucusu çalıştırmıyorsanız (ki çoğu kullanıcı çalıştırmaz), kaynak portu 11211 olan tüm UDP paketleri yasal trafik değildir.

Protocol Saldırıları: State Tablosu Savaşı

Protocol seviyesi saldırılarda kazanan, daha büyük state tablosuna sahip olandır. SYN flood saldırısında saldırgan size yüz binlerce yarı-açık TCP bağlantısı gönderir; her bağlantı sunucunuzda bir slot tutar. Eğer TCP backlog kuyruğunuz dolarsa, yasal kullanıcı SYN paketleri reddedilir. Linux çekirdeğinde tipik backlog limiti 256, optimize edilmiş bir sunucuda 65536’ya çıkarılabilir. Saldırgan yüzbinlerce SYN gönderirse hala başarısız olabilirsiniz.

MikroTik’te SYN flood’a karşı klasik savunma connection-state=new + connection-limit kombinasyonudur. Şu kural setini incelerseniz mantığı anlayacaksınız:

/ip firewall filter
add chain=forward action=jump jump-target=syn-protect protocol=tcp tcp-flags=syn connection-state=new
add chain=syn-protect action=add-src-to-address-list address-list=syn-attackers 
    address-list-timeout=10m connection-limit=30,32 protocol=tcp 
    comment="30 yarı-açık bağlantı eşiği"
add chain=syn-protect action=drop src-address-list=syn-attackers comment="Drop blacklisted"
add chain=syn-protect action=jump jump-target=tcp-syncookies protocol=tcp tcp-flags=syn

/ip firewall mangle
add chain=prerouting action=mark-packet new-packet-mark=syn-flood protocol=tcp tcp-flags=syn 
    connection-state=new tcp-mss=!1460 comment="Spoofed SYN'ler genelde anormal MSS taşır"

Burada 30 yarı-açık bağlantı eşiği üretim ortamı için makul başlangıçtır. Ancak SYN flood’un asıl çözümü syncookiestır. RouterOS 7.x’te /ip settings altında tcp-syncookies=yes aktifleştirildiğinde, MikroTik kendisi kapalı portlara gelen SYN paketlerine syncookie ile yanıt verir ve state oluşturmadan saldırıyı emer.

ICMP flood için yaklaşım daha basit: trafik gerçekten gerekli mi? Çoğu kurumsal ağda dış dünyadan içeri ICMP echo-request kabul etmek mecbur değildir. Rate-limit ile sınırlamak iyi başlangıçtır:

/ip firewall filter
add chain=input action=accept protocol=icmp icmp-options=8:0 limit=10,5:packet 
    comment="Saniyede 10 ping isteğine izin ver"
add chain=input action=drop protocol=icmp icmp-options=8:0 
    comment="Fazlasını düşür"

ACK flood, RST flood gibi varyantlar için connection-state=invalid filtresi mükemmel iş çıkarır. Geçerli bir bağlantıya ait olmayan ACK paketleri tanım gereği saldırı paketidir:

/ip firewall filter
add chain=forward action=drop connection-state=invalid comment="Invalid state drop"
add chain=input action=drop connection-state=invalid comment="Invalid state drop input"

Fragmented packet saldırıları için raw chain’de fragment’leri tamamen reddedebilirsiniz. Modern uygulamaların büyük çoğunluğu MTU keşfi ile çalışır ve fragment üretmez. Fragmented gelen trafik genellikle taban tarafından MTU manipülasyonu yapan saldırgandır:

/ip firewall raw
add chain=prerouting action=drop fragment=yes comment="Fragmented packet drop"

Layer-7 Saldırıları: MikroTik Nereye Kadar?

Burada dürüst olmak gerekir: MikroTik tam anlamıyla bir L7 WAF değildir. HTTP içeriği analiz edip “bu istek SQL injection mı, yoksa yasal mı” diye karar veremez. Ancak L7 saldırılarının önemli bir kısmı protokolün kendisinden çok davranışsal anomaliler içerir. Slowloris saldırısında saldırgan, HTTP başlığını saniyeler arayla küçük parçalar halinde gönderir; sunucu bağlantıyı bekler ve thread havuzu tükenir. Burada MikroTik connection-limit ile çok şey yapabilir.

HTTP flood karşı MikroTik’i web sunucusu önüne yerleştirip per-IP bağlantı sayısını sınırlamak etkilidir. Aşağıdaki konfigürasyon, web sunucularımız önünde aktif olarak kullanıyoruz:

/ip firewall filter
add chain=forward action=add-src-to-address-list address-list=http-flooders 
    address-list-timeout=30m protocol=tcp dst-port=80,443 
    connection-limit=50,32 comment="50'den fazla eşzamanlı bağlantı kuran IP'yi listele"
add chain=forward action=drop src-address-list=http-flooders 
    comment="HTTP flood liste"

# TLS handshake flood
add chain=forward action=add-src-to-address-list address-list=tls-flooders 
    address-list-timeout=15m protocol=tcp dst-port=443 
    connection-state=new tcp-flags=syn 
    limit=100,200:packet comment="Saniyede 100 TLS handshake eşiği"

Bunlar tek başına yeterli değildir. L7 katmanında en az iki ek katman gerekir: web sunucusu önünde NGINX/HAProxy rate limit ve önünde Cloudflare/Akamai gibi bir CDN+WAF. MikroTik’in görevi, “açıkça anormal” davranışı erken kesmek ve yasal trafiği WAF’a iletmektir.

Gerçek bir PCAP Analizi: 14 Mart Saldırısı

Hizmet verdiğim bir e-ticaret müşterisi 14 Mart 2025’te ilginç bir saldırıyla karşılaştı. Hibrit bir saldırıydı: ilk dakika saf SYN flood, ikinci dakika DNS amplification, üçüncü dakikadan itibaren Slowloris benzeri uzun başlık HTTP flood. Saldırgan açıkça katmanlı savunmayı test ediyordu. PCAP dosyasından örnek bir SYN paketini incelersek:

Frame: 60 bytes on wire
Ethernet II, Src: 00:0c:29:1a:2b:3c
Internet Protocol Version 4, Src: 198.51.100.42, Dst: 203.0.113.10
    Time to live: 246 (anomali: çoğu yasal trafik TTL 64 veya 128'den başlar, 246 kontrol edilmiş)
    Identification: 0x0000 (anomali: gerçek OS'lar artan ID üretir, sabit 0 spoof işareti)
Transmission Control Protocol, Src Port: 27834, Dst Port: 443, Seq: 0
    Flags: 0x002 (SYN)
    Window size value: 65535
    Maximum segment size: 1400 (anomali: standart 1460, 1400 unusual değer)

Bu paketin üç anomalisi vardı: TTL 246 (genelde 64/128’den başlar ama 246 spoofing indikatörü), IP identification 0x0000 sabit, MSS 1400. MikroTik mangle chain’inde bu üç koşulu birden taşıyan paketleri işaretleyip drop ederek saldırının %94’ünü filtreledik. Geri kalan %6 yasal görünümlü trafikti, conn limit ile temizlendi.

İkinci dalga DNS amplification içindi. Tipik bir paket 60 byte istek karşılığında 3000+ byte yanıt üretiyordu. Kaynak portu 53 olan tüm UDP paketleri raw chain’de düşürüldü çünkü iç ağda DNS server yoktu. Üçüncü dalga Slowloris benzeriydi; her saldırgan IP saniyede 1-2 yeni HTTP bağlantısı açıp asla tamamlamıyordu. Burada connection-limit=20,32 + 60 saniye timeout ile saldırı sönümlendi.

Threshold Ayarlarını Nasıl Belirlersiniz?

“30 connection-limit yazdım, doğru mu?” sorusunun cevabı yok, çünkü doğru değer trafiğinize bağlı. Önce baseline belirlemelisiniz. Şu komutla normal koşullarda ortalama bağlantı sayınızı görebilirsiniz:

/ip firewall connection print count-only
/ip firewall connection print where dst-port=443
/tool profile interface=ether1 duration=60

Saldırı altında olmayan bir günde, en yoğun saatte web sunucunuza bir IP’den gelen maksimum eşzamanlı bağlantı sayısını ölçün. NAT arkasındaki büyük bir kurumsal müşteri için bu 80-100 olabilir; bireysel ev kullanıcısı için 10-20. Threshold’unuzu bu sayının 3-4 katı civarında ayarlayın. 100 yasal bağlantınız varsa 300-400 connection-limit makul. Daha düşük tutarsanız NAT’lı yasal kullanıcıları engellersiniz; daha yüksek tutarsanız saldırı algılamaz.

Rate limit için aynı mantık: günlük trafiğinizin tepe noktası ne? Saniyede 500 istek ortalama yapan bir e-ticaret sitesi için packet-rate 2000/s threshold mantıklı. Geleneksel olarak limit=X,Y:packet formatında X istenen tepe, Y burst değeridir. Burst’u istek başına büyük tutmak yasal trafik için nefes alanı bırakır.

Address-list Otomasyonu ve Otomatik Mitigation

El ile saldırı tespiti yapmak yorucu. MikroTik’te scripting ve scheduler ile otomatik mitigation kurabilirsiniz. Şu script her dakika çalışıp ortalama paket oranını ölçer, eşiği aşarsa daha agresif kuralları aktifleştirir:

/system script
add name=ddos-watch source={
    :local pktrate [/interface monitor-traffic ether1 once as-value]
    :local pps ($pktrate->"rx-packets-per-second")
    :if ($pps > 100000) do={
        :log warning "DDoS suspected: $pps pps"
        /ip firewall filter set [find comment="ddos-mode"] disabled=no
        /ip firewall raw set [find comment="aggressive-mode"] disabled=no
    } else={
        /ip firewall filter set [find comment="ddos-mode"] disabled=yes
        /ip firewall raw set [find comment="aggressive-mode"] disabled=yes
    }
}

/system scheduler
add name=ddos-monitor interval=1m on-event=ddos-watch

Bu yaklaşım, saldırı yokken filtreleri kapalı tutar ve sadece yüksek trafik dalgalarında devreye sokar. Yanlış pozitif riski azalır, normal trafik için CPU kullanımı düşük kalır.

Felaket Senaryosu: Tüm Katmanlar Aynı Anda Çöktüğünde

Mükemmel mimari yoktur. Bazı durumlarda saldırgan hattınızı doldurur, ISP-level black hole zamanında devreye girmez, MikroTik CPU’nuz %100’e gider ve siz Winbox’a bile bağlanamazsınız. Bu senaryoda hazırlığınız şu olmalı:

• Out-of-band yönetim: MikroTik’inizin serial console portunu USB-to-serial adaptör ile bağlı tutun. Network çökse bile ulaşabilirsiniz.
• Yedek BGP path: Çift ISP kullanıyorsanız, saldırı altında etkilenen ISP’den prefix’i geri çekip diğeri üzerinden trafiğinizi yönlendirebilirsiniz.
• Maintenance modu: Web sunucularınızda statik bir maintenance sayfası tutun. Saldırı uzun sürerse dinamik backend yerine bu sayfayı sunarak en azından “sistem yaşıyor” mesajı verin.
• Yedek dosyalar: Tüm firewall yapılandırmasının export’unu otomatik olarak günlük alın ve harici sunucuya yedekleyin. Saldırı altında configurasyon bozulursa hızla geri yükleyebilirsiniz.

CHR ve BGP FlowSpec ile Bulut Tarafında Savunma

Daha büyük altyapılar için fiziksel MikroTik yetersiz kalabilir. CHR (Cloud Hosted Router) lisansını upstream ISP’nizin bulut altyapısına yerleştirip BGP FlowSpec ile dinamik kurallar enjekte edebilirsiniz. Saldırı tespit edildiğinde MikroTik bir FlowSpec rule yayar, upstream router’lar bu kuralı tanıyıp trafiği daha içerideyken karaya alır. Bu özellik özellikle terabit ölçekli saldırılarda hayat kurtarır.

FlowSpec konfigürasyonu için temel komutlar:

/routing bgp peer
add name=upstream remote-address=192.0.2.1 remote-as=64500 
    address-families=ip,ipv6,flowspec

/routing bgp flowspec
add name=block-udp-amplification match-rule="protocol=udp and src-port=11211 or src-port=389 or src-port=1900" 
    action=traffic-rate rate=0

İzleme ve Loglama: Saldırıdan Sonrası

Her saldırı bir öğrenme fırsatıdır. MikroTik’te tüm drop’ları loglarsanız log diski hızla dolar. Bunun yerine sadece istatistik tutun:

/ip firewall filter
add chain=forward action=add-src-to-address-list address-list=blocked-attackers 
    address-list-timeout=24h comment="İstatistik için"

# Saldırı sonrası analiz
/ip firewall address-list print where list=blocked-attackers count-only

Saldırı sonrası bu listeyi dışa aktarıp coğrafi dağılım, ASN dağılımı, IP reputation analizleri yapın. Hangi botnet aktif, hangi ülkelerden geliyor, ileride benzer saldırılar için baseline geliştirin.

Daha gelişmiş kullanım için MikroTik’i NetFlow veya sFlow exporter olarak yapılandırıp dışarıdaki bir analiz aracına (örneğin ntopng) trafik gönderebilirsiniz. Bu sayede paket düzeyinde değil akış düzeyinde uzun vadeli analiz yapabilirsiniz.

SSS: MikroTik DDoS Koruma Hakkında Sık Sorulanlar

MikroTik tek başına 100 Gbps DDoS saldırısını durdurabilir mi?

Hayır. Fiziksel hattınız 10 Gbps ise hattınız 100 Gbps öncesinde tıkanır. MikroTik bu boyutta bir saldırıyı tek başına duramaz. ISP BGP RTBH veya FlowSpec ile upstream’de filtreleme şarttır. MikroTik’in işi sızan trafiği temizlemek ve protokol seviyesinde sertleştirmektir.

Raw chain mi filter chain mi daha iyi?

Her ikisini birlikte kullanırsınız. Raw chain connection tracking devreye girmeden önce çalışır; CPU tasarrufu sağlar. Açıkça atılması gereken trafik (bogon, amplification kaynak portları, fragmented paketler) raw’da düşürülmelidir. Filter chain ise connection state’e bağlı kararlar verebildiği için yasal uzun ömürlü bağlantıları korumakta daha hassastır.

Hangi MikroTik modeli DDoS savunması için uygundur?

Trafik hacminize bağlıdır. 1 Gbps altı için hAP ax3 veya RB4011 yeterli. 1-10 Gbps için CCR2004 serisi. 10-100 Gbps arası için CCR2216, CCR2116. 100 Gbps üstü için CHR + BGP FlowSpec mimarisi gerekir. CPU paket işleme kapasitesi anahtar metrik; saniyede milyonlarca paket işleyebilen modeller tercih edin.

Connection-limit ne kadar olmalı?

Trafiğinizin baseline’ına bağlı. Tipik web sunucusu için per-IP 100-300 makul. NAT arkasındaki büyük kurumsal müşterileri kapsayan e-ticaret için 500-1000. Çok düşük tutarsanız yasal NAT kullanıcıları engellersiniz; çok yüksek tutarsanız saldırgan rahat eder.

Syncookies aktif olunca yan etki olur mu?

Minimal. Syncookies sadece backlog dolduğunda devreye girer; normal trafik için fark yok. Yan etkisi olarak TCP timestamp ve SACK gibi bazı opsiyonlar geçici olarak müzakere edilemez ama modern client/server bunu sorunsuz handle eder.

Layer-7 saldırılarına karşı MikroTik yetersiz mi?

Tek başına yetersiz. MikroTik davranışsal anomalileri (yüksek bağlantı sayısı, anormal istek paterni) kesebilir ama HTTP içeriği derinlemesine analiz edemez. Tam koruma için MikroTik + NGINX rate limit + WAF (Cloudflare, ModSecurity) üçlüsü gerekir.

BGP FlowSpec her ISP destekliyor mu?

Hayır, ne yazık ki değil. Türkiye’de Telia, Cogent gibi Tier 1 sağlayıcılar destekler, ancak yerel ISP’lerin çoğu desteklemiyor. ISP’nizle anlaşma yaparken BGP RTBH (en azından /32 black hole community desteği) ve mümkünse FlowSpec destek olup olmadığını mutlaka sorun.

Saldırı sonrası nasıl forensik analiz yaparım?

MikroTik’in /tool sniffer aracını saldırı sırasında PCAP dosyasına yazdırın, daha sonra Wireshark veya tshark ile analiz edin. Address-list dökümlerini ASN/coğrafi bilgi ile zenginleştirin. NetFlow exporter kullanıyorsanız ntopng veya ElastiFlow üzerinden uzun vadeli akış analizi yapın. Her saldırı, bir sonrakini daha iyi karşılamak için veridir.

Sonuç: Katmanlı Savunma Bir Felsefedir

DDoS koruması tek bir cihaz veya konfigürasyon değildir. ISP anlaşmanız, MikroTik raw chain’iniz, filter chain’iniz, scripting’iniz, web sunucusu rate limit’iniz, CDN/WAF’ınız ve operasyonel hazırlığınızın bütünüdür. Saldırgan, en zayıf halkayı arar; sizin işiniz, her halkayı kabul edilebilir bir güvenlik seviyesine çıkarmak. Bu yazıda paylaştığım reçeteler ofansif perspektiften test edilmiş, gerçek saldırılarda denenmiştir. Yine de unutmayın: tehdit manzarası her hafta değişir. Bugünün best practice’i yarının zayıflığı olabilir. Düzenli olarak konfigürasyonunuzu gözden geçirin, yeni amplification vektörlerini takip edin ve test ortamınızda kendi sisteminize saldırın. En iyi savunma, kendi sisteminizin saldırgan gözüyle görülmesidir.

Aynı Konuda Diğer Yazılarımız

Konuyu daha geniş ele almak için aşağıdaki yazılarımıza da göz atabilirsiniz:

• TCP Flood Saldırıları: MikroTik 3 Katmanlı Savunma — TCP SYN, ACK, RST flood saldırılarına karşı MikroTik üzerinde RAW, Filter, Mangle ile 3 ka
• Oyun Sunucusu DDoS Koruma: SAMP, MTA, CS:GO, Minecraft için Vakalar ve Konfigürasyonlar — SAMP, MTA, CS:GO, Minecraft, Rust gibi oyun sunuculari icin MikroTik tabanli DDoS koruma:
• 2026 DDoS Tehdit Manzarası: Trendler, Saldırgan Profili ve Korunma Yatırımı Mantığı — Cloudflare, NETSCOUT ve Akamai raporlari isiginda 2024-2026 DDoS trendleri, botnet evrimi,
• Sunucu Önünde MikroTik: DDoS Mitigation, Rate Limit ve Geo-IP Filtreleme Mimarisi — Hosting saglayicilari icin sunucu onunde MikroTik mimarisi: raw chain filtreleme, Geo-IP,

Kaynaklar ve Daha Fazla Bilgi

Bu yazıdaki konuları derinleştirmek için aşağıdaki otoriter kaynaklara başvurabilirsiniz:

• Cloudflare DDoS Threat Report
• NETSCOUT Threat Intelligence
• CISA DDoS Best Practices
• NIST Cybersecurity Framework
• OWASP Foundation