For this week's Azure Platform Security blog, we are featuring Azure principal product manager, Gopi Kannan
The X-Forwarded-For (XFF) HTTP header provides crucial insight into the origin of web requests. The header works as a mechanism for conveying the original source IP addresses of clients, and not just across one hop, but through chains of multiple intermediaries.
Information embedded in XFF headers is vital to network security to help with both enforcement and auditing. Thus, it’s important for proxies like Azure Firewall to preserve this information when packets flow through the networks. This blog shares Azure Firewall handling XFF headers.
How does Azure Firewall handle XFF headers?
Proxies can perform several actions on the XFF headers received. This includes preserving the XFF contents received before forwarding to the next hop, augmenting client IP to the XFF header and enforcing policies based on XFF contents.
Azure Firewall preserves and augments XFF header based on how the traffic is received and processed. Behavior is detailed below.
|
Traffic/Payload |
Rule Processed |
Preserves original content in the XFF header |
Augment Client IP to the XFF header |
|
HTTP payload |
Application Rules |
Preserved |
YES |
|
HTTPs payload |
Application Rules |
Preserved |
NO (XFF header is encrypted) |
|
HTTPs with TLS termination |
Application Rules |
Preserved |
YES |
|
HTTP or HTTPs payload |
DNAT/Network rules |
Preserved – Azure Firewall doesn’t impact HTTP headers as traffic is processed at layer 4 | |
Validating Azure Firewall behavior:
For this blog, I set up a local environment with NGINX to validate Firewall behavior. This includes a local client running in Azure, Internet client and a NGINX webserver to process http/s traffic. I used a private DNS zone to redirect traffic of a popular domain (example.com) to my NGINX server behind the firewall.
HTTP/s client traffic and response:
The client sends a http payload to example.com after adding 192.0.2.100 to XFF header.
Azure Firewall output:
The Azure Firewall receives both HTTP and HTTPs requests as the NGINX server redirects the client HTTP traffic to HTTPs listener.
Server XFF header output:
For HTTP requests, XFF output displays both the client IP and the appended IP in the curl request.
For HTTPs requests, XFF output displays only the IP added by the client.
DNAT traffic to the server:
Internet clients send https traffic to the NGINX server via Azure Firewall Public IP.
Azure Firewall receives the traffic as a DNAT rule and redirects the traffic to the translated destination server.
Server XFF header output:
Traffic is received with XFF header inserted by the client. Azure Firewall doesn’t impact this header as it receives the traffic on the network.
Conclusion:
In conclusion, the X-Forwarded-For (XFF) HTTP header plays a crucial role in providing insight into the origin of web requests. It helps convey the original source IP addresses of clients through multiple intermediaries, which is vital for network security, enforcement, and auditing.
Azure Firewall's handling of XFF headers ensures that this information is preserved and augmented based on how the traffic is received and processed. By maintaining the integrity of XFF headers, Azure Firewall enhances security measures and provides a reliable mechanism for tracking the source of web traffic.
Microsoft