Little Snitch is one of my favorite apps in the world, and it's one of the very first things I install on any new Mac.
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.
Using Little Snitch, and seeing the amount of phoning-home Chrome was doing was my "straw that broke the camels back". It tipped me over the edge: drove me back to Linux, Duck Duck Go, NextDNS (I'm not confident enough to "roll my own), turning everything off on my phone (location services, search helpers etc), and not using software that checks for updates or does the least amount of telemetry (I went from VSCode to Emacs)... favoring anything that doesn't track/use cdns/anything by default: whatever is vaguely usable (no matter how annoying) and tracks the least, wins.
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 [0], 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 1.1.1.1 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) [1] 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) [2], 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) [3].
That said, the simplest way to ad-block would be to point the workers instance to adguard-doh.
Maintaining Lil'Snitch's access list whenever apps get updated reminded me that it goes against the reason why I started using MacOS in the first place. It was especially hard to justify when someone else is casually browsing on one my machines and a new connection request pops up.
I'd not heard of NextDNS until I read your comment, but it looks really promising! I already have a PiHole set up but I'm always looking to simplify and eliminate "maintenance" from my life (although the Pihole is extremely low maintenance).
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.
Huge fan of Little Snitch, and I agree: it's been really useful for discovering and shutting down all the telemetry and ad traffic. One thing people don't realize is that you can take many of the popular ad-blocking lists and subscribe to them in Little Snitch! Peter Lowe's Block List, for instance, produces a plain-text format (https://pgl.yoyo.org/adservers/serverlist.php?hostformat=lit...) that's perfect: you subscribe to it in Little Snitch, and it automatically blocks everything on the list everywhere, with updates pulled on the regular from the pgl.yoyo.org servers.
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.
Also I personally also am a huge fan of Little Snitch, I do want to caution everyone who rushes to install that, after all, like all software Little Snitch has bugs, and because it runs in ring 0, any bugs can potentially have annoying consequences, including being exploited by malware.
See for example this news report[0] or the DEF CON talk[1].
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.
I would think Little Snitch reduces your attack surface enough that it's a strict improvement in security, not just privacy. After all, macOS has bugs too.
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).
On the cheaper side on the spectrum but not quite as cheap as TripMode, there is Vallum: https://vallumfirewall.com
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
I tried to install TrioMode for the bandwidth-monitoring features until I realized it actually needs to run in the kernel, which is too much of security trade off for me to accept.
Thanks for the link to TripMode. Didn't realize how much I need it. Always try to turn off apps when I'm tethered but somehow still eat up all my data.
I will be curious what kinds of bugs blocking said requests flushes out of various applications. I expect some applications will be built robustly and gracefully accept that adserver.trackallusers.com has suddenly ceased to exist forever, and continue to do what the user expects them to do. But, I will not be surprised if other applications turn out to crash, turn into security vulnerabilities, or throw up annoying popups that say something like, "We use advertisements to pay for this awesome free service we give you. :( Please unblock evil-cabal.org. An assassin has been dispatched to ensure your compliance." Okay, maybe I'm not expecting that last one quite so much, but crashes and breakages are totally plausible, IMO.
There are numerous Mac, Windows and Linux apps that do not behave well when they detect the network is up, but they can not reach a resource. Most of the time I run into these on Windows. Some apps can lock up the desktop until the flow is permitted, but permitting the flow requires the desktop.
Why do people use non-standard ports for public internet-facing services?
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.
Security through obscurity is one reason. A lot of script kiddies will blast away at services on well known ports. Simply changing the port off the default cuts down on a lot of script based attacks, inhibits generic port scans, and makes it easier to differentiate a deliberate, human attacker from a script.
In this specific case, I don't know. Perhaps rotating through ephemeral ports is done to mess with simple traffic filtering rules on firewalls?
I will second the notion that setting up your preferences after installing little snitch is a bit overwhelming, especially if it's on a machine where you have installed a lot of software.
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.
Its threat model isn’t to protect you from anything a state-level actor might try to do, but to give you insight into changed app behaviors. Why is my weather app now talking to Bolivia? Why is a shell script trying to connect to an Active Directory server? I don’t think that’s so much a hole as something that’s just out of scope for Little Snitch.
The DNS lookup would be of the form "request PTR record for 128.2.1.2" - this would leak a little info from the nearest recursing resolver, but maybe not enough to be useful to an attacker. I suppose Snitch might conceivably use some other, non-DNS repository like ipinfo.io though.
Does Little Snitch work as a kernel extension? I use Lulu but it really screws with Virtualbox and generally can really stress kernel if you try to do something very network intensive. Would love to find better alternative, ideally free.
This is neat, but it seems strange to call it a "port" of a closed source proprietary commercial product. It doesn't actually seem to be related beyond also being a firewall with a UI that kinda imitates Little Snitch.
Software like this seem like snakeoil to me. They often rely on process paths to identify applications, but that can be easily bypassed by using a reputable/plausible program as a lackey [1], or more sophisticated techniques like process hollowing[2]. Afterwards, they can communicate as the (presumably whitelisted) application. Any host-based rules (if any) can be bypassed by routing internet traffic using "popular" domains (eg. CDNs, social media networks), or by social engineering (eg. triggering a request at the same time as a user action, to make the user think it's something he intended to do).
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.
> They often rely on process paths to identify applications, but that can be easily bypassed by using a reputable/plausible program as a lackey, or more sophisticated techniques like process hollowing
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 [1] [2].
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.
[2] 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.
> Seems like this is probably a useful tool to figure out programs that are talking to servers when they're expected to be silent
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.
> 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.
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...
Applications that perform DLL injection or modify PEB or to try ring 0 escalation can already be detected in some forms by heuristic anti virus. Little Snitch is still useful as long as the other bases are covered. Think of security as a whole instead of debunking a utility because it fails to prevent other types of exploitation
>Applications that perform DLL injection or modify PEB or to try ring 0 escalation can already be detected in some forms by heuristic anti virus.
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[1]). The only reason they haven't been bypassed is because the install base is small and isn't worth the effort.
[1] technically it's still possible to achieve arbitrary communication and/or code execution, but the blocking features can't be bypassed.
An application can also repeatedly ask for permissions, flooding the user with (little snitch or whatever) popups until they gave up and disable it just to be able to use their computer again.
'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.'
One feature opensnitch has (and I have not seen mentioned here) is that you can run the filter on one device e.g. your openwrt router, and the GUI on your laptop; this is a nice feature that no other “personal” firewall (including the original LittleSnitch) provides - filtering for your iPad and smart tv as well!
Fun fact: in macOS Little Snitch if you create a separate profile for your VPN interface (as specified with the goal to allow certain apps/traffic only when the VPN is up), circumventing the VPN it is as easy as:
curl --interface en0 ifconfig.co
In other words, no firewall rules are applied to actually block traffic on the non-VPN interface. Apps are only blocked from accessing the internet when the VPN interface goes down.
> yes, i'm not working on it anymore and i'm not responding to issues, because i lost interest and nobody pays me for this ... if this project is so essential (?), the "Linux community" can fork it and send a PR.
Readit News
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 [0], 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 1.1.1.1 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) [1] 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) [2], 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) [3].
That said, the simplest way to ad-block would be to point the workers instance to adguard-doh.
[0] https://news.ycombinator.com/item?id=21598413
[1] https://github.com/pieroxy/lz-string/
[2] https://stackoverflow.com/questions/5562297/fast-search-in-c...
[3] https://news.ycombinator.com/item?id=22017868
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
- Done.
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[0] or the DEF CON talk[1].
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.
[0]: https://www.theregister.co.uk/AMP/2016/08/03/mac_firewall_li...
[1]: https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20pre...
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.
Something from dev.visualweboptimizer.com! Had to make an exception
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.
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.
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.
[1] https://news.ycombinator.com/item?id=22207089
[2] https://wikileaks.org/ciav7p1/cms/page_3375167.html
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 [1] [2].
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.
[1] https://github.com/evilsocket/opensnitch/issues/12
[2] 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[1]). The only reason they haven't been bypassed is because the install base is small and isn't worth the effort.
[1] 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.'
https://eclecticlight.co/2020/01/26/last-week-on-my-mac-when...
https://github.com/evilsocket/opensnitch/issues/259
https://github.com/evilsocket/opensnitch/issues/259#issuecom...