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.
Add Google to the list. It is unfortunate that not even one of these companies can differentiate from the others on this practice. They each assume that the user gives them a free pass to make automatic outbound connections, where no consent from the user is required, for whatever purpose they deem "necessary".
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
Yeah, Little Snitch offers fine grained filtering control as it works at the "connection" level monitoring each and every connection, where as TripMode works at the "app" level only and either allows or blocks them from accessing the internet without any regards to the number of "connections" made or to whom the "connection" is made to.
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).
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.
I guess for bandwidth-monitoring alone that may seem like an overkill. But it's a firewall too. The TripMode FAQ does point out:
> 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).
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.
You would need to do that for every domain firefox talks too, which will quickly get annoying, as stated in the original comment:
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
How are you going to handle CDNs? Are you going to whitelist all the [random letters].cloudfront.net? What about public websites? You can conceivably establish a communications channel over any popular social media site.
uMatrix helps with all of this to block domains by name in the browser.
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.
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.
I don’t know how little snitch does it, but iirc our old fortinet at the office caches the DNS response for logging, so that no extra reverse dns requests are needed (and if there isn’t a cached one, you have to explicitly ask to look it up when looking at the logs)
From a quick look in opensnitch, it should be tracking DNS replies in UDP packets.
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.
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.
Reminds me of that Windows marvel called Kerio Personal Firewall which allowed to restrict connections for any application, a feature that Linux should have had since forever and is becoming more and more important today. Most Linux FOSS apps may not call home, but closed hosted or emulated ones (through WINE for example) often do.
Linux does do that, and has since the Kernel 2.2 or so; In fact, opensnitch is a user mode process thanks to Linux allowing that, whereas windows needed drivers last I checked (win 2000 days, but the network driver model was still the same for win 7 and even later iirc)
I never knew about that, thanks. I always believed one had to either resort to address/packet filtering at machine level or limit access to networking to a certain uid/gid, then running the software under those credentials. But that would defeat the purpose of allowing access while being warned about that, so that for example one could check if an application is really phoning home for innocuous updates or connecting to some shady addresses for unknown purposes.
There's loads of firewall application on Windows: ZoneAlarm, Comodo, Tinywall. Some use their own packets filtering driver, while some are just frontend for Window's built-in firewall.
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.
Windows Firewall Control https://www.binisoft.org/wfc.php is a nice interactive control system for the built in windows 10 firewall control, its good.
It became free some time last year 2019 afaik.
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.
There are many, some better, some worse in particular ways. It all began with Outpost firewall during the Windows 98 days, then more alternatives emerged. Kerio Personal Firewall was what I liked the best for Windows XP. Windows 7-10 have surprisingly good firewall built-in, all you need is a good GUI to control it - Windows 10 Firewall Control by Sphinx Software.
i wanted something a bit simpler, so forked and reduced. recently dropped path matching except for display in the visual prompt, simple global firewall, inbound and out. as others noted, path matching is quite janky. never saw a use of libnetfilterqueue before this, so hats off to evilsocket.
Great that this exists. I really like the application. Here are some issues:
- 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.
About 15 years ago this kind of "application firewall" used to be really popular on Windows. IIRC, ZoneAlarm and/or Kerio was really popular? And some Antivirus software also included application firewall. Can't vouch for anything particular these days, though, haven't used such thing for a long time.
The problem with all such applications on Windows was (and probably still is) that it was too easy to install something that could bypass them at the network layer.
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.
Zone Labs released ZoneAlarm in 2000. Microsoft shipped Windows XP with the built-in Internet Connection Firewall (later rebranded to Windows Firewall) in 2001. ZoneAlarm was far more intuitive to use, but there was only one year when Windows did not have a built-in firewall while ZoneAlarm already out.
To be fair, Window XP's firewall cannot block Outgoing connection, only Incoming. Vista SP1 and later versions of Windows include a firewall with Outbound blocking.
I've tried various apps, including this. Other apps like this too, both on Linux and Windows.
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)
There already are enough powerful network-level firewalls available for Linux. The key feature of LittleSnitch mising on Linux is controlling network activities of particular applications on your computer.
That’s one key feature, but another is the real-time approval UI. I’d love to have that for my other network devices like printers, video game consoles, etc.
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.
I've never been a fan of that kind of application.
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.
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.