Fortinet 269 FortiWeb 5.0 Patch 6 Administration Guide
3. Click OK.
4. To apply the X-header rule, select it when configuring an inline protection profile (see
“Configuring a protection profile for inline topologies” on page 468).
Indicating to back-end web servers that the client’s request was HTTPS
Usually if your FortiWeb is receiving HTTPS requests from clients, and it is operating in reverse
proxy mode, SSL/TLS is being offloaded. FortiWeb has terminated the SSL/TLS connection and
the second segment of the request, where it forwards to the back-end servers, is clear text
HTTP. In some cases, your back-end server may need to know that the original request was, in
fact, encrypted HTTPS, not HTTP.
To add an HTTP header that indicates the service used in the client’s original request, go to
Server Objects > X-Forwarded-For > X-Forwarded-For, then enable X-Forwarded-Proto:.
Blocking the attacker’s IP, not your load balancer
When you configure Use X-Header to Identify Original Client’s IP, FortiWeb compensates for
NAT in your data center by using an HTTP header to derive the client’s IP address. In this way,
even if the connection is not established directly between the web browser and FortiWeb, but
instead is relayed, with the last segment established between your proxy/load balancer’s IP and
FortiWeb, FortiWeb will still be able to report and block the actual attacker, rather than your own
infrastructure.
Only public IPs will be used. If the original client’s IP is a private network IP (e.g. 192.168.*,
172.16.*, 10.*), FortiWeb will instead use the first public IP before or after the original client’s IP
in the HTTP header line. (Whether this is counted from the left or right end of the header line
depends on IP Location in X-Header.) In most cases, this public IP will be the client’s Internet
gateway, and therefore blocking based on this IP may affect innocent clients that share the
attacker’s Internet connection. See also “Shared IP” on page 522.
To limit the performance impact, FortiWeb will analyze the HTTP header for the client’s IP only
for the first request in the TCP/IP connection. As a result, it is not suitable for use behind load
balancers that multiplex — that is, attempt to reduce total simultaneous TCP/IP connections
by sending multiple, unrelated HTTP requests from different clients within the same TCP/IP
connection. Symptoms of this misconfiguration include FortiWeb mistakenly attributing
subsequent requests within the same TCP/IP connection to the IP found in the first request’s
HTTP header, even though the X-header indicates that the request originated from a different
client.
After FortiWeb has traced the original source IP of the client, FortiWeb will use it in attack logs
and reports so that they reflect the true origin of the attack, not your load balancer or proxy.