しつこい相手からサーバーを守るためzip bombを使ったらこうなった
引用元：https://news.ycombinator.com/item?id=43826798
2001年ごろの話だけど、家にstatic lineがあって、Linux boxで色々ホストしてたんだ．Windows NTのアップデートで、多くのNT boxがoptimistic encryptionとかいうのを有効にしちゃって、特定のポートでs/wanを交渉しようとしてTCP trafficを送ってくるようになったんだよね．firewallでそういうトラフィックをよく見てたから、別に大したことなかったんだけど．
でも、特に一つ、めちゃくちゃしつこいマシンがいたんだ．数秒おきに接続しようとしてきて、全然やめないんだよ．そいつのadminに連絡取ろうとしたんだけど（当時はみんなそうしてたんだよ）、全然ダメだった．
最終的に「あのさ、君のマシンがポート＜whatever it is＞に数秒おきに接続しようとしてるみたいなんだけど．ちょうどそのポートで新しいサービスを始めるから、君に問題起こさないか念のため知らせとくね．」ってメッセージを送ったんだ．
もちろん返事はなかったね．
で、そのポートにサーバーを立てたんだ．基本的に/dev/urandomから読んで、TCP_NODELAYとか他のフラグを設定して、ランダムなゴミデータをできるだけ速く送り出すようにしたんだ．クライアントはこのランダムな文字列がnull終端されてない方がいいかもしれないと思って、親切にも本来なら自然に発生するnullは全部取り除いたんだ．
その設定ミスったNT boxは接続して、5秒間ぐらいランダムデータを飲んで、それから消えたんだ．それから5分後、また現れて、接続して、そのbuffer overflow medicineを受け取って、また消えた．
このパターンが数週間続いて、最終的にそいつはインターネットから完全に消えたんだ．
きっと向こうのadminは、なんでNT boxが再起動しまくるんだ？って頭かきむしってたんだろうなって想像すると面白いね．
これを読んでるプログラマーのみんなへの教訓だけど、他人から受け取るデータの量には必ず上限を設定すべきってこと．全部のリクエストで、timeoutと消費するデータ量の制限を設けるべきだよ．
それは必ずしもリクエスト自体に入れる必要はないと思うな．
リクエストが一部になっているもっと広いプロセスとかシステム全体で制限することもできるでしょ．
これ読んで面白かったよ、シェアしてくれてありがとう．adminに連絡しようとしたって言ってたけど、当時ってどうやって適当なクライアントのadminの連絡先を見つけてたの？
それはそうだけど、やっぱりリクエスト単位で制限することをおすすめするよ．その方がプログラマーはリクエストが失敗する可能性があるってことをはっきり意識するようになるし、失敗をどうにか処理する必要があるってわかるからね．たとえそれがプロセスを強制終了して再起動するってことだとしても．
これに賛成．文脈によっては、長すぎるレスポンスを処理プロセスをクラッシュさせるより、もっと優雅に処理する方法があるかもしれないしね．
ただ、「バイト数が多すぎる」制限の問題は、時間が経つと共通のサイズだったものが今度は「小さすぎる」サイズになって、後から障害の原因になりがちだってことかな．画像とかを扱ってる場合とかね．
時間の制限の方が、bandwidthが多少制限されてれば、結果的にサイズも制限する傾向があるよ．
テクノロジーが進化したからって一つのユーザーフローで意図的にサービス拒否する方が、システムの一部が誤動作して全員に誤ってサービス拒否しちゃうよりはるかにマシだよ．
timeoutとかサイズ制限は、正当なニーズが見つかれば簡単にアップデートできるもんね．
当時はpostmaster@theirdomainとかwebmaster@theirdomainみたいなのは、実際に人が読んでたんだよ．あとwhoisコマンドもよく使えたね．
やあ、君にいくつかの障害発生後の報告書を見せてあげたいな．実際問題として、どこかに適当なサイズ制限を置くのは、クリティカルなシステムに「また更新が必要なssl-cert」を置くみたいなもんだよ．いずれ予期せぬ障害を引き起こすだろうね．
もちろん、誰か非難できる人はいるだろうけど、現実には、誰かが忘れてそれに突っ込むのは避けられなかったってことだね．
timeoutは色々な理由で、こういう問題が起きにくい傾向があるよ．
そしたらさ、正当なユーザーにも使われてるサービスも一緒にぶっ壊しちゃうかもよ。
スイスの大手ISPで働いてんだけどさ、今でもこういうメールボックスって実際に人が読んでるんだ（俺も含めてね）。だから今でも時にはやる価値あるんだぜ。
全然関係ない話だけどさ、家のRPiサーバーでダウン検知のめんどくさい修正したことあるんだ。自分のドメインにping打って、それがダメならネットワークに繋がってないか再起動したと見なしてたの。そしたらそのドメイン更新し忘れてさ、RPiが5分おきにダウンしまくり…電力障害かと思ったら、CRONジョブのこと思い出したわ。
驚くかもしれないけど、あの時代のNTのインストールでサービスを提供してる大半のケースでは、何が起きてるかに気づくような管理者はほとんどいなかったんだ。こんな風にNTでサービス動かすのは、‘管理者を置かなくて済むように’って目的で、数えきれないくらい何千件もそうだった。これは過小評価できないよ。免責事項として言うけど、俺は90年代から2000年代初頭にかけてたくさんのサーバーをネットに置いたんだ。‘管理者がいらないからNTを使え’って、業界標準のやり方だったんだよ。
それはどう設定するかによるね。例えば、リクエストごとにforkするなら、そのプロセスはそのユーザーだけに対応するし。もしくは十分早く再起動できるかとか。これは主にErlangに触発されてるんだ。
でも、制限を設けないと、バッファオーバーフローっていう別の種類のアウトの原因を作ることになる。これって攻撃者に悪用される可能性のあるセキュリティリスクにもなりうるんだ。
たぶんこの問題はプロトコルレベルで解決した方がいいだろうけど、それまでの間はサイズ制限が現実的だね。
ちょうど同じ頃か、もっと前かな。どっかの会社が毎週金曜日に迷惑FAX送ってきてたんだ。オフィス番号に何度も丁寧に留守電入れたけど無視されてさ。だから、100ページのPDFで、各ページが大きな黒い四角形になってるのを作って、当時流行りのメールtoFAXゲートウェイを使ってそいつらに送ったんだ。そしたら1時間も経たないうちに怒りの電話がかかってきたよ。迷惑FAXは止まったね。
1997年頃かな、同僚がメールリストに登録しちゃって、解除しようとしてもできなかった（確か手動だった）。そいつに提案したんだ、毎時間動くcronjobを設定して、解除リクエストのメールを送るようにって。解除リクエストの入ったテキストファイルを元にするんだけど、繰り返すごとにそのテキストを複製していく、実質的に等比数列的に増えていくようにね。そしたらリストオーナーが1週間かそこらで返信してきて、かなり緊急で同僚に止めるように要求してきたよ、リストから削除するって言って。どうやらリストオーナーはずっと休暇で留守にしてたらしい。
リクエストごとにforkするのは、速いサーバーにはならないだろうね。
これ、俺のテスト戦略の一つにつながる話だよ。ランダムにタイムアウトを短くしたり、バッファサイズを小さくしたりするのは簡単なんだ。それを使ってエラーを起こさせて、システムがどうなるか見るんだよ。一時停止して続けるか、それとも完全にクラッシュするか？
Stalwartで新しいメールサーバーを立てたんだけど、postmaster宛てに自動メールが届くようになったんだ（主にセキュリティ関連の結果だけど）。なかなかいい感じだよ。
Hetznerとかにポートスキャンされてるって問い合わせてみたけど、誰も気にしてくれないんだよね。Plexの開けてるポートへのスキャンでファイアウォール警告が出まくった時はさすがに問題にしたよ。そこからめちゃくちゃ調べていったら、ストリートアドレスのランダムな部分みたいなドメインがいっぱい見つかったんだ。明らかに自動生成で、関連ドメインを追跡しにくくするためにわざとやってるみたい。
責任あるドメインオーナーなら、そういうメールはちゃんと読むもんだよ。俺のpostmasterは、全部のドメインのキャッチオールにしてるんだ。ユーザー名のタイプミスも拾えるからね。家族用のドメインで、慌ててる医療スタッフが親のアカウント設定を間違えた時とかに、めっちゃ助かってるんだ。
IPアドレスのまとまりの所有者も調べられるんだ。昔は、特定のIPアドレスの責任者が誰かっていうのを、さらに特定するのをよく助けてくれたりもしたんだよ。
RP DNSレコード（https://www.rfc-editor.org/rfc/rfc1183）がずっと好きだったんだけど、もう誰も知らないみたいだし使ってないよね。俺のサーバーに今ついてない唯一の理由は、route53がサポートしてないからだよ。
tech-cとかabuse addressesは、whoisでよく見れたんだよね。
＞また更新しなきゃいけないssl-certを、なんかクリティカルなシステムに入れるなんてさ
これに対する解決策を数年前に見つけたんだ。openssl req -x509 -days 36500だよ。
いや、単なるOOMだよ。うん、どこかで制限は必要だけどね。それは勝手な制限じゃなくて、なんか処理の限界に基づいてるべきだよ。理想的には、例えばメモリ使用量が増えるにつれて適応するべきだね。
バカな子供だった頃の話なんだけどさ＜、＞ホームページでln -s /dev/zero index.htmlをジョークでやったんだ＜。＞＜br＞当時のブラウザはあれダメで＜、＞フリーズしたり＜、＞クライアントシステムごと落ちたりしたんだよ＜。＞＜br＞後からブラウザはコンテンツチェックするようになって＜、＞そういうのは止まるようになったと思うな＜。＞
昔＜、＞エンコーダーに同じマクロブロックの行をずーっと食わせて＜、＞64kx64kのJPEG作ったことあるんだよね＜。＞＜br＞何年か経って＜、＞やっと開けるようになったよ＜。＞
もっとコメントを表示（1）
この前さ＜、＞10MBくらいのデカいpng開けるのにめっちゃ苦労したんだ＜。＞ゲームのマップ画像繋げたやつ＜。＞＜br＞一部ソフトは開けないか固まるかぼやけるかでダメ＜。＞スマホのFossify Galleryは遅いけど見れた＜。＞＜br＞結局GIMPで開けたけど＜、＞RAM 8GB食った＜。＞GIMPのビューワー機能だけ欲しいわ＜。＞＜br＞ファイルはここ＜：＞https://0x0.st/82Ap.png＜br＞ブラウザじゃなくてcurl/wgetで落とすのがいいよ＜。＞
squashfs使ってさ＜、＞無限の＜div＞＜div＞＜div＞＜。＞＜。＞＜。＞って閉じタグない500TBのhtmlファイル＜、＞適切なヘッダー付きで作れないかな＜、＞あとサーバーにダウンロード前にファイルサイズ教えないように指示できるかなって思ってるんだけど＜。＞＜br＞なんかアイデアある＜？＞
うん＜、＞サーバーはチャンクエンコーディング使えばサイズ教えないで返事できるよ＜。＞残りはさ＜、＞「＜div＞」ってループで返すカスタムウェブサーバー作ればできるね＜。＞ブラウザがそういうのに弱いかは分かんないけど＜。＞
iPhone 12のsafariで5秒くらいで開いたよ＜。＞＜br＞パンとかズームもスムーズだよ＜。＞
サーバーサイドインクルード使ってhtml爆弾作れないかなって＜？＞＜br＞普通の静的htmlページ書いて＜、＞＜p＞タグの中に＜!–＜！＞–＜！＞#include file=”/dev/random”–＜！＞＞で無限のランダムデータ入れるとかさ＜。＞＜br＞それってサーバー落ちちゃうかな＜？＞
squashfsじゃなくて＜、＞OPと同じく圧縮版を配信してさ＜、＞クライアントに解凍とDOMの深さの両方でダメージ与えればいいじゃん＜？＞＜br＞yes ”＜div＞”|dd bs=1M count=10240 iflag=fullblock|gzip | pv ＞ zipdiv.gz＜br＞ファイルは15mibくらいなのに＜、＞解凍したら閉じタグないdivが17億個以上入ったヤバい奴になるよ＜。＞
メインページから見えないリンクにしちゃえばいいんじゃない＜？＞（ロゴの後ろとかに隠してさ）＜。＞ユーザーはクリックしないけど＜、＞ボットは食いつくから＜。＞
もしかしたら、/dev/zipbombみたいなデバイスがあってもいい頃かもね。
え、symlinkを設定したの？どうやってそれが動いたのかよく分からないな。もし実際の/devツリーがwebサーバーのchroot環境に公開されてなかったら、”ファイルが見つかりません”って表示されるだけで特別なことは何も起きなかったはずだよ。webサーバーのchrootの目的って、そういう特別なファイルにクライアントがアクセスするのを防ぐことだったじゃん！
たぶんサーバーの実装によるんだろうけどさ。でも、どうせhtml bombをいつ返すか判断するロジックが必要なんだから、なんでこの解決策が良いのか分からないな。ボットを検知してるスクリプトを使ってbombを返せば良いだけじゃない。
IrfanViewでRyzen 7 5800xだと、8秒くらいで2.8GBのRAMを使って読み込めたよ。でもズームとかパンはかなり遅かったな（1アクションあたり500msくらい）。
KiB単位で帯域幅にお金払ってなかったら良いけどね。
ゼロ除算って誰にでも起きるもんだよね。USS Yorktownが訓練中に3時間近く止まったのも、データベースアプリのゼロ除算エラーが制御システムに広まったかららしいよ。技術者が燃料バルブを調整するのに0を入力したのが原因みたい。
不思議だなあ、Safariを入れたiPhone 12 Pro Maxだと読み込みに30秒かかったけど、その後はパンやズームがスムーズだったよ。ChromeとEdgeがすぐに諦めて”壊れたサムネイル”アイコンになった16コア64GB RAMのWindowsマシンよりずっと良い感じだった。
かなり古いスマホのAndroidでFirefoxだと、ぼやけたプレビューが10秒くらいで表示されて、完全に表示されるまで20秒ちょいだったかな。その間ずっとパンもズームもスムーズだったよ。
君自身がどうやって動いたのか説明してるじゃん。たくさんのwebサーバーがchrootされてない、あるいはされてなかったんだよ。
これの問題は、tarpitの場合、ボットにとって高価にするだけじゃなくて、自分にとっても安価にしたいってことなんだよ。これは君にとって安くない。zip bombは安価だ。
他のスクリプトはナシね。人間がクリックできないように、爆弾へのリンクを画像の後ろに隠すんだ。
ln -s /dev/urandom /dev/zipbomb && echo ’Boom！’
まあ、これは本物のzip bombじゃないけどね。本物にはkernel moduleが必要になるかな。
これがscreen readerとか他のaccessibility deviceとどう連携するかってのが、まず最初に思ったことだね？
いやー、あの頃はbandwidthってkb単位で金払ってたからさ。
多分、同じengineがベースになってるからじゃない？
browserをcrashさせるfavicon.icoみたいだね。
これだと思うよ：https://freedomhacker.net/annoying-favicon-crash-bug-firefox…
そうそう、だから見えないlink + zipbombってのが「da bomb」なんだよ。
vectorベースのlayerが入ってるPDFファイル、e.g. 広いエリアのplanとかmapとかも、renderしたり開いたりするの結構大変なんだよね。
同じ経験だよ。Safariでズームして高解像度renderさせたらタブがcrashした。
部分ズームは平気だったけど、最大ズームで落ちたんだ。
Safariの賢いprogressive renderingでも、全解像度だとOOMとかでダメみたいだね。
Samsung S23 UltraのFirefoxだと数秒速かったけど、それ以外は同じ体験だったよ。
Pythonの小さいスクリプトでテストしてみたんだ。900MB/sくらいのレートでdiv送りまくったら、firefoxは1〜2GB受け取ったとこで「メモリ不足」エラー出してすぐ落ちちゃった。chromeの方は1MB/sくらいしか受け取らないくせにCPUを1コア100パーセント使って、メモリも無限に増え続ける感じ。3分で6GBくらい（起動時より追加で）消費したとこで強制終了したよ。
最近のブラウザはほとんどzstdとかbrotliに対応してるから、今の時代だとzip bombはもっと効果的かもね！これは昔のコメントだけど、1.2M:1っていうすごい圧縮率だったみたいだし、zstdはさらにすごいみたいだね。まあ、botは最新の圧縮規格に対応してないかもしれないけど。逆に言えば、それってbotをブロックするのに良い方法かも。最新のブラウザはみんなzstd対応してるから、ホワイトリストに載ってないブラウザエージェントにはzstdを強制すれば、スクレーパーとかを自動的に混乱させられるよ。
実は俺、これ（圧縮を使ってbotを除外すること）を、俺の100万個のチェックボックスのDatastarデモ[1]で実際にやってるんだ。これって、ユーザーのビュー全体をインタラクションのたびにストリーミングするのにすごく依存してるんだよね。brotli over SSEを使えば、簡単に200:1の圧縮率を達成できるよ[2]。問題なのは、悪意のあるアクターが非圧縮でストリームを要求してくる可能性があること。brotliは98パーセントのブラウザにサポートされてるから、brotli圧縮をサポートしてないクライアントにはデータをプッシュしないようにしてるんだ。それと、たくさんのスクレーパーやbotがこれに対応してないってことも分かったから、結構うまく機能してるよ。
[1] チェックボックス デモ https://checkboxes.andersmurphy.com
[2] brotli SSEに関する記事 https://andersmurphy.com/2025/04/15/why-you-should-use-brotl…
もっとコメントを表示（2）
gzipの中にさらにgzipを入れ子にすると、最初のgzipで作られた圧縮された ’0’ のブロック自体が低エントロピーだから、さらに小さくなるんだ。ネストしたzstdだと、10GBのファイルが99バイトになるらしいよ。
再帰的なファイル構造を自分で編集して作って、無限にできるのかな？昔、dosのdebugでFATを編集して、ものすごく巨大に見えるフロッピーディスクを作ってたのを思い出すよ。
https://research.swtch.com/zipit は基本的にクワインだよ。
でもbotはおそらく外側のレイヤーしか自動では解凍しないだろうから、ネストしてもbot対策としてはあまり役に立たないと思うよ。
それだと攻撃を無効化しちゃうんじゃないの？だって大きなコンテンツをサーバーが提供してないってことになるでしょ。
ボットがリンク経由でファイルにアクセスして解凍・内容チェックする必要あるね。圧縮ファイルを圧縮レスポンスで送れば二重構造でトラフィック減らせる。passwd.zstとかsecrets.docxは魅力的なファイルだろ？robots.txtにリストしたハニーポットディレクトリに餌仕掛けて、誰が釣れるか見てみようぜ。
前調べた時、タブが読み込み続けて固まり、RAM食いすぎるとタブのプロセス落ちたよ。「タブがブラウザ遅くしてる」とか出るくらいで、壊滅的な被害はないみたい。
タブプロセスが落ちるマズさはブラウザによるかな。サイト分離してるならそのサイトだけ落ちる。共有してるなら状態失うかも。Chromeは大丈夫、Firefoxは設定・タブ数で変わる、Safariは設定次第。Safariはzstd非対応だからbrotli爆弾が一番効くよ。
gzipはどこにでもあるから、どんなクローラーにも効くだろ。
＞ 前の会社で、ボットがwordpressの脆弱性を見つけて、サーバにヤバいスクリプト仕込まれたってさ
ちょっと話題ズレるけど、Wordpressを1時間セットアップしただけでPHPシェルが魔法みたいにサーバにデプロイされるって知って、面白くて（訂正: 安心した）よかったわ。
そうそう、正気でいたいならWordpressを自分でホストするのは絶対やめた方がいいよ。最初の一時間じゃなくても、パッチ忘れればいつかやられるだろうね。
13年もWordpress自分でホストしてるけど、全然問題ないよ :) 標準的なセキュリティ対策ちゃんとやって、プラグイン大量に入れなきゃ大丈夫。
Wordpressって、色々基本的な機能が足りなくてプラグイン入れなきゃいけない場面が多いんだよ。何やりたいかにもよるけどね。でも、とにかく最悪なプラットフォームだから、正直Wordpressを何かで使う理由なんてないと思う。どんな使い方でも、Wordpressより良い別の選択肢があるはずだよ。
非技術系の団体で、ページ編集したり資料アップしたりする人がいて、使いやすい画面が必要な場合、特に予算なくてボランティアで手伝ってる時、おすすめの代替策ある？Wordpress立てるのがすごく楽なんだけど、俺もあんまり好きじゃないんだよね。前、こういう時Drupal試したけど、彼らには難しすぎた。昔の話だから、今もっと良くなってるかもだけど。
Jekyllを使った静的サイトなんてどうかな？
JekyllとかのStaticサイトジェネレーターとWordpressは全然違うよ。WordpressはUIで複数人編集、画像追加、スマホ対応も楽。Staticサイトだとgit必須、手動ビルド、WYSIWYGなし、スマホ非対応で投稿が超めんどくさい。ブログをWordpressからStaticサイトに変えたら投稿の手間が増えて投稿頻度下がっちゃったんだ。
俺、カスタムWeb開発ばっかやってるから、ウェブサイトホスティングとか全然詳しくないんだけどさ。ちょっとだけ技術わかる人がウェブサイト立ち上げるのを軽く手伝うとしたら、今いいフレームワークとかある？ReactのSPAとかAPI付きのガッツリしたのじゃなくて。
非技術者の組織で、定期的にページ編集やドキュメントアップロードできる人がいて、そのために可能な限りユーザーフレンドリーなインターフェースが必要な場合の代替案を勧められますか？
25年前のMicrosoft Frontpageはファイル共有経由でワープロみたいに編集できてシンプルだった。あのシンプルさから後退して、Wordpressの場当たり的な方法が取って代わった気がするんだ。誰か俺が間違ってるって証明してくれ。
君の質問の感じだと、中小企業向けのウェブサイトを作りたい感じかな？それならjQueryくらいしか必要な”フレームワーク”はないと思うよ。何か売るならサードパーティサービスをiframeで埋め込む感じ。超大企業向けとか、それくらい大規模なウェブショップ全体を作るなら、俺じゃなくて他の人に聞いて。
みんなのお気に入りのStaticサイトジェネレーターは何？Googleで調べたらCloudflareの記事でJekyll, Gatsby, Hugo, Next.js, Eleventyが出てきたんだけど。それぞれの長所短所を調べるのはできれば避けたいんだけどさ。
Statamicこれ→https://statamic.com/
Wordpressはホストしたことないけど、インターネットにHTTPサーバー公開したらすぐに/wp-loginとかへのリクエストが来るようになるよね。あれ、ボット見つけるのにも結構使えるんだわ。人気のCMS関連のリクエストしてくるIP見たら、即iptablesの穴にぶち込んでる。
その理由の一つはFrontpageがWindowsサーバーを必要としたこと、それに付随する全て。
もう一つは、Frontpageで危険なCVEが連続して発生して、クライアントがパニックになったこと。
そして最後に、Frontpageの一部が人気出るたびに、MSがそのAPIを非推奨にして新しいものに置き換えたこと。
Wordpressは適切な場所、適切なタイミングで登場したんだ。
うちにはさ、（内部からしかアクセスできない）Wordpressがあって、そこでプラグイン使ってコンテンツをZIPファイルにエクスポートして、ちょっとしたスクリプトやAnsibleでNGINXサーバーにデプロイしてるんだ。
もっと自動化できるはずだけど、まあ両方のいいとこ取りって感じかな。
jQueryはもう何年も必要ないんだよ。jQueryコードのVanilla JS版は十分にサポートされてる。
https://youmightnotneedjquery.com/
