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 a 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 a 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 the WAF installed as part of the load‑balancing layer. This works well if you are using NGINX Plus as the load balancer. Alternatively, the 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 a 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.
- 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
- 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 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 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:
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.
wallarm_modein 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_modeseparately 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.