コンテンツにスキップ

Threat Replay Testingのセットアップ

この記事では、WallarmのThreat Replay Testingの有効化と設定方法を説明します。

有効化

Threat Replay Testingはデフォルトで無効です。有効化して実行するには、次の手順に従います。

  1. Advanced API Securityのサブスクリプションプランを契約していることを確認します。

  2. Wallarm ConsoleのSecurity Testing → Threat Replayに、US CloudまたはEU Cloudのリンクから進み、Enable Threat Replay Testingスイッチをオンに切り替えます。

    Threat Replayが表示されない場合は、Wallarmのテクニカルサポートにお問い合わせください。

  3. Threat Replay TestingのIPアドレスを許可リストに追加します。

  4. Test policiesタブに移動し、少なくとも1つのポリシーを作成します。

ブロックされないようにする

Wallarmに加えて、自動的にトラフィックをフィルタリングおよびブロックする追加の仕組み（ソフトウェアまたはハードウェア）を使用している場合は、Threat Replay TestingのIPアドレスを含む許可リストを設定することを推奨します。

これにより、Threat Replay Testingを含むWallarmコンポーネントが、対象のリソースに対して脆弱性スキャンをシームレスに実行できるようになります。

テストポリシーの設定

フィルタリングノードがあるエンドポイントへの攻撃を検知すると、有効化済みのThreat Replay Testingが、当該エンドポイントがその攻撃タイプに対して脆弱かどうかを確認するテストを実行します。

これらのテストを実行するかどうか、また具体的な実行方法は、テストポリシーで定義します。各ポリシーでは次を定義します：

  • どのホストに対してテストを実行するか。

  • どの環境でテストを実行するか。

  • どの攻撃タイプに対してテストを実行するか（制限事項を参照）。

  • このエンドポイントと攻撃タイプについて再テストをどの頻度で実行するか。

  • 任意項目として、テスト環境で実行する前にテストリクエストをどのように変更するか。

Threat Replay Testing - テストポリシー

複数のテストポリシーの動作

次のとおりです。

  • ポリシーがない → テストは実行されません。

  • このホスト/攻撃タイプ向けのポリシーがない → テストは実行されません。

  • 対象ホストに影響するポリシーが複数ある → 複数の独立したテストが実行されます。

時間に関して：このエンドポイントと攻撃タイプに対するテストがすでに実行済みで、その後このエンドポイントに同タイプの新たな攻撃が発生しても、Periodの期限が切れるまでテストは再実行されません。

ホストとリプレイ先ホスト

テストを実行するホストと、それらのテストをどの環境で実行するかは、Host affected by attackおよびReplay attack on hostフィールドで定義します。

両フィールドでは、キャプチャグループや後方参照を含む正規表現を使用できます。以下に代表的なシナリオを示します。

シナリオ#1：特定のホスト上の任意のサブドメインの攻撃を再チェック

Host affected by the attack: .+\.wallarm\.com
Replay attack on host: test.wallarm.com

結果：

  • www.wallarm.com への任意の攻撃はtest.wallarm.com上でテストされます。

  • dev.wallarm.comへの任意の攻撃はtest.wallarm.com上でテストされます。

シナリオ#2：ホスト名の中間部分を置換

Host affected by the attack: (.+)\.wallarm\.com
Replay attack on host: \1.test-wallarm.com

結果：

  • www.wallarm.comへの攻撃はwww.test-wallarm.com上でテストされます。

  • dev.wallarm.comへの攻撃はdev.test-wallarm.com上でテストされます。

シナリオ#3：同一ホスト上の任意のリクエストを再チェック

Host affected by the attack: (.+)
Replay attack on host: \1

結果：

  • www.wallarm.comへの攻撃はwww.wallarm.com上でテストされます。

  • dev.wallarm.comへの攻撃はdev.wallarm.com上でテストされます。

シナリオ#4：特定のホストの攻撃を特定のホストで再チェック

Host affected by the attack: www\.wallarm\.com
Replay attack on host: test.wallarm.com

結果：

  • 攻撃先がwww.wallarm.comの場合はtest.wallarm.com上でテストされます。

  • dev.wallarm.comへの攻撃はテストされません。

Rewrites

デフォルトでは、Threat Replay Testingは特定の認証パラメータの除去を除き、オリジナルのリクエストデータを保持します。テストポリシーのRewritesセクションを使用すると、オリジナルのリクエスト要素を基にテスト攻撃セットを生成する前に、それらの要素を変更できます。これは、オリジナルの認証データをテスト用データに置き換える場合や、別のアドレスで攻撃のリプレイを実施する場合に特に有用です。

オリジナルのリクエスト要素の変更

変更できるのは、オリジナルのリクエストのヘッダー（header）とパス（uri）のみです。その他のリクエスト要素は変更も追加もできません。

Rewriteの例

以下は、example.comで再生される攻撃がCOOKIEヘッダーにPHPSESSID=mntdtbgt87j3auaq60iori2i63; security=lowという値を保持するようにするためのRewriteです。

COOKIEを変更するRewriteの例