Cloudflare’ın 11 Ağustos 2026 tarihli ilk yarı DDoS raporu, 1 Tbps sınırını aşan ağ katmanı saldırılarının hızla arttığını gösteriyor. Şirket ilk altı ayda bu ölçekte 935 saldırıyı engellediğini, ikinci çeyrekte hiper hacimli saldırıların çeyrekten çeyreğe yüzde 519 arttığını bildiriyor. DNS ve CLDAP yansıtma vektörleri öne çıkan kaynaklar arasında.
Bu rakamlar “yalnız büyük bankaların sorunu” diye okunmamalı. Küçük bir WordPress sitesi veya yerel hosting firması 1 Tbps trafiği kendi sunucusunda karşılayamaz; savunma, trafik sunucuya ulaşmadan önce başlamalıdır. Asıl soru saldırının büyüklüğü değil, DNS, ağ ve uygulama katmanında hangi bağımlılığın önce kırılacağıdır.
1 Tbps ne anlama geliyor?
1 Tbps, saniyede bir trilyon bit veri aktarımıdır; istek veya paket sayısıyla aynı ölçü değildir. Ancak tek başına bant genişliği saldırının tüm etkisini anlatmaz. Çok küçük paketler ağ cihazının paket işleme kapasitesini, pahalı HTTP istekleri uygulama sunucusunun CPU’sunu, DNS sorguları ise yetkili ad sunucularını tüketebilir.
Bu yüzden “sunucumda 10 Gbps port var” savunma planı değildir. Koruma sağlayıcısının emme kapasitesi, anycast ağı, otomatik filtreleme süresi ve origin adresini gizleme başarısı birlikte değerlendirilmelidir.
Türkiye’de küçük işletme nereden başlamalı?
DNS’i tek noktaya bağlamayın
Alan adının yetkili DNS hizmeti kesilirse web sunucusu çalışsa bile kullanıcı onu bulamaz. İki farklı NS adı yazmak, ikisi aynı altyapıya bağlıysa gerçek çeşitlilik sağlamaz. DNSSEC kullanıyorsanız imza ve anahtar yenileme sürecini ayrıca izleyin. Hatalı imza, saldırı olmadan da erişimi kesebilir.
Origin IP’yi açığa çıkarmayın
CDN arkasındaki sunucunun gerçek IP’si eski DNS kayıtlarında, e-posta başlıklarında veya doğrudan çalışan alt alan adında görünüyorsa saldırgan korumayı atlayabilir. CDN arkasındaki web hizmetinde, sağlık kontrolleri ve sertifika yenileme gereksinimlerini test ederek yalnız yetkili CDN kaynak ağlarına izin verin; yönetim erişimini ayrı VPN veya kısıtlı ağdan sağlayın.
Uygulama maliyetini ölçün
Aynı hızdaki iki istek eşit değildir. Önbellekten dönen ana sayfa ucuz, karmaşık arama veya giriş denemesi pahalı olabilir. Rate limit’i yalnız IP sayısına göre değil uç nokta maliyetine göre uygulayın. Giriş, XML-RPC, arama ve API uç noktaları için ayrı eşikler belirleyin.
20 dakikalık dayanıklılık testi
- Alan adı, DNS, CDN, origin ve veritabanı bağımlılıklarını çizin.
- Origin IP’nin açık kaynaklı DNS geçmişinde ve alt alanlarda görünmediğini kontrol edin.
- CDN dışı web trafiğini sınırlamadan önce yedek alın; sağlık kontrolü, sertifika yenileme ve yönetim erişiminin çalışacağını doğrulayın.
- Statik içerik önbelleğini ve hata sayfasının CDN’den döndüğünü test edin.
- Giriş ve arama uç noktalarında oran sınırını doğrulayın.
- DNS veya CDN sağlayıcısı kesildiğinde iletişim kanalını belirleyin.
- Bir saldırı anında hangi metrikte koruma modunun değişeceğini yazın.
Bu test canlı sisteme saldırı trafiği göndermek değildir. Yapılandırma, rota ve erişim sınırlarını güvenli şekilde doğrular. Yük testi gerekiyorsa sağlayıcıdan yazılı izin alın, deneme ortamı ve belirlenmiş trafik sınırı kullanın.
Saldırı sırasında hangi kayıtlar gerekir?
Başlangıç ve bitiş zamanı, saldırı vektörü, hedef port, paket hızı, bant genişliği, uygulama yanıt süresi ve uygulanan kural değişikliklerini kaydedin. Ekran görüntüsü tek başına yeterli değildir; ham veya dışa aktarılabilir olay kaydı sonraki analizi kolaylaştırır. Müşteriye açıklama yaparken kesinleşmemiş kaynağı ülke veya saldırgan adı olarak sunmayın.
Cloudflare verileri kendi ağına aittir; internetin tamamını bire bir temsil ettiği varsayılmamalı. Yine de artışın büyüklüğü, küçük işletmenin kapasite satın almaktan önce mimari zayıflıkları gidermesi gerektiğini gösteriyor. kesinti planı rehberindeki iletişim ve geri dönüş adımları DDoS senaryosuna da uyarlanabilir.
Satın alma kontrolü
“Sınırsız DDoS koruması” ifadesine güvenmek yerine kapsanan saldırı katmanlarını, otomatik müdahale süresini, origin korumasını, temiz trafik kapasitesini, aşım ücretini ve olay raporunun kapsamını yazılı isteyin. En iyi savunma, saldırı başladıktan sonra panelde düğme aramak değil; DNS’ten uygulamaya kadar sınırları önceden prova etmektir.
Yanlış alarm ile gerçek saldırıyı ayırmak
Kampanya, bot taraması veya hatalı istemci sürümü trafik sıçraması yaratabilir. Karar için yalnız toplam bant genişliğine bakmayın. Kaynak dağılımı, hedef uç nokta, hata oranı, önbellek isabeti ve normal kullanıcı gecikmesini birlikte izleyin. Bir kuralı çok geniş yazmak saldırıyı keserken gerçek müşterileri de engelleyebilir.
Koruma modunu önce gözlem veya dar eşikle etkinleştirin. Otomatik engelin hangi koşulda devreden çıkacağını da belirleyin; aksi halde olay bittikten sonra ödeme veya giriş trafiği saatlerce kapalı kalabilir. Kural değişikliklerini sürümleyin ve geri alma komutunu olay başlamadan test edin.
KOBİ için asgari olay planı
Teknik kişiye ulaşılamadığı durumda alan adını, CDN hesabını ve durum sayfasını kimin yöneteceği belli olmalı. Müşteri iletişimi ana web sitesine bağlıysa kesintide duyuru yapılamaz; ayrı sağlayıcıdaki durum sayfası veya doğrulanmış sosyal kanal kullanın. Sağlayıcı destek numarası, müşteri numarası ve yetkili kişi listesi çevrimdışı erişilebilir olmalı.
Olay bittiğinde yalnız trafik grafiğini arşivlemeyin. Hangi korumanın işe yaradığını, hangi yanlış pozitifi ürettiğini, maliyet ve yanıt süresini yazın. Bu kısa rapor bir sonraki saldırıda panik yerine ölçülmüş karar alınmasını sağlar.
