NAT66: The good, the bad, the ugly(mcilloni.ovh)
mcilloni.ovh
NAT66: The good, the bad, the ugly
https://mcilloni.ovh/2018/01/20/oh-god-why-NAT66/
15 コメント
> I think it still belongs between the internet and most networks made entirely of desktop, IoT & personal devices.
I think your belief has been shaped by the fact that adoption of P2P protocols was hampered by NAT for over a decade, and that developers often write software that trusts the local network. Default deny policies help protect insecure servers for the time being, but I'd like to see servers that utilize encryption and authentication instead of relying on simple allow all/disallow all firewall policies at the connection level.
I think your belief has been shaped by the fact that adoption of P2P protocols was hampered by NAT for over a decade, and that developers often write software that trusts the local network. Default deny policies help protect insecure servers for the time being, but I'd like to see servers that utilize encryption and authentication instead of relying on simple allow all/disallow all firewall policies at the connection level.
> developers often write software that trusts the local network
Yes, this is still a source of problems - DNS rebinding allowing websites to attack random sockets on LAN and localhost makes my skin crawl. That the protections are being implemented in the browser makes me sad.
> I'd like to see servers that utilize encryption and authentication
Me, I'd prefer architectural solutions further down the stack than /every single service/ that happens to benefit from a TCP control socket having to duplicate the work of encryption + authentication, with the attendant myriad opportunities for it to go horribly wrong. I already mentioned IoT and we know exactly what that's like when it comes to protecting itself.
Yes, I know, pipe dream .. and going off topic .. but I can wish.
Yes, this is still a source of problems - DNS rebinding allowing websites to attack random sockets on LAN and localhost makes my skin crawl. That the protections are being implemented in the browser makes me sad.
> I'd like to see servers that utilize encryption and authentication
Me, I'd prefer architectural solutions further down the stack than /every single service/ that happens to benefit from a TCP control socket having to duplicate the work of encryption + authentication, with the attendant myriad opportunities for it to go horribly wrong. I already mentioned IoT and we know exactly what that's like when it comes to protecting itself.
Yes, I know, pipe dream .. and going off topic .. but I can wish.
The author's life would be a lot easier by switching to a better VPS provider.
Which VPS providers would you suggest for proper IPv6 support? Thanks!
As others have mentioned, Digital Ocean and Linode would probably be good options here.
If you're looking for something even smaller and cheaper than $5/mo, I've had luck with BuyVM. They've very cheap, have good customer support, a nice panel, and you get an entire /64.
If you're looking for something even smaller and cheaper than $5/mo, I've had luck with BuyVM. They've very cheap, have good customer support, a nice panel, and you get an entire /64.
Linode. Its in enough places it can be local to you, it has the beginnings of a machine deployment method which can go into kubernetes if you want, it does true IPv6.
I use Linode for work, and a local provider (binary lane) with a /56 for personal at $10 a month or less each.
I use Linode for work, and a local provider (binary lane) with a /56 for personal at $10 a month or less each.
Maybe Digital Ocean? Vultr? I don't really follow the VPS market.
Both will give your VPS a "home" IPv6 address, but if you also expect to receive an IPv6 prefix/subnet, DO only gives you a /125 per VPS (8 IPs). I moved my VPN nodes to Vultr for that reason; they give you a /112 (65K IPs) per VPS.
Neither DO nor Vultr actually routes the assigned prefix to your VPS, so you have to run something like ndppd [1] to answer NDP queries for IPs in the IPv6 prefix you've been assigned if you want the local router to send your VPS any traffic on those addresses.
[1] https://github.com/DanielAdolfsson/ndppd
Neither DO nor Vultr actually routes the assigned prefix to your VPS, so you have to run something like ndppd [1] to answer NDP queries for IPs in the IPv6 prefix you've been assigned if you want the local router to send your VPS any traffic on those addresses.
[1] https://github.com/DanielAdolfsson/ndppd
It's actually a /64 at Vultr.
My DO control panel says /124
tilaa.com and vultr spring to mind. I'm using them with IPv6 and it work's relatively flawlessly with tilaa.
I've often seen criticism that "NAT is not a security boundary" etc., but never seen them explained.
How is putting your network behind a NAT different from a stateful firewall set to deny inbound connections (and allow outbound and related ones)?
How is putting your network behind a NAT different from a stateful firewall set to deny inbound connections (and allow outbound and related ones)?
It's different because not only does it deny inbound connections, it breaks the end-to-end principle[1] of the internet. You can have the security boundary without NAT by using a firewall, so if that's all you want, don't use NAT.
1: https://en.wikipedia.org/wiki/End-to-end_principle
1: https://en.wikipedia.org/wiki/End-to-end_principle
NAT66 is also used frequently used for multi-wan egress load balancing.
It bugs me when this dogma gets repeated without further explanation, /particularly in the case of IPv6/. No, NAT probably doesn't provide as much security as you think it does, but it does provide benefits. A NAT network is a default-deny-incoming network that cannot fail open, protecting against common boundary firewall configuration errors. A small (but once very pervasive) class of firewall bypass attacks (fragmentation) is eliminated. Obscuring information about the number of devices, and especially (IPv6) their vendors is beneficial. When (inevitably) a bug in your firewall is discovered by bad guys, the presence of NAT limits the kinds of attacks they can make. In the world of IoT, These Things Matter.
It's commonly phrased "NAT is not a security feature, firewalls are", which is midly nonsensical as NAT is a firewall feature .. one which often improves the security posture of the network. Of course there are places you absolutely don't want NAT, but I think it still belongs between the internet and most networks made entirely of desktop, IoT & personal devices.