サーバー保護のための Zip Bomb 利用

• Webトラフィックの大半はボットによるものであり、その一部は悪意ある目的で使われる
• Zip Bombは小さな圧縮ファイルだが、展開すると非常に大きなファイルに拡張され、サーバーに過負荷をかける可能性がある
• 圧縮技術は Web 上でデータを効率的に転送するために使われ、ボットもこれを活用する
• 悪性ボットを検知すると、サーバーはgzipで圧縮されたファイルを提供してボットを無力化する
• Zip Bomb は完全な解決策ではないが、単純なボットを防ぐのには効果的である

---

Zip Bomb を使ってサーバーを保護する

• Webトラフィックの大半はボットによるものであり、その一部は悪意ある目的で使われる
• 悪性ボットはサーバーの脆弱性を見つけ、悪意あるスクリプトを挿入してサーバーをボットネットへ変える可能性がある
• Zip Bomb は小さな圧縮ファイルだが、展開すると非常に大きなファイルに拡張され、サーバーに過負荷をかける可能性がある

圧縮技術の活用

• gzipは Web 上でデータを効率的に転送するために使われる圧縮技術である
• Webブラウザとボットはいずれも gzip 圧縮をサポートしており、これによって帯域幅を最大限に活用する
• 悪性ボットを検知すると、サーバーは gzip で圧縮されたファイルを提供してボットを無力化する

Zip Bomb の作成方法

• dd コマンドを使って 10GB のデータを生成し、これを gzip で圧縮して 10MB のファイルにする
• サーバーは悪意あるリクエストを検知すると、10MB の Zip Bomb ファイルを提供してボットを無力化する

Zip Bomb の限界

• Zip Bomb は完全な解決策ではなく、一部のボットはこれを検知して回避できる
• しかし、単純なボットを防ぐには効果的であり、サーバー保護に役立つツールである

関連記事

• 130万件の Web リクエストを処理する方法
• Apache サーバー署名の変更
• Google Analytics で Do Not Track を遵守する

[GN⁺]

Hacker Newsのコメント

• 子どものころ、いたずらで自分のホームページに ln -s /dev/zero index.html をやったことを覚えている。当時のブラウザはこれを嫌い、システムがフリーズしたり落ちたりすることもあった
  • その後、ブラウザが実際のコンテンツを確認し始めるようになり、この種のリクエストは打ち切られるようになった
• 今ではほぼすべてのブラウザが zstd と brotli をサポートしているので、この種の爆弾はより効果的かもしれない
  • 以前のコメントでは 1.2M:1 の圧縮率が示されていて、zstd はさらに優れた性能を見せていた
• ボットは最新の圧縮標準をサポートしていないかもしれない
  • これはボットを遮断する良い方法になり得る。すべての現代的なブラウザが zstd をサポートしているので、ホワイトリストにないブラウザエージェントにこれを強制すれば、スクレイパーを混乱させられるかもしれない
• 前の職場では、ボットが WordPress の脆弱性を見つけてサーバーに悪意のあるスクリプトを挿入したことがあった
  • WordPress を設定してから1時間で PHP シェルがサーバーに展開される、という経験をしたのが自分だけではないというのは面白い
• zip 爆弾は面白い。セキュリティ製品が一定サイズ以上の zip アーカイブを正しく検査しない脆弱性を見つけたことがある
  • その結果、zip 爆弾を Office XML ドキュメントに入れると、簡単に識別できるマルウェアが含まれていても製品を素通りしてしまった
• ssh を使って root パスワードを推測しようとする SSH クライアントをクラッシュさせる方法を見つけた
  • 結果として、スクリプトキディたちが自分のサーバーに DDoS 攻撃をしてきた
  • その後は「悪意ある行為者」を特定し、ファイアウォールルールで IP を遮断する方法に切り替えた
  • IPv6 のせいでますます難しくなっている
• Web ページを書く人なら、人間には見えないリンクで zip 爆弾を作ることができる（白い背景に白い文字、ホバーやクリックのアンカーにも強調表示なし）
  • ボットはそれをダウンロードして確認する（クローラーや AI スクレイパーも同様）
• これは gzip 爆弾であり（普通の圧縮 Web ページのように動作する）、ウイルスをブロックする昔ながらの zip ファイルではない
• 普通のハニーポットスクリプトの代わりにこれを配備したことがある
  • あまりうまくはいかなかった
  • Web サーバーのログを見ると、ボットは 10 メガバイトの毒を最後までダウンロードしていないことがわかる
  • さまざまな長さで中断している。今のところ、約 1.5Mb 以上取得したのを見たことはない
  • それとも動いているのだろうか。リアルタイムでストリームをデコードしてクラッシュしているのだろうか。たとえば、1.5Mb 読んだと記録されているものが、リアルタイムで RAM 上で 1.5Gb にデコードされてクラッシュしている可能性はあるのだろうか？
  • 知る術はない
• 少し前に、Tor Project の検閲回避インフラが zip 爆弾に関するブログ記事のようなサイトで運用されていた出来事があった
  • Google がその zip ファイルのひとつをクロールして悪性ドメインの一覧に追加し、Tor の Snowflake ツールの重要な部分が損なわれた
  • 問題の解決には数週間かかった
• 自分のアプリケーションのひとつでは、アップロードを保護するために 10MB の固定サイズの一時ディスクパーティションを作り、大きすぎるファイルがアップロードされた場合の影響を制限している
• 数年かけて組み合わせたスクリプトを使って、似たようなことをしている
  • 毎年 404 ログを確認し、最もよく使われる脆弱性パスをブラックリストに追加している
  • その URL を 3 回リクエストしたら、そのホストを、限られた正当なパスだけを許可するグレーリストに追加する