Comment by tptacek
12 hours ago
This has been gospel among snooty network engineers for decades, but NAT was initially introduced to the wider market as a security feature, and it is absolutely a material factor in securing networks. The network engineers are wrong about this.
(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
I would never debate NAT was marketed as security (as marketing is often detached from the reality of what's being sold) but I'd be interested why it's a material factor in securing networks independent of the stateful firewall mentioned, which most seem to actually rely on. The "snooty" people probably mean less what may have been marketed to consumers and more what the standards which introduced it say. E.g. https://www.rfc-editor.org/rfc/rfc1631 notes address depletion and scaling as drivers in the opening but the only mentions of security are later on in how NAT actually makes security more difficult.
I.e. it would seem whatever argument could be made about security from NAT, poor or not, intended to be security or not, would be immaterial in context of stateful session tracking with outbound originate allowed alone w/o doing the NAT on top anyways.
It was more than just "marketed" as security. It was brought to market as a security product and used that way for many years, before address depletion was a meaningful problem. People used NAT firewalls back in the eras of routable flat class-B desktop computer networks.
The first commercial NAT box was the PIX in 1994, which featured stateful session firewalling (not just NAT) in agreement with the above 1994 RFC. It was still the era of referring to classful networks, but I'm able to source documents from the time which state the opposite of your claims.
Here's an ad for it from Jan 1995 https://www.jma.com/The_History_of_the_PIX_Firewall/NTI_file.... Note by the 3rd paragraph it's saying
> corporate networkers are free to expand and reconfigure their TCP/IP networks without agonizing over the much publicized IP addressing crunch. It also spares them from having to upgrade all of their host and router software to run IP version 6
It does end with the aforementioned security marketing making it sound like NAT is what provides security on the PIX:
> PIX also increases network security. 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.
> And what about hosts that should be recognizable from the Internet, such as mail servers?
> These either can be directly attached to the Internet and assigned a public address or can be attached through PIX. In the latter case, the translator is configured to map one of these external addresses to the device not just for the duration of the application session but on a permanent basis.
Looking past the marketing line and reading the manual, the reality was the PIX was always acting as a full stateful firewall and did not just rely on NAT itself to provide the inbound filtering. See the "PIX Firewall Adaptive Security" section on page 2 of this 1996 manual I managed to dig up as reference https://mail.employees.org/univercd/Nov-1996/data/doc/netbu/.... Rule hits that missed a state match were even loggable (what a box for the time!)
Whether people saw the marketing and assumed it was NAT that provided security is precisely the bad assumption the article talks to, but at no point in history was NAT prevalent without being paired with a normal stateful firewall to provide the security - since the intent of NAT was not to fill that role, even in the beginning, as sourced by 3 references now vs your personal claims.
17 replies →
The principle difference, IMHO, is that it makes the security visible. My home cable router has NO firewall configuration at all. Supplied by my ISP and woefully deficient in absolutely all respects. I can't (for example) configure It does have a configuration for forwarding IPv4 ports to inside machines; but none for forwarding IPv6 ports. Does it have stateful filtering of IPv6 ports? I'd like to think that it does, but if so there is no visible evidence that it does.
This is one of those occasions where people are arguing semantics, and you're like "but -- I was there!"
My first cable modem did not have a NAT, nor did my first ADSL modem. You'd use "Internet Connection Sharing" on Windows 98 SE to share the internet connection on your LAN. And you'd get badly hacked, and then also install a firewall. Sygate had a firewall and NAT combined. (Or, you'd use linux - and also get badly hacked, but for different reasons.)
As a response, ISPs started to ship modems with built-in NATs. They did not start to ship what we now call routers (modem+NAT) because they wanted to encourage people to share their internet connections out of the goodness of their hearts. They'd prefer to sell more cablemodems, or dial-up. They started shipping (NATted!) routers because it saved them a lot of support calls from hacked (and disconnected) customers. Instead they got support calls about port-forwarding, so uPnP was the next hot feature.
Was NAT originally intended to be a firewall? No. Did it effectively protect many innocents? It did. Is it still needed as an additional layer of security-through-side-effects? Let's hope not.
NAT isn't security at all, good or otherwise. If it was sold as such, then the people selling it were giving out inaccurate info. But just because some people wrongly said that NAT provides security back in the beginning doesn't somehow make those claims true today.
NAT absolutely does provide good security. It denies all incoming traffic that is not part of an established connection.
Of course, that can be accomplished trivially without NAT. It can be done in IPv4 and in IPv6 with the simplest of routing rules.
So there is nothing about a lack of NAT in IPv6 that makes it less secure.
But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it.
The router will then do exactly the same thing it would've done if no NAT was involved at all: if the dest IP in the packet is the router itself then the router will accept or refuse the connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.
It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.
3 replies →
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.
[dead]