Re: [squid-users] Host header forgery policy

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 15 Jul 2014 18:46:43 +1200

On 15/07/2014 6:23 a.m., Edwin Marqe wrote:
> Hi Eliezer,
>
> I understand that, but this is pretty much the point of my e-mail. In
> my company we don't work with servers installed physically here,
> instead, we rent servers to a company. We use 2 nameservers for our
> clients, and the IT company uses others and additionally they don't
> allow to change them and they're restricted to their net... So I don't
> know what else can I do.

If there is a fully controlled routing path between your and the
suppliers networks you can arrange for policy routing to route the port
80 packets to their proxy where the NAT can happen.

Otherwise you require some form of tunnel over which the packets can be
transferred without altering the IP level address:port details on the
packets. GRE, VPN, stunnel, ssh are the four common methods of doing that.

(NP: I have just updated the Host forgery wiki page to mention tunnels
as alternative to policy routing, sorry that was an oversight).

I also have an experimental patch underway to support the Haproxy
designed PROXY protocol. If you can convince the supplier to patch their
Squid proxy with it you could setup a haproxy on your network to do the
capture and relay through them.

>
> We don't have a specific configuration for the google.com DNS entry,
> so I don't really know why Squid says it's pointing to a local
> address.

Because you are using NAT on the packets. DNAT re-writes the
destination-IP:port to the ones you select.

Squid on a remote box has no access to the kernels internal NAT table of
the machine doing the NAT. That is required to identify that this was
actually a NAT'd packet, and what the original details are.

Therefore to avoid the security vulnerability we must assume that the
destination IP is correct (its not) when validating. Squid acts
"transparent" and connects to that IP whenever Host fails to validate
(which it always will in this case) so that at worst the client can
still get through to where it would connect without Squid having done
anything. N your case that means connecting to itself ... and things barf.

Amos
Received on Tue Jul 15 2014 - 06:47:03 MDT

This archive was generated by hypermail 2.2.0 : Tue Jul 15 2014 - 12:00:08 MDT