On 15/12/10 22:27, David Gubler wrote:
Hi Amos, thanks for your response!
Be careful, very very careful. ESPN is the example of the month for doing
this badly. Their site refuses to open for anyone browsing from a host
with
local proxy installed.
Thanks for the warning. I'll try it with a proxy server before putting
this into production.
I could configure the Squid's IP address on Apache. But this is
undesirable, because Squid is running on EC2, its IP may change, and
further EC2 instances can come and go.
The ONLY way to trust its contents is to verify that the listed
content is
correct, individually IP by IP starting with the machine directly
connecting to supply it. If you can't track exactly where the proxy
*is* in
cyberspace then you cannot trust anything sent. XFF ACL tests will accept
any ACL criteria that version of Squid can take.
I do not fully understand what you mean here, but I'll try to answer
anyway:
All the reverse proxy servers will be run by us, so I consider them
trusted. But since Amazon does not provide availability guarantees or
stable IP addresses and load may change, we might have to add or remove
instances on the fly. I'd like to have a system that can handle this in
a robust way (reconfiguring Apache doesn't count as robust, too much
room for errors).
I was thinking, if the rDNS of the dynamic EC proxies are set correctly
to produce something in your company domain. Your follow_x_forwarded_for
ACL tests could use the srcdomain or srcdom_regex ACL type to authorize
trust without knowing the actual IP assigned.
Better, Squid can send Basic auth login credentials in the
Proxy_Authentication: header. squid-3.2 adds Negotiate auth protocol to
this for more secure logins.
Hmm, that sounds like exactly what I was looking for! Why couldn't I
figure this out by myself...?
Noting that XFF contains a ', ' delimited list. These rules may not work
as intended.
I'm using the
header_replace X-Forwarded-For
directive. If I understood it correctly, it should clear any existing
X-Forwarded-For headers, and Squid has no reason to add more than one IP
here, so I think it should be fine.
"forwarded_for truncate" replaces the entire header with only the
immediately connected client IP. The docs appear to be wrongly stating
squid uses its own IP, fixing them now.
The IP may still be "unknown", IPv4 or IPv6 clients.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.9
Beta testers wanted for 3.2.0.3
