Sprawdź, co Twój Mac wysyła w ciągu 10 minut z terminala

Nie musisz niczego instalować, aby uzyskać prawdziwy, aktualny obraz tego, z czym rozmawia Twój Mac. Każde narzędzie w tym laboratorium jest dostarczane z systemem macOS. Żaden z nich nie wymaga powierzania ruchu osobom trzecim, a przejrzenie wszystkich sześciu zajmuje około dziesięciu minut, gdy znasz polecenia. To, czego nie zrobią, a to ma znaczenie, to powiedzenie Ci, które z tych połączeń są w porządku, a które nie – do tego nadal potrzebny jest kontekst, a na koniec będziemy szczerze mówić o tym, gdzie kończą się te narzędzia.

1. lsof — każde otwarte połączenie, w tej chwili

W systemie Unix gniazdo sieciowe jest plikiem, a lsof (lista otwartych plików) wyświetla je. Strona podręcznika systemu macOS opisuje -i jako wybieranie plików, których adres internetowy odpowiada podanej specyfikacji — bez podania żadnego, dla każdego gniazda internetowego. Dodaj -n, aby pominąć rozpoznawanie adresów na nazwy hostów i -P, aby pominąć rozpoznawanie portów na nazwy usług; oba sprawiają, że polecenie jest szybsze, a wynik dokładny, a nie przybliżony.

$ 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 *:5353

Przeczytaj od lewej do prawej: nazwę procesu i PID, adres lokalny i port, -> oraz adres i port zdalny oraz stan połączenia. ESTABLISHED oznacza aktywne, dwukierunkowe połączenie w tej chwili. Uruchom bez sudo, nadal będziesz widzieć swoje własne procesy; potrzebują tego te, których właścicielem jest root. Czego to nie może ci powiedzieć: lsof to migawka chwili naciśnięcia Enter. Połączenia, które się otworzyło, wysłało kilka kilobajtów i zamknęło pół sekundy przed uruchomieniem polecenia, po prostu nie ma — musisz je uruchamiać wielokrotnie lub przejść do następnego narzędzia, aby to złapać.

2. nettop — ten sam widok, ale na żywo

nettop to żywa wersja tego samego pomysłu. Strona podręcznika opisuje go jako wyświetlający „listę gniazd lub tras” z okresowo aktualizowanymi statystykami. -m route przełącza go z listy gniazd na listę widoku tablicy routingu; -m tcp lub -m udp ograniczają go do jednego protokołu.

$ 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.4K

Dodaj -l 5, aby pobrać pięć próbek i wyjść, zamiast przeprowadzać interaktywną sesję, co jest przydatne, jeśli chcesz gdzieś przesłać dane wyjściowe. nettop naprawia problem migawki lsof — możesz oglądać pojawienie się połączenia, przesyłanie danych i zamykanie — ale dziedziczy ten sam pułap: nazwę procesu i PID, nic o tym, kto podpisał plik binarny i brak pamięci po zamknięciu terminala.

3. strumień logów — co sam system mówi o sieci

macOS prowadzi ujednolicony, uporządkowany dziennik tego, co robi każdy proces, a log stream pozwala oglądać go na żywo, filtrowany. Strona podręcznika opisuje --predicate jako filtrowanie wpisów przy użyciu klauzul w stylu NSPredicate względem podsystemu, kategorii, procesu i treści komunikatu.

$ 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"

Jest to najmniej dostępne z sześciu narzędzi — jest ich dużo, a składnia predykatów wymaga uczenia się — ale jest też jedynym, które wyświetla zmiany stanu sieci na poziomie systemu i zdarzenia cyklu życia połączenia na bieżąco, prostym (w przybliżeniu) angielskim, oznaczonym przez odpowiedzialny podsystem. Traktuj to jak coś do grep, a nie czytanie wiersz po wierszu: przeprowadź go przez grep, aby uzyskać nazwę procesu, na której Ci zależy, lub słowo kluczowe, takie jak "Wi-Fi" lub "VPN".

4. scutil --dns i dig — co tak naprawdę rozwiązuje Twój Mac

Zanim nastąpi połączenie, zwykle następuje wyszukiwanie DNS. scutil --dns, zgodnie ze swoją stroną podręcznika, „raportuje bieżącą konfigurację DNS”: które programy rozpoznawania nazw są skonfigurowane, co jest ustawieniem domyślnym i które mają zastosowanie tylko do określonych domen (split DNS, powszechny w sieciach VPN).

$ 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 odpowiada bezpośrednio na jedno pytanie: do czego w tej chwili zmierza ta nazwa. Jego strona podręcznika nazywa go „elastycznym narzędziem do przesłuchiwania serwerów nazw DNS”, cenionym za „elastyczność, łatwość użycia i przejrzystość wyników”.

$ dig example.com +short
# example output
93.184.216.34

Żadne z narzędzi nie informuje, która aplikacja uruchomiła wyszukiwanie ani co wydarzyło się później — DNS podaje tylko adres, z którym aplikacja ma się połączyć (lub już się z nią połączyła). samo połączenie jest tym, co pokazuje lsof, nettop lub dziennik zapory ogniowej.

5. tcpdump — podstawowa prawda i ta, która wymaga sudo

Wszystko powyżej oznacza stan, który system operacyjny już utrzymuje. tcpdump jest inny: przechwytuje pakiety bezpośrednio z interfejsu, dlatego też jego własna dokumentacja bezpośrednio określa wymagania — „Odczyt pakietów z interfejsu sieciowego może wymagać specjalnych uprawnień” — w praktyce sudo na macOS. Użyj -i, aby wybrać interfejs, -n, aby zachować adresy numeryczne, i wyrażenia filtrującego, takiego jak port 53, aby odizolować ruch DNS:

$ 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)

Należy zauważyć wzorzec: zapytanie wysyłane na port 53, po którym natychmiast następuje odpowiedź. Jeśli uruchomisz dig w jednym terminalu, podczas gdy tcpdump uruchomi się w innym, możesz dokładnie obejrzeć zapytanie i odpowiedź wygenerowaną przez twoje własne polecenie — to dobry sposób, aby rzeczywiście wierzyć w to, co mówią strony podręcznika, zamiast brać je na wiarę.

Bezpłatne siódme narzędzie: Monitor aktywności

Warto wymienić jedną opcję graficzną na tej liście, ponieważ nie wszystko potrzebuje terminala. Karta Sieć w Monitorze aktywności wyświetla sumy — dane wysłane i odebrane na proces oraz wykres przepustowości na bieżąco — co jest właściwym pierwszym przystankiem w przypadku, gdy „coś przeżuwa przepustowość i nie wiem co”. Jest to także najjaśniejsza ilustracja pułapu, który dzieli każde narzędzie opisane w tym artykule: może powiedzieć, że proces pomocniczy przesunął się o dwa gigabajty w ciągu nocy i nie ma kolumny opisującej, dokąd poszły te dwa gigabajty. Wolumen i miejsce docelowe to dwa różne pytania, a macOS odpowiada na nie za pomocą dwóch różnych narzędzi.

Łączymy te dziesięć minut

1. sudo lsof -i -n -P — pobierz aktualną listę otwartych gniazd, jedno przejście, trzydzieści sekund.
2. nettop -m route -l 5 — pobierz kilka próbek na żywo, aby uchwycić wszystko, co przeoczyłeś w migawce lsof.
3. scutil --dns — potwierdź, jakiego resolwera faktycznie używasz, szczególnie jeśli korzystasz z VPN lub publicznej sieci Wi-Fi.
4. dig <name> +short na czymkolwiek nieznanym z kroku 1, aby zobaczyć, do czego aktualnie zmierza.
5. sudo tcpdump -i en0 -n port 53 przez sześćdziesiąt sekund, aby obserwować nieprzetworzony ruch DNS podczas wykonywania swoich zadań przez aplikacje.
6. log stream --predicate ze słowem kluczowym grep, jeśli coś powyżej wywołało pytanie, na które poprzednie pięć nie odpowiedziało.

Sprawdzony przykład

Powiedzmy, że krok 1 uruchamia proces o nazwie helperd utrzymujący otwarte połączenie z adresem, którego nie rozpoznajesz. Nie zatrzymuj się na tym. Uruchom dig -x <the address>, aby wyszukać wstecz — nie zawsze da to coś czytelnego, ale kiedy tak się stanie, nazwa hosta taka jak ads.example-cdn.net powie Ci więcej w ciągu pięciu sekund niż surowy adres IP kiedykolwiek. Uruchom nettop -m tcp -l 3 i zobacz, czy kilka sekund później to samo połączenie jest nadal otwarte i czy bajty faktycznie się po nim przemieszczają, czy też pozostaje bezczynne. Jeśli jest nieczynny i otwiera się ponownie w ustalonych odstępach czasu, ma to raczej charakter okresowego meldowania się niż jednorazowego przelewu – warto o tym pamiętać, a nie automatycznie warto się tym przejmować, bo zwykłe sprawdzacze aktualizacji zachowują się tak samo. Następnie sprawdź scutil --dns, aby potwierdzić, że przelicznik, który wygenerował adres helperd, z którym połączony był ten, którego oczekiwałeś, zwłaszcza jeśli korzystasz z cudzej sieci Wi-Fi. Pięć poleceń, jeden proces i od „Nie rozpoznaję tego” przeszedłem do „Oto konkretnie, co wiem, a czego nie wiem na ten temat” – co jest faktycznym celem takiego audytu, czymś więcej niż oceną, czy jest dobry, czy zły.

Czego żadne z tych narzędzi Ci nie powie

Przebiegnij wszystkie sześć, a nadal będziesz mieć trzy prawdziwe luki. Po pierwsze, tożsamość wykraczająca poza nazwę procesu: nic tutaj nie sprawdza, czy plik binarny o nazwie „Mail” jest programem Apple Mail, czy czymś, co samo się zmieniło, lub czy w ogóle jest podpisany — jest to osobne wyszukiwanie za pomocą codesign i spctl. Po drugie, pamięć: po zamknięciu okna terminala zamyka się wszystko, czego się nauczyłeś; nie ma dziennika „z czym połączył się mój Mac w zeszły wtorek”, chyba że sam go zbudujesz. Po trzecie, ocena: żadne z tych narzędzi nie ma opinii na temat tego, czy oczekiwane jest połączenie. Aplikacja do robienia notatek łącząca się z adresem, którego nigdy wcześniej nie używała, wygląda dokładnie tak samo w lsof, jak aplikacja łącząca się ze zwykłym serwerem synchronizacji — rozróżnienie tych dwóch to rozpoznawanie wzorców, które musisz zabrać ze sobą lub narzędzie, które musi ci przynieść.

Jaką rolę odgrywają FireAI i HisnLabs

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 to własny produkt HisnLabs: zapora sieciowa z AI działająca bezpośrednio na Macu. Pokazuje prostym językiem każde połączenie nawiązywane przez twoje aplikacje i pozwala ci decydować, co opuszcza twojego Maca — jej AI działa lokalnie, więc twój ruch nigdy nie jest wysyłany do nas ani do nikogo innego. Zespół badań nad bezpieczeństwem HisnLabs dba o to, by te decyzje pozostały trafne: kataloguje, które domeny to zwykła telemetria, a które prawdziwa usługa, śledzi kraj i sieć stojące za połączeniem oraz trenuje lokalny model (funkcję Autopilot) na rzeczywistych wzorcach ruchu — a nic z tego nie opuszcza twojego Maca.

Możesz przeczytać o decyzjach technicznych, które za tym stoją, albo wypróbować FireAI przez 17 dni na FireAI od HisnLabs.