Erweiterte Themen

Dieses Kapitel erklärt die inneren Abläufe von Little Snitch für Linux für technisch interessierte Leser. Nichts hiervon ist für die alltägliche Nutzung erforderlich, aber es hilft zu verstehen, was das Produkt kann und was nicht, und warum.

Warum Linux nicht alles kann, was die macOS-Version kann

Little Snitch klinkt sich mithilfe von eBPF in den Linux-Netzwerkstack ein. eBPF ist ein Mechanismus, der Programmen erlaubt, Ereignisse innerhalb des Kernels sicher zu beobachten und abzufangen. Ein eBPF-Programm beobachtet ausgehende und eingehende Verbindungen und liefert Daten an den Daemon, der Statistiken führt und die Web-Oberfläche bereitstellt.

eBPF ist mächtig, aber bewusst begrenzt. Bevor ein eBPF-Programm geladen wird, analysiert der Verifier des Kernels es statisch und weist alles zurück, dessen Sicherheit und Terminierung er nicht beweisen kann. Das erzwingt strikte Grenzen für Programmkomplexität und Speicher:

Keine Verbindungswarnungen. eBPF-Programme können das aufrufende Programm nicht anhalten, während eine Warnung angezeigt wird.
Keine Deep Packet Inspection. Die macOS-Version von Little Snitch analysiert Protokoll-Header innerhalb von Netzwerkpaketen. Algorithmen dieser Komplexität würden den eBPF-Verifier nicht passieren, daher kann die Linux-Version Protokollinhalte über einfache TCP/IP-Header hinaus nicht untersuchen.
Begrenzte Cache-Tabellen. eBPF-Maps haben fixe Maximalgrößen. Bei starkem Datenverkehr können die Tabellen, die Pakete mit Prozessen und DNS-Namen verknüpfen, überlaufen. Wenn das passiert, lassen sich manche Pakete nicht mehr zuverlässig zuordnen.

Das ist die technische Ursache für die Aussage in der Einführung: Little Snitch für Linux ist für den Datenschutz gemacht, nicht um ein System gegen einen gezielten Angriff zu härten.

IP-Adressen zu Namen auflösen

Das Problem

Nutzer wollen Regeln für Domainnamen, denn alles andere ist unübersichtlich. Aber der Filter arbeitet im Kernel, wo nur IP-Adressen sichtbar sind. Little Snitch muss deshalb rekonstruieren, welcher Name für eine gegebene IP-Adresse abgefragt wurde.

Diese Rekonstruktion ist grundsätzlich mehrdeutig. Viele Namen können auf dieselbe IP-Adresse verweisen. Websites mit hohem Datenverkehr werden typischerweise auf Content-Delivery-Networks gehostet. Es ist durchaus möglich (und sogar wahrscheinlich), dass sich eine Tracking-Seite und ein Computermagazin dieselbe Adresse teilen.

Zwei bekannte Techniken

Es gibt zwei allgemeine Techniken, um einen Namen für eine IP-Adresse zu ermitteln:

Zeitliche Nähe von Abfragen. Man beobachtet DNS-Abfragen und ihre Antworten. Wird eine Verbindung zu einer IP-Adresse aufgebaut, nimmt man die zuletzt beobachtete DNS-Abfrage, deren Antwort diese Adresse enthielt.
Im Protokoll mitgeführte Namen. Viele Protokolle enthalten den Namen des Servers in ihren Daten. Insbesondere sendet ihn TLS im SNI-Header (Server Name Indication) mit, und QUIC hat ein Äquivalent.

Beide Techniken sind unzuverlässig.

Zur ersten: Ein Prozess kann eine Abfrage durchführen, das Ergebnis zwischenspeichern und erst viel später eine Verbindung aufbauen. Bis dahin kann die zuletzt beobachtete Abfrage für diese Adresse einem anderen Namen gegolten haben. Immerhin ist der so gefundene Name zumindest ein gültiger Name für die Adresse. Außerdem funktioniert die Beobachtung nur, solange DNS-Abfragen unverschlüsselt sind.

Zur zweiten: Der SNI-Header liegt vollständig in der Kontrolle des Clients. Der Client kann einen beliebigen Namen senden, solange ihn der Server akzeptiert. Und es gibt laufende Bestrebungen, SNI zu verschlüsseln (Encrypted Client Hello).

Little Snitch für macOS nutzt beide Techniken: Es liest den Namen primär aus Protokoll-Headern, gleicht ihn aber mit kürzlich beobachteten DNS-Abfragen ab. Little Snitch für Linux kann Protokoll-Header nicht untersuchen, wie oben erklärt, und verlässt sich daher ausschließlich auf die zeitliche Nähe von DNS-Abfragen. Das funktioniert in der Regel sehr gut, außer wenn ein DNS-Cache zwischen der Anwendung und dem sichtbaren Netzwerkverkehr sitzt oder DNS-Abfragen verschlüsselt sind.

DNS-Sichtbarkeit und systemd-resolved

Auf modernen Distributionen sitzt üblicherweise systemd-resolved zwischen Anwendungen und dem Netzwerk. Es kann zwei Dinge tun, die die Beobachtung von Abfragen stören: Antworten zwischenspeichern und DNS verschlüsseln. Die Konsequenz: Little Snitch sollte die Kommunikation zwischen der Anwendung und systemd-resolved beobachten, nicht die Abfragen, die systemd-resolved an den entfernten DNS-Server sendet.

systemd-resolved bietet Anwendungen zwei Schnittstellen:

Einen UDP/TCP-Socket auf 127.0.0.53, Port 53. Das ist gewöhnlicher Loopback-Netzwerkverkehr, den der Netzwerkfilter von Little Snitch beobachten kann.
Einen Unix-Domain-Socket, der vom nss-resolve-Modul der glibc verwendet wird. Verkehr auf Unix-Domain-Sockets ist kein Netzwerkverkehr und für den Filter nicht ohne Weiteres zugänglich.

Für beste Ergebnisse stelle sicher, dass Anwendungen den UDP-Socket statt des Unix-Domain-Sockets verwenden. Das wird über die hosts:-Zeile in /etc/nsswitch.conf gesteuert. Enthält diese Zeile das Schlüsselwort resolve, verwendet glibc das nss-resolve-Modul und kommuniziert über den Unix-Domain-Socket mit systemd-resolved, unsichtbar für Little Snitch. Entferne das Schlüsselwort resolve (und jede unmittelbar darauffolgende Bedingung in eckigen Klammern). Dann fällt glibc auf klassisches DNS über /etc/resolv.conf zurück, und diese Datei verweist auf einem systemd-verwalteten System auf 127.0.0.53. Zum Beispiel:

hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns

Die Namensauflösung verhält sich danach unverändert. Die Anfragen laufen lediglich über den beobachtbaren UDP-Socket statt über den verborgenen Unix-Domain-Socket.

DNS-Verschlüsselung auf Anwendungsebene

Manche Anwendungen, insbesondere Webbrowser, bieten eine eigene Einstellung für DNS over HTTPS (oder TLS oder QUIC) an. Ist diese aktiviert, sendet die Anwendung verschlüsselte Abfragen direkt an einen entfernten Resolver, und Little Snitch sieht von dieser Anwendung überhaupt keine Abfragen mehr.

Unsere Empfehlung: Deaktiviere die DNS-Verschlüsselung in einzelnen Anwendungen und aktiviere sie stattdessen in systemd-resolved. Little Snitch beobachtet dann die unverschlüsselten Abfragen zwischen der Anwendung und systemd-resolved, während systemd-resolved jenen Verkehr verschlüsselt, der deinen Rechner tatsächlich verlässt. Als willkommener Nebeneffekt profitiert dein gesamtes System von der DNS-Verschlüsselung, nicht nur der Browser.

Um verschlüsseltes DNS systemweit zu aktivieren, setze DNSOverTLS=yes (oder DNSOverTLS=opportunistic) in /etc/systemd/resolved.conf oder einer Drop-in-Datei unter /etc/systemd/resolved.conf.d/, und starte systemd-resolved neu. Suche in Browsern nach der Einstellung für DNS over HTTPS oder „sicheres DNS“ und stelle sie so ein, dass der Resolver des Betriebssystems verwendet wird.

Loopback-Antworten

DNS-Antworten, die Loopback-Adressen enthalten (127.0.0.0/8, ::1), werden verworfen. Solche Antworten stammen üblicherweise von blockierenden Resolvern wie Pi-hole, und dort blockierte Namen sollten nicht dem Loopback-Verkehr zugeordnet werden.

Zuordnung des übergeordneten Prozesses

Wie unter Verbindungen im Blick beschrieben, zeigt Little Snitch „übergeordneter Prozess via Prozess“ an, wenn ein Hilfsprozess wie curl eine Verbindung im Auftrag eines anderen Programms aufbaut. Hier erfährst du, wie der übergeordnete Prozess gefunden wird.

Little Snitch durchläuft die Elternkette des verbindenden Prozesses und versucht, „etwas Interessantes“ zu finden. Wird ein interessanter übergeordneter Prozess gefunden, wird die Verbindung als „übergeordneter Prozess via Prozess“ angezeigt, und Regeln für diese Kombination werden berücksichtigt. Regeln nur für den übergeordneten Prozess werden ebenfalls berücksichtigt. Sie gelten für Verbindungen, die dieser direkt oder über einen beliebigen anderen Prozess aufbaut.

„Etwas Interessantes“ steht bewusst in Anführungszeichen, denn es gibt keine scharfe Definition. Drei Verfeinerungen machen die Heuristik brauchbar:

App-Manager beenden die Suche. Letztlich ist jeder Prozess auf dem System ein Kind von systemd, und niemand möchte überall „systemd via irgendwas“ sehen. Es gibt eine Liste von App-Managern (Init-Systeme, Desktop-Starter und Ähnliches). Wird einer davon in der Elternkette angetroffen, bricht die Suche ab.
Shells werden übersprungen. In einer Kette wie „App verwendet Shell verwendet curl“ ist nicht die Shell der interessante Teil, sondern die App. Eine Liste von Shells legt ausführbare Dateien fest, die beim Durchlaufen der Kette stillschweigend übersprungen werden.
Ein Prozess ist nie sein eigener übergeordneter Prozess. Manche Programme rufen fork() auf und lassen einen Unterprozess die Arbeit erledigen. Da es sich um dieselbe ausführbare Datei handelt, wird kein übergeordneter Prozess angezeigt.

Die Listen der App-Manager und Shells werden als Glob-Muster in executables.toml konfiguriert. Wie du diese Datei überschreibst, erfährst du unter Erweiterte Konfiguration, die Syntax steht in der Datei selbst.

Normalisierung ausführbarer Dateien

Mangels anderer Erkennungsmerkmale werden ausführbare Dateien anhand ihres Pfads im Dateisystem identifiziert. Bei den meisten ausführbaren Dateien ist der Pfad fix. Manche enthalten aber in einem übergeordneten Verzeichnis eine Versionsnummer, die sich mit jedem Upgrade ändert. Und manche werden dynamisch unter einem Einhängepunkt eingebunden, dessen Name eine eindeutige Kennung enthält und sich bei jedem Start ändert.

Regeln sollen Updates und Neustarts überstehen, und die Verbindungsansicht soll nicht für jede Version oder nach jedem Start einer Anwendung eine eigene Zeile zeigen. Little Snitch normalisiert deshalb Pfade, bevor Regeln zugeordnet oder Einträge gruppiert werden.

Die Normalisierung wandelt den Pfad in ein Glob-Muster um: Die Versionsnummer oder eindeutige Kennung wird durch * ersetzt, im selben Stil wie bei Mustern, die bash und andere Shells verwenden.

Welcher Teil eines Pfads eine Versionsnummer oder eindeutige Kennung ist, lässt sich nicht zuverlässig erraten, deshalb wird es in executables.toml konfiguriert. Ein Normalisierungseintrag besteht aus:

einem regulären Ausdruck, der auf die betreffenden Pfade zutrifft, und
einem Glob-Muster mit Ersetzungsverweisen, in das die erfassten Teilzeichenketten eingesetzt werden.

Eine Einschränkung verdient besondere Betonung: Das resultierende Glob-Muster muss selbst vom regulären Ausdruck erfasst werden. Das lässt sich im Code nicht erzwingen oder einfach überprüfen. Es muss von der Person gewährleistet werden, die das Muster schreibt. Überprüfe diese Eigenschaft sorgfältig, wenn du eigene Einträge hinzufügst.

Wenn du Normalisierungsmuster schreibst, von denen auch andere Nutzer profitieren könnten, teile sie gerne mit uns.