upvote
Regarding unidentified processes: Little Snitch daemon must have been running when the process started in order to identify it reliably. It's best to reboot after installation so that Little Snitch starts before everything else. I should probably note this somewhere.

And regarding failed reverse DNS names: Little Snitch is sniffing DNS lookups. If lookups are encrypted, there is little it can do. We usually recommend DNS encryption at the systemd layer, not at app layer. This way we can see lookups on 127.0.0.53 and the actual lookup sent out is still encrypted.

Also, it's currently only sniffing UDP lookups, not TCP. The eBPF part is already very close to the complexity limits (700k instructions of allowed 1M) and adding TCP parsing would exceed this limit. It should be possible to forbid TCP port 53 with a rule, though. Some complex DNS lookups will fail, but routine things should still work.

reply
The thing is, 127.0.0.53 is a fallback. The real default upstream is nss_resolve, which talks to systemd-resolved via non-DNS protocol on a UNIX-domain socket. Ubuntu disabled this in favor of the less-featured fallback. If you insist on sniffing DNS, you need to add instructions to disable the native nss_resolve module by not including it in /etc/nsswitch.conf.
reply
If I don't know who my machine is talking to, the information is not very useful. So there needs to be a fallback on some level.

Perhaps there should be a mode where littlesnitch just does its own lookup using the system-configured rDNS, for example from the ui or for specific processes, etc? It should be cached if it is a recent lookup, so minimal performance implications; and offloaded to the system rDNS resolver, so minimal instruction set.

reply
Not all "hostname lookups" by applications happen over DNS (or the DNS is done by something like systemd-resolved, which is often using encrypted lookups), so in many cases, depending on NSS configuration (e.g. 'file', 'resolve', 'db', 'nis', 'mymachines', 'libvirt', 'winbind', ...) this would never work?
reply
I'm curious, why not do things like the DNS look-up from userspace?
reply
I guess that makes sense, since it's pretty new. OpenSnitch is great software in terms of functionality but I find the UI lacking. If LittleSnitch can keep the same functionality, while improving the UI, I'm switching. My other current concern here is that the LittleSnitch UI is just a Webview and I think it would be much better if there was a native option (ideally GTK-based for me, but Qt would also be acceptable). Webviews are slow and full of bloat.
reply
I wonder why LS can't be given access to systemd resolved stub resolver to get all my DNS lookups.
reply
Is there any DNS based software to do block/allow? Kinda lika what's present in CiliumNetworkPolicies in Kubernetes networking?
reply
Yes, PiHole is the most common, but malware can easily bypass that using shared domains, P2P or IP addresses directly.

Use a filtering proxy instead and no gateway / route to the internet.

reply
1) Dnsmasq, you don't need the whole PiHole for that.

2) You're advising security through obscurity instead of a network namespace + firewall.

reply
You mean like PiHole or AdGuard?
reply
OpenSnitch (+ block lists) ;)

or DNS stubs with filtering capabilities.

reply