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
