[squid-users] source spoofing without tproxy?

[David Kewley]

Thanks for your reply, Amos.

On Mon, Jun 12, 2017 at 9:50 PM, Amos Jeffries <squid3 at treenet.co.nz> wrote:

> 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.
>

What exactly is the "it" that you're saying is prohibited by the OS kernel?
Source spoofing alone, or something else?

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).


Good to know there are strong performance implications, thanks. I don't
understand these systems deeply enough to have anticipated this, so I
appreciate the heads-up. Too many systems to learn, too quickly...

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.


"Can be used to attack" because of source spoofing, or something else?

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/>
>

I'll ask the team managing the next-hop device to evaluate that
possibility; it looks to me from the docs like it might work. Thanks for
the suggestion.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170612/00e27b48/attachment-0001.html>