Tor、Onionサービスにプルーフ・オブ・ワーク防御を導入
(blog.torproject.org)- Tor 0.4.8では、OnionサービスがDoS攻撃を受けた際に検証済みのネットワークトラフィックを優先処理する防御が導入された
- IPアドレスを隠すOnionサービスの構造では、IPベースのレート制限は不完全であり、プライバシーを損なわないクライアントパズル方式が必要だった
- サービスに負荷がかかると、クライアントは徐々に難しくなるパズル計算で作業量を証明し、その水準に応じて接続の優先順位が変わる
- 一般ユーザーの初回の解答時間は高速なコンピュータで約5ms、低速なハードウェアでも最大30ms程度で、ほとんどのデバイスで対応可能
- 攻撃トラフィックが増えると要求される作業量は約1分まで増加し、大量の接続試行を高コスト化する一方、正規ユーザーは混雑時でもアクセス機会を得られる
Tor 0.4.8のOnionサービス向けPoW防御
- TorはTor 0.4.8のリリースに合わせて、Onionサービス向けのプルーフ・オブ・ワーク（PoW）防御を正式に導入した
- 目的は、DoS攻撃を抑止しつつ検証済みトラフィックを優先処理すること
- Onionサービス運営者にはバージョン0.4.8への更新が推奨される
- Onionサービスはユーザーのプライバシー保護のためIPアドレスを隠すため、DoS攻撃に対して脆弱になりうる。また、従来のIPベースのレート制限だけでは保護が不十分である
クライアントパズルと優先処理
- PoWは、通常は無効になっているチケットシステムのように動作し、ネットワークに負荷が生じると優先キューを作る
- クライアントはOnionサービスにアクセスする前に小さなパズルを解き、一定の作業量を行ったことを証明しなければならない
- パズルが難しいほど、より多くの作業を行ったことを意味する
- Onionサービスは、クライアントが示した努力の水準に応じて接続の優先順位を決める
- 攻撃者が大量のリクエストでOnionサービスをフラッディングすると、.onionサイトへのアクセスに必要な計算負荷が増える
- 大量の接続試行には、より多くの計算資源が必要となる
- 作業量が増えるほど、攻撃者の採算性は低下する仕組みである
一般ユーザーに見える影響
- 一般ユーザーは通常一度に送るリクエスト数が少ないため、パズル解答の負担はほとんどのデバイスで管理可能な水準に収まる
- 初回の解答時間は高速なコンピュータで約5ms
- 低速なハードウェアでは最大30ms
- 攻撃トラフィックが増えると、作業量はおおよそ1分まで増加しうる
- この過程はユーザーには見えず、PoWの解答を待つ体験は低速なネットワーク接続を待つのと似ている
- 主要サイトがこの方式を採用すれば、標的型攻撃がネットワーク速度に与える悪影響を減らせるほか、突発的なトラフィック急増時の負荷分散にも役立ち、Onionサービスへのアクセスをより一貫性があり信頼できるものにできる
1件のコメント
Hacker News の意見
興味深い。提案書を見ると期待値は明確です。大規模ボットネットを防ぐものではなく、スクリプトキディや小規模ボットネットへの防御を目標にしています
DoS 攻撃中でも本当に接続しようとするユーザーは通過できますが、ある程度の手間が必要になる場合があります
Proof-of-Work アルゴリズムとして https://github.com/tevador/equix を選んでいるのも興味深いです
Bitcoin のように静的な目標値を下回れば成功する方式ではなく、クライアントが Proof-of-Work の努力量で「入札」し、より多くの努力を払うほど優先順位が高くなる仕組みです。コインを預ける代わりに作業を預けるという点で、Proof-of-Stake に似ているという説明です
[1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...
このバージョンも良いですが、価値移転が追加されるとさらに良いと思います
しかも Proof-of-Work は、無駄な不要計算にすぎません。計算は無料ではなく、Proof-of-Work に使うすべてのワットは現在の気候危機をさらに悪化させます
数日以内に体感 120 度、実際 109 度まで上がる地域に住んでいる身としては、丁寧に言えば、Proof-of-Work が何に対してであれ良いアイデアだと提案する人にはくたばれと言いたいです
興味深いのではなく、地球上で最も露骨な顕示的消費の事例です
より良い記事、つまり実際の技術的詳細は https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p... です
選ばれた Proof-of-Work 関数は equi-X のようです
こういうものがもっと早く入らなかったのは驚きですし、提案書 [0] を十分詳しく読んでいないので、ユーザーの匿名性に影響するデータが増えるかはまだ分かりません。それでもユーザー・サービス単位でひも付けられ、どこにも保存されないなら問題なさそうです
プロキシされるサービスの負荷とノード自体の負荷を、それぞれどれくらい減らすのかも気になります。アクセスが複数ノードに分散されるので、サービス側のほうがより大きな恩恵を受けそうです
[0]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
良いですね。近いうちに DDoS 防御用 CDN が不要になるかもしれません。API を Onion サービスとして提供すればよいのです
この方式は以前、メールスパム防止用としても提案されたことがあります
Cloudflare でもできます。混雑しているサイトにアクセスするたびに、数秒から数分間、役に立たない計算を回させる形です。全体としては世界中のバッテリーを吸い上げる効果になりそうです
http://www.hashcash.org/
興味深いことに、Bitcoin の Proof-of-Work マイニングの着想元になりました
温室効果ガスも大気中に吐き出すことになるので
Proof-of-Work が機能し始めたとき、悪用者が新しいアイデンティティを取得して DDoS を続けるのを何が防ぐのか気になります
修正: クライアントではなく、攻撃を受けている「サービス」単位で Proof-of-Work が設定されるようです
匿名性や自由に新しいアイデンティティを作れる特性のため、攻撃者はシビル攻撃で容量を枯渇させ、サービス拒否を引き起こせます
ここでシビル攻撃をもっと優雅に解決する方法があるのか気になる。たとえば多くの CPU にはプロセッサごとに固有の鍵ペアが入っており、発行者である Intel、AMD などの CA ルート証明書で検証できる。作業証明を連続署名と結び付け、並列検証を許せば、すべての作業証明が CPU ごとに固有になり、ボットネットで並列化できなくなる
彼らはボットネットのコストを上げるためにメモリを狙っているように見える。この攻撃シナリオを減らす別の方法も多くありそうだ。同じ論理は ESIM を使う携帯電話にも適用できそうだ。その後のモバイルネットワーク認証は公開鍵暗号を使うので、固有の証明も可能だと思う
ただ思い付いただけなので、この方式の明らかな問題を見落としている可能性は大きい
メモリを多く使うアルゴリズムを選んだ理由は、特定のハードウェア、つまり ASIC の使用を防ぐためだ
似た方向で、サーバーが複数の IP プールを持ち、クライアントにポートノッキングの証明を返させるのはどうだろう。たとえばトークンを渡し、この IP:ポートへ送らせ、自分が検証できる固有の応答を待つ、という形だ。これはレイテンシ証明と呼べるかもしれない。CPU 使用量は低く、負荷を複数のマシンとポートに分散できる。欠点は当然、複数の IP と、潜在的には複数のサーバーが必要になることだ。同じマシンでも実装はできるだろうが、その場合 CPU 負荷がポート接続へ移るだけだ
Tor ネットワークのトラフィックを減らしたり、より高速にしたりするアイデアがある。ネットワークを CDN のように使えるべきだ。ファイルを公開したいなら、許可したノードにファイル片を送り、ファイル要求が来たらそのノードを指し示せるようにするべきだ
もちろん Tor ネットワークが「匿名 Torrent 代替」になって目的を損なわないよう注意しなければならない
現在の提案は「検証済みネットワークトラフィックの優先順位付け」をうたっている。実際にネットワークを助けるものなので、「ファイル片」共有がトラフィックの優先順位を上げられるなら面白そうだ。「作業証明」の代わりに帯域幅貢献証明になるわけだ
とはいえ、それがネットワークトラフィックをどう減らすのかはよく分からない。結局 CDN ノードと通信する必要がある
この提案が立てた目標と制約を見ると妥当で、おそらくその目標は達成しそうだ。述べられているように小規模なボットネットには効くだろうが、大規模なボットネットはなお個々のクライアントの利用可能リソースを圧倒できる
個人的には作業証明は好きではない。ここでは防御メカニズムとしての非対称性に近く、古いハードウェアを急速に時代遅れにし得るし、影響を受けるデバイス全体で見るとかなり多くの電力を使う可能性がある。大規模に適用されれば相当な環境負荷になる
攻撃者の立場では、難易度をそこまで高くさせること自体も成功と見なせるだろう。ユーザーがデバイスを 100% で動かしながら 1 分待たなければならないなら、多くの場合そのまま離脱するからだ
それでもユーザーの匿名性を損なわずに DoS 攻撃を緩和するかなり良い方法なので、その観点では欠点にもかかわらず良い解決策だ。Tor に存在する限り大きな問題はないが、一般の Web に適用されたら完全な災厄だと思う
記事では、高性能サーバーと低スペックの携帯電話の解答時間の差は6倍にすぎないという。これがどう可能なのか分からない。サーバーは携帯電話より RAM と CPU の数が 6 倍よりはるかに多く、CPU もより高速である可能性が高い
また DDoS ならサーバー側の作業は困るほど並列化しやすいが、クライアント側の作業は必ずしも並列化されないかもしれない
その差が 6 倍、あるいは 1 倍にすぎないとしても、DDoS が検知されると解答時間は 1 分だという。その時点でサービスは実質的に落ちているのではないか？
DDoS が検知されると解答時間が 1 分という部分の核心は、従来の容易な DoS 攻撃である introduction flooding を、部分的な障害や速度低下へ変えることだ。難しい問題に対する漸進的な改善である