Deploying Wallarm from GCP Machine Image¶
This article provides instructions for deploying Wallarm on GCP using the official Machine Image. The solution can be deployed either in-line or Out-of-Band.
Use cases¶
Among all supported Wallarm deployment options, GCP Machine Image is recommended for Wallarm deployment in these use cases:
-
Your existing infrastructure resides on GCP.
-
You aim to deploy a security solution as a separate cloud instance, rather than installing it directly on frontend systems like NGINX.
Requirements¶
-
A GCP account
-
Access to the account with the Administrator role and two‑factor authentication disabled in Wallarm Console for the US Cloud or EU Cloud
-
Access to
https://us1.api.wallarm.com:444
for working with US Wallarm Cloud or tohttps://api.wallarm.com:444
for working with EU Wallarm Cloud. If access can be configured only via the proxy server, then use the instructions -
Executing all commands on a Wallarm instance as a superuser (e.g.
root
)
1. Launch a filtering node instance¶
Launch the instance via the Google Cloud UI¶
To launch the filtering node instance via the Google Cloud UI, please open the Wallarm node image on the Google Cloud Marketplace and click LAUNCH.
The instance will launch with a preinstalled filtering node. To see detailed information on launching instances in the Google Cloud, please proceed to the official Google Cloud Platform documentation.
Launch the instance via Terraform or other tools¶
When using a tool like Terraform to launch the filtering node instance using Wallarm GCP image, you may need to provide the name of this image in the Terraform configuration.
-
Image name has the following format:
wallarm-node-195710/wallarm-node-<IMAGE_VERSION>-build
-
To launch the instance with the filtering node version 4.6, please use the following image name:
wallarm-node-195710/wallarm-node-4-6-20230630-122224
To get the image name, you can also follow these steps:
-
Install Google Cloud SDK.
-
Execute the command
gcloud compute images list
with the following parameters:gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-6-*'" --no-standard-images
-
Copy the version value from the name of the latest available image and paste the copied value into the provided image name format. For example, the filtering node version 4.6 image will have the following name:
wallarm-node-195710/wallarm-node-4-6-20230630-122224
2. Configure the filtering node instance¶
Perform the following actions to configure the launched filtering node instance:
-
Navigate to the VM instances page in the Compute Engine section of the menu.
-
Select the launched filtering node instance and click the Edit button.
-
Allow the required types of incoming traffic by ticking the corresponding checkboxes in the Firewalls setting.
-
If necessary, you can restrict connecting to the instance with the project SSH keys and use a custom SSH key pair for connecting to this instance. To do this, perform the following actions:
- Tick the Block project-wide checkbox in the SSH Keys setting.
- Click the Show and edit button in the SSH Keys setting to expand the field for entering an SSH key.
-
Generate a pair of public and private SSH keys. For example, you can use the
ssh-keygen
andPuTTYgen
utilities. -
Copy an open key in OpenSSH format from the interface of the used key generator (in the current example, the generated public key should be copied from the Public key for pasting into OpenSSH authorized_keys file area of the PuTTYgen interface) and paste it into the field containing the Enter entire key data hint.
- Save the private key. It will be required for connecting to the configured instance in the future.
-
Click the Save button at the bottom of the page to apply the changes.
3. Connect to the filtering node instance via SSH¶
To see detailed information about ways of connecting to instances, proceed to this link.
Connecting to the instance via a custom private key
If during base instance creation process you have enabled connection to the instance via a custom SSH key pair, make sure you have access to the private key from this key pair.
4. Connect the filtering node to the Wallarm Cloud¶
The Wallarm filtering node interacts with the Wallarm Cloud. You need to connect the node to the Cloud.
When connecting node to the Cloud, you can set the node name, under which it will be displayed in the Wallarm Console UI and put the node into the appropriate node group (used to logically organize nodes in UI).
To connect the node to the Cloud, use a Wallarm token of the appropriate type:
- Open Wallarm Console → Settings → API tokens in the US Cloud or EU Cloud.
- Find or create API token with the
Deploy
source role. - Copy this token.
-
Run the
register-node
script on a machine where you install the filtering node:sudo /usr/share/wallarm-common/register-node -t <TOKEN> --labels 'group=<GROUP>' -H us1.api.wallarm.com
sudo /usr/share/wallarm-common/register-node -t <TOKEN> --labels 'group=<GROUP>'
<TOKEN>
is the copied value of the API token with theDeploy
role.--labels 'group=<GROUP>'
parameter puts your node to the<GROUP>
node group (existing, or, if does not exist, it will be created).
- Open Wallarm Console → Nodes in the US Cloud or EU Cloud.
- 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.
-
Run the
register-node
script on a machine where you install the filtering node:sudo /usr/share/wallarm-common/register-node -t <TOKEN> -H us1.api.wallarm.com
sudo /usr/share/wallarm-common/register-node -t <TOKEN>
<TOKEN>
is the copied value of the node token.
- You may add
-n <HOST_NAME>
parameter to set a custom name for your node instance. Final instance name will be:HOST_NAME_NodeUUID
.
5. Enable Wallarm to analyze the traffic¶
By default, the deployed Wallarm node does not analyze incoming traffic.
Depending on the selected Wallarm deployment approach (in-line or Out-of-Band), configure Wallarm to either proxy traffic or process the traffic mirror.
Perform the following configuration in the /etc/nginx/sites-enabled/default
file on the Wallarm instance:
-
Set an IP address for Wallarm to proxy legitimate traffic to. It can be an IP of an application instance, load balancer, or DNS name, etc., depending on your architecture.
To do so, edit the
proxy_pass
value, e.g. Wallarm should send legitimate requests tohttp://10.80.0.5
:server { listen 80; listen [::]:80 ipv6only=on; ... location / { proxy_pass http://10.80.0.5; ... } }
-
For the Wallarm node to analyze the incoming traffic, set the
wallarm_mode
directive tomonitoring
:server { listen 80; listen [::]:80 ipv6only=on; wallarm_mode monitoring; ... }
The monitoring mode is the recommended one for the first deployment and solution testing. Wallarm provides safe blocking and blocking modes as well, read more.
-
For the Wallarm node to accept mirrored traffic, set the following configuration in the
server
NGINX block:wallarm_force server_addr $http_x_server_addr; wallarm_force server_port $http_x_server_port; # Change 222.222.222.22 to the address of the mirroring server set_real_ip_from 222.222.222.22; real_ip_header X-Forwarded-For; real_ip_recursive on; wallarm_force response_status 0; wallarm_force response_time 0; wallarm_force response_size 0;
- The
set_real_ip_from
andreal_ip_header
directives are required to have Wallarm Console display the IP addresses of the attackers. - The
wallarm_force_response_*
directives are required to disable analysis of all requests except for copies received from the mirrored traffic.
- The
-
For the Wallarm node to analyze the mirrored traffic, set the
wallarm_mode
directive tomonitoring
:server { listen 80; listen [::]:80 ipv6only=on; wallarm_mode monitoring; ... }
Since malicious requests cannot be blocked, the only mode Wallarm accepts is monitoring. For in-line deployment, there are also safe blocking and blocking modes but even if you set the
wallarm_mode
directive to a value different from monitoring, the node continues to monitor traffic and only record malicious traffic (aside from the mode set to off).
6. Restart NGINX¶
To apply the settings, restart NGINX on the Wallarm instance:
sudo systemctl restart nginx
Each configuration file change requires NGINX to be restarted to apply it.
7. Configure sending traffic to the Wallarm instance¶
Depending on the deployment approach being used, perform the following settings:
Update targets of your load balancer to send traffic to the Wallarm instance. For details, please refer to the documentation on your load balancer.
Configure your web or proxy server (e.g. NGINX, Envoy) to mirror incoming traffic to the Wallarm node. For configuration details, we recommend to refer to your web or proxy server documentation.
Inside the link, you will find the example configuration for the most popular of web and proxy servers (NGINX, Traefik, Envoy).
8. Test the Wallarm operation¶
-
The request with test Path Traversal attack to an address of either the load balancer or the machine with the Wallarm node:
curl http://<ADDRESS>/etc/passwd
-
Open Wallarm Console → Events section in the US Cloud or EU Cloud and make sure the attack is displayed in the list.
Since Wallarm operates in the monitoring mode, the Wallarm node does not block the attack but registers it.
9. Fine-tune the deployed solution¶
The deployment is now complete. The filtering node may require some additional configuration after deployment.
Wallarm settings are defined using the 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 -
/etc/default/wallarm-tarantool
or/etc/sysconfig/wallarm-tarantool
with the Tarantool database 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.
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: