Tarihin en büyük DDoS saldırısı saniyede 398 milyon rps zirvesine ulaştı

 (cloud.google.com)
1 puan yazan GN⁺ 2023-10-11 | 1 yorum | WhatsApp'ta paylaş
  • DDoS saldırılarının ölçeği hızla büyürken Google, Ağustos 2023'te zirvede 398 milyon rps seviyesine ulaşan bir saldırıyı etkisiz hale getirdi; bu, bir önceki yılın 46 milyon rps'lik rekorundan 7,5 kat daha büyüktü
  • Saldırganlar, HTTP/2'nin akış çoklama özelliğini kötüye kullanan Rapid Reset tekniğini kullandı ve birçok internet altyapısı şirketi etkilendi
  • Saldırı dalgası Ağustos 2023'ün sonunda başladı ve Eylül boyunca sürdü; Google hizmetleri, Google Cloud altyapısı ve müşteriler dahil başlıca altyapı sağlayıcıları hedef alındı
  • Google, saldırıyı ağ edge katmanında emip savunma sistemlerini güncelledi; Application Load Balancer ve Cloud Armor müşterileri de aynı temeldeki korumadan yararlandı
  • HTTP/2'yi destekleyen sunucu, proxy, uygulama sunucusu ve yük dengeleyiciler CVE-2023-44487'den etkilenebilir; bu yüzden zafiyet kontrolü ve üretici yamalarının uygulanması gerekiyor

Saldırının ölçeği ve Rapid Reset tekniği

  • Google'ın DDoS Response Team'i, son birkaç yılda DDoS saldırılarının ölçeğinin katlanarak büyüdüğünü doğruladı
  • Ağustos 2023'te engellenen saldırı, önceki yılın en büyük kaydından 7,5 kat daha büyüktü
    • Zirvede 398 milyon requests per second (rps) seviyesine ulaştı
    • 2022'de kaydedilen en büyük DDoS saldırısı 46 milyon rps idi
  • İki dakika süren bu saldırı, Wikipedia'nın Eylül 2023 boyunca bildirdiği toplam makale görüntüleme sayısından daha fazla istek üretti
  • Temel teknik, HTTP/2'nin akış çoklama özelliğinden yararlanan yeni HTTP/2 Rapid Reset yöntemiydi

Hedefler ve hizmetlere etkisi

  • Son saldırı dalgası Ağustos 2023'ün sonunda başladı ve Eylül boyunca gözlemlenmeye devam etti
  • Hedefler arasında büyük altyapı sağlayıcıları da vardı
    • Google hizmetleri
    • Google Cloud altyapısı
    • Google müşterileri
  • Google, küresel yük dengeleme ve DDoS azaltma altyapısı sayesinde hizmetleri çalışır durumda tutmayı başardı
  • Sektör ortaklarıyla iş birliği içinde saldırı mekanizmasını analiz etti ve Google'ı, müşterilerini ve genel olarak interneti korumaya yönelik azaltma adımlarını koordine etti

Google'ın azaltma yöntemi ve Cloud müşterilerinin korunması

  • İnceleme sonucunda saldırının, yaygın kullanılan HTTP/2 protokolünün akış çoklama özelliğini kullanan Rapid Reset tekniğine dayandığı görüldü
  • Google saldırıyı ağ edge katmanında azalttı
    • Edge kapasitesine yaptığı yatırımlar sayesinde Google hizmetleri ile müşteri hizmetlerinin büyük ölçüde etkilenmemesini sağladı
    • Saldırı yöntemini daha ayrıntılı analiz ettikten sonra azaltma önlemleri geliştirdi
    • Proxy ve hizmet reddi savunma sistemlerini güncelleyerek bu tekniği verimli şekilde sınırladı
  • Google Cloud'un Application Load Balancer ve Cloud Armor hizmetleri, Google'ın kendi internete açık hizmetlerini sunarken kullandığı aynı donanım ve yazılım altyapısını kullanır
  • Bu hizmetleri kullanan Cloud müşterilerinin internete açık web uygulamaları ve servisleri de benzer koruma alır

CVE-2023-44487 ve sektör genelinde ortak müdahale

  • Google, Ağustos ayındaki ilk saldırıları tespit ettikten hemen sonra ek azaltma stratejileri uyguladı ve HTTP/2 protokol yığınını kullanan bulut sağlayıcıları ile yazılım bakım ekipleri arasında sektör çapında ortak müdahaleyi koordine etti
  • Saldırı sürerken saldırıya ilişkin bilgiler ve azaltma yöntemleri gerçek zamanlı paylaşıldı
  • Bu iş birliği, birçok büyük altyapı sağlayıcısının kullandığı yamalara ve azaltma tekniklerine dönüştü
  • Yeni saldırı yöntemi ile çeşitli yaygın açık kaynaklı ve ticari proxy, uygulama sunucusu ve yük dengeleyicilerdeki potansiyel zafiyetler koordineli sorumlu açıklama kapsamında duyuruldu
  • Bu saldırıya yönelik toplu zafiyet CVE-2023-44487 olarak izleniyor
    • Önem derecesi High
    • CVSS puanı 7.5/10

Etkilenebilecek sistemler ve gerekli önlemler

  • İnternete HTTP tabanlı iş yükleri sunan şirketler veya bireyler bu saldırının riskine maruz kalabilir
  • HTTP/2 üzerinden iletişim kurabilen sunucu ya da proxy üzerindeki web uygulamaları, servisler ve API'ler savunmasız olabilir
  • Kurumlar, HTTP/2'yi destekleyen sunucularının savunmasız olup olmadığını doğrulamalı
  • Kendi HTTP/2 destekli sunucularınızı işletiyor veya yönetiyorsanız, açık kaynak ya da ticari fark etmeksizin ilgili üretici yamalarını sunulur sunulmaz uygulamalısınız
  • CVE-2023-44487 için yayınlanan üretici yamaları, bu saldırı vektörünün etkisini sınırlamaya yönelik önlemlerdir

Google Cloud ortamı için savunma önerileri

  • Büyük ölçekli DDoS saldırılarına karşı savunma zordur ve yama uygulanmış olsa bile orta ölçekli ya da daha büyük saldırılarda hizmeti ayakta tutmak için ciddi altyapı yatırımı gerekir
  • Google Cloud üzerinde hizmet veren kurumlar, Cross-Cloud Network'ün küresel ölçekli kapasite yatırımlarından yararlanarak uygulamalarını sunabilir ve koruyabilir
  • Hizmetlerini global veya bölgesel Application Load Balancer ile internete açan Google Cloud müşterileri, Cloud Armor always-on DDoS protection korumasından yararlanır
    • CVE-2023-44487 gibi zafiyetleri kullanan saldırılar hızla azaltılır
  • Cloud Armor always-on DDoS protection, Google ağ edge'inde saniyede yüz milyonlarca isteğin büyük bölümünü emebilse de saniyede milyonlarca istenmeyen istek yine de geçebilir
  • Layer 7 saldırılarına karşı Cloud Armor custom security policies, proaktif rate limiting kuralları ve yapay zeka tabanlı Adaptive Protection kullanımının devreye alınması önerilir
  • Mevcut DDoS saldırı dalgasına dair teknik ayrıntılar HTTP/2 Rapid Reset DDoS saldırısı analizi yazısında bulunabilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-10-11
Hacker News yorumları
  • Konuyla ilgili devam eden başlıklar:
    The novel HTTP/2 'Rapid Reset' DDoS attack - https://news.ycombinator.com/item?id=37830987
    HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks - https://news.ycombinator.com/item?id=37830998
  • Böyle DDoS saldırıları düzenlemek için kimin motivasyonu olduğunu merak ediyorum. Kurumsal bulut altyapısına karşı büyük para ve sofistike saldırı geliştirmeyi göze almak için pek neden göremiyorum; makul görünen tek cevap yabancı devletler gibi duruyor.
    Yine de sonuç birkaç saat boyunca ABD teknoloji şirketlerini ve müşterilerini rahatsız etmekten ibaretse, bunun neden sürekli yaşandığını pek anlayamıyorum.
    • Yaklaşık 20 yıldır DDoS savunması yapıyorum; cevap bazen devlet aktörleri olsa da çoğu zaman Doğu Avrupalı dolandırıcılar oluyor. Bot topluluklarında itibar kazanmak için büyük saldırılar yapıyorlar.
      Bu itibarla, rakiplerine saldırmak isteyen daha az temiz müşterilerden para alıyorlar; o müşteri bazen bir devlet, bazen de şüpheli bir şirket olabiliyor. Geçen yıl kripto para şirketlerinin birbirlerinin web sitelerine saldırdığı çok olay oldu.
      Bu işleri yapan kişiler teknik olarak çok yetenekli, ama yaşadıkları yer ya da yetiştikleri ortam nedeniyle bu becerilerle para kazanma fırsatları genelde az oluyor.
    • Amaç tanıtım. Google ya da Cloudflare’e saldırıyorlar, onların “tarihin en büyük saldırısı” blog yazısını yayımlamasını bekliyorlar, sonra da potansiyel müşterilere botnetlerinin herkesten daha büyük saldırı yapabildiğini söyleyip o yazıyı kanıt olarak gösteriyorlar.
    • Acemi saldırganlar için amaç hacker topluluklarında gösteriş ve itibar kazanmak; otoyol üst geçidine graffiti bırakmaktan farklı değil.
      İleri seviye saldırganlar ise kapasiteyi ve tepkileri test ediyordur. Taliban geçmişte üslerin dışında çocuklara havai fişek patlatmaları için para vererek savunma taktiklerini, tekniklerini ve prosedürlerini gözlemlemişti; ayrıca insanları silah sesine duyarsızlaştırma etkisi de vardı.
      Gerçekten iyi bir düşman, ikincisini yaparken birincisi gibi görünmeyi bilir.
    • Eski bir bilgi ama, botnet sahibine birkaç yüz dolar verip sevmediğiniz birinin sunucusunu aksatabiliyordunuz. Rekabetçi oyun klanının maçını mahvetmek buna bir örnek. Dünyada bu tür küçük hesaplı işlerden şaşırtıcı derecede çok var.
      Mirai botnetinde ise geliştiricilerin bazıları aynı zamanda DDoS hafifletme şirketi de işletiyordu. Bir tarafa silahı, diğer tarafa da o silaha karşı savunmayı satıyorlardı.
      Motivasyon bazen itibar, şaka yapmak ya da botnet oluşturmanın kendi başına bir meydan okuma olması da olabiliyor.
    • Yakın zamanda benzer büyük ölçekli saldırılarda botnet yazılımını yazanlar, DDoS hafifletme çözümleri satan ABD’li bir güvenlik şirketinden çıkmış kişilerdi (https://en.wikipedia.org/wiki/Mirai_(malware))
  • Eski şirketimde çok daha küçük ölçekli saldırıları epey sık alıyorduk. İçeride bunun bir rakibin bizi sabote etmeye çalışması olduğunu varsayıyorduk ama sonuçta bir gizem olarak kaldı.
    İster internet altyapısı ölçeğinde olsun ister belirli bir şirketi hedeflesin, bu tür saldırılara karışmış birinin geçici hesap açıp motivasyonunu anlatacak kadar cesur ya da deli olup olmadığını merak ediyorum.
    • Benzer bir şey yaşadık; başta script kiddie’lerin eğlence için yaptığını sanmıştık. Meğer biri çok kötü bir mikroservis yazmış ve verimsiz bir sorgu ara sıra tüm alarmları tetikliyormuş.
    • Yerel bir hosting şirketi, IT altyapısı olan yerel işletmelere DDoS saldırıları yaptıktan sonra DDoS koruması içeren kendi hosting çözümünün reklamını yapmıştı.
    • İsveç üniversiteleri, büyük Kuran yakma tartışmasının ardından “Türkiye” tarafından saldırıya uğradı. Bunu bir Twitter hesabıyla övünerek de duyurdular ama Rusya olduğu epey açık görünüyordu.
    • Hedefin bir alt sistem olduğu saldırılar da olduğunu duydum. Dikkat çekmemek için tüm ağı hedef alma yöntemi.
    • Bir müşterimiz rakipleri tarafından DDoS’a uğradı; ancak rakiplerin DDoS yaptıklarının farkında olmama ihtimali yüksek. Ürün listelerini çok agresif şekilde kazıyorlardı, hiçbir gecikme ya da hız sınırı koymamışlardı ve sonuçta bu DDoS’a dönüştü.
      Amaçları hedef siteyi yavaşlatmak değildi; gerçek ücretli müşterinin sunucu maliyetlerini karşılayamayacağı bir hızda veri çekmeye çalışıyorlardı.
      Bu tür saldırılar gerçek DDoS saldırılarından farklı, ama deneyimime göre çok daha yaygın; Cloudflare ya da Akamai gibi çözümlerle nispeten kolay hafifletilebildiği için müşterilere genelde bunu öneriyorum.
  • Cloudflare de aynı saldırıyı yaşadı: https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
  • “Google ve AWS de aynı dönemde bu saldırıyı görüyordu” kısmı ilginç. Büyük sağlayıcılarda bu seviyede çalışan biri varsa, bu ölçekteki bir saldırı sırasında gerçekte neler olduğunu merak ediyorum.
    Cloudflare, Google ve AWS ekipleri gerçek zamanlı bir görüntülü toplantıya girip birlikte koordinasyon yaparak mı hafifletiyor, yoksa herkes uzaktan diğerlerinde neler olduğunu izleyip kendi sorununu çözmeye mi odaklanıyor?
    • Genelde herkes kendi yangınını söndürür; ama biri ilginç ya da yeni bir şey görürse, yangın söndükten sonra başka yerlerde de benzer saldırılar olup olmadığını sorar. Yeni bir botnet, yeni bir saldırı yöntemi vb. olabilir.
      Bu sefer herkesin aynı şeyi gördüğünü fark ettiler; küçük hedefler için etkisi çok büyük olabileceğinden sorunu birlikte anlamaya çalışıp tüm web sunucusu sağlayıcılarıyla güvenlik müdahalesini koordine ettiler.
  • DDoS hafifletme nasıl çalışıyor merak ediyorum. “Web sitesini Cloudflare’in arkasına alarak DDoS’u hafifletmek” tam olarak ne anlama geliyor?
    Birkaç Gb/s’lik saldırıyı kaldıracak kadar büyük giriş bant genişliği sağlayıp meşru trafik için de yedek kapasite bırakmaktan mı ibaret, merak ediyorum.
    • Bu da dahil ama çok daha fazla unsur var. Genelde gelen seli kaldırabilmek için bant genişliğini ve hesaplama kaynaklarını dinamik olarak artırabilmeniz gerekir.

DDoS trafiğinin büyük bölümü gerçek HTTP değil; IP adreslerine doğru hattı dolduran çöp trafiktir. Daha büyük hatlar ve coğrafi olarak dağıtılmış birden fazla sunucu yardımcı olur. TCP SYN flood gibi, yalnızca TCP bağlantısı açıp kullanılabilir portları tüketen durumlar da vardır. Bu tür anormal istekler çoğu zaman sunucunun önündeki birkaç basit ters proxy ile işlenebilir.
Görünüşte normal HTTP trafiği gönderen daha karmaşık sorgular ise eninde sonunda işlenmek zorundadır. Önbellekten yanıt vermek, saldırganı yavaşlatıp normal trafiği belirlemek için CAPTCHA koymak ya da hız sınırlaması uygulamak gibi. İstek gerçek sunucuya iletilmeden önce normal olup olmadığını ayırt etmek istersiniz; bunun için çeşitli araçlar devreye alınabilir.

  • Cloudflare ve diğer şirketler bir isteğin DDoS trafiği olup olmadığını algılayıp, sunucuya iletmek yerine onu atabilir, sınırlayabilir veya doğrulayabilir.
    Sunucu da Cloudflare’dan gelmeyen tüm trafiği atacak şekilde yapılandırılır; bu yöntem verimlidir.
  • Google SRE’deyken insanlar “DDoS trafiğini sadece Avustralya’ya gönderiyoruz” diye şaka yapardı.
    Genel olarak Google’ın iç veri merkezleri arasındaki trafik, birinin DDoS ile gönderebileceği miktardan çok daha büyüktür; bu yüzden her zaman onu işlemenin bir yolunu bulabilir.
  • DDoS saldırısı kapasite tabanlıysa, hafifletmenin tek yolu trafiği kaldıracak kadar geniş bir ağa sahip olmak ve ISP’lerle işbirliği yaparak yukarı akışta engellemeye başlamaktır.
    Ancak tüm DDoS’lar kapasite tabanlı değildir. slow loris saldırısında olduğu gibi protokolün temel özelliklerini kötüye kullananlar da vardır.
    https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...
  • Yaygın anlamıyla hafifletme, DDoS isteklerini otomatik olarak tanımak ve normal kullanıcıları etkilemeden daha düşük maliyetle işlemek demektir.
    Bu olayda bu, istemcinin akışları hızla sıfırlayıp sıfırlamadığını fark edip o trafiği yavaş şeride almak veya tamamen filtrelemek şeklinde olabilir.
  • Bu yazıda, DDoS’un bir parçası olarak kullanılan HTTP/2 Rapid Reset özelliği hakkında ek bilgiye bağlantı verilmiş: https://cloud.google.com/blog/products/identity-security/how...
  • Bu saldırının kaynağına dair bir ifade yok mu? Muazzam miktarda donanım gerektiriyor gibi görünüyor; bir botnet değilse kolayca izlenebilir gibi duruyor.
    • Özellikle kötü haber şu ki bu saldırı gerçekten devasa bir botnet gerektirmiyor.
      https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
      “Rekor saldırıyla ilgili dikkat edilmesi gereken kilit noktalardan biri, yaklaşık 20.000 makineden oluşan orta ölçekli bir botnet’in işin içinde olmasıdır.”
    • Ölçek düşünüldüğünde, kaynağı açıklamak siyasi ve hukuki açıdan hassas olabilir.
    • İlk tahmin bunun İran tarafından yapıldığı yönünde. Daha önce de defalarca yaptılar ve Hamas ile müttefikler. Kanıt görmedim ama oldukça güvenli bir tahmin gibi görünüyor.
  • Cloudflare, ilgili IP’nin sonraki birkaç HTTP isteğinde “ağınızdaki bir şey DDoS saldırısına katılıyor” diyen bir sayfa gösteremez mi?
    Büyük sağlayıcıların hepsi bunu yapıp, bir sonraki ziyaret edilen Cloudflare sitesinin önüne küçük bir Turnstile benzeri sayfa ekleyebilir gibi geliyor.
    Ağımda enfekte olmuş bir cihaz varsa bilmek isterim; şu anda bunu tespit edecek gerçek bir izleme de yok. Eksiksiz bir çözüm değil ama en azından kullanıcıya bir sorun olduğunu bildirmek iyi bir başlangıç olur.
    • Güzel. HTTPS öncesi döneme geri dönüp ISP’lerin HTML’e reklam enjekte ettiği zamanlar gibi yapabiliriz. Bu kez bunu CDN sağlayıcılarının yapmasını normalleştirmiş oluruz.
    • CGNAT çağında iyi bir fikir değil.
  • Cloudflare blogu: https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...