UDP flood saldırıları, ofansif güvenlik perspektifinden bakıldığında en sevimsiz davranan saldırı kategorisidir. Saldırgan için neredeyse maliyetsiz, savunan için ise minimum latency hedefinde olan herkes için kabus. Çünkü UDP, doğası gereği bağlantısız; her paket bağımsız değerlendirilir, state tutmaz, kolayca spoof edilebilir. Bu yazıda UDP flood ailesinin teknik anatomisini paket düzeyinde inceleyeceğim, en yaygın amplification vektörlerini açacağım ve MikroTik üzerinde aşırı düşük latency hedefli (oyun sunucusu, VoIP, finansal trading) ortamlarda nasıl koruma sağlayacağımızı reçete halinde paylaşacağım. Bu içerik, pentest sırasında defalarca kendi sistemlerimizde test ettiğim çözümlere dayanıyor.

UDP Protokolünün Anatomisi: Neden Bu Kadar Saldırıya Açık?

TCP’nin three-way handshake’i (SYN, SYN-ACK, ACK) saldırgan için bir engeldir; çünkü TCP bağlantısı kurmak için saldırgan kendi IP’sinden gerçek paket gönderip yanıt almak zorunda. Spoofed (sahte kaynak IP’li) TCP saldırısı bağlantı kuramaz, sadece SYN flood yapabilir. UDP’de bu engel yok: saldırgan istediği kaynak IP’yi yazıp herhangi bir hedefe paket gönderebilir. Hedef “bu IP’den geldi mi gerçekten?” diye sorgulayamaz çünkü UDP’de oturum yok.

UDP başlığı sadece 8 byte: source port (2), destination port (2), length (2), checksum (2). TCP’nin 20+ byte başlığına kıyasla minimum overhead. Saldırgan açısından bu, aynı bant genişliğinde daha fazla paket göndermek demek; aynı 1 Gbps bant ile UDP üzerinden TCP’ye göre ~%2.5 daha fazla paket sığar. PPS (paket/saniye) tabanlı saldırılarda bu fark anlamlıdır.

UDP’nin saldırı için bir başka avantajı amplification potansiyelidir. Bazı UDP servisleri (DNS, NTP, Memcached, CLDAP, SSDP, CHARGEN) küçük bir isteğe büyük bir yanıt döner. Saldırgan kaynak IP’yi hedefin IP’si olarak spoof eder, açık bir public servera istek gönderir, server cevabı hedef IP’ye atar. Saldırgan 1 Gbps gerçek trafik üretip hedefe 50-500 Gbps’lik yanıt yağdırabilir.

Amplification Vektörleri: Kim Ne Kadar Büyütür?

Şu tablo, US-CERT ve Cloudflare’in 2024 raporlarına göre güncel amplifikasyon faktörlerini özetliyor:

Memcached saldırısının paketteki anatomisini açayım. Saldırgan şu yapıda bir UDP isteği gönderir:

UDP istek paketi (kurbana yansiyan):
  Kaynak IP (spoofed): 198.51.100.10 (hedef IP)
  Hedef IP: 203.0.113.20 (acik Memcached sunucu)
  Kaynak port: 11211
  Hedef port: 11211
  Payload: "x00x00x00x00x00x01x00x00statsrn"
  Toplam paket boyutu: ~50 byte

Memcached sunucu yaniti (hedefe gider):
  Kaynak IP: 203.0.113.20 (sunucu)
  Hedef IP: 198.51.100.10 (kurban, spoofed olan)
  Kaynak port: 11211
  Hedef port: 11211
  Payload: Cache icindeki tum istatistikler veya cached object'ler
  Toplam paket boyutu: 50KB - 1MB

1 MB / 50 byte = 20,000x amplification. Saldırgan 100 Mbps gerçek trafik üretirse, hedefe potansiyel olarak 2 Tbps yanıt yağabilir. 2018’de GitHub’un yaşadığı 1.35 Tbps saldırı tamamen Memcached amplification kaynaklıydı.

Bu noktada anlaşılması gereken kritik şey: siz hiç Memcached çalıştırmıyor olabilirsiniz; ama hala kaynak portu 11211 olan UDP paketleri size geliyor olabilir. Çünkü saldırgan dünyada açık herhangi bir Memcached sunucusunu kullanıyor, paketi size yansıtıyor. Sizin işiniz, beklemediğiniz kaynak portlardan gelen UDP trafiğini reddetmek.

DNS Amplification: Hala En Yaygın Vektör

DNS amplification, 20+ yıldır kullanılan ama hala çok yaygın saldırı vektörü. Saldırgan, hedef IP’sini kaynak olarak spoof eden bir DNS sorgusu yapar. Yanıt boyutunu maksimize etmek için “ANY” tipi sorgu ya da DNSSEC imzalı kayıt sorgular. Tipik bir paket:

DNS sorgu (spoofed):
  Soru: "isc.org" ANY (yaklaşik 80 byte)

DNS yanit (hedefe):
  Tum A, AAAA, MX, NS, TXT, DNSKEY, RRSIG kayitlari
  ~3000-4000 byte
  Amplification: ~50x

Modern open resolver sayısı 2016’da 28 milyondan 2024’te 1.2 milyona düştü (Shadowserver verilerine göre). Ancak bu hala devasa bir saldırı havuzu. Resolver’ları kapatmak operatör sorumluluğu; ancak siz saldırı kurbanı olarak resolver kapatmaya yardım edemezsiniz. Yapacağınız tek şey kaynak portu 53 olan beklenmedik UDP paketlerini reddetmektir.

NTP Amplification: Eski Ama Hala Tehlikeli

NTP’nin monlist komutu (eski versiyonlarda) bir sunucunun en son etkileşim kurduğu 600 IP’yi liste halinde döner. Tek istek 234 byte, yanıt 50KB+. 200x+ amplification. Modern NTP sunucuları (ntp-4.2.7p26+) monlist’i varsayılan olarak kapatır, ancak güncellenmemiş on binlerce sunucu hala savunmasız durumda.

Saldirgan paketi (NTP control mode):
  ntpdc komutu: MON_GETLIST_1
  Boyut: 234 byte

Hedef yaniti:
  Maks 600 IP listesi
  Boyut: 50,000+ byte
  Amplification: ~213x

UDP Flood Hedefleri: Aşırı Düşük Latency Ortamlar

UDP saldırıları en çok şu hedeflere zarar verir:

• Oyun sunucuları: Çoğu oyun protokolü UDP (CS:GO 27015, Minecraft 25565, GTA SAMP 7777, Metin2 13000+, Fortnite custom UDP). Oyuncu deneyimi 50ms üzeri ping’te bozulur; 200ms üzerinde oyun oynanamaz hale gelir.
• VoIP servisleri: SIP (5060), RTP (10000-20000 random) UDP üzerinden çalışır. Paket kaybı %1 üzerinde sesli iletişim bozulur, %3 üzerinde çağrı düşer.
• DNS sunucuları: DNS UDP üzerinden çalışır; saldırı altında DNS yanıt veremezse tüm bağımlı servisler etkilenir.
• WireGuard VPN sunucuları: WireGuard UDP 51820 üzerinden çalışır. Saldırı altında VPN bağlantısı kesilirse uzaktan çalışanlar etkilenir.
• QUIC/HTTP3 web sunucuları: Yeni web altyapısı UDP 443 üzerinden çalışır. QUIC tabanlı saldırı vektörleri 2025’te %600+ arttı.
• Finansal trading altyapıları: Bazı market data feed’leri UDP multicast. Mikrosaniye düzeyinde gecikme bile milyon dolarlık zarara yol açabilir.

MikroTik ile UDP Flood Mitigation: Reçete

UDP flood’a karşı en etkili yer raw chain’dir. Connection tracking aktive olmadan paketi reddetmek, hem CPU’yu rahatlatır hem de state tablosu doldurulmasını engeller. Temel raw chain konfigürasyonu:

/ip firewall raw
# Bilinen amplification kaynak portlari
add chain=prerouting action=drop protocol=udp src-port=11211 
    comment="Memcached amplification"
add chain=prerouting action=drop protocol=udp src-port=123 dst-port=!123 
    comment="NTP reflection (hedef 123 disindaysa)"
add chain=prerouting action=drop protocol=udp src-port=53 dst-port=!53 
    comment="DNS reflection (hedef 53 disindaysa)"
add chain=prerouting action=drop protocol=udp src-port=389 
    comment="CLDAP amplification"
add chain=prerouting action=drop protocol=udp src-port=1900 
    comment="SSDP amplification"
add chain=prerouting action=drop protocol=udp src-port=19 
    comment="CHARGEN amplification"
add chain=prerouting action=drop protocol=udp src-port=17 
    comment="QOTD amplification"
add chain=prerouting action=drop protocol=udp src-port=161 
    comment="SNMP amplification"
add chain=prerouting action=drop protocol=udp src-port=520 
    comment="RIPv1 amplification"

# Fragment'leri tamamen reddet
add chain=prerouting action=drop protocol=udp fragment=yes 
    comment="UDP fragment drop"

# Servis disindaki UDP portlari icin baseline rate limit
add chain=prerouting action=jump jump-target=udp-defense protocol=udp

Spesifik koruma için her hedef portu için ayrı rate limit kuralı:

/ip firewall raw
# DNS sunucumuz icin per-source rate limit
add chain=udp-defense action=add-src-to-address-list address-list=dns-flooders 
    address-list-timeout=10m protocol=udp dst-port=53 dst-address=203.0.113.10 
    limit=20,40:packet 
    comment="Saniyede 20 DNS sorgu esigi"

add chain=udp-defense action=drop src-address-list=dns-flooders 
    protocol=udp dst-port=53 dst-address=203.0.113.10 
    comment="DNS flooder drop"

# Oyun sunucusu UDP 27015 icin
add chain=udp-defense action=add-src-to-address-list address-list=game-flooders 
    address-list-timeout=5m protocol=udp dst-port=27015 dst-address=203.0.113.20 
    limit=60,120:packet 
    comment="Saniyede 60 paket esigi (CS:GO normalde 30-50 pps)"

add chain=udp-defense action=drop src-address-list=game-flooders 
    protocol=udp dst-port=27015 dst-address=203.0.113.20 
    comment="Game flood drop"

# WireGuard VPN icin
add chain=udp-defense action=add-src-to-address-list address-list=vpn-flooders 
    address-list-timeout=15m protocol=udp dst-port=51820 
    limit=10,20:packet 
    comment="Saniyede 10 handshake esigi"

Burada threshold’lar çok kritik. CS:GO oyuncusu normal koşullarda saniyede 30-50 paket gönderir. 60’lık eşik %20-100 marj sağlar. WireGuard handshake saniyede 1 kez yapılır; saldırgan ise saniyede binlerce handshake denemesi yapar. 10/saniye eşiği yasal kullanıcıyı etkilemez.

Conntrack Tablosu Korumak: Stateful Filtering Nasıl Patlamaz?

UDP flood en yıkıcı etkilerinden birisi conntrack tablosunu doldurmaktır. Her UDP paketi conntrack’te bir entry yaratır; default timeout 10 saniye. Saniyede 100,000 UDP paketi gelirse, 10 saniyede 1 milyon entry üretir; bu CCR2004’ün default conntrack limit’ini (1M) tamamen doldurur. Yeni yasal bağlantılar conntrack’a giremez, drop olur.

Çözüm üç katmanlı:

• UDP timeout düşürmek: 10 saniyeden 5 saniyeye indirin. Tablo daha hızlı temizlenir.
• UDP no-track: Korunmadığınız UDP portlar için raw chain’de notrack kullanın. Conntrack hiç oluşmaz.
• Conntrack limit artırmak: Donanım kapasiteniz izin veriyorsa max-entries değerini 2M-4M’ye çıkarın.

/ip firewall connection tracking
set udp-timeout=5s
set udp-stream-timeout=2m
set generic-timeout=5m

# Memory-permitting modellerde
set max-entries=2097152

/ip firewall raw
# Korumadigimiz UDP icin notrack
add chain=prerouting action=notrack protocol=udp 
    src-port=11211,389,1900,19,17,520 
    comment="Amplification kaynak portlari conntrack disinda"

add chain=output action=notrack protocol=udp dst-port=33434-33523 
    comment="Traceroute icin notrack"

Bu üçünü birlikte uygulayınca conntrack tablonuz UDP saldırısı altında bile sağlıklı kalır.

Performance Testi: Korumalı vs Korumasız

Production öncesi bir test laboratuarında MikroTik CCR2004 üzerinde yaptığımız UDP flood testleri:

Sonuç çok net: raw chain ve notrack’in latency üzerinde dramatik etkisi var. Yalnız filter chain kullanımı yasal trafiği 45x yavaşlatırken, raw chain + notrack kombinasyonu sadece 1.5x yavaşlatıyor. Oyun sunucusu için 3ms ile 45ms arasındaki fark, oyuncu deneyimini kurtaran ile kaybeden arasındaki fark anlamına gelir.

Aşırı Düşük Latency için Özel Optimizasyonlar

Oyun sunucuları ve finansal altyapılarda her milisaniye değerlidir. Tipik MikroTik ayarlarının ötesinde şu optimizasyonları uygulayın:

• Hardware queue priority: Oyun trafiğine HW queue üzerinde en yüksek öncelik verin.
• MSS clamping: Tüm WAN interface’lerinde MSS clamp 1460 (veya MTU – 40) aktif olsun.
• Disable software queue scheduling: Hardware ile yapılabilenleri hardware’de yapın.
• Buffer küçültme: Default buffer’lar büyük, latency için küçültün.

/queue type
add name=game-priority kind=pfifo pfifo-limit=10

/queue tree
add name=game-traffic parent=ether1-wan packet-mark=game-pkt 
    priority=1 queue=game-priority max-limit=100M

/ip firewall mangle
add chain=prerouting action=mark-packet new-packet-mark=game-pkt 
    protocol=udp dst-port=27015,7777,25565,13000-14000 
    passthrough=no comment="Oyun trafigi isaretleme"

/interface ethernet
set ether1-wan rx-flow-control=auto tx-flow-control=auto

/ip settings
set tcp-syncookies=yes

BGP FlowSpec ile Upstream’de UDP Flood Filtreleme

Yerel olarak filtrelediğiniz UDP flood hattınızı tıkamış olabilir. Asıl çözüm upstream’de filtrelemektir. BGP FlowSpec destekleyen ISP’lerle çalışıyorsanız, MikroTik üzerinden dinamik kurallar enjekte edebilirsiniz:

/routing bgp flowspec
add name=block-udp-amp 
    match-rule="protocol=udp and src-port=11211,389,1900,19,17 and dst-port-range=any" 
    action=traffic-rate rate=0

add name=block-ntp-reflect 
    match-rule="protocol=udp and src-port=123 and dst-port-range=not 123" 
    action=traffic-rate rate=0

add name=block-large-udp-fragments 
    match-rule="protocol=udp and packet-length=1500-9000 and is-fragment" 
    action=traffic-rate rate=0

Bu FlowSpec kuralları upstream router’lara enjeke edilir, trafik daha hattınıza ulaşmadan filtre edilir. ISP’nizin BGP FlowSpec desteğini doğrulamak için BGP peer konfigürasyonunda address-families=ip,flowspec olmalı.

Saldırı Sırasında Canlı Müdahale

Saldırı tespit edildiğinde manuel müdahale için hazır komut takımı:

# Canli trafik gozlemleme
/tool sniffer quick interface=ether1-wan protocol=17

# En cok paket gonderen kaynak IP'leri
/ip firewall connection print where protocol=udp count-only
/ip firewall connection print stats where protocol=udp

# Manuel acil filtreleme - belirli IP'leri drop
/ip firewall address-list add list=manual-block address=AAA.BBB.CCC.DDD comment="Acil"
/ip firewall raw add chain=prerouting action=drop src-address-list=manual-block

# Belirli portu komple kapatma (gecici)
/ip firewall raw add chain=prerouting action=drop protocol=udp dst-port=53 
    src-address=!192.0.2.0/24 comment="DNS sadece anlasmali musteriden"

Bu komutlar ile saldırı anında 30 saniye içinde mitigation devreye alınabilir. Otomatik script ile birlikte (kelime sınırına göre tetiklenen scheduler), insan müdahalesi gerekmeden saldırılar büyük ölçüde sönümlenir.

Anycast ve UDP: Saldırıyı Coğrafi Olarak Dağıtmak

Yüksek hacimli UDP servisleri (özellikle authoritative DNS, public DNS resolver) anycast altyapıda barındırılmalı. Anycast ile aynı IP adresi birden çok lokasyonda ilan edilir; kullanıcı en yakın lokasyondaki sunucuya yönlendirilir. Saldırı altında bile saldırı trafiği coğrafi olarak dağıldığı için tek nokta tıkanması olmaz.

MikroTik BGP ile anycast yapılandırma için temel adımlar:

# Iki ayri DC'de iki ayri MikroTik
# DC1 - MikroTik
/routing bgp template
set default disabled=no router-id=10.0.1.1 as=64500

/routing bgp connection
add name=upstream-dc1 remote.address=192.0.2.1 remote.as=64600 
    address-families=ip output.network=203.0.113.0/24

# Anycast prefix announce
/ip address add address=203.0.113.100/32 interface=loopback comment="Anycast service IP"

# DC2 - MikroTik (aynisi)
/routing bgp template
set default disabled=no router-id=10.0.2.1 as=64500

/routing bgp connection
add name=upstream-dc2 remote.address=192.0.2.2 remote.as=64700 
    address-families=ip output.network=203.0.113.0/24

/ip address add address=203.0.113.100/32 interface=loopback comment="Anycast service IP"

Bu yapıda 203.0.113.100 IP’si hem DC1 hem DC2’den ilan edilir. Saldırı geldiğinde trafik upstream BGP routing tablolarında en yakın hop’a gider; saldırgan IP’leri farklı kıtalardan geliyorsa otomatik olarak saldırı iki DC arasında bölünür.

SSS: UDP Flood Hakkında Sık Sorulanlar

UDP saldırılarını TCP’ye göre daha mı zor durdurmak?

Evet. TCP’de three-way handshake state oluşturur; saldırgan kendi IP’sinden yanıt almak zorunda. UDP’de state yok; saldırgan spoof edilmiş kaynak IP ile paketi gönderir, hedef savunamaz. Bu nedenle UDP koruma reaktif değil, proaktif (kaynak port + rate limit tabanlı) olmak zorunda.

Memcached’i hiç kullanmıyorum, neden korumalıyım?

Çünkü saldırgan dünyanın herhangi bir yerindeki açık Memcached sunucusunu kullanır, paketi size yansıtır. Sizin Memcached çalıştırmanız önemli değil; saldırgan kaynak portu 11211 olan UDP paketleri size atar. Bu paketleri reddetmek hayati önem taşır.

Raw chain mi mangle chain mi daha hızlı?

Raw chain. Mangle conntrack tabanlıdır; paket önce conntrack’a girer, sonra mangle uygulanır. Raw conntrack’tan önce çalışır; CPU işlemi minimum.

UDP flood altında oyun ping’im neden yükseliyor?

Çünkü conntrack tablonuz doluyor veya CPU paket işleme kuyruğu doluyor. Yasal oyun paketi içeri girmek için kuyrukta bekliyor; bekleme süresi ping olarak görünüyor. Çözüm raw chain + notrack + hardware queue priority.

BGP FlowSpec her ISP’de var mı?

Hayır. Türkiye’de Telia, Cogent gibi Tier 1 sağlayıcılar destekler. Yerel ISP’lerin çoğu desteklemez. ISP’nizle sözleşmeden önce sorun.

QUIC saldırıları nasıl filtrelenir?

QUIC UDP 443 üzerinden çalışır. Connection migration özelliği nedeniyle TCP’ye göre daha karmaşık. Şimdilik QUIC tabanlı saldırılar için en iyi koruma rate limit + CDN edge mitigation. MikroTik tek başına QUIC handshake’ini analiz edemez.

Conntrack max-entries değerini artırmanın yan etkisi var mı?

Bellek tüketimi artar. Her entry yaklaşık 300 byte. 2M entries = 600MB RAM. CCR2004 4GB RAM’e sahip, sorun yok. Daha küçük cihazlarda donanım sınırına dikkat.

Tüm UDP’yi kapatabilir miyim?

Servisinize bağlı. DNS, NTP, oyun, VoIP UDP gerektirir. Web sunucusu için (HTTP/1, HTTP/2) UDP gerekmez, kapatabilirsiniz. HTTP/3 kullanıyorsanız UDP 443 açık olmalı.

Sonuç: UDP Flood ile Yaşamayı Öğrenmek

UDP flood saldırıları, internet altyapısının yaşadığı sürece var olacak bir gerçeklik. TCP gibi bağlantı yönelimli bir protokole geçilemez; UDP’nin sunduğu düşük overhead ve hız, oyun ve gerçek zamanlı uygulamalar için vazgeçilmez. Bu yüzden saldırıları “yok etmek” yerine “yaşanabilir hale getirmek” hedefine odaklanmalıyız. Bu yazıdaki reçeteler raw chain, notrack, conntrack tuning, hardware queue priority ve BGP FlowSpec gibi katmanlı tekniklerin kombinasyonu ile UDP flood saldırılarının yasal trafik üzerindeki etkisini minimize etmeyi amaçlar. Sayısal performans testleri, doğru konfigürasyonun aşırı düşük latency hedeflerinde bile mitigation sağlayabildiğini gösteriyor. Önemli olan, herhangi bir konfigürasyonu uygulamadan önce kendi trafiğinizin baseline’ını ölçmek, threshold’ları kalibre etmek ve saldırı simülasyonu yaparak gerçek koşullarda test etmektir. UDP flood ile yaşamak, savunulan tarafın daima öğrenmeye ve adapte olmaya açık olmasıyla mümkündür.

Bu Konuda Daha Fazla

Bağlantılı kavramları daha derinden işleyen yazılarımız: Metin2 Sunucu Operatörü için DDoS Koruma: 9 Yıllık Deneyimden Pratik Mitigation Reçetesi; 2026 DDoS Tehdit Manzarası: Trendler, Saldırgan Profili ve Korunma Yatırımı Mantığı; Sunucu Önünde MikroTik: DDoS Mitigation, Rate Limit ve Geo-IP Filtreleme Mimarisi.

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
• Wikipedia: Network Address Translation
• Wikipedia: OSI Model