How to Add Wallarm to Protect Your NGINX Plus Installation

Why a WAF?

If you are developing applications based on a high‑performance application server such as NGINX Plus, you need to consider security implications, especially if your web application accepts requests from outside the company perimeter.

A web application firewall (WAF) is a security module focused on applications themselves, providing highly granular and customizable logic for protecting both web applications and the underlying data. For example, many of the vulnerabilities a WAF protects from are common across many web applications. These types of vulnerabilities are well documented in Open Web Application Security Project (OWASP) and include SQL injection, cross‑site scripting, field/cookie validation, and others.

Together, NGINX Plus and WAF:

Inspect traffic at Layer 7
Protect web applications from OWASP vulnerabilities
Can be configured with security rules based on signatures, specific to the web application

Like most legacy WAFs, Wallarm inspects traffic at Layer 7 and protects against the OWASP Top 10.

Unlike a legacy WAF, Wallarm doesn’t rely on signatures, instead using machine learning and AI to understand nested application APIs, learn the application logic, and establish boundaries for what represents a “normal” payload. This means that Wallarm security rules are both automated and customized to each application without the need for additional manual configuration.

Going further, Wallarm functionality includes proactive threat validation. Wallarm tests every attack against the application to check if it might result in an exploit because there is a matching vulnerability within the application. Effectively, Wallarm combines WAF and Dynamic Application Security Testing (DAST) functionality.

Deploying Wallarm with NGINX Plus

To make sure WAF is functional, the security module needs to be in-line for the application traffic. It can be in non-blocking Monitoring mode if that is a concern. There are two ways to install a WAF with a modern web application: at the first tier or at the last mile – right on the application server.

First tier means that you have WAF installed as part of the load‑balancing layer. This works well if you are using NGINX Plus as the load balancer. Alternatively, WAF can be installed directly on the application server. This is also known as a secured or protected container, in environments where the developers use containers like Docker with preinstalled WAF inside to deploy their apps. The latter option is only available with software WAFs. This can work well when NGINX Plus is used as an application server.

Wallarm installs right into the instance of NGINX or NGINX Plus as a dynamic software module certified by NGINX, Inc., making it a perfect fit for either of the deployment models.

Installing Wallarm

Prerequisites

A 64-bit system
One of the supported Linux distributions (we use Ubuntu as an example in the following installation instructions)
Root permissions or equivalent access via sudo
A valid Wallarm license key
A Wallarm account that has permissions to add new nodes
NGINX Plus installed on the system (see the instructions in the NGINX Plus Admin Guide)

To install Wallarm:

Add repositories.

Add the Wallarm node repositories to the location where the installation packages are stored. The following commands are appropriate for Ubuntu:

apt-key adv --keyserver keys.gnupg.net --recv-keys 72B865FD

echo 'deb http://repo.wallarm.com/ubuntu/wallarm-node trusty/' > /etc/apt/sources.list.d/wallarm.list

apt-get update

Install packages.

Install the following two packages on the same server to enable the primary processing and post‑analytics subsystems:
- NGINX module
- Post‑analytics module
```
apt-get install --no-install-recommends wallarm-node-nginx nginx-plus-module-wallarm
```
Note that if the volume of application API traffic is high, it might be preferable to install the post‑analytics module on a separate server.
Install the Wallarm license key.

Wallarm sends the license key to the email address specified in your account. Copy the key contents to /etc/wallarm/license.key and set access rights for the file.
```
chmod 0640 /etc/wallarm/license.key

chown root:wallarm /etc/wallarm/license.key
```
Connect the filter node to the Wallarm cloud.

The filter node interacts with the Wallarm cloud to update security rules and send various metrics and attack data. To initiate communication with the server, run the addnode script:
```
/usr/share/wallarm-common/addnode
```
When started, the script asks for your username and password to enter https://my.wallarm.com. Note that your account must have the privileges to create a new filter node, and an error message appears if you do not.
Enable API access.

To interact with the Wallarm cloud, the filter node must have access to port 444 on api.wallarm.com. Make sure there are no firewall settings blocking the access.
Configure the post‑analytics module.

If necessary, you can modify parameters of the post‑analytics module.
```
vi /etc/default/wallarm-tarantool
SLAB_ALLOC_ARENA=1
systemctl restart wallarm-tarantool
```
Set up the filtration mode.

Uncomment wallarm_mode in the /etc/nginx/conf.d/wallarm.conf file to set up filtration, as in this example:
```
/etc/nginx/conf.d/wallarm.conf

#

# Wallarm module specific parameters

#
wallarm_mode monitoring;

# wallarm_mode_allow_override on;
# ...
```
If necessary, you can configure wallarm_mode separately for each virtual server.

You’re all set. Your web application is now protected with Wallarm WAF.

Testing Your Application’s Protection

To test how well your application is protected, you can write security tests manually and attempt typical applications exploits.

Many examples, including XSS and the “Page not found” error are described on the OWASP website.

You can also log into your account at http://my.wallarm.com and access the Vulnerabilities tab. The following example shows the initial result of the Wallarm DAST component, where Wallarm has tested an application against well‑known vulnerabilities seen by other Wallarm customers.