On Tue, Jun 13, 2017 at 3:15 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
