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?
Sure, maybe I've worded things too factually and not differentiated between theory and practice. But,
Regarding the summary: I don't think I want to advise people not to use a firewall. I thought this was a theoretical discussion about single arguments. And it's complicated and confusing anyways. Which firewall do you run? The default Windows firewall is a completely different thing and setup than nftables and a Linux server that closes everything and only opens ports you specifically allow. Next question: How do you configure it? And where do you even run it? On a seperate host? Do you always rent 2 VPS? Do you do only do perimeter security for your LAN network and run a single firewall? Do you additionally run firewalls on all the connected computers in the network? Does that replace the firewall in front of them? What other means of security protection did you implement? As we said a firewall won't necessarily protect against weak passwords and keys. And it might not be connected to the software that gets brute-forced and thus just forward the attack. In practice it's really complicated and it always depends on the exact context. It is good practice to not allow everything by default, but take the approach to block everything and explicitly configure exceptions like a firewall does. It's not the firewall but this concept behind it that helps.
I think I get you and the 'theory vs. practice' point you make is very valid. ;-) I mean, in theory my OS has software w/o bugs, is always up-to-date and 0-days do not exist. (Might even be true in practice for a default OpenBSD installation regarding remote vulnerabilities. :-P)
fail2ban absolutely mitigates a subset of timing attacks in its default setup. ;-)
LIMIT is a high level concept which can easily applied for ufw, don't know about default setups of commonly used firewalls.
If someone exposes something like SSH or anything else w/o fail2ban/LIMIT IMHO that is grossly incompetent.
You are totally right, of course firewalls have bugs/errors/miss configurations... BUT ... if you are using a Linux firewall, good chances are, that the firewall has been reviewed/attacked/pen tested more often and thoroughly than almost all other services reachable from the internet. So, if I have to choose between a potential attacker first hitting a well tested and maintained firewall software or a MySQL server, which got no love from Orcacle and lives in my distribution as an outdated package, I'll put my money on the firewall every single time. ;-)
Thank you for pointing out that my arguments don't necessarily apply to reality. Sometimes I answer questions too direct. And the question wasn't "should I use a firewall" or I would have answered with "probably yes."
I think I have to make a few slight corrections: I think we use the word "timing attack" differently. To me a timing attack is something that relies on the exact order or interval/distance packets arrive at. I was thinking of something like TOR does where it shuffles around packets, waits for a few milliseconds, merges them or maybe blows them up so they all have the same size. Brute forcing something isn't exploiting the exact time where a certain packet arrives, it's just sending many of them and the other side lets the attacker try an indefinite amount of passwords. But I wouldn't put that in the same category with timing attacks.
Firewall vs MySQL: I don't think that is a valid comparison. The firewall doesn't necessarily look into the packets and detect that someone is running a SQL injection. Both do a very different job. And if the firewall doesn't do deep-packet-inspection or rate limiting or something, it just forwards the attack to the service and it passes through anyways. And MySQL probably isn't a good example since it rarely should be exposed to the internet in the first place. I've configured MariaDB just to listen on the internal interface and not to packets from other computers. Additionally I didn't open the port in the firewall but MariaDB doesn't listen on that interface anyways. Maybe a better comparison would be a webserver with https. The firewall can't look into the packets because it's encrypted traffic. It can't tell apart an attack from a legitimate request and just forwards them to the webserver. Now it's the same with or without a firewall. Or you terminate the encrypted traffic at the firewall, do packet inspection or complicated heuristics. But that shifts the complexity (including potential security vulberabilities in complex code) from the webserver to the firewall. And it's a niche setup that also isn't well tested. And you need to predict the attacks. If your software has known vulnerabilities that won't get fixed, this is a valid approach. But you can't know future attacks.
Having a return channel from the webserver/software to the firewall so the application can report an attack and order the firewall to block the traffic is a good thing. That's what fail2ban is for. I think it should be included by default wherever possible.
I think there is no way around using well-written software if you expose it to the internet (like a webserver or a service that is used by other people.) If it doesn't need to be exposed to the internet, don't do it. Any means of assuring that are alright. For crappy software that is exposed and needs to be exposed, a firewall doesn't do much. The correct tools for that are virtualization, containers, VPNs, and replacing that software... Maybe also the firewall if it can tell apart good and bad actors by some means. But most of the time that's impossible for the firewall to tell.
I agree. You absolutely need to do something about security if you run services on the internet. I do and have ran a few services. And especially webserver-logs (especially if you have a wordpress install or some other commonly attacked CMS), SSH and Voice-over-IP servers get bombarded with automated attacks. Same for Remote-Desktop, Windows-Networkshares and IoT devices. If I disable fail2ban, the attackers ramp up the traffic and I can see attacks scroll through the logfiles all day.
I think a good approach is: