コンテンツにスキップ

AWSへのWallarm Dockerイメージのデプロイ

このクイックガイドでは、NGINXベースのWallarmノードのDockerイメージを、Amazon Elastic Container Service(Amazon ECS)を使用してAmazonクラウドプラットフォームにデプロイする手順を説明します。

この手順の制限事項

この手順には、ロードバランシングおよびノードの自動スケーリングの構成は含まれていません。これらのコンポーネントを自身で設定する場合は、AWSの手順の該当箇所を確認することをおすすめします。

セキュリティに関する注意

このソリューションは、AWSのセキュリティベストプラクティスに従うように設計されています。デプロイにはAWSのルートアカウントの使用を避けることをおすすめします。代わりに、必要最小限の権限のみを持つIAMユーザーまたはロールを使用します。

デプロイプロセスは最小権限の原則を前提としており、Wallarmコンポーネントのプロビジョニングと運用に必要な最小限のアクセスのみを付与します。

本デプロイに必要なAWSインフラストラクチャのコスト見積もりについては、AWSにWallarmをデプロイする際のコストガイダンスを参照してください。

ユースケース

Among all supported Wallarm deployment options, Wallarm deployment on AWS ECS using the Docker image is recommended in these use cases:

  • If your applications leverage a microservices architecture, and are already containerized and operational on AWS ECS.

  • If you require fine-grained control over each container, the Docker image excels. It affords a greater level of resource isolation than typically possible with traditional VM-based deployments.

要件

  • admin権限を持つAWSアカウントとユーザー

  • AWS CLI 1またはAWS CLI 2が正しくインストールされ、設定されていること

  • US CloudまたはEU CloudのWallarm ConsoleでAdministratorロールを持つアカウントへのアクセス

  • 攻撃検出ルールおよびAPI仕様の更新のダウンロード、ならびに許可リスト、拒否リスト、グレーリストに登録した国・地域・データセンターの正確なIPの取得のために、以下のIPアドレスへのアクセス

    node-data0.us1.wallarm.com - 34.96.64.17
node-data1.us1.wallarm.com - 34.110.183.149
us1.api.wallarm.com - 35.235.66.155
34.102.90.100
34.94.156.115
35.235.115.105

    node-data1.eu1.wallarm.com - 34.160.38.183
node-data0.eu1.wallarm.com - 34.144.227.90
api.wallarm.com - 34.90.110.226

WallarmノードのDockerコンテナ設定オプション

The filtering node configuration parameters should be passed to the deployed Docker container in one of the following ways:

  • In the environment variables. This option allows for the configuration of only basic filtering node parameters. Most directives cannot be configured through environment variables.

  • In the mounted configuration file. This option allows full filtering node configuration via any directives. With this configuration method, environment variables with the filtering node and Wallarm Cloud connection settings are also passed to the container.

環境変数で構成されたWallarmノードのDockerコンテナのデプロイ

環境変数のみで構成されたコンテナ化Wallarmフィルタリングノードをデプロイするには、AWS Management ConsoleとAWS CLIを使用します。

  1. Get Wallarm token of the appropriate type:

    1. Open Wallarm Console → Settings → API tokens in the US Cloud or EU Cloud.
    2. Find or create API token with the Node deployment/Deployment usage type.
    3. Copy this token.
    1. Open Wallarm Console → Nodes in the US Cloud or EU Cloud.
    2. Do one of the following:
      • Create the node of the Wallarm node type and copy the generated token.
      • Use existing node group - copy token using node's menu → Copy token.

  2. AWS Management Consoleにサインインし、Services一覧からElastic Container Serviceを開きます。

  3. Create Clusterボタンからクラスター作成に進みます:

    1. テンプレートとしてEC2 Linux + Networkingを選択します。
    2. クラスター名を指定します。例: wallarm-cluster。
    3. 必要に応じて、AWSの手順に従ってその他の設定を行います。
    4. クラスターを保存します。

  4. Wallarm Cloudへの接続に必要な機密データ(ノードトークン)をAWS Secrets ManagerまたはAWS Systems Manager → Parameter Storeを使用して暗号化します。

    本手順では、機密データはAWS Secrets Managerに保存します。

    機密データストレージへのアクセス

    Dockerコンテナが暗号化された機密データを読み取れるように、AWSの設定が次の要件を満たしていることを確認してください:

    • 機密データが、Dockerコンテナを実行するリージョンに保存されていること。
    • タスク定義のexecutionRoleArnパラメータで指定したユーザーにIAMポリシーSecretsManagerReadWriteがアタッチされていること。IAMポリシー設定の詳細 →

  5. 次のタスク定義(task definition、タスク定義はDockerコンテナの動作シナリオを定義します)を記述したローカルJSONファイルを作成します:

    {
    "executionRoleArn": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/ecsTaskExecutionRole",
    "containerDefinitions": [
        {
            "memory": 128,
            "portMappings": [
           {
               "hostPort": 80,
               "containerPort": 80,
               "protocol": "tcp"
           }
       ],
       "essential": true,
       "environment": [
           {
               "name": "WALLARM_API_HOST",
               "value": "us1.api.wallarm.com"
           },
           {
               "name": "NGINX_BACKEND",
               "value": "<HOST_TO_PROTECT_WITH_WALLARM>"
           },
           {
               "name": "WALLARM_LABELS",
               "value": "group=<GROUP>"
           }
       ],
       "secrets": [
           {
               "name": "WALLARM_API_TOKEN",
               "valueFrom": "arn:aws:secretsmanager:<SECRETS_MANAGER_AWS_REGION>:<AWS_ACCOUNT_ID>:secret:<SECRET_NAME>:<WALLARM_API_TOKEN_PARAMETER_NAME>::"
           }
       ],
       "name": "wallarm-container",
       "image": "registry-1.docker.io/wallarm/node:6.4.1"
       }
   ],
   "family": "wallarm-api-security-node"
   }

    {
    "executionRoleArn": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/ecsTaskExecutionRole",
    "containerDefinitions": [
        {
            "memory": 128,
            "portMappings": [
           {
               "hostPort": 80,
               "containerPort": 80,
               "protocol": "tcp"
           }
       ],
       "essential": true,
       "environment": [
           {
               "name": "NGINX_BACKEND",
               "value": "<HOST_TO_PROTECT_WITH_WALLARM>"
           },
           {
               "name": "WALLARM_LABELS",
               "value": "group=<GROUP>"
           }
       ],
       "secrets": [
           {
               "name": "WALLARM_API_TOKEN",
               "valueFrom": "arn:aws:secretsmanager:<SECRETS_MANAGER_AWS_REGION>:<AWS_ACCOUNT_ID>:secret:<SECRET_NAME>:<WALLARM_API_TOKEN_PARAMETER_NAME>::"
           }
       ],
       "name": "wallarm-container",
       "image": "registry-1.docker.io/wallarm/node:6.4.1"
       }
   ],
   "family": "wallarm-api-security-node"
   }
    • <AWS_ACCOUNT_ID>: あなたのAWSアカウントID。
    • environmentオブジェクトは、Dockerコンテナにテキスト形式で渡す環境変数を設定します。使用可能な環境変数の一覧は以下の表に記載しています。WALLARM_API_TOKEN変数はsecretsオブジェクトで渡すことを推奨します。

    • secretオブジェクトは、機密データストレージへのリンクとしてDockerコンテナに渡す環境変数を設定します。値の形式は選択したストレージによって異なります(詳細はAWS Secrets ManagerまたはAWS Systems Manager → Parameter Storeのドキュメントを参照してください)。

      WALLARM_API_TOKEN変数はsecretsオブジェクトで渡すことを推奨します。

      Environment variable Description Required
      WALLARM_API_TOKEN Wallarm node or API token. Yes
      WALLARM_LABELS

      Available starting from node 4.6. Works only if WALLARM_API_TOKEN is set to API token with the Deploy role. Sets the group label for node instance grouping, for example:

      WALLARM_LABELS="group=<GROUP>"

      ...will place node instance into the <GROUP> instance group (existing, or, if does not exist, it will be created).

      		 Yes (for API tokens)
      NGINX_BACKEND Domain or IP address of the resource to protect with the Wallarm solution. Yes
      WALLARM_API_HOST Wallarm API server:
      • us1.api.wallarm.com for the US Cloud
      • api.wallarm.com for the EU Cloud
      By default: api.wallarm.com.      		 No
      WALLARM_MODE Node mode:
      • block to block malicious requests
      • safe_blocking to block only those malicious requests originated from graylisted IP addresses
      • monitoring to analyze but not block requests
      • off to disable traffic analyzing and processing
      By default: monitoring.
      Detailed description of filtration modes →      		 No
      WALLARM_APPLICATION Unique identifier of the protected application to be used in the Wallarm Cloud. The value can be a positive integer except for 0.

      Default value (if the variable is not passed to the container) is -1 which indicates the default application displayed in Wallarm Console → Settings → Application.

      More details on setting up applications →      		 No
      SLAB_ALLOC_ARENA (TARANTOOL_MEMORY_GB NGINX Node 5.x and earlier) Amount of memory allocated to wstore. The value can be a float (a dot . is a decimal separator). By default: 1.0 (1 gygabyte).
      Note that when passing this variable in Docker run command with the -e, the variable is not recorded in any configuration file within the container, but it is still used when wstore starts.      		 No
      NGINX_PORT Sets a port that NGINX will use inside the Docker container.

      Starting from the Docker image 4.0.2-1, the wallarm-status service automatically runs on the same port as NGINX.

      Default value (if the variable is not passed to the container) is 80.

      Syntax is NGINX_PORT='443'.      		 No
      WALLARM_STATUS_ALLOW Custom CIDRs that are allowed to access the /wallarm-status endpoint from outside the Docker container. Example value: 10.0.0.0/8. If you need to pass several values, use a comma , as a separator. To access the service externally, use the Docker container's IP, specifying the /wallarm-status endpoint path. No
      DISABLE_IPV6 The variable with any value except for an empty one deletes the listen [::]:80 default_server ipv6only=on; line from the NGINX configuration file which will stop NGINX from IPv6 connection processing.

      If the variable is not specified explicitly or has an empty value "", NGINX processes both IPv6 and IPv4 connections.      		 No
      WALLARM_APIFW_ENABLE This setting toggles API Specification Enforcement on or off, available from release 4.10 onwards. Please note that activating this feature does not substitute for the required subscription and configuration through the Wallarm Console UI.

      Its default value is true, enabling the functionality.      		 No
      WALLARM_APID_ONLY (5.3.7 and higher) In this mode, attacks detected in your traffic are blocked locally by the node (if enabled) but not exported to Wallarm Cloud. Meanwhile, API Discovery and some other features remain fully functional, detecting your API inventory and uploading it to the Cloud for visualization. This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides sensitive attack data masking if needed. More details
      By default: false.      		 No
      APIFW_METRICS_ENABLED (6.4.1 and higher) Enables Prometheus metrics for the API Specification Enforcement module.
      By default: false (disabled).      		 No
      APIFW_METRICS_HOST (6.4.1 and higher) Defines the host and port on which the API Specification Enforcement exposes metrics.
      By default: :9010.      		 No
      APIFW_METRICS_ENDPOINT_NAME (6.4.1 and higher) Defines the HTTP path of the API Specification Enforcement metrics endpoint
      By default: metrics.      		 No
      WALLARM_WSTORE__METRICS__LISTEN_ADDRESS Defines the host and port on which [Postanalytics and general system metrics][wstore-metrics] are exposed.
      By default: http://localhost:9001/metrics.      		 No
      WALLARM_WSTORE__SERVICE__PROTOCOL (6.6.0 and higher) Specifies the protocol family that wstore uses for incoming connections. Possible values:
      • "tcp" - dual-stack mode (listens on both IPv4 and IPv6)
      • "tcp4" - IPv4 only
      • "tcp6" - IPv6 only
      By default: "tcp4".      		 No

    • すべての設定ファイルパラメータはAWSドキュメントに記載されています。

  6. JSON構成ファイルに基づいて、aws ecs register‑task‑definitionコマンドでタスク定義を登録します:

    aws ecs register-task-definition --cli-input-json file://<PATH_TO_JSON_FILE>/<JSON_FILE_NAME>
    • <PATH_TO_JSON_FILE>: ローカルマシン上のタスク定義JSONファイルへのパス。
    • <JSON_FILE_NAME>: タスク定義JSONファイルの名前と拡張子。

  7. aws ecs run-taskコマンドでクラスター内にタスクを実行します:

    aws ecs run-task --cluster <CLUSTER_NAME> --launch-type EC2 --task-definition <FAMILY_PARAM_VALUE>
    • <CLUSTER_NAME>: 最初の手順で作成したクラスター名。例: wallarm-cluster。
    • <FAMILY_PARAM_VALUE>: 作成したタスク定義の名前。JSONファイル内のfamilyパラメータに指定した値と一致させます。例: wallarm-api-security-node。

  8. AWS Management Console→Elastic Container Service→該当の実行中タスクがあるクラスター→Tasksを開き、タスクが一覧に表示されていることを確認します。

  9. フィルタリングノードの動作をテストします。

マウントしたファイルで構成されたWallarmノードのDockerコンテナのデプロイ

環境変数とマウントしたファイルで構成されたコンテナ化Wallarmフィルタリングノードをデプロイするには、AWS Management ConsoleとAWS CLIを使用します。

本手順では、設定ファイルをAWS EFSファイルシステムからマウントします。その他のマウント方法についてはAWSドキュメントを参照してください。

AWS EFSからマウントした設定ファイルと環境変数を使用してコンテナをデプロイする手順:

  1. Get Wallarm token of the appropriate type:

    1. Open Wallarm Console → Settings → API tokens in the US Cloud or EU Cloud.
    2. Find or create API token with the Node deployment/Deployment usage type.
    3. Copy this token.
    1. Open Wallarm Console → Nodes in the US Cloud or EU Cloud.
    2. Do one of the following:
      • Create the node of the Wallarm node type and copy the generated token.
      • Use existing node group - copy token using node's menu → Copy token.

  2. AWS Management Consoleにサインインし、Services一覧からElastic Container Serviceを開きます。

  3. Create Clusterボタンからクラスター作成に進みます:

    • Template: EC2 Linux + Networking。
    • Cluster name: wallarm-cluster(例)。
    • Provisioning Model: On-Demand Instance。
    • EC2 instance type: t2.micro。
    • Number of instances: 1。
    • EC2 AMI ID: Amazon Linux 2 Amazon ECS-optimized AMI。
    • Key pair: インスタンスへのSSH接続用のkey pair。設定ファイルをストレージにアップロードするため、SSHでインスタンスに接続する必要があります。
    • その他の設定はデフォルトのままでもかまいません。他の設定を変更する場合は、AWS EFSのセットアップ手順に従うことをおすすめします。

  4. AWSの手順のステップ2〜4に従ってAWS EFSストレージを構成します。

  5. AWSの手順のステップ4で、設定ファイルdefaultを作成し、デフォルトでマウント対象のファイルを格納するディレクトリに配置します。defaultファイルにはフィルタリングノードの設定を記述します。最小設定の例:

    server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    #listen 443 ssl;

    server_name localhost;

    #ssl_certificate cert.pem;
    #ssl_certificate_key cert.key;

    root /usr/share/nginx/html;

    index index.html index.htm;

    wallarm_mode monitoring;
    # wallarm_application 1;

    location / {
            proxy_pass http://example.com;
            include proxy_params;
    }
}

    設定ファイルで指定できるフィルタリングノードのディレクティブ一覧 →

  6. Wallarm Cloudへの接続に必要な機密データ(ノードトークン)をAWS Secrets ManagerまたはAWS Systems Manager → Parameter Storeを使用して暗号化します。

    本手順では、機密データはAWS Secrets Managerに保存します。

    機密データストレージへのアクセス

    Dockerコンテナが暗号化された機密データを読み取れるように、AWSの設定が次の要件を満たしていることを確認してください:

    • 機密データが、Dockerコンテナを実行するリージョンに保存されていること。
    • タスク定義のexecutionRoleArnパラメータで指定したユーザーにIAMポリシーSecretsManagerReadWriteがアタッチされていること。IAMポリシー設定の詳細 →

  7. 次のタスク定義(task definition、タスク定義はDockerコンテナの動作シナリオを定義します)を記述したローカルJSONファイルを作成します:

    {
    "executionRoleArn": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/ecsTaskExecutionRole",
    "containerDefinitions": [
        {
            "memory": 128,
            "portMappings": [
           {
               "hostPort": 80,
               "containerPort": 80,
               "protocol": "tcp"
           }
       ],
       "essential": true,
       "mountPoints": [
           {
               "containerPath": "<PATH_FOR_MOUNTED_CONFIG>",
               "sourceVolume": "<NAME_FROM_VOLUMES_OBJECT>"
           }
       ],
       "environment": [
           {
               "name": "WALLARM_API_HOST",
               "value": "us1.api.wallarm.com"
           },
           {
               "name": "WALLARM_LABELS",
               "value": "group=<GROUP>"
           }
       ],
       "secrets": [
           {
               "name": "WALLARM_API_TOKEN",
               "valueFrom": "arn:aws:secretsmanager:<SECRETS_MANAGER_AWS_REGION>:<AWS_ACCOUNT_ID>:secret:<SECRET_NAME>:<WALLARM_API_TOKEN_PARAMETER_NAME>::"
           }
       ],
       "name": "wallarm-container",
       "image": "registry-1.docker.io/wallarm/node:6.4.1"
       }
   ],
   "volumes": [
       {
           "name": "<VOLUME_NAME>",
           "efsVolumeConfiguration": {
               "fileSystemId": "<EFS_FILE_SYSTEM_ID>",
               "transitEncryption": "ENABLED"
           }
       }
   ],
   "family": "wallarm-api-security-node"
   }

    {
    "executionRoleArn": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/ecsTaskExecutionRole",
    "containerDefinitions": [
        {
            "memory": 128,
            "portMappings": [
           {
               "hostPort": 80,
               "containerPort": 80,
               "protocol": "tcp"
           }
       ],
       "essential": true,
       "mountPoints": [
           {
               "containerPath": "/etc/nginx/http.d",
               "sourceVolume": "default"
           }
       ],
       "environment": [
           {
               "name": "WALLARM_LABELS",
               "value": "group=<GROUP>"
           }
       ],
       "secrets": [
           {
               "name": "WALLARM_API_TOKEN",
               "valueFrom": "arn:aws:secretsmanager:<SECRETS_MANAGER_AWS_REGION>:<AWS_ACCOUNT_ID>:secret:<SECRET_NAME>:<WALLARM_API_TOKEN_PARAMETER_NAME>::"
           }
       ],
       "name": "wallarm-container",
       "image": "registry-1.docker.io/wallarm/node:6.4.1"
       }
   ],
   "volumes": [
       {
           "name": "default",
           "efsVolumeConfiguration": {
               "fileSystemId": "<EFS_FILE_SYSTEM_ID>",
               "transitEncryption": "ENABLED"
           }
       }
   ],
   "family": "wallarm-api-security-node"
   }
    • <AWS_ACCOUNT_ID>: あなたのAWSアカウントID。

    • <PATH_FOR_MOUNTED_CONFIG>: 設定ファイルをマウントするコンテナ内ディレクトリ。設定ファイルは、以下のNGINXで使用されるコンテナディレクトリにマウントできます:

      • /etc/nginx/conf.d — 共通設定
      • /etc/nginx/http.d — バーチャルホスト設定
      • /var/www/html — 静的ファイル

      フィルタリングノードのディレクティブは/etc/nginx/http.d/default.confファイルに記述します。

    • <NAME_FROM_VOLUMES_OBJECT>: マウント対象のファイルを保存するAWS EFSストレージの構成を含むvolumesオブジェクトの名前(値は<VOLUME_NAME>と同一にします)。

    • <VOLUME_NAME>: マウント対象のファイルを保存するAWS EFSストレージの構成を含むvolumesオブジェクトの名前。
    • <EFS_FILE_SYSTEM_ID>: コンテナにマウントするファイルを含むAWS EFSファイルシステムのID。IDはAWS Management Console→Services→EFS→File systemsに表示されます。
    • environmentオブジェクトは、Dockerコンテナにテキスト形式で渡す環境変数を設定します。使用可能な環境変数の一覧は以下の表に記載しています。WALLARM_API_TOKEN変数はsecretsオブジェクトで渡すことを推奨します。

    • secretオブジェクトは、機密データストレージへのリンクとしてDockerコンテナに渡す環境変数を設定します。値の形式は選択したストレージによって異なります(詳細はAWS Secrets ManagerまたはAWS Systems Manager → Parameter Storeのドキュメントを参照してください)。

      WALLARM_API_TOKEN変数はsecretsオブジェクトで渡すことを推奨します。

      Environment variable Description Required
      WALLARM_API_TOKEN Wallarm node or API token. Yes
      WALLARM_API_HOST Wallarm API server:
      • us1.api.wallarm.com for the US Cloud
      • api.wallarm.com for the EU Cloud
      By default: api.wallarm.com.      		 No
      WALLARM_LABELS

      Available starting from node 4.6. Works only if WALLARM_API_TOKEN is set to API token with the Deploy role. Sets the group label for node instance grouping, for example:

      WALLARM_LABELS="group=<GROUP>"

      ...will place node instance into the <GROUP> instance group (existing, or, if does not exist, it will be created).

      		 Yes (for API tokens)
      SLAB_ALLOC_ARENA (TARANTOOL_MEMORY_GB NGINX Node 5.x and earlier) Amount of memory allocated to wstore. The value can be a float (a dot . is a decimal separator). By default: 1.0 (1 gygabyte). No
      WALLARM_APID_ONLY (5.3.7 and higher) In this mode, attacks detected in your traffic are blocked locally by the node (if enabled) but not exported to Wallarm Cloud. Meanwhile, API Discovery and some other features remain fully functional, detecting your API inventory and uploading it to the Cloud for visualization. This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides sensitive attack data masking if needed. More details
      By default: false.      		 No
      APIFW_METRICS_ENABLED (6.4.1 and higher) Enables Prometheus metrics for the API Specification Enforcement module.
      By default: false (disabled).      		 No
      APIFW_METRICS_HOST (6.4.1 and higher) Defines the host and port on which the API Specification Enforcement exposes metrics.
      By default: :9010.      		 No
      APIFW_METRICS_ENDPOINT_NAME (6.4.1 and higher) Defines the HTTP path of the API Specification Enforcement metrics endpoint
      By default: metrics.      		 No
      WALLARM_WSTORE__METRICS__LISTEN_ADDRESS Defines the host and port on which [Postanalytics and general system metrics][wstore-metrics-mount] are exposed.
      By default: http://localhost:9001/metrics.      		 No
      WALLARM_WSTORE__SERVICE__PROTOCOL (6.6.0 and higher) Specifies the protocol family that wstore uses for incoming connections. Possible values:
      • "tcp" - dual-stack mode (listens on both IPv4 and IPv6)
      • "tcp4" - IPv4 only
      • "tcp6" - IPv6 only
      By default: "tcp4".      		 No

    • すべての設定ファイルパラメータはAWSドキュメントに記載されています。

  8. JSON構成ファイルに基づいて、aws ecs register‑task‑definitionコマンドでタスク定義を登録します:

    aws ecs register-task-definition --cli-input-json file://<PATH_TO_JSON_FILE>/<JSON_FILE_NAME>
    • <PATH_TO_JSON_FILE>: ローカルマシン上のタスク定義JSONファイルへのパス。
    • <JSON_FILE_NAME>: タスク定義JSONファイルの名前と拡張子。

  9. aws ecs run-taskコマンドでクラスター内にタスクを実行します:

    aws ecs run-task --cluster <CLUSTER_NAME> --launch-type EC2 --task-definition <FAMILY_PARAM_VALUE>
    • <CLUSTER_NAME>: 最初の手順で作成したクラスター名。例: wallarm-cluster。
    • <FAMILY_PARAM_VALUE>: 作成したタスク定義の名前。JSONファイル内のfamilyパラメータに指定した値と一致させます。例: wallarm-api-security-node。

  10. AWS Management Console→Elastic Container Service→該当の実行中タスクがあるクラスター→Tasksを開き、タスクが一覧に表示されていることを確認します。

  11. フィルタリングノードの動作をテストします。

フィルタリングノードの動作テスト

  1. AWS Management Consoleで実行中のタスクを開き、External Link欄からコンテナのIPアドレスをコピーします。

    コンテナインスタンスの設定

    IPアドレスが空の場合は、コンテナがRUNNINGステータスであることを確認してください。

  2. テスト用のPath Traversal攻撃リクエストをコピーしたアドレスに送信します:

    curl http://<COPIED_IP>/etc/passwd

  3. Wallarm Console→AttacksをUS CloudまたはEU Cloudで開き、攻撃が一覧に表示されていることを確認します。
    UIのAttacks

  4. 必要に応じて、ノード動作の他の側面も[テスト][link-docs-check-operation]します。

コンテナのデプロイ中に発生したエラーの詳細は、AWS Management Consoleのタスク詳細に表示されます。コンテナにアクセスできない場合は、必要なフィルタリングノードのパラメータが正しい値でコンテナに渡されていることを確認してください。