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

> Dziesięciominutowy, zawierający tylko narzędzia system macOS z audytem: lsof, nettop, log stream, scutil --dns, dig i tcpdump — co właściwie każdy z nich pokazuje, dokładne polecenia i czego żadne z nich nie może ci powiedzieć.

HisnLabs Security & Research Team · Published 2026-09-14
Canonical: https://hisnlabs.com/pl/blog/audit-mac-network-terminal

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.

*Terminal — każde otwarte gniazdo sieciowe*

```console
$ 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.

*Terminal — połączenia na żywo, odświeżane co sekundę*

```console
$ 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.

*Terminal — przesyłanie strumieniowe wpisów dziennika związanych z siecią*

```console
$ 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).

*Terminal — bieżąca konfiguracja programu rozpoznawania nazw DNS*

```console
$ 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”.

*Terminal — rozpoznawanie pojedynczej nazwy hosta*

```console
$ 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:

*Terminal — oglądanie zapytań DNS opuszczających maszynę*

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

> **Warning:** Wymaga to wyższych uprawnień, ponieważ odczytuje pakiety bezpośrednio z interfejsu sieciowego — ten sam poziom dostępu, który w zasadzie mógłby przechwycić znacznie więcej niż DNS, jeśli rozszerzysz filtr lub całkowicie go porzucisz. Utrzymuj wąski filtr, uruchamiaj go przez krótkie okno i zamknij terminal, gdy skończysz. Nie pozostawiaj szerokiego, niefiltrowanego przechwytywania bez nadzoru.

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ę FireAI Pilot) 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](https://hisnlabs.com/fireai/pl/download).

## Sources

- [SS64: lsof man page for macOS](https://ss64.com/mac/lsof.html)
- [nettop(1) man page (Xcode man pages mirror)](https://keith.github.io/xcode-man-pages/nettop.1.html)
- [log(1) man page (Xcode man pages mirror)](https://keith.github.io/xcode-man-pages/log.1.html)
- [scutil(8) man page (Xcode man pages mirror)](https://keith.github.io/xcode-man-pages/scutil.8.html)
- [dig(1) man page (Xcode man pages mirror)](https://keith.github.io/xcode-man-pages/dig.1.html)
- [SS64: tcpdump man page for macOS](https://ss64.com/mac/tcpdump.html)