Linux

Seriously, unless you are extremely specialized and know exactly what you are doing, IMHO the answer is: Always (and even being extremely specialized, I would still enable a firewall. :-P)

Operating systems nowadays are extremely complex with a lot of moving parts. There are security relevant bugs in your network stack and in all applications that you are running. There might be open ports on your computer you did not even think about, and unless you are monitoring 24/7 your local open ports, you don't know what is open.

First of all, you can never trust other devices on a network. There is no way to know, if they are compromised. You can also never trust the software running on your own computer - just look at CVEs, even without malicious intentions your software is not secure and never will be.

As soon as you are part of a network, your computer is exposed, doesn't matter if desktop/laptop, and especially for attacking Linux there is a lot of drive by attacks happening 24/7.

Your needs for firewalls mostly depend on your threat model, but just disabling accepting incoming requests is trivial and increases your security by a great margin. Further, setting a rate limit for failed connection attempts for open ports like SSH if you use this services, is another big improvement for security. (... and of course disabling password authentication, YADA YADA)

That said, obviously security has to be seen in context, the only snake oil that I know of are virus scanners, but that's another story.

People, which claim you don't need a firewall make at least one of the following wrong assumptions:

• Your software is secure - demonstrably wrong, as proven by CVEs
• You know exactly what is running/reachable on your computer - this might be correct for very small specialized embedded systems, even for them one still must always assume security relevant bugs in software/hardware/drivers

Security is a game, and no usable system can be absolutely secure. With firewalls, you can (hopefully) increase the price for successful attacks, and that is important.

Other comments have hit this, but one reason is simply to be an extra layer. You won’t always know what software is listening for connections. There are obvious ones like web servers, but less obvious ones like Skype. By rejecting all incoming traffic by default and only allowing things explicitly, you avoid the scenario where you leave something listening by accident.

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.

You say that like that isn't providing value. How many services are listening on a port on your system right now? Run 'ss -ltpu' and prepare to be surprised.

Security isn't about "this will make you secure" it's about layers of protection and probability. It's a "good practice" because people make mistakes and having a second line of defense helps reduce the odds of a hack.

When you expose ports to the Internet. It's honestly interesting to setup a Web server with the default page on it and see how quickly you get hits on it. You don't need to register a DNS or be part of an index anywhere. If you open a port (and your router does forward it) then you WILL get scanned for vulnerabilities. It's like going naked in the forest, you sure can do that but clothes help, even if it's "just" again ivy or random critters. Now obviously the LONGER you run naked or leave a computer exposed, the most likely you are to get a bad bug.

You always need a firewall, no other answer's.

Why do you think windows and most linix distributions come packaged with one?

Always, as others have said.

#2 is strange -- why does it matter?

It doesn't. If you're running a laptop with a local web server for development, you wouldn't want other devices in i.e. the coffee shop WiFi to be able to connect to your (likely insecure) local web server, would you?

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?

Who is "they"? What about all the other ports?

Imagine a family member visits you and wants internet access in their Windows laptop, so you give them the WiFi password. Do you want that possibly malware infected thing poking around at ports other than 80 running on your server?

Obviously you shouldn't have insecure things listening there in the fist place but you don't always get to choose whether some thing you're hosting is currently secure or not or may not care too much because it's just on the local network and you didn't expose it to the internet.
This is what defense in depth is about; making it less likely for something to happen or the attack less potent even if your primary protections have failed.

#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

Mostly addressed by the above but also note that you likely do have applications listening on ports you didn't know about. Take a look at sudo ss -utpnl.

#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.

It's rather the other way around; you don't want the outside world to be able to talk to untrusted software on your computer. To be a classical "door", the application must be able to listen to connections.

OTOH, smarter malware can of course be something like a door by requesting intrusion by itself, so outbound filtering is also something you should do with untrusted applications.

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?

I'd rather liken it to a razor fence around your house, protecting you from thieves even getting near it. Your windows are likely safe from intrusion but they're known to be fragile. Razor fence can also be cut through but not everyone will have the skill or patience to do so.

If it turned out your window could easily be opened from the outside, you'd rather have razor fence in front until you can replace the window, would you?

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.

Firewall for incoming traffic :

• If you a home user with your computer or laptop inside a LAN you would not really need a firewall, unless you start to use applications which expose its ports to 0.0.0.0 rather than 127.0.0.1 (I believe Redis server software did this a few years ago) and do not trust other users or devices (smart home devices, phones, tablets, modems, switches and so on) inside your LAN.

• If you are running a server with just a few services, for example ssh, smtp, https, some hosting company people I knew argue that no firewall is needed. I am not sure, my knowledge is lacking.

Application firewalls, watching also outgoing traffic :

If you compare Linux with some other Operating System you will see that on Linux for years an application firewall was non existing. But there is a choice now : opensnitch This can be useful if you run desktop applications that you do not fully trust, or want more control.

This question reads a bit to me like someone asking, "Why do trapeze artists perform above nets? If they were good at what they did they shouldn't fall off and need to be caught."

Do you really need a firewall? Well, are you intimately familiar with every smidgeon of software on your machine, not just userland ones but also system ones, and you understand perfectly under which and only which circumstances any of them open any ports, and have declared that only the specific ports you want open actually are at every moment in time? Yes? You're that much of a sysadmin god? Then no, I guess you don't need a firewall.

If instead you happen to be mortal like the rest of us who don't read and internalize the behaviors of every piddly program that runs or will ever possibly run on our systems, you can always do what we do for every other problem that is too intensive to do manually: script that shit. Tell the computer explicitly which ports it can and cannot open.

Luckily, you don't even have to start from scratch with a solution like that. There are prefab programs that are ready to do this for you. They're called firewalls.

You need to understand the mindset behind running a firewall, and that mindset is that you define with mathematical precision what's possible within the network connectivity of a device, you leave nothing to chance or circumstance, because doing so would be sloppy.

Provided you want to subscribe to this mindset, and that the circumstances of that device warrant it, and that you have the networking knowledge to pull it off, you should in theory start with a DENY policy on everything and open up specific ports for specific users and related connections only. But it's not trivial and if you're a beginner it's best done directly on the server console, because you WILL break your SSH connection doing this. And of course maybe not persist the firewall rules permanently until you've learned more and can verify you can get in.

Now obviously this is an extreme mindset and yes you should use it in a professional setting. As a hobbyist? Up to you. In theory you don't need a firewall if your server only exposes the services you want to expose and you were gonna expose them through the firewall anyway. In practice, keeping track on what's running on a box and what's using what connections can be a bit harder than that.

If you're a beginner my recommendation is to use a dedicated router running OpenWRT with LUCI, which comes with a sensible firewall out of the box, an easy to use UI, and other goodies like an easy to use DNS+DHCP server combo and the ability to install plugins for DoH, DDNS etc.

It seems that the consensus from all the comments is that you do in fact need a firewall. So my question is how does that look exactly? A hardware firewall device directly between modem and router? I using the software firewall on the router enough? Or, additionally having software firewall installed on all capable devices on the network? A combination of the above?

When you are attacked. Ok so when are you attacked , as soon as you connect outside. So unless you are air gapped you need a firewall.

You're right. If you don't open up ports on the machines, you don't need a firewall to drop the packages to ports that are closed and will drop the packets anyways. So you just need it if your software opens ports that shouldn't be available to the internet. Or you don't trust the software to handle things correctly. Or things might change and you or your users install additional software and forget about the consequences.

However, a firewall does other things. For example forwarding traffic. Or in conjunction with fail2ban: blocking people who try to guess ssh passwords and connect to your server multiple times a second.

Edit:

1. “It’s just good security practice.” => nearly every time I've heard that people followed up with silly recommendations or were selling snake-oil.
2. “You [just] need it if you are running a server.” => I'd say it's more like the opposite. A server is much more of a controlled environment than lets say a home network with random devices and people installing random stuff.
3. “You need it if you don’t trust the other devices on the network.” => True, I could for example switch on and off your smarthome lights or disable the alarm and burgle your home. Or print 500 pages.
4. “You need it if you are not behind a NAT.” => Common fallacy, If A then B doesn't mean If B then A. Truth is, if you have a NAT, it does some of the jobs a firewall does. (Dropping incoming traffic.)
5. “You need it if you don’t trust the software running on your computer.” => True

Firewalls are necessary for least privilege. You only give something access that needs access.

Additionally you should not port forward and especially not port 80.

A large part of this is only thinking of a firewall as preventing inbound connections. A big part of securing a net comes from preventing things like someone establishing an outbound connection on some random port and siphoning off everything to a home base.

A firewall in itself won't cover everything, that's just ports, protocols, and addresses. Tack on an IPS for behavioral scanning, reputation lists for dynamic 'do no allow connections to/from these IPs' and some DNS filters or a proxy to help get vision into the basic 80/443 traffic that you can't just block without killing the internet and you've got something going.

A firewall is not security on a box, although most think of it that way. A lot of commercial security-suite products actually do a few things but it's just easier to market it to grandma if they simply call it a firewall, it's a term well embedded in the public concesness.

In the world of Windows XP before SP2, your system would be taken over by internet worms within minutes of connecting to the internet. If you had an Internet connection while running setup, it would happen before you even booted the computer into the OS for the first time.

Things have gotten better, but vulerabilities are still discovered all the time. A big point of a firewall is to have a device guaranteed to have very little attack surface in between devices that are more unknown quantities. Then they can add additional features, like recognizing when someone is trying to take advantage of a vulnerability in the webserver on port 80 and blocking it.

I personally use a firewall for containing the local services I am running on my non-server PC, ex. Tiny Tiny RSS. If I am only using Tiny Tiny RSS locally, it's just potentially dangerous to make this service visible and accessible for every client in my local network, which in my case, isn't populated by my own personal devices, as I live in a dormitory. Other than that, you can block the well-known ports of commonly exploited protocols such as UPnP. That's not because someone will "break into your device" with UPnP, but rather as a matter of digital autonomy, to control the mode of network communication done by the software on your device.

I think it’s better to have one but you probably don’t need multiple layers. When I’m setting up servers nowadays, it’s typically in the cloud and AWS and the like typically have firewalls. So, I don’t really do much on those machines besides change ports to non-standard things. (Like the SSH port should be a random one instead of 22.)

But you should use one if you don’t have an ecosystem where ports can be blocked or forwarded. If nothing else, the constant login attempts from bots will fill up your logs. I disable password logins on web servers and if I don’t change the port, I get a zillion attempts to ssh using “admin” and some common password on port 22. No one gets in but it still requires more compute than just blocking port 22 and making your SSH port something else.

As i see it, the term "firewall" was originally the neat name for an overall security concept for your systems privacy/integrity/security. Thus physical security is (or can be) as well part of a firewall concept as maybe training of users. The keys of your server rooms door could be part of that concept too.

In general you only "need" to secure something that actually is there, you won't build a safe into the wall and hide it with an old painting without something to put in it or - could be part of the concept - an alarmsensor that triggers when that old painting is moved, thus creating sort of a honeypot.

if and what types of security you want is up to you (so don't blame others if you made bad decisions).

but as a general rule out of practice i would say it is wise to always have two layers of defence. and always try to prepare for one "error" at a time and try to solve it quickly then.

example: if you want an rsync server on an internet facing machine to only be accessible for some subnets, i would suggest you add iptables rules as tight as possible and also configure the service to reject access from all other than the wanted addresses. also consider monitoring both, maybe using two different approaches: monitor the config to be as defined as well as setup an access-check from one of the unwanted, excluded addresses that fires an alarm when access becomes possible.

this would not only prevent those unwanted access from happening but also prevent accidental opening or breaking of config from happen unnoticed.

here the same, if you want monitoring is also up to you and your concept of security, as is with redundancy.

In general i would suggest to setup an ip filtering "firewall" if you have ip forwarding activated for some reason. a rather tight filtering would maybe only allow what you really need, while DROPping all other requests, but sometimes icmp comes in handy, so maybe you want ping or MTU discovery to actually work. always depends on what you have and how strong you want to protect it from what with what effort. a generic ip filter to only allow outgoing connections on a single workstation may be a good idea as second layer of "defence" in case your router has hidden vendor backdoors that either the vendor sold or someone else simply discovered. Disallowing all that might-be-usable-for-some-users-default-on-protocols like avahi & co in some distros would probably help a bit then.

so there is no generic fault-proof rule of thumb..

to number 5.: what sort of "not trusting" the software? might, has or "will" have: a. security flaws in code b. insecurity by design c. backdoors by gov, vendor or distributor d. spy functionality e. annoying ads as soon as it has internet connection f. all of the above (now guess the likely vendors for this one)

for c d and e one might also want to filter some outgoing connection..

one could also use an ip filtering firewall to keep logs small by disallowing those who obviously have intentions you dislike (fail2ban i.e.)

so maybe create a concept first and ask how to achieve the desired precautions then. or just start with your idea of the firewall and dig into some of the appearing rabbit holes afterwards ;-)

regards

I've got two services on my computer. One is for email, I want that this port to be open to the public WAN and one is for immich which hosts all my private pictures, I don't want this port to be public but reachable on LAN. In my router I open the port for email but not for immich. Emal can communicate on LAN and WAN and immich only on LAN. On a foreign, untrusted LAN, like an airport I don't want other people being able to sniff my immich traffic which is why I have another firewall setting for an untrusted LAN.