Overview

Starting with BitNinja 3.16.0, the legacy web application firewall components have been removed and replaced by the new WAF Pro solution.

WAF Pro is built on the Caddy web server and consolidates the functionality previously provided by multiple modules into a single, modern solution.

What’s Changed?

The following legacy modules have been removed:

• WAF 2.0
• ProxyFilter
• SSLTerminating

Their responsibilities are now handled by WAF Pro, simplifying deployment and maintenance while providing a more secure and up-to-date architecture.

Known Limitation

Transparent Proxy Support

WAF Pro supports Transparent Proxy mode only on operating systems that provide the required OpenSSL 3 runtime library.

If the required library is unavailable, you may encounter an error similar to the following:

/opt/bitninja-waf3/nginx/sbin/nginx: error while loading shared libraries:
libssl.so.3: cannot open shared object file: No such file or directory

Why This Happens

Transparent Proxy relies on libssl.so.3.

Some older Linux distributions either:

• do not include OpenSSL 3, or
• cannot install it through their supported package repositories.

Rather than shipping or linking against an outdated OpenSSL version with known security vulnerabilities, WAF Pro requires OpenSSL 3. This ensures the proxy uses a modern cryptographic library that includes security fixes for previously disclosed vulnerabilities.

Fallback Behavior

If libssl.so.3 is available:

• WAF Pro operates in Transparent Proxy mode.

If libssl.so.3 cannot be installed:

• the Transparent Proxy component does not start;
• WAF Pro automatically switches to DNAT mode.

This allows the WAF to continue protecting the web server even on older operating systems.

Client IP Addresses in DNAT Mode

When WAF Pro operates in DNAT mode, the backend web server sees requests as originating from the local server rather than the actual client.

However, WAF Pro preserves the original client IP address by adding the standard HTTP headers:

• X-Forwarded-For
• X-Real-IP

Most modern web servers can be configured to trust these headers and log the real visitor IP address.

Note: Configure your web server to trust these headers only when requests originate from the server IP address or any other TrustedProxies you might use like Cloudflare or BunnyCDN.

Configuring Real Client IP

NGINX

Enable the Real IP module:

set_real_ip_from 127.0.0.1;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Reload NGINX:

systemctl reload nginx

Apache HTTP Server

Enable the mod_remoteip module.

Example configuration:

RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 127.0.0.1

Restart Apache:

systemctl restart httpd

or

systemctl restart apache2

Depending on your distribution.

LiteSpeed Enterprise

1. Open the LiteSpeed WebAdmin Console.
2. Navigate to:

Configuration → General

3. Enable:

Use Client IP in Header

4. Specify:

X-Forwarded-For

5. Save the configuration and perform a graceful restart.

OpenLiteSpeed

1. Open the WebAdmin Console.
2. Navigate to:

Server Configuration → General

3. Enable:

Use Client IP in Header

4. Set the header name to:

X-Forwarded-For

5. Gracefully restart OpenLiteSpeed.