Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
OpenSnitch in Debian ready for prime time (skolelinux.org)
224 points by pabs3 on May 14, 2023 | hide | past | favorite | 31 comments


As a huge fan of simplewall [0] by Henry++ on Windows, I'm looking forward to testing OpenSnitch on Debian, it looks like it could be the former's counterpart.

[0]: https://github.com/henrypp/simplewall


I had no idea this existed and I’m glad it’s been shared here. I’ve been using Windows Firewall Control [0] and for most things it’s been decent, but it can’t seem to create usable rules for some store apps (Age of Empires IV in particular), and I’d prefer something open source and actively maintained. Definitively going to give this a try.

- [0] https://www.binisoft.org/wfc


interesting. will definitely check this out.

and for TFA, that's also nice. and i think, if it works on debian, it could be made work on vast majority of other distros.


Glasswire[0] is good too, albeit it's commercial/paid software. It has a good Android app and allows me to block malicious/privacy-invasive outbound connections from various apps.

[0] https://www.glasswire.com/


The founders seem to have sold Glasswire / SecureMix to some Italian firm: https://archive.is/tQLfK


There's also Portmaster[0], which is open-source and supports both Windows and Linux.

0: https://safing.io/


Looks really neat! Thanks for posting it


I use OpenSnitch on Linux which is great, and if you are looking for similar software for Windows I can recommend simplewall.

https://github.com/henrypp/simplewall


I've been using OpenSnitch on Linux for some time now as well. While the user interface can be finicky at times, it's generally working very well. My biggest annoyance would be creating robust rules for applications using runtimes like Python, Java, Node, Electron or even Wine. After a bit of trial and error, I often end up with a relatively complex regular expression for the specific command and its possible parameters, that may or may not work for all future invocations.


Opensnitch is a great tool, and fits well particularly as part of a defense in depth strategy to secure your machines from telemetry and ads by including other tools like adblock, no script, and hblock.

I predict in the coming years the sorts of invasive surveillance capitalism we see today will in most cases become too economically unviable to be considered worthwhile outside a handful of closed ecosystems.


Huge news! The only way I knew to restrict apps to specific domains under Linux was to create a user group, assign iptable rules to that group, and then run the app under that user group. Works (kind of), but was clunky to setup and run. Happy that OpenSnitch exists!


You can use network namespaces too. As a reference, here is my torrent setup:

  ip netns add torrent
  ip link add wg1 type wireguard
  ip link set wg1 netns torrent
  ip -n torrent addr add 10.67.124.111/32 dev wg1
  ip netns exec torrent wg setconf wg1 /etc/wireguard/wg1.conf
  ip -n torrent link set wg1 up
  ip -n torrent route add default dev wg1
  ip netns exec torrent ip link set dev lo up

  ip netns exec torrent transmission-daemon -f 2>&1
AFAIK it's pretty bulletproof. But for good measure I also have transmission configured to only listen on the wireguard address.


Network namespaces are amazingly powerful but every guide I can find seems to include a whole bunch of manual IP address management (either through virtual ethernet pairs or through VPNs). The guides also seem to skip over IPv6 in many cases, which is another downside I've noticed.

Is there a tool out there to manage these namespaces automatically? I'd like to isolate applications from each other or put them in groups together, but I really don't want to deal with writing scripts for every single application.


There is a pull request adding network namespace support to systemd-networkd: https://github.com/systemd/systemd/pull/14915

I have read that some use NetworkManager by running a whole separate instance of it in their netns, along with a a D-Bus broker running in there too for clients to communicate with NM.


I use systemd-nspawn to create test containers so I can muck with the internals without dealing with docker cp and exec commands. The containers themselves are just directories sitting in a filesystem.

I ended up writing a shell script to handle setting up a bridge, launching the container with systemd-nspawn and kick off commands to bring up the virtual ethernet interfaces inside the container and handle some other housekeeping

systemd-nspawn with systemd-network/resolve/etc can automatically manage the IP addresses for you. I'm using it as a wrapper around cgroup/netns commands.

One of these days, I will remove the dependency on systemd-nspawn so that I can use it on Linux systems without systemd or docker.


I haven't been able to find a solution for this either. Most people seem to just use docker for this and just deal with all the baggage that comes with it.


you can just disable ipv6 in kernel command line options and call it a day

automation indeed sucks


I agree that namespaces are pretty awesome functionality for this, but I've been burnt too many times by bespoke on-host configurations to put much stock in them. Plus they only work for the single host, and do nothing about the myriad of Internet of Trash devices.

I keep all my routing complexity contained to one (virtual) machine with extensive nftables rules, that functions as the house router. It has a table with each host and the network horizon it can see. Then I create a virtual machine for each activity that needs a separate horizon.

The one thing I'm missing is some way of securing the binding of hosts to addresses. Most switches/devices don't support ethernet authentication. I could do something like fine grained VLANs and keeping track of what is connected to what, but that seems like a huge pain in the ass.


Just a caveat: the one thing that will not be found in the Debian version that is in MacOS is:

ability to filter by incoming port and process ID combined. This is a Linux netfilter limitation.


> ability to filter by incoming port and process ID combined

Considering Process ID almost always changes, is that a significant limitation? I can think of one use case when it can be useful is when you want to apply the rule temporarily until the process is restarted.


When working with default deny firewall rulesets, inbound port by PID is an essential rule mechanism.


I still don't get it - how do you define rules by PID and make it work after the next reboot? Won't the PID change for the process in question? I assume by PID we are talking about the same Process ID that we can see in "ps"


It may not be obvious but one (lesser) application is to block all ports to PID 1 ... for logging purpose.

Most of this kind of firewall rule get created after such executable starts ... by a dedicated firewall daemon monitoring the operating system's PID state (creation/deletion/child).


Great work and definitely needed.

I look forward to this landing so it will eventually appear in the downstream distro I use.

This the kind of work Ubuntu should be sponsoring.


Skolelinux, thats a long time ago! 24 years ago to be precise.


There is also safing which does something similar with a great GUI and it works on Linux, windows and macOS and its open source!


Are you referring to Portmaster? https://github.com/safing/portmaster/

If so, it "is currently not available for macOS". https://docs.safing.io/portmaster/install/status/mac


Yup and oops, unfortunately can't edit it right now


I use portmaster on Linux and I think its great.


this is the way.


I picked up Little Snitch recently, after 10 or so years off it. It certainly provides value, but way way way less than I’d expected, and way way way less than it used to. Public cloud homogeneity and the ubiquity of connected applications means that there has been very little occasion to meaningfully do anything more than an “all or nothing” on an application, and very little occasion for me to want to err on the “nothing” side.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: