OpenSnitch – A Linux clone of the Little Snitch application firewall
github.com
github.com
The problem with existing tools (iptables & co.) is that they are pretty much useless for "ordinary power users". I don't want to spend my precious time checking logs and trying to figure out if yeat another tool / extension / ... decided it needed to phone home (or worse). Ideal UI? Block everything, inform me about it (via unobtrusive non-modal message notification) and let me decide on a case-by-case basis what to do with such traffic in future. Bonus points if you keep the log of events so I can traverse and approve / forbid them at time of my choice. Kind of like NoScript, but better.
I don't know how close to that LittleSnitch / OpenSnitch are, but I would love to see that as a standard part of OS.
edit - yes Glasswire blocks by executable rather than port.
Hopefully, this'll eventually get separated into a daemon which does all the superuser bits and exposes a single API for a client GUI to consume.
As far as nfqueue, I googled around but I wasn't able to find out what perms you need in order to communicate with netlink. I assumed you could open an fd and drop perms but it looks like it might not allow that. I agree that eventually you'd need a pretty robust multithreaded app to handle large packet flows without adding too much latency... it seems like quite a big burden just to authorize specific applications to make specific network connections.
Kudos on what's been done so far! ^_^
This is cool stuff! Wanted to have this kind of thing for a long while. Thanks for merging my changes so quickly too. Packaging would not have been possible without it.
But what we generally do is, you know, not run plugins that phone home :).
Edit: I just looked on a Linux machine - things have changed a little. That used to be my go-to document for iptables, which is why I referred you to it. You probably want to consult something more up-to-date.
In any case: iptables can do filtering based on who created the packets.
Even later edit: it probably goes without saying, but just in case -- this solves only half the problem, because it can only identify the process based on its PID. This makes it pretty trivial to overcome PID-based rules. The usual solution, of course, was to filter based on UID and run the program under a separate account.
I don't know if this got solved in the meantime, I haven't used iptables in a while now.
Why? That's the case for most major proprietary UI apps -- open source versions are usually subpar in several ways (not because of some inherent issue with open source as a license, but because of time constraints, unglamorous work, not enough UX/UI volunteers, no top/down vision, etc). Where they do get the upper hand is usually in offering more configurability.
>Even more why Objective Development themselves did not try to port their very successful product to other platforms.
For Windows it might make sense, but which other platforms would they port to? Linux desktop users are few and far between (1/5 to 1/10 of Mac users), and there's not much of a paid software market.
I wasn't very happy with Douane since it was a kernel module and a memory bug (Think it missed a free) caused kernel panics on every single boot after an update. But other than that I would say it was pretty good.
My main complaint about implementing all of these things in kernel space is that it's simply not necessary -- with netfilter_queue and connmark you can relay all decision making to userspace without losing any generality. The only thing that you might argue is a benefit of using a kernel module is that figuring out the "path" for an application might be easier but I'm not sure I agree. Also Douane simply will not work properly with containers because of how it assumes that everything is in the host namespace.
As an aside, I decided to write my own application-level firewall for GNU/Linux[3] (mainly as an exercise to myself to learn Rust as well as learn more about low-level network programming in Linux). My plan is to make it far more modular than OpenSnitch with an client API so the GUI can be completely separate (and also perhaps allowing different clients to have different policies).
[1]: https://github.com/Douane/douane-dkms/blob/master/douane.c#L... [2]: https://github.com/Douane/douane-dkms/blob/master/douane.c#L... [3]: https://github.com/cyphar/whistled
There are couple books/guides around about good practices in rust. You should be able to find with proper googling. If you can't, comment here. I should be able to dig it out from my bookmarks.
And about Douane, I don't know a lot about what you said, so I can't comment on it. It definitely didn't feel polished but it was honestly the best one around, so again, good luck with your new endeavor.
Others could build GUIs around the storage (LDAP, SQLite, whatever) and we could share rules via a website. That would be a great help for many users! Thanks!
My thinking is to make it so that you just have a "dumb" daemon which has the concept of a process requesting the ability to connect to an IP/unix socket and sends requests over gRPC to clients that make access decisions. So there's no long-term storage of rules in the daemon (except possibly in some edge cases).
In any case I'm still writing a PoC so it's a bit early for features like that.
The other thing worthy of note is that it appears every single packet will need to be processed through this application; necessary for it to do its job, but will likely have a significant effect on performance.
The performance of this Python implementation will be interesting to watch.
No, only the initial connection requests will go into the netfilter queue (as well as DNS requests so that it knows what a particular IP actually refers to). Packets sent as part of a connection aren't vetted, and it uses the marking feature of netfilter so all of the actual filtering is done by the kernel.
I'm surprised, I expected this to be an iptables frontend.
The used technique, redirecting initial packets to a netfilter queue and then marking the connection to offload further processing to the kernel seems like a reasonable way to do this from userspace.
netfilter is the underlying kernel infrastructure, that's used e.g. by iptables to set rules for packets. From this https://github.com/evilsocket/opensnitch/blob/master/opensni..., it looks like OpenSnitch uses iptables to set rules so that the kernel delivers outgoing packets that don't belong to an existing connection to a queue. It then can use said queue to only intercept those packets – if it lets them pass, a connection will be created and further packets will not be passed to/handled by OpenSnitch. It touches the first packet of each outgoing connection, but not all traffic.
Unless you were planning to use Ragel.
Has this changed nowadays? Especially when we are talking about little snitch which has a really good reputation like I noticed the last years.
If you know what you are doing it is a pretty useful "pf with desktop notifications".
But what I personally use it most for: Binary traffic shaping for the lengthy conversation my laptop has with apple.com. One click and I can suddenly use ssh and watch something on youtube again.
What does this mean?
> They are useless against real Trojans
Highly doubt anyone will consider it as a way of protecting against trojans.
> In worst case it's blocking applications from self updating which can lead to a less secure system.
Since this is mostly done on the package management level, it makes sense to use a tool similar to Little Snitch. You're detecting how apps phone home and nothing more. I would take it a step further and disallow some apps to connect to the Internet at all, and allow some apps to contact only certain web pages. Seems like a good way without spending a lot of time playing with firewalls.
But only the harmless or respectively naive ones?
On GNU/Linux, is this much of an issue? Most programs seem to offer opt-in on metrics related stuff. If you assume OpenSnitch is set to match the opt-in settings whenever they are present, what sort of stuff is remaining to block at all? I.e. if people use this, what stuff are they seeing blocked?
There are also popular bona fide proprietary desktop apps on Linux, like Skype, Spotify, etc.
edit: Docker images also come to mind, they're quite black boxes.
I could certainly see using OpenSnitch if you let your system get infected with stuff like Steam games, Skype, or Spotify, sure…
Thanks for the answers to my question.
Thanks for the note about FF opt-out, okay.
Let's not forget applications such as browser plugins.
But even so, that can be disabled via the stuff on that site.
Even if you ignore the proprietary software side of things (which is an issue unfortunately), if an application is misconfigured or exploited then this is one way of detecting and blocking that.
And sometimes there's some weirdness like VLC will sometimes make network requests to get album artwork even though I'm fairly sure I've disabled that feature. It's better to have a tool that screams about applications that are safe than it is to try to patch things up with configuration options in every app on your machine.
Systemd will eventually be functionally overloaded with network requests much like svchost.exe is (over)used on Microsoft Windows. That is just one example.
This is also useful for folks to catch browser exploits that escape the sandboxes and make arbitrary connections to bypass privacy mechanisms such as Tor or other forms of proxies. i.e. dns leakage, tcp leakage via websockets, etc..
There are many other examples I could provide, but I have limited time right now to respond.
I began working on a application firewall like this a little over 6 weeks ago for my thesis, as I was mildly disappointed there wasn't a GNU/Linux version of this (yet) and I considered it an interesting topic to dive into.
I definitely appreciated it when I was using OS X though.
I hope they do something about this in the new version of Glasswire that is about to be released.
https://forum.glasswire.com/t/temporarily-disable-arp-scanni...
Actually, even Windows Firewall can do that. But sadly, Windows itself messes around with WF too much. So I would not trust it that much.
It's possible to block ports, PIDs and Users from accessing the network using iptables but it's not possible (easily) to restrict access by process name.
The only issue I have is that is runs on a single core using 100%, CPU temp ramps up to 82'c.
How is it not a clone?
Little snitch is closer to GlassWire for Windows [1] then OpenSnitch.
[1] https://www.glasswire.com/
Let's not start calling every application firewall a clone.
I think the name is very clear for the purpose of discerning the creator's intentions.
> Let's not start calling every application firewall a clone.
We're not. We're calling this specific project, which explicitly describes itself in its header as "a GNU/Linux port [sic] of the Little Snitch application firewall" a clone, because that is its stated aspiration. That it hasn't yet copied all of Little Snitch's features after 17 days of existence doesn't countervail that.
Thanks for the clarification. In that context then calling it a clone makes perfect sense. All the best to the project. LittleSnitch is great and to have a full clone on Linux would be fantastic!
If I have the source code and I am curious I just read it. I have yet to see any source code that attempted to obfuscate opening sockets.
Sometimes I run programs with ktrace (strace for Linux folks I guess) and look at the calls.
But truthfully in most cases controlling DNS catches most if not all of today's applications' attempts contact the mothership.
I do not use a third party cache, I maintain a custom root and can use it to block wildcarded domains, something that cannot be done with /etc/hosts. I do make extensive use of the HOSTS file but not for blocking.
I can also redirect traffic to localhost servers where I can log requests and analyze the captured packets. For instance if I want to reverse engineer the protocols used.
In my opinion an "application firewall" is a misnomer. IMHO a "firewall" operates on incoming packets from other computers, not packets originating from the computer running the firewall.
If a Windows user wants to run a "firewall" then IMO they need an additional computer, e.g., a gateway they control. This is the way to stop the telemetry, IMHO.
I think Microsoft puts some application they call a "firewall" on Windows. IMHO that is misleading, but not surprising considering the source.
In an open source world, in the event a particular user does not "have the time" to read source code or even grep it for clues, chances are that some other user does have the time and compiles all his programs from source. It is always possible that an application's "phoning home" behaviour could be documented by such users in public forums, etc.
What if an application hard codes an IP address? Answer: I see it in the source code. NB: I very rarely see this in practice. Apparently few people can maintain a stable IP.
A project like this to notify me that a process is connecting out to the internet (or another device on my local net), and selectively allow it is a welcome feature.
Aside from the problems with trying to read the source code for every application on your machine (which I guarantee you have not done), security is all about depth.
If an application is compromised or contains network functionality that doesn't do what you would like (and assuming you don't want to have to patch it and rebuild it) then something like this is incredibly useful. Not to mention that (unfortunately) we don't live in a completely free software world, so something like this is very useful if you're forced to run a proprietary program.
> But truthfully in most cases controlling DNS catches most if not all of today's applications' attempts contact the mothership.
Okay, but what if the application hard-codes the IP address? For an example of a normal project that does this, look at Tor.
And even if it doesn't hard-code the IP address how do you dynamically add entries to /etc/hosts? Are you tracing every process on your system and adding entries to /etc/host as soon as the process tries to gethostbyname(2) -- how do you deal with the fact that this will slow down your programs significantly? And what if you want to handle different applications differently?
There definitely is utility in a tool that can do all of this dynamically, per-process and also has full support in the Linux kernel already built in without the need to generate /etc/hosts in a horrifically racy way.
> IMHO a "firewall" operates on incoming packets from other computers,
Yes, and an "application-level firewall" operates on packets from applications. The term firewall is used to describe the "operates on packets" part, not on the "from applications" part of the definition.