このページでは、DoS攻撃を軽減する方法をいくつかご紹介します。 これらのアプローチはすべて組み合わせることができます。 しかし、現時点では、この問題に対する唯一無二の解決策はありません。 攻撃を受けているサイトを防御するには、創造性とカスタマイズされたアプローチが必要です。

Tor デーモンに実装されている防御の概要につきましては、Tor のサービス妨害防止メカニズムの概要セクションをご覧ください。

導入ポイントでのレート制限

提案 305 が実装されてから、導入ポイントでの DoS 攻撃を軽減するために、いくつかのtorrc オプションが追加されました。

  • HiddenServiceEnableIntroDoSDefense: イントロポイントレベルでDoS防御を有効にする。 これを有効にすると、レートおよびバーストパラメーターがイントロポイントに送信され、イントロポイントはそれらを使用してこのサービスへの導入要求のレート制限を適用します。

  • HiddenServiceEnableIntroDoSBurstPerSec: 導入ポイントで許可される1秒あたりのクライアント導入バースト。 このオプションが0の場合は無限と見なされるため、HiddenServiceEnableIntroDoSDefense が設定されている場合は、防御が実質的に無効になります。

  • HiddenServiceEnableIntroDoSRatePerSec: 導入ポイントで許可される1秒あたりのクライアント導入レート。 このオプションが0の場合は無限と見なされるため、HiddenServiceEnableIntroDoSDefense が設定されている場合は、防御が実質的に無効になります。

動作の詳細につきましては、tor (1)マンページおよび Onion Service v3 仕様書の DoS 防御拡張 (DOS_PARAMS) セクションをご覧ください。

ランデブー回線を確立する前の Proof of Work (PoW)

Proof of Work (PoW) 防御メカニズムについては、PoW FAQ で詳しく説明されており、Onion Service ごとに以下の torrc オプションを設定することができます。

  • HiddenServicePoWDefensesEnabled: Proof of Work ベースのサービスDoS軽減策を有効にします。 有効にすると、Tor はこの Onion Service の記述子の暗号化された部分にオプションのクライアントパズルのパラメーターを含めます。 受信したランデブー要求は、パズルの解を計算するときにクライアントが選択した作業量に基づいて優先順位が付けられます。 サービスは、攻撃負荷に基づいて推奨される作業量を定期的に更新し、サービスが過負荷になっていない場合はパズルを完全に無効にします。

  • HiddenServicePoWQueueRate: 優先キューから1秒間にディスパッチされるランデブーリクエストの持続率。

  • HiddenServicePoWQueueBurst: 優先キューから一度に処理されるランデブーリクエストの最大バーストサイズ。

以下のグローバルオプションは、Onion Service とそのクライアントの両方に適用されます。

  • CompiledProofOfWorkHash: Proof of Work による DoS対策が有効な場合、サービス自体と接続するクライアントの両方が、パズル計算の一部として動的に生成されたハッシュ関数を使用します。

C Tor バージョン 0.4.8.1-alpha 以降では、PoW はデフォルトで有効になっています (ただし、--disable-module-pow を指定してコンパイルすると無効にできます) 。 基本的な PoW のサポートは、以下のコマンドを実行して確認できます。

tor --list-modules
relay: yes
dirauth: yes
dircache: yes
pow: yes

pow: yes があれば、C Tor に PoW 防御メカニズムが組み込まれています。

ライセンス要件により、PoW v1クライアントパズルライブラリー (tevador による Equi-X および HashX 、どちらも LGPL-3.0 準拠) は、tor が --enable-gpl でコンパイルされている場合にのみ有効になります。 これは、以下のコマンドを実行して確認できます。

tor --version
Tor バージョン 0.4.8.3-rc。
この Tor ビルドには GNU General Public License (https://www.gnu.org/licenses/gpl-3.0.en.html) が適用されています
Tor は Linux 上で Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd N/A, libc として Glibc 2.36 で動作しています。
GCC バージョン 12.2.0 でコンパイルされた Tor

インストールした C Tor が PoW を有効にしていなかったり、GNU GPL サポート付きでビルドされていない場合は、他のパッケージを探すか、自分でコンパイルする必要があります。

確立されたランデブー回線のストリーム制限

次の設定オプションを使用して、ランデブー回線の接続を制限できます。

  • HiddenServiceMaxStreams: ランデブー回線ごとの同時ストリーム (接続) の最大数。 指定できる最大値は 65535 です。(これを0に設定すると、無制限の数の同時ストリームが許可されます。)

  • HiddenServiceMaxStreamsCloseCircuit: 1に設定されている場合、HiddenServiceMaxStreams を超えると、問題のあるランデブー回線が切断されます。これは、制限を超えるストリーム作成要求が暗黙的に無視されるのとは対照的です。

Onionbalance

Onionbalance を使用すると、Onion Service のオペレーターは、複数のマシンが Onion Service の要求を処理できるようにすることで、高可用性の特性を実現できます。 Onionbalance を使用すると、水平方向に拡大縮小できます。 規模が大きくなればなるほど、攻撃者が圧倒するのは難しくなります。 Onionbalance は v3 Onion Service でご利用いただけます。

ウェブサーバーのレート制限

攻撃者があまりにも多くのクエリを実行する攻撃的な回線によってあなたを圧倒している場合は、torrc オプションHiddenServiceExportCircuitIDを使用して、その過剰使用を検出し、それらを強制停止するようにしてください。 独自のヒューリスティックスを使用するか、ウェブサーバーのレート制限モジュールを使用することができます。

上記のヒントは、波乱の状況で安定を保つのに役立つはずです。 同時に、私たちはより高度な防御に取り組んでいます。これにより、Onion Service の運営者が手動で設定したり、変更したりする必要が少なくなります。

キャッシュ

サービスの負荷を軽減するもう1つの方法は、バックエンドアプリケーションで直接、またはキャッシュプロキシフロントエンドを設定して、コンテンツキャッシュを実装することです。

クライアント認証または複数の Onion アドレスによるユーザーの区分け

信頼できるユーザーがいる場合は、専用の Onion Service とクライアント認証資格情報を提供して、常に使用できるようにしてください。 信頼できないユーザーについては、複数のアドレスに分割します。 ただし Onion アドレスが多すぎると、(多くのガードノードが使用されるため) 実際にはセキュリティに悪影響を及ぼすため、可能な限りクライアント認証を使用するようにしてください。

Captcha と Cookie

さらにユーザーのレートを制限する必要がある場合は、インフラストラクチャをレイヤーに分割し、フロントエンドの近くに Captcha を配置します。 こうすることで、攻撃者は Captcha を解決しないと、インフラストラクチャの奥深くまで攻撃することができなくなります。

Captcha とは DDoS 攻撃を和らげるための方法です。 クライアントから要求があった場合、クライアントに正しいセキュア Cookie が含まれているかどうかを確認します。そうでない場合は、reCaptcha ページにリダイレクトします。 クライアントは CAPTCHA 文字を入力します。 Nginx はこの入力文字を確認のために reCAPTCHA サーバーに送信します。

reCAPTCHA サーバーからの正しい答えは "true..." で始まり、そうでなければ "false..." で始まります。 正しい検証済みクライアントのセキュア Cookie を追加し、クライアントを表示したいページにリダイレクトします。

Nginx と OpenResty を使えば、Luaで Captcha 画像の生成を用いた検証を使って、ウェブサーバーで直接 Captcha を実装することが可能です。 この実装を構成するのは容易ではありません。

代わりに、単に test-cookie チャレンジを実装することもできます。 ウェブサーバーで、クライアントが有効な Cookie を設定できることをご確認ください。悪意のあるクライアントはこの機能を持っていないことがよくあります。 Nginx では、Cloudflare は Cookie を操作するためのライブラリーを提供しています。

その他の方法としては、.onion に接続しているクライアントに有効な User-Agent ヘッダーがあり、Referer ヘッダーが攻撃に関連付けられる値に設定されていないか確認することなどがあります。