Hacker News Reader

Comment by aidenn0 | Hacker News Reader

When we say "NAT" we are specifically talking about stateful one-to-many NAT implementations as found in consumer IPv4 hardware. Such a NAT is largely isomorphic to a firewall with default-deny semantics for incoming connections and default-allow semantics for outgoing connections.

There are other possible NAT implementations that are much less like a firewall, but saying that a NAT does not provide security is a misunderstanding of the terms as they are used.

Not you specifically, but others in other threads have pointet to UPnP as proof that NATs don't provide security. If the existence of UPnP means that NATs don't provide security, then the existence of PCP means that Firewalls also don't provide security.

View on HN

NAT-PMP, UPnP, PCP, et. all primarily exist because consumer networks that have to share a public IP face more issues than simply opening a port up to the internet. Destination port conflicts, port remapping, discovery of your public IP, are huge fucking headaches that these protocols also assist with.

Given most consumer routers these days can be configured with a mobile app, I could easily foresee a saner alternative where devices could simply ask the gateway if they could open up a port and have a notification sent to a mobile app to allow it.

But, that said, given how many devices are mobile these days I think the benefit of endpoint firewalls shouldn’t be underplayed either.

It's not isomorphic to a firewall, because it doesn't have default-deny semantics for incoming connections.

Think about it for a second. These NAT implementations change the apparent source IP of your outbound connections. How does that block inbound connections? Changing the IP isn't blocking, and outbound connections are the wrong ones.

If a connection comes into your router with a dest IP set to one of your LAN machines, no amount of changing the IPs on your outbound connections will block it.

You literally can't access the internal devices with the NAT implementation on most consumer level router/access points except for packets addressed to the port mapped to an already open connection originating from the inside. This is almost guaranteed to be a random high port. There's no way to access any other port on an internal ip address.

That's equivalent to default-deny.

I think either you're just trying to "well-actually" us or you're confused.

I think understand what GP is saying; if you manage to get a packet to the internet port of the NAT router with a destination IP of e.g. 192.168.0.123, and the NAT router is running a generic IPv4 routing stack, it will dutifully route it to the internal network.

This can be done by compromising another host on the same link. It can also be done if anything on the same link (including the router itself) is running an improperly configured tunneling setup that lets the attacker send e.g. an IP-in-IP packet that gets unwrapped. The NAT has made it much harder to get a packet establishing an inbound connection to the router, but doesn't actually prevent the establishment of a connection should such a packet get there.

Compare to a default-deny firewall with public addresses on the LAN. Any inbound connections will be dropped, by definition; the lack of NAT makes it trivial to get a packet to the firewall itself, but once it's there, it won't get through.

I'm not. You literally can do this, provided there's no firewall. All you need to do is send the router a packet that's already addressed to a LAN machine, and in it goes. "NAT won't translate the packet" doesn't matter if the address is already set to an IP from the LAN.

Most consumer-level routers do have a firewall to prevent it from happening, and if they don't then people describe that router as being "grossly misconfigured" or as having a security vulnerability and similar things, so in practice it'll be blocked. But that's my point: they need the firewall to do the job precisely because NAT doesn't do it.

I said "largely isomorphic" Note:

1. How did a packet with a RFC1918 address reach router; it would require an attacker able to generate packets (or get something to e.g. unwrap an IP-in-IP packet) on the same link, since the router isn't going to ARP any of those addresses. Limiting inbound connections to originate on the same link does provide some measure of security.

2. Will the router even do anything with a packet coming in on the inbound port that doesn't target the public IP? This is implementation dependent.

Reply on news.ycombinator.com