Hi Mark,
It seems you have already resolved the issue by changing your internal ELB into NLB. Please allow me to add some notes for you.
From what you have described, I guess the product you are using is the "On-premise WAF" deployed on AWS environment. (It is formerly named "SecureSphere".)
And because it is deployed on a cloud platform (AWS) it may be easy to get mixed up with another product line "Cloud WAF" (formerly named "Incapsula").
- The link you have quoted, and those screenshots posted by the others are all referring to the "Cloud WAF". I guess that's the reason why they looks like a totally different thing to your environment.
For "On-premise WAF", WAF should bring all the header values (including custom headers) from the original request from clients to the internal host, while there are options to "insert" new headers as needed.
One of them is the client IP, which is configured under the "Reverse Proxy" tab. You are able to specify your own custom header name here too. (see the screenshot below)
"On-premise WAF" User Guide (v13.6):
https://docs.imperva.com/bundle/v13.6-web-application-firewall-user-guide/page/3094.htmI always apply below filters to look for "On-premise WAF" documentations:
1. Go to
https://docs.imperva.com/2. Click the "Library" next to search box to browse the documentation library.
3. Expand the "Application Security" category.
4. Select "On-premise WAF".
Hope you'll find this helpful!
Best Regards,
Louis
------------------------------
Louis Tsoi
Associate Consultant
Cyberforce Limited
------------------------------
Original Message:
Sent: 01-21-2021 13:33
From: Mark Bays
Subject: Request Headers X-Forwarded-For-Proto
As I stated and linked in my post we don't have that, and linked this exact statement from you. Unfortunately not valuable. Thank you though.
However we did find the issue here, and in this case is was the type of loadbalancers employed by AWS. We used a second ALB as the internal load balancer, as indicated by the documentation form Imperva, however the side effect of this is that since X-FORWARDED-FOR* headers are written by the ALBs the initial set gets overwritten by the internal LB before passing it on, destroying the headers from the edge ALB. The solution is to use an NLB (network Load Balancer) as the internal LB which is a Layer 4 LB, and thus doesn't add it's own headers, preserving the original headers from the edge ALB.
------------------------------
Mark Bays
Original Message:
Sent: 01-21-2021 13:28
From: Abhishek Gupta
Subject: Request Headers X-Forwarded-For-Proto
Hi Mark,
A simple ADR rule ( that is available with LB license ) can be used to perform this simple header addition.
"X-Forwarded-For-Proto": "http"
------------------------------
Abhishek Gupta
Customer Success team
Imperva
Original Message:
Sent: 01-20-2021 11:34
From: Mark Bays
Subject: Request Headers X-Forwarded-For-Proto
We have just spun up Imperva Cloud WAF on AWS, in our web application we use the X-Forwarded-For-Proto header to determine if the client request was made using HTTP or HTTPS, this header (and possibly others ie. ALB (Load Balancer) headers may be missing too. How do we have the Imperva WAF include these headers when proxying the request to the backend?
I have already read the discussion on enabling X-Forwarded-For for client IP, I added an additional line for X-Forwarded-For-Proto but this didn't pass that header. I additionally saw a post by Imperva discussing making custom rules (https://docs.imperva.com/bundle/cloud-application-security/page/rules/create-rule.htm?_ga=2.119830222.7759906.1611082681-2090835113.1607392760) This is not in our setup anywhere and looks to be part of a different offering.
#CloudWAF(formerlyIncapsula)
------------------------------
Mark Bays
------------------------------