Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IPv6 is not insecure because it lacks a NAT

johnmaguire.me

Post reply on HN
Print view View original

521–530 of 606 posts

Re: IPv6 is not insecure because it lacks a NAT

#521

Post by theamk »

NewJazz wrote: post #466
theamk wrote: post #425

Earlier quoted context omitted.

Only in IPv6 world... in IPv4, it's all safe

Nope, iproute can still show your Mac address. And a curl ipinfo.io can show your public v4 address.

Mac address is absolutely safe in IPv4 world - the only info it gives is the network card manufacturer.

And people don't usually share "curl ipinfo.io" output unless they plan to share their external IP (unlike "ifconfig" output, which is one of the first things you want to share for any sort of networking problems)

Re: IPv6 is not insecure because it lacks a NAT

#522

Post by kortilla »

Dagger2 wrote: post #464
kortilla wrote: post #176

Earlier quoted context omitted.

That makes no sense. If a packet comes into a public IP to a session that doesn’t exist, there is nowhere to forward the packet onto. The public IP belongs to the router. If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.

There's always somewhere to forward a packet to. The router looks at the dest IP field in the packet header, and that's where it goes. > If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet. This is generally going to be true, but it's not relevant to how NAT behaves when it receives inbound connections.

I’m not sure you understand how NAT implementations work.

I recommend you setup a basic iptables NAT set of rules on linux to reflect what a home router does (masquerade) with ip forwarding enabled.

The inbound packets from the internet are to a public IP that belongs to the device performing NAT. If there is no entry in the conntrack table from a connection to translate that public IP to a private IP, there is nowhere it can be forwarded to. It’s already at the device that owns that destination IP.

Even if it spit the packet out a private interface (which makes no sense given the routing table), the destination IP would be a public IP that both cannot be ARPed for on the local network and will not be honored by any private device.

Re: IPv6 is not insecure because it lacks a NAT

#523

Post by fulafel »

vlan0 wrote: post #359
deng wrote: post #294

Before you engage in discussions, may I suggest to look into RFC 4787, especially section 5 about filtering behaviors of NAT: https://datatracker.ietf.org/doc/html/rfc4787#section-5 Several things can be correct at the same time: * NAT is not a firewall * NAT can still filter traffic (and practically always does) * NAT can hence still provide security features * The real world often does not care about original defin…

And if I think back to my 30 years of IT, environments with NAT end up with lazy engineering from systems and application folks. It doesn't provide an environment that forces folks to understand their problems holistically. Thus, relying on perimeter firewalling and NAT as a large catch all. It's a bad security practice imo

Yep, rfc19188 addressing leads to accumulating complexity due to workarounds (end-to-end addressing is simple, there are very good reasons for that design), addressing ambiguity, and various practical security problems.

Re: IPv6 is not insecure because it lacks a NAT

#524

Post by kortilla »

Dylan16807 wrote: post #201
kortilla wrote: post #175

Earlier quoted context omitted.

> Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device. This is a security feature ad, nothing else. And it’s 100% because of NAT, not anything else in the PIX feature set.

That came up earlier and I know it's a gray area but I agree with the idea that a line tossed into the marketing and not backed up by the manual weakens the importance. The firewall in the PIX is the security workhorse. Also that sentence implies you can get a connection to a device, you just know less about which one it is. Is that really a meaningful security feature? To the extent that connections are actually blo…

No, you cannot get a connection to the device. It’s an un-routable block of RFC 1918 addresses.

Re: IPv6 is not insecure because it lacks a NAT

#525

Post by kortilla »

fsh wrote: post #172
kortilla wrote: post #158

Earlier quoted context omitted.

> NAT is not for security, it does not provide security. It’s not for security but it absolutely does provide security and pretending otherwise continues to harm discussions. I have a pile of ipv4-only IoT devices that have no firewalls of their own that are being protected by the symmetric NAT in my home router. Kick and scream all you want but there is security there and nothing on the internet can reach those devi…

If you really don't have a stateful v4 firewall, your ISP can happily connect to all of your devices.

I don’t think you understand symmetric NAT. Requiring an entry in the port address translation table to propagate a packet is not the same thing as a stateful firewall.

You absolutely can have a port address translation implementation without a stateful v4 firewall that wouldn’t forward packets destined for inner IPs on the outer interface. Just put an ACL on the external interface to not allow traffic to the inner IP block.

Re: IPv6 is not insecure because it lacks a NAT

#526

Post by kortilla »

bandrami wrote: post #272
ErroneousBosh wrote: post #225

Earlier quoted context omitted.

How do they manage that?

If your public IP from your ISP is 12.13.14.15, and your internal block is 192.168.0.0/24, then your ISP can send a packet to 12.13.14.15 destined for 192.168.0.7, and without a firewall your router will happily forward it. An attacker who can convince intervening routers to send traffic destined for 192.168.0.7 to 12.13.14.15 (and these attacks do exist, particularly over UDP) can also do that.

No, the router will only forward it with specific implementations that don’t isolate routing tables between the external and internal. Or an easier approach is just a stateless ACL on the external interface. Neither are a stateful firewall.

Re: IPv6 is not insecure because it lacks a NAT

#527

Post by kortilla »

Dagger2 wrote: post #476
sedawkgrep wrote: post #337

Earlier quoted context omitted.

yeah but the likelihood of this is incredibly remote. It would shock me if ISPs didn't have alarms going off if RFC1918 space was suddenly routable within their BGP table. Not to mention the return packet would be NAT'd so the attacker would have to deal with that complication.

The return packet wouldn't be NATed, because stateful NAT tracks connections and only applies NAT to packets that belong to outbound connections. Arguing over how likely this is is missing the point. If it can happen at all when you're running NAT, then it should be clear that NAT isn't providing security.

“if it protects 99.999% of attackers from reaching you but not this one specific attacker in this one case of misconfiguration, it’s not providing security”…

Dude, that’s a really shitty take and this is why people that do care about security end up ignoring advice from anyone who thinks this way.

You’re in the camp of “don’t use condoms because they can break”.

Re: IPv6 is not insecure because it lacks a NAT

#528

Post by tsimionescu »

Dagger2 wrote: post #493
tsimionescu wrote: post #485

Earlier quoted context omitted.

So, assuming the router doesn't have any server running, the connection will be reset, thus protecting all of the machines behind the router from any incoming connection, almost exactly like a firewall (sure, a firewall might just drop the packet instead of responding with a RST). So, in other words, NAT alone can act like a security perimeter, even with no firewall present.

How does the router rejecting a connection to the router protect the machines behind the router? That doesn't make any sense.

Because no one on the Internet can reach my 192.168.0.7 machine if the NAT router doesn't translate the packet. And the NAT router won't send a packet that arrives with its public IP as dstIP to any machine behind it, unless the port its ports correspond to an open connection, or to an explicitly forwarded port.

Re: IPv6 is not insecure because it lacks a NAT

#529

Post by tsimionescu »

Dagger2 wrote: post #494
tsimionescu wrote: post #486

Earlier quoted context omitted.

The machine that has the NAT's external IP to it is, well, the NAT, by definition. So you admit that the NAT box will act almost exactly like a connection tracking firewall, even if only NAT is enabled.

No, I'm not going to "admit" that, because I know full well that it won't. It's not like I'm sat here thinking "I know it does block traffic, but I'm going to lie to everyone that it won't". NAT in fact, actually, really and honestly, doesn't block traffic, and I think I've been pretty consistent in saying as much.

You've been consistently wrong, yes. A NAT router box will NOT translate a packet coming from the Internet (so, a packet with a globally routable IPv4 address) arriving on its WAN to the RFC1918 IPv4 address of any box sitting behind it on the LAN side, unless it is arriving on a previously open connection, or on a port the user explicitly asked to be allowed and forwarded - exactly the same behavior of a regular stateful firewall.

Re: IPv6 is not insecure because it lacks a NAT

#530

Post by tsimionescu »

benlivengood wrote: post #491
tsimionescu wrote: post #469

Earlier quoted context omitted.

And if you have only the first line, what will happen if someone sends a request to the NAT's external IP on some random port?

Without at least some filtering a Gateway NAT appliance is vulnerable to: * LAN IP address spoofing from the WAN * Potential for misconfigured "internal" daemons to accept WAN traffic (listening on 0.0.0.0 instead of the LAN or localhost) * Reflection amplification attacks

LAN IP address spoofing is indeed a valid attack vector, if the ISP is compromised.

Internal daemons on machines other than the router itself in the LAN network listening on 0.0.0.0 are not insecure (unless you have the problem from point 1, malicious/compromised ISP). The router won't route packets with IPs that are not in its LAN to them. Of course, the router itself could be compromised if it accidentally listens on 0.0.0.0 and accepts malicious packets.

Not sure what you mean by reflection amplification attacks, but unless they are attacking the router itself, or they are arriving on WAN with LAN IPs (again, compromised/malicious ISP), I don't see how they would reach LAN machines.

Post reply on HN