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.
Addition to comment - Note that Douane being a kernel modules is not a bad thing. Little Snitch also installs a kernel module. I just would say it didn't go as smooth as I had hoped. It is still the closest thing that comes to Little Snitch, so try it in a VM to see if it is for you.
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).
Good luck on your project! Be sure to visit r/rust in case you have any trouble. The people over there are very helpful.
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.
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!
> 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.
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.
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).
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.
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?
Note that the Pro versions of GlassWire do aggressive ARP scanning on all networks to populate the "What's on your Network" tab. I think it's still only controllable via a text file.
I've been working on a program that does this based on lpfw. It's not ready for release yet but there's a preview at https://fireprompt.com. I'm hoping it's not eclipsed by OpenSnitch!
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 :)
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?
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.
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.
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 :)
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.
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?
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.
>It's hard to believe there wasn't a credible little snitch like application for Linux yet.
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.
Linux didn't really have software that "phoned home" in the past. Most of the software was open source, so you could literally look inside it to see if it would ever "phone home". But now proprietary software for Linux is getting more popular, and I guess this makes people paranoid.
To be technical, a port is where you take the original codebase and modify it so that it can run on a different platform. Usually it doesn't involve a complete rewrite. A clone is where you start from scratch and try to emulate the behaviour.
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.
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!
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.
> The other thing worthy of note is that it appears every single packet will need to be processed through this application
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.
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.
(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..., 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.
OpenSnitch author here ... although performances are not a big deal here because only conntrack packets are intercepted, the project will move to a C++ implementation once the current Python prototype/PoC will be complete and will prove that what I want to do is 100% doable on GNU/Linux :)
I would say that golang is good enough. But if you are interested , you could go for Rust. Multiple teams have built extremely high performance network manipulation tools in Rust - like linkerd-tcp .
Once I saw OpenSnitch I decided to write my own in Rust (mostly as a learning experience for myself)[1] -- it's still obviously WIP as it doesn't even filter packets yet! My intention is to make it have a remote API so that policy decisions aren't done in the daemon but are done in swappable clients.
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?
Yes, desktop apps are quite bad at this. Browsers (FF & Chrome) and plugins, dev tools (Atom at least), distro tools etc call home by default. Then there's Steam games, and sandboxed or emulated apps many people run under Linux (like Windows, Android or Chrome web store apps).
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.
FF has opt-in to metrics (and I trust Mozilla to honestly anonymize anyway). I wouldn't trust OpenSnitch to stop all the deeply-integrated tracking in Chrome. Atom used to have analytics built-in by default, but they switched it to be opt-in (last I checked).
I could certainly see using OpenSnitch if you let your system get infected with stuff like Steam games, Skype, or Spotify, sure…
Nope, FF is opt-out. I just verified this by creating a new profile, the Health Report is enabled by default. I have a recollection that Atom had telemetry checked by default, but I'm not at a computer with Atom installed right now. There's also a big fight about it on the Atom issue tracker, but I can't be bothered to read through it. (https://github.com/atom/atom/issues/4966)
Okay, but regarding Atom, that thread stared in 2015, and all you had to do was hit END on your keyboard to see "At the current pace of development metrics should be disabled by default starting in Atom 1.11.0." as the last comment in the issue that is closed (or check current Atom behavior).
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).
Mhh.. Little Snitch (and its alternatives like HandsOff!) is pretty damn chatty when you first set it up as well. Unless you have an encyclopedic knowledge of what each Apple daemon does, you don't have the ability to make an informed decision on whether it should be getting online or not.
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…
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.
Right now, only a little bit. In the future, very likely.
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.
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.
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.
Unfortunately I don't have the time to audit the source of every piece of code I run on my workstation.
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.
> 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.
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 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...
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 :)
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.
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.
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.
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.
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.
No, they cannot except for the few users who actually understand what it is all about. I probably did more harm than good by advising clueless OSX-users (as in "ordinary users") to use the Little Snitch. Now they browse as careless as before but they are "safe" because they have a "firewall" (in which they always click "allow forever" anyway).
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.
Wow, I know that a ton of requests from Apple are revealed when using Little Snitch, but it's hard to imagine how they use such a significant amount of bandwidth.
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.
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.
107 comments
[ 3.9 ms ] story [ 165 ms ] threadI 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/
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.
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.
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! ^_^
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.
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!
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.
[1]: https://github.com/cyphar/whistled
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.
https://fixubuntu.com/ [1]
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 definitely appreciated it when I was using OS X though.
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.
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.
http://www.brendangregg.com/DTrace/connections
http://www.brendangregg.com/DTrace/tcpsnoop
https://github.com/pirate/security-growler
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.
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.
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?
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.