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

Hi Amos,

Thanks for the reply - I remember seeing the doc bug :)

I am building the Deb6 boxes as we speak (ext4+squid 3.1 is sounding very
nice)

Cheers,

Pieter

On Mon, 21 Feb 2011, Amos Jeffries wrote:

> 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 - 03:28:48 MST