Web Gateway: Via and X-Forwarded-For Headers (Proxy Loop Prevention)

[#1]

• Introduction
• Explanation: Via Header
• Proxy Loop Examples
• Best Practices
• Via header
• X-Forwarded-For
• Procedure
• Ruleset Downloads
• Conclusion

Introduction

Have you noticed the Via and X-Forwarded-For headers added to your requests/responses when passing traffic through the Web Gateway? Perhaps you've noticed them while troubleshooting or checking network tool sites like www.ifconfig.me. This guide will help you understand what these headers are for and give you best practices for using them.

Explanation: Via Header

The Via Header is a general-header defined by RFC. The header is added by the MWG to outbound requests to the web and to responses going back to the client.  The Via header includes information for these recipients to indicate protocol capabilities, the IP address of the proxy, as well as the type/version of the proxy being used.

Below is a screenshot that shows the Via Header in a packet capture:

One of the main benefits to having a Via Header is that it can help prevent Proxy Loops.

A proxy loop can happen when a proxy forwards a request either to itself or receives a request “back” from another proxy . The proxy keeps trying to serve the request and the process is repeated causing a loop.  You want to avoid proxy loops as the request that keeps looping will cause a large resource spike on your proxy which can lead to performance problems such as the proxy failing to pass traffic. When the Via header is added to the request, the proxy (MWG) will be able to identify and end the loop.

 

Proxy Loop Examples

Below is a visual example of a proxy loop:

Below is what a request will look like in a proxy chain without the Via header.

Client (pink): 10.10.72.1 – Proxy1 (blue): 10.10.72.5 - Proxy2 (green): 10.10.72.101

• The first request to www.google.com is made by the client to Proxy1.
• In the first blue packet, you can see Proxy1 makes the same request on behalf of the client to Proxy2.
• Next, Proxy2 sends the same request back toProxy1. This is the start of the proxy loop.
• Notice the request keeps being forwarded between Proxy1 and Proxy2. The client will never actually receive a response and eventually timeout. This is a Proxy Loop.  Because of the large amount of requests in a short time, a Proxy loop will eventually cause a CPU load and connection spike on both Proxies.

Below is what a request willlook like in a proxy chain with the Via header.

Client (pink): 10.10.72.1 – Proxy1 (blue): 10.10.72.5 - Proxy2 (yellow): 10.10.72.101

• The first request to www.google.com is made by the client toProxy1.
• In the first blue packet, you can see Proxy1makes the same request on behalf of the client to Proxy2.
• The final request from proxy2 to proxy1 is in yellow. Notice that the request gets forwarded back to the proxy1 in our first yellow packet. Because the request came in with a Via header, the MWG’s proxy loop prevention kicks in as Proxy1 responds back with a 502 infinite proxy loop response. That response goes back the path it came until it reaches the client were it will be displayed as a block page.

Explanation: X-Forwarded-For Header

X-forwarded-for is a header used to keep track of the originating client IP connecting to a web server through a proxy or load balancer. This header can be used by other appliances such as firewalls to gather statistics about the originating client IP.

Below is a screenshot that shows the X-Forwarded-For Header in a packet capture:

Best Practices

Via header

As the Via header can include sensitive network information that you may not want released, we recommend that it be modified to say a single word such as “Proxy”. Using the Via Header in this way can still protect you from proxy loops and also gives you security in knowing that network information is not being sent to the Internet.

X-Forwarded-For

As we discussed, the X-Forwarded-for header also includes network information you may not want released to the Internet. It is our recommendation that you remove this unless you have a device in your network that can take advantage of using this header.

Note: There are situations in which web servers may act strange when they see the Via Header and/or x-forwarded-for headers. These are not common scenarios as properly coded servers are supposed to ignore headers they are not interested in.  In this case, it may be needed to remove these headers only for these specific web servers.

We'll cover best practices for modifying and removing these headers below.

Procedure

Set Via Text:This is the rule that will store the string you use in your modified Via Header. You need to modify this rule and replace “proxy A” with the value you want to have in place of the default Via header value.

Check If Via Text Exists: This rule is here to prevent proxy loops by blocking requests with the modified Via Text. It does this by checking the Via Header value for the text defined in the “Set Via Text”.

Modify Via: If the Requests gets past the “Check If Via Text Exists”, we remove the current Via header and add a new one with the value defined in the “Set Via Text” rule.

Remove Via:This rule is disabled by default. It will remove the via header on a per site basis

Remove X-Forwarded-For: This rule will remove the X-Forwarded-For Header.

Once the rule is created/imported, it will look this:

Ruleset Downloads

Version >=7.2

Conclusion

By reading this article, you learned about the Via and X-Forwarded-For headers and how to manage them using our best practices.

[renata.petrasov]

Hi, what if the rule applies only to requests and not to responses? I guess the second rule "Check if Via Text exists" would not work, but are there any other concerns? I'm reviewing our rules and I saw that we applied this only to requests...

thx