Installation

System Requirements

To install and use vWAF, make sure the following requirements are satisfied:

Sufficient CPU resources on the Virtual Traffic Manager (Traffic Manager). Prior to the installation of vWAF the load on the server should not exceed 60%.
A minimum total of 1 GB free memory space on the hard disk for program data and log files created during operation.
A minimum of 1 GB RAM.

ATTENTION
For web applications with high traffic, the log files generated can quickly become very large. Rotate and archive these files on a regular basis.

First-Time Installation

Refer to the detailed instructions in the Virtual Traffic Manager User’s Guide for installation and configuration instructions.

Update Installation

Updates of vWAF are handled through the Traffic Manager’s standard update channel. Contact Technical Support if you encounter any difficulties.

Configuring vWAF

You can configure basic settings for vWAF from the Traffic Manager administration interface (Admin UI). The System > Application Firewall section of the Traffic Manager Admin UI contains settings for the vWAF administration server, the decider processes, and for the internal communication ports that vWAF uses.

For more detailed configuration options, see Global Configuration.

Note that any changes that you make to the vWAF settings apply to every machine in the cluster. After changing the settings, vWAF is automatically restarted on every machine in the cluster so the new settings take effect.

Setting Enforcer Options

Please refer to the detailed instructions in the Virtual Traffic Manager User’s Guide which describe how to configure options for the Enforcer TrafficScript rule.

Protecting Your Services

You can configure your Traffic Manager’s Virtual Servers to have their traffic inspected by vWAF. Each Virtual Server’s settings page provides an option to enable vWAF. When vWAF is activated, the Enforcer TrafficScript rule will be added to the Virtual Server and will start sending traffic to vWAF immediately. For more information, see the Virtual Traffic Manager User’s Guide.

ATTENTION
As soon as the Enforcer is activated, all queries to the web server are evaluated by vWAF. If any ruleset is active in protection mode, vWAF may deny queries that match one of the underlying rules.

Starting and Stopping the Software

You can restart the vWAF software from the System > Traffic Manager section of the Traffic Manager administration interface (Admin UI). You can uninstall vWAF from the System > Application Firewall section of the Traffic Manager Admin UI. For more information, see the Virtual Traffic Manager User’s Guide.

Allowing Connection to Update Server

If you want to take advantage of automated updates of rules and blacklists provided for basic detection and protection (see Baseline Protection Wizard, Baseline Protection Handler, Vulnerability Description Import Wizard), vWAF needs to connect to the following update server.

https://mydefence.artofdefence.com/update/

If you want to use a proxy, you must also specify this proxy. This is done within the configuration file zeusafm.conf (see System Configuration).

Configuring Multi-CPU Support

With complex rulesets the decider can become a performance bottleneck. With multi-CPU support, an individual decider process is run on each CPU. The Traffic Manager allocates the individual requests to the different CPUs, ensuring that queue times are minimized.

vWAF automatically takes advantage of multi-CPU machines by running one decider process for each CPU core that’s available. If vWAF is installed on a cluster of Traffic Managers, then the number of decider processes running on each machine is equal to the number of CPUs on the machine with the fewest CPUs.

You can manually configure the number of decider processes from the System > Application Firewall page of the Traffic Manager Admin UI.

Changing Ports

You can configure the ports that vWAF uses for internal communication from the System > Application Firewall page of the Traffic Manager Admin UI.

Using Custom Configuration Files

On Linux/Unix systems, you can optionally use custom configuration files instead of the default zeusafm.conf and updater.conf file. You can even split your settings and have multiple configuration files in parallel.

To use a custom configuration file, set the following environment variables before starting vWAF or before starting the updater:

AOD_CONFIG_FILENAME for zeusafm.conf
AOD_UPDATER_CONFIG_FILENAME for updater.conf

Example

export AOD_CONFIG_FILENAME = /path/to/myconf.conf export AOD_UPDATER_CONFIG_FILENAME = /path/to/myupconf.conf

Paths must be absolute (no relative paths). If the specified configuration file doesn’t exist, or if the script has no permission to read it, vWAF or the updater won’t start. If a value isn’t found in the specified file, its default setting is used.

Instead of using one single custom configuration file, you can use multiple ones. This enables you to split or to cascade your settings. If identical configuration items are found in multiple files, the last processed one wins. Additional configuration files are always read after the global ones (that is, after zeusafm.conf and updater.conf or after the ones specified by AOD_CONFIG_FILENAME and AOD_UPDATER_CONFIG_FILENAME). To use additional custom configuration files, set the following environment variables:

AOD_CONFIG_FILENAME_* for zeusafm.conf
AOD_UPDATER_CONFIG_FILENAME_* for updater.conf

The files are processed in lexicographical order; that is, numbers before letters and letters alphabetically.

Example

export AOD_CONFIG_FILENAME_A = /path/to/myfile1.conf export AOD_CONFIG_FILENAME_B = /path/to/myfile2.conf export AOD_CONFIG_FILENAME_1 = /path/to/myfile3.conf

In this case, myfile3.conf is processed first, and then myfile1.conf and myfile2.conf. If a setting is specified in all three files, the setting of myfile2.conf is used because this is file that is last processed.