Sie müssen nichts installieren, um ein reales, aktuelles Bild davon zu bekommen, mit wem Ihr Mac gerade spricht. Jedes Werkzeug in diesem Lab ist Teil von macOS. Keines davon verlangt, dass Sie Ihren Datenverkehr einem Drittanbieter anvertrauen, und alle sechs zusammen dauern etwa zehn Minuten, sobald Sie die Befehle kennen. Was sie nicht leisten — und das ist wichtig —, ist zu sagen, welche dieser Verbindungen in Ordnung sind und welche nicht. Dafür brauchen Sie weiterhin Kontext, und am Ende sind wir ehrlich darüber, wo diese Werkzeuge an ihre Grenzen stoßen.
1. lsof — jede offene Verbindung, jetzt gerade
Unter Unix ist ein Netzwerk-Socket eine Datei, und lsof (list open files) listet sie auf. Die macOS-Manpage beschreibt -i so, dass es Dateien auswählt, deren Internetadresse einer angegebenen Spezifikation entspricht — wird keine angegeben, sind es alle Internet-Sockets. Mit -n werden Adressen nicht in Hostnamen aufgelöst, mit -P Ports nicht in Dienstnamen; beides macht den Befehl schneller und die Ausgabe exakt statt angenähert.
sudo lsof -i -n -P
# example output, trimmed to a few representative lines
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Mail 612 alice 9u IPv4 0x... 0t0 TCP 192.168.1.10:54321->17.57.145.13:993 (ESTABLISHED)
Slack 980 alice 22u IPv4 0x... 0t0 TCP 192.168.1.10:54400->35.186.224.25:443 (ESTABLISHED)
mDNSResp 88 root 4u IPv4 0x... 0t0 UDP *:5353Lesen Sie es von links nach rechts: Prozessname und PID, die lokale Adresse und der Port, -> sowie die entfernte Adresse und der Port, und der Verbindungsstatus. ESTABLISHED bedeutet eine aktive, bidirektionale Verbindung genau jetzt. Ohne sudo sehen Sie weiterhin Ihre eigenen Prozesse; für Prozesse, die root gehören, brauchen Sie es. Was dieser Befehl nicht kann: lsof ist eine Momentaufnahme des Augenblicks, in dem Sie Enter gedrückt haben. Eine Verbindung, die geöffnet wurde, ein paar Kilobyte gesendet hat und eine halbe Sekunde vor Ihrem Befehl wieder geschlossen wurde, taucht schlicht nicht auf — dafür müssen Sie den Befehl wiederholt ausführen oder zum nächsten Werkzeug wechseln.
2. nettop — dieselbe Ansicht, aber live
nettop ist die Live-Version derselben Idee. Die Manpage beschreibt es als Anzeige „einer Liste von Sockets oder Routen“ mit periodisch aktualisierten Statistiken. -m route schaltet von der Socket-Liste auf die Ansicht der Routing-Tabelle um; -m tcp oder -m udp beschränken die Ausgabe auf ein Protokoll.
nettop -m route
# interactive; press q to quit, or use -l N to print N samples and exit
# example output, trimmed
time interface state bytes_in bytes_out
23:41:02.123 Mail.612 en0 Established 4.2K 1.1K
23:41:02.123 Slack.980 en0 Established 18.6K 6.4KMit -l 5 werden fünf Stichproben erfasst und der Befehl beendet sich, statt eine interaktive Sitzung offenzuhalten — nützlich, wenn Sie die Ausgabe weiterleiten möchten. nettop behebt das Momentaufnahme-Problem von lsof — Sie können beobachten, wie eine Verbindung entsteht, Daten überträgt und sich schließt —, erbt aber dieselbe Grenze: einen Prozessnamen und eine PID, nichts darüber, wer die Binärdatei signiert hat, und kein Gedächtnis, sobald Sie das Terminal schließen.
3. log stream — was das System selbst über das Netzwerk sagt
macOS führt ein einheitliches, strukturiertes Protokoll darüber, was jeder Prozess tut, und mit log stream können Sie es live und gefiltert mitverfolgen. Die Manpage beschreibt --predicate als Filterung von Einträgen mit NSPredicate-artigen Klauseln nach Subsystem, Kategorie, Prozess und Nachrichteninhalt.
log stream --predicate 'eventMessage contains "network" or subsystem == "com.apple.network"' --info
# live stream; Ctrl-C to stop. Example line, trimmed:
2026-09-14 23:41:05.001 process=nesessionmanager subsystem=com.apple.network "TCP Connection ... state changed to Ready"Das ist das am wenigsten zugängliche der sechs Werkzeuge — die Datenmenge ist hoch, und die Syntax der Prädikate hat eine Lernkurve —, aber es ist auch das einzige, das Änderungen des Netzwerkstatus auf Systemebene und Ereignisse im Lebenszyklus von Verbindungen in (halbwegs) verständlichem Englisch zeigt, sobald sie passieren, versehen mit dem zuständigen Subsystem. Behandeln Sie es als etwas zum Durchsuchen, nicht zum zeilenweisen Lesen: leiten Sie es durch grep für einen Prozessnamen, der Sie interessiert, oder ein Schlagwort wie "Wi-Fi" oder "VPN".
4. scutil --dns und dig — was Ihr Mac tatsächlich auflöst
Bevor eine Verbindung zustande kommt, gibt es meist eine DNS-Abfrage. scutil --dns „meldet die aktuelle DNS-Konfiguration“, so die Manpage: welche Resolver konfiguriert sind, welcher davon der Standard ist und welche nur für bestimmte Domains gelten (Split-DNS, häufig bei VPNs).
scutil --dns
# example output, trimmed
DNS configuration
resolver #1
nameserver[0] : 192.168.1.1
if_index : 12 (en0)
flags : Request A records, Request AAAA records
reach : 0x00020002 (Reachable,Directly Reachable Address)dig beantwortet direkt eine einzelne Frage: Wozu löst dieser Name gerade auf. Die Manpage nennt es „ein flexibles Werkzeug zum Befragen von DNS-Nameservern“, geschätzt für „Flexibilität, Einfachheit und Klarheit der Ausgabe“.
dig example.com +short
# example output
93.184.216.34Keines der beiden Werkzeuge sagt Ihnen, welche App die Abfrage ausgelöst hat oder was danach geschah — DNS liefert nur die Adresse, zu der eine App gleich (oder bereits) eine Verbindung aufbaut; die Verbindung selbst zeigen Ihnen lsof, nettop oder ein Firewall-Protokoll.
5. tcpdump — die ungeschminkte Wahrheit, und das Werkzeug, das sudo braucht
Alles oben liest einen Zustand, den das Betriebssystem ohnehin schon führt. tcpdump ist anders: Es erfasst Pakete direkt an einer Schnittstelle, weshalb die eigene Dokumentation unmissverständlich ist — „Das Lesen von Paketen von einer Netzwerkschnittstelle kann besondere Rechte erfordern“ —, in der Praxis also sudo unter macOS. Mit -i wählen Sie die Schnittstelle, mit -n bleiben Adressen numerisch, und ein Filterausdruck wie port 53 isoliert den DNS-Verkehr:
sudo tcpdump -i en0 -n port 53
# example output, trimmed
23:41:10.221331 IP 192.168.1.10.54812 > 192.168.1.1.53: 41213+ A? example.com. (30)
23:41:10.244109 IP 192.168.1.1.53 > 192.168.1.10.54812: 41213 1/0/0 A 93.184.216.34 (46)Worauf Sie achten sollten: eine Anfrage, die über Port 53 hinausgeht, unmittelbar gefolgt von einer zurückkommenden Antwort. Wenn Sie dig in einem Terminal ausführen, während in einem anderen tcpdump läuft, sehen Sie genau die Anfrage und Antwort, die Ihr eigener Befehl erzeugt hat — eine gute Möglichkeit, das, was die Manpages behaupten, tatsächlich nachzuvollziehen, statt es einfach zu glauben.
Ein kostenloses siebtes Werkzeug: Aktivitätsanzeige
Es lohnt sich, auch die eine grafische Option in dieser Liste zu nennen, denn nicht alles braucht ein Terminal. Der Reiter „Netzwerk“ der Aktivitätsanzeige zeigt Ihnen Summen — gesendete und empfangene Daten pro Prozess sowie einen Live-Graphen der Durchsatzrate —, was die richtige erste Anlaufstelle ist für „irgendetwas frisst Bandbreite, und ich weiß nicht, was“. Es ist auch die klarste Illustration der Grenze, die alle Werkzeuge in diesem Artikel teilen: Es kann Ihnen sagen, dass ein Hilfsprozess über Nacht zwei Gigabyte bewegt hat, hat aber keine Spalte dafür, wohin diese zwei Gigabyte gegangen sind. Menge und Ziel sind zwei verschiedene Fragen, und macOS beantwortet sie mit zwei verschiedenen Werkzeugen.
Die zehn Minuten im Zusammenhang
sudo lsof -i -n -P— die aktuelle Liste offener Sockets holen, ein Durchgang, dreißig Sekunden.nettop -m route -l 5— ein paar Live-Stichproben erfassen, um alles zu erwischen, was die Momentaufnahme von lsof verpasst hat.scutil --dns— bestätigen, welchen Resolver Sie tatsächlich verwenden, besonders bei VPN oder öffentlichem WLAN.dig <name> +shortfür alles Unbekannte aus Schritt 1, um zu sehen, wozu es aktuell auflöst.sudo tcpdump -i en0 -n port 53, für sechzig Sekunden, um den rohen DNS-Verkehr zu beobachten, während Apps ihrer Arbeit nachgehen.log stream --predicatemit einem Schlagwort-grep, falls einer der Schritte oben eine Frage aufgeworfen hat, die die vorherigen fünf nicht beantwortet haben.
Ein durchgerechnetes Beispiel
Angenommen, Schritt 1 zeigt einen Prozess namens helperd, der eine offene Verbindung zu einer Adresse hält, die Sie nicht kennen. Hören Sie hier nicht auf. Führen Sie dig -x <die Adresse> für eine Rückwärtsauflösung aus — sie löst nicht immer zu etwas Lesbarem auf, aber wenn doch, sagt Ihnen ein Hostname wie ads.example-cdn.net in fünf Sekunden mehr als die reine IP-Adresse je könnte. Führen Sie nettop -m tcp -l 3 aus und beobachten Sie, ob dieselbe Verbindung ein paar Sekunden später noch offen ist und ob tatsächlich Bytes darüber fließen oder sie im Leerlauf verharrt. Ist sie im Leerlauf und öffnet sich in festen Abständen erneut, spricht das für eine periodische Rückmeldung statt einer einmaligen Übertragung — bemerkenswert, aber nicht automatisch besorgniserregend, denn gewöhnliche Update-Prüfungen verhalten sich genauso. Prüfen Sie dann scutil --dns, um zu bestätigen, dass der Resolver, der die Adresse geliefert hat, mit der sich helperd verbunden hat, tatsächlich der erwartete war — besonders in einem fremden WLAN. Fünf Befehle, ein Prozess, und Sie sind von „das kenne ich nicht“ zu „hier ist genau, was ich darüber weiß und was nicht“ gelangt — was das eigentliche Ziel eines solchen Audits ist, mehr als ein Urteil zwischen gut und schlecht.
Was Ihnen keines dieser Werkzeuge sagt
Auch nach allen sechs Schritten bleiben drei echte Lücken. Erstens die Identität jenseits eines Prozessnamens: Nichts hier prüft, ob die Binärdatei namens „Mail“ tatsächlich Apples Mail ist oder sich nur so umbenannt hat, oder ob sie überhaupt signiert ist — das ist eine eigene Abfrage mit codesign und spctl. Zweitens das Gedächtnis: Sobald das Terminalfenster schließt, verschwindet auch alles, was Sie erfahren haben; es gibt kein Protokoll darüber, „womit sich mein Mac letzten Dienstag verbunden hat“, außer Sie legen selbst eines an. Drittens das Urteilsvermögen: Keines dieser Werkzeuge hat eine Meinung dazu, ob eine Verbindung erwartet ist. Eine Notiz-App, die sich mit einer Adresse verbindet, die sie nie zuvor genutzt hat, sieht in lsof genauso aus wie eine, die sich mit ihrem gewohnten Synchronisierungsserver verbindet — die beiden auseinanderzuhalten ist Mustererkennung, die entweder Sie selbst mitbringen müssen oder die ein Werkzeug für Sie leisten muss.
Wo FireAI und HisnLabs ins Spiel kommen
Everything in this lab is free and built into macOS, and none of it names the process behind a connection or remembers it after the terminal closes — which is the specific, narrow gap FireAI’s per-app rules and connection history are built to close.
FireAI ist das eigene Produkt von HisnLabs: eine KI-Firewall für den Mac, die direkt auf dem Gerät läuft. Sie zeigt jede Verbindung Ihrer Apps in verständlicher Sprache und lässt Sie entscheiden, was Ihren Mac verlässt — die KI arbeitet lokal, Ihr Datenverkehr wird also nie an uns oder irgendjemand anderen gesendet. Das Sicherheitsforschungsteam von HisnLabs sorgt dafür, dass diese Entscheidungen verlässlich bleiben: Es katalogisiert, welche Domains gewöhnliche Telemetrie und welche ein echter Dienst sind, verfolgt Land und Netzwerk hinter einer Verbindung und trainiert das lokale Modell (die Autopilot-Funktion) mit echten Verkehrsmustern — ohne dass irgendetwas davon Ihren Mac verlässt.
Die technischen Entscheidungen dahinter können Sie nachlesen — oder FireAI 17 Tage lang ausprobieren — unter FireAI, von HisnLabs.