I'll note that it's not this decision is not coming from the newspaper article's writer, it's coming from any common transliteration of the manuscript that you'll find. But it's clearly a transliteration decision made because the people doing this assume it is an interjection, and they're using modern punctuation rules accordingly.
> No. It isn't. And if you enable NAT without firewall rules, it will happily expose your internal network to external actors. In fact, that's the whole point of NAT.
How exactly would a regular NAT implementation, such as s consumer router's NAT, remove security compared to a direct connection? Assuming there is no port forwarding configured, the NAT will drop (or NACK) any packets addressed to the router's IP on any port that doesn't correspond to a currently open connection.
Since the machines behind the NAT have RFC1918 addresses, remote actors will not be able to send a packet to them, other than by sending packets to the router's IP.
So, overall, a NAT box with no firewall rules configured still acts like a stateful firewall for remote attackers. It's true that attackers that have access to the WAN port of the router, such as someone infecting your ISP, can still send traffic directly to the RFC1918 addresses behind the router, and the router would deliver them (whereas with a firewall, those would also get dropped). So a firewall is still preferable, but the difference in security is actually quite low.
> In fact, not using IPv4 NAT is enormously more secure than using IPv4 NAT, assuming you're using RFC1918 addresses internally. Primarily because non-NATted RFC1918 addresses won't be forwarded by routers on the Internet (CGNAT notwithstanding).
This statement makes no sense. If you are not using NAT of some kind, and your machines only have RFC1918 addresses, then your machines can't access the Internet at all. Now, sure, that is quite secure - but you can get the exact same security by disconnecting the WAN port of the router, with the exact same effects - so this is quite irrelevant to the use-cases being discussed.
>How exactly would a regular NAT implementation, such as s consumer router's NAT, remove security compared to a direct connection? Assuming there is no port forwarding configured, the NAT will drop (or NACK) any packets addressed to the router's IP on any port that doesn't correspond to a currently open connection.
No one (at least not me) said anything about a "direct connection" (which I assume means using globally routable IPv4 addresses on your internal systems).
Nor did anyone say anything about not forwarding any ports. In fact, much of the discussion has been about how "secure" NAT is when forwarding ports, with some folks claiming that doing so is all you need. Or did you miss those 80-100 comments?
>This statement makes no sense. If you are not using NAT of some kind, and your machines only have RFC1918 addresses, then your machines can't access the Internet at all.
Exactly. That was my point. And if you add NAT without stateful firewall rules to limit access, your internal systems are exposed.
I tell you what: post the IP address/range of your home network, turn off the firewall you're using and just leave NAT enabled as it is right now and we can see for ourselves just how "secure" bare NAT is. What do you say?
Unsecured NAT (i.e., without, at a minimum, firewall rules limiting connectivity -- a default deny rule at least) is not secure at all.
I've said (now twice) what I had to say. Feel free to disagree (again) and/or downmod my post, but my decades of experience professionally implementing networks, the security infrastructure which attempts to secure them, at the perimeter as well as at the LAN, server and endpoint informs my opinion.
Don't agree? That's fine with me. It's no skin off my nose. I have no axe to grind with you or anyone else around this or anything else.
Have a good day.
Edit: Clarified the "Globally routable" addresses as IPv4.
I've explained before, in many threads, that pure consumer NAT, without a firewall, has exactly the same behavior as a consumer stateful firewall, except for two cases :
1. The ISP is malicious/compromised, and sends packets with RFC1918 addresses on the router's WAN port.
2. The router itself has admin services that are listening on public IPs (eg HTTP server listening on 0.0.0.0 instead of 192.168.0.1), so it itself could be compromised from outside the ISP network.
Except for these two points, there is no difference between the security characteristics of a consumer NAT and a consumer firewall:
1. LAN machines can't be reached over the internet other than through the NAT, since a packet addressed to 192.168.0.7 from Google will not be routed by any ISP.
2. When a packet arrives to the NAT with a destination IP set to the NAT public IP, the packet will not be delivered to any box on the LAN unless (a) its ports match an active connection from a LAN box, or (b) its destination port matches an explicit port forward rule an admin added.
Case (a) above is exactly what a stateful firewall with a default deny rule does. Case (b) is also exactly the same, as if you explicitly open a port in this type of consumer firewall, it will allow any packet matching that port.
Now, I wouldn't disable my firewall, because I don't trust that my consumer router is itself well enough secured, and I don't necessarily trust my ISP's network either. But this doesn't mean that my laptop is exactly as secure if it were to sit behind this router with no firewall as it would be if I disabled both firewall and NAT entirely and gave my laptop a publicly routable IPv4.
Sure, but the Internet will not route packets going to RFC1918 addresses. So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped. And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused.
This is all behavior that happens even with no firewall whatsoever.
Because this is exactly what the GP was claiming, and you denied: even without a firewall, packets that don't correspond to an open connection will get dropped by a NAT, even without a firewall. Sure, maybe "dropped" is wrong, as the NAT box will probably instead send a RST packet, but this is almost entirely irrelevant.
Right, we were talking about NAT. So how is any of that non-NAT-related stuff relevant?
> Sure, but the Internet will not route packets going to RFC1918 addresses
This is about RFC1918, not NAT.
> So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped.
This is about reverse path filtering, not NAT.
> And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused.
And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.
> And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.
Fine. Packets that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection, an explicit port forwarding rule, OR the port of a service on the router itself listening on the WAN IP will also get refused.
The point is that any LAN box sitting behind the NAT will not get that packet, same as if the router had a stateful firewall running.
And sure, this is not purely a property of the NAT itself, it's a combination of the Internet not routing private IP addresses, reverse path filtering, and NAT. That still doesn't need any firewall to achieve this.
So what do you think will happen with a packet that arrives at the router with destination IP set to the router's IP, and destination port set to some port for which there is no port forward rule (and no currently open TCP connection)? Will it reach some machine on the network, or will it get dropped/NACKed?
It will reach the router, obviously. If it's a TCP SYN packet and there's a server listening on that port, you'll connect to that server. If there's no listener then you get a RST.
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.
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.
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.
Whichever machine has the NAT's external IP assigned to it will accept or refuse the connection, depending on whether they have a server running on that port or not.
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.
I watched this video a few days ago after it was randomly recommended by YouTube. Definitely found it very interesting and he has a load of other videos about learning Old English, so I'll be checking out more of them soon.
You're using somewhat sloppy terminology that will confuse things. An IP packet can't be addressed both to 12.13.14.15 AND to 192.168.0.7.
The realistic attack here is that your ISP sends a packet with destination address 192.168.0.7 to the MAC of your router (the MAC that corresponds to 12.13.14.15). This is a realistic attack scenario if the device that your router connects directly to gets compromised (either by an attacker or by the ISP itself).
Getting a public route that would take packets destined for 192.168.0.7 to reach your router over the Internet is far more unlikely.
Note that DHCPv6 is really uncommon for IPv6, especially on consumer routers - so uncommon that Android doesn't even support it. But your point stands, even more so, with SLAAC.
The whole premise of IPv6 is that every device should have a globally routable IP. This thread went into DHCP for some reason, but that is uncommon and not recommended for IPv6, where you're supposed to use SLAAC. With SLAAC, I'm not even sure you could realistically disable the ability to get a public IP. And if you did, I'm not sure you could allow a device to access the Internet over IPv6 with a consumer router without it having a publicly routable IPv6.
reply