Menggunakan Zip Bomb untuk Melindungi Server

 (idiallo.com)
2 poin oleh GN⁺ 2025-04-30 | 1 komentar | Bagikan ke WhatsApp
  • Operator blog pribadi mengirim Zip Bomb berbasis gzip sebagai respons HTTP kepada bot berbahaya untuk mengurangi pemindaian kerentanan, spam, dan scraping konten
  • Memanfaatkan alur Accept-Encoding: gzip, deflate yang digunakan browser dan crawler normal; untuk permintaan mencurigakan, server mengembalikan 200 OK dan Content-Encoding: gzip
  • File gzip 1MB akan membesar menjadi sekitar 1GB saat didekompresi, sedangkan file 10MB menjadi sekitar 10GB, sehingga banyak bot kehabisan memori atau menghentikan permintaan
  • Middleware server memeriksa IP daftar hitam dan pola spam; jika memenuhi kondisi, server mengirim file Zip Bomb yang sudah dibuat sebelumnya lalu mengakhiri pemrosesan permintaan
  • Karena mudah dideteksi dan dilewati, ini bukan pertahanan yang sempurna, tetapi cukup untuk menahan bot sederhana yang mengganggu server dengan crawling membabi buta

Latar belakang penggunaan lalu lintas bot dan Zip Bomb

  • Sebagian besar lalu lintas web berasal dari bot, dan ada juga penggunaan sah untuk menemukan konten baru seperti RSS reader, crawler mesin pencari, dan bot AI
  • Masalahnya adalah bot berbahaya yang dijalankan oleh spammer, scraper konten, dan peretas
    • Di tempat kerja sebelumnya, bot mencari kerentanan WordPress dan menyisipkan skrip berbahaya ke server
    • Server tersebut kemudian menjadi bagian dari botnet yang digunakan untuk DDoS
    • Salah satu situs web awal sepenuhnya dikeluarkan dari hasil Google Search karena spam yang dibuat oleh bot
  • Setelah pengalaman tersebut, penulis mulai menggunakan Zip Bomb untuk melindungi server dari bot berbahaya

Cara mengubah kompresi gzip menjadi sarana pertahanan

  • Zip Bomb adalah file terkompresi kecil yang saat didekompresi mengembang menjadi file yang sangat besar dan membebani mesin
  • Pada masa awal web, kompresi gzip diperkenalkan untuk mengurangi jumlah data yang dikirim di lingkungan internet lambat
    • Jika file HTML 50KB diperkecil menjadi 10KB, transfer data dapat dihemat 40KB
    • Pada internet dial-up, ini berdampak mengurangi waktu unduh halaman dari 12 detik menjadi 3 detik
  • Browser memberi tahu metode kompresi yang didukungnya melalui header saat mengirim permintaan
Accept-Encoding: gzip, deflate
  • Jika server juga mendukung kompresi, server mengembalikan versi terkompresi dari data yang diharapkan
  • Bot crawling web juga mendukung kompresi seperti gzip untuk mengumpulkan data dalam jumlah besar, dan karakteristik ini dimanfaatkan sebagai pertahanan

Respons yang dikirim untuk permintaan berbahaya

  • Di blog, bot yang memindai kerentanan keamanan sering muncul, dan sebagian besar diabaikan
  • Jika permintaan dinilai mencoba menyisipkan input berbahaya atau menelusuri respons, server mengirim respons gzip bersama 200 OK
Content-Encoding: gzip
  • Ukuran file yang dikirim berkisar 1MB–10MB tergantung situasi
    • File 1MB membesar menjadi sekitar 1GB saat didekompresi
    • File 10MB membesar menjadi sekitar 10GB saat didekompresi
  • Bot melihat header dan menganggapnya sebagai file terkompresi, lalu mencoba mendekompresi untuk menemukan isinya
  • Saat file terus mengembang, memori terkuras dan server atau skrip dapat crash
  • Untuk skrip bandel yang tidak cukup dihentikan dengan file 1MB, penulis mengirim file 10MB; dalam kasus ini skrip disebut langsung berhenti

Contoh pembuatan Zip Bomb dan penerapannya di server

  • Saat membuat Zip Bomb, Anda harus menanggung risiko karena dapat membuat perangkat sendiri crash atau rusak
  • File gzip yang terurai menjadi 10GB dibuat dengan perintah berikut
dd if=/dev/zero bs=1G count=10 | gzip -c > 10GB.gz
  • Susunan perintahnya adalah sebagai berikut
    • dd: perintah untuk menyalin atau mengonversi data
    • if=/dev/zero: menggunakan file khusus yang menghasilkan aliran byte 0 tanpa batas sebagai input
    • bs=1G: menetapkan ukuran blok menjadi 1GB
    • count=10: memproses 10 blok 1GB untuk menghasilkan data nol sebesar 10GB
    • gzip -c > 10GB.gz: mengompresi data keluaran dengan gzip dan menyimpannya sebagai file 10GB.gz
  • Dalam kasus ini, ukuran file hasilnya sekitar 10MB
  • Di server, ditambahkan middleware yang memeriksa apakah permintaan saat ini berbahaya
    • Memelihara daftar hitam IP yang berulang kali memindai seluruh situs
    • Pola setelah meninggalkan spam lalu kembali memeriksa apakah spam tersebut muncul di halaman juga digunakan untuk deteksi
if (ipIsBlackListed() || isMalicious()) {
    header("Content-Encoding: gzip");
    header("Content-Length: ". filesize(ZIP_BOMB_FILE_10G)); // 10 MB
    readfile(ZIP_BOMB_FILE_10G);
    exit;
}
  • Biayanya adalah dalam situasi tertentu server harus mengirim file 10MB
  • Saat tulisan menjadi viral, penulis menurunkannya ke file 1MB, dan file ini juga disebut tetap efektif

Batasan dan cakupan penggunaan

  • Zip Bomb bukan pertahanan yang sempurna
    • Dapat dengan mudah dideteksi
    • Juga dapat dilewati
    • Klien mungkin hanya membaca sebagian isi
  • Meski begitu, ini cukup sebagai alat untuk menahan bot yang tidak canggih yang meng-crawl web secara membabi buta dan mengganggu server
  • Contoh cara kerjanya dapat dilihat di replay log server: this replay of my server logs

Bacaan terkait

1 komentar

 
GN⁺ 2025-04-30
Pendapat di Hacker News

  • Sekitar tahun 2001, pernah ada masa ketika saya punya jalur tetap di rumah dan meng-hosting macam-macam dari kotak Linux rumahan
    Karena pembaruan Windows NT, banyak sistem mengaktifkan fitur enkripsi oportunistis yang mencoba terhubung lebih dulu ke port tertentu untuk menegosiasikan s/wan sebelum mengirim trafik TCP, dan saya sering melihat trafik seperti itu di firewall, jadi tidak terlalu saya hiraukan
    Namun ada satu mesin yang terus mencoba terhubung setiap beberapa detik dan itu sangat mengganggu; saya mencoba menghubungi administratornya, tetapi gagal
    Akhirnya saya memberi tahu dengan gaya “saya harap tidak ada masalah karena saya akan memulai layanan baru di port itu”, dan karena tidak ada jawaban, saya menjalankan server di port tersebut yang membaca /dev/urandom, menyalakan TCP_NODELAY dan semacamnya, lalu mendorong data acak secepat mungkin
    Kotak NT yang salah konfigurasi itu tersambung, menenggak data acak selama sekitar 5 detik lalu menghilang, kemudian 5 menit kemudian datang lagi, menelan obat buffer overflow, lalu menghilang lagi; pola itu berulang beberapa minggu sampai akhirnya lenyap sepenuhnya dari internet
    Saya kadang membayangkan ada admin yang garuk-garuk kepala bertanya-tanya kenapa kotak NT itu terus reboot

    • Sebagai programmer, kita harus selalu memberi batas atas pada jumlah data yang diterima dari pihak lain
      Setiap request harus punya batas waktu sekaligus batas jumlah data yang akan dikonsumsi
    • Pada masa yang mirip, ada sebuah perusahaan yang mengirim faks spam setiap Jumat, dan mereka mengabaikan beberapa pesan suara sopan yang saya tinggalkan
      Jadi saya membuat PDF 100 halaman yang setiap halamannya berupa persegi hitam besar, lalu mengirimnya lewat gateway email-ke-faks yang waktu itu masih baru; dalam satu jam ada telepon marah, dan faksnya berhenti
    • Saya penasaran pada masa itu biasanya bagaimana orang menemukan kontak administrator untuk klien sembarang
      Bagian “saya mencoba menghubungi admin kotak itu dan itu hal yang umum” terasa sangat menarik
    • Saya pernah memperbaiki deteksi down pada server RPi rumahan dengan cara asal-asalan: server melakukan ping ke domain milik saya, dan kalau gagal dianggap jaringan putus lalu reboot
      Setelah domainnya kedaluwarsa, RPi ini mati setiap 5 menit sehingga saya kira masalahnya pada daya, sampai kemudian saya teringat pekerjaan CRON itu
    • Mungkin Anda akan terkejut jika tahu bahwa sebagian besar instalasi NT yang menyediakan layanan pada era itu hampir tidak punya administrator yang akan menyadari apa yang terjadi
      Dalam ribuan kasus, alasan layanan seperti ini dijalankan di kotak NT justru adalah “supaya tidak perlu administrator”, dan itu tidak boleh diremehkan
      Pada era 90-an dan awal 2000-an, saya menaruh banyak server di internet, dan praktik standar di seluruh industri adalah memakai NT agar bisa dipakai tanpa admin

  • Saat kecil, secara bodoh saya pernah iseng memasang ln -s /dev/zero index.html di homepage saya
    Browser pada masa itu tidak bisa menanganinya dengan baik sehingga hampir membeku, dan kadang bahkan ikut menjatuhkan sistem klien
    Belakangan sepertinya browser mulai memeriksa konten sebenarnya dan menghentikan request semacam itu

    • Saya pernah memasukkan baris macroblock yang sama terus-menerus ke encoder hingga membuat JPEG 64k×64k
      Baru beberapa tahun kemudian akhirnya bisa dibuka
    • Saya penasaran apakah mungkin membuat file HTML 500TB dengan header yang tepat di atas squashfs, memasukkan konten tak berujung tanpa tag penutup, lalu membuat server tidak melaporkan ukuran file sebelum download
      Ada ide?
    • Saya teringat favicon.ico yang dulu membuat browser crash
      Mungkin yang ini: https://freedomhacker.net/annoying-favicon-crash-bug-firefox...
    • Semoga saat itu bukan situasi membayar bandwidth per KiB
    • Mungkin sekarang sudah saatnya membuat perangkat /dev/zipbomb

  • Sekarang hampir semua browser menerima zstd dan brotli, jadi bom seperti ini mungkin malah lebih efektif saat ini
    Komentar lama This menunjukkan rasio kompresi mengesankan 1.2M:1, dan zstd seems to be doing even better
    Namun bot mungkin tidak mendukung standar kompresi modern
    Sebaliknya, itu juga bisa menjadi cara yang bagus untuk memblokir bot: karena semua browser modern mendukung zstd, jika dipaksakan pada browser agent yang tidak ada di allowlist, scraper bisa otomatis dibuat kebingungan

    • Sebenarnya di demo one million checkboxes Datastar[1] saya, kompresi dipakai untuk menyaring bot
      Demo itu sangat bergantung pada streaming seluruh tampilan pengguna pada setiap interaksi, dan dengan brotli di atas SSE, rasio kompresi 200:1[2] mudah dicapai
      Masalahnya adalah aktor jahat bisa meminta stream tanpa kompresi
      Karena brotli didukung oleh 98% browser, saya tidak mengirim data ke klien yang tidak mendukung kompresi brotli; banyak scraper dan bot juga tidak mendukungnya, jadi ini bekerja cukup baik
      [1] demo checkboxes
      https://checkboxes.andersmurphy.com
      [2] artikel tentang brotli SSE
      https://andersmurphy.com/2025/04/15/why-you-should-use-brotl...
    • Kalau gzip ditumpuk lagi di dalam gzip, ukurannya jadi lebih kecil
      Itu karena blok data 0 yang sudah dikompresi oleh gzip generasi pertama sendiri memiliki entropi rendah, dan zst bertingkat dapat mengecilkan file 10G menjadi 99 byte
    • Saya penasaran bagaimana browser saya akan bereaksi kalau menerima bom seperti ini
      Saya tidak ingin mencobanya sendiri
    • gzip ada di mana-mana, dan bisa mengganggu semua crawler

  • Bagian tentang bot yang menemukan kerentanan WordPress di tempat kerja lama lalu memasukkan skrip berbahaya ke server memang sedikit keluar topik, tapi menarik
    Justru agak lega mengetahui bahwa bukan cuma saya yang mengalami PHP shell yang secara ajaib terpasang di server hanya 1 jam setelah WordPress diinstal

    • Saat mengambil alih situs WordPress pelanggan, jadinya “oh, ada 3 PHP shell dengan nama string acak”
      Tidak pernah kurang dari 3, selalu terjamin
    • Kalau ingin tetap waras, jangan host WordPress sendiri
      Kalaupun bukan pada satu jam pertama, pada akhirnya akan meledak begitu suatu saat lupa patch
    • Saya belum pernah meng-host WordPress, tapi begitu mengekspos server HTTP ke internet, request seperti /wp-login langsung masuk
      Ini juga bisa jadi cara bagus untuk menemukan bot; begitu melihat IP yang meminta path terkait CMS terkenal, langsung saya masukkan ke lubang iptables
    • WordPress adalah backdoor yang hebat, dan bahkan punya fitur CMS bawaan
    • Saya pernah memakai ini saat mengajar DevOps
      Saat berkata “coba deploy server nginx hello world pertama kalian”, tidak lama kemudian request aneh mulai terlihat di log

  • Saya pernah melakukan hal serupa juga di ssh: saya menemukan cara untuk membunuh klien ssh yang mencoba menebak kata sandi root
    Sebagai gantinya, beberapa script kiddie melancarkan DDoS ke server kecil saya, dan akhirnya saya beralih ke cara mengidentifikasi pelaku yang jelas-jelas berniat buruk lalu memblokir IP mereka dengan aturan firewall
    Namun di IPv6 ini menjadi lebih sulit
    Jika Anda membuat halaman web sendiri, Anda juga bisa memasukkan zip bomb ke halaman melalui tautan yang tidak terlihat oleh mata manusia
    Misalnya anchor berupa teks putih di latar putih tanpa highlight saat hover/click; bot akan mengunduh dan memeriksanya, begitu juga crawler dan scraper AI

    • Saya memakai variasi metode ini pada formulir permintaan akun di server fediverse saya
      Masalahnya adalah bot yang sangat sederhana, yang menjelajahi web dan mengirim spam kasar ke semua formulir yang terlihat seolah akan dipublikasikan
      Awalnya saya menambahkan CAPTCHA sederhana berupa karakter terdistorsi, dan itu memblokir banyak bot, tapi tidak semuanya
      Dari log server, bot-bot ini hanya mengirim tiga request secara cepat: halaman yang berisi formulir, gambar CAPTCHA, dan request POST data formulir; mereka sama sekali tidak memuat CSS atau JS
      Jadi saya menambahkan beberapa field lagi ke formulir, menyembunyikannya dengan CSS, lalu membuat request gagal dan sesi diblokir jika ada apa pun yang dikirim di field tersebut
      Selain itu, saya menjadikan gambar CAPTCHA sebagai background CSS dan mengganti src dengan gambar transparan; setelah itu spam berhenti total dan pengguna nyata tidak menyadari apa pun
    • Jika ingin mencegah perilaku semacam ini, ini layak dicoba
      https://github.com/skeeto/endlessh
    • Kalau tautannya tidak terlihat oleh mata manusia, saya khawatir bagaimana nasib pengguna screen reader
    • Saya tidak tahu mengapa pemblokiran firewall lebih sulit di IPv6
      Di antara keduanya, justru terlihat lebih mudah
    • Tautan seperti itu bisa terlihat oleh orang yang memakai browser teks, screen reader, bookmarklet yang menampilkan daftar tautan halaman, dan sejenisnya

  • Zip bomb itu menarik
    Saya pernah menemukan kerentanan pada sebuah produk keamanan: jika sebuah arsip zip lebih besar dari ukuran tertentu, atau file berisi arsip seperti itu, produk tersebut tidak melakukan pemindaian malware dengan benar
    Dalam praktiknya, jika zip bomb dimasukkan ke dalam dokumen Office XML, produk itu bisa meloloskan file OOXML meski berisi malware yang mudah diidentifikasi

    • Masalah ukuran file masih tetap ada di banyak EDR terkenal

  • Saya mencoba men-deploy ini sebagai ganti skrip honeypot yang biasa saya pakai, tapi sepertinya tidak bekerja dengan baik
    Dari log web server, bot-bot tidak mengunduh seluruh racun 10MB itu; mereka berhenti di berbagai panjang
    Sejauh ini saya belum melihat ada yang mengambil lebih dari sekitar 1,5MB
    Atau mungkin sebenarnya sedang bekerja? Bisa saja mereka mati saat mendekode stream secara langsung
    Misalnya jika tercatat membaca 1,5MB, mungkin mereka crash saat mendekodenya secara langsung menjadi 1,5GB di memori
    Tidak ada cara untuk memastikannya

    • Labirin konten layak dicoba
      Bentuknya seperti konten yang dibuat tanpa henti dengan banyak referensi ke halaman generator lain
      Ini bisa membantu sampai wget sederhana dan bot beradaptasi
      Sebagai tambahan, saya sebenarnya berada di pihak bot, tapi tidak masalah membantu
    • Mungkin ukuran file perlu dibuat setengah acak
      Sepertinya sebagian bot punya hard limit untuk ukuran resource yang akan diunduh
      Karena cukup banyak di antaranya adalah bot scraping/pelatihan LLM yang menyebalkan, meski zip bomb 800KB tidak membunuh mereka, setidaknya bisa memboroskan sumber daya komputasi pihak sana
    • Jika mereka kembali, berarti mereka mendeteksi dan menghindarinya; jika tidak kembali, berarti crash, jadi misi selesai

  • Perlu dicatat bahwa ini bukan file zip klasik, melainkan gzip bomb
    Ini bukan cara menjatuhkan antivirus dengan zip bersarang, melainkan bekerja seperti halaman web terkompresi biasa

  • Beberapa waktu lalu, sebagian infrastruktur circumvention milik Tor Project dijalankan dari situs yang sama dengan tulisan blog tentang zip bomb[0]
    Salah satu file zip itu di-crawl oleh Google dan masuk ke daftar domain berbahaya, sehingga bagian yang cukup penting dari tool Snowflake milik Tor rusak
    Butuh beberapa minggu untuk menyelesaikannya[1]
    [0] https://www.bamsoftware.com/hacks/zipbomb/
    [1] https://www.bamsoftware.com/hacks/zipbomb/#safebrowsing

  • Untuk melindungi upload di aplikasi saya, saya membuat partisi disk sementara berukuran tetap masing-masing sekitar 10MB dan mengekstrak arsip di sana
    Kalau ada yang mengunggah sesuatu yang terlalu besar, dampaknya tetap terkurung di dalamnya

    • unzip -p | head -c 10MB
    • Jadi alih-alih tidak mengekstrak file yang ukurannya tidak masuk akal, Anda malah repot-repot mempartisi disk?