OpenSnitch is a GNU/Linux port of the Little Snitch application firewall | Hacker News Reader

OpenSnitch is a GNU/Linux port of the Little Snitch application firewall

github.com

208 pointsbtdmaster75 comments

I love Little Snitch. I hate Little Snitch.

The first time I installed and ran Little Snitch, I was pretty much flabergassted at how chatty my system was. Just constantly being presented with requests to the point that made it impossible to work. I loved learning how prevelant E.T. phoned home.

But then as I was just constantly inundated with those requests, I hated having to constantly deal with it. Now it's time to whitelist/authorize/etc. But do I really want to blanket OK something just because I'm annoyed? What does one do to stay sane and safe?

<disables Little Snitch> securely places head back in sand

Little Snitch is the single program to illustrate all of the scary websites/blogs/etc of how shitty companies are about their "free" software and other shenanigans that devs play and from some "legit" companies.

I love Little Snitch and I hate Little Snitch, and it's not their fault.

I think what's missing with programs like little snitch are the default filter lists similar to ublock zero filters. If there was a pre curated list, it would have been a lot more adopted.

They have them, they just don't default.

It's a 2 edged sword. Full tilt block mode causes insanity but shows just how bad all these devs are at phoning home for whatever. Setting it to some default might be okay for some but still too much/not enough for others. Some people then might think they are protected while potentially nefarious back room deals to get something whitelisted.

I found it less annoying to just silently block everything. Then, when something doesn't work, manually allow it.

btw, similar program for Windows: https://binisoft.org/wfc

Until Linux duplicates that BSD tagging of inbound packets to process ID, no Linux-derivative LittleSnitch is going to match macOS/BSD-variant LittleSnitch’s capability set of detecting WHICH application having received a network packet.

Given the above, sandboxing with namespace nftable is still required for ultimate inbound security (I am looking at you, systemd).

What is the BSD equivalent of a Application Firewall?

It is a notation macOS/BSD.

Not macOS and BSD.

This is very easy to accomplish with eBPF, which OpenSnitch appears to use, but I didn't review it sufficiently to determine if that's how they're associating processes with packets.

IIRC the problem with tagging in Linux is that there isn't necessarily a 1:1 relationship with a destination PID and a packet in a variety of scenarios.

doesnt the bpf solve this? https://www.gcardone.net/2020-07-31-per-process-bandwidth-mo...

In a secured system, you disable BPF in Linux.

In a secured system, you don't run MacOS in the first place. It's a catch-22.

Previous discussions:

2017: https://news.ycombinator.com/item?id=14245270 (103 comments)

2020: https://news.ycombinator.com/item?id=22206116 (131 comments)

What exactly is the use case of such an application firewall?

I mean I get what it is supposed to do, but if I already have a means of blocking certain spam/telemetry URLs that I don't want (via etc/hosts, or PiHole), is there any real benefit of using an application firewall on top?

As others have said, micro-managing all these connections is not really feasible in most cases. And if I have a domain I don't trust, I can just globally block that.

What are some real-world use-case scenarios of a domain that I want to block for one application, but not generally for all applications? It sounds cool in theory to be able to fine-tune all that on an application basis, but is this actually useful/sensible in practice?

Compared to etc/hosts or PiHole, it allows you to go from "allow by default, block specific" to "block by default, allow specific".

I understand that, but again, what's a real-world use-case for that? Are there any domains that you want to block for every application except one?

Again, the key is block vs allow by default, not whether it's per application.

But yes there's real world use cases for per application filtering -- you want Facebook messenger to reach Facebook.com but probably not any other applications.

Ah, but if I use the FB messenger, I probably trust FB enough that I also regularly visit/use it in my browser, and probably even use it to authorize other apps and services through it... So I'll have to unblock every app that uses FB services anyways.

And FB's trackers and ad-services and other privacy-invading stuff is all on different sub-domains that PiHole or any other "generic" firewall blocks anyways, so again I'm fine without application-level firewalling

> Ah, but if I use the FB messenger, I probably trust FB enough that I also regularly […]

Except if someone sends you a specially crafted message that causes an exploit to be triggered which could contact some other site to download malware on your system.

* https://www.wired.com/story/facebook-messenger-bug-bounty/

Do a search for "no-click exploits":

* https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

You may trust the authors of the software and how the software acts as intended, but you should also considered unintended / undesired usage.

For example I have allowed only my mail servers for Thunderbird. And then I have discovered that Thunderbird sends filenames and SHA-256 hashes of all received email attachments to Google (browser.safebrowsing.downloads.remote.url, https://brmlab.cz/project/spyzilla#thunderbird) and that it sends telemetry saying "you have disabled telemetry" when you disable telemetry.

It also allows you to deny all internet access per-app. For example, should there be an exploit for a MP3 parser in Audacity (presume that Audacity has no use for internet normally -- at least that's my use case), it will probably try to download a second stage from the internet, and you want to block this. Unfortunately, OpenSnitch probably cannot detect "Audacity has spawned wget and you have allowed wget, but only as a child of bash in your terminal launched from your DE startup script, not as a child of Audacity".

This is not entirely made up (only the exploit part), there was indeed an Audacity telemetry incident: https://www.google.com/search?client=firefox-b-e&q=site%3Ane...

As another real-life example, I have discovered that Stardict scans clipboard by default and tries to translate what it finds there using an online dictionary. This includes passwords in your clipboard. https://jenda.hrach.eu/w/et#stardict (the linked page contains several other less severe examples discovered about 2014-2016; I'm not in infosec anymore, so I'm not looking for this that much)

this is a really great project.

if you haven’t heard of libnetfilterqueue, this is what it’s for. it’s really good. tremendous thanks to the author for introducing me to it via this project.

the main problem with libnetfilterqueue is that it doesn’t have pid information. you have to look that up in /proc or via a hashmap maintained by ebpf. either method has issues.

an unexplored alternative, afaik, is seccomp with userspace filtering[1]. then you get pid information and direct control of syscalls. this may still need to be paired with libnetfilterqueue depending on implementation.

1. https://lwn.net/Articles/756233/

Anyone aware of userspace application firewalls that be run for a process from cli? No requiring system level configs/packages or root privileges.

Something like this:

  app_firewall --block all --allow www.google.com ./my_untrusted_application

Or like this:

  app_firewall --rules my_employer_network.conf  ./untrusted_employer_application

Then you can do cool stuff like:

  app_firewall --block microsoft.com qemu my_dirty_windows_virtual_machine.qcow

interesting idea. trivial to do but not packaged in anyway.

if you can set up a socks server, tsocks?

or you will have to create iptable rules and then use cgroups et al to tag the proccess to them.

How does it compare to Bubblewrap? I tried it to test Windows software that I don't trust under WINE and it worked, but a few times the sandboxed program wouldn't work although it would when run under a non networked machine, so I thought the sandboxing was also affecting Unix sockets, that is, IPC.

Command used was: "bwrap --bind / / --dev /dev --unshare-net -- exe_name"

Bubblewrap is cool, but not exactly a like comparison. Bwrap is a tool with a lot of different sandboxing tools, some of which work and some of which don't. OpenSnitch simply looks like an abstraction over your OS's firewall.

This looks great, but is there a TUI or headless mode?

I don't really like GUIs in my Linux, setting up VNC is such a pain.

I think the whole point of LittleSnitch/OpenSnitch is the GUI. I feel like this is sort of a descendant of (or rather inspired by) a piece of software from long ago called "ZoneAlarm" for Windows. I mention this because I primarily used it before I could code or knew about the "system"; which, also happened to be when I was pirating a lot of software (high school). You should be able to accomplish most all of this, and more, from the command line already. `netstat` alone would probably get you most of the way there.

ZoneAlarm, now there is something I haven't thought about in nearly two decades!!! (since HS or early uni)

Netstat sort of fills this niche, but not without a lot of manual toil on behalf of the operator. In general, Linux and the apps in the ecosystem are much more well-behaved with regard to "wtf is this traffic" compared to macOS or Windows.

Trust is great and all but visibility is better. Linux is still dicey to correlate traffic with a particular app, especially if the connection is/was shortlived.

> Linux is still dicey to correlate traffic with a particular app, especially if the connection is/was shortlived.

This is has become a lot easier and more reliable to do now with BPF [0].

I also used the same approach to create a somewhat user-friendly TUI and web dashboard for it [1]. It is also able to hash the executable (even if it was shortlived).

[0] https://www.gcardone.net/2020-07-31-per-process-bandwidth-mo...

[1] https://github.com/elesiuta/picosnitch

ebpf used in this way is typically nonblocking. it drops data instead of blocking. for a firewall, that’s potentially bad.

can ebpf operate in a blocking manner while making drop/allow decisions on packets WITH reliable access to the callers pid and argv?

> for a firewall, that’s potentially bad

I wasn't talking about using it as a firewall, just a connection/bandwidth monitor that correlates traffic with a particular app.

bandwidth monitor use case seems like a perfect fit, and the occasional missed packet wouldn’t be an issue.

picosnitch looks really cool! i’ve rss subscribed to its github commits.

Thanks! Also I used lost_cb [0] to detect if a packet or connection (with security_socket_connect) was missed between the BPF and Python parts, but is it possible for the BPF program to miss either entirely without triggering that callback?

If so (without a kernel vulnerability which should be a given) I'd like to have it mentioned under the limitations section for picosnitch so others can be aware as well.

[0] https://github.com/iovisor/bcc/blob/master/docs/reference_gu...

i don’t think so. i think exactly what you’ve documented is the case. if the callback can’t keep up with the data before the ringbuffer overflows, data is lost. in that case, the solution is to increase the size of the ringbuffer, giving the callback a larger window to keep up with incoming data bursts.

in the end there are only two ways to handle this: drop data or block. for a bandwidth monitor, i’d choose drop. for a firewall, i’d choose block.

i use bpftrace to monitor docker filesystem access in a similar way[1]. i also increase the ringbuffer size until i stop seeing lost data.

1. https://github.com/nathants/docker-trace#files

Very cool! I also found it recently submitted to HN: https://news.ycombinator.com/item?id=31160863

I think OpenSnitch just uses eBPF to capture metadata about the new connection, the "hold for user confirmation" does not happen inside eBPF. The eBPF does not need to block waiting for user input.

https://github.com/evilsocket/opensnitch/blob/4ce8b0e57cfb25... https://github.com/evilsocket/opensnitch/blob/d9e0c59158ddf6...

by the time a user prompt is displayed, all metadata has been joined to the packet, and libnetfilterqueue is waiting for a decision.

my understanding of what is happening is as follows:

- 1: libnetfilterqueue gets a packet.

- 2: lookup packet via ebpf to get pid and argv.

- 3: lookup rule, on miss prompt user to allow/deny.

- 4: libnetfilterqueue allows/denies the packet.

the tricky part is step 2. afaik there are 3 possibilities:

- ebpf already knows about about this packet, return pid and argv.

- ebpf will know about this packet shortly, wait, then return pid and argv.

- ebpf dropped the data because of ringbuffer overflow, wait, then give up.

My understanding: ebpf runs at connect(2) time, stores metadata in a map; later, an NFQUEUE userspace helper fetches the metadata from the map.

this is correct. it's the datarace between these components, and the possibility of ebpf dropping data because of a slow userspace callback, that makes this flaky.

You can use lsof in Linux to show connexions:

lsof -i -n -P | grep "\\-\>" | awk '{a[\$1"_p"\$2]++;}END{ for (it in a){print it,a[it]}}' | sort -nr -k2,2

This project uses conky to display the current connexions:

https://github.com/viviparous/plonky/blob/main/plonky.pl

that awk expression fails here (v5.1)

Ah yes, it doesn't require the escapes that I pasted above.

awk '{a[$1"_p"$2]++;}END{ for(it in a){print it,a[it]}}'

unfortunately malicious lkms and userland rootkits can hide processes/connections from lsof/netstat

https://github.com/gianlucaborello/libprocesshider

Agree on the GUI however opensnitch does seem to assume a single user with a single X server, I have not been able to figure out a way last time I tried to get it to work with say 2 X servers and a VNC session or two running concurrently (meaning I couldn’t figure out a way to get connection alerts anywhere but in one of them, as also described here https://github.com/evilsocket/opensnitch/issues/388 )

Little snitch does not have this issues and you can have multiple users logged in with fast user switching and all can operate their notifications no problem.

i use a kind of tui. it is actually a gui, pops up fullscreen. you can’t click it though, just keypress interaction.

i agree with you. especially if i’m filtering all traffic, i need to be able to y/n quickly and easily.

https://github.com/nathants/tinysnitch#demo

Take a look into rustdesk the server ie self hosting bit has been recently open sourced. It's basically Teamviewer but faster and rock solid so far. Some features are missing but the basics are there. I'm going to be dumping our TV account quite soon.

The missing piece was remote installing the client on Windows en mass to be able to be able to switch to root errr Administrator. TV allows you to pass Windows creds through to remote install itself but rustdesk can't yet or that might become an "enterprise feature". However Ansible can manage a WinRM enabled Windows box with Kerb and encryption over http and no client install. You can switch on WinRM via a GPO.

Getting some bits of Ansible working on Arch and certain other bleeding edge distros might involve pip install --update pycrypto (and/or) pykerberos. Python 3.10 deprecated something in a rather cryptic way, that I'm sure was jolly important but broke quite a lot of things important to a Linux sporting sysadmin in a Windows world.

Yes, recently submitted ( https://news.ycombinator.com/item?id=31456007 ) and IIRC, the verdict was it's a bit shady and sketchy on the security front. Unfortunate.

Take a look into the source. I've only cast a vague eye so far but it looks like it reuses quite a lot of well regarded stuff including VNC, so I'll take issue with "shady and sketchy".

If you skim read that thread from HN where I also learned about Rust Desk then there is no consensus about "sketchy". Searching for the word "security" gets a discussion about SSL/TLS and some pontificating.

I'm no real expert on IT security but I do have a Nessus license and a box to wield it from. I've run quite a few firewalls from Fortinet, pfSense, Juniper, hand crafted Linux, <various others>. I have 15 VLANs at home 8)

In my office I have a pair of Dell S funky devops switches worth around £20,000 sat on the bench as I plough through the 2000 page manual. I've got over the lack of old school stacking (why do they still have a stack LED indicator?) They have a LACP mediated VLT domain link running at 200Gbs-1 (Gb/s) - two physical wires. Now, do I partition the 100Gb links into four lots of 25Gb because that will allow more flows. Ok let's look at how this thing is used: iSCSI for data and VMware. The iSCSI links are 10Gb to the M series SAN so more links seem indicated.

I also learned Ansible on Thursday rather rapidly because I can deploy these beasts with it (they boot Debian and have Docker installed already, which is adorable!) and coincidentally, I need a non MS way of getting at Windows boxes from Linux. Ansible doesn't need a client app.

It's getting busy in IT. I'm 52 FFS (and absolutely love it!)

The Rust Desk security concern is due to it's not 100% self-hosted, it uses some kind of TURN or fw hole puncher which they host and didn't provide the sources for.

If I'm mistaken please tell me, would love to use it if it's "safe".

I've got a self hosted host in my office. When you deploy a client, you can rename the Windows exe to include the DNS name and public key of your host and it will then use them - clever idea. So I don't think you need their TURN/STUN. I suspect those are simply provided as a service and nothing more sinister.

They also provide three or so really low spec jump boxes to get people up and running if they can't self host - again, I call that altruism not sinister.

I will get Wireshark out anyway to check about this stuff next week.

You can do your own real due-dil stuff yourself by browsing around this: https://github.com/rustdesk/rustdesk - read the issues, browse the source (read the comments!) get a feel for the software.

I'm asserting that it is no worse than anything else. I can also assert that the binaries that I get on Arch Linux are probably from the official sources (I checked a few strings etc). I can't sign off the Windows binaries but I can assert that I do trust them from their GitHub repo.

I can assert things until I'm blue in the face but I trust rustdesk more than most remote access facilities for now but I am still kicking the tyres.

There is also eBPFSnitch, though it hasn't been updated in a while. It uses eBPF for packet filtering.

https://github.com/harporoeder/ebpfsnitch

it hasn't been updated because the ebpf module from it landed in opensnitch

https://github.com/evilsocket/opensnitch/tree/master/ebpf_pr...

Also see https://objective-see.org/ and their LuLu tool if you're on MacOS.

Is it a coincidence that both have “Objective” in the name?

So Wireshark but with connection permission toggles... Why does anyone need this on Linux? You can already block domains you know are malicious in the hosts file or use a personalized DNS resolver for that. Or am I missing something?

A couple of obvious reasons:

- You can apply more flexible rules than just blocking specific hostnames -- for example, based on IP subnets, port numbers, or specific binary executables

- You can block connections even from programs that bypass the default system-wide DNS configuration

> You can apply more flexible rules than just blocking specific hostnames -- for example, based on IP subnets, port numbers, or specific binary executables

This doesn't sound like a common use case. You can already block connection on a specific port with all available firewall programs. And you can bubblewrap binaries from making internet connections.

> You can block connections even from programs that bypass the default system-wide DNS configuration

Other than browser's making use of DOH for DNS, I can't think of a common use case for this. Besides, why would I want to Wireshark my browser? Why not use uBlock to filter domains.

Doesn't seem obvious to me why one would go through all this trouble.

The whole point of something like Little Snitch is to detect, and give you the option of preventing, connections that you wouldn't otherwise know about. For instance, programs that secretly phone home with telemetry about the user's behavior.

I can easily imagine such a program doing its own DNS lookups (or just using hardcoded IP addresses) to avoid detection, and this approach allows you to block it anyway.

Sure, you could do the same thing manually. But you might as well say "why does anyone need Visual Studio Code when we have sed and awk?"

My point is. With Linux and FOSS software, you do not necessarily need to treat programs as hostile. By default, most software is open and can be audited. If you decide to extensively use proprietary software then you have bigger problems that even Little Snitch cannot solve.

There are better alternative routes you can take that do not involve a "MITM" for all your connections.

You somehow assume exploits never happen.

There’s no MITM involved. Just another hop (potentially with an interactive go/no decision.

If am not wrong, Little snitch doesn't stop any malicious domain that the user is not aware of.

Little snitch is effectively a MITM app for all connections on the system it is installed on.

Little Snitch can be setup whichever way you like, but the default/recommended way is for it to ask the user about every connection attempt, which you can then approve or deny (for a limited time, or forever).

Little Snitch is a gate. It either lets a specific connection through, or not; it does not modify it. It all happens on your own machine. You keep using that term, "MITM", I don't think it means what you think it means.

Your head is firmly in the clouds if you believe that “audit all your software” is an appropriate solution for even the majority of desktop Linux users. The sun still rises every day with people using software that they aren’t personally auditing. Continued interest in this project proves its use. I don’t buy that you genuinely believe your viewpoint. You’re just being a FOSS purist.

> Besides, why would I want to Wireshark my browser?

https://github.com/gustavo-iniguez-goya/opensnitch/issues/21

https://nullsweep.com/why-is-this-website-port-scanning-me/

https://user-images.githubusercontent.com/2742953/84960681-9...

i want a cable modem + oss router/outbound firewall/egress logger all in one device. does such a thing exist?

1. get linux router on lan or linux vpn on wan.

2. install opensnitch or similar on 1.

3. route all traffic through 1.

4. figure out how to deal with rule management and new connection requests from 1 to wherever is most convenient for you.

i feel like i want something with full egress logging and a community driven filterset.

bonus points for making it easy to install a cert on the machines in my network and capture/inspection of ssl streams.

alternatively, some cloud egress point i can vpn to with outbound firewalling/logging/filtering as a service. i don't want to think about it all the time, so either community driven filters or a managed service.

basically i'm interested in two things. catching malware on my personal devices and inspecting/defeating software that is gossiping too much about what appears to me to be private.

I've kinda been keeping an eye on firewalla [0] since it looks pretty simple and probably good enough for home use? If anyone has any experience with it, or has looked into how good/useful the security of it is I'd love to hear it.

There's also pfsense [1] and OPNsense [2] which are more geared towards business users, and personally not worth the effort for me to maintain at home, so I haven't looked into them as much.

[0] https://firewalla.com/

[1] https://www.pfsense.org/products/

[2] https://shop.opnsense.com/product-categorie/hardware-applian...

I’d love to hear some feedback from any users on HN as well.

I've been a pfSense fan for something like 15 years. I run something like 50-60 of them around the country (UK). In my office is a 2 node CARP beastie with six WANs and 12 NICs each (Dell R310s) and quite a lot of cabling. At home I have an APU4 humming away in the attic. I have a full IPv4 and 6 stack running and more VPNs than you can shake a stick at. The docs: https://docs.netgate.com/pfsense/en/latest/index.html are excellent.

Slap on the pfblocker-ng package and you effectively have a souped up Pi-Hole in the router too. My TV at home has stopped showing adverts for certain streaming channels which is nice.

There are certain strong feelings against Netgate (nee Electric Sheep Fencing) which may or may not be justified. You have Opnsense as an alternative option - it's a very well thought of fork of pfSense.

OpenWRT

Unfortunately without sandboxing, these sorts of tools just add an extra layer of maintenance to your system for a false sense of security [1, 2].

This can actually be harmful for less experienced Linux users who may trust something like this to keep them safe for running random scripts, especially since I see this tool often recommended for such a use case.

[1] https://news.ycombinator.com/item?id=22208223

[2] https://news.ycombinator.com/item?id=14254679

It's not just to avoid scripts. Sometimes I just what to control what a program can do. Eg not call home but connect to ftp servers I want to use it with.

I'm sorry, I should have clarified that my criticism was that these sorts of tools often get recommended as a security tool that can protect you from malware/spyware. There are still valid use cases for it like what TripMode for Mac is marketed towards.

Also if you're using it to prevent an app not to phone home, you still have to trust it not to do anything more nefarious than that, or simply spawn a program like curl (which you've probably allowed) to phone home for it.

the issue is that libnetfilterqueue doesn’t have pid information, and so that must be looked up or joined to another data stream at runtime. this can fail. flakes at this point can be dangerous, and can reduce confidence in the system. they can also encourage you to add rules at both system and program level, which is annoying.

one alternative is to specify rules at system level instead of program level. that’s the approach i ended up landing on[1]. i wish i had finer granularity, but i’m glad i don’t have flakes.

it’s hard to imagine that monitoring network exfil isn’t THE best way to secure any system. at the least, it’s an important and necessary step.

1. https://github.com/nathants/tinysnitch

Firewalls have not much to do with running untrusted executables... You are confused about what a firewall is for (it's for managing network connections, not prevent virus, etc)...

Reply on news.ycombinator.com