[squid-users] source spoofing without tproxy?

Amos Jeffries squid3 at treenet.co.nz
Tue Jun 13 04:50:45 UTC 2017


On 13/06/17 13:48, David Kewley wrote:
> I want my clients to explicitly address squid as a proxy (not use 
> tproxy), but have squid spoof the source addresses in the forwarded 
> connection, so that further hops know the original source address from 
> the IPv4 headers.
>
> I could find no indication that anyone else has done this, and when I 
> tried various things, I could not get it working.
>
> Is this possible today? If not, is it worth considering as a future 
> feature? Or am I overlooking a reason that this cannot work even in 
> theory?

It is not possible.

No, it is a terrible idea.

It is prohibited by the OS kernel as part of the anti-malware 
protections, in this case to prevent the local machine being used to 
attack its surrounding network nodes. And by Squid to make it harder to 
use Squid as viral payload and damage the brand reputation.


Also, HTTP contains multiplexing and persistent connections. So there is 
no particular relation between one incoming/client connection and the 
outgoing/server connection(s) the traffic from that client goes out on. 
Added to that, a client request may generate multiple outgoing requests 
of various types, or Squid may itself generate traffic for its own needs 
without any client interaction.

So doing this just degrades the proxy performance. And not in a small 
way - intercepted traffic pinning everything as this would need comes 
out about 10% nominal (90% reduction), and at the extreme end proxies 
with NTLM going through to an origin see only 1% of nominal performance. 
Nominal for me being what I clocked a big clients network doing in 
real-world traffic a few years back: ~20000 requests per second a few 
years back (Squid Project got approx 2x that in controlled lab tests).

>
> I got the nearly-equivalent functionality working for reverse proxying 
> using nginx, but so far I've found no way to do it with forward 
> proxying. Nginx doesn't do https forward proxying (no handling of 
> CONNECT).

So Nginx can be used to attack networks from inside. Good no know we now 
have to watch out for that in viral payloads too.

>
> If squid can't do what I'm looking for today, I would welcome pointers 
> to other possible approaches.

Squid supports X-Forwarded-For fully - it was invented by Squid devs 
back in the day, and Squid is still the authoritative implementation for 
how it is supposed to work. As an old feature just about all other HTTP 
server and intermediary software have support for that too so you should 
have no issue pulling the data out at the receiving end, or in HTTP 
processing DPI software / firewalls etc. It is sent on all outgoing 
Squid messages unless you explicitly configure something else to happen 
with the forwarded_for directive.
  <http://www.squid-cache.org/Doc/config/forwarded_for/>


There is also newer HTTP "Forwarded" header which supercedes 
X-Forwarded-For and some very newly written servers might only support 
that. Squid lacks the built-in support for that directive so its no good 
on received traffic. But if you have to it can be sent to an upstream 
server fine with the request_header_add directive, like so:
   request_header_add Forwarded for=%>a


HTH
Amos



More information about the squid-users mailing list