[squid-users] source spoofing without tproxy?

[Amos Jeffries]

On 13/06/17 18:14, David Kewley wrote:
> Thanks for your reply, Amos.
>
> On Mon, Jun 12, 2017 at 9:50 PM, Amos Jeffries <squid3 at treenet.co.nz 
> <mailto: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?

The "it" that was the subject of your question "it" - spoofing.
>
>     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?
>

Directly because of source spoofing, or equivalent if you got it sending 
from any non-local IP address. "local" meaning an IP address explicitly 
assigned for use by the machine the proxy runs on.

This might be of help if you are not already aware of the risks and 
issues involved with spoofing and handling of non-local IPs; 
<http://www.bcp38.info/>


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

That would be best if it works.

I came up with a bodgy workaround using NAT after sending the earlier 
mail. So if there is no other way than delivering the client-IP on the 
packets there is still something that might be done. But, that would 
still run up against HTTP multiplexing and also add all sorts of NAT 
related issues as well. So only a last resort really.

Amos