[sgc]

I just tried littlesnitch and it did not resolve very many ips to domains, which is pretty basic. It also failed to identify most processes, and they were grouped under "Not Identified". It appears these are known limitations of the Linux version [1]. So for that alone I need to stick with opensnitch.

[1] "Little Snitch for Linux is built for privacy, not security, and that distinction matters. The macOS version can make stronger guarantees because it can have more complexity. On Linux, the foundation is eBPF, which is powerful but bounded: it has strict limits on storage size and program complexity. Under heavy traffic, cache tables can overflow, which makes it impossible to reliably tie every network packet to a process or a DNS name. And reconstructing which hostname was originally looked up for a given IP address requires heuristics rather than certainty. The macOS version uses deep packet inspection to do this more reliably. That's not an option here." -- from https://obdev.at/products/littlesnitch-linux/index.html

[littlesnitch]

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.

[janc_]

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?

[littlesnitch]

Yes. For these cases it won't work. OpenSnitch intercepts the client side library for this reason. I would rather want to avoid this for the moment and wait for feedback.

[patrakov]

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.

[littlesnitch]

Thanks for that hint! We still get the lookup if it leaves the machine unencrypted, but if you have both, the Unix domain socket and DNS encryption, we miss lookups.

[sgc]

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.

[littlesnitch]

What exactly do you mean with rDNS resolver?

We do not want the reverse lookup name. For instance, if you look up a google.com name with dig, you get an IP address. If you then do the reverse lookup with dig -x, you get a 1e100.net name. That's as good as the IP address for our purpose.

Plus: We need to respond with a DROP or ALLOW verdict to a network packet without the ability to do any blocking requests. So we can only use information already available in the kernel to decide.

[WhyNotHugo]

I'm curious, why not do things like the DNS look-up from userspace?

[a022311]

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.

[toredash]

Is there any DNS based software to do block/allow? Kinda lika what's present in CiliumNetworkPolicies in Kubernetes networking?

[M95D]

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.

[chupasaurus]

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

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

[M95D]

Please explain #2. How is a filtering proxy security through obscurity?

[Milpotel]

You mean like PiHole or AdGuard?

[gus_]

OpenSnitch (+ block lists) ;)

or DNS stubs with filtering capabilities.

[jms703]

I wonder why LS can't be given access to systemd resolved stub resolver to get all my DNS lookups.