Hacker News new | ask | show | jobs
by TrueDuality 2556 days ago
NAT is definitively not a security layer and was never intended as such. You can get better security with a simple stateful ingress firewall (block packets not associated with an established/related connection) which is what most people think of for security with NAT.

The only slight benefit it has imparted is the privacy benefit of hiding multiple devices behind a single address, but they can usually be individually profile anyway.

1 comments

I've heard before that "NAT is not intended as security", but isn't the effect still the same, that an external device can't connect to a device behind NAT without explicit configuration allowing it?
That is generally true, but has weird edge cases. For example using not so specially crafted ICMP packets[1] two hosts each behind independent NATs can communicate with each other without any change to a firewall configuration.

Also honorable mentions: The UPnP protocol & STUN servers

[1]: https://samy.pl/chownat/

For an even cooler trick, check out pwnat, also from Samy: https://samy.pl/pwnat/

Server sends constant icmp pings with fixed payload to unreachable dead Internet IP. Client sends icmp time exceeded message to server containing original fixed ping subpayload, which the server NAT lets through because the payloads match as related traffic. Server then learns client IP and usual chownat udp hole punching tricks apply.

Wow that's insane!
I find this argument to be completely ridiculous, and it’s become remarkably common among those who wish to justify some of IPv6s shortcomings. Whether it was designed to be a security control or not, it is one, and it’s an incredibly important one. Anything that controls how hosts are allowed to communicate with each other is a security control. The argument is so absurd that I literally can’t believe people go around parroting it.
Please explain how NAT without a stateful firewall provides security against what.
It allows you to connect a private network to any other network, including the internet, without allowing hosts on that network access to hosts on the private network. It’s a form of access control. What is your justification for saying that access control measures are not security controls? That is so incredibly contrived.
> It allows you to connect a private network to any other network, including the internet, without allowing hosts on that network access to hosts on the private network.

So, how does it do that?

> What is your justification for saying that access control measures are not security controls?

I am not saying that. It simply isn't an access control measure.

> So, how does it do that?

By rewriting the IP headers of packets as they traverse routing devices. If you’re trying to say that all NAT devices are stateless firewalls, then your point is even more contrived than I first thought.

> It simply isn't an access control measure.

Then why can’t other internet connected devices connect to my internet connected laptop? If I’d connected my laptop directly to my ISP then they would be able to. But I didn’t do that, I connected my home router to my ISP, and I connected my laptop to my home router, which is providing access control for me.

No, NAT does not prevent connections, it only rewrites addresses. If your NAT router also has a stateful firewall, that is what prevents inbound connections, and removing the NAT from that equation does not change that.
The point is NAT is actually a couple of rules in router's stateful firewall, it is done by firewall, and firewall can't do it without explicit configuration. There can't be 'default allow NAT' config.
... which doesn't change that that "default allow" firewall will still pass through all packets, and thus allow access to all your internal devices/machines? Absence of NAT rules does not prevent packets from passing through the firewall, it only prevents rewriting of addresses.
The point you were objecting to was "external device can't connect to a device behind NAT without explicit configuration". Without NAT rules access to internal devices is prevented because packets don't get routed to private IPs.
That just isn't the case, though. A router without NAT and without a firewall (or a combined NAT/firewall thingy with default allow and no further rules) will route packets addressed to "private addresses" just fine. An IP router does not distinguish between "private addresses" and "non-private addresses": As long as there is a route for a prefix in the routing table, the router will route packets addressed to that prefix, and your typical home router most definitely does have a route for your LAN prefix.
So an inbound packet comes in to your NAT and there is no entry for it in the state table. Isn't it then dropped? Isn't that preventing a connection?
Why should it be dropped?

If there is no entry in the state table, then NAT rules are consulted to see whether a new rewrite entry should be added (such as DNAT/port forwarding rules on your home router), and if there is no matching rule either, it simply is forwarded without address rewriting.

Why would it be forwarded? Do you mean that it forwards it to itself, the NAT device addressed by the actual public IP? Wikipedia seems to disagree [0] "if the destination port number of the incoming packet is not found in the translation table, the packet is dropped or rejected because the PAT device doesn't know where to send it."

I am sure a NAT could be configured any number of ways, though, and could probably do anything you want with such packets.

[0] https://en.m.wikipedia.org/wiki/Network_address_translation

> Why would it be forwarded?

Because the device is a router, and that is what routers do.

> Do you mean that it forwards it to itself, the NAT device addressed by the actual public IP?

No, it forwards it to whatever destination address is in the destination address field of the IP headers, because that is what IP routers do.

If it is addressed to one of the NAT device's own addresses, of course, the routing decision would deliver it to the local protocol stack instead of forwarding it, and if there was any service listening on the respective protocol/port, that service would receive the packet (or the TCP stack would respond with a SYN+ACK, or whatever), and if nothing is listening there, the IP stack should respond with either some ICMP error message or possibly a TCP reset or something.

> Wikipedia seems to disagree [0] "if the destination port number of the incoming packet is not found in the translation table, the packet is dropped or rejected because the PAT device doesn't know where to send it."

Well, maybe that is good enough for explaining to a lay audience what a NAT gateway does, because that is what home routers typically will do, because they tend to also have a stateful firewall built in, but it's pretty misleading if you are trying to understand what is actually going on.

> I am sure a NAT could be configured any number of ways, though, and could probably do anything you want with such packets.

Not really, simply by definition: The function of a NAT is the translation of addresses. A router can have many more features, of course, such as a stateful firewall, but the point is that if you only had the address translation functionality, that would not prevent inbound connections, and if you remove the address translation functionality and keep the stateful firewall, inbound connections still aren't possible. Hence, NAT has nothing to do with whether inbound connections are possible, other than that devices that have NAT functionality commonly also have a stateful firewall.