DDoS Saldırısı: Korunma, Kapasite ve Bildirim Rehberi

DDoS konuşmaları neredeyse her zaman bir terabit sayısıyla başlıyor: 31,4 Tbps, 14,1 milyar paket/saniye, 35 saniye süren tek bir saldırı. Oysa bir şirketin sistemini kapatan olay genellikle bu sayıların anlatmadığı bir şeyden kaynaklanıyor. 2026'nın üçüncü çeyreğinde ağ katmanındaki saldırıların yüzde 96'sı on dakikadan kısa sürdü ve yüzde 98'i bir gigabit/saniyenin altında kaldı. Orta ölçekli bir ofisin hattını doldurmak için tek bir gigabit yeter, on dakika ise çoğu kurumun olayı fark etmesinden daha kısa.

Bu yazı bir "hangi ürünü alalım" metni değil. Saldırıyı üç ölçülebilir sayı ve bir kanıt zinciri olarak ele alıyor: tepe paket hızının orijin sunucunuzun durum tablosu sınırlarına oranı, saldırı süresinin sizin müdahale sürenize oranı ve kesinti maliyetinin kontrolün fiyatına oranı. Bu üç oranı bilmeden alınan hiçbir koruma kararı savunulabilir değil - ne teknik olarak, ne de bir denetimde.

Türkiye tarafında işi acil hâle getiren bir gelişme var: 2026'nın ilk yarısında Türkiye, Cloudflare'in ağında en çok DDoS saldırısı alan üçüncü ülke oldu; rapor bunu Temmuz'daki Ankara NATO Zirvesi'yle aynı döneme koyuyor. Bu, ülkedeki her kurumun hedef olduğu anlamına gelmiyor; "hedef olmak için ilginç olmak gerekmiyor, erişilebilir olmak yetiyor" tespitinin bu coğrafyada daha pahalıya geldiği anlamına geliyor.

DDoS'u "bant genişliği" sanmak neden pahalıya çıkıyor

Denetimlerde en sık duyduğumuz cümle şu: "DDoS korumamız var." Bu cümle bir kontrolü değil, bir satın alma işlemini anlatıyor. Kontrolün var olduğunu göstermek için üç soruya yazılı cevap gerekir: hangi katmanda hangi eşikte devreye giriyor, devreye girme kararını kim ya da ne veriyor, ve kararın verildiği ana kadarki süreyi hangi kayıt gösteriyor.

Bunun pratikteki karşılığı şu: bir kurum hacimsel temizleme hizmeti alır, kendini korunmuş sanır, sonra arama uç noktasına gelen saniyede kırk bin istekle kapanır. Hacimsel olarak büyük hiçbir şey olmamıştır. Hat yüzde iki kullanımdadır. Veritabanı yüzde yüz kullanımdadır. Faturayı ödeyen kontrol, olayın hiç görmediği katmanda duruyordur.

İkinci yaygın hata, korumayı bir kapasite sorunu olarak çerçevelemek. Oysa bu işin kapasite kısmı en kolay satın alınan kısmı. Zor olan üç şey var ve hiçbiri tedarikçiyle çözülmüyor: orijin adresinizin gizli kalması, yetkili DNS'inizin ayakta kalması ve olay anında kimin neyi kaç dakikada yapacağının önceden yazılmış olması.

Türkiye neden artık daha sık hedefte: 2026 telemetrisi

En geniş sürekli örneklem Cloudflare'in ağı ve bu ağ taraflı bir örneklem: kendi müşterilerine yapılan saldırıları ve çok büyük miktarda arka plan gürültüsünü görüyor. Yine de yönü gösteriyor. Yayımlanan rakamlar şöyle:

• 2026 ilk yarısı: 23,2 milyon ağ katmanı saldırısı, saatte yaklaşık 5.343 saldırı. Bir terabitin üzerine çıkan 935 saldırı; ikinci çeyrekte 805 saldırı, yani bir önceki çeyreğe göre yüzde 519 artış.
• Vektör ağırlığı değişti: ağ katmanı trafiğinin yüzde 34,3'ü DNS kaynaklı. Yalnızca DNS flood saldırıları çeyrekten çeyreğe yüzde 25,7'den yüzde 40,0'a çıktı. CLDAP yansıtma saldırıları yüzde 580 artarak ikinci çeyreğin üçüncü vektörü oldu.
• Türkiye üçüncü sırada: ilk yarıda en çok saldırı alan ülkeler sıralamasında Türkiye üçüncü sıraya yükseldi; rapor bunu Temmuz'daki Ankara NATO Zirvesi'yle ilişkilendiriyor.
• 2026 üçüncü çeyreği: 18,2 milyon ağ katmanı saldırısı, saatte 8.226 saldırı, ortalama 0,44 saniyede bir. Aynı çeyrekte saldırıların yüzde 96'sı on dakikadan kısa sürdü, yüzde 98'i bir gigabitin altında kaldı, DNS flood yüzde 39,3 ile en sık vektör olmayı sürdürdü.
• Rekor: Aralık 2025'te 31,4 Tbps ve 14,1 milyar paket/saniye ile ölçülen saldırı 35 saniye sürdü; aynı kampanyada HTTP tarafında 200 milyon istek/saniye aşıldı.

Bu tablodan çıkan yanlış sonuç "31 Tbps'e hazırlanmalıyız". Doğru sonuç şu: saldırıların büyük çoğunluğu küçük ve kısa, ama küçük ve kısa olanların sizin için maliyeti büyük. Hazırlanmanız gereken olay, o raporlardaki olay değil; size yönelen ve çoğu zaman tek bir gigabitin altında kalan olay. Ve o olayı ilk denemede atlatmanız gerekiyor, olay sonrası incelemede değil.

Saldırının üç ailesi ve her ailenin bıraktığı iz

Saldırı isimleri, vurdukları katmandan daha az önemli. Katman, hangi kontrolün olayı görebileceğini belirliyor: hacimsel bir filtre saniyede yüz isteği görmez, WAF bir SYN flood'u görmez. Aşağıdaki tablo, olay müdahalesinde en sık karşılaştığımız aileleri, tükettikleri kaynağı ve geride bıraktıkları kanıtı yan yana koyuyor.

Aile	Tipik büyüklük	Neyi tüketir	Hangi kontrol görür	Geride kalan kanıt
Hacimsel (L3/L4)	Birkaç yüz Mbps - onlarca Gbps	Hat, yönlendirici arayüzü, paket işleme	Sağlayıcı tarafı temizleme, ACL, BGP yönlendirme	Arayüz sayaçları, NetFlow/sFlow, sağlayıcı temizleme raporu
Protokol / durum tüketimi	On binlerce paket/saniye yeter	Bağlantı tablosu, SYN kuyruğu, oturum sayısı	SYN cookie, bağlantı limitleri, kenar proxy	Bağlantı tablosu doluluk anlık görüntüsü, kuyruk düşürmeleri, çekirdek sayaçları
Uygulama (L7)	Saniyede on binlerce geçerli istek	CPU, veritabanı bağlantı havuzu, yavaş bağımlılık	WAF, hız sınırı, bot yönetimi, önbellek	Erişim kaydı, uygulama izleri, yavaş sorgu kaydı
Yansıtma / amplifikasyon	Kaynak hacmin 30-51.000 katı	Hat (kurban tarafında)	Kaynak adres doğrulama (BCP 38), açık servislerin kapatılması	Kaynak port dağılımı, yanıt boyutu dağılımı, açık servis envanteri

Tablodaki son satır çoğu zaman atlanıyor ve en çok işe yarayan satır o. Yansıtma saldırısında sizin altyapınız kurban değil, alet olabilir: açık bir çözücü, monlist'i açık bir NTP sunucusu, internete bakan bir memcached örneği. Kendi adres bloğunuzda başkasının silahını barındırıyor olabilirsiniz ve bunu ancak dışarıdan tarayarak öğrenirsiniz.

Yansıtma ekonomisi: 1 Mbps nasıl 50 Gbps olur

Yansıtma saldırısının mantığı basit: UDP kaynak adresini doğrulamıyor, dolayısıyla saldırgan sizin adresinizi sahte kaynak olarak yazıp küçük bir soru gönderiyor, büyük cevap size geliyor. CISA'nın TA14-017A numaralı uyarısında yayımladığı bant genişliği amplifikasyon katsayısı (BAF), cevabın yük baytının isteğin yük baytına oranı. Aşağıdaki hesap, bu katsayıları saldırganın gerçekten göndermesi gereken hacme çeviriyor:

Vektör	BAF (CISA)	Saldırganın gönderdiği	Kurbana ulaşan	Saniyedeki istek
DNS	28 - 54	1 Gbps (60 baytlık sorgular)	yaklaşık 50 Gbps (3.000 baytlık cevaplar)	2.083.000
NTP (monlist)	556,9	10 Mbps (234 baytlık istekler)	yaklaşık 5,6 Gbps	5.342
memcached	10.000 - 51.000	1 Mbps	yaklaşık 51 Gbps	2.083

Sayının neden bu kadar çarpıcı olduğunu bir de tersinden okuyun. 2018'de GitHub'a yapılan ve 1,35 Tbps'e ulaşan memcached saldırısında yaklaşık 17.300 yansıtıcı kullanıldı; bu, yansıtıcı başına ortalama 75 Mbps demek. Yüz gigabitin üstüne çıkmak için gereken açık memcached sayısı bu hızla yaklaşık 1.300. Yani bir botnet ordusuna ihtiyacınız yok; yeterince yanlış yapılandırılmış sunucu var.

Buradan çıkan savunma işi iki tanedir ve ikisi de bu hafta yapılabilir. Birincisi kendi ağınızdan çıkan trafiğin kaynak adres doğrulamasını yapmak (RFC 2827 / BCP 38): sizin bloğunuzdan sahte kaynaklı paket çıkamaz. İkincisi kendi envanterinizde ve müşteri bloklarınızda açık çözücü, açık NTP izleme, internete bakan memcached, SSDP ve CLDAP servisi taramak. Bir kurumun kendi kaynağını temizlemesi, satın aldığı temizleme kapasitesinden daha az konuşuluyor ve daha çok fark yaratıyor.

Paket/saniye ile megabit/saniye arasındaki on sekiz kat

Aynı gigabit, paket boyutuna göre tamamen farklı bir iştir. 64 baytlık paketlerle bir gigabit, saniyede yaklaşık 1,49 milyon paket demek. 1500 baytlık paketlerle aynı gigabit, saniyede yaklaşık 82 bin paket demek. Aradaki fark 18 kat ve bu fark, aynı saldırıyı iki farklı olay gibi yaşamanıza yol açıyor.

Somut sonucu şu: veri sayfasında 10 Gbps ve 2 milyon paket/saniye yazan bir güvenlik duvarı, 64 baytlık trafikte 1,34 Gbps'te durur. Hat dolmamıştır, bant genişliği raporu yüzde 13 gösterir, ama cihaz paket işlemeyi bırakmıştır. Aynı cihaz 1500 baytlık trafikte 10 Gbps'i zorlar. Yani "10 Gbps korumam var" cümlesi, saldırının paket boyutunu söylemeden hiçbir şey söylemiyor.

Bu yüzden kapasite planına üç satır değil dört satır yazılmalı: hat hızı, cihazın paket/saniye sınırı, uygulamanın istek/saniye sınırı ve en yavaş bağımlılığın (veritabanı havuzu, arama dizini, ödeme servisi, oturum deposu) sınırı. Dördüncüsü genellikle en düşük olan ve hiçbir veri sayfasında yazmayan.

Kendi kapasitenizi ölçmek: hangi bileşen kaçta ölür

Bir DDoS tatbikatının ilk çıktısı, hangi bileşenin hangi hızda düştüğünü gösteren bir tablo olmalı. Ölçüm, üretim ortamında değil, üretimin bir kopyasında ve kontrollü bir trafik üreteciyle yapılır; kendi altyapınıza yapılan testin de yazılı kapsamı olması gerekir. Aşağıdaki tablo orta ölçekli bir kurulumda tipik satırları gösteriyor - değerler örnektir, sizin ölçümünüzle değiştirilmelidir:

Bileşen	Nominal değer	İlk düşme noktası	Nasıl ölçülür
İnternet hattı	1 Gbps	1 Gbps sürekli, 64 baytta paket kaybı	Kenar yönlendirici arayüz sayacı
Güvenlik duvarı	10 Gbps / 2 Mpps	1,34 Gbps (64 bayt), 2 Mpps	Kuyruk düşürmeleri, oturum tablosu doluluğu
Yük dengeleyici	40.000 eşzamanlı bağlantı	SYN kuyruğu 1.024 girişte dolar	Yarı açık bağlantı sayısı, kuyruk düşürmeleri
Web katmanı	Saniyede 1.200 istek	CPU yüzde 70'te gecikme ikiye katlanır	Erişim kaydı + CPU profili
Veritabanı havuzu	200 bağlantı	Saniyede 400 sorgu (2 ms ortalama)	Havuz bekleme süresi, yavaş sorgu kaydı

Bu tabloyu doldurmadan alınan hiçbir alarm eşiği savunulabilir değil. Çünkü eşiğin doğru olup olmadığını ancak bileşenin gerçek sınırına göre söyleyebilirsiniz: hattın yüzde 80'inde alarm veren bir sistem, veritabanını koruyan bir sistem değildir.

Baseline olmadan anomali yok: yedi metrik

"Anormal trafik" tanımı, normalin ölçülmüş olmasını gerektiriyor. Çoğu kurum bunu tek bir metrikle, hat kullanımıyla yapıyor ve tam da bu yüzden L7 saldırılarını kaçırıyor. Ölçülmesi gereken en az yedi metrik var ve her biri farklı bir saldırı ailesine karşı erken uyarı:

Metrik	Örnek baseline	Alarm eşiği	Neyi yakalar
Gelen bit/saniye	420 Mbps tepe	Ortalama + 4σ, 3 ardışık kova	Hacimsel
Gelen paket/saniye	42.000	66.000 (ortalama + 4σ, σ=6.000)	Küçük paket flood'u
Yeni bağlantı/saniye	900	Tabanın 5 katı	SYN flood, el sıkışma flood'u
TLS el sıkışma/saniye	600	Tabanın 4 katı	CPU tüketimi
HTTP istek/saniye	1.050	Tabanın 3 katı veya 1.200 (kapasite)	L7 flood
5xx oranı	yüzde 0,2	yüzde 2, 2 dakika boyunca	Kapasite tükenmesi
p95 gecikme	180 ms	600 ms	Sessiz kaynak tükenmesi

Son iki satır en çok atlanan ve en çok işe yarayan satırlar. Saldırı sırasında 5xx oranı ile gecikme, hangi bileşenin düştüğünü saniyeler içinde söyler; hat kullanımı ise çoğu zaman yüzde iki gösterir.

Alarm eşiğini 4σ'ya koymak ve 90 saniyede karar vermek

Saldırıların medyanı on dakikanın altında olduğu için, müdahale süresinin tamamı bu on dakikanın içinde geçiyor. Bu da karar zincirinin saniye cinsinden ölçülmesi gerektiği anlamına geliyor. Örnek bir zincir:

• 0-15 saniye: 5 saniyelik kovalarla ortalama + 4σ eşiği, üç ardışık kovada aşılırsa alarm. Üç kova, tek bir sıçramayı saldırıdan ayırmak için.
• 15-60 saniye: otomatik karar. Hangi kural setinin uygulanacağı önceden yazılı; insan onayı beklenmiyor.
• 60-90 saniye: sağlayıcı tarafında yayılım ve ölçüm: BGP duyurusu ya da kenar kuralının tüm noktalara ulaşması.
• 90 saniye: ilk durum değerlendirmesi. Saldırı devam ediyor mu, hangi vektör, hangi bileşen düştü?

Bu zincir 90 saniyede karar veriyor ve on dakikalık bir saldırının yüzde 15'ini kaybediyor. İnsan onaylı bir zincir ise tipik olarak 20-40 dakika sürer; yani medyan saldırının tamamından uzun. "Otomatik mod kapalı olsun, yanlış pozitif istemiyorum" cümlesi savunulabilir bir tercih değil; ölçülmüş bir tercih olmalı: otomatik kuralın yanlış pozitif oranını ölçüp o oranın kabul edilebilir olduğuna karar vermek gerekiyor.

Önbellek oranının aritmetiği

L7 saldırılarına karşı en ucuz ve en az konuşulan kontrol önbellek. Çünkü saldırganın isteği orijine ulaşmadığında, saldırının maliyeti sizin CPU'nuzda değil, kenarda oluşuyor. Aritmetiği net:

Senaryo	Saldırı	Önbellek isabeti	Orijine ulaşan	Orijin kapasitesi 1.200 istek/sn
Önbellek yok	900.000 istek/sn	yüzde 0	900.000	kapasitenin 750 katı
Kısmi önbellek	900.000 istek/sn	yüzde 80	180.000	kapasitenin 150 katı
Agresif önbellek	900.000 istek/sn	yüzde 92	72.000	kapasitenin 60 katı
Agresif önbellek + hız sınırı	900.000 istek/sn	yüzde 92 + sınır	1.200 (sınır)	kapasitede

Tablodaki son satır işin özü: önbellek tek başına yetmiyor, önbellek artı hız sınırı yetiyor. Ve bu ikisi, satın alınmış bir hacimsel temizleme kapasitesinin görmediği saldırıyı kesiyor. Aynı tablo, neden "CDN kullanıyoruz" cümlesinin tek başına bir DDoS kontrolü sayılmadığını da gösteriyor: önbellek isabet oranı yüzde 40 ise, orijine giden hacim yüzde 60.

Katman 7'de pahalı olan şey bant değil, CPU'dur

Uygulama katmanındaki bir saldırının maliyeti, hat üzerinden değil işlemci üzerinden ödenir. Bunu görünür kılan hesap, el sıkışma maliyetidir: TLS el sıkışması sunucu tarafında yaklaşık 2,5 ms işlemci zamanı alıyorsa, saniyede 900 bin el sıkışma 2.250 çekirdek-saniye demektir; yani olayı karşılamak için 2.250 çekirdek. Aynı istekler önbellekten sunulduğunda maliyet istek başına 0,3 ms'e iner ve gereken çekirdek sayısı 270 olur.

Fark, satın alınacak donanımın sekiz katı. Ama daha önemli sonuç şu: 2.250 çekirdek hiçbir makul bütçede yok. Dolayısıyla L7 savunması bir kapasite yarışı değil, bir eleme işi. Sıralama her zaman aynı: kenarda sonlandır, önbellekten sun, şüpheli istemciyi zorlaştır (JavaScript doğrulaması, çerez), kalanı sınırla, en son orijine bırak.

Bu sıralamada en çok atlanan adım ikincisi. Çünkü önbellek bir performans ayarı gibi görünüyor; oysa saldırı anında önbellek isabet oranı, savunmanın kapasitesi hâline geliyor. Saldırı sırasında önbellek isabet oranını yüzde 60'tan yüzde 92'ye çıkarmak, orijine giden yükü beşte bire indiriyor - yeni donanım almadan.

Orijin adresini gizlemek: koruma satın alanların en sık kaybettiği yer

Bir kurum hacimsel koruma satın aldığında, saldırganın orijin adresini bulması satın alınan korumayı atlatan en kolay yoldur. Ve orijin adresi genellikle hizmetinizden değil, geçmişinizden sızar: eski bir DNS bölge dosyası, sertifika şeffaflık kayıtlarındaki eski bir alt alan adı, bir pazarlama e-postasının izleme başlığı, bir mobil uygulamanın içine gömülmüş API adresi, sağlayıcı değişiminden kalan bir sunucu.

• Doğrudan erişimi kapatın: orijin güvenlik duvarı yalnızca sağlayıcı ağını kabul etsin, diğer her şeyi düşürsün. "Sadece güvenlik duvarı kuralı" cümlesi, kuralın test edildiğini göstermiyor - dışarıdan doğrulanması gerekir.
• Alt alan adlarını sayın: hangi kayıt orijine bakıyor? Sertifika şeffaflık kaydında görünen ve artık kullanılmayan adlar, kapatılmadıkça kalıcı bir açık kapı.
• Giden trafiği kontrol edin: izleme pikselleri, e-posta bağlantıları ve hata raporlayıcıları orijin adresini sızdırabilir; bunların da koruma arkasından çıkması gerekir.
• Yedeği ayrı tutun: yedekleme ve yönetim erişimi ayrı bir ağda, korunan yüzeyin dışında olsun. Saldırı anında yönetim erişimini kaybetmek, olayı iki katına çıkarıyor.

DNS: en sık unutulan tek nokta arızası

Hacimsel koruma bir saldırıyı temizlerken, sitenin bulunamaz hâle gelmesi mümkün. Nedeni basit: alan adınızın yetkili sunucuları saldırıya açıksa, kullanıcı koruma katmanına hiç ulaşamaz. Bu nedenle DNS, koruma planının ilk maddesi olmalı, son maddesi değil.

İki sayı bu kararı verir. Birincisi TTL: 300 saniyelik bir TTL'de yanlış bir kaydı geri almak en kötü durumda 300 saniye sürer; 60 saniyeye indirildiğinde 60 saniye. Ama ikinci sayı bunun bedelini gösteriyor: saniyede 900 bin sorgu alan bir alan adında TTL'yi 300'den 60'a indirmek, sunucuların göreceği sorgu sayısını beş katına çıkarır. Yani TTL kararı bir konfor değil, bir kapasite kararı.

Pratik kural: yetkili DNS'i en az iki ayrı ağda, tercihen her ikisi de kendi ağınızdan bağımsız çalışan sağlayıcılarda tutun; zone transferini kapatın; DNSSEC imzalama işlemini ayrı bir yedekleme yolundan yürütün. DNSSEC'in kendisi bir DDoS savunması değil, ama imzalama anahtarını kaybetmek, saldırıdan bağımsız bir kesinti üretiyor.

Zarif bozulma: hangi özelliği ilk kapatırsınız

Saldırı anında her özelliği eşit korumak istemek, hepsini kaybetmenin en yaygın yoludur. Önceden yazılmış bir öncelik listesi, olay anında tartışmayı bitirir. Tipik bir sıralama:

Öncelik	İşlev	Saldırı anındaki davranış	Kimin kararı
1	Kimlik doğrulama ve ödeme	Tam kapasite, agresif bot filtresi	Olay komutanı
2	Statik içerik	Kenardan sunulur, orijine hiç gitmez	Otomatik
3	Arama ve listeleme	Önbellekten, sonuç sayısı sınırlı	Otomatik
4	Raporlama ve dışa aktarma	Kapatılır, kuyruğa alınır	Otomatik
5	Yönetim paneli	Yalnızca VPN'den, hız sınırlı	Olay komutanı
6	Pazarlama ve analitik betikleri	Tamamen kapatılır	Otomatik

Altıncı satır, ilk bakışta önemsiz görünen ama en çok işe yarayan satır. Üçüncü taraf bir betiğin yavaşlaması, sizin sayfanızı tarayıcıda kilitler; saldırı sırasında bu betikleri kapatmak, kullanıcıya "site çalışıyor" hissini veren en ucuz hamle.

İlk 30 dakika: karar zinciri ve sahiplik

Olay anındaki en pahalı kaynak kapasite değil, karar. Kimin hangi eşikte neyi yapacağı yazılı değilse, ilk yarım saat toplantıyla geçiyor. Aşağıdaki zincir, tatbikatta ölçülebilir olacak şekilde yazılmalı: her adımın bir sahibi, bir süresi ve bir çıktısı var.

Dakika	Adım	Sahip	Çıktı / kanıt
0-5	Alarmı doğrula, saldırı mı yoksa kendi değişikliğimiz mi?	Nöbetçi mühendis	Olay kaydı açıldı, zaman damgası
5-10	Vektörü ve hedefi belirle: hangi katman, hangi uç nokta	Nöbetçi mühendis	Vektör etiketi, ilk ölçüm (pps, rps, 5xx)
10-15	Otomatik kural setini uygula, yanlış pozitif ölç	Platform ekibi	Kural kimliği, önce/sonra metrikleri
15-20	Sağlayıcıyı bilgilendir, olay numarası al	Olay komutanı	Tedarikçi olay numarası, iletişim kaydı
20-25	Bildirim yükümlülüğünü değerlendir: kişisel veri var mı?	Hukuk / veri koruma	Değerlendirme notu, karar ve gerekçe
25-30	Müşteri iletişimi ve durum sayfası	İletişim	Yayımlanmış duyuru, zaman damgası
30-240	Azaltma, izleme, saatlik durum güncellemesi	Olay komutanı	Saatlik kayıt, kapanış raporu

Bu tablodaki 20-25 satırı çoğu kurumda boş. Oysa bir DDoS olayının hukuki sonucu genellikle teknik sonucundan daha uzun sürüyor: kesinti biter, bildirim yükümlülüğünün değerlendirilip değerlendirilmediği sorusu aylarca kalır.

Kanıt dosyası: hangi kayıt, kaç saniye, hangi alan

Saldırı sonrası iki iş var: hizmeti geri getirmek ve ne olduğunu kanıtlamak. İkincisi için gereken kayıtlar genellikle olay sırasında üretilmediği için sonradan üretilemiyor. Kanıt dosyasının çekirdeği şu dört kaynaktır:

Kaynak	Tutulması gereken alanlar	Saklama	Hacim (örnek)
Kenar erişim kaydı	zaman (ms), istemci IP, istek yolu, durum kodu, user-agent, istek kimliği	30 gün sıcak, 1 yıl soğuk	10 dakikalık 900 bin istek/sn olayı: 540 milyon satır, yaklaşık 162 GB (sıkıştırılmış ~16 GB)
Akış kayıtları (NetFlow/sFlow)	kaynak/hesap adresi, port, protokol, bayt ve paket sayısı, başlangıç-bitiş	90 gün	Saniyede 4.000 akışta 90 gün: yaklaşık 3,7 GB
Sağlayıcı temizleme raporu	saldırı başlangıcı, tepe hacim, vektör, uygulanan kural, süre	Olay dosyasıyla birlikte, 10 yıl	Olay başına birkaç sayfa
Sistem sayaçları	CPU, bellek, bağlantı tablosu, kuyruk düşürmeleri, gecikme	90 gün, 10 saniyelik çözünürlük	Metrik başına aylık birkaç yüz MB

İlk satırdaki sayı, neden her isteği saklamanın mümkün olmadığını gösteriyor: on dakikalık bir olay 162 GB ham kayıt üretiyor. Bu yüzden kanıt planı bir örnekleme politikası içermeli: hangi istekler tam tutulur (durum kodu 4xx/5xx, kimlik doğrulama uç noktaları, ödeme yolları), hangileri sayılır. Bir denetimde "kaç istek geldi" sorusuna cevap, tek tek kayıtlardan değil sayaçlardan gelir; ama "hangi istemci hangi hesabı denedi" sorusuna cevap tam kayıt ister.

Türkiye'de bildirim zinciri: üç ayrı muhatap, üç ayrı eşik

Bir DDoS olayının hukuki tarafı, çoğu zaman teknik taraftan daha az hazırlıklı yakalanıyor. Nedeni karmaşıklık değil, muhatap çokluğu: aynı olay üç ayrı yükümlülük doğurabiliyor ve üçünün eşiği, süresi ve dayanağı farklı.

Yükümlülük	Muhatap	Eşik / süre	Dayanak
Siber olay bildirimi	Siber Güvenlik Başkanlığı	Sayısal süre yok: "gecikmeksizin"	7545 sayılı Kanun md.7/1-b
Kişisel veri ihlali bildirimi	Kişisel Verileri Koruma Kurulu	Öğrenmeden itibaren en geç 72 saat (259.200 saniye)	6698 md.12/5 ve Kurul'un 2019/10 sayılı kararı
Şebeke ve bilgi güvenliği ihlali	BTK	Abonelerin yüzde 5'inden fazlası etkileniyorsa "en kısa sürede"	Şebeke ve Bilgi Güvenliği Yönetmeliği md.38
Aboneye bildirim	Etkilenen abone + USOM	Kaynağın kendi abonesi olması hâlinde bildirim	Aynı Yönetmelik md.35/4

Bu tablonun en can alıcı satırı ilki. 7545 sayılı Siber Güvenlik Kanunu 19 Mart 2025'te, 32846 sayılı Resmî Gazete'de yayımlandı ve md.7/1-b, kapsamdaki kuruluşlara "tespit ettikleri zafiyet veya siber olayları gecikmeksizin Başkanlığa bildirmek" yükümlülüğünü getiriyor. Kanun sayısal bir süre vermiyor. Bu, yükümlülüğün gevşek olduğu anlamına gelmiyor; tam tersi: süreyi siz tanımlamadığınız için, "zamanında yaptık" iddiasını ancak kendi kayıtlarınız kanıtlayabiliyor.

Uygulamada bu, olay anında saat damgası üreten bir karar günlüğü demek: alarm saati, doğrulama saati, bildirim taslağının hazırlandığı saat, gönderim saati. Bu dört damga yoksa, "gecikmeksizin" ölçütüne uyduğunuzu savunmak bir beyana kalıyor.

BTK tarafı: yüzde 5 eşiği kime uygulanır

Şebeke ve Bilgi Güvenliği Yönetmeliği'nin md.38/1 hükmü, abonelerinin yüzde 5'inden fazlasını etkileyen şebeke ve bilgi güvenliği ihlallerini ve iş sürekliliğini kesintiye uğratan olayları "en kısa sürede" Kuruma bildirmeyi zorunlu kılıyor; bildirimin asgari içeriği olayın gerçekleşme zamanı, niteliği, etkisi, süresi ve alınan önlemler.

Bu hükmün kapsamı, yönetmeliğin adından da anlaşılacağı gibi elektronik haberleşme işletmecileri. Yani bir e-ticaret sitesi bu maddeye tabi değil. Ama iki nedenle bu satır herkes için önemli. Birincisi, barındırma ya da bulut hizmeti veriyorsanız kendinizi bir gün bu tanımın içinde bulabilirsiniz. İkincisi, eşiğin kendisi iyi bir iç karar kuralı: yüzde 5, bir kurumun "bu olayı dışarıya bildireceğiz" çizgisini sayısallaştıran makul bir referans.

Eşiği somutlaştıralım: 250.000 aboneli bir hizmette yüzde 5, 12.500 abone demek. Self servis portalı 40.000 aboneyi etkileyecek şekilde çökertilirse etkilenen oran yüzde 16 olur ve eşik aşılmış olur; aynı olay yalnızca kurumsal bir API'yi vursa ve 4.000 aboneyi etkilese oran yüzde 1,6'da kalır. Yani aynı teknik olay, etkilenen kitleye göre iki farklı hukuki olay.

KVKK tarafı: formdaki "hizmet dışı bırakma" kutusu

Bir DDoS saldırısı kişisel verileri ele geçirmez; çoğu zaman hiçbir veri okunmaz. Bu, olayın KVKK kapsamı dışında olduğu anlamına gelmiyor. Kişisel Verileri Koruma Kurumu'nun veri ihlali bildirim formunda olay türleri arasında "hizmet dışı bırakma (DoS/DDoS)" başlığı ayrıca yer alıyor. Yani Kurum, erişilebilirliğin kaybını da bir ihlal türü olarak ele alıyor - veri sızmasa bile.

Bunun pratik anlamı şu: saldırı sırasında kişisel veri içeren bir sistem erişilemez hâle geldiyse, bildirim yükümlülüğünün değerlendirilmesi gerekiyor. Değerlendirmenin sonucu "bildirim gerekmiyor" olabilir, ama değerlendirmenin yapıldığını gösteren bir kayıt olmalı. 72 saatlik süre, olayın öğrenildiği andan işlemeye başladığı için, ilk saatlerde verilecek bu karar sürenin tamamını etkiliyor.

Mali tarafı da tabloya koyalım. 6698 sayılı Kanun'un md.18/1-b kapsamındaki idari para cezası, 2026 yılı için yeniden değerleme oranı (yüzde 25,49) uygulandıktan sonra 256.357 TL ile 17.092.242 TL arasında. Aşağıda hesaplayacağımız dört saatlik kesinti maliyeti 109.589 TL; yani ceza bandının alt sınırı, modellenen kesinti maliyetinin 2,34 katı. Üstelik bu iki kalem birbirinin alternatifi değil, üst üste biniyor.

Kesinti maliyetini hesaplamak: yılda 19,7 saatlik başabaş noktası

Koruma bütçesi tartışması genellikle "ne kadar pahalı" sorusuyla başlıyor ve "ne kadar kaybettiriyor" sorusuyla bitmesi gerekiyor. Basit ama savunulabilir bir model: yıllık 240 milyon TL cirosu olan bir kurum, saniyede 7,61 TL, saatte 27.397 TL gelir üretiyor. Dört saatlik tam kesinti, 109.589 TL doğrudan gelir kaybı demek.

Kalem	Hesap	Sonuç
Saniyedeki gelir	240.000.000 TL / 31.536.000 saniye	7,61 TL/saniye
Saatlik kayıp	7,61 x 3.600	27.397 TL/saat
Dört saatlik kesinti	27.397 x 4	109.589 TL
Koruma maliyeti (örnek)	45.000 TL/ay x 12	540.000 TL/yıl
Başabaş noktası	540.000 / 27.397	19,7 saat/yıl

Bu tablonun söylediği şey şu: yılda 19,7 saatten fazla kesinti yaşama olasılığınız yüksekse, koruma kendini ödüyor. Ama modele üç kalem daha eklenmeli, çünkü gerçek maliyet tabloda görünenden büyük: kurtarma işçiliği, müşteri kaybı ve sözleşme cezaları. Hizmet seviyesi sözleşmesi olan kurumlarda kesinti başına ceza, gelir kaybını kolayca aşabiliyor.

Bir de ters yönlü hata var: korumayı yalnızca kesinti maliyetiyle gerekçelendirmek. Oysa orta ölçekli kurumlarda asıl kalem, olay sonrası harcanan mühendislik zamanı. Saldırı başına 40 adam-saat harcayan bir ekip, yılda altı olayda 240 saat eder; bu, bir kişinin altı haftası. Otomasyonun gerekçesi burada.

Tedarikçi seçimi: sözleşmede okunacak yedi madde

Hacimsel koruma hizmetleri birbirine benzer broşürlerle satılıyor. Ayrım, sözleşme maddelerinde ve olay anındaki davranışta ortaya çıkıyor. Teklif değerlendirmesinde şu yedi soruya yazılı cevap isteyin:

Madde	Aranan ölçüt	Kabul edilemez cevap
Temizleme kapasitesi	Bölge bazında, gerçekten ölçülmüş kapasite	"Sınırsız"
Devreye girme süresi	Otomatik modda saniye cinsinden süre	"Anında"
Uygulama katmanı	İstek/saniye cinsinden kapasite ve kural sayısı	"WAF dahil" (sayı yok)
Raporlama	Olay sonrası ham veri erişimi, saklama süresi	"Panelde görebilirsiniz"
Orijin gizliliği	Sağlayıcının orijini maskeleme yöntemi	Belirtilmemiş
Destek	7/24, isimlendirilmiş eskalasyon, yanıt süresi	"E-posta ile"
Çıkış	Veri ve yapılandırmanın taşınabilirliği	Sessizlik

"Sınırsız" cevabı teknik olarak anlamsız: her temizleme ağı bir yerde doyuyor ve o noktada ya paket düşürüyor ya da sizi yönlendirme dışı bırakıyor. Sözleşmede aranması gereken şey, kapasitenin aşılması hâlinde ne olacağının yazılı olması: hangi trafik önceliklendirilir, hangi müşteri korunur, haber verilir mi.

Tatbikat: dört saatlik masa başı ve üç ölçüt

Yazılı plan, tatbikatla sınanmadan plan sayılmıyor. DDoS için en verimli tatbikat biçimi, üretimi durduran tam kapsamlı bir test değil; dört saatlik bir masa başı çalışması. Katılımcılar: nöbetçi mühendis, platform, ağ, hukuk, iletişim. Senaryo gerçek telemetriden türetilmeli, uydurma olmamalı.

• Ölçüt 1 - tespit süresi: alarmın üretilmesinden olay kaydının açılmasına kadar geçen süre. Hedef: 5 dakikanın altı.
• Ölçüt 2 - ilk azaltma süresi: ilk kural setinin uygulandığı ana kadar geçen süre. Hedef: 15 dakikanın altı.
• Ölçüt 3 - karar günlüğü: bildirim yükümlülüğü değerlendirmesinin yapıldığı saatin kayıtta olması. Hedef: ilk 30 dakika içinde yazılı karar.

Tatbikatın çıktısı bir rapor değil, üç düzeltme olmalı: bir eşik, bir sahiplik ve bir kayıt alanı. Üçü de somut değilse tatbikat tekrarlanmalı.

Sekiz yaygın hata

Denetimlerde ve olay incelemelerinde tekrar eden hatalar aynı sekiz başlıkta toplanıyor. Her birinin karşısına, düzeltmesi bir haftadan kısa süren bir karşılık yazdık.

1. Korumayı bir ürün sanmak. Karşılığı: üç soruya yazılı cevap - hangi katman, hangi eşik, hangi kayıt.
2. Yalnızca hat kullanımını izlemek. Karşılığı: paket/saniye, bağlantı/saniye, 5xx ve p95 gecikmeyi aynı panoda görmek.
3. Orijin adresini korumadan bırakmak. Karşılığı: orijin güvenlik duvarında yalnızca sağlayıcı ağını kabul etmek ve bunu dışarıdan doğrulamak.
4. DNS'i plan dışında tutmak. Karşılığı: iki bağımsız ağda yetkili DNS, TTL kararını kapasiteyle birlikte vermek.
5. Otomatik modu kapalı tutmak. Karşılığı: yanlış pozitif oranını ölçmek, sonra karar vermek.
6. Bildirim yükümlülüğünü olay anında düşünmek. Karşılığı: karar matrisini önceden yazmak, ilk 30 dakikada saat damgası üretmek.
7. Kanıt kaydını örneklemeden tutmaya çalışmak. Karşılığı: tam kayıt tutulacak yolları seçmek, gerisini sayaçla özetlemek.
8. Tatbikatı yıllık denetime bırakmak. Karşılığı: çeyrekte bir, dört saatlik masa başı; çıktı üç somut düzeltme.

Bu yazıdan çıkacak üç sayı

Metnin tamamını tek bir sayfaya indirmek gerekirse üç sayı kalıyor. Birincisi 18: aynı gigabitin paket boyutuna göre yarattığı yük farkı; kapasite planınızın neden paket/saniye cinsinden yazılması gerektiğini bu sayı açıklıyor. İkincisi 90 saniye: tespitten ilk azaltmaya kadar geçmesi gereken süre; on dakikalık bir saldırının yüzde 15'ine denk geliyor. Üçüncüsü 19,7 saat: yılda bu kadar kesinti yaşama olasılığınız, orta ölçekli bir koruma bütçesini kendiliğinden gerekçelendiriyor.

Bu üç sayıyı kendi ortamınız için yeniden hesaplamak bir saatlik iş. Hesaplamadan satın alınan her koruma, bir sonraki olayda aynı soruyla karşılaşacak: saldırı hangi katmandaydı ve biz hangi katmanı koruyorduk?

On iş gününde yapılabilecek beş adım

Tabloları ve hesapları bir plana çevirmek için gereken şey büyük bir proje değil, sıralı beş adım. Her adımın çıktısı bir belge; belge yoksa adım yapılmamış sayılmalı.

• 1. ve 2. gün - Envanter ve sızıntı taraması: hangi uç nokta internete açık, hangi alt alan adı orijine bakıyor, blokta açık yansıtıcı var mı. Çıktı: kapatılan kayıtların listesi. Saldırı yüzeyini daraltmanın en hızlı yolu bu; ayrıntı için güvenlik sertleştirme kapsamına bakabilirsiniz.
• 3. ve 4. gün - Kapasite ölçümü: hat, cihaz, uygulama ve veritabanı için ilk düşme noktasını ölçmek. Çıktı: dört satırlık kapasite tablosu ve ondan türetilmiş alarm eşikleri.
• 5. ve 6. gün - Karar matrisi: hangi olayda kimin neyi yapacağı, hangi eşikte otomatik karar verileceği. Çıktı: olay müdahale planı içinde bir DDoS bölümü, isim ve sürelerle.
• 7. ve 8. gün - Kanıt ve bildirim: hangi kayıt tutuluyor, kaç gün saklanıyor, bildirim değerlendirmesini kim yapıyor. Çıktı: teknik tedbirler ve kanıt dosyasına eklenmiş bir kayıt envanteri ve karar günlüğü şablonu.
• 9. ve 10. gün - Tatbikat: dört saatlik masa başı, üç ölçütle. Çıktı: üç somut düzeltme ve bir sonraki tatbikat tarihi.

Bu beş adımın hiçbiri yeni bir ürün satın almayı gerektirmiyor. Gereken şey, ölçüm ve yazılı karar. Ürün kararı ancak bundan sonra anlamlı hâle geliyor: hangi katmanda ne kadar kapasiteye ihtiyacınız olduğunu artık tahmin etmiyor, biliyor oluyorsunuz.

Son not: koruma bir eşik değil, bir alışkanlık

DDoS savunmasında en büyük risk, korumanın bir kez kurulup kapatılan bir konu sanılması. Oysa saldırı yüzeyi sürekli değişiyor: yeni bir alt alan adı, yeni bir bulut hesabı, yeni bir tedarikçi entegrasyonu, yeni bir mobil sürüm. Her biri orijin adresini sızdırabilir, her biri yeni bir açık servis getirebilir.

Bu yüzden DDoS hazırlığının gerçek göstergesi, satın alınan kapasite değil, üç aylık takvimde duran üç iş: envanter taraması, eşik gözden geçirmesi ve masa başı tatbikat. Bu üç iş yapılıyorsa kapasite bir işe yarıyor; yapılmıyorsa elde yalnızca bir sözleşme ve bir broşür kalıyor.

Tedarikçi ve bulut bağımlılıklarınızın olay anındaki davranışını netleştirmek için tedarik zinciri risk rehberine, olayın giriş yolu çoğu zaman kimlik bilgisi olduğu için e-posta güvenliği denetimine, kesinti sonrası veri bütünlüğü tarafı için veri kurtarma rehberine bakabilirsiniz. Uygulama katmanındaki açıkların bu tablodaki yerini görmek için sızma testi, olay sonrası kayıt incelemesi için dijital adli inceleme kapsamlarımız var.