Hizmet reddi saldırısı, bir sistemin ya da servisin meşru kullanıcılara hizmet veremez hâle getirilmesini amaçlar. Saldırgan veri çalmaz ya da sisteme girmez; yalnızca erişilebilirliği hedef alır. Bu nedenle saldırı, güvenliğin üç temel niteliğinden erişilebilirliği doğrudan zedeler. Etkisi, hizmetin kritikliğine göre saatlik gelir kaybından can güvenliği riskine kadar uzanabilir. Bu çeşitlilik, savunma yatırımının da farklılaşmasına yol açar.

Saldırının temel mantığı kaynak tüketimidir. Hedef sistemin işlem gücü, bellek, bağlantı kapasitesi ya da bant genişliği tüketilerek meşru isteklere yanıt veremez hâle gelmesi sağlanır. Hangi kaynağın hedef alındığı, saldırı türünü belirler. Bazı türler yüksek hacim gerektirirken, bazıları az kaynakla büyük etki üretir. İkinci grup savunma açısından daha zorludur.

Hizmet Reddi Saldırısı Nedir?

Hizmet reddi saldırısı, hedef sistemin kaynaklarını tüketerek ya da bir zafiyeti tetikleyerek meşru kullanıcıların hizmete erişimini engellemeyi amaçlayan saldırı türüdür.

Saldırı tek bir kaynaktan yapıldığında hizmet reddi, çok sayıda dağıtık kaynaktan yapıldığında ise dağıtık hizmet reddi olarak adlandırılır. Dağıtık hizmet reddi saldırıları çok daha yüksek hacim üretebildiği için günümüzde daha yaygındır. Tek kaynaklı saldırılar ise genellikle uygulama katmanındaki zafiyetleri hedefler. İki tür farklı savunma yaklaşımı gerektirir.

Saldırı Türleri

Birinci grup, hacim tabanlı saldırılardır. Amaç, hedefin bant genişliğini doldurarak meşru trafiğin ulaşmasını engellemektir. Bu saldırılar genellikle güçlendirme teknikleriyle üretilir ve çok yüksek hacimlere ulaşabilir. Savunma, trafiğin hedefe ulaşmadan önce filtrelenmesini gerektirir. Bu nedenle sağlayıcı seviyesinde koruma zorunludur.

İkinci grup, protokol tabanlı saldırılardır. Bağlantı kurma mekanizmalarının kötüye kullanılmasıyla sunucu kaynakları tüketilir. Bant genişliği dolmasa bile sistem yeni bağlantı kabul edemez hâle gelir. SYN flood bu grubun klasik örneğidir. Savunma, protokol düzeyindeki koruma özellikleriyle sağlanır.

Üçüncü grup, uygulama katmanı saldırılarıdır. Meşru görünen ama işlem maliyeti yüksek istekler gönderilerek sunucu tüketilir. Az sayıda istekle büyük etki üretilebildiği için tespiti zordur. Slowloris ve benzeri teknikler bu gruptadır. Savunma, uygulama davranışının izlenmesine dayanır.

• Hacim tabanlı: bant genişliğinin doldurulması
• Protokol tabanlı: bağlantı tablolarının tüketilmesi
• Uygulama katmanı: maliyetli isteklerle kaynak tüketimi
• Zafiyet tabanlı: tek bir istekle sistemin çökertilmesi
• Mantıksal: hesap kilitleme ve kota tüketme gibi dolaylı yöntemler

Zafiyet Tabanlı Hizmet Reddi

Bazı saldırılar yüksek hacim gerektirmez; tek bir özel hazırlanmış istek sistemi çökertebilir. Bu tür zafiyetler, hatalı girdi işleme ya da kaynak yönetimi hatalarından kaynaklanır. Etkisi ani ve tamdır. Savunma, yama uygulama ve girdi doğrulamaya dayanır. Trafik filtreleme bu tür saldırılara karşı çoğu zaman işe yaramaz.

Sonsuz döngü ve aşırı bellek tüketimine yol açan girdiler de bu kategoridedir. Sıkıştırılmış veri açılırken oluşan aşırı büyüme, düzenli ifade işlemede oluşan üstel gecikme bu örneklerdendir. Uygulama geliştirme sırasında girdi boyutu ve işlem süresi sınırları tanımlanmalıdır. Bu sınırlar, sömürüyü baştan engeller. Tasarım aşamasında ele alınmaları gerekir.

Mantıksal Hizmet Reddi

Bazı saldırılar teknik kaynak yerine iş mantığını hedef alır. Hesap kilitleme mekanizmasının kasıtlı olarak tetiklenmesi, kullanıcıların sisteme erişemez hâle gelmesine yol açar. Benzer biçimde stok rezervasyonu ya da kota tüketimi de kötüye kullanılabilir. Bu saldırılar hiçbir teknik zafiyet gerektirmez. Savunma, iş mantığının tasarımında yatar.

Bu nedenle hesap kilitleme yerine kademeli gecikme tercih edilebilir. Ayrıca kota ve rezervasyon mekanizmalarına kimlik doğrulama ve hız sınırı eklenmelidir. İş mantığı zafiyetleri değerlendirmesinde bu senaryolar aranır. Otomatik tarayıcılar bu tür sorunları bulamaz. Manuel inceleme gerekir.

Nasıl Önlenir?

İlk önlem kapasite ve mimari planlamasıdır. Yedeklilik, yük dengeleme ve otomatik ölçeklenme, ani yük artışlarına karşı dayanıklılık sağlar. Bu yatırım aynı zamanda normal işletme koşullarında da fayda üretir. Mimari tasarım aşamasında ele alınması gerekir. Sonradan eklenmesi maliyetlidir.

İkinci önlem, hız sınırlama ve kota uygulamasıdır. Her istemcinin belirli sürede yapabileceği istek sayısının sınırlanması, kaynak tüketimini kontrol altına alır. Sınırların kimlik doğrulanmış ve doğrulanmamış kullanıcılar için ayrı tanımlanması önerilir. Bu ayrım, meşru kullanıcıları korurken saldırıyı zorlaştırır. Uygulama, ağ geçidi katmanında yapılabilir.

Üçüncü önlem, uzman koruma hizmetleridir. Yüksek hacimli saldırılar için trafiğin hedefe ulaşmadan filtrelenmesi gerekir. Bu hizmet genellikle sağlayıcı ya da uzman bir platform tarafından sunulur. Bulut koruma katmanları bu işlevi yerine getirir. Devreye alma süresi önceden planlanmalıdır.

Müdahale Planı

Saldırı anında ne yapılacağı önceden yazılmış olmalıdır. Kimin karar vereceği, hangi sağlayıcıyla iletişime geçileceği ve hangi trafiğin feda edilebileceği önceden belirlenir. Kriz anında bu kararların alınması zaman kaybettirir. Plan, iletişim şablonlarını da içermelidir. Müşteri bilgilendirmesi de planın parçasıdır.

Plan ayrıca hangi hizmetlerin öncelikli ayakta tutulacağını tanımlamalıdır. Tüm hizmetlerin aynı anda korunması mümkün olmayabilir. Öncelik sıralaması iş birimleriyle birlikte belirlenir. Bu karar teknik değil iş kararıdır. Önceden verilmediğinde kriz anında tartışma çıkar.

Planın tatbikatla sınanması da gereklidir. Sağlayıcıya geçiş süresi, yönlendirme değişikliğinin yayılma süresi ve iletişim akışı ancak denenerek doğrulanır. Masa başı tatbikat senaryoları bu doğrulamayı sağlar. Sınanmamış plan, çalıştığı varsayılan plandır.

İş Etkisi Değerlendirmesi

Hizmet reddi saldırılarının etkisi, kesintinin süresine ve etkilenen hizmetin kritikliğine göre değişir. Bir tanıtım sitesinin erişilemez olması ile bir ödeme sisteminin durması aynı sonucu doğurmaz. Bu nedenle koruma yatırımı, hizmet bazında farklılaştırılmalıdır. Tüm hizmetleri aynı seviyede korumak ne mümkün ne gereklidir. Öncelik sıralaması iş birimleriyle birlikte yapılır.

Değerlendirmede saatlik kayıp tahmini kullanılır. Bir saatlik kesintinin gelir, operasyon ve itibar açısından maliyeti hesaplanır. Bu rakam, koruma yatırımının gerekçesini oluşturur. Ayrıca kabul edilebilir kesinti süresinin belirlenmesini sağlar. Bu süre, mimari kararlara girdi olur.

Sözleşmesel yükümlülükler de değerlendirmeye dahil edilir. Müşterilere verilen hizmet seviyesi taahhütleri, kesinti durumunda mali sonuç doğurabilir. Bu yükümlülüklerin bilinmesi, koruma seviyesinin belirlenmesinde kullanılır. Taahhütler ile koruma kapasitesi uyumlu olmalıdır. Uyumsuzluk, sözleşme riski üretir.

Test ve Tatbikat

Koruma mekanizmalarının gerçekten çalıştığı ancak test edilerek doğrulanabilir. Kontrollü yük testleri, sistemin hangi noktada bozulduğunu gösterir. Bu bilgi, kapasite planlamasına doğrudan girdi olur. Test öncesinde tüm paydaşların bilgilendirilmesi gerekir. Habersiz testler gerçek bir kriz gibi algılanabilir.

Koruma hizmetine geçiş süresi de ölçülmelidir. Yönlendirme değişikliğinin yayılma süresi ve trafik temizleme merkezinin devreye girme süresi kaydedilir. Bu süreler, gerçek olayda beklenen kesinti süresini belirler. Sözleşmedeki taahhütlerle karşılaştırılır. Fark varsa sağlayıcıyla görüşülür.

Masa başı tatbikatlar da faydalıdır. Teknik test yapmadan, senaryo üzerinden karar süreçlerinin sınanması mümkündür. Kimin ne zaman karar vereceği bu çalışmada netleşir. Masa başı tatbikat senaryoları bu amaçla kullanılır. Maliyeti düşük, getirisi yüksektir.

Sık Yapılan Hatalar

İlk hata, korumanın yalnızca ana web sitesi için düşünülmesidir. API uç noktaları, kimlik doğrulama servisleri ve ad çözümleme altyapısı da hedef olabilir. Bu bileşenlerin korunmaması, ana site korunsa bile hizmeti durdurur. Kapsam belirleme bu bileşenleri içermelidir. Envanter eksikliği en yaygın nedendir.

İkinci hata, ad çözümleme altyapısının unutulmasıdır. Bu altyapı erişilemez olduğunda hiçbir hizmete ulaşılamaz. Yedekliliğin farklı sağlayıcılarda kurulması önerilir. Tek sağlayıcıya bağımlılık kritik bir tek nokta oluşturur. Bu risk sık gözden kaçar.

Privia Security olarak erişilebilirlik risklerini ve mevcut koruma katmanlarının yeterliliğinialtyapı ve mimari gözden geçirme kapsamında değerlendiriyoruz.