Sunucuyu korumak için Zip Bomb kullanımı

 (idiallo.com)
2 puan yazan GN⁺ 2025-04-30 | 1 yorum | WhatsApp'ta paylaş
  • Kişisel blog işleten bir geliştirici, zafiyet taramalarını, spam’i ve içerik kazımayı azaltmak için kötü niyetli botlara HTTP yanıtı olarak gzip tabanlı bir Zip Bomb gönderiyor
  • Normal tarayıcıların ve crawler’ların kullandığı Accept-Encoding: gzip, deflate akışından yararlanarak, şüpheli isteklere 200 OK ve Content-Encoding: gzip döndürüyor
  • 1 MB’lık bir gzip dosyası açıldığında yaklaşık 1 GB, 10 MB’lık bir dosya ise yaklaşık 10 GB boyuta ulaşıyor; bu da birçok botun belleği tüketmesine veya isteği durdurmasına yol açıyor
  • Sunucu middleware’i kara listedeki IP’leri ve spam kalıplarını kontrol ediyor; koşullar eşleşirse önceden oluşturulmuş Zip Bomb dosyasını gönderip isteğin işlenmesini sonlandırıyor
  • Kolayca tespit edilip atlatılabileceği için tam bir savunma olmasa da, ayrım gözetmeden crawl ederek sunucuyu rahatsız eden basit botları engellemek için yeterli görülüyor

Bot trafiği ve Zip Bomb kullanımının arka planı

  • Web trafiğinin büyük bölümü botlardan geliyor; RSS okuyucuları, arama motoru crawler’ları ve yeni içerik arayan AI botları gibi meşru kullanım örnekleri de var
  • Sorun, spam gönderenlerin, içerik kazıyıcıların ve korsanların işlettiği kötü niyetli botlar
    • Geçmişte çalıştığı bir yerde botlar WordPress zafiyetlerini bulup sunucuya kötü amaçlı script’ler enjekte etti
    • Bu sunucu daha sonra DDoS için kullanılan bir botnet’in parçası haline geldi
    • İlk web sitelerinden biri, botların ürettiği spam yüzünden Google arama sonuçlarından tamamen çıkarıldı
  • Bu deneyimlerden sonra sunucuyu kötü niyetli botlardan korumak için Zip Bomb kullanmaya başladı

gzip sıkıştırmasını savunma aracına çevirme yöntemi

  • Zip Bomb, küçük bir sıkıştırılmış dosyanın açılma sürecinde çok büyük bir dosyaya genişleyerek makineye yük bindirmesi prensibine dayanır
  • Web’in ilk dönemlerinde gzip sıkıştırması, yavaş internet bağlantılarında veri aktarımını azaltmak için kullanılmaya başlandı
    • 50 KB’lık bir HTML dosyasını 10 KB’a indirmek, 40 KB veri tasarrufu sağlıyordu
    • Çevirmeli internet döneminde bu, sayfa indirme süresini 12 saniyeden 3 saniyeye düşürebiliyordu
  • Tarayıcılar istek sırasında destekledikleri sıkıştırma yöntemlerini başlıkta bildirir
Accept-Encoding: gzip, deflate
  • Sunucu da sıkıştırmayı destekliyorsa beklenen verinin sıkıştırılmış sürümünü döndürür
  • Web crawling botları da büyük miktarda veri toplamak için gzip gibi sıkıştırmaları destekler ve bu özellik savunmada kullanılır

Kötü niyetli isteklere gönderilen yanıt

  • Blogda güvenlik açıklarını tarayan botlar sık görülüyor ve çoğu genelde görmezden geliniyor
  • Ancak kötü niyetli girdi enjekte etmeye çalışan veya yanıtları yoklayan bir istek tespit edilirse, 200 OK ile birlikte gzip yanıtı gönderiliyor
Content-Encoding: gzip
  • Gönderilen dosyanın boyutu duruma göre 1 MB ile 10 MB arasında değişiyor
    • 1 MB’lık dosya açıldığında yaklaşık 1 GB’a ulaşıyor
    • 10 MB’lık dosya açıldığında yaklaşık 10 GB’a ulaşıyor
  • Bot, başlıklara bakıp bunun sıkıştırılmış bir dosya olduğunu düşünüyor ve içeriği okumak için açmaya çalışıyor
  • Dosya genişlemeye devam ettikçe bellek tükeniyor, sunucu ya da script çökebiliyor
  • 1 MB’lık dosyanın yetmediği daha inatçı script’lere 10 MB’lık dosya gönderiliyor; bu durumda script’in anında sonlandığı belirtiliyor

Zip Bomb oluşturma ve sunucuda uygulama örneği

  • Zip Bomb oluştururken kendi cihazınızı çökertebilir veya zarar verebilirsiniz; bu nedenle risk size aittir
  • Açıldığında 10 GB olan gzip dosyası şu komutla oluşturuluyor
dd if=/dev/zero bs=1G count=10 | gzip -c > 10GB.gz
  • Komutun parçaları şöyle
    • dd: veriyi kopyalamak veya dönüştürmek için kullanılan komut
    • if=/dev/zero: sonsuz 0 bayt akışı üreten özel dosyayı girdi olarak kullanır
    • bs=1G: blok boyutunu 1 GB olarak ayarlar
    • count=10: 10 adet 1 GB blok işleyerek 10 GB sıfır verisi üretir
    • gzip -c > 10GB.gz: çıktı verisini gzip ile sıkıştırıp 10GB.gz dosyasına yazar
  • Bu durumda ortaya çıkan dosya yaklaşık 10 MB boyutundadır
  • Sunucuya, mevcut isteğin kötü niyetli olup olmadığını kontrol eden bir middleware eklenmiştir
    • Siteyi sürekli tarayan IP’ler için bir kara liste tutulur
    • Spam bıraktıktan sonra bunun sayfaya yansıyıp yansımadığını kontrol etmek için geri dönen kalıplar da tespitte kullanılır
if (ipIsBlackListed() || isMalicious()) {
    header("Content-Encoding: gzip");
    header("Content-Length: ". filesize(ZIP_BOMB_FILE_10G)); // 10 MB
    readfile(ZIP_BOMB_FILE_10G);
    exit;
}
  • Maliyeti, belirli durumlarda sunucunun 10 MB’lık bir dosya göndermek zorunda kalmasıdır
  • Yazı viral olduğunda bunun 1 MB’lık sürümüne geçiliyor ve bunun da etkili olduğu söyleniyor

Sınırlamalar ve kullanım kapsamı

  • Zip Bomb tam kapsamlı bir savunma değildir
    • Kolayca tespit edilebilir
    • Atlatılabilir
    • İstemci içeriğin yalnızca bir kısmını okuyabilir
  • Yine de web’i rastgele crawl ederek sunucuyu rahatsız eden sofistike olmayan botları engellemek için yeterli bir araç olarak görülüyor
  • Çalışma örneği sunucu loglarının yeniden oynatımında görülebilir: this replay of my server logs

İlgili okumalar

1 yorum

 
GN⁺ 2025-04-30
Hacker News yorumları

  • 2001 civarında evde sabit hat bağlantım vardı ve evdeki Linux kutumda bir şeyler barındırıyordum.
    Bir Windows NT güncellemesi yüzünden birçok sistem, belirli bir porta önce bağlanıp s/wan pazarlığı yaptıktan sonra TCP trafiği göndermeye çalışan iyimser bir şifreleme özelliğini açmıştı; güvenlik duvarında bu trafiği sık gördüğüm için pek önemsemiyordum.
    Ama özellikle bir makine birkaç saniyede bir sürekli bağlanmayı deniyordu; çok can sıkıcıydı ve yöneticisine ulaşmaya çalıştım ama başaramadım.
    Sonunda “o portta yeni bir servis başlatmak üzereyim, umarım sorun çıkmaz” gibi bir mesaj ilettim; yanıt gelmeyince de o portta /dev/urandom okuyan, TCP_NODELAY vb. seçenekleri açan bir sunucu çalıştırıp rastgele veriyi olabildiğince hızlı bastım.
    Yanlış yapılandırılmış NT kutusu bağlanıyor, yaklaşık 5 saniye rastgele veri içip kayboluyor, 5 dakika sonra tekrar gelip buffer overflow ilacını alıp yine kayboluyordu; bu örüntü birkaç hafta sürdükten sonra internette tamamen ortadan kayboldu.
    Bir yöneticinin NT kutusunun neden sürekli yeniden başladığını anlamaya çalışıp kafasını kaşıdığını hayal ederdim.

    • Programcıysanız başkalarından aldığınız veri miktarına her zaman bir üst sınır koymalısınız.
      Her istekte hem zaman aşımı hem de tüketilecek veri miktarı için sınır olmalı.
    • Benzer bir dönemde bir şirket her cuma spam faks gönderiyordu; defalarca kibarca sesli mesaj bırakmamıza rağmen görmezden geldiler.
      Ben de her sayfası büyük siyah bir dikdörtgenden oluşan 100 sayfalık bir PDF hazırlayıp o zamanlar yeni olan e-posta-faks geçidiyle gönderdim; bir saat içinde öfkeli bir telefon geldi ve fakslar durdu.
    • O dönemde rastgele bir istemcinin yönetici iletişim bilgileri genelde nasıl bulunuyordu, merak ediyorum.
      “Kutunun yöneticisine ulaşmaya çalıştım ve bu yaygındı” kısmı özellikle ilginç.
    • Evdeki RPi sunucumun çökme algılamasını kaba bir şekilde düzeltmiştim: sahip olduğum domaine ping atıyor, başarısız olursa ağ kesildi sayıp yeniden başlatıyordu.
      Domainin süresi dolduktan sonra bu RPi 5 dakikada bir kapanmaya başladı; güç sorunu sanmıştım, sonra o CRON işi aklıma geldi.
    • O dönemde servis sunan NT kurulumlarının çoğunda neler olup bittiğini fark edecek neredeyse hiç yönetici olmadığını öğrenirseniz şaşırabilirsiniz.
      NT kutularında bu tür servisleri çalıştırmanın nedeni çoğu zaman zaten “yöneticiye gerek kalmaması”ydı; binlerce örneği vardı, hafife alınmamalı.
      90’larda ve 2000’lerin başında internete pek çok sunucu koydum; sektör genelindeki standart uygulama yönetici olmadan kullanmak için NT kullanmaktı.

  • Çocukken aptalca bir şaka olarak ana sayfama ln -s /dev/zero index.html koymuştum.
    O dönemin tarayıcıları bunu iyi idare edemiyor, neredeyse donuyordu; bazen istemci sistemini de beraberinde öldürüyordu.
    Sonraları tarayıcılar gerçek içeriği kontrol edip bu tür istekleri kesmeye başlamış gibi görünüyor.

    • Bir keresinde kodlayıcıya aynı makroblok satırını sürekli besleyerek 64k×64k JPEG oluşturmuştum.
      Ancak yıllar sonra nihayet açabildim.
    • squashfs üzerinde uygun başlıklara sahip 500 TB’lık bir HTML dosyası oluşturup kapanış etiketi olmayan sonsuz içerik koymak ve sunucunun indirme öncesinde dosya boyutunu bildirmemesini sağlamak mümkün mü, merak ediyorum.
      Fikri olan var mı?
    • Tarayıcıyı çökerten favicon.ico aklıma geldi.
      Muhtemelen şuydu: https://freedomhacker.net/annoying-favicon-crash-bug-firefox...
    • Umarım bant genişliği ücretini KiB başına ödediğiniz bir durumda değildiniz.
    • Belki de artık /dev/zipbomb aygıtı yapmanın zamanı gelmiştir.

  • Günümüzde neredeyse tüm tarayıcılar zstd ve brotli kabul ediyor; bu yüzden böyle bombalar şimdi daha da etkili olabilir.
    Bu eski yorum etkileyici bir 1,2M:1 sıkıştırma oranı gösteriyordu ve zstd daha da iyi görünüyor.
    Gerçi botlar modern sıkıştırma standartlarını desteklemeyebilir.
    Öte yandan bu, bot engellemek için iyi bir yöntem de olabilir: tüm modern tarayıcılar zstd desteklediğine göre izin listesinde olmayan tarayıcı ajanlarına zorla uygularsanız scraper’ları otomatik olarak şaşkına çevirebilirsiniz.

    • Aslında kendi one million checkboxes Datastar demomda[1] botları sıkıştırmayla filtreliyorum.
      Her etkileşimde tüm kullanıcı görünümünü stream etmeye büyük ölçüde dayanıyor; SSE üzerinde brotli kullanınca 200:1 sıkıştırma oranı[2] kolayca çıkıyor.
      Sorun, kötü niyetli bir aktörün sıkıştırmasız stream isteyebilmesi.
      brotli tarayıcıların %98’i tarafından desteklendiği için brotli sıkıştırmayı desteklemeyen istemcilere veri göndermiyorum; birçok scraper ve bot da bunu desteklemediğinden oldukça iyi çalışıyor.
      [1] checkboxes demo
      https://checkboxes.andersmurphy.com
      [2] brotli SSE hakkında makale
      https://andersmurphy.com/2025/04/15/why-you-should-use-brotl...
    • gzip’in içine bir gzip daha yerleştirirseniz daha da küçülür.
      Bunun nedeni, ilk nesil gzip’te sıkıştırılmış 0 veri bloğunun kendisinin düşük entropili olması; iç içe zst ise 10G dosyayı 99 bayta indiriyor.
    • Böyle bir bomba alırsa tarayıcımın nasıl tepki vereceğini merak ediyorum.
      Kendim denemek istemem.
    • gzip her yerde var ve tüm crawler’lara eziyet edebilir.

  • Eski iş yerimde botların WordPress açıklarını bulup sunucuya kötü amaçlı betikler yerleştirmesi kısmı konudan biraz sapıyor olsa da eğlenceli
    WordPress kurduktan 1 saat sonra sunucuya PHP shell’in sihirli biçimde dağıtılmasının sadece benim başıma gelmediğini öğrenmek aksine içimi rahatlattı

    • Bir müşterinin WordPress sitesini devralınca “Aa, rastgele karakter dizisi adlı 3 PHP shell varmış” durumuna düşüyorsun
      3’ten az olduğu hiç olmadı, her zaman garanti
    • Akıl sağlığınızı korumak istiyorsanız WordPress’i kendiniz host etmeyin
      İlk bir saat olmasa bile, bir gün yamayı unuttuğunuz anda sonunda patlar
    • WordPress host etmişliğim yok ama internete bir HTTP sunucusu açtığınız anda /wp-login gibi istekler gelmeye başlıyor
      Botları bulmak için iyi bir yöntem de oluyor; popüler CMS yollarını isteyen bir IP görünce doğrudan iptables deliğine atıyorum
    • WordPress harika bir arka kapıdır; içinde CMS özellikleri de yerleşik gelir
    • DevOps öğretirken bunu kullandığım olmuştu
      “İlk hello world nginx sunucunuzu dağıtın” deyince loglarda hemen tuhaf istekler görünmeye başlıyor

  • ssh’de de benzer bir şey yapmıştım; root parolasını tahmin etmeye çalışan ssh istemcisini öldürmenin bir yolunu bulmuştum
    Bunun bedeli olarak birkaç script kiddie küçük sunucuma DDoS attı ve sonunda açıkça kötü niyetli davranan aktörleri tespit edip IP’lerini güvenlik duvarı kurallarıyla engelleme yöntemine geçtim
    Ancak IPv6’da bu daha zorlaşıyor
    Kendi web sayfalarını yapan biriyseniz, sayfaya insan gözüyle görünmeyen bağlantılar üzerinden zip bombası koyabilirsiniz
    Beyaz arka plan üzerinde beyaz metin, hover/click vurgusu olmayan anchor gibi; bot indirip kontrol eder, crawler’lar ve yapay zeka scraper’ları da aynısını yapar

    • Fediverse sunucumdaki hesap başvuru formunda bunun bir varyantını kullandım
      Web’de dolaşıp gönderilecekmiş gibi görünen her forma kaba saba spam gönderen çok basit botlar sorun çıkarıyordu
      Başta bozulmuş karakterlerden oluşan basit bir CAPTCHA ekledim; birçok botu engelledi ama hepsini değil
      Sunucu loglarına bakınca bu botların yalnızca üç isteği hızlıca gönderdiğini gördüm: formun olduğu sayfa, CAPTCHA görseli ve form verisi POST isteği; CSS ya da JS hiç yüklemiyorlardı
      Bu yüzden forma birkaç alan daha ekleyip CSS ile gizledim; bu alanlara herhangi bir şey gönderilirse isteği başarısız kılıp oturumu engelleyecek şekilde ayarladım
      Ayrıca CAPTCHA görselini CSS arka planı yaptım, src’yi de şeffaf görselle değiştirdim; spam tamamen durdu ve gerçek kullanıcılar hiçbir şey fark etmedi
    • Böyle davranışları engellemek istiyorsanız buna bakmaya değer
      https://github.com/skeeto/endlessh
    • İnsan gözüyle görünmeyen bir bağlantıysa ekran okuyucu kullanıcıları ne olacak diye endişeleniyorum
    • IPv6’da güvenlik duvarı engellemesinin neden daha zor olduğunu bilmiyorum
      İkisi arasında bana aksine daha kolay görünüyor
    • Böyle bağlantılar metin tarayıcı, ekran okuyucu, sayfa bağlantılarını listeleyen bookmarklet vb. kullanan kişilere görünebilir

  • Zip bombaları eğlenceli
    Bir güvenlik ürününde, belirli bir boyuttan büyük zip arşivlerini ya da onları içeren dosyaları kötü amaçlı yazılım taramasından doğru düzgün geçirmeyen bir açık bulmuştum
    Pratikte Office XML belgesinin içine zip bombası koyunca, içinde kolayca tanımlanabilecek kötü amaçlı yazılım olsa bile ürün OOXML dosyasını geçirebiliyordu

    • Birçok ünlü EDR’de dosya boyutu sorunu hâlâ aynen duruyor

  • Normalde kullandığım honeypot betiği yerine bunu dağıttım ama pek iyi çalışmıyor gibi
    Web sunucusu loglarına bakınca botların 10 MB’lık zehrin tamamını indirmediğini, çeşitli uzunluklarda kestiklerini görüyorum
    Şimdiye kadar yaklaşık 1,5 MB’tan fazlasını alan görmedim
    Yoksa çalışıyor olabilir mi? Akış olarak anında decode ederken ölüyor olabilirler
    Örneğin 1,5 MB okunduğu kaydedildiyse, bellekte anında 1,5 GB’a decode etmeye çalışırken çökmüş olabilir
    Bunu doğrulamanın bir yolu yok

    • İçerik labirenti denemeye değer
      Başka üreteç sayfalara giden bir sürü referans içeren sonsuz üretilen içerik gibi bir yöntem
      Basit wget ve botlar adapte olana kadar işe yarayabilir
      Bu arada ben bot tarafındayım ama yardım etmemde sakınca yok
    • Dosya boyutunu yarı rastgele hâle getirmek gerekebilir
      Bazı botların indirecekleri kaynak boyutuna katı limit koyduğunu düşünüyorum
      Bunların önemli bir kısmı can sıkıcı LLM eğitim/scraping botları olduğundan, 800 KB’lık bir zip bombası göndermek onları öldürmese bile karşı tarafın hesaplama kaynaklarını boşa harcatabilir
    • Geri gelirlerse tespit edip kaçınıyorlardır; geri gelmezlerse çökmüşlerdir, görev tamam

  • Bunun klasik bir zip dosyası değil, gzip bombası olduğunu belirtmekte fayda var
    İç içe zip’lerle antivirüsü devirmekten ziyade, sıradan sıkıştırılmış web sayfası gibi çalışıyor

  • Kısa süre önce Tor Project’in sansür aşma altyapısının bir kısmı, zip bombalarıyla ilgili blog yazısıyla aynı sitede çalışıyordu[0]
    Bu zip dosyalarından biri Google tarafından tarandı ve kötü amaçlı alan adı listesine girdi; Tor’un Snowflake aracında oldukça önemli bir kısmı bozdu
    Çözmesi haftalar sürdü[1]
    [0] https://www.bamsoftware.com/hacks/zipbomb/
    [1] https://www.bamsoftware.com/hacks/zipbomb/#safebrowsing

  • Uygulamamdaki yüklemeleri korumak için her biri yaklaşık 10 MB olan sabit boyutlu geçici disk bölümleri oluşturup sıkıştırmayı oraya açıyordum
    Biri çok büyük bir şey yüklese bile zarar bunun içinde hapsoluyordu

    • unzip -p | head -c 10MB
    • Saçma derecede büyük dosyaların sıkıştırmasını açmamak yeterliyken, özellikle diski bölümlere mi ayırdın?