[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?