コンテンツにスキップ

脅威リプレイテストのセットアップ

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

有効化

Threat Replay Testingはデフォルトで無効化されています。有効化して動作させるには:

  1. US CloudまたはEU Cloudのリンクに従いWallarm Console → Threat Replay Testingに移動し、Enable Threat Replay Testingスイッチをオンにしてください。

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

  2. Threat Replay TestingのIPアドレスをホワイトリストに追加してください。

  3. Test policiesタブに移動し、少なくとも1つのポリシーを作成してください。

IPアドレス

Threat Replay TestingのIPアドレスは、トラフィックの自動フィルタリングやブロックに使用するWallarm以外のソフトウェアまたはハードウェア設備のwhitelistsに追加することを推奨します。これにより、Threat Replay Testingがこれらの設備によってブロックされることを防ぎます。

US CloudおよびEU Cloud用の該当アドレスの一覧はこちらに記載されています。

テストポリシーの設定

フィルタリングノードによってエンドポイントへの攻撃が検出されると、有効化されたThreat Replay Testingがそのエンドポイントがこの攻撃タイプに脆弱かどうかを確認するためのテストを実行します。

これらのテストが実行されるかどうかおよびその実行方法は、それぞれ以下を定義するテストポリシーにより決定されます:

  • テストを実行するホスト

  • テストを実行する環境

  • テストを実行する攻撃タイプ(limitationsを参照)

  • このエンドポイントおよび攻撃タイプについて再テストを実行する頻度

  • オプションで、テスト環境上で実行する前にテストリクエストをどのように変更するか

Threat Replay Testing - テストポリシー

複数のテストポリシーの相互作用

以下の場合を考えてください:

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

  • このホスト/攻撃タイプに対するポリシーがない場合 → テストは実行されません。

  • ホストに影響を与える複数のポリシーがある場合 → 複数の個別テストが実行されます。

時間に関しては、すでにこのエンドポイントと攻撃タイプに対してテストが実施されており、同じ攻撃タイプの新たな攻撃がこのエンドポイントに発生した場合、Periodの期限が切れる前に再テストは実行されません。

ホストとリプレイホスト

テストを実行するホストおよびテストを実行する環境は、Host affected by attackReplay attack on hostフィールドで定義します。

両フィールドでは、キャプチャグループとバックスリファレンスを含む正規表現を使用できます。以下に最も一般的なシナリオの例を示します。

シナリオ#1: 特定のホスト上の任意のサブドメインでの攻撃再検証

攻撃対象ホスト: .+\.wallarm\.com
リプレイ攻撃ホスト: test.wallarm.com

結果:

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

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

シナリオ#2: ホスト名の中央での置換

攻撃対象ホスト: (.+)\.wallarm\.com
リプレイ攻撃ホスト: \1.test-wallarm.com

結果:

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

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

シナリオ#3: 同一ホスト上の任意のリクエスト再検証

攻撃対象ホスト: (.+)
リプレイ攻撃ホスト: \1

結果:

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

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

シナリオ#4: 特定のホストでの攻撃再検証

攻撃対象ホスト: www\.wallarm\.com
リプレイ攻撃ホスト: test.wallarm.com

結果:

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

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

リライト

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

元のリクエスト要素の変更について

元のリクエストのヘッダー(header)およびパス(uri)のみを変更できます。その他のリクエスト要素は変更も追加もできません。

リライト例

以下は、example.comでリプレイされる攻撃がCOOKIEヘッダーにPHPSESSID=mntdtbgt87j3auaq60iori2i63; security=lowの値を保持するようにするリライトです。

COOKIEを変更するリライトの例