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
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
Re: [squid-users] X-Forwarded-For + Squid Version 3.0.STABLE8
Hi Amos, just had a go at this: request_header_access X-Forwarded-For deny header_replace X-Forwarded-For and it's still passing XFF from another source thru - Nothing to urgent since the Deb6 boxes are getting built :) But if you spot something ? Cheers, Pieter
Re: [squid-users] X-Forwarded-For + Squid Version 3.0.STABLE8
On 21/02/11 16:33, Pieter De Wit wrote: Hi Amos, just had a go at this: request_header_access X-Forwarded-For deny header_replace X-Forwarded-For and it's still passing XFF from another source thru - Nothing to urgent since the Deb6 boxes are getting built :) But if you spot something ? Just a typo missing all after the deny . and no value to hard-code into the header on the replace line. This one is tricky to use since you have to hard-code the value passed back, it wont contain the real client IP you want. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.11 Beta testers wanted for 3.2.0.5
Re: [squid-users] X-Forwarded-For + Squid Version 3.0.STABLE8
On 21/02/2011 18:16, Amos Jeffries wrote: On 21/02/11 16:33, Pieter De Wit wrote: Hi Amos, just had a go at this: request_header_access X-Forwarded-For deny header_replace X-Forwarded-For and it's still passing XFF from another source thru - Nothing to urgent since the Deb6 boxes are getting built :) But if you spot something ? Just a typo missing all after the deny . and no value to hard-code into the header on the replace line. This one is tricky to use since you have to hard-code the value passed back, it wont contain the real client IP you want. Amos Yeah, not quite what we are after so squid 3.1.6 will have to do the trick :) Thanks for the time ! Pieter
