OpenSnitch is a GNU/Linux interactive application firewall
github.com
github.com
For example, supposed I run `curl` on the terminal, I can either always decide on a case-by-case basis to allow it thru, or I'm required to whitelist it permanently. Once I've whitelisted generic tools like `curl` or `wget`, then the floodgates are really open, since any malware that have compromised my machine can just use `curl` or `wget` to get to the internet without hitting the firewall.
To me, the peace of mind knowing that I’ll be prompted to allow new access is worth the initial hassle. And once the habit is built, it’s pretty easy to manage.
Editing to add: I also use expiring rules regularly. Maybe I trust an installer and want to let it do its thing. So I open it up with a rule for the executable expiring in the near future (options include: forever, until reboot, for the next 30s, for the next 5 mins, etc). This can drastically simplify some tasks if there are a large number of endpoints for some reason and avoids leaving a hole open permanently.
My use cases are general productivity, development on side projects and a variety of software experiments, gaming, and some local AI stuff.
I also don’t see this as a ton of work. Rules are 99% pre-configured for you and all you have to do is choose the scope and duration of the rule and whether to reject or allow.
I’ll admit it’s annoying once in awhile if there’s a major update to software that spawns a bunch of new rules, but once I get past the feeling of being annoyed, it’s really an extremely simple and quick process.
Really have to emphasize the habit creation part. After I stuck with it for a few weeks, it became second nature and I stopped getting annoyed for the most part. I consider this a worthwhile habit to build if you’re trying lots of code/libraries and want to know what’s phoning where.
The user experience is streamlined, and adding rules involves responding to a dialog that automatically pops up when a connection is attempted. UX is key here and this would be a very different story if you had to go into a separate rule management interface every time.
Regarding paranoia, I don’t see it that way. Supply chain attacks are alive and well, and if you’re running other people’s code on a regular basis, this is a low cost precautionary measure. I totally recognize that not everyone has the same risk profile or tolerance.
You can make rules based on host, process arguments, etc so it's pretty flexible for allowing stuff you consider safe and staying out the way.
Long ago I used zonealarm on windows and it's a pretty similar ux to that.
I still use firejail or docker for anything that might be sketchy, but it's been super interesting seeing what trusted applications are doing. For example I was a bit shocked that the gnome calculator app was making network requests but it turned out it was for currency exchange rates.
In using it for a while, I have only found a few pieces of software trying to access places I don't expect and don't approve of (quite a few more that I do expect, but don't approve of). And none of them seemed to be actively malicious, just misbehaved or poorly configured.
> I don’t have to update rules all that often (usually a few rules/week)
I think that we have different definitions of "all that often". Even twice a week would be too often for me.How do you feel about other common permission prompts, e.g. location, microphone, camera, share your screen, run as privileged user, etc? I appreciate being asked about those things and I put this in a similar category.
> Genuinely curious: how/why does that seem too often?
I want to work, not manage my work station.I don't mind configuring things, my dotfiles are the product of 25 years of tweaking. But having to tweak anything multiple times per day is not going to help me work, it is going to hinder my work.
The experience is much closer to the other common permission prompts I mentioned which is why I asked how you feel about them.
As a fellow multi-decade dotfile tweaker, that experience isn’t comparable and is not a good model for judging this tool.
One thing I wished I knew sooner was that the square [+] button on the rule dialog opens more fields on the form for editing.
This makes it super easy to create a single wildcard rule e.g. when timesyncd tries to hit an ntp server for the first time, I expand the autogenerated rule that pops up to include all subdomains like *.ntp.domain.tld so I don’t have to keep creating rules for the other ntp servers. I’ve gotten more efficient over time this way.
for dev work run 'su -c curl … dev'
But if malicious program in normal user space is running, then app firewall flags curl and wget use appropriately.
It would be annoying to input password every time so maybe setup PAM to use yubikey or biometric? Also make sure this user cannot login and does not have a password.
The easiest way to stop programs/malware from phoning home IME is to deny access to DNS. I have been doing this for decades and it still works flawlessly. "99%" of the time programs/malware that phone home rely on DNS, not "hard-coded" IP addresses. And it is quite easy for me to detect the rare case of a program/malware that does not need DNS.
With DNS I "whitelist" certain domain names. In fact today I do not even use a locally-served zone file with the IP addresses I need (the whitelist); a forward proxy handles the domain to IP address mapping, the whitelist loaded by the proxy is a text file, like a zone file but simpler.
> However there are just some problems (that are not the fault of OpenSnitch) that I'm not even sure that are even solvable.
Those problems are solvable. Some "big" EDRs, which happen to work in a similar way, allow to declare the parent/child relationship of the executables to block, i.e. it should be possible to declare that if "curl" is spawned, and if by walking the parent list we encounter a process called "/usr/bin/trusted", then allow this curl invocation. This action would allow running "curl" from bash scripts, as long as the bash script has "/usr/bin/trusted" as a parent.
https://www.cloudflare.com/en-gb/learning/ssl/what-is-encryp...
Or, also, not using SNI at all.
But still, you can probably correlate DNS requests with connections to IP addresses in many cases. Although if the program uses DNS over HTTPS (DoH) like several programs do now then the DNS record is also not known.
still will capture when processes unexpectedly try to connect to the network for the first time and there is some value in that. even if the popups aren't great.
snitch -c "curl blah.blah"
Is there a better way without writing code?Yes, this is accurate (for security reasons). However you still should not have serious problems with Youtube: https://forum.qubes-os.org/t/hd-video-playback-on-qubes-os-o... (see also a few next posts).
How to fix it if you do have problems: https://forum.qubes-os.org/t/improve-video-playback-performa...
Why did you need Wayland on Qubes?
> It doesn’t pin to PID? What if I rename a program to something that has been whitelisted?
That's a valid question. It should allow/disallow executables by hashing the executable file (not even the device id + inode), not by comparing the paths. Also pinning the PID also isn't good, since pid is temporary.
- allow a specific parent structure, e.g. when the python interpreter is invoked by a different parent command
- allow a specific process ID temporarily until the process is killed (both with allowing/disallowing child processes)
- allow a specific target port range for games, and not only a specific port in the rulesets.
...because I feel that 99% of the annoying dialogues could have been avoided with this.
Definitely a minor hassle to set up compared to just saying yes or no to permissions, but it's not complicated, if it works.
By integrating with the package manager that hasn't been an issue. Once I got through the initial work of setting up my whitelists I just have a little bit of effort each time I add a new package to my nix configs. If I don't want to take on the effort of adding a whitelist to my nix config, I can just add a temporary whitelist that lasts until the next reboot.
It was a steep learning curve and a lot of work, but now its a breeze to maintain.
I tend to put all the random grab bags rules needed for basic functionality in the opensnitch.nix module. If a package needed rules it gets a module and they go in there. Check the signal.nix module for a good example
I like it, but it has a small annoyance in that the temporary rules that have expired don’t get deleted or marked in the interface. So I have to restart the gui once in a while to clear them.
https://news.ycombinator.com/item?id=41124755
Could just let it, but would prefer not to.
There's even a helpful example in each Fedora repo that you can use as a template.
Good luck.
Which isn't very nice or helpful. So I considered mentioning (again) that there are examples that just need to be un-commented and the example url replaced. Which is perhaps a half-dozen keystrokes per file, or maybe a dozen to replace them all at once. As such, if you are, in fact, that lazy, I guess it really does suck to be you.
Hosting your own private mirror[0] is also an option. But then, you'd need a couple dozen more keystrokes (and maybe ten or fifteen minutes of set up), so I'm guessing that's a no go either.
I suppose you could, alternatively, add all the mirrors near you (by your own estimation) to an OpenSnitch allow list and you wouldn't have to change the repo definitions at all. DNF with metalinks will attempt to connect to additional mirrors until it can complete the current request.
That said, I'm guessing setting that up is much more work than deleting, then adding a '#' character (uncomment the baseurl and comment out the metalink) and replacing a URL (the mirror you wish to use).
And since you're that lazy, I imagine that's a no go too.
[This isn't really relevant and I should probably remove it, but I kind of like it there. And you're welcome]
I'd further add that your 'complaint' is an idiotic one at that. So you're lazy and dumb. Good combination friend.
[End not relevant but not deleted text.]
As I mentioned previously, although this time I'm being more expansive in my admonition: Good luck. It seems like you're gonna need it.
[0] https://fedoraproject.org/wiki/Infrastructure/Mirroring#How_...?
Edit: Added some additional thoughts.
But, I did find you being an ass amusing.
containerA: all outbound traffic allowed
containerB: no outbound traffic allowed, except to reply to a client
containerC: may only reach out to updates.example.com
Is this just per-container iptables? I could wedge iptables into existing images but it seems like a lot of work.
Or maybe something with iptables on the host?
An alternative android root only option is afwall+ which allows blocking on lte, WiFi, lan, and VPN separately, and script access to iptables. Not sure how actively developed it is, but it seems to work ok.
*edit: Seems to still be active, open source, and available on fdroid too.
NetGuard is simply awesome. The piece of mind when I know which servers the apps are contacting, and being able to block their access to the net by default, is just great. The rules could be made a bit more easily adjustable (it would be nice if I could block `*.firebaseinstallations.googleapis.com` everywhere, even if other traffic is allowed for the app), but I'm just nitpicking now. Highly recommend it.
"You can get all current and future NetGuard pro features (including updates) without Google Play services for the GitHub or F-Droid version by a one time donation of € 0.10 or more. If you donate 7 euros or more, you can activate the pro features on all Android devices you personally own, else you can activate the pro features one time only."
Without root only VPN solutions like Adguard are available.
EDIT: if you want neat stats: Glasswire has an Android version. I have only used the beta so I have no idea about its current state. Might be worth checking out though.
> Sadly all real firewalls need root
What do you mean by a "real" firewall? It is very much possible to build a userspace firewall in Android using the VPN APIs.
On Android, ROMs like GrapheneOS, Lineage, and CalyxOS have firewalls built-in.
> Glasswire has an Android version
Note though, Glasswire was recently acquired by another company: https://archive.is/KW2R3
Ah that's why the premium stuff is now free. I was wondering. Let's hope it's not the first sign of enshittification.
> What do you mean by a "real" firewall?
In my experience the "block all non VPN traffic" options in Android don't work reliably. iptables does however.
It's a sad state that you cannot even set a static IPv6 on Android without root.
Both (iptables/nftables and VPN APIs) have to be enforced by the Linux Kernel, which is subject to the same "Androidisms", if that makes sense.
root, in fact, opens up a gaping hole in that, it totally compromises Android's security model. IMO, it isn't worth to root Android just to run iptables (just because it seems like iptables is what makes a firewall).
I think device you don't have root on isn't really yours and should be treated as a lease.
But you are right, when Wifi/Data is on at boot even the -tables might not get updated fast enough so stuff might get through.
I appreciate you trying to add to the discussion but in this case you leave me with way more questions than I started out with which I personally perceive as an unwanted mental overhead.
What I mean is by watching the IPs, I see a lot of cross-border ingress/egress when it shouldn't be necessary. It's not proof, but an indicator of probability to me, that echelon style mechanisms are being used.
If you are unaware of echelon and related programs, essentially, since it's illegal for the US (officially at least) to spy on it's own citizens without a warrant, instead they let an "ally" country like the UK spy on Americans and then "share the data", essentially another abuse of third party doctrine.
I hope that helps clarify.
Would you mind elaborating?
Switched to it from NetGuard mentioned above.
Doesn't stop direct IP connections, but it's good enough.
I also have the CLI installed on OpnSense so DoH is enforced for all devices on my LAN as well.
It isn't something I'd recommend for everyone, because it is a lot of work and faffing around, but be extremely effective if you are willing to invest in managing it correctly.