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
