But does it live up to such a description? Going into it, I at first had configured OpenSnitch to intercept and restrict connections based on user ID, port number and destination address. But this proved to generate far too much notification activity. Excessive notification dialogues have a tendency to condition users to simply make exceptions uncritically in the wake of fatigue. Reducing these interceptions down to just destination addresses is much more practical while preserving the granularity that OpenSnitch makes possible.
And, like with other interactive firewalls, there is a brief training period where your most frequently accessed net resources must first be committed to persistent rules as you find you will need them. Once these are established, OpenSnitch shouldn’t generate any notifications when there is no operator input.
I find the default rules of allowing, in full, the connections made per application to be too relaxed. However, the default is probably sane for a more typical end user device. Extending a comparison with uMatrix, the “scope” of OpenSnitch is comprised of applications, rule duration and optionally destination addresses, ports, process & user IDs. Permitting domains and subdomains is also independently possible via regular expressions.
The limitation in this “scope”, however, is that OpenSnitch has no context awareness for different functions within the same application (e.g. browser tabs). Programs as sophistocated as Firefox will continue to require a firewall like uMatrix.
Blacklisting is as straightforward as pointing to a single text file containing the addresses to be blocked, and prepending the name with zeroes to ensure it gets parsed before other rules. One benefit is that this allows IP addresses to also be blocklisted and without having to rely on something like dnsmasq. It may be ideal to double-dip the list we generate with hosts-blocking.
One should be certain to avoid globally allowing traffic from interpreters and intermediaries like Python. If you allow Python executable because you are downloading with yt-dlp, it will then enable any Python program to access the network. Instead, select “From: command line” when building rules for such applications. This should IMO be made the default behavior when launching such things.
Since dipping my toes in with OpenSnitch, it has caught a few blind spots in my buildout. For example, despite de-crappifying Firefox with a user.js template, one may find connections still being opened to firefox.settings.services.mozilla.com. Or Gnome calculator connecting to \www.imf.org! Another reason to prefer simpler programs like GNU bc. Or linear video editors that phone home for update checks. Now such leaks can conveniently be discovered and plugged.
Another caveat to look out for is with federated ActivityPub sites in combination with OpenSnitch and uBlock Origin. Due to the distributed nature of federation, when uBlock Origin has “Uncloak canonical names” enabled, a DNS lookup for every domain called by a page will be made. This iniates an OpenSnitch dialogue popup for each, regardless of whether that domain had already been blocked by another extension or whether or not you had opened any links to said third party domains.
One way to work around this is to temporarily disable “Uncloak canonical names” when using a federated site. It is lazy and opens some opportunity for adtech tagging, but avoids being endlessly bombarded with intercept notifications. This is no failing of OpenSnitch, rather it is a sign that OpenSnitch is doing exactly what it advertises on the packaging. The issue stems from uBlock Origin’s lack of contextual awareness as to whether a domain is being blocked by anything other than itself. This same blindness has caused leaks and conflicts before.
OpenSnitch is more highly interactive or “needy” by way of it being realtime. Browser addons, in comparison, cleanly know when a page load occurs and control for it. Network requests are more spontaneous and can originate from a multitude of sources. It is best when going into OpenSnitch to already know your system and which services, daemons and common programs require network connectivity. It can be overly needy when first configured, but once beyond the initial training period becomes a godsend for maintaining silent running on the network. Every request leaving your computer (well, not ICMP/IGMP, more on that later) is fully permissioned with least level privilege default deny sanity.
A more in depth configuration and usage guide will be made up for the ‘hardening’ family of articles. All info subject to change as both OpenSnitch and my own config findings develop.