[HN Gopher] OpenSnitch is a GNU/Linux interactive application fi...
       ___________________________________________________________________
        
       OpenSnitch is a GNU/Linux interactive application firewall
        
       Author : dp-hackernews
       Score  : 381 points
       Date   : 2024-08-10 14:15 UTC (1 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | vhguru wrote:
       | Would be great to have Arch and OpenSUSE packages too.
        
         | jiripospisil wrote:
         | There is an official package for Arch Linux. It doesn't ship
         | with the ebpf modules for some reason though (you need to get
         | them separately from AUR).
        
         | diggan wrote:
         | `opensnitch` is in the extra repository on Arch, and
         | `opensnitch-ebpf-module` exists on the AUR.
        
       | amingilani wrote:
       | Is there an open source equivalent for MacOS?
        
         | jiripospisil wrote:
         | There's Lulu based on Apple's Network Extension framework but
         | there are quite a few issues with the framework itself (it will
         | briefly initiate a connection even though there's a deny rule
         | for that address etc).
         | 
         | https://github.com/objective-see/LuLu
        
         | lelag wrote:
         | Yes, there is: Lulu at https://objective-
         | see.org/products/lulu.html.
        
         | eep_social wrote:
         | I tried LuLu and it was okay but I did end up trying and
         | subsequently buying Little Snitch. The level of UX polish
         | wasn't quite there for me with LuLu.
        
           | collinvandyck76 wrote:
           | I also feel the same way re: UX polish. I haven't bought
           | little snitch yet, but was kind of wondering if I even needed
           | to. I've already got a pihole on my tailnet that blocks a
           | fair amount of things, and then ublock origin on firefox to
           | boot. If LS were only like $20 I'd probably just buy it for
           | the pleasing graphs, but otherwise I'm not sure what extra
           | value it adds. There's probably a usecase for it given the
           | other things I have, but perhaps I'm not the target audience.
        
             | eep_social wrote:
             | I felt similarly, waited a long time on the trial, and
             | grabbed it on sale for a good bit off retail after I was
             | sure that it met my needs.
        
       | samlinnfer wrote:
       | I've tried to use it extensively (as an interactive firewall).
       | However there are just some problems (that are not the fault of
       | OpenSnitch) that I'm not even sure that are even solvable.
       | 
       | 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.
        
         | haswell wrote:
         | I've found that by using subdomain wildcards and/or subnets, I
         | build up a stable set of rules pretty quickly and then only
         | have to review requests to new endpoints once in awhile.
         | 
         | 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.
        
           | xyst wrote:
           | IMO - requires a ton of work. Adoption requires updating
           | rules quite often
        
             | haswell wrote:
             | Sounds like that varies widely by person/use case. I've
             | been using this software for a couple years at this point.
             | I don't have to update rules all that often (usually a few
             | rules/week), and when I do, it's usually a 10-30 second
             | detour. The only time it takes more work is if I don't know
             | why something is trying to connect. But that's exactly the
             | scenario I'm targeting, i.e. calling attention to the weird
             | looking connections.
             | 
             | 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.
        
               | BadBadJellyBean wrote:
               | A few rules per week sounds like a lot. I think I am not
               | paranoid enough to micromanage my connections like this.
        
               | haswell wrote:
               | In terms of time spent, that amounts to about one minute
               | per week for me right now. Sometimes less.
               | 
               | 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.
        
               | cam_l wrote:
               | I have found it makes me less paranoid, which is good.
               | 
               | 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.
        
               | mnahkies wrote:
               | Generally I don't get many prompts day to day, if I do
               | it's because something has changed or I'm using a new
               | application and I find it comforting to know what's going
               | on.
               | 
               | 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.
        
               | dotancohen wrote:
               | > 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.
        
               | haswell wrote:
               | Genuinely curious: how/why does that seem too often? I
               | truly don't understand. Have you seen the user experience
               | and what's involved?
               | 
               | 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.
        
               | dotancohen wrote:
               | > 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.
        
               | haswell wrote:
               | I highly recommend you look at the UX before drawing any
               | conclusions in that case, because what you're describing
               | does not resemble the OpenSnitch UX.
               | 
               | 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.
        
               | dotancohen wrote:
               | OK, thanks, I'll give it a shot then. Thank you for
               | insisting ))
        
               | haswell wrote:
               | Worth a shot! The first few days are by far the worst
               | while all of the existing connections are accounted for,
               | but things calm down quickly.
               | 
               | 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.
        
               | dotancohen wrote:
               | Great, thanks, noted.
        
         | chefandy wrote:
         | It's the filter configured per user, or is it system-wide? I
         | know you can filter per-user with IP tables and whatever the
         | newer one is, but I haven't dug that deep into open snitch.
         | Maybe a single trusted user account without a login that you
         | could su into? I wonder if you could also whitelist a VM
         | process and spin up single-use VM sandboxes to use when you
         | want to do a bunch of work like that.
         | 
         | Definitely a minor hassle to set up compared to just saying yes
         | or no to permissions, but it's not complicated, if it works.
        
         | netule wrote:
         | I wonder if there's a way to configure it so that when the
         | parent cmd is a trusted command (say, a bash/zsh owned by the
         | user), it could let the curl command through and otherwise
         | block it. But yeah, that seems like a bit of a hassle.
        
           | akdev1l wrote:
           | Then any process can do `system("bash -c curl
           | malware.attacker")`
        
             | netule wrote:
             | The bash command line wouldn't be the same as the one
             | launched by your terminal, though. But yes, I'm sure there
             | are myriad exploits around something like that.
        
               | ddtaylor wrote:
               | What could work instead is something where you run a
               | command like `opensnitch-context dev` and it would talk
               | to the running daemon to do proper authentication ("do
               | you want to allow this context to be used?") and then
               | hopefully some other magic (cgroups?) to know if the
               | processes are part of that context even if they are
               | sparse/nested child processes.
        
         | phoe-krk wrote:
         | You'd need a firewall that is not just TCP/UDP-aware, but
         | HTTP(S)-aware, and a way for your firewall to sniff on TLS-
         | encrypted traffic.
        
           | diggan wrote:
           | Or be ok with filtering HTTP/TLS traffic based on the domain
           | only, as that part isn't encrypted (the SNI [Server Name
           | Indication]). OpenSnitch should be able to allow/disallow
           | based on that, rather than having to decrypt the TLS part.
        
             | codetrotter wrote:
             | Unless it's using Encrypted SNI.
             | 
             | 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.
        
         | djent wrote:
         | so don't do that. problem solved
        
         | xyst wrote:
         | Might be the same but what if you allow all curl/wget traffic
         | for 'dev' user, but continue to flag any traffic for 'normal'
         | user
         | 
         | 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.
        
           | prmoustache wrote:
           | dev user might be the one you want to protect the best in
           | order to detect some supply chain issues.
        
         | fsflover wrote:
         | The solution that worked for me was to switch to Qubes OS,
         | where everything runs in VMs with strong hardware-assisted
         | isolation.
        
           | irundebian wrote:
           | I switched from Qubes OS to Fedora+Flatpak+Opensnitch.
           | Couldn't make it to run Wayland on my hybrid GPU system
           | (Nvidia). QubesOS drained battery very quickly and since
           | graphics is afaik software rendered, I've gotten into
           | problems in watching HD videos (e. g. a lot of dropped frames
           | on Youtube).
        
             | fsflover wrote:
             | > graphics is afaik software rendered
             | 
             | 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?
        
               | irundebian wrote:
               | I meant Wayland on Fedora for better application
               | isolation.
        
         | a-dub wrote:
         | a sudo like wrapper for this could be pretty cool.
         | 
         | 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.
        
           | psd1 wrote:
           | I'm early in my Linux journey. Would it be a good approach to
           | symlink bash to some new name, say, snitch, then do
           | snitch -c "curl blah.blah"
           | 
           | Is there a better way without writing code?
        
         | cookiengineer wrote:
         | I wish OpenSnitch had a temporary allow feature for things
         | like:
         | 
         | - 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.
        
         | 1vuio0pswjnm7 wrote:
         | This sounds rather silly. If this is really a concern, then
         | "curl" or "wget" can be renamed. I use an application level
         | firewall on mobile and I do not "whitelist" names of programs,
         | I "whitelist" access to certain domain names/IP addresses by
         | certain programs.
         | 
         | 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.
        
         | aflag wrote:
         | You can install a unrestricted version with a new name and
         | alias wget and curl to that in interactive shells
        
         | Kiboneu wrote:
         | It doesn't pin to PID? What if I rename a program to something
         | that has been whitelisted?
        
           | bornfreddy wrote:
           | Including the path? If you can do that, there's bigger
           | problems than the outgoing network communications.
        
           | self_awareness wrote:
           | Kiboneu wrote:
           | 
           | > 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.
        
         | self_awareness wrote:
         | samlinnfer wrote:
         | 
         | > 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.
        
       | mixmastamyk wrote:
       | This is great for catching sloppy apps that make an excessive
       | number of connections. Thunderbird, I'm looking at you.
       | 
       | 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.
        
         | richardlblair wrote:
         | Not to be that guy, because I never really have the time
         | myself. But, I'm sure PRs are welcome
        
           | mixmastamyk wrote:
           | Have thought about it, though haven't used QT in twenty
           | years.
        
       | orkj wrote:
       | Does something like this exist for my phone, android
       | specifically? Any good recommendations?
        
         | Joe_Cool wrote:
         | Sadly all real firewalls need root. I was using AFWall+ for a
         | long time it has neat controls for every app to allow or deny
         | Wifi, Cell or LAN (if you have). It is a iptables/nftables
         | frontend so you can customize the rules to your heart's
         | content: https://github.com/ukanth/afwall Works from Android 2+
         | 
         | 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.
        
           | ignoramous wrote:
           | _ex-AOSP and rethink dns+firewall dev here_
           | 
           | > _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
        
             | yndoendo wrote:
             | I thought parts of the Android OS can by-pass the VPN so
             | the firewall becomes ineffective against blocking Google,
             | OEMs, and others that have root. Wouldn't the VPN API being
             | used as a firewall also prevent one to use a VPN client at
             | the same time?
        
               | khimaros wrote:
               | for the latter, Rethink can be configured to work with
               | eg. a wireguard VPN because it has a built-in wireguard
               | client.
        
             | Joe_Cool wrote:
             | > Note though, Glasswire was recently acquired by another
             | company
             | 
             | 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.
        
               | ignoramous wrote:
               | > _In my experience the "block all non VPN traffic"
               | options in Android don't work reliably. iptables does
               | however._
               | 
               | 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).
        
               | Joe_Cool wrote:
               | IMHO Android's security model is incredibly flawed
               | anyways. I don't even need root to access stuff I
               | shouldn't have access to on my Mediatek based phone
               | because the firmware has tons of gaping security holes
               | anyways.
               | 
               | 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.
        
         | sureglymop wrote:
         | The app "Rethink: DNS + Firewall + VPN" has similar features.
        
           | FireInsight wrote:
           | TrackerControl is great too. Both are FOSS and can be used in
           | the backgroud for using a custom DNS server and blocking
           | certain categories of domains.
        
           | arminiusreturns wrote:
           | I really like Rethink DNS. I have learned many things from
           | watching it (such as I think Signal is compromised by some
           | five-eyes "crossing the border" fuckery.)
        
             | codethief wrote:
             | > such as I think Signal is compromised by some five-eyes
             | "crossing the border" fuckery
             | 
             | Would you mind elaborating?
        
             | sureglymop wrote:
             | I agree with the first sentence. I cannot even begin to
             | comprehend what semantics you were trying to convey with
             | the second sentence however. I am also lacking all context
             | to be able to understand (compromised in what sense, by
             | whom and to what degree? which border? what is "fuckery"
             | defined as?).
             | 
             | 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.
        
         | SparkyMcUnicorn wrote:
         | My non-root solution is to use NextDNS or ControlD with
         | "private DNS" (DNS over TLS).
         | 
         | 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.
        
         | supriyo-biswas wrote:
         | There's netguard[1], although most of the convenience features
         | are behind a small payment.
         | 
         | [1] https://netguard.me
        
           | butz wrote:
           | "Small payment" is an understatement :)
           | 
           | "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 EUR 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."
        
             | bardan wrote:
             | Can confirm that after donating > 7EUR I am still able to
             | unlock pro features on new devices 8 years later
        
               | bornfreddy wrote:
               | And it is also opensource, so you can install it by
               | yourself. But it is worth it (for me) to pay something to
               | support the developer.
        
           | ggeorgovassilis wrote:
           | Netguard is fantastic, although it takes a while to get a
           | safe setup working. I'm blocking traffic by default and get
           | to see all the blocked connection attempts - the extent to
           | which apps transmit data to various parties is depressing.
           | Netguard should be a standard OS feature.
        
           | cam_l wrote:
           | I have heard good things about this one. But i think this one
           | of those no root firewalls that uses the vpn, so I figure
           | this means I can't use a VPN at the same time.
           | 
           | 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.
           | 
           | https://github.com/ukanth/afwall
        
             | ranger_danger wrote:
             | Another issue I have with using the VPN in general is that
             | it breaks Android Auto for me.
        
           | bornfreddy wrote:
           | I didn't want to pay without testing the features first, so I
           | have rebuilt the app (it is opensource) with Pro enabled, so
           | I guess that's an option if you want to avoid payment.
           | Updates are a problem then though. Once I tested it I gladly
           | paid (more than requested) to support the development. I
           | never got around to reinstalling it though, so I'm still on
           | an older version.
           | 
           | 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.
        
         | mikae1 wrote:
         | GrapheneOS can at least block internet traffic for specific
         | apps. But can't do it for port ranges or specific domains.
        
         | JoosToopit wrote:
         | AFWall+
         | 
         | Switched to it from NetGuard mentioned above.
        
       | vlovich123 wrote:
       | How does this compare with something like UFW? Is the main thing
       | a UI to view ongoing activity?
        
         | pull_my_finger wrote:
         | OpenSnitch prompts you when there's network activity. So if
         | random app makes a telemetry call or something, you get the
         | option to white/greylist that connection with granularity, like
         | OK to make a connection to that address from this executable
         | etc, or always OK to this address, and with duration options
         | like once/for 15 seconds, until reboot etc. Once you get over
         | the hurdle of whitelisting the apps you use and trust, it's
         | actually pretty nice and gives you good insight into what your
         | apps/games are doing you otherwise wouldn't have known about.
        
         | zargon wrote:
         | UFW isn't an application firewall, it only blocks/allows port
         | numbers (system-wide), as far as I know.
        
           | irundebian wrote:
           | That's right.
        
       | irundebian wrote:
       | Can recommend it on Fedora over fiddling with firewalld/firewall-
       | config.
        
         | mixmastamyk wrote:
         | How to deal with dnf looking anywhere on the continent each
         | time it wants to update?
         | 
         | https://news.ycombinator.com/item?id=41124755
         | 
         | Could just let it, but would prefer not to.
        
           | nobody9999 wrote:
           | As was mentioned in the thread you linked, use 'baseurl'
           | instead of 'metalink' in the repo definitions (in
           | /etc/yum.repos.d) and set the update server to whichever
           | mirror you like.
           | 
           | There's even a helpful example in each Fedora repo that you
           | can use as a template.
           | 
           | Good luck.
        
             | mixmastamyk wrote:
             | Yep, there's six or eight of those. I don't think it's
             | reasonable to have to change all of them, and it didn't
             | work when I tried.
        
       | stusmall wrote:
       | This is what finally got me over to NixOS. In the past when I've
       | used application firewalls its a lot of set up that often breaks
       | on updates changing paths or I have to redo it all whenever I
       | move to a new computer. Just tons and tons of churn and wasted
       | effort.
       | 
       | 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.
        
         | mubu wrote:
         | Did you achieve this using the OpenSnitch Nix options over at
         | search.nixos.org/options ?
        
           | stusmall wrote:
           | Yup. My configs can be found here:
           | https://github.com/stusmall/nixos
           | 
           | 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
        
             | mubu wrote:
             | Very nice, thanks!
        
       | ranger_danger wrote:
       | I have tried to use it off and on many times, but all the random
       | crashes I get really make it very difficult.
        
       | michaelmrose wrote:
       | Has anyone ever in history had an issue prevented by such a
       | firewall?
        
         | spacebacon wrote:
         | Researching every connection is painstaking at first across
         | various operating systems but a tool like this really helps you
         | get familiar with what is normal and what is not.
        
       | kerkeslager wrote:
       | Is there any plan to port this to MacOS? I use Little Snitch
       | (which this is obviously influenced by) for a while, but really
       | prefer open source (for reasons unrelated to payment).
        
         | SettembreNero wrote:
         | Try LuLu
        
       | meonkeys wrote:
       | I'd love something sorta like this but for Docker containers
       | running APIs or web services. Like:
       | 
       | 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?
        
         | rnmmrnm wrote:
         | just my two cents that netfilter (for which iptables is a
         | frontend) is a kernel subsystem and therefore global to all
         | containers on host.
        
       ___________________________________________________________________
       (page generated 2024-08-11 23:02 UTC)