Deploying on Google Cloud Platform (GCP)¶
To deploy a filter node on the Google Cloud Platform, perform the following steps:
-
Log in to your Google Cloud Platform account.
-
Launch a filter node instance.
-
Configure the filter node instance.
-
Connect to the filter node instance via SSH.
-
Connect the filter node to the Wallarm Cloud.
-
Set up the filter node for using a proxy server.
-
Set up filtering and proxying rules
-
Allocate more memory for the Wallarm Node.
-
Configure logging.
-
Restart NGINX.
1. Log In to Your Google Cloud Platform Account¶
Log in to console.cloud.google.com.
2. Launch a Filter Node Instance¶
If Wallarm WAF instance is already launched
If you launch Wallarm WAF instead of already existing Wallarm WAF or need to duplicate the instance in the same environment, please keep the same WAF version as currently used or update the version of all installations to the latest.
To check the launched version, run the following command:
apt list wallarm-node
- If the version
2.18.x
is installed, then follow the current instructions. - If the version
2.16.x
is installed, then follow the instructions for 2.16 or update all Wallarm WAF instances to 2.18. - If the version
2.14.x
or lower is installed, then please update all Wallarm WAF instances to 2.18.
More information about WAF node versioning is available in the WAF node versioning policy.
Launch the instance via the Google Cloud UI¶
To launch the WAF node instance via the Google Cloud UI, please open the WAF node image on the Google Cloud Marketplace and click LAUNCH.
The instance will launch with a preinstalled WAF 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 WAF 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 WAF node version 2.16, please use the following image name:
wallarm-node-195710/wallarm-node-2-16-0-7-19878-build
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-2-16-*'" --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 WAF node version 2.16 image will have the following name:
wallarm-node-195710/wallarm-node-2-16-0-7-19878-build
3. Configure the Filter Node Instance¶
Perform the following actions to configure the launched filter node instance:
-
Navigate to the VM instances page in the Compute Engine section of the menu.
-
Select the launched filter 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.
4. Connect to the Filter 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.
5. Connect the Filter Node to the Wallarm Cloud¶
The filter node interacts with the Wallarm cloud. There are two ways of connecting the node to the cloud:
Required access rights
Make sure that your Wallarm account has the Administrator or Deploy role enabled and two-factor authentication disabled, therefore allowing you to connect a filter node to the cloud.
You can check the aforementioned parameters by navigating to the user account list in the Wallarm console.
- If you are using https://my.wallarm.com/, proceed to the following link to check your user settings.
- If you are using https://us1.my.wallarm.com/, proceed to the following link to check your user settings.
Connecting Using the Filter Node Token¶
To connect the node to the cloud using the token, proceed with the following steps:
-
Create a new node on the Nodes tab of Wallarm web interface.
- Click the Create new node button.
- In the form that appears, enter the node name into the corresponding field and select the “Cloud” type of installation from the drop-down list.
- Click the Create button.
-
In the window that appears, click the Copy button next to the field with the token to add the token of the newly created filter node to your clipboard.
-
On the virtual machine run the
addcloudnode
script:Info
You have to pick which script to run depending on the Cloud you are using.
- If you are using https://my.wallarm.com/, run the script from the EU Cloud tab below.
- If you are using https://us1.my.wallarm.com/, run the script from the US Cloud tab below.
sudo /usr/share/wallarm-common/addcloudnode
sudo /usr/share/wallarm-common/addcloudnode -H us1.api.wallarm.com
-
Paste the filter node token from your clipboard.
Your WAF node will now synchronize with the Cloud every 2‑4 minutes according to the default synchronization configuration.
WAF node and Cloud synchronization configuration
After running the addcloudnode
script, the /etc/wallarm/syncnode
file containing the WAF node and Cloud synchronization settings will be created. The settings of the WAF node and Cloud synchronization can be changed via the /etc/wallarm/syncnode
file.
More details on the WAF node and Wallarm Cloud synchronization configuration →
Connecting Using Your Cloud Account Login and Password¶
To connect the node to the cloud using your cloud account requisites, proceed with the following steps:
-
On the virtual machine run the
addnode
script:Info
You have to pick which script to run depending on the Cloud you are using.
- If you are using https://my.wallarm.com/, run the script from the «EU Cloud tab below.
- If you are using https://us1.my.wallarm.com/, run the script from the US Cloud tab below.
sudo /usr/share/wallarm-common/addnode
sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com
-
Provide your Wallarm account’s login and password when prompted.
API Access
The API choice for your filter node depends on the Cloud you are using. Please, select the API accordingly:
- If you are using https://my.wallarm.com/, your node requires access to
https://api.wallarm.com:444
. - If you are using https://us1.my.wallarm.com/, your node requires access to
https://us1.api.wallarm.com:444
.
Ensure the access is not blocked by a firewall.
Your WAF node will now synchronize with the Cloud every 2‑4 minutes according to the default synchronization configuration.
WAF node and Cloud synchronization configuration
After running the addnode
script, the /etc/wallarm/node.yaml
file containing the WAF node and Cloud synchronization settings and other settings required for a correct WAF node operation will be created. The settings of the WAF node and Cloud synchronization can be changed via the /etc/wallarm/node.yaml
file and system environment variables.
More details on the WAF node and Wallarm Cloud synchronization configuration →
6. Set up the Filter Node for Using a Proxy Server¶
Info
This setup step is intended for users who use their own proxy server for the operation of the protected web applications.
If you do not use a proxy server, skip this step of the setup.
You need to assign new values to the environment variables, which define the proxy server used, to configure Wallarm node for using your proxy server.
Add new values of the environment variables to the /etc/environment
file:
-
Add
https_proxy
to define a proxy for the https protocol. -
Add
http_proxy
to define a proxy for the http protocol. -
Add
no_proxy
to define the list of the resources proxy should not be used for.
Assign the <scheme>://<proxy_user>:<proxy_pass>@<host>:<port>
string values to the https_proxy
and http_proxy
variables.
-
<scheme>
defines the protocol used. It should match the protocol that the current environment variable sets up proxy for. -
<proxy_user>
defines the username for proxy authorization. -
<proxy_pass>
defines the password for proxy authorization. -
<host>
defines a host of the proxy server. -
<port>
defines a port of the proxy server.
Assign a "<res_1>, <res_2>, <res_3>, <res_4>, ..."
array value, where <res_1>
, <res_2>
, <res_3>
, and <res_4>
are the IP addresses and/or domains, to the no_proxy
variable to define a list of the resources which proxy should not be used for. This array should consist of IP addresses and/or domains.
Resources that need to be addressed without a proxy
Add the following IP addresses and domain to the list of the resources that have to be addressed without a proxy for the system to operate correctly: 127.0.0.1
, 127.0.0.8
, 127.0.0.9
, and localhost
.
The 127.0.0.8
and 127.0.0.9
IP addresses are used for the operation of the Wallarm filter node.
The example of the correct /etc/environment
file contents below demonstrates the following configuration:
-
HTTPS and HTTP requests are proxied to the
1.2.3.4
host with the1234
port, using theadmin
username and the01234
password for authorization on the proxy server. -
Proxying is disabled for the requests sent to
127.0.0.1
,127.0.0.8
,127.0.0.9
, andlocalhost
.
https_proxy=http://admin:01234@1.2.3.4:1234
http_proxy=http://admin:01234@1.2.3.4:1234
no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost"
7. Set Up Filtering and Proxying Rules¶
The following files contain NGINX and WAF node settings:
-
/etc/nginx/nginx.conf
defines the configuration of NGINX -
/etc/nginx/conf.d/wallarm.conf
defines the global configuration of Wallarm WAF node -
/etc/nginx/conf.d/wallarm‑status.conf
defines the WAF node monitoring service configuration
You can 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.
To see detailed information about working with NGINX configuration files, proceed to the official NGINX documentation.
Wallarm directives define the operation logic of the Wallarm filter node. To see the list of Wallarm directives available, proceed to the Wallarm configuration options page.
A Configuration File Example¶
Let us suppose that you need to configure the server to work in the following conditions:
-
Only HTTP traffic is processed. There are no HTTPS requests processed.
-
The following domains receive the requests:
example.com
andwww.example.com
. -
All requests must be passed to the server
10.80.0.5
. -
All incoming requests are considered less than 1MB in size (default setting).
-
The processing of a request takes no more than 60 seconds (default setting).
-
Wallarm must operate in the monitor mode.
-
Clients access the filter node directly, without an intermediate HTTP load balancer.
Creating a configuration file
You can create a custom NGINX configuration file (e.g. example.com.conf
) or modify the default NGINX configuration file (default.conf
).
When creating a custom configuration file, make sure that NGINX listens to the incoming connections on the free port.
To meet the listed conditions, the contents of the configuration file must be the following:
server {
listen 80;
listen [::]:80 ipv6only=on;
# the domains for which traffic is processed
server_name example.com;
server_name www.example.com;
# turn on the monitoring mode of traffic processing
wallarm_mode monitoring;
# wallarm_instance 1;
location / {
# setting the address for request forwarding
proxy_pass http://10.80.0.5;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
8. Allocate More Memory for the Wallarm Node¶
The Wallarm Node uses Tarantool, an open‑source in-memory database, to calculate traffic metrics required for automated adjusting of security rules.
By default, the amount of RAM allocated to Tarantool is 40% of the total instance memory.
You can change the amount of RAM allocated for Tarantool. To allocate the instance RAM to Tarantool:
-
Open the Tarantool configuration file:
sudo vim /etc/default/wallarm-tarantool
-
Set the amount of allocated RAM in the
SLAB_ALLOC_ARENA
in GB. The value can be an integer or a float (a dot.
is a decimal separator). For example, to set 24 GB:
SLAB_ALLOC_ARENA=24
-
To apply changes, restart the Tarantool daemon:
sudo systemctl restart wallarm-tarantool
9. Configure Logging¶
Configure the filter node variables logging using NGINX. This will allow to perform a quick filter node diagnostics with the help of the NGINX log file.
10. Restart NGINX¶
Restart NGINX by running the following command:
sudo systemctl restart nginx
The Installation Is Complete¶
The installation is now complete.
Check that the filter node runs and filters the traffic. See Check the filter node operation.
Default Settings
A freshly installed filter node operates in blocking mode (see the wallarm_mode
directive description) by default.
This may result in the inoperable Wallarm scanner. If you plan to use the scanner, then you need to perform additional actions to render scanner operational.
Additional Settings¶
The filter node may require some additional configuration after installation.
The document below lists a few of the typical setups that you can apply if needed.
To get more information about other available settings, proceed to the “Configuration” section of the Administrator’s Guide.
Configuring the Display of the Client's Real IP¶
If the filter node is deployed behind a proxy server or load balancer without any additional configuration, the request source address may not be equal to the actual IP address of the client. Instead, it may be equal to one of the IP addresses of the proxy server or the load balancer.
In this case, if you want the filter node to receive the client's IP address as a request source address, you need to perform an additional configuration of the proxy server or the load balancer.
Adding Wallarm Scanner Addresses to the Whitelist¶
The Wallarm scanner checks the resources of your company for vulnerabilities. Scanning is conducted using IP addresses from one of the following lists (depending on the type of Wallarm Cloud you are using):
If you are using the Wallarm scanner, you need to configure the whitelists on your network scope security software (such as firewalls, intrusion detection systems, etc.) to contain Wallarm scanner IP addresses.
For example, a Wallarm filter node with default settings is placed in the blocking mode, thus rendering the Wallarm scanner unable to scan the resources behind the filter node.
To make the scanner operational again, whitelist the scanner's IP addresses on this filter node.
Limiting the Single Request Processing Time¶
Use the wallarm_process_time_limit
Wallarm directive to specify the limit of the duration for processing a single request by the filter node.
If processing the request consumes more time than specified in the directive, then the information on the error is entered into the log file and the request is marked as an overlimit_res
attack.
Limiting the Server Reply Waiting Time¶
Use the proxy_read_timeout
NGINX directive to specify the timeout for reading the proxy server reply.
If the server sends nothing during this time, the connection is closed.
Limiting the Maximum Request Size¶
Use the client_max_body_size
NGINX directive to specify the limit for the maximum size of the body of the client's request.
If this limit is exceeded, NGINX replies to the client with the 413
(Payload Too Large
) code, also known as the Request Entity Too Large
message.