- Katılım
- 21 May 2023
- Mesajlar
- 602
- Tepki
- 17
- Puan
- 18
Site bir anda ağırlaşıyor, sonra hiç açılmıyor. Sunucu tarafında hata yok, kod değişmedi, veritabanı ayakta. Böyle bir tabloda akla gelen ilk ihtimallerden biri, sistemin dışarıdan gelen yükle boğulması oluyor.
Bu yazı hizmet reddi saldırısının ne olduğunu, dağıtık biçiminin farkını, hangi kaynağın tüketildiğini ve savunmanın neden bu kadar zor sayıldığını protokol belgelerine ve standart tanımlara dayanarak anlatıyor.
Hizmet reddi saldırısı nedir?
RFC 4732'nin tanımı sade: bir hizmet reddi saldırısı, bir ya da daha fazla makinenin bir kurbanı hedef alması ve kurbanın yararlı iş yapmasını engellemesi durumu. Belgeye göre hedef bir ağ sunucusu olabileceği gibi istemciler, yönlendiriciler, ağ bağlantıları ya da tüm ağlar da olabiliyor.
NIST'in terim sözlüğü aynı kavramı sonuç tarafından tanımlıyor: yetkili erişimin kaynaklara engellenmesi ya da zaman açısından kritik işlemlerin geciktirilmesi. İkinci yarısı önemli — sistem tamamen düşmese bile, işlemler kritik ölçüde gecikiyorsa saldırı amacına ulaşmış oluyor.
Dağıtık olması ne değiştiriyor?
"Dağıtık" ifadesi saldırının birden fazla makineden gelmesini anlatıyor. RFC, tek bir iyi bağlantılı sistemin de başarılı bir saldırı gerçekleştirebileceğini belirtiyor; yani dağıtık olmak şart değil, ama trafiğin çok sayıda kaynaktan gelmesi hem hacmi büyütüyor hem de ayıklamayı zorlaştırıyor.
Tek adresten gelen anormal trafiği engellemek görece kolay. Binlerce farklı adresten, üstelik normal görünen isteklerle gelen trafikte ise "kim gerçek ziyaretçi" sorusu belirsizleşiyor.
Hangi kaynak tüketiliyor?
RFC 4732 saldırıları tükettikleri kaynağa göre ayırıyor:
- Bant genişliği: Meşru trafiğin kabul edilemez ölçüde yüksek paket kaybına uğrayacağı kadar trafik gönderilir.
- Sistem kaynakları: Bellek, işlemci, disk ya da bağlantı sayısı tüketilir; belgede TCP SYN taşması bu türe örnek veriliyor.
- Protokol zafiyetleri: Yazılım kalitesi kaynaklı açıklar, yönlendirme protokolü istismarları ya da ad çözümleme üzerinden yapılan saldırılar.
Bu ayrım, savunmanın nereye kurulacağını da belirliyor: bant genişliği tüketen bir saldırıda sunucudaki ayarın etkisi sınırlı kalıyor, çünkü hat zaten dolu.
Neden ayırt etmek zor?' Alıntı:RFC, yeterince ince bir saldırıyla ani ziyaretçi akınını ayırmanın prensipte imkânsız olmadığını söylüyor. Yani ayrım mümkün ama otomatik ve hatasız değil; her filtre gerçek kullanıcıyı da eleme riski taşıyor.
İnternet mimarisi bu tehdide göre kurulmadı
Belgenin çerçeve cümlelerinden biri, sorunun neden kalıcı olduğunu açıklıyor: internet mimarisi başlangıçta bu tehditleri göz önüne almadığı için hemen hemen tüm hizmetler savunmasız durumda.
Bu, "doğru yapılandırırsanız bağışık olursunuz" beklentisini boşa çıkarıyor. Yapılabilecek şey saldırıyı imkânsız kılmak değil, maliyetini yükseltmek ve etkisini sınırlamak.
Ölçmeden savunma kurulmuyor
Saldırı anında en çok vakit kaybettiren şey, normalin ne olduğunun bilinmemesi. Sıradan bir günde saniyede kaç istek geldiğini, hangi sayfaların ne kadar kaynak tükettiğini bilmiyorsanız, gelen yükün saldırı mı yoksa beklenmedik ilgi mi olduğunu ayırt etmek zorlaşıyor.
Bu yüzden ilk iş bir taban çizgisi çıkarmak oluyor: günlük istek sayısı, en çok çağrılan adresler ve olağan yanıt süresi. Sonrasında sapma görüldüğünde karşılaştıracak bir referans bulunuyor.
Etkiyi sınırlamanın yolları
RFC'nin çerçevesi savunmanın nereye kurulacağını da söylüyor. Bant genişliği tüketen bir saldırıda müdahale hattın yukarısında, sağlayıcı tarafında olmak zorunda; sistem kaynağı tüketen bir saldırıda ise bağlantı sınırları ve zaman aşımı ayarları etkili olabiliyor.
Protokol zafiyetlerinde ise iş yazılım tarafına dönüyor: güncel sürüm kullanmak ve gereksiz servisleri kapatmak, saldırganın kullanabileceği yüzeyi daraltıyor.
Barındırma tarafındaki vaat
Barındırma firmalarının "DDoS korumalı" ifadesi tam olarak neyi kapsıyor, bu ayrı bir okuma gerektiriyor; söz konusu vaadin sınırlarını DDoS korumalı barındırmayı ele aldığımız yazıda incelemiştik.
Saldırı sırasında ya da sonrasında bir güvenlik açığı fark ederseniz, bunu kime ve nasıl bildireceğinizi açık bildirimini anlattığımız yazıda ele almıştık. Saldırının ardından hesap bilgilerinizin başka bir olayda ortaya çıktığını fark ederseniz izlenecek yol farklıdır; onu e-posta adresi sızıntıda çıkınca ne yapılacağını ele aldığımız yazıda adım adım yazmıştık.
Sık Sorulan Sorular
DDoS saldırısı nedir?
RFC 4732'ye göre bir ya da daha fazla makinenin bir kurbanı hedef alıp yararlı iş yapmasını engellemesidir; dağıtık biçimde trafik çok sayıda kaynaktan gelir.
DoS ile DDoS arasındaki fark ne?
Dağıtıklık kaynak sayısıyla ilgilidir. Belge, tek bir iyi bağlantılı sistemin de başarılı bir saldırı yapabileceğini belirtiyor.
Saldırı hangi kaynakları tüketir?
Bant genişliği, sistem kaynakları (bellek, işlemci, disk, bağlantı sayısı) ya da protokol zafiyetleri üzerinden yürütülür.
Sistem çökmezse saldırı başarısız mı sayılır?
Hayır. NIST'in tanımı, zaman açısından kritik işlemlerin geciktirilmesini de hizmet reddi kapsamında sayıyor.
Tamamen korunmak mümkün mü?
RFC 4732, internet mimarisinin bu tehditler düşünülerek kurulmadığını ve hemen hemen tüm hizmetlerin savunmasız olduğunu belirtiyor; hedef saldırıyı imkânsız kılmak değil, etkisini sınırlamak.
Özetle
Hizmet reddi saldırısı, sistemi çökertmekten çok onu iş yapamaz hâle getirmeyi amaçlıyor; gecikme de bu tanıma giriyor. Tüketilen kaynak bant genişliği, sistem kaynakları ya da protokol zafiyetleri olabiliyor ve savunmanın kurulacağı yer buna göre değişiyor. Meşru trafikle saldırıyı ayırmak ise otomatik ve hatasız bir iş değil.
Sitenizin ani trafik artışında nasıl davrandığını hiç ölçtünüz mü?
Güncelleme: 26 Ağustos 2026.
Dijital Dünyanıza Yön Veren Pusula