【ITニュース解説】Traefik 3.6's multi-layer routing held up against 500 concurrent header-spoofing attempts

Traefikは、Webサービスへのリクエストを適切に振り分ける「リバースプロキシ」や「ロードバランサー」と呼ばれるソフトウェアの一種だ。Webサービスは通常、たくさんのユーザーからのリクエストを同時に受け付けるが、どのリクエストをどのサーバーに送るか、あるいは特定の条件を満たすリクエストにだけアクセスを許可するといった制御を行うのがTraefikの役割である。システムエンジニアにとって、Traefikのようなツールは、複数のサーバーで動くアプリケーションの公開や、アクセス制御、負荷分散を効率的に管理するために非常に重要だ。

今回注目するのは、Traefik 3.6で導入された「マルチレイヤールーティング」という新機能の検証結果だ。この機能は、Webサービスへのアクセス経路を複数段階に分けることで、より柔軟で安全なアクセス制御を実現するものだ。具体的には、「親ルーター」が最初のリクエストを受け取り、そこで何らかの処理（例えば、認証チェック）を行い、その結果に基づいて「子ルーター」がさらに詳細なルーティングを行う。子ルーターは親ルーターの処理が完了した後にのみ動作するため、親ルーターが設定した条件を満たさないと、子ルーターに到達することはできない仕組みになっている。

この検証の目的は、この「子ルーターは直接呼び出せない」というTraefikの設計が、実際に外部からの攻撃に対してどれだけ堅牢であるかを確認することだった。特に、親ルーターが設定する特定のヘッダー情報（Webリクエストに付加される追加情報）を、悪意のあるユーザーが自分で作成して送りつけた場合、子ルーターに直接アクセスできてしまうのではないか、というセキュリティ上の疑問を解消しようとした。

検証環境では、Traefik 3.6.25をDockerコンテナで動作させ、バックエンドのWebサービスとして、リクエスト情報を表示する「Whoami」という簡単なコンテナを3つ用意した。これらのサービスはそれぞれ「admin-svc」（管理者向けサービス）と「default-svc」（一般的なサービス）として動作する。 Traefikの設定は以下のようになった。まず「parent-api」という親ルーターを設定し、/apiというURLパスから始まるリクエストを受け取るようにした。この親ルーターには「role-admin」というミドルウェア（追加処理を行う部品）を適用した。このミドルウェアの役割は、リクエストに「X-Role: admin」というカスタムヘッダーを強制的に追加することだ。つまり、どんなユーザーがどんなヘッダーを送っても、/apiパスを通るリクエストには必ず「X-Role: admin」が設定される。

次に「child-admin」という子ルーターを設定した。この子ルーターは「X-Role」ヘッダーが「admin」という値であるリクエストにのみマッチするように設定されている。そして、最も重要な点として、この子ルーターは「parent-api」を親ルーターとして参照する「parentRefs」という設定を持っていた。これにより、「child-admin」は「parent-api」を経由したリクエストにしか反応しない。最後に、「catchall」というルーターを設定し、どのルーターにもマッチしない全てのリクエストを受け止める役割を持たせた。これは優先度が最も低く設定されており、デフォルトのサービスにリクエストを転送する。

この設定が期待通りに動けば、/apiパスへのリクエストは必ず「parent-api」ルーターを通って「role-admin」ミドルウェアによって「X-Role: admin」ヘッダーが挿入され、その後に「child-admin」ルーターに到達して「admin-svc」に転送されるはずだ。もしユーザーが自分で「X-Role: user」のようなヘッダーを付けて/apiにリクエストを送っても、「role-admin」ミドルウェアがそれを「X-Role: admin」に上書きするため、不正なヘッダーは無視される。

そしていよいよ、セキュリティ検証の本番だ。子ルーターが反応するはずの「X-Role: admin」ヘッダーを自分でリクエストに含めて送信し、しかしそのリクエストを親ルーターが担当する/apiパスではなく、/や/not-api/といった/api以外のパスに送ってみた。もし子ルーターが親ルーターと無関係にヘッダーを読み取ってしまうなら、直接「admin-svc」に到達してしまう可能性がある。 しかし、結果は期待通りだった。リクエストは「default-svc」（catchallルーターのサービス）に転送され、「admin-svc」には一切到達しなかったのだ。さらに、500件ものリクエストを同時に、同じようにヘッダーを偽装して送ってみたが、やはり全てのリクエストが「default-svc」に転送され、「admin-svc」へのアクセスはゼロだった。この結果は、「子ルーターは直接呼び出せない」というTraefikの主張が、実際の攻撃シミュレーションにおいても有効であることを力強く示している。このセキュリティ境界が堅牢であることが確認できたのは、非常に心強い発見だ。

今回の設定作業では、いくつかの間違いを犯したが、それらから重要な知見が得られた。 一つ目は、子ルーターに「entryPoints」（リクエストを受け付けるネットワークポート）を設定しようとしたことだ。通常のルーターには必須の設定だが、子ルーターにこれを設定すると「非ルートルーターはEntrypoints設定を持つことはできない」というエラーが発生し、そのルーターは無効化されてしまった。子ルーターは親ルーターから「entryPoints」を継承するため、自分で設定する必要はない。 二つ目は、ヘッダーをマッチさせるルールとして「HeadersRegexp」（複数形）と誤って記述したことだ。正しくは「HeaderRegexp」（単数形）であり、これにより「サポートされていない関数」というエラーが出た。些細なミスだが、解決に時間がかかった。 三つ目は、存在しない親ルーターの名前を「parentRefs」に指定した場合だ。この場合、「親ルーターが存在しない」というエラーが出るだけでなく、その親ルーター自体もエラー状態になってしまった。親ルーターは、それが担当するサービスがあるか、または参照されている子ルーターが正しく解決されるかのどちらかが必要であり、どちらもないと全体が機能しなくなるという仕様が明らかになった。

さらに、マルチレイヤールーティングの多層ネストについても試してみた。ドキュメントには2層までの例しか示されていなかったが、祖父母、親、子の3段階のルーティングチェーンを構築したところ、期待通りに動作した。 しかし、既存のTraefikのバージョンとの互換性には大きな落とし穴があることが判明した。今回作成した設定ファイルにはTraefik 3.6で導入された「parentRefs」フィールドが含まれている。このファイルを、一つ前のバージョンであるTraefik 3.5.6で読み込ませたところ、「フィールドが見つからない」というエラーが発生し、parentRefsを含むルーターだけでなく、設定ファイル全体が無効になってしまったのだ。その結果、すべてのルーティングが停止し、Webサービスにアクセスできなくなった。これは、もしTraefikインスタンスを段階的にアップグレードするような運用をしている場合、古いバージョンのTraefikが新しいバージョンの設定ファイルを読み込むと、システム全体が停止する可能性があるという重大な警告となる。

この多層ルーティング機能のパフォーマンスについても検証した。3層ネストのルーティングチェーンと、同等の機能を単一のルーターで実装した場合のスループットを比較した結果、両者の間に実質的な性能差は見られなかった。Traefikはルーターチェーンを、リクエストごとに内部的な関数呼び出しとして処理するため、ルーティングの段階が増えても、それがネットワーク越しの追加の処理になるわけではない。そのため、この程度のネスト数であれば、パフォーマンスに大きな影響はないと判断できる。

最後に、今回の検証を行う中で気づいた、テスト設計上の重要な教訓がある。最初のバイパス試行では、不正なリクエストが意図せず親ルーターのパス（/api）にマッチしてしまっていた。これは、「catchall」ルーターの優先度設定を忘れており、Traefikがより具体的なルールを優先するというデフォルトの挙動によって、意図しないルーターにリクエストが送られてしまっていたためだ。このような誤解を避けるためには、単にバックエンドサービスからの応答内容だけでなく、どのルーターが実際にリクエストを処理したかというデバッグ情報を常に確認することが非常に重要だと分かった。

以上の検証結果から、Traefik 3.6のマルチレイヤールーティング機能のセキュリティは、ヘッダー偽装攻撃に対して堅牢であることが確認された。しかし、この機能を導入する際には、旧バージョンとの互換性問題に十分に注意し、また、実際に使用する認証ミドルウェアと組み合わせた形での独自の検証を行うことが強く推奨される。新しい技術の導入には、そのメリットだけでなく、潜在的なリスクや運用上の注意点をしっかりと把握することが、システムエンジニアとして非常に重要だ。