
OpenSnitch – A Linux clone of the Little Snitch application firewall - dvko
https://github.com/evilsocket/opensnitch
======
annnnd
I really hope this tool takes off!

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.

~~~
tonylemesmer
Glasswire (paid version) is nearly there - Only annoyance is when using across
multiple users on the same machine. An app is blocked by one user cannot be
unblocked easily by a non-admin (e.g. one of my kids) - have to switch user,
unblock and switch back. Annoying if I do actually want to allow some traffic
through.

edit - yes Glasswire blocks by executable rather than port.

~~~
annnnd
Unfortunately it is not available for Linux.

------
hobarrera
Apparently, the whole things needs to be run as root, since it's all one huge
blob.

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.

~~~
evilsocket
OpenSnitch author here ... that's exactly the direction the project is going,
C++ daemon running as root and low privileged UI in Python or whatever. The
current implementation is more of a PoC/test to see the whole logic working
before starting the real thing :)

~~~
peterwwillis
Why C++? The backend only has to read ftrace events, and Python should be fast
enough for that.... And why root? Can't you just create a dbus connection,
open your fd to the ftrace pipe, and then drop privs to a nonroot user?

~~~
evilsocket
OpenSnitch is not only about ftrace, check the NFQUEUE handling, moving to
native will improve performances and stability. Also, it requires root because
that's the only way it can install the iptable rules it needs in order to
function properly.

~~~
peterwwillis
The iptables rules are static though, aren't they? And they have bypass
enabled, so you should be able to load them once at system boot time and leave
them there to default to allow.

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.

~~~
evilsocket
as long as i know, you definitely need root to communicate with netlink .... i
don't think there're gonna be large packet flows, only first connection
packets tnx to conntrack, it's doable :)

------
adisbladis
I just made an AUR package for this:
[https://aur.archlinux.org/packages/opensnitch-
git/](https://aur.archlinux.org/packages/opensnitch-git/)

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.

~~~
Proof
Thank you so much for your work!! Will install it on my arch as soon I get
home. :)

------
Abishek_Muthian
It's hard to believe there wasn't a credible little snitch like application
for Linux yet. Even more why Objective Development themselves did not try to
port their very successful product to other platforms. I hope opensnitch gets
some community love.

~~~
mi100hael
I suspect most Linux users just use iptables and/or /etc/hosts. That's what
I've done since making the switch from Mac.

~~~
annnnd
Curious: how do you detect that some plugin is phoning home with iptables?
Especially if it is cleverly written to only do it when there is lots of other
traffic?

~~~
notalaser
You can use the owner extension: [https://www.frozentux.net/iptables-
tutorial/iptables-tutoria...](https://www.frozentux.net/iptables-
tutorial/iptables-tutorial.html#OWNERMATCH) , which can filter based on the
PID of the process which created the packets.

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.

------
ktta
I wonder how it compares to Douane[1] which is touted as the alternative to
Little Snitch.

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.

[1]:[http://douaneapp.com/](http://douaneapp.com/)

~~~
cyphar
I remember looking into Douane a while ago and was not impressed. Rather than
implementing all of the rules and policy in userspace (as OpenSnitch does) it
implements the rules in kernelspace. It also has a bunch of questionable
technical decisions in how policies are handled, especially when it comes to
"edge cases" like processes with long paths[1] or connections where the socket
file descriptor is greater than 8 or something like that[2].

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...](https://github.com/Douane/douane-
dkms/blob/master/douane.c#L217) [2]: [https://github.com/Douane/douane-
dkms/blob/master/douane.c#L...](https://github.com/Douane/douane-
dkms/blob/master/douane.c#L669) [3]:
[https://github.com/cyphar/whistled](https://github.com/cyphar/whistled)

~~~
LinuxFreedom
Looks very interesting! Would you like to add LDAP support, maybe in a
modularized way to store rules "somewhere" and provide a mechanism for
mandatory application of these rules on clients ("enforce rules from trusted
storage x")?

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!

~~~
cyphar
> Would you like to add LDAP support, maybe in a modularized way to store
> rules

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.

------
Cieplak
I love using DTrace for network monitoring. I wonder what's the simplest way
to integrate it with pf to achieve a similar solution to Little Snitch, except
with an htop-style interface :)

[http://www.brendangregg.com/DTrace/connections](http://www.brendangregg.com/DTrace/connections)

[http://www.brendangregg.com/DTrace/tcpsnoop](http://www.brendangregg.com/DTrace/tcpsnoop)

------
userbinator
I was surprised to see that it's written in Python... I was expecting
something lower-level for this type of application.

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.

~~~
voltagex_
If performance becomes an issue, the packet processing stuff could be split
out into a faster daemon.

I'm surprised, I expected this to be an iptables frontend.

~~~
detaro
What would a "pure iptables front end" be and how would it learn about
connection attempts? (Serious question, it's quite possible I'm forgetting an
API)

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.

~~~
voltagex_
I don't know enough about Linux networking - I didn't realise the distinction
between iptables and netfilter. Off to do some reading - thanks.

~~~
detaro
(I interpreted "iptables frontend" as probably meaning something that just
generates iptables rules, that's why I was asking)

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...](https://github.com/evilsocket/opensnitch/blob/master/opensnitch/snitch.py#L33),
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.

------
nikisweeting
I created a similar app for macOS called Security Growler. I have some
bugfixes to work on for Sierra, and Linux support is waiting to be merged, but
basically it's a monitoring tool (not a full firewall) that also supports
watching logfiles for events.

[https://github.com/pirate/security-
growler](https://github.com/pirate/security-growler)

------
krylon
The timing is impeccable! I just switched from a MacMini running OS X 10.10 to
a custom-built PC running GNU/Linux, and one of the few things I miss is
Little Snitch.

------
tmsldd
Great job! That was for sure a missing package for Linux. Side comment: the
author seems to work 24/7 for his open projects(!).. im very impressed.

~~~
evilsocket
Ahah not really 24/7, but you're almost there :) it's my way to repay the OSS
community for everything I learned from OSS during my life.

------
quadrangle
So, Little Snitch has lots to block because MacOS is proprietary and filled
with proprietary software which would be inclined to track users for the goals
of the developers (which are only sometimes aligned with the interests of
users)…

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?

~~~
sasas
Out of the box, Ubuntu doesn't behave well. [1]

Let's not forget applications such as browser plugins.

[https://fixubuntu.com/](https://fixubuntu.com/) [1]

~~~
quadrangle
I think that's all gone now, as of a year ago.
[http://www.omgubuntu.co.uk/2016/01/ubuntu-online-search-
feat...](http://www.omgubuntu.co.uk/2016/01/ubuntu-online-search-feature-
disabled-16-04)

But even so, that can be disabled via the stuff on that site.

~~~
annnnd
That's not the point. Sure, everything can be disabled - if you know there is
something that should be disabled. Do you? I am 100% sure I don't.
LittleSnitch notifies you about such activity and conveniently offers to block
it. But it's the notifying part that makes the difference (which iptables
can't do because of all the noise on common computer setup).

~~~
quadrangle
Yeah, but what I'm getting at is basically: running LittleSnitch on MacOS
makes it clear how much activity is happening. Surely OpenSnitch on GNU/Linux
would do the same. But I would assume that some knowledgeable people would
know about the extent of the difference generally. I suspect that MacOS
programs are _far_ more rampant in calling home, and the GNU/Linux stuff would
mostly just be proprietary programs doing it. So, I was asking if people know
about this stuff generally…

------
m8rl
This is absolutely great news! Just the other week I was again researching
every option, from Subgraph OS's fw-daemon to the Douane firewall.

------
stiGGG
Can such thing really improve security? I remember the times when Desktop
Firewalls like ZoneAlarm got popular, there were dozens of tech talks that
showed how baby simple it was to bypass them. I think it was common sense
these times that this tools are nothing than SnakeOil. They are useless
against real Trojans and only cause a lot of work for the user with all that
false positives. In worst case it's blocking applications from self updating
which can lead to a less secure system.

Has this changed nowadays? Especially when we are talking about little snitch
which has a really good reputation like I noticed the last years.

~~~
r3bl
Since this is a Linux clone:

> 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.

~~~
stiGGG
>You're detecting how apps phone home and nothing more.

But only the harmless or respectively naive ones?

------
a2decrow
Interesting.

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.

~~~
isostatic
The point of a thesis isn't to build something useful and practical, it's to
show you understand the concepts of computer science.

~~~
wiz21c
I expect student to be able to demonstrate at least a little bit of practical
thinking too. Just demonstrating understanding of concepts won't get your very
far...

------
EdSharkey
It is tools like this that make Linux a viable replacement for Windows for
desktop use for me. I love running all apps through ZoneAlarm on Windows and
this looks like it would be a fine substitute.

~~~
distances
Last I heard, ZoneAlarm itself was phoning home. Granted, this was in 2006.
Didn't trust it since though.

~~~
lozf
As I recall (and just for completeness), Little Snitch phones home too -
unless you use it to block itself.

I definitely appreciated it when I was using OS X though.

------
pingec
Is there a similar application for Windows? I was able to google NetLimiter,
has anyone used it and can share how it compares?

~~~
pierrec
Glasswire seems quite good, though you have to buy it in order to get the
basic "ask to connect" feature. I've been planning to try it since forever.
Zonelarm is nice too (or at least it was when I used it years ago).

~~~
oridecon
The problem I have with Glasswire and similar products is that you can make
calls through other Windows APIs (I don't know if that's the correct term for
this but you get the idea). Especially if you run it as administrator. That
means that if they want they can hide themselves from the firewall tab (the
standalone .exe I mean) and make calls that will only show in other places
like System or Internet Explorer. Hard to monitor or manage that.

I hope they do something about this in the new version of Glasswire that is
about to be released.

~~~
voltagex_
Post in their forum with a list of the APIs they're not catching. Perhaps this
is a limitation of the LSA (?) they're using to monitor and control traffic?

------
lnx01
I've been looking for something like this for ages.

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.

------
l8nite
Awesome. I used to love Little Snitch!

------
bangonkeyboard
Since when is a clone a port?

~~~
johnhenry
What makes this a clone?

~~~
bangonkeyboard
OpenSnitch is an unsanctioned recreation by an unrelated party of Little
Snitch's functionality, appearance, and name.

How is it not a clone?

~~~
sasas
It's not a clone. LittleSnitch is more functionally rich. The name is
misleading. You can take pcap traces on applications, plot bandwidth usage and
more.

Little snitch is closer to GlassWire for Windows [1] then OpenSnitch.

[1] [https://www.glasswire.com/](https://www.glasswire.com/)

Let's not start calling every application firewall a clone.

~~~
bangonkeyboard
_> The name is misleading._

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.

~~~
sasas
> a clone, because that is its stated aspiration.

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!

------
10165
What is the purpose of an "application firewall" in an open source world?

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.

~~~
cyphar
> What is the purpose of an "application firewall" in an open source world?

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.

