For those unfamiliar, it monitors and restricts outbound connections that your applications are trying to make. For example, you might be working away and suddenly get a popup saying:
"Chrome is making an outbound TCP connection to adserver.trackallusers.com, port 9876. Do you want to:
- Allow or Deny the connection...
- To all hosts in the domain trackallusers.com, that specific hostname, or that specific IP address, or all hosts everywhere...
- On this port or any port...
- Protocol TCP...
- Once, or for the next 15 minutes / 1 hour / 2 hours / until I reboot / forever"
...and it will postpone making that connection until you answer. You can set defaults for that popup according to your own preferences, for instance to block by domain name instead of hostname so that "server432.example.com" and "server592.example.com" don't have to be managed separately.
When you first run Little Snitch, it's a bit overwhelming. Safari and Chrome want to talk to all kinds of things on TCP/80 and 443, so you pretty quickly say they're allowed to make any 80 or 443 connection they want without further pestering you. Soon you have a good coverage of your apps' normal behaviors, and that's where it really shines. For instance, suppose your text editor commonly talks to "updateserver.example.com" to check for app updates. But this morning, it's suddenly trying to chat with "exfiltrator.badhost.ru". Uhh, maybe you want to block that and see what's going on.
And my earlier Chrome example isn't an exaggeration. It's surprising how many websites want to connect to ad or tracking servers on nonstandard ports. I actually appreciate that a lot because those connections stick out like sore thumbs and I can permanently deny them.
Sorry if this reads like an ad pitch for Little Snitch. I'm not associated with them, but I'm a very, very happy customer. I'm very happy to see something like it becoming available for my friends using Linux is awesome.
I could block it all with Little Snitch - but it's a technical solution to a political problem. I miss a lot of the convenience, and I miss a lot of the slickness/lovely UIs... but Lil' Snitch taught me that that's the price!
For local net, setting up pi-hole is do-able, whilst setting it up over a VPN involves a bit of additional tooling.
A 100% uptime DNS on public internet is tricky, but if you're okay with just DoH , the https://workers.dev free-tier would you give you a 100% uptime "anycast", low-latency DoH enough for a single device's worth of queries for a month. At $5, you'd have enough for a 100 devices.
I've one setup with adblock forwarding queries to 184.108.40.206 and I see e2e latencies as low as 50ms regardless of location. This setup is a bit involved: You'd need to convert blocklists (the one I use has a million entries) to either a long-string, custom LZ-compress it (~6 MiB)  and do a boyer-moore needle-haystack search on it for incoming questions (v8's native String#index impl uses a variant of boyer-moore) , or use a json-map at a cost of higher RAM usage but blazing-fast lookups (~25 MiB), or use succinct radix-trees for optimal RAM usage (~1.5 MiB) but relatively slower lookups, or use bloom-filters with low false-positive but fast membership queries at extremely frugal RAM usage (~200 KiB) .
That said, the simplest way to ad-block would be to point the workers instance to adguard-doh.
Related, people also complain about Microsoft phoning home, but Apple does the same thing. (Not that apple is as blatant a jerk as microsoft)
This is a great thing to recommend to friends and family who may not have the technical ability or desire to set up a Pihole.
- Install knot-resolver
You can block anything on pi-hole, not just ads.
Am I missing something?
One frustration I've had lately—and it's not Little Snitch's fault!—is the number of unnamed micro-service endpoints in use. Office365, Dropbox, and others have started using random cloud IPs for their content distribution endpoints, so you get a popup for "OneDrive wants to connect to XXX.YYY.ZZZ.QQQ on port 25427. Allow?" You have no basis for knowing if that IP is legit or not, you can't use the port to judge it, and you know if you cut off too many of them the app will break. Super frustrating, and seems deliberately designed to break things like LS.
See for example this news report or the DEF CON talk.
I personally do use Little Snitch, but this is after consideration of my own privacy desire against risk of security holes being exploited. I personally chose the former. You should personally weigh these and decide.
But a much, much cheaper and much easier and simpler to use software is TripMode - https://www.tripmode.ch/ ...
While it is not marketed as an outbound firewall, it does a great job as one. It isn't as sophisticated as Little Snitch and doesn't offer fine-grained levels of filtering but that's a plus for those who are not advanced users - it simply allows or blocks an "app" from connecting to the internet. It can also monitor your bandwidth usage.
(The Mac version is very stable, but I found the Windows 10 version to be a bit buggy).
I've been using it for years and the only feature I miss is domain/subdomain blacklisting.
If there is no need for such a granular control of outgoing connections for any given application, there's also the no-cost and open-sourced LuLu: https://github.com/objective-see/LuLu
LittleSnitch = I want to monitor every connection every application makes.
TripMode = I want to disable Dropbox, Apple Software Update & Steam while on MyPhoneHotspot.
That being said, I wish there was an OpenTripMode, or... something on Linux.
And it works on broadband / fibre connections too, and not just for mobile data.
(Tip: Private Eye is a free software that allows you to monitor all connections made by any system or application softwares on your Mac. It's now bundled as part of another paid outbound firewall, similar to TripMode, called RadioSilence - https://radiosilenceapp.com/ but the free "monitoring only" version of Private Eye can still be found on the net).
> TripMode uses a macOS feature called “Network Kernel Extension” to be able to block apps from accessing the Internet. This is the Apple-endorsed way of managing network traffic on a Mac ... We notarize each TripMode for Mac release with Apple, which means that Apple guarantees that they are free from malware ...
I also found this discussion that explains a bit about why Mac firewalls still prefer to use a Kernel Extension on macOS - https://forums.developer.apple.com/thread/79590 (The developers of all the three popular firewall mentioned here - Little Snitch, TripMode, RadioSilence - have added their thoughts in that thread).
Something from dev.visualweboptimizer.com! Had to make an exception
Safari and Chrome want to talk to all kinds of things on TCP/80 and 443, so you pretty quickly say they're allowed to make any 80 or 443 connection they want without further pestering you
For example, block graph.facebook.com forever.
You can also look in the little snitch network monitor and block sites after the fact for the future.
It's a lot less tedious if you know the keyboard commands:
alt-return denies the connection, and cmd-return allows it.
I suspect Little Snitch has a sort of hole in it's design.
I think the DNS lookups go through before you get the allow/deny dialog box. So your browser might do a dns lookup for user-gruez-jan-2020-in-timbuktu.<random>.trackingjerks.net which would get around little snitch.
Nowadays everyone seems to ask nsurlsessiond to make a connection to AWS on port 443.
no need, little snitch is one of the most popular programs for power mac users; I've been a fan since at at least 2011
To me it just smells of "we don't have enough public IP's, and still manage our network with port-forwarding rather than a proper application level loadbalancer".
That matches my observations that 'ancilery'services frequently seem to be on non-standard ports - like the employee login portal, the company webchat service, the analytics service, etc.
I mean, we kinda knew that already. Port numbers give you a free 16-bit address space per public IP, that's nothing to sneeze at.
In this specific case, I don't know. Perhaps rotating through ephemeral ports is done to mess with simple traffic filtering rules on firewalls?
It's alarming just how much software starts running in the background after a startup, and starts making connections you didn't know about before you ever open a single user application.
Looking up 2020-01-31-user-kstrauser.example.com might cause a DNS lookup to go out, even though little snitch will block the subsequent web traffic to it.
I think umatrix helps with that.
It would be:
- browser looks up 2020-01-31-user-kstrauser.example.com
- dns lookup proceeds, returns 220.127.116.11
- browser connects to 18.104.22.168
- little snitch intercepts
- little snitch does reverse lookup
- dialog box
I don't see it filtering the responses, so spoofing hostnames or even overloading the translation table (memory exhaustion) might be possible, even for network attackers.
If the app resolves two hostnames (e.g. useful-serivce.cloudprovider.com and malware.cloudprovider.com), that are both at the same ip, and then connects to that ip, which of the hostnames it connects to?
Without sniffing Host header (for http) or SNI (for TLS pre-ESNI), it is just a guess.
I think a better term might be "clone"?
It's just a Hyperbolic Headline.
Maybe, but it's effective. I instantly know what it does instead of trying ascertain what makes Yet Another Linux Firewall different from the rest.
Calling it a "port" is completely inaccurate and misleading. I clicked on this thread thinking the Little Snitch developers must be involved somehow.
And If I were the Little Snitch devs, I'd be more than a little annoyed.
And with "clone" you wouldn't?
It is annoying that it still calls itself a port three years later.
On unsandboxed platforms, you either trust an application completely, or you don't. Tools like little snitch don't turn dangerous programs into safe ones; they only give you a false sense of security.
Even that is difficult to achieve and possibly opens up additional attack surfaces. On Linux, AFAIK, there's no built in method to filter packets on the basis of the path of the sending process, so firewalls like this have to be adding a kernel module (like Douane does), which adds attack surface, or basically attempting to work out the path on a "best effort" basis, which seems to be what OpenSnitch does, with mixed results  .
Seems like this is probably a useful tool to figure out programs that are talking to servers when they're expected to be silent, but I probably wouldn't rely on it for security, at least until / unless more robust application level filtering is built into the Linux kernel. For better or worse, it seems like the intended approach for Linux systems is to rely on the Unix permissions model: a program running under a user is allowed all the permissions that user has. The fact that this isn't really ideal for single-user desktops notwithstanding.
 https://github.com/evilsocket/opensnitch/issues/171 <- apparently some applications bypass OpenSnitch by accident, so it wouldn't be surprising to find out that malicious programs could / are doing it on purpose.
Absolutely. It's funny to see that whenever you dis/connect a USB device there're broadcast transmissions. Or connections to localhost:9229 by Chrome whenever you open the Dev Tools.
I don't rely on it for security, but for curiosity. Right now a Linux box is a Black Box from a user point of view, and this kind of software can help you understand more about your system.
Even if it can be bypassed, it surely make things a bit harder.
I think the name carries a great implication here though. It "snitches" on the apps you have running. Mostly it's not practical (or possible) to work out the "trustworthiness" of every application you run. This discussion has several examples of people realising "_Seriously_ chrome/firefox, you're doing _what?_" when they get Snitched on. That seems useful...
Process hollowing is a last resort. You can get pretty far by exploiting chrome/firefox (with their multiprocess architecture), or by using common command line utils like curl/wget.
>Think of security as a whole instead of debunking a utility because it fails to prevent other types of exploitation
If you understand the limitations, great. However I don't think most users do. As it stands now, using such programs is closer to security by obscurity than any serious security measure (eg. ublock or noscript). The only reason they haven't been bypassed is because the install base is small and isn't worth the effort.
 technically it's still possible to achieve arbitrary communication and/or code execution, but the blocking features can't be bypassed.
'Predictably, online discussions about problems with app translocation and Little Snitch usually recommend stripping quarantine flags, and from what I can see, this has become quite widespread practice. Yet – just as in the blog article – no one seems to be concerned that what they are doing is bypassing macOS’s primary security defences.'
curl --interface en0 ifconfig.co
Can it divert, modify and delay packets? Or just have a set of rules for go/no-go?
I used to run these for a while, but it gets annoying real fast with large amount of pop-up. So now I stop using them, and only block known bad IPs using my Pi-hole, allowing everything else.
I'd consider this too nit-picky in most contexts, but we're in a thread about connection-blocking software. PiHole is a DNS server. It cannot block IPs or connections.
I'm with you that Little Snitch style filtering gets annoying, but DOH is going to obsolete PiHole / DNS filtering very fast. Can't filter DOH at the gateway without taking on all the other hassles of MITM and can't prevent an app from using whatever DOH server it chooses.
Has the same blocking capabilities, however it is not just install and run like LS is. It needs a little configuring to get it to behave like LS, and (For me) it took a bit till I understood what to turn on and what rules to enable. Once I had the rules setup, it's basically the same. Once an app wants to connect you can let it connect once, until terminated, for forever, to once domain only, or any domain.
FortKnox Personal Firewall works too.
Also, all frontends for builtin Windows Firewall that I've tested, have failed in "2ip Firewall Tester".
- There's a countdown when an unknown outgoing connection is discovered - the countdown is currently not being stopped when you focus the countdown window. The countdown is only 15 seconds or so - if the countdown is over, it automatically approves the connection.
- Rules cannot be edited via the python interface. There is one config file per rule though.
- My computer has been freezing sometimes since I started using it. Not sure but that behavior is related to the tool.
- Sometimes high cpu usage.
- It would be great of have some kind of rule-set which can be used as a starting point (optionally).
- Python interface is slow. Generally not a fan of client applications that are based on Python.
The other issue was that their blocking wasn't fine-grained enough; you couldn't, for example, do what others are describing elsewhere in this thread, allowing an application like firefox to connect to a particular site on a particular port only. You could only allow or block the application itself. You could tell the firewall to explicitly ask you on every request, but of course that wasn't feasible for apps like Internet Explorer. So anything that wanted to get around the firewall could just script Internet Explorer to send its request in the background and you would never see it.
Eh, this is such a basic task that even Window's built-in firewall can do it. They just do not make it very obvious in the UI.
If it can now, that's progress. Windows didn't even have a built-in firewall back when third-party firewalls like ZoneAlarm were popular.
On Linux, OpenSnitch and Douane. OpenSnitch is not optimized and results in high CPU usage when you move a lot of traffic. With Douane I had trouble using it for longer than a day since it resulted in my PC crashing caused by the kernel module that it installs. There seemed to be a bug in the C code somewhere, and it didn't go away when I checked back a couple months later.
Coming to Windows, most apps were really old. Only some actually worked with Windows 10 where NDIS 6.x came in and broke some things. Those that did work were so basic you could just use the Windows Firewall app. I tried everything I could get my hands on (in a VM) in search of the nice features that LittleSnitch provided. GlassWire was so far ahead in the features and control it provided, I made an exception in buying a subscription based software (which I almost never do)
If I had that I might even consider off-the-shelf “smart home” stuff but for now I just won’t buy any such hardware unless it’s 100% local with wires and/or 802.1X support, and even then I don’t really trust it.
As a user, it ruins the usability of the operating system. Having alert boxes constantly popping up feels empowering at first, and eventually becomes really annoying and distracting.
As a developer, it breaks your application's expectations and is the root cause of hard to diagnose bug reports. People don't understand what they do and end up breaking software updates (making applications less secure) or other applications features.
As a developer, you kind of have to just accept users taking back their own privacy and work around it.
Is the UI a python web app or a Qt desktop app? There's references to both in the readme
There is also an open issue for tracking a replacement UI in Go