NAT of course is not the best solution ever, but vast majority of currently used network nodes do not need publicly routed IPs in a limited global space. If anything, many of them are much better without one. Yes, I know, firewalls. But why not just avoid the issue by not having publicly accessible address for non-public systems in the first place?
Because NAT is an abominable hack with significant technical and administrative overhead.
My home is not intended to be a public space. But, it has a unique address, just like any other bar or restaurant in the area. Being able to locate it with a unique identifier is valuable, even if I don't intend for my living room to be publicly accessible.
> Because NAT is an abominable hack with significant technical and administrative overhead.
Agreed. But you can use private networks without NAT. In fact, 99% of traffic in the private network doesn't need NAT. Only outside traffic does, and only that which can't use proxies etc. - which is pretty small amount of overall traffic, I think.
Particularly notable example of this is that the three ip6tables rules needed to get NAT-like everything out nothing out behavior are exactly the same three rules that you need in v4 iptables for the NAT to have any security effect at all.
And how is NAT not added security by default? By default it drops everything incoming, no? (I mean, theoretically NAT doesn't, but [almost] every practical implementation situations means that there's no possible automatic internal-external address correspondence, otherwise you wouldn't need the NAT.)
A NAT doesn't drop anything. A NAT translates. A firewall drops.
If you only have a NAT, your ISP (or anyone who has compromised their router, or possibly simply your neighbour when ISPs occasionally fail to isolate their customers on layer 2) still can send you packets addressed directly to your "internal" addresses. The only thing that actually helps is a stateful firewall. And when you have that, the NAT does not add anything security-wise.
NAT and "internal addresses" is as much a security mechanism as not telling anyone that there is a room called "living room" in your house. If you want to prevent strangers from getting into your living room, you don't use internal names for your rooms, you install a lock on the door.
By default a NAT is unconfigured, so it doesn't know what to translate into what. The usual practical deployment consists of a dynamic outgoing NAT setup and UPnP. So outgoing TCP/UDP/etc protocols are snooped and the incoming packets are translated accordingly. (Hence the UDP NAT hole punching technique.) This setup works well for SoHo sites.
In this case without knowing my egress traffic, any incoming packet will be dropped by the NAT middlebox/facility/software/device/module/thing. So NATs do drop. And nice ones emit ICMP or TCP RST too.
> The only thing that actually helps is a stateful firewall. And when you have that, the NAT does not add anything security-wise.
Yes, indeed. That's a different threat model though. And I agree that hosts should have a default deny ingress policy.
Yet NATs do work wonderfully for SoHo networks. And of course a stateful firewall is just as easy to fool (circumvent) with a back-connecting connection as a NAT.
And a NAT as described above or a stateful firewall that enables local network functions such as CIFS/SMB were just as vulnerable to the usual Blaster-type worms/malware.
Again, of course, usually things go hand in hand. Firewalls usually have SNAT/DNAT capabilities, and SoHo shitboxes come with too much of every kind of NAT/firewall thingies already.
And, I know the misery of interconnecting two internal networks both using the same 192.168.0.0/24 or whatever prefix, so I can't wait to get rid of this and move to proper v6. But the fact of life is that the typical NAT setup was very convenient for ticking the local network ingress security checkbox for ISPs for years (decades).
> In this case without knowing my egress traffic, any incoming packet will be dropped by the NAT middlebox/facility/software/device/module/thing. So NATs do drop.
No, that is the firewall, or simply the IP stack of the device, not the NAT. A NAT only translates. In your typical home setup, it will track connections coming from the LAN side and translate the source address of the connection to the public address, and then match packets of the same connection in the opposite direction and translate them back. If there is a packet coming in on the WAN side that does not match any known connections that are being translated, the packet is simply left unmodified by the NAT. If it happens to be addressed to the public adress of the gateway, it will then be passed to the higher layers of the IP stack of the gateway where it might be delivered to some TCP or UDP socket or who knows what other stuff that is running on the device and using IP--and if the IP stack cannot find any applicable socket to deliver it to, it might respond with the appropriate ICMP error or TCP reset or whatever. If the packet is not addressed to the gateway's public address, it will simply be forwarded to wherever the routing table says--if it's addressed to an address from the LAN range, it will be forwarded to the LAN.
A NAT without a firewall does not drop packets. A NAT only translates addresses of packets belonging to connections it is configured to translate, everything else is left untouched. If there is no firewall in addition to the NAT, it will not prevent inbound connections from the WAN side to the LAN side.
> But the fact of life is that the typical NAT setup was very convenient for ticking the local network ingress security checkbox for ISPs for years (decades).
Well, the real fact of life is that tons of supposed network professionals think that, and then potentially deploy a pure NAT setup that allows unlimited access to the LAN from the ISP's router and possibly other customers of the ISP when the ISP fails to properly isolate customers on layer 2 because of the completely baseless assumption that a NAT prevents inbound connections.
This is largely theoretical now, as there's a single bit difference in definition (or implementation) of a NAT. (Leaves unknown untouched, or drops them.) But you are right, that thinking of a NAT as a pure transformer that cannot drop packets results in a better model.
> deploy a pure NAT setup
Is that even possible? I mean, sure, get a PC with 2 NICs and use raw sockets, but with a simple off the shelf network gadget?
> This is largely theoretical now, as there's a single bit difference in definition (or implementation) of a NAT. (Leaves unknown untouched, or drops them.)
So ... any distinction between two different things is a single-bit difference and therefore largely theoretical? I am not sure I follow ...
> But you are right, that thinking of a NAT as a pure transformer that cannot drop packets results in a better model.
Which is the important point, in particular in this context where the common argument essentially is "because I consider dropping packets a function of a NAT, NAT is good to have", where the whole argument only hinges on the definition, not on any real-world facts about network devices.
> Is that even possible? I mean, sure, get a PC with 2 NICs and use raw sockets, but with a simple off the shelf network gadget?
I don't know, I have never investigated that, as I don't tend to use off the shelf network gadgets. However, there is no need to use raw sockets, just install Linux and use the kernel's netfilter, which behaves in exactly that way: If you only configure NAT rules but no filtering rules to prevent inbound connections, your LAN is wide open. And that is not bad design, that is the obvious way to implement this as a matter of separating concerns.
Now, Linux is (was?) a popular OS for off the shelf home routers, and some of them at some point even use(d?) netfilter for their NAT. If you consider what kinds of completely moronic security holes have been and still are being found in those kinds of devices (shell injection in the web interface, trivial buffer overflows, backdoors with hard-coded passwords, ...), that does not make me particularly optimistic that they are careful when putting together the actual network setup on those devices. Not configuring the filtering of inbound connections is exactly the kind of mistake that I would expect to happen in an environment that produces that kind of garbage: Unless you are competent and do invest in quality assurance, that is exactly the kind of problem that noone will notice, as it does not affect day-to-day operation, and noone in the target market will notice if you screw it up because even the supposed experts think that the NAT implies that they are safe.
I suspect other network stacks or even ASICs have similar separation of concerns in order to be usable for a broader market than "home routers", so I suspect you can make the same mistake on other platforms used for implementing home routers.
So, do I know that there are devices out there that do NAT but don't filter? No. Would I be surprised if there were? No, definitely not.
However, if you do away with NAT, that makes it much more likely that a home router lacking a filter wouldn't go unnoticed for long, because it's trivial to check whether it does filter or not. So, it's not only that NAT does not logically imply a firewall and that a firewall does not necessitate NAT, but that not having a NAT makes it actually more likely that your device does in fact have a firewall.
I think the most productive way to look at it that for NAT/NAPT/cone NAT to work, a necessary prerequisite is a default-deny inbound firewall policy and stateful connection tracking.
Once you have that, layering on NAT is possible. But the security implications were already addressed before you get to that point.
> NAT does nothing meaningful securitywise that a firewall cannot achive
One good thing about NAT is even if you screw up the firewall config, such as configure everything in "allow all" mode, your internal network is still secure, because private IPs are not routable at the Internet level.
