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?
Even if you do trust the software running on your computer, did you actually fuzz it for vulnerabilities? Heartbleed could steal your passwords even if you ran ostensibly trustworthy software.
So unless you harden the software and prove it's completely exploit-free, then you can't trust it.
Heartbleed is independent of a firewall though -- it's a protocol vulnerability that was patched into a specific library -- this feels somewhat like a strawman argument.
The type of "firewall" that I am referring to operates at layer 3/4. From what I understand, you seem to be describing exploits closer to the application layer.
I'm not saying there would be a Heartbleed 2.0 that you need a firewall against
I'm saying unless you read the code you're running, including the firmware and the kernel, how can you trust there isn't a remote execution exploit?
At work I showed a trivial remote execution using an upload form. If we didn't run php, it wouldn't happen. If the folder had proper
.htaccess, it wouldn't happen. If we didn't trust the uploader's MIME type, it wouldn't happen.There's something to be said about defense in depth. Even if you have some kind of a bug or exploit, the firewall just blocking everything might save you.
A packet filtering firewall isn't able to protect against server, or protocol exploits directly. Sure, if you know that connections originating from a specific IP are malicious, then you can drop connections originating from that IP, but it will not be able to direclty protect against application layer exploits.
There do exist application layer firewalls (an example of which was pointed out to me here (opensnitch)), but those are out of the scope of this post.