Skip Navigation
Linux @lemmy.ml
Kalcifer @sh.itjust.works

When do I actually need a firewall?

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:

  1. "It's just good security practice."
  2. "You need it if you are running a server."
  3. "You need it if you don't trust the other devices on the network."
  4. "You need it if you are not behind a NAT."
  5. "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?

126 comments

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

    • You may also want to check up on regulations and laws of your country.

      In Belgium, for instance, I am responsible for any and all attacks originating from my PC. If you were hacked and said hackers used your computer to stage an attack, the burden of proof is upon you. So instead of hiring very expensive people to trace the real source of an attack originating from your own PC, enabling a firewall just makes sense, besides making it harder on hackers…

      • That's a strange law. That's like saying one should be held responsible for a thief stealing their car and then running over someone with it (well, perhaps an argument could be made for that, but I would disagree with it).

    • Seriously, unless you are extremely specialized and know exactly what you are doing, IMHO the answer is: Always

      In what capacity, though? I see potential issues with both server firewalls, and client firewalls. Unless one wants their devices to be offline, there will always be at least one open port (for example, inbound on a server, and outbound on a client) which can be used as an attack vector.

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

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

      AKA Defense In Depth and should be considered for any type of security.

    • In the military when learning ORM we called this the "swiss cheese" theory.

      The more layers of sliced swiss cheese, the fewer holes that go all the way through.

  • 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?

    • You always need a firewall, no other answer’s.

      Okay, but why? That's kind of the point of why I made this post, as is stated in the post's body.

      • To keep your system secure no matter what, you open up only the ports you absolutely need.

        People will always make a mistake while configuring software, a firewall is there to make sure that error is caught. With more advanced firewall' you can even make sure only certain app's have access to the internet to make sure only what you absolutely need toconnect to the internet does.

        In general it's for security, but can also be privacy related depending on how deep you want to get into it.

        EDIT: It isnt about not trusting other devices on your netork,or software you run, or whether you are runni g a server. It's about general security of your system.

  • 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?

    • 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?

      This is a fair point that I hadn't considered for the mobile use-case.

      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?

      Fair point!

      note that you likely do have applications listening on ports you didn't know about. Take a look at sudo ss -utpnl.

      Interesting! In my case I have a number of sockets from spotify, and steam listening on port 0.0.0.0. I would assume, that these are only available to connections from the LAN?

      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.

      It could also be malicious software that simply makes a request to a remote server -- perhaps even siphoning your local data.

      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?

      Fair point!

      • In my case I have a number of sockets from spotify, and steam listening on port 0.0.0.0. I would assume, that these are only available to connections from the LAN?

        That's exactly the kind of thing I meant :)

        These are likely for things like in-house streaming, LAN game downloads and remote music playing, so you may even want to consider explicitly allowing them through the firewall but they're also potential security holes of applications running under your user that you have largely no control over.

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

    • 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

      Interestingly, on one of my devices, running # ss -utpnl shows quite a number of Spotify, and Steam sockets listening on 0.0.0.0. I looked up some of the ports, and, for example, one of the steam ones was a socket for Remote Play.

      But there is a choice now : opensnitch

      This is really cool! Thank you so much for this recommendation! This pretty much solves what was bugging me about outgoing connections in a layer 3/4 firewall like nftables.

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

    • Tell the computer explicitly which ports it can and cannot open.

      Isn't this all rather moot if there is even one open port, though? Say, for example, that you want to mitigate outgoing connections from potential malware that gets installed onto your device. You set a policy to drop all outgoing packets in your firewall; however, you want to still use your device for browsing the web, so you then allow outgoing connections to DNS (UDP, and TCP port 53), HTTP (TCP port 80), and HTTPS (TCP port 443). What if the malware on your device simply pipes its connections through one of those open ports? Is there anything stopping it from siphoning data from your PC to a remote server over HTTP?

      • The point of the firewall is not to make your computer an impenetrable fortress. It's to block any implicit port openings you didn't explicitly ask for.

        Say you install a piece of software that, without your knowledge, decides to spin up an SSH server and start listening on port 22. Now you have that port open as a vector for malware to get in, and you are implicitly relying on that software to fend it off. If you instead have a firewall, and port 22 is not one of your allowed ports, the rogue software will hopefully take the hint and not spin up that server.

        Generally you only want to open ports for specific processes that you want to transmit or listen on them. Once a port is bound to a process, it's taken. Malware can't just latch on without hijacking the program that already has it bound. And if that's your fear, then you probably have a lot of way scarier theoretical attack vectors to sweat over in addition to this.

        Yes, if you just leave a port wide open with nothing bound to it, either via actually having the port reserved or by linking the process to the port with a firewall rule, and you happened to get a piece of actual malware that scanned every port looking for an opening to sneak through, sure, it could. To my understanding, that's not typically what you're trying to stop with a firewall.

        In some regards a firewall is like a padlock. It keeps out honest criminals. A determined criminal who really wants in will probably circumvent it. But many opportunistic criminals just looking for stuff not nailed down will probably leave it alone. Is the fact that people who know how to pick locks exist an excuse to stop locking things because "it's all pointless anyway"?

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

  • 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?

    • Depends on the setup. For most people at home their router also does firewalling and NAT, and that is enough.

      Even in corporate it is not uncommon for a firewall to be the gateway, or transparent in between, with maybe more internally too. There are just more routers inside and out, but those routers are real network routers in the traditional sense.

    • And like most things related to Linux on the internet, the consensus is generally incorrect. For a typical home user who isn't opening ports or taking a development laptop to places with unsecure wifi networks, you don't really need a firewall. It's completely superflous. Anything you do to your PC that causes you genuine discomfort will more than likely be your own fault rather than an explicit vulnerability. And if you're opening ports on your home network to do self-hosting, you're already inviting trouble and a firewall is, in that scenario, a bandaid on a sucking chest wound you self-inflicted.

      • For a typical home user who isn’t opening ports or taking a development laptop to places with unsecure wifi networks, you don’t really need a firewall. It’s completely superflous.

        A "typical" home user, whom I assume is less knowledgeable about technology, is probably the person who would benefit the most from strict firewalls installed on their device. Such an individual assumedly doesn't have the prerequisite knowledge, or awareness required to adequately gauge the threats on their network.

        Anything you do to your PC that causes you genuine discomfort will more than likely be your own fault rather than an explicit vulnerability.

        Would this not be adequate rationale for having contingencies, i.e. firewalls? A risk/threat needn't only be an external malicious actor. One's own mistakes could certainly be interpreted as a potential threat, and are, therefore, worthy of mitigation.

        And if you’re opening ports on your home network to do self-hosting, you’re already inviting trouble and a firewall is, in that scenario, a bandaid on a sucking chest wound you self-inflicted.

        Well, no, not necessarily. It's important to understand what the purpose of the firewall is. If a device can potentially become an attack vector, it's important to take precautions against that -- you'd want to secure other devices on the network in the off chance that it does become compromised, or secure that very device to limit the potential damage that it could inflict.

    • Depends on your setup. I got a network-level firewall+router setup between my modem and my LAN. But also, got firewalld (friendly wrapper on iptables) on every Linux device I care about because I don't want to unintentionally expose something to the network.

      hm, guess maybe I should find something for Android and my Windows boxes.

      • (friendly wrapper on iptables)

        iptables is deprecated, so it's better to label it as a wrapper for nftables.

    • I use the firewall built into Proxmox with a device running openwrt

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

    • because you WILL break your SSH connection doing this

      Haha, yeah, I've certainly inadvertently done this when I was first learning about how firewalls worked on Linux.

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

    • Yeah like JFC the most insecure way to access the Internet let's just open it up to the whole world.

    • Additionally you should not port forward

      In what context? There is nothing inherently insecure about port forwarding. If you want a service accessible outside of your local network, you generally need to port forward. The security mostly depends on the service that is bound to the forwarded port.

      especially not port 80

      Why? If you want to run a webserver without specifying a port in the URL all the time, you are going to forward port 80; port 80 is a standardized port for all HTTP connections.

      • No offense to you but there is a massive risk exposing services to the internet. I'll let someone else more qualified explain.

  • 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

    • True, I could for example switch on and off your smarthome lights or disable the alarm and burgle your home. Or print 500 pages.

      How would the firewall on one device prevent other devices from abusing the rest of the network? Perhaps you misunderstood the original intent of my post. I certainly wouldn't blame you if that is the case, though -- when I made my post I was far too vague in my intent -- perhaps I simply didn't think through my question enough, but the more likely answer is that I simply wasn't knowledgeable enough on the topic to accurately pose the question that I wanted to ask.

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

      Fair point!

      “You need it if you don’t trust the software running on your computer.” => True

      For this, though, the only solution to it would be an application layer firewall like OpenSnitch, correct?

      • How would the firewall on one device prevent other devices from abusing the rest of the network?

        Sure. I'm not exactly sure any more what I was trying to convey. I think I was going for the firewall as a means if perimeter security. Usually devices are just configured to allow access to devices from the same Local Access Network. This is the case for lots of consumer electronics (and some enterprises also rely on securing the perimeter, once you get in their internal network, you can exploit that.) My printer lets everyone print and scan, no password setup required while installing the drivers. The wifi smart plugs I use to turn on and off the mood light in the livingroom also per default accept everyone in the WiFi. And lots of security cameras also have no password on them or people don't change the default since they're the only ones able to connect to the home WiFi. This works, since usually there is a Wifi router that connects to the internet and also does NAT, which I'd argue is the same concept as a firewall that discards incoming connections. And while wifi protocols have/had vulnerabilities, it's fairly uncommon that people go wardriving or close to your house to crack the wifi password. However, since you mentioned mixing devices you trust and devices you don't trust... That can have bad consequences in a network setup like this. You either do it properly, or you need some other means to secure your stuff. That may be isolating the cheap chinese consumer electronic with god knows which bugs and spying tech from the rest of the network. And/or shielding the devices you can't set up a password on.

        the only solution to it would be an application layer firewall like OpenSnitch, correct?

        I don't think you can make an absolute statement in this case. It depends on the scenario, as it always does with security. If you have broken web software with known and unpatched vulnerabilities, a Web Application Firewall might filter out malicious requests. An Application Firewall if other software is susceptible to attacks or might become the attacker itself (I'm not entirely sure what they do.) But you might also be able to use a conventional firewall (or a VPN) to restrict access to that software to trusted users only. For example drop all packets if it's not you interacting with that piece of software. And you can also combine several measures.

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

      Sorry, hard disagree.

      I assume you are assuming: 1.) You know about all open ports at all times, which is usually not the case 2.) There are no bugs/errors in the network stacks or services with open ports (e.g. you assume a port is only available to localhost) 3.) That there are no timing attacks which can easily be mitigated by a firewall 4.) That software one uses does not trigger/start other services transitively which then open ports you are not even aware of w/o constant port scanning

      I agree with your point, that a server is a more controlled environment. Even then, as you pointed out, you want to rate limit bad login attempts via firewall/fail2ban etc. for the simple reason, that even a fully updated ssh server might use a weak key (because of errors/bugs in software/hardware during key generation) and to prevent timing attacks etc.

      In summary: IMHO it is bad advice to tell people they don't need a firewall, because it is demonstrably wrong and just confuses people like OP.

      • Sure, maybe I've worded things too factually and not differentiated between theory and practice. But,

        1. "you know everything": I've said that. Configurations might change or you you don't pay enough attention: A firewall adds an extra layer of security. In practice people make mistakes and things are complex. In theory where everything is perfect, blocking an already closed port doesn't add anything.
        2. "There are no bugs in the network stack": Same applies to the firewall. It also has a network stack and an operating system and it's connected to your private network. Depends on how crappy network stacks you're running and how the network stack of the firewall compares against that. Might even be the same as on my VPS where Linux runs a firewall and the services. So this isn't an argument alone, it depends.
        3. Who migitates for timing attacks? I don't think this is included in the default setup of any of the commonly used firewalls.
        4. "open ports you are not even aware of": You open ports then. And your software isn't doing what you think it does. We agree that this is a use-case for a firewall. that is what I was trying to convey with the previous argument no 5.

        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.

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

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

      What's the stop said malware from siphoning data over a known port? If one were to block all outbound connections, then they essentially have an offline device. If they were to want to browse the web, for example, they would need to allow outbound connections to at least HTTPS, HTTP, and DNS. What's to stop the malware from simply establishing a connection to a remote server over HTTPS?

      • That's where some of the other lines come into play. Stop the bad domains with some lists in pi-hole/ad-guard, IP reputational blocking tools, proxies can be used for decrypting traffic if you want to go that route, IPS systems can help identify behavioral patterns for known bad actors.

        I like to think of a basic firewall as the very efficient big dumb first line. You block everything except what is needed and it doesn't matter what app or vulnerability is in play those ports are dead to the world. Then the more refined tools dig through the rest to find the various evil bits and needles in the needle stack.

  • 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'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.

  • 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

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

      Is there any way to reliably do this in practice? There's no way of really knowing what outgoing source ports are being used, as they are chosen at random when the connection is made, and if the device is to be practically used at all, some outgoing destination ports must be allowed as well e.g. DNS, HTTP, HTTPS, etc. What other methods are there to filter malicious connections originating from the device using a packet filtering firewall? There is the option of using a layer 7 firewall like OpenSnitch, but, for the purpose of this post, I'm mostly curious about packet filtering firewalls.

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

      This is a fair point! I hadn't considered that.

      • you do not need to know the source ports for filtering outgoing connections.

        (i usually use "shorewall" as a nice and handy wrapper around iptables and a "reject everything else policy" when i configured everything as i wanted. so i only occasionally use iptables directly, if my examples dont work, i simply might be wrong with the exact syntax)

        something like:

        iptables -I OUTPUT -p tcp --dport 22 -j REJECT

        should prevent all new tcp connection TO ssh ports on other servers when initiated locally (the forward chain is again another story)

        so ... one could run an http/s proxy under a specific user account, block all outgoing connections except those of that proxy (i.e. squid) then every program that wants to connect somewhere using direct ip connections would have to use that proxy.

        better try this first on a VM on your workstation, not your server in a datacenter:

        iptables -I OUTPUT -j REJECT iptables -I OUTPUT -p tcp -m owner --owner squiduser -j ACCEPT

        "-I" inserts at the beginning, so that the second -I actually becomes the first rule in that chain allowing tcp for the linux user named "squiduser" while the very next would be the reject everything rule.

        here i also assume "squiduser" exists, and hope i recall the syntax for owner match correctly.

        then create user accounts within squid for all applications (that support using proxies) with precise acl's to where (the fqdn's) these squid-users are allowed to connect to.

        there are possibilities to intercept regular tcp/http connections and "force" them to go through the http proxy, but if it comes to https and not-already-known domains the programs would connect to, things become way more complicated (search for "ssl interception") like the client program/system needs to trust "your own" CA first.

        so the concept is to disallow everything by iptables, then allow more finegrained by http proxy where the proxy users would have to authenticate first. this way your weather desktop applet may connect to w.foreca.st if configured, but not e.vili.sh as that would not be included in its users acl.

        this setup, would not prevent everything applications could do to connect to the outside world: a local configured email server could probably be abused or even DNS would still be available to evil applications to "transmit" data to their home servers, but thats a different story and abuse of your resolver or forwarder, not the tcp stack then. there exists a library to tunnel tcp streams through dns requests and their answers, a bit creepy, but possible and already prepaired. and only using a http-only proxy does not prevent tcp streams like ssh, i think a simple tcp-through-http-proxy-tunnel software was called "corckscrew" or similar and would go straight through a http proxy but would need the other ond of the tunnel software to be up and running.

        much could be abused by malicious software if they get executed on your computer, but in general preventing simple outgoing connections is possible and more or less easy depending on what you want to achieve

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

    • If nothing else, the constant login attempts from bots will fill up your logs.

      Yeah, this is defintely a scenario that I hadn't considerd.

  • You always need it and you actually use it. The smarter question is when you need to customize its settings. Defaults are robust enough, so unless you know what and why you need to change, you don't.

  • A couple of decades ago, iirc, SANS.org ( IF I'm remembering who it was who did it ) put a fresh-install of MS-Windows on a machine, & connected it to the internet.

    It took SEVERAL MINUTES for it to be broken-into, & corrupted, botnetted.

    The auto-attacks by botnets are continuous: hitting different ports, trying to break-in, automatically.

    I've had linux desktops pwned from me.

    the internet should be considered something like a mix of toxic & corrosive chemicals: "maybe" your hand will be fine, if you dip it in for a moment & immediately rinse it off ( for 3 hours ), but if you leave you limbs dwelling in the virulent slop, Bad Things(tm) are going to happen, sooner-or-later.

    I used to de-infest Windows machines for my neighbours...

    haven't done it in years: they'll not pay-for good anti-virus, they'll not resist installing malware: therefore there is no point.

    Let 'em rot.

    I've got a life to work-on uncrippling, & too-little strength/time left.

    "but I don't need antivirus: i never get infected!!"

    then how come I needed to de-infest it for you??

    "but I don't need an immune-system: pathogens are a hoax!!"

    get AIDS, then, & don't use anti-AIDS drugs, & see how "healthy" you are, 2 years in.

    Same argument, different context-mapping.

    Tarpit was a wonderful-looking invention, for Linux's netfilter/iptables, years ago: don't help botnets scan quickly & efficiently to help them find a way to break-in...

    Anyways, just random thoughts from an old geek...

    EDIT: "when do I need to wear a seatbelt?"

    is essentially the same category of question.

    _ /\ _

    • put a fresh-install of MS-Windows on a machine, & connected it to the internet.

      What version of Windows? Connected how? Through a NAT, or was it through a DMZ connection, or netiher? Was Windows' firewall enabled?

      It took SEVERAL MINUTES for it to be broken-into, & corrupted, botnetted.

      This is highly dependent on the setup, ofc. I can't really comment without more knowledge of the experiment.

      haven’t done it in years: they’ll not pay-for good anti-virus

      Idk, nowadays, 3rd party anti-virus software on Windows doesn't have too much user -- Windows Defender is pretty dang good. If anything, a lot of them are borderline scams, or worse.

      get AIDS, then, & don’t use anti-AIDS drugs, & see how “healthy” you are, 2 years in.

      You don't catch AIDS. HIV is the virus which causes AIDS to develop over time, if untreated. I'm not sure what you mean by anti-AIDS drugs. You could potentially be referring to anti-retroviral medication, or other related medication used to treat HIV, but, again that's treating HIV to prevent the development of AIDS. You could also be referring to PrEP, but, once again, that is for protection against contracting the virus, not the collection of symptoms from a chronic HIV infection which is referred to as AIDS.

      Tarpit was a wonderful-looking invention

      This is interesting, I hadn't heard of this!

      Linux’s netfilter/iptables

      Just a side note: iptables is deprecated -- it has been succeeded by nftables.

      EDIT: “when do I need to wear a seatbelt?”

      is essentially the same category of question.

      Fair point!

  • For me, it's primarily #5: I want to know which apps are accessing the network and when, and have control over what I allow and what I don't. I've caught lots of daemons for software that I hadn't noticed was running and random telemetry activity that way, and it's helped me sort-of sandbox software that IMO does not need access to the network.

    Not much to say about the other reasons, other than #2 makes more sense in the context of working with other people: If your policy is "this is meant to be an HTTPS-only machine," then you might want to enforce that at the firewall level to prevent some careless developer from serving the app on port 80 (HTTP), or exposing the database port while they're throwing spaghetti at the wall wrestling with some bug. That careless developer could be future-you, of course. Then once you have a policy you like, it's also easier to copy a firewall config around to multiple machines (which may be running different apps), instead of just making sure to get it consistently right on a server-by-server basis.

    So... Necessary? Not for any reason I can think of. But useful, especially as systems and teams grow.

    • I’ve caught lots of daemons for software that I hadn’t noticed was running and random telemetry activity that way

      I did the exact same thing recently when I installed OpenSnitch -- it was quite interesting to see all the requests that were being made.

      If your policy is “this is meant to be an HTTPS-only machine,” then you might want to enforce that at the firewall level to prevent some careless developer from serving the app on port 80 (HTTP), or exposing the database port while they’re throwing spaghetti at the wall wrestling with some bug. That careless developer could be future-you, of course.

      That's a fair point!

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

    Agreed. That's mostly BS from people who make commissions from some vendor.

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

    A Firewall might be more advanced than just NAT/poking a hole, it may do intrusion detection (whatever that means) and DDoS protection

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

    Maybe you've a bunch of IoT devices in your network that are sold by a Chinese company or any IoT device (lol) and you don't want them to be able to access the internet because they'll establish connections to shady places and might be used to access your network and other devices inside it.

    #5 is the only one that makes some sense;

    Essentially the same answer and in #3

    If we're talking about your home setup and/or homelab just don't get a hardware firewall, those are overpriced and won't add much value. You're better off by buying an OpenWRT compatible router and ditching your ISP router. OpenWRT does NAT and has a firewall that is easy to manage and setup whatever policies you might need to restrict specific devices. You'll also be able to setup things such as DoH / DoT for your entire network, setup a quick Wireguard VPN to access your local services from the outside in a safe way and maybe use it to setup a couple of network shares. Much more value for most people, way cheaper.

    • A Firewall might be more advanced than just NAT/poking a hole, it may do intrusion detection (whatever that means) and DDoS protection

      I mean, sure, but the original question of why there's a need for a second firewall still exists.

      Maybe you’ve a bunch of IoT devices in your network that are sold by a Chinese company or any IoT device (lol) and you don’t want them to be able to access the internet because they’ll establish connections to shady places and might be used to access your network and other devices inside it.

      This doesn't really answer the question. The device without a firewall would still be on the same network as the "sketchy IoT devices". The question wasn't about whether or not you should have outgoing rules on the router preventing some devices from making contact with the outside world, but instead was about what risk there is to a device that doesn't have a firewall if it doesn't have any services listening.

      Essentially the same answer and in #3

      Somewhat, only I would solve it using an application layer firewall rather than a packet filtering firewall (if it's even possible to practically solve that with a packet filtering firewall without just dropping all outgoing packets, that is).

      just don’t get a hardware firewall

      What is the purpose of these devices? Is it because enterprise routers don't contain a firewall within them, so you need a dedicated device that offers that functionality?

      • I don't know what else is there to answer about the purpose of a hardware firewall.

        Hardware firewalls have their use cases, mostly overkill for homelabs and most companies but they have specific features you may want that are hard or impossible to get in other ways.

        A hardware firewall may do the following things:

        • Run DPI and effectively block machines on the network to access certain protocols, websites, hosts or detect whenever some user is about to download malware and block it;
        • Run stats and alert sysadmins of suspicious behaviors like a user sending large amount of confidential data to the outside;
        • Have "smart" AI features that will detect threats even when they aren't known yet;
        • Provide VPN endpoints and site-to-site connections. This is very common in brands like WatchGuard;
        • Higher throughput than your router while doing all the other operations above;
        • Better isolation.

        An isolated device is the fact that you can then play around with your routers without having to think about the security as much - you may break them, mess some config but you can be sure that the firewall is still in place and doing its job. The firewall becomes both a virtual and a physical and physiological barrier between your network and the outside, there's less risk of plugging a wire on the wrong spot or a apply a configuration and suddenly having your entire network exposed.

        Sure you may be able to setup something on OpenWRT to cover most of the things I listed before but how much time will you spend on that? Will it be as reliable? What about support? A Pi-hole is also another common solution for those problems, and it may work until a specific machines devices to ignore its DNS server and go straight to the router / outside.

        You can even argue that you can virtualize something like pfSense or OPNsense on some host that also virtualizes your router and a bunch of other stuff, however, is it wise? Most likely not. Virtualization is mostly secure but we've seen cases from time to time where a compromised VM can be used to gain access to the host or other VMs, in this case the firewall could be hacked to access the entirety of your network.

        When you've to manage larger networks, lets say 50* devices I believe it becomes easier to see how a hardware firewall can become useful. You can't simply trust all those machines, users and software policies in them to ensure that things are secure.

  • You most likely don’t need on device firewall if your in your home network behind a router that has a firewall. If you‘d disable that firewall as well and one of your devices has e.g. SSH activated using username and password, than there is nothing stopping a "hacker" or "script kiddy" from penetrating/spamming your SSH port and brute force your password. The person than can take over your PC and can e.g. install software for his botnet or install keylogger or can overtake your browser session including all authentication cookies or many other bad stuff.

    If you are using puplic WiFi, I’d recommend a good on device firewall, or better just use a VPN to get an encrypted tunnel to your home (where you would need to open a port for that tho) and go into the internet from there.

    • You most likely don’t need on device firewall if your in your home network behind a router that has a firewall.

      Under what circumstance(s) would one need a device firewall? If I were to guess, I would say that it is when the internet facing device doesn't contain a firewall within it (e.g. some enterprise-grade router), so a dedicated firewall device must exist behind it.

  • It's to stop Genghis Khan from invading your computer.

126 comments