設計のシンプルさ。 エピソード1. Warhol's Worm

可能な限り単純ですが、単純ではありません



2001年、CodeRedの流行後、Nicholas Weaverは急速に広まったワーム、Warhol Worms:The Potential for Very Fast Internet Plaguesについて非常に興味深い記事を書きました。 記事の要約:ワームの伝播メカニズムにいくつかの最適化が追加されると、ワームは15分以内に脆弱な集団全体に影響を与え、さらに速くなります。 大まかに言って、管理者がコーヒーを飲み終えるよりも、インターネットを壊す方が速いです。 最適化は興味深いものでした:

  1. ヒットリストスキャン(最初の穏やかな指数関数的成長段階を回避するために、最初の1000〜10.000の犠牲者のリストを事前に作成します)
  2. 順列スキャン(感染したマシンを検出した場合は、アドレスリストにジャンプします。感染したマシンの次のアドレスがスキャンされる可能性が高いためです)
  3. 分割スキャン(親ワームはアドレス範囲を子孫に配布して、再スキャンを完全に防止します)
  4. サブネットスキャン-そもそもローカルサブネットの明らかなスキャン


ワームを作成するこのような機会に非常に感銘を受けました。 その後、 「モジュラーワーム」という記事をロールアップしました。将来のワームには交換可能なノズルがあり、ネットワーク上で直接更新するなどです。 私の記事はいつものように拒否され、5年後にはいつものように、ボットネットの構築に使用されたのはこれらのワームでした。 最初はAgobotあり 、その後物事が流れました。 「オープンソースワーム」という用語も登場しました。



本物のウォーホルワームは2003年2月25日に登場しました。 これはSQL Slammerと呼ばれ、MS SQL Serverに感染していました。 そして、このワームは単一のトリッキーな最適化を使用しませんでした。 単一のデータグラムに収まるように、それはUDPを介して愚かに配布されました。 それは簡単で、安くなりました。 結局、TCPは通信を開始するためだけに3つのパケットを送信する必要があることを皆知っています。 この場合、カーネルにデータ構造を保持し、応答を待機し、タイマーを設定するなどが必要です。 など 対照的に、UDPワームは、適合する限り、アップリンクをデータグラムで愚かに詰まらせる可能性があります。 そして、1Mビットは毎秒332個の「胞子」であり、各論争は376バイトです。 ワームの世界的な拡散は10分で発生しました。 私の統計は10分単位で収集されたので、たぶんもっと速いと思いました。 また、あるファイルにはワームはありませんでしたが、次のファイルにはすでにワームがありました。 タイムスタンプを確認しました-はい、約10分です。 外国人の同僚も10分言った。 この記録はまだ壊れていません。



したがって、ワーム構築の分野で最も顕著な結果は、洗練されたメカニズムや最適化ではなく、シンプルさと安さによって達成されました。



All Articles