[squid-users] source spoofing without tproxy?

[David Kewley]

On Tue, Jun 13, 2017 at 3:15 AM, Amos Jeffries <squid3 at treenet.co.nz> wrote:

> On 13/06/17 18:14, David Kewley wrote:
>
>> 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/>
>>
>
I was aware of at least most of those issues, though I'm not an expert on
them. So the reference is useful, thanks.

Our squid server will only accept connections from its internal IP spaces,
and I only wanted it to spoof the actual client source IPs to make
downstream decision making easier based on the IP headers (but
X-Forwarded-For might be sufficient, as you pointed out). Also the actual
egress point to the internet is a NAT device that always uses its external
IP as the source IP. So I see zero risk of us leaking foreign spoofed
source IP addresses.

I will take a look at our ingress filtering to make sure we're rejecting
external inbound packets claiming to be from our internal network.

Do you see anything obvious I'm missing around what I should do for BCP38?

I'm taking seriously your warning about a significant performance impact.
I'll be curious to see if similar issues impact our nginx reverse proxies
that spoof the original source IP in the proxied connection. Makes sense it
might.

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


Thanks! I'll come back to you if I think that might be useful. For now I'll
proceed with using squid in a more normal fashion, and work with the owners
of our next-hop-device about using X-Forwarded-For for any decision making.

I will proceed assuming that squid will never support the sort of spoofing
I was hoping for (since it would probably simplify things greatly for us),
even though I believe in our design that spoofing would have been safe.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170613/1970d282/attachment.html>