自分のサーバーを守るために ZIP Bomb を使っている
(idiallo.com)はじめに
- インターネットトラフィックの大半はボットであり、その一部は悪意のある目的(スパム、ハッキングなど)を持っている。
- 筆者は過去にボットが原因で WordPress サーバーが感染したり、Google 検索から除外されたりする被害を受けた。
- これを防ぐために Zip Bomb を使い始めた。
本文
-
Zip Bomb とは?
- 小さいが、展開すると非常に大きな容量に拡張される圧縮ファイル。
- 1MB の圧縮ファイルが 1GB に、10MB は 10GB に膨れ上がり、サーバーを麻痺させる。
-
既存の gzip 機能
- Web では転送効率のために gzip 圧縮が使われている。
- ほとんどのボットも gzip 圧縮に対応している。
-
Zip Bomb による対処方法
- 悪性ボットだと判断した場合、
200 OKとともに gzip 圧縮された Zip Bomb ファイルを返す。 - このファイルを開く途中で、ボットがサーバー側でダウンしたり停止したりする。
- 一般的には 1MB(1GB に拡張)または 10MB(10GB に拡張)を使う。
- 悪性ボットだと判断した場合、
-
Zip Bomb の生成方法
dd if=/dev/zero bs=1G count=10 | gzip -c > 10GB.gz/dev/zeroで 10GB のゼロバイトデータを生成した後、gzip で圧縮する。- 出来上がるものは約 10MB サイズの zip bomb。
-
サーバーへの適用例
- ミドルウェアで IP ブラックリストまたは悪性パターンを検知したら Zip Bomb を送信する。
if (ipIsBlackListed() || isMalicious()) { header("Content-Encoding: deflate, gzip"); header("Content-Length: "+ filesize(ZIP_BOMB_FILE_10G)); readfile(ZIP_BOMB_FILE_10G); exit; }
結論
- Zip Bomb は 完璧な防御策ではない。
- 巧妙なボットはこれを検知して回避できる可能性がある。
- しかし、無差別に Web クローリングを行う低品質なボットには 効果的な防御手段 になる。
- 一部のサーバーリソースを使うとしても、セキュリティのために十分な価値がある。
29件のコメント
スパムトラフィックを発生させるボットを効果的に遮断する方法がないなら、一度試してみてもよい方法だと思います。
宅配泥棒にグリッターボムを渡す話みたいで、面白く読みました :)
あの動画、面白いですよね。それとまったく同じですね(笑)
インターネット上の文章は、誰かが所有する宅配便ではありません。
それが非公開の所有物なら、認証手続きを入れていたでしょう。
道端にチラシを1枚置いて、そこに猛毒を塗っておくのと似ていると見てもよさそうですね。
それは、悪意をもって毒を塗ったビラを貼っておくのとは別の概念ですよ。
倫理的に良い方法ではないですね。根本的な解決策でもありません。
こういう類は初めてなのですが、根本的な解決策が何なのか気になります!!
同意します
悪意のあるボットは、まあ倫理的なやり方なのか?(笑)
本当に悪質なボットは、こういうやり方では捕まえられません。
gzip爆弾も効かないし、
ただの知らない人が面白半分で爆弾ネタの投稿を1つ書いた、くらいに見ればいいです。
こういう人たちのせいで正当防衛が認められにくくなるんだな、ってことか(笑)...
倫理的に良い方法ではないのはなぜでしょうか? 気になります。
面白い記事ですね! 思いもよらない方法だったので、教えてくださってありがとうございます!
こういう文章を投稿する目的は何なのでしょうか?
実際にクローラーを回している企業がこの記事を読んで、除外対象にする可能性はほとんどないと思うのですが。
では、この記事はどんな読者を対象に書かれたものなのでしょうか?
同じようにブログを運営している人たちに、こういう方法があると知らせる紹介文なのか、
それとも「うちのブログはこんなにセキュリティが強いから、できるものなら一度クローリングしてみろ」という煽りなのでしょうか?
記事を投稿して何を得たいのか、本当に気になります
こういう方法もあるということではないでしょうか..
個人ブログなのに、好き勝手に書いちゃだめなんですか? 🤔
もちろん、公の場ではないので、深く考えずに投稿しただけかもしれません。
コミュニティで深く考えずにコメントすることがあるのと同じように。
私はクローラーを完全に防ぐことはできないので、そもそも試行自体を受け付けないのがいちばん良いと思うのですが、注目を集める意図が何だったのか気になりました。
つまり、IPでボットだと判断した場合も爆弾を送りつけるってことですね(笑)
筆者に怒りが感じられます(笑)
agentが bot だと言ってくるリクエストに爆弾をお見舞いするということですが……あまりにも悪意的ですね。どうせ agent は簡単に偽装できます。本当に悪意のあるボットなら、悪意を表には出しません。
最近は、LLM連携サービスからの過剰なトラフィックによる被害事例が時折見られますが、実際にはそうした類いへの対策としても見られる気がします。たとえばChatGPTのWeb検索機能などを見ると、そのユーザープールの特性上、「悪意のない」過剰なトラフィックが発生する余地が大いにあり、こうしたものは簡単なエージェントマッチングで容易にふるい分けられると聞きました。これが本当に意図通りなら、罪のないOpenAIのサーバー費用(と評判?)をただ食いつぶすだけの道ですが……
だから、意味のない文章だということです
OpenAIは、すでにそのくらいの礼儀(?)は持てる大きな……会社ではありますよね。
そして、おそらくユーザーが直接検索結果をクリックする程度では負担になるようなトラフィックは発生しにくいと思いますし、問題はクローラーが過度に動作しすぎることではないでしょうか?
おっしゃる User-Agent であれ、元記事で言及されている IP ベースの検知であれ、識別情報は偽装可能なので、悪意があるかどうかを断定するのは難しいという点には同意します。実際、悪意のあるボットはもっと巧妙にアクセスしてくるでしょう。
私としては、このような攻撃への対策としては、むしろ負荷制限付きのクローリング API を提供し、正当な自動化アクセスは許可しつつサーバー資源は保護する、という方向のほうが、より現実的な「ナッジ」なのではないかと思います。笑
すでに私たちがずっと前から合意していた bots.txt というものがありますよね..
この記事とは関係のないコメントですが、普段見ている hada で最近、悪質なコメントをするユーザーが何人か目に見えて増えた気がします。コメントがなかったり、数件しか付かなかった頃の雰囲気とはかなり変わってしまったように思います。
個人的には、ブロック機能があるか、多数の通報を受けたコメントをグレー表示にする機能があるとどうかと思います。
高く評価されたユーザーには、そのような機能が付与されるものと推測されます
2222222222222222