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@xxxxxxxxxxxxx
<mailto:squid3@xxxxxxxxxxxxx>> 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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
