[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