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?

ShellMonkey ,
@ShellMonkey@lemmy.socdojo.com avatar

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.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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?

ShellMonkey ,
@ShellMonkey@lemmy.socdojo.com avatar

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.

pixelscript ,

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.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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?

pixelscript ,

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

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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.

Is this because the kernel assigns that port to that specific process, so that all traffic at that port is associated with only that process? For example, if you have an SSH server listening on 22, and another malicious porgram decides to start listening on 22, all traffic sent to 22 will only be sent to the SSH server, and not the malicious program?

EDIT (2024-01-31T01:20Z): While writing this, I came across this stackoverflow answer, which states that when a socket is created it calls some bind() function that attaches it to a port. This makes me wonder how difficult it would be for malware to steal the bound port.

pixelscript ,

Is this because the kernel assigns that port to that specific process, so that all traffic at that port is associated with only that process?

Yes, that's what ports do. They split your IP connection into 65,536 separate communication lines, that's the main thing, but that is specifically 65,536 1-on-1 lines, not party lines. When a process on your PC reserves port 80, that's it. It's taken. Short of hacking the kernel itself, it cannot be reassigned or stolen until the bound process frees it.

The SO answer you found it interesting, I was not aware that the Linux kernel had a feature that allowed two or more processes to willingly share a single port. But the answer explains that this is an opt-in parameter that the first binding process has to explicitly allow. And even then, traffic is not duplicated to all listening processes. It sounds like it's more of a "first come first serve" to whichever of the processes are free to read the incoming message at the time it arrives, making it more of a load balancing feature that isn't a useful vector for eavesdropping.

LoveSausage ,

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.

bionicjoey ,

TempleOS doesn't need one

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

Out of curiosity, why do you claim that? I know very little about TempleOS's functionality -- I'm essentially only aware of it's existence and some of it's history.

bionicjoey ,

It doesn't have networking

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

Haha, yeah, a device without networking capabilities would be rather well protected from attacks originating from a network 😜

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

Would you mind defining what you mean by "attacked"?

LoveSausage ,

Scanned for vulnerability and exploited if found

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

I'm not sure if I understand perfectly the scenario that you are describing, but it appears that you are describing a situation in which one has a device behind a NAT that is running a server, which is port forwarded. In this scenario, the attack vector would depend on the security of the server itself, and is essentially independent to the existence of a firewall. One could potentially drop packets based on source IP, or some other metadata, or behaviour that identifies the connections as malicious, but, generally, unless the firewall drops all incoming connections (essentially creating an offline device), a packet filtering firewall will make no difference to thwarting such exploits.

crony ,
@crony@lemmy.cronyakatsuki.xyz avatar

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

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

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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.

crony ,
@crony@lemmy.cronyakatsuki.xyz avatar

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.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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.

This sounds very interesting. This would have to be some forme of additional layer 7 firewall, right (As in it would have to interract with system processes, rather than filtering by network packet at layers 3, and 4)? Does this type of firewall have a specific name, or do you perhaps have some examples? I don't think it would be possible with something like nftables, but I could certainly be wrong.

crony ,
@crony@lemmy.cronyakatsuki.xyz avatar

I honestly only know of a windows one called simplewall.

I used to use it to outright block windows telemetry, microsoft services, apps, ...

It also helped me to save a lot of bandwith in regards to windows and all the stuff that comes preinstalked with it.

I havent searched for one for linux, mostly because 90% of apps I run are cli tools that don't require internet connection, but I'm sure there is probably one that exists.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

OpenSnitch was recommended to me in this comment. I've set it up, and it seems to be working quite well. While doing some research on the topic, I also came across Portmaster, but, while it does look nice, some of it's features are locked behind a paywall, so I'm not interested -- OpenSnitch works just fine!

avidamoeba ,
@avidamoeba@lemmy.ca avatar

Always, as others have said.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

Do you have any supporting arguments/rationale for that claim?

smb ,

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

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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.

smb ,

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

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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

But the point that I was trying to make was that that would then also block you from using SSH. If you want to connect to any external service, you need to open a port for it, and if there's an open port, then there's a opening for unintended escape.

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.

I don't fully understand what this is trying to accomplish.

smb ,

But the point that I was trying to make was that that would then also block you from using SSH. If you want to connect to any external service, you need to open a port for it, and if there’s an open port, then there’s a opening for unintended escape.

now i have the feeling as if there might be a misunderstanding of what "ports" are and what an "open" port actually is. Or i just dont get what you want. i am not on your server/workstation thus i cannot even try to connect TO an external service "from" your machine. i can do so from MY machine to other machines as i like and if those allow me, but you cannot do anything against that unless that other machine happens to be actually yours (or you own a router that happens to be on my path to where i connect to)

lets try something.
your machine A has ssh service running
my machine B has ssh and
another machine C has ssh.

users on the machines are a b c , the machine letters but in small.
what should be possible and what not?
like:
"a can connect to B using ssh"
"a can not connect to C using ssh (forbidden by A)"
"a can not connect to C using ssh (forbidden by C)"
[...]

so what is your scenario? what do you want to prevent?

I don’t fully understand what this is trying to accomplish.

accomplish control (allow/block/report) over who or what on my machine can connect to the outside world (using http/s) and to exactly where, but independant of ip addresses but using domains to allow or deny on a per user/application + domain combonation while not having to update ip based rules that could quickly outdate anyway.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

now i have the feeling as if there might be a misunderstanding of what “ports” are and what an “open” port actually is. Or i just dont get what you want. i am not on your server/workstation thus i cannot even try to connect TO an external service “from” your machine.

This is most likely a result of my original post being too vague -- which is, of course, entirely my fault. I was intending it to refer to a firewall running on a specific device. For example, a desktop computer with a firewall, which is behind a NAT router.

so what is your scenario? what do you want to prevent?

What is your example in response to? Or perhaps I don't understand what it is attempting to clarify. I don't necessarily have any confusion regarding setting up rules for known and discrete connections like SSH.

accomplish control (allow/block/report) over who or what on my machine can connect to the outside world (using http/s) and to exactly where, but independant of ip addresses but using domains to allow or deny on a per user/application + domain combonation while not having to update ip based rules that could quickly outdate anyway.

Are you referring to an application layer firewall like, for example, OpenSnitch?

smb ,

This is most likely a result of my original post being too vague – which is, of course, entirely my fault.

Never mind, and i got distracted and carried away a bit from your question by the course the messages had taken

What is your example in response to?

i thought it could possibly help clarifying something, sort of it did i guess.

Are you referring to an application layer firewall like, for example, OpenSnitch?

no, i do not conside a proxy like squid to be an "application level firewall" (but i fon't know opensnitch however), i would just limit outbound connections to some fqdn's per authenticated client and ensure the connection only goes to where the fqdns actually point to. like an atracker could create a weather applet that "needs" https access to f.oreca.st, but implements a backdoor that silently connects to a static ip using https. with such a proxy, f.oreca.st would be available to the applet, but the other ip not as it is not included in the acl, neither as fqdn nor as an ip.
if you like to say this is an application layer firewall ok, but i dont think so, its just a proxy with acls to me that only checks for allowed destination and if the response has some http headers (like 200 ok) but not really more. yet it can make it harder for some attackers to gain the control they are after ;-)

smb , (edited )

so here are some reasons for having a firewall on a computer, i did not read in the thread (could have missed them)
i have already written this but then lost the text again before it was saved :( so here a compact version:

  • having a second layer of defence, to prevent some of the direct impact of i.e. supply chain attacks like "upgrading" to an malicously manipulated version.
  • control things tightly and report strange behaviour as an early warning sign 'if' something happens, no matter if attacks or bugs.
  • learn how to tighten security and know better what to do in case you need it some day.
  • sleep more comfortable when knowing what you have done or prevented
  • compliance to some laws or customers buzzword matching whishes
  • the fun to do because you can
  • getting in touch with real life side quests, that you would never be aware of if you did not actively practiced by hardening your system.

one side quest example i stumbled upon:
imagine an attacker has ccompromised the vendor of a software you use on your machine. this software connects to some port eventually, but pings the target first before doing so (whatever! you say).
from time to time the ping does not go to the correct 11.22.33.44 of the service (weather app maybe) but to 0.11.22.33 looks like a bug you say, never mind.

could be something different.
pinging an IP that does not exist ensures that the connection tracking of your router keeps the entry until it expires, opening a time window that is much easier to hit even if clocks are a bit out of sync.

also as the attacker knows the IP that gets pinged (but its an outbound connection to an unreachable IP you say what could go wrong?)

lets assume the attacker knows the external IP of your router by other means (i.e. you've send an email to the attacker and your freemail provider hands over your external router address to him inside of an email received header, or the manipulated software updates an dyndns address, or the attacker just guesses your router has an address of your providers dial up range, no matter what.)

so the attacker knows when and from where (or what range) you will ping an unreachable IP address in exact what timeframe (the software running from cron, or in user space and pings at exact timeframes to the "buggy" IP address)
Then within that timeframe the attacker sends you an icmp unreachable packet to your routers external address, and puts the known buggy IP in the payload as the address that is unreachable. the router machtes the payload of the package, recognizes it is related to the known connection tracking entry and forwards the icmp unreachable to your workstation which in turn gives your application the information that the IP address of the attacker informs you that the buggy IP 0.11.22.33 cannot be reached by him. as the source IP of that packet is the IP of the attacker, that software can then open a TCP connection to that IP on port 443 and follow the instructions the attacker sends to it. Sure the attacker needs that backdoor already to exist and run on your workstation, and to know or guess your external IP address, but the actual behaviour of the software looks like normal, a bit buggy maybe, but there are exactly no informations within the software where the command and control server would be, only that it would respond to the icmp unreachable packet it would eventually receive. all connections are outgoing, but the attacker "connects" to his backdoor on your workstation through your NAT "Firewall" as if it did not exist while hiding the backdoor behind an occasional ping to an address that does not respond, either because the IP does not exist, or because it cannot respond due to DDos attack on the 100% sane IP that actually belongs to the service the App legitimately connects to or to a maintenance window, the provider of the manipulated software officially announces. the attacker just needs the IP to not respond or slooowly to increase the timeframe of connecting to his backdoor on your workstation before your router deletes the connectiin tracking entry of that unlucky ping.

if you don't understand how that example works, that is absolutely normal and i might be bad in explaining too. thinking out of the box around corners that only sometimes are corners to think around and only under very specific circumstances that could happen by chance, or could be directly or indirectly under control of the attacker while only revealing the attackers location in the exact moment of connection is not an easy task and can really destroy the feeling of achievable security (aka believe to have some "control") but this is not a common attack vector, only maybe an advanced one.

sometimes side quests can be more "informative" than the main course ;-)
so i would put that ("learn more", not the example above) as the main good reason to install a firewall and other security measures on your pc even if you'ld think you're okay without it.

lemmyreader ,

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.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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.

possiblylinux127 ,
@possiblylinux127@lemmy.zip avatar

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.

c0mbatbag3l ,
@c0mbatbag3l@lemmy.world avatar

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

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

What is "JFC"? I'm not familiar with this acronym.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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.

possiblylinux127 ,
@possiblylinux127@lemmy.zip avatar

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

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

Of course there is risk in exposing a service to the internet; a service open to the internet has a far greater potential attack surface, so there is a greater chance that an existing vulnerability in the exposed service gets exploited. But that is not an argument against the practice of port forwarding -- you just need to make sure that you take adequate precautions to mitigate risk. You do realize that, to be able to access a service from the internet, you need to expose it to the internet, right?

possiblylinux127 ,
@possiblylinux127@lemmy.zip avatar

The problem is when you expose your server to the entire internet. It only takes a few minutes for the bots to find you.

Honestly you should use a mesh VPN instead.

Kalcifer OP , (edited )
@Kalcifer@sh.itjust.works avatar

The problem is when you expose your server to the entire internet. It only takes a few minutes for the bots to find you.

I mean, sure, but the existence of bots doesn't immediately guarantee that a given service will be compromised; simply take precautions to ensure that the exposed services are secure, that the rest of the network, and the device itself are adequately protected, etc.

Honestly you should use a mesh VPN instead.

In order to solve what problem, specifically?

ShittyBeatlesFCPres ,

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.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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.

Bitrot ,
@Bitrot@lemmy.sdf.org avatar

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.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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.

Are you referring to a NAT?

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.

It seems that you are using more of a general interperetation of the term "firewall" rather than something more specific like a packet filtering firewall (which is more of the focus of my post). Am I correct In my interperetation?

Bitrot ,
@Bitrot@lemmy.sdf.org avatar

No, I was referring to a firewall, how many ports are open on one versus a random user's device?

My response is general to any firewall as you did not specify. They go all the way into deep packet inspection and intrusion detection (blocking exploitation of your webserver). NGFWs have extensive capabilities beyond packet filtering.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

No, I was referring to a firewall

A NAT is a type of firewall.

how many ports are open on one versus a random user’s device?

I don't understand the wording of this question.

NGFWs have extensive capabilities beyond packet filtering.

Interesting. Do you have any recommendations for software, or further reading on the topic?

MajorMajormajormajor ,

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?

Bitrot ,
@Bitrot@lemmy.sdf.org avatar

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.

MajorMajormajormajor ,

My setup is pretty basic, only thing I have is a media server accessed locally, and a pi running pihole and pivpn that has a port forwarded on my router for remote access. The pi has password login disabled, and the port forward is set to the static IP set for the pi with my router. The router has the firewall set, but nothing on any other machine. Do I need more?

YIj54yALOJxEsY20eU ,

What service do you have forwarded? Do you have any devices on your lan you don't 100% trust?

I have a similar set up only forwarding a wire guard vpn port. I live alone and fully trust every device on my LAN, so I let my router take care of the firewall and dont have any firewalls on the devices on my lan.

Some will still argue this is bad practice but I really have no desire to toggle firewall rules every time I want to expose a port while I'm developing/testing software. If someone cracks wireguard then I don't think they will risk exposing the industry halting 0 day to run a crypto miner on my raspberry pi.

IOT and friends get the guest wifi.

MajorMajormajormajor ,

wire guard vpn port

This is the only thing forwarded. As for devices the worst offender would be my Roku TV but I'm not sure how much of a security threat that actually would be. More of a privacy threat, hence running pihole.

YIj54yALOJxEsY20eU ,

Any way you could put the roku on guest wifi or does pihole let you block all outgoing traffic? Something like that would make me a little hesitant. My lan has my graphene os device, 3 computers running debian, and an iot smart switch I flashed myself.

Like you said, more of a privacy concern than anything.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

but I’m not sure how much of a security threat that actually would be. More of a privacy threat, hence running pihole.

It is important to note that being unaware of something's level of security is not an argument that it is more secure, or not worthy of scrutiny.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

For most people at home their router also does firewalling and NAT, and that is enough.

It is important to note (as was pointed out by others in this thread) that one must also consider threats emanating from within the LAN, as well: Do you have guests that you allow onto your network with potentially un-vetted devices? Do you have other network-capable devices connected to your network that you cannot guarantee their security? Can you guarantee that there are no unintended services with potential security vulnerabilities listening to ports on your device? If so, it is worth considering, at the very least, a packet filtering firewall, e.g. nftables, and if you cant trust the services running on your device, perhaps also an application layer firewall like OpenSnitch.

possiblylinux127 ,
@possiblylinux127@lemmy.zip avatar

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

treadful ,
@treadful@lemmy.zip avatar

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.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

(friendly wrapper on iptables)

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

rwhitisissle ,

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.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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.

rwhitisissle ,

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.

They also would not realistically be doing anything that would cause open ports on their machine to serve data to some external application. It's not like someone can just "hack" your computer by picking a random port and weaseling their way in. They have to have some exploitable mechanism on the machine that serves data in a way that's insecure.

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.

I am assuming that there's a hierarchy of needs in terms of maintaining any Linux system. Whenever you learn how to use something (and you would have to learn how to use a firewall), you are sacrificing time and energy that would be spent learning something else. Knowing how your package manager works, or how to use systemctl, or understanding your file system structure, or any number of pieces of fundamental Linux knowledge is, for a less technically sophisticated user, going to do comparatively more to guarantee the longevity and health of their system than learning how to use a firewall, which is something capable of severely negatively impacting your user experience if you misconfigure it. In other words: don't mess around with a firewall if you don't know what you're doing. Use your time learning other things first if you're a not technically sophisticated user. I also don't exactly know what "mistakes" you'd be mitigating by installing a firewall if you aren't binding processes to those ports (something a novice user should not be doing anyway).

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.

You just wrote that "One’s own mistakes could certainly be interpreted as a potential threat, and are, therefore, worthy of mitigation." The best way of mitigating mistakes is by not making them in the first place, or creating a scenario in which you could potentially make them. Prevention is always better than cure. You should never open ports on your local network. Ever. I don't care if you have firewalls on everything down to your smart thermostat - if you need to expose locally hosted services you should be maintaining a cloud VM or similar cloud based service that forwards connections to the desired service on your internal network via a VPN like Tailscale. Or, even better, just put Tailscale's service on whatever machine you're using that needs access to your personal network. And, yes, if you're doing things like that, you would also want robust firewall protections everywhere. But the firewall simply isn't ever "enough."

Anyway, just my 2 cents. The more you know and do, the greater steps you should take to protect yourself. For someone who knows very little, the most important thing that can help them is knowing more, and there is a hierarchy of learning that will take them from "knowing little" to "knowing much," but they shouldn't/don't need to concern themselves with certain mechanisms before they know enough to reliably use them or mitigate their own mistakes. That said, if you are a new user, you're probably installing a linux distro that already comes with its own preconfigured firewall that's already running and you just don't know about it. In which case, moot point. If you're not, though, I'm assuming your goal is learning linux stuff, in which case, I've gone into that.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

They also would not realistically be doing anything that would cause open ports on their machine to serve data to some external application.

They may not explicitly do it, no, but I could certainly see the possibility of the software that they use having such a vulnerability, or even a malicious bit of software inadvertently being installed on their device.

In other words: don’t mess around with a firewall if you don’t know what you’re doing. Use your time learning other things first if you’re a not technically sophisticated user. I also don’t exactly know what “mistakes” you’d be mitigating by installing a firewall if you aren’t binding processes to those ports (something a novice user should not be doing anyway).

This sort of skirts around answering the question.

The best way of mitigating mistakes is by not making them in the first place

But mistakes will be made all the same.

Prevention is always better than cure.

This is exactly the point that I am trying to make. Having contingencies in place on the off chance that something doesn't go as expected could certainly be interpreted as "prevention".

You should never open ports on your local network. Ever.

What would be the rationale for this statement?

if you need to expose locally hosted services you should be maintaining a cloud VM or similar cloud based service that forwards connections to the desired service on your internal network via a VPN like Tailscale.

I'm not sure that I understand what issue that this would solve. Would the malicious connections not still be forwarded through the VPN to the service? I am quite lacking in knowledge on Tailscale, and how related infrastructure is used in production, so please pardon my ignorance.

atzanteol ,

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.

treadful ,
@treadful@lemmy.zip avatar

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.

c0mbatbag3l ,
@c0mbatbag3l@lemmy.world avatar

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.

utopiah ,

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.

Feathercrown ,

Can confirm. As an example, I'm developing a game server that runs a raw socket connection over the Telnet port. Within 10 minutes of opening the port, I reliably get requests trying to use Telnet to enable command mode or login as admin. People are constantly scanning.

mvirts ,

Ya. And sometimes hosting companies run active scans on customer machines. I get a crazy number of login attempts over ssh. I ❤️ fail2ban

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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.

utopiah ,

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.

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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.

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.

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

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.

Paragone ,

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.

_ /\ _

Kalcifer OP ,
@Kalcifer@sh.itjust.works avatar

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!

conorab ,

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.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • linux@lemmy.ml
  • test
  • worldmews
  • mews
  • All magazines
    •