Origin Server¶

rescaled WAF supports traffic distribution between one or multiple origin servers. These are the servers that actually serve your website or application.

Load Balancing¶

If you are providing more than one origin server, the WAF will automatically distribute the incoming traffic between them using the least-connection principle to even out load to your systems. Upon request, it's possible to adjust the load balancing algorithm to e.g. use round-robin or a weighted distribution to better suit your custom requirements.

Transport Layer Security (TLS)¶

Client connections towards the WAF are (usually) encrypted using TLS. In order to inspect the traffic and to evaluate rules against it, the TLS connection needs to be terminated. To avoid MITM attacks and to ensure the confidentiality and integrity of the web traffic on the way between the WAF and the origin, the WAF is able to re-encrypt the traffic before forwarding it to the origin. While technically possible to send the traffic unencrypted, this is highly discouraged.

In order to be able to use traffic encryption via TLS between the WAF and the origin, your origin web-server needs to support and serve TLS traffic. It's not required to listen on a specific port for TLS traffic as this is configurable. While we recommend using a valid certificate from a trusted CA, you can configure the WAF to accept any certificate presented by the origin. While this poses a security risk in regard to potential traffic redirection attacks, it's safer to handle it this way instead of not using TLS between WAF and origin at all.

rescaled WAF doesn't interfere with ACME (Automatic Certificate Management Environment) traffic for HTTP-01 challenges. Please notice that it's not possible to use ALPN-01 challenges, as the WAF doesn't support forwarding custom ALPN traffic towards the origin.

Client IP¶

From the point of view of your origin, all client connections are coming from the WAF. Web servers are usually using the source IP of the incoming connection as single source of truth to determine the client's IP address. In order to allow origins to actually identify the client, rescaled WAF is forwarding the client's IP address from the WAF to the origin server in two headers.

X-Forwarded (RFC 7239)¶

Requests that are being sent from the WAF to the origin server contain two well-known X-Forwarded headers. These are defined in RFC 7239 and are used to preserve the original client IP address information when performing reverse proxying. The following headers are being transmitted:

Proprietary Header¶

rescaled WAF also adds another header containing the client's original IP address in case the default headers can not be used for any reason.

Origin Configuration¶

In order to properly consume the client IP address you need to configure your origin server to actually accept the headers. Basically all web servers or reverse proxies are capable of handling these headers, but they might be disabled or restricted in some way to prevent clients from setting the headers to arbitrary values to "spoof" the client IP address, the web servers are seeing.

We've prepared configuration snippets for common web servers and reverse proxies to help you get started.

Whenever a snippet refers to {RESCALED_IP_RANGE}, you need to replace it with the outgoing IP address range of the WAF. This depends on the location of the WAF you have chosen for your deployment.

NGINX¶

set_real_ip_from {RESCALED_IP_RANGE};
real_ip_header X-Forwarded-For;

# Alternatively, you can use the `x-rescaled-connecting-ip` header.
# real_ip_header x-rescaled-connecting-ip;

Configuring this requires the ngx_http_realip_module module, which is usually enabled by default. The instruction set_real_ip_from can be repeated multiple times.

Apache 2¶

LoadModule remoteip_module modules/mod_remoteip.so

RemoteIPHeader X-Forwarded-For
# Alternatively, you can use the `x-rescaled-connecting-ip` header.
# RemoteIPHeader x-rescaled-connecting-ip

RemoteIPTrustedProxy {RESCALED_IP_RANGE}

The instruction RemoteIPTrustedProxy can be repeated multiple times.

HAProxy¶

acl rescaled_waf src {RESCALED_IP_RANGE}

http-request del-header X-Forwarded-For if !rescaled_waf
http-request set-var(req.client_ip) req.hdr(X-Forwarded-For)

# Alternatively, you can use the `x-rescaled-connecting-ip` header.
# http-request set-var(req.client_ip) req.hdr(x-rescaled-connecting-ip)

To add multiple source IP ranges, simply add the ranges to the acl trusted_proxy instruction, separated by spaces. The configuration example needs to be placed in the frontend section it should apply to.

Traefik¶

entryPoints:
  web:
    address: ":80"
    forwardedHeaders:
      trustedIPs:
        - {RESCALED_IP_RANGE}
  websecure:
    address: ":443"
    forwardedHeaders:
      trustedIPs:
        - {RESCALED_IP_RANGE}

The trustedIPs section is a list and can be extended by adding multiple ranges to the list. Using a different header name is not natively supported in Traefik.

Securing Origin¶

In order to prevent direct access to the origin servers, thereby effectively disabling/circumventing the WAF, you can configure your origin to only allow incoming connections from the WAF.

Whenever a snippet refers to {RESCALED_IP_RANGE}, you need to replace it with the outgoing IP address range of the WAF. This depends on the location of the WAF you have chosen for your deployment.

NGINX¶

For NGINX, you can either restrict the access to the origin server on a per-directory level or globally per virtual host.

location / {
    allow {RESCALED_IP_RANGE};
    deny all;
}

stream {
    server {
        listen 80;
        allow {RESCALED_IP_RANGE};
        deny all;
    }
}

The allow block can be repeated multiple times to allow multiple IP ranges. You might want to explicitly allow your loopback IP address as well as private network ranges (RFC 1918). This functionality requires the ngx_stream_access_module module which is enabled by default.

Apache 2¶

Apache also supports the restriction on a per-directory level as well as on the virtual host level.

<Location "/">
    Require ip {RESCALED_IP_RANGE}
</Location>

The RequireAny keyword is valid within a VirtualHost definition.

<RequireAny>
    Require ip {RESCALED_IP_RANGE}
</RequireAny>

The Require instructions can be repeated multiple times to allow multiple IP ranges.

HAProxy¶

For HAProxy, we recommend restricting access on a TCP-level, rather than on the HTTP-level.

acl rescaled_waf src 10.0.0.0/8
tcp-request connection reject if !rescaled_waf

The snippet above needs to be placed in the frontend section it should apply to. To add more IPs or IP ranges, you can simply add the ranges to the acl rescaled_waf instruction, separated by spaces.

Traefik¶

Use the IPAllowList middleware in Traefik to restrict access to the origin server.

http:
  middlewares:
    allow-trusted-ips:
      ipAllowList:
        sourceRange:
          - {RESCALED_IP_RANGE}

The sourceRange field is a list and can be extended by adding multiple ranges to the list. You need to explicitly configure the middleware to be used in the service you want to protect.