Re: [squid-users] X-Forwarded-For + Squid Version 3.0.STABLE8

 On Mon, 21 Feb 2011 12:16:46 +1300 (NZDT), Pieter De Wit wrote:
> Hi Guys,
>
> I run a reverse proxy for a client. They are using XFF for
> restricting certain content to IP.
>
> We have noted that the following doesn't "appear" to work as it
> should:
>
> header_replace X-Forwarded-For allow all
>
> My understanding is that this will cause squid to replace the XFF
> header with it's own "client IP" ?

 No this will replace the content of X-Forwarded-For with the text
 "allow all".

 BUT, only if there is a corresponding "request_header_access
 X-Forwarded-For deny" line (or reply_header_access).

 FWIW there was a documentation bug for a while indicating that Squid
 would add its *own* IP to XFF.
   Squid will never do that. Only the remote visitors/client IP is added
 to XFF.

>
> I see there is various answers about this on the internet so I would
> like to know which one applies to this setup.
>

 In 3.0 you can use the header access denial + replace to strip out the
 existing header and add any desired forgery.

 In 3.1+ you can use "forwarded_for truncate" to erase a prior history
 trace and perform what you describe in a much cleaner way. This is not
 usually a good idea and only useful to paper around broken web app
 security vulnerabilities.

> Here is some more details on the proxy chain:
>
> client -> proxy1 -> proxy2 -> origin web server
>
> Proxy 1 should replace the XFF header no matter what, so that if
> "client" is behind a proxy, it doesn't matter.

 Well, truncate will do that, BUT using an origin server app which only
 pulls the *newest* IP off the list will be much better. And will protect
 against malicious forgery attacks as well.

>
> Proxy 2 should just pass the header as per normal, it doesn't matter
> if it adds an IP to the header.
>
> I am looking at replacing these boxes with Debian 6 boxes over the
> next week or so, but would really like to nail this one now :)

 Then you will have access to 3.1.6+ with the above mentioned
 forwarded_for extensions.

 In this setup in order to pass the client IP to the origin I would
 advise using this config:

 proxy 1:
   - nothing special. It will add the real client IP to X-Forwarded-For:
 header.
   - you MAY use "forwarded_for truncate" here to explicitly erase any
 past garbage. But see above.

 proxy 2:
   forwarded_for transparent

  - this will mean proxy 2 preserves the client IP proxy1 added as
 latest on the list, by not mentioning proxy1
  - BE CAREFUL that the only way requests can reach proxy2 is via
 proxy1.

 origin:
  - trust proxy 2 as provider of X-Forwarded-For and grab the latest
 client from the XFF which it hands over.

 Amos
Received on Mon Feb 21 2011 - 02:51:07 MST