Yeni HTTP/2 'Rapid Reset' DDoS saldırısı
(cloud.google.com)- Google hizmetlerini ve Google Cloud müşterilerini hedef alan HTTP/2 tabanlı Layer 7 DDoS saldırısı, 2023 Ağustos'unda zirveye ulaşarak saniyede 398 milyon isteği aştı
- Saldırıların büyük bölümü Google'ın küresel yük dengeleme altyapısı üzerinde engellendiği için kesintiye yol açmadı ve ardından benzer saldırıları azaltmaya yönelik ek koruma önlemleri uygulandı
- Rapid Reset, istekten hemen sonra RST_STREAM frame ile yalnızca akışı iptal edip bağlantıyı açık tutarak eşzamanlı akış sınırını aşmadan tekrar tekrar istek üretir
- Sunucu, iptal edilen isteklere rağmen başlık sıkıştırmasını açma, URL eşleme ve backend proxy gibi işlemleri gerçekleştirebilir; bu da maliyet asimetrisini büyütür
- HTTP/2 işletenlerin maruziyet durumunu kontrol edip yamaları uygulaması gerekir; kötüye kullanım tespit edildiğinde temel önlem tek tek isteklerden çok TCP bağlantısının kendisini sonlandırmak olur
Saldırının ölçeği ve Google'ın yanıtı
- Google hizmetleri ve Cloud müşterileri, 2023 Ağustos'unda zirveye ulaşan HTTP/2 tabanlı Layer 7 DDoS saldırılarının hedefi oldu
- En büyük saldırı, saniyede 398 milyon isteği aşarak daha önce raporlanan Layer 7 saldırılarından çok daha büyük bir ölçeğe ulaştı
- Google'ın küresel yük dengeleme altyapısı, saldırının büyük kısmını ağ kenarında engelledi
- Kesinti yaşanmadı
- Etki sınırlı düzeyde kaldı
- Google DDoS Response Team, saldırıyı inceledikten sonra benzer saldırıları azaltmak için ek koruma önlemleri uyguladı
- Google, sektör ortaklarıyla birlikte yeni HTTP/2 saldırı vektörünü ele almak için koordineli açıklama sürecine öncülük etti
HTTP/2'nin DDoS için avantaj sağladığı noktalar
- 2021 sonundan bu yana Google 1st-party hizmetlerinde ve Cloud Armor ile korunan Google Cloud projelerinde gözlemlenen Layer 7 DDoS saldırılarının büyük bölümü HTTP/2 tabanlıydı
- Saldırı sayısı bakımından da yüksekti
- En yüksek istek oranı bakımından da öndeydi
- HTTP/2'nin verimliliği, yalnızca meşru istemciler için değil, DDoS saldırılarının etkinliğini artırmak için de kullanılabilir
-
Akış çoklama
- HTTP/2, endpoint'ler arasında frame'leri çift yönlü bir soyutlama olan akışlar (stream) üzerinden taşır
- Akış çoklama sayesinde tek bir TCP bağlantısı üzerinden aynı anda birden fazla istek işlenebilir
- Layer 7 DoS saldırılarındaki temel kısıt, eşzamanlı iletim bağlantılarının sayısıdır
- Her bağlantı, socket kayıtları ve buffer'lar için işletim sistemi belleği kullanır
- TLS handshake, CPU zamanı gerektirir
- Her bağlantı için her iki taraftaki IP adresleri ve port çiftlerinden oluşan benzersiz bir 4-tuple gerekir
- HTTP/1.1 genellikle istekleri seri işler; bu yüzden tek bir bağlantının istek oranı yaklaşık her gidiş-dönüş süresi başına 1 isteğe yakındır
- HTTP/2'de tek bir TCP bağlantısı üzerinde birden fazla eşzamanlı akış açılabilir ve her akış bir HTTP isteğine karşılık gelir
- Gerçek ortamda istemci istek başına 100 akış açıp sunucu bunları paralel işleyebildiğinde, tek bağlantının etkin throughput'u her gidiş-dönüşte 100 istek seviyesine çıkabilir
- Sonuç olarak bağlantı kullanım verimliliği HTTP/1.1'e göre neredeyse 100 kat artabilir
Rapid Reset nasıl çalışır
- HTTP/2, istemcinin önceki bir akışı iptal ettiğini sunucuya bildirmek için RST_STREAM frame göndermesine izin verir
- İptal için istemci ve sunucu arasında ayrı bir koordinasyon gerekmez
- İstemci tek taraflı olarak iptal edebilir
- RST_STREAM frame alan sunucunun, aynı TCP bağlantısındaki diğer verilere göre iptali önce uygulayacağı varsayılabilir
- Rapid Reset, istek frame'lerini gönderdikten hemen sonra RST_STREAM frame gönderilmesine dayanır
- Karşı endpoint'in işlem başlatmasını sağlar, ardından isteği hızla resetler
- İstek iptal edilir ama HTTP/2 bağlantısı açık kalır
- Saldırı prosedürü basittir
- Standart bir HTTP/2 saldırısı gibi aynı anda çok sayıda akış açılır
- Sunucu veya proxy yanıtı beklenmez
- Her istek hemen iptal edilir
- Anında reset mümkün olduğunda her bağlantı fiilen süresiz şekilde çok sayıda isteği işleniyor durumda tutabilir
- Saldırgan, eşzamanlı açık akış sınırını açıkça aşmaz
- İşlemdeki istek sayısı, gidiş-dönüş süresinden (RTT) çok mevcut ağ bant genişliğiyle sınırlanır
- Tipik HTTP/2 sunucu uygulamaları, iptal edilen istekler için bile işlem yapmak zorunda kalabilir
- Yeni akış veri yapıları tahsis etmek
- Sorgu ayrıştırmak
- Başlık sıkıştırmasını açmak
- URL'yi kaynağa eşlemek
- Reverse proxy uygulamalarında, RST_STREAM frame işlenmeden önce istek backend sunucuya proxy'lenebilir
- İstemci istek gönderme maliyetini neredeyse hiç ödemediği için sunucu ile istemci arasında kötüye kullanılabilir bir maliyet asimetrisi oluşur
- İstek, yanıt yazılmadan önce iptal edilirse reverse proxy sunucu yanıt göndermez; böylece sunucu veya proxy'den saldırgana doğru giden downlink bant genişliği de azalır
Gözlemlenen varyant saldırılar
- İlk DDoS'un ardından birkaç hafta boyunca Rapid Reset varyantları gözlemlendi
- Bu varyantlar ilk yöntem kadar verimli olmasa da standart HTTP/2 DDoS saldırılarından hâlâ daha verimli olabilir
-
Toplu iptal varyantı
- İlk varyant, akışları hemen iptal etmek yerine bir grup akış açıp kısa bir süre bekledikten sonra hepsini topluca iptal eder
- İptalin hemen ardından yeni büyük akış grupları açarak saldırıyı sürdürür
- Bu yöntem, yalnızca gelen RST_STREAM frame oranına dayanan önlemleri atlatabilir
- Örneğin: bağlantı başına saniyede en fazla 100 RST_STREAM'e izin verip aşılırsa bağlantıyı kapatma politikası
- Bağlantı kullanım verimliliğini en üst düzeye çıkaramadığı için iptal saldırısının ana avantajını azaltır
- Yine de standart HTTP/2 DDoS saldırılarından uygulama açısından daha verimli olabilir; bu yüzden sadece akış iptal oranını sınırlamak oldukça katı eşikler gerektirebilir
-
İptalsiz varyant
- İkinci varyantta hiç akış iptali yapılmaz
- Bunun yerine sunucunun duyurduğu eşzamanlı akış sayısından daha fazla akış iyimser şekilde açılmaya çalışılır
- Bu sayede istek pipeline'ı sürekli dolu tutulabilir ve istemci-proxy RTT darboğazı azaltılabilir
- Hedef, HTTP/2 sunucusunun anında yanıt verdiği kaynaklar olduğunda proxy-sunucu RTT darboğazı da ortadan kaldırılabilir
- Mevcut HTTP/2 RFC'si olan RFC 9113, çok fazla akış açma girişimlerinde tüm bağlantıyı değil yalnızca sınırı aşan akışları geçersiz kılmayı önerir
- Çoğu HTTP/2 sunucusunun fazla akışları işleme almayan yapısında, önceki akışın yanıtından hemen sonra yeni akış neredeyse anında kabul edilip işlenebildiği için iptalsiz varyant mümkün hâle gelir
Azaltma stratejileri
- Bu saldırı ailesinde yalnızca tek tek istekleri engellemek uygulanabilir bir azaltma yöntemi olmaktan çıkabilir
- Kötüye kullanım tespit edildiğinde tüm TCP bağlantısı kapatılmalıdır
- HTTP/2, GOAWAY frame tipi ile bağlantı sonlandırmayı destekler
- RFC, önce yeni akış açma sınırı koymayan bilgi amaçlı bir GOAWAY gönderilmesini, bir gidiş-dönüş sonra ise ek akış açılmasını yasaklayan ikinci bir GOAWAY gönderilmesini tanımlayan kademeli bir kapatma prosedürü içerir
- Ancak bu tür kademeli GOAWAY prosedürleri, kötü niyetli istemcilere karşı çoğu durumda yeterince sağlam değildir
- Rapid Reset saldırısında bağlantı çok uzun süre açıkta kalır
- Gelen istekleri durduramaz
- Azaltma amacıyla GOAWAY, akış oluşturmayı hemen sınırlayacak şekilde ayarlanmalıdır
-
Kötüye kullanım yapan bağlantıları belirleme
- İstemcinin istek iptal etmesi tek başına her zaman kötüye kullanım anlamına gelmez
- HTTP/2'nin iptal özelliği, istek işlemesini daha iyi yönetmek için vardır
- Kullanıcının sayfadan ayrılması ve tarayıcının artık istenen kaynağa ihtiyaç duymaması durumu
- İstemci tarafı timeout içeren long polling kullanan uygulamalar
- Azaltma çalışmaları, bağlantı istatistiklerini izleyip çeşitli sinyaller ve iş mantığıyla her bağlantının yararlılığını değerlendirmeye odaklanır
- Örneğin bir bağlantıda 100'den fazla istek varsa ve bunların %50'den fazlası iptal edilmişse azaltma adayı olabilir
- Verilecek yanıtın boyutu ve türü, platformun risk durumuna göre değişir
- Zorlayıcı GOAWAY frame
- TCP bağlantısını hemen sonlandırma
- İptalsiz varyantı azaltmak için HTTP/2 sunucularının, eşzamanlı akış sınırını aşan bağlantıları kapatması önerilir
- Hemen kapatılabilir
- Ya da az sayıda tekrarlanan ihlalin ardından kapatılabilir
HTTP/3'e uygulanabilirlik
- Google, protokol farkları nedeniyle bu saldırı yönteminin HTTP/3'e (QUIC) doğrudan uygulanabilir olduğunu düşünmüyor
- Şu anda Google, HTTP/3'ün büyük ölçekli bir DDoS saldırı vektörü olarak kullanıldığını görmüyor
- Yine de HTTP/3 sunucu uygulamalarının, tek bir iletim bağlantısının yapabileceği iş miktarını sınırlayan mekanizmaları önleyici biçimde hayata geçirmesi önerilir
- Bu, tartışılan HTTP/2 azaltmalarına benzer bir yöndedir
Sektör koordinasyonu ve CVE
- Google DDoS Response Team'in soruşturmasının başından itibaren bu saldırı türünün HTTP/2 sunan tüm hizmetleri geniş ölçekte etkileyebileceği ortaya çıktı
- Google, mevcut koordineli güvenlik açığı açıklama grubunu kullanarak koordineli güvenlik açığı açıklama sürecine öncülük etti
- Açıklama süreci, büyük ölçekli HTTP/2 uygulayıcılarını bilgilendirmeye odaklandı
- Altyapı şirketleri
- Sunucu yazılımı sağlayıcıları
- Ön bildirimin amacı, azaltma yöntemlerinin geliştirilmesi ve koordineli açıklama takvimine göre hazırlanmasıydı
- Geçmişte de bu yaklaşım, hizmet sağlayıcılar tarafından yaygın koruma uygulanmasına veya çeşitli paket ve çözümler için yazılım güncellemeleri sunulmasına yol açtı
- Koordineli açıklama sürecinde birden fazla HTTP/2 uygulamasındaki düzeltmeleri izlemek için CVE-2023-44487 ayrıldı
HTTP/2 hizmeti işletenlerin yapması gerekenler
- Bu saldırı, her ölçekteki hizmet üzerinde önemli etki yaratabilir
- HTTP/2 hizmeti sunan tüm sağlayıcılar, bu soruna ne ölçüde maruz kaldıklarını değerlendirmelidir
- Genel web sunucuları ve programlama dilleri için yazılım yamaları ve güncellemeleri şu anda veya yakın gelecekte sunulabilir
- Sunulan düzeltmelerin mümkün olan en kısa sürede uygulanması önerilir
- Google Cloud müşterilerine, yazılım yamalarıyla birlikte Application Load Balancer ve Google Cloud Armor kullanmaları önerilir
- Google Cloud Armor, Google'ı ve mevcut Google Cloud Application Load Balancing kullanıcılarını korumaya yardımcı oldu
1 yorum
Hacker News yorumları
İlgili devam eden başlıklar:
Bugüne kadarki en büyük DDoS saldırısı, saniyede 398 milyondan fazla istekle zirve yaptı - https://news.ycombinator.com/item?id=37831062
HTTP/2 sıfır gün açığı rekor düzeyde DDoS saldırılarına yol açtı - https://news.ycombinator.com/item?id=37830998
HAProxy ekibinin HTTP/2’deki bu tür sorunu daha 2018’de fark edip hafifletmiş gibi görünmesi güzel: https://www.mail-archive.com/haproxy@formilux.org/msg44134.h...
https://www.nginx.com/blog/http-2-rapid-reset-attack-impacti...
Tipik bir HTTP/2 sunucu uygulamasında, iptal edilen istekler için bile yeni stream veri yapısı ayırma, sorguyu ayrıştırma, header sıkıştırmasını açma, URL’yi kaynaklarla eşleme gibi epey iş yapılması gerekir
Ters proxy uygulamalarında,
RST_STREAMçerçevesi işlenmeden önce istek arka uç sunucuya proxy’lenmiş bile olabilir. Buna karşılık istemci isteği göndermek için neredeyse hiç maliyet ödemez; böylece sunucu ile istemci arasında istismar edilebilir bir maliyet asimetrisi oluşurHTTP/2 tasarlanırken bunun öngörülmemiş olması şaşırtıcı. Diğer protokollerde amplifikasyon saldırıları zaten iyi biliniyordu. Bu saldırının bu kadar geç ortaya çıkması da benzer şekilde şaşırtıcı; ancak HTTP/2 yakın zamana kadar değerli bir hedef olacak kadar yaygın dağıtılmamış olabilir
RST_STREAMSPDY’nin erken sürümlerinde zaten vardı ve SPDY genel olarak 2009 civarında tasarlanmış görünüyorSlowloris gibi saldırılar da neredeyse aynı dönemde çıktı ama o zamanlar yaygın biçimde bilinmiyordu. Öte yandan SYN cookie’leri 1996’da tanıtılmıştı; dolayısıyla kurbanın Y, saldırganın X maliyeti ödediği türden saldırılar için açık tarihsel örnekler var
Buradaki sıra dışı kısım, Google’a karşı ciddi biçimde denenmiş olması
Reklamları, izleyicileri ve şişkin frontend framework’lerini daha hızlı iletmek için HTTP/2’ye ihtiyaç duymuşuz demek. Artık saldırıları da daha hızlı iletiyor
Neyse ki HTTP/1.1 hâlâ çalışıyor. O protokol hoşunuza gitmiyorsa tarayıcı ayarlarında ve web sunucusunda istediğiniz zaman HTTP/1.1’i etkinleştirebilirsiniz
Temel protokolü küçük tutmak için bir neden daha. HTTP/2, SPDY’yi de sayarsak 10 yıldan uzun süredir var ve bu saldırı türü ilk kez ortaya çıkıyor
HTTP/3 ve QUIC içinde ne gibi sürprizler saklı merak ediyorum
“İptal”i de “zor bilgisayar bilimi problemleri” listesine eklemek gerek
Listedeki diğer maddeler, örneğin bir farkla hata ya da cache invalidation gibi, aslında inanılmaz derecede zor değil ama hafife alınıp gözden kaçırılmaya çok yatkın. Oluşturma, constructor ve başlatmaya harcanan zamanın yarısı bile yok etme, temizleme, parçalama ve iptal tasarımına ayrılsaydı, özellikle kaynak tüketimi bug’ları çok daha az olurdu gibi geliyor
awaitnoktasında Future’ı anında iptal edip tüm çağrı yığınını birlikte iptal edebiliyorHerkese Google’ın HTTP/2’yi yapan şirket olduğunu hatırlatmak isterim
Şimdi kendi yarattıkları problemden bizi kahramanca kurtarıyorlarmış gibi anlatıyorlar ama onu kendilerinin yarattığı kısmını söylemiyorlar. Bu teknoloji şirketlerinin pişkinliği yok mu. Microsoft da onlarca yıldır böyleydi
Bu saldırıda sıradan bir istek selinden farklı olan yeni şeyin ne olduğunu açıklayabilir misiniz?
HTTP/1.1’de her gidiş-dönüş süresi başına bir istek gönderebiliyordunuz[0]. HTTP/2 multiplexing ile her gidiş-dönüş süresi başına 100 istek gönderebilirsiniz. Bu saldırıda ise her gidiş-dönüş süresi başına fiilen sınırsız sayıda istek gönderebilirsiniz. Bu yazıdaki diyagramların farkı göstermesini umuyorum; ama belki yukarıdakinden farklı bir saldırı biçimini kastediyorsunuzdur
[0] HTTP/1.1 pipelining’i hesaba katarsak bir gidiş-dönüş süresi unsurunu azaltabilirsiniz; ancak gerçek istemciler HTTP/1.1 pipelining’i neredeyse hiç kullanmadığı için, bunun kullanımı başlı başına kötü niyetli trafiğe dair çok net bir sinyal olur
Tek bir bağlantı içinde isteklerle birlikte stream reset’leri gönderildiğinde, eskisine kıyasla bağlantı/istemci başına daha fazla istek gönderilebilir; bu da saldırı maliyetini düşürebilir veya engellemeyi zorlaştırabilir
Blog başlığı sürekli üstte belirip sayfayı okumayı imkânsız hale getiriyor