I've spent some time searching this question, but I have yet to find a satisfying answer. The majority of answers that I have seen state something along the lines of the following:
- "It's just good security practice."
- "You need it if you are running a server."
- "You need it if you don't trust the other devices on the network."
- "You need it if you are not behind a NAT."
- "You need it if you don't trust the software running on your computer."
The only answer that makes any sense to me is #5. #1 leaves a lot to be desired, as it advocates for doing something without thinking about why you're doing it -- it is essentially a non-answer. #2 is strange -- why does it matter? If one is hosting a webserver on port 80, for example, they are going to poke a hole in their router's NAT at port 80 to open that server's port to the public. What difference does it make to then have another firewall that needs to be port forwarded? #3 is a strange one -- what sort of malicious behaviour could even be done to a device with no firewall? If you have no applications listening on any port, then there's nothing to access. #4 feels like an extension of #3 -- only, in this case, it is most likely a larger group that the device is exposed to. #5 is the only one that makes some sense; if you install a program that you do not trust (you don't know how it works), you don't want it to be able to readily communicate with the outside world unless you explicitly grant it permission to do so. Such an unknown program could be the door to get into your device, or a spy on your device's actions.
If anything, a firewall only seems to provide extra precautions against mistakes made by the user, rather than actively preventing bad actors from getting in. People seem to treat it as if it's acting like the front door to a house, but this analogy doesn't make much sense to me -- without a house (a service listening on a port), what good is a door?
For this specific argument, what difference does it make if that specific device has a firewall in addition to the NAT that it is behind? To expose the device to the internet, a port needs to be openend on the router which points to a specific port on the device. When a request is made to that port, only that port is accessed. Some third party can't start poking around at other ports on the device, as there is no route from the router.
True but there are also DMZ options that allow to expose an entire machine. I imagine someone who is not familiar with networking or firewalls might "give up" and use that "solution" if they don't manage to expose just the right port on just the right machine. I'm sure I did that at some point when I was tired of tinkering.
Also if the single port that is exposed has vulnerabilities, then scanning the other ports might not be necessary. If the vulnerability on the opened port allow some kind of access, even without escalating privilege (i.e no root access) maybe localhost queries could be made and from there maybe escalating on another service that wouldn't be exposed.
Finally on your initial question I'd argue if the firewall rules are equivalent then it would be equivalent but if they are a bit more refined than "just" open or close a port, e.g drop traffic that is not from within the LAN, so a specific subnet, then it might still create risk.
For sure, but this is a separate topic. The existence of a firewall is kind of independent of the security of the service listening on the port that it's expected to listen on. If there is a vulnerability in the service, the existence of a packet filtering firewall most likely won't be able to do anything to thwart it.
Fair point! Still, though, I'm not super convinced of the efficacy of a packet filtering firewall running on a device in preventing malicious connections from itself, were a service running on it to become compromised. The only way that I can see it guaranteeing protection from this scenario is if it drops all packets, but, at that point, it's just an offline system -- no networking -- so the issue essentially no longer applies.