AMI
[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair
[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group
[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance
[anchor1]: #2-create-a-security-group
[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws
[img-create-sg]: ../../../../images/installation-ami/common/create_sg.png
[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list
[img-wl-console-users]: ../../../../images/check-user-no-2fa.png
[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png
[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md
[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node
[api-token]: ../../../../user-guides/settings/api-tokens.md
[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation
[platform]: ../../../../installation/supported-deployment-options.md
[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal
[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png
[wallarm-nginx-directives]: ../../../../admin-en/configure-parameters-en.md
[autoscaling-docs]: ../../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md
[real-ip-docs]: ../../../../admin-en/using-proxy-or-balancer-en.md
[allocate-memory-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md
[limiting-request-processing]: ../../../../user-guides/rules/configure-overlimit-res-detection.md
[logs-docs]: ../../../../admin-en/configure-logging.md
[wallarm-mode]: ../../../../admin-en/configure-wallarm-mode.md
[wallarm-api-via-proxy]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md
[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png
[cloud-init-spec]: ../../../cloud-platforms/cloud-init.md
[wallarm_force_directive]: ../../../../admin-en/configure-parameters-en.md#wallarm_force
[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md
[api-spec-enforcement-docs]: ../../../../api-specification-enforcement/overview.md
[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md
# Amazon Machine ImageからWallarmをデプロイする
本記事では、[公式Amazon Machine Image (AMI)](https://aws.amazon.com/marketplace/pp/B073VRFXSD)を使用してAWS上にWallarmをデプロイする手順について説明します。
## ユースケース
Among all supported [Wallarm deployment options][deployment-platform-docs], AMI is recommended for Wallarm deployment in these **use cases**:
* Your existing infrastructure resides on AWS.
* You aim to deploy a security solution as a separate cloud instance, rather than installing it directly on frontend systems like NGINX.
## Requirements
* An AWS account
* Understanding of AWS EC2, Security Groups
* Any AWS region of your choice, there are no specific restrictions on the region for the Wallarm node deployment
Wallarm supports both single availability zone (AZ) and multi availability zone deployments. In multi-AZ setups, Wallarm Nodes can be launched in separate availability zones and placed behind a Load Balancer for high availability.
* Access to the account with the **Administrator** role in Wallarm Console for the [US Cloud](https://us1.my.wallarm.com/) or [EU Cloud](https://my.wallarm.com/)
* Access to `https://us1.api.wallarm.com:444` for working with US Wallarm Cloud or to `https://api.wallarm.com:444` for working with EU Wallarm Cloud. If access can be configured only via the proxy server, then use the [instructions][wallarm-api-via-proxy]
* Access to the IP addresses below for downloading updates to attack detection rules and [API specifications][api-spec-enforcement-docs], as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted][ip-lists-docs] countries, regions, or data centers
=== "US Cloud"
```
34.96.64.17
34.110.183.149
35.235.66.155
34.102.90.100
34.94.156.115
35.235.115.105
```
=== "EU Cloud"
```
34.160.38.183
34.144.227.90
34.90.110.226
```
* Executing all commands on a Wallarm instance as a superuser (e.g. `root`)
## 1. Create a pair of SSH keys in AWS
During the deploying process, you will need to connect to the virtual machine via SSH. Amazon EC2 allows creating a named pair of public and private SSH keys that can be used to connect to the instance.
To create a key pair:
1. Navigate to the **Key pairs** tab on the Amazon EC2 dashboard.
2. Click the **Create Key Pair** button.
3. Enter a key pair name and click the **Create** button.
A private SSH key in PEM format will automatically start to download. Save the key to connect to the created instance in the future.
To see detailed information about creating SSH keys, proceed to the [AWS documentation][link-ssh-keys].
## 2. Create a Security Group
A Security Group defines allowed and forbidden incoming and outgoing connections for virtual machines. The final list of connections depends on the protected application (e.g., allowing all of the incoming connections to the TCP/80 and TCP/443 ports).
The Wallarm AMI is designed to operate with a minimal set of permissions. When deploying the instance, we recommend assigning an IAM role and configuring security groups based on the principle of least privilege, granting only the access required for the node's operation to align with AWS security best practices.
To create a security group for the filtering node:
1. Navigate to the **Security Groups** tab on the Amazon EC2 dashboard and click the **Create Security Group** button.
2. Enter a security group name and an optional description into the dialog window that appears.
3. Select the required VPC.
4. Configure incoming and outgoing connections rules on the **Inbound** and **Outbound** tabs.
5. Click the **Create** button to create the security group.
![Creating a security group][img-create-sg]
!!! warning "Rules for outgoing connections from the security group"
When creating a security group, all of the outgoing connections are allowed by default. If you restrict outgoing connections from the filtering node, make sure that it is granted access to a Wallarm API server. The choice of a Wallarm API server depends on the Wallarm Cloud you are using:
* If you are using the US Cloud, your node needs to be granted access to `us1.api.wallarm.com`.
* If you are using the EU Cloud, your node needs to be granted access to `api.wallarm.com`.
The filtering node requires access to a Wallarm API server for proper operation.
To see detailed information about creating a security group, proceed to the [AWS documentation][link-sg].
## 3. Launch a Wallarm node instance
To launch an instance with the Wallarm filtering node, proceed to this [link](https://aws.amazon.com/marketplace/pp/B073VRFXSD) and subscribe to the filtering node.
When creating an instance, you need to specify the [previously created][anchor1] security group as follows:
1. While working with the Launch Instance Wizard, proceed to the **6. Configure Security Group** instance launch step by clicking the corresponding tab.
2. Choose the **Select an existing security group** option in the **Assign a security group** setting.
3. Select the security group from the list that appears.
After specifying all of the required instance settings, click the **Review and Launch** button, make sure that instance is configured correctly, and click the **Launch** button.
In the window that appears, specify the [previously created][anchor2] key pair by performing the following actions:
1. In the first drop-down list, select the **Choose an existing key pair** option.
2. In the second drop-down list, select the name of the key pair.
3. Make sure you have access to the private key in PEM format from the key pair you specified in the second drop-down list and tick the checkbox to confirm this.
4. Click the **Launch Instances** button.
The instance will launch with the preinstalled filtering node.
To see detailed information about launching instances in AWS, proceed to the [AWS documentation][link-launch-instance].
## 4. Connect to the filtering node instance via SSH
To see detailed information about ways to connect to an instance via SSH, proceed to the [AWS documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html).
You need to use the `admin` username to connect to the instance.
!!! info "Using the key to connect via SSH"
Use the private key in PEM format that you [created earlier][anchor2] to connect to the instance via SSH. This must be the private key from the SSH key pair that you specified when creating an instance.
## 5. Generate a token to connect an instance to the Wallarm Cloud
The local Wallarm filtering node needs to connect with the Wallarm Cloud using a Wallarm token of the [appropriate type][wallarm-token-types]. An API token allows you to create a node group in the Wallarm Console UI, which helps in organizing your node instances effectively.
![Grouped nodes][img-grouped-nodes]
Generate a token as follows:
=== "API token"
1. Open Wallarm Console → **Settings** → **API tokens** in the [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) or [EU Cloud](https://my.wallarm.com/settings/api-tokens).
1. Find or create API token with the `Node deployment/Deployment` usage type.
1. Copy this token.
=== "Node token"
1. Open Wallarm Console → **Nodes** in the [US Cloud](https://us1.my.wallarm.com/nodes) or [EU Cloud](https://my.wallarm.com/nodes).
1. 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**.
## 6. インスタンスをWallarm Cloudに接続する
クラウドインスタンスのノードは[cloud-init.py][cloud-init-spec]スクリプトを介してCloudに接続します。このスクリプトは、提供されたトークンを使用してノードをWallarm Cloudに登録し、グローバルに監視[mode][wallarm-mode]を設定し、`--proxy-pass`フラグに基づいてノードが正当なトラフィックを転送するように設定します。NGINXの再起動によってセットアップが完了します。
クラウドイメージから作成したインスタンス上で`cloud-init.py`スクリプトを次のように実行します。
=== "USクラウド"
``` bash
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t <TOKEN> -m monitoring --proxy-pass <PROXY_ADDRESS> -H us1.api.wallarm.com
```
=== "EUクラウド"
``` bash
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t <TOKEN> -m monitoring --proxy-pass <PROXY_ADDRESS>
```
* `WALLARM_LABELS='group=<GROUP>'`はノードグループ名を設定します（既存の場合はそのまま、存在しない場合は新規作成されます）。これはAPIトークンを使用している場合にのみ適用されます。
* `<TOKEN>`はトークンのコピーされた値です。
* `<PROXY_ADDRESS>`はWallarmノードが正当なトラフィックをプロキシする先のアドレスです。アーキテクチャに応じて、これはアプリケーションインスタンスのIP、ロードバランサ、またはDNS名などの場合があります。
## 7. Wallarmインスタンスへのトラフィック送信の設定
Update targets of your load balancer to send traffic to the Wallarm instance. For details, please refer to the documentation on your load balancer.
## 8. Wallarmの動作のテスト
1. The request with test [Path Traversal][ptrav-attack-docs] attack to an address of either the load balancer or the machine with the Wallarm node:
```
curl http://<ADDRESS>/etc/passwd
```
2. Open Wallarm Console → **Attacks** section in the [US Cloud](https://us1.my.wallarm.com/search) or [EU Cloud](https://my.wallarm.com/search) and make sure the attack is displayed in the list.
![Attacks in the interface][attacks-in-ui-image]
Since Wallarm operates in the monitoring mode, the Wallarm node does not block the attack but registers it.
1. Optionally, [test][link-wallarm-health-check] other aspects of the node functioning.
## 9. デプロイしたソリューションの微調整
The deployment is now complete. The filtering node may require some additional configuration after deployment.
Wallarm settings are defined using the [NGINX directives][wallarm-nginx-directives] or the Wallarm Console UI. Directives should be set in the following files on the Wallarm instance:
* `/etc/nginx/sites-enabled/default` defines the configuration of NGINX
* `/etc/nginx/conf.d/wallarm.conf` defines the global configuration of Wallarm filtering node
* `/etc/nginx/conf.d/wallarm-status.conf` defines the filtering node monitoring service configuration
* `/opt/wallarm/wstore/wstore.yaml` with the postanalytics service (wstore) settings
You can modify the listed files or create your own configuration files to define the operation of NGINX and Wallarm. It is recommended to create a separate configuration file with the `server` block for each group of the domains that should be processed in the same way (e.g. `example.com.conf`). To see detailed information about working with NGINX configuration files, proceed to the [official NGINX documentation](https://nginx.org/en/docs/beginners_guide.html).
!!! info "Creating a configuration file"
When creating a custom configuration file, make sure that NGINX listens to the incoming connections on the free port.
Below there are a few of the typical settings that you can apply if needed:
* [Wallarm node auto-scaling][autoscaling-docs]
* [Displaying the client's real IP][real-ip-docs]
* [Allocating resources for Wallarm nodes][allocate-memory-docs]
* [Limiting the single request processing time][limiting-request-processing]
* [Limiting the server reply waiting time](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout)
* [Limiting the maximum request size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)
* [Wallarm node logging][logs-docs]
To apply the settings, restart NGINX on the Wallarm instance:
``` bash
sudo systemctl restart nginx
Each configuration file change requires NGINX to be restarted to apply it.
```