Why would I need to have software firewalls on my devices behind my NAT router at home? The topology is a basic consumer grade one: ISP -> my router (NAT) -> LAN, and vice versa.
If NAT already obfuscates my private addresses through translation, how would a potential adversary connect to anything beyond it?
What “good” would my public IP do for a hacker if I have no ports forwarded?
Is a firewall a second line of defense just in case I execute malware that starts forwarding ports?
I do have software firewalls on all my devices, but that wasn’t an informed choice. I just followed the Arch Wiki’s post installation guidelines.
The difference between NAT and firewalls is a common point of confusion, and particularly irks me because I am very pro-IPv6 and very anti-NAT. Nevertheless, we should start with the raison d’etre for NAT and firewalls.
Network Address Translation (NAT) is a variety of technologies used to map one (or more) external-facing IP addresses to one (or more) internal IP addresses. The various flavors of NAT are described in RFC2663, but suffice it to say that the most common situation is to share a single public IP with many internal machines on a LAN, by rewriting port numbers to distinguish each internal machine’s packets from each other. This is usually called Network Address/Port Translation (NAPT) and necessarily only works for protocols that the translator understands (usually just TCP, UDP, and ICMP).
A firewall is a security feature that inspects and rejects unwanted traffic from entering or exiting a network. A simple configuration would be to reject all ingress traffic, except when that traffic is expected as a reply to an earlier packet sent from the internal network. This sort of simple configuration is sufficient for client-server applications, such as web browsing, but will not support peer-to-peer software nor would it support hosting services at home. Note that rejecting traffic at the firewall still means that the packet had to be sent through the ISP all the way to the firewall, and then blocked there.
With these definitions in mind, all commercially-available home routers for the past two decades have always included both a NAT and a default firewall, even if people did not necessarily notice the presence of the latter. This has led to the perception that only the NAT is what keeps the internal network safe, but it really doesn’t.
Perhaps the best way I can explain why NAT != security is by pointing to the Wikipedia page on NAT Traversal. This is when various applications (legitimate or not) have a valid need to overcome the port-mapping that NAPT does, or whatever else molestation that the translator is doing. STUN and TURN are two specific technologies explicitly designed to help break through a NAT, and they’re in common use for enabling VoIP in video games and video/screen sharing in telepresence applications. Those two examples have a need to send traffic directly inbound to a user’s machine, and the fact that it’s possible means that NAT can (and has) been abused to break into networks.
Here is the general structure of a malicious break-in to a network, in spite of NAT, requiring only an unwitting machine on the inside to help jump-start the attack. Consider that we have a secure machine (eg accounting database server) on the network, labeled S. And we have a number of user machines, with one of them being labeled U. Somewhere faraway, Mallory has set up a scam website on HTTP port 80, and convinces the user on machine U to visit it. Through any available mechanism that Mallory can conceive, Mallory gets U to send an outbound packet with a fake source IP and with src port 22. Actually, Mallory gets U to send loads of packets, each from a different source IP. By sheer brute force, one of these packets will have the forged source IP of S and port 22.
From the NAPT translator’s perspective, it just sees a bunch of outbound connection attempts to a faraway server. So it happily does translation and passes the connection through. It also marks the port as “established”, meaning a reply will be allowed back into the network. It turns out, all of these connections are to Mallory’s machine. Uh oh.
Mallory can now send packets back towards the the internal network, and the NAT lets those packets through. Mallory specifically crafts an SSH connection attempt, and lo and behold, the accounting machine is running a seriously out-of-date, unpatched version of SSH server (why? idk). Pwned. You can replace any part of this theoretical attack to make it more plausible, but that’s the rub: it’s entirely possible. NAT does not provide security. Mallory can trick the translator.
Why didn’t the firewall do anything? As explained before, a default firewall allows any machine on the inside to talk to the internet. But that was not a wise choice, because the S machine really shouldn’t ever be talking to the internet. Good network design would have blocked outbound connections from the S machine’s IP, because S has no legitimate reason for doing so. This is the principle of least-privilege.
Even better design would be defense in depth: even with the network’s firewall configured to reject any attempt by S to reach the internet, S should also be running its own firewall. Two > One. And that firewall can be a lot less complicated, because it only needs to deal with a single machine’s traffic. Did S need to have an SSH server? Turn that off, and then configure S’s firewall to drop port 22 inbound traffic.
TL;DR: check your firewall settings. Imagine ways to break into your own network. Fix what you find.
Thank you for the quick and detailed response! I learned a lot, not only about the two technologies but also about how to approach network security in general. 😊
While possibly, this is generally unlikely to achieve, unless Mallory can convince U to run malicious code with elevated privileges. Binding to ports under 1024 and forging TCP packets require elevated privileges on any user OS.
In my mind, I figured that an attacker would sidestep binding to L3 at all, and would just craft raw L2 packets that contain TCP headers with src_addr of every possible address in the subnet. But that too would require elevated privileges, so point taken.
That said, using most of the same general scenario where S is blitheringly unsecured against internal threats – under the false pretense that NAT somehow provides security – a DNS rebinding attack that uses an unwitting user’s web browser to proxy Mallory’s traffic to S could succeed. Maybe not SSH per-se, but any internal service that S is hosting would be vulnerable.
This isn’t an attack that’s per-se exacerbated by NAT, but a good-and-proper firewall config at the network and on S would easily protect against this, which is why I mention it. If NAT is believed to be “security”, then almost certainly the firewall configuration will be overlooked and attack vectors will be left open.
Typically you’d just run a bind C2 implant on the User machine that reaches out to the attackers C2 servers to retrieve cached commands to execute. Yeah NAT isn’t going to stop it, but tbh a stateful firewall isn’t really gonna stop it either.