Проверьте, что отправляет ваш Mac, за 10 минут из терминала

Чтобы получить реальную, актуальную картину того, с кем разговаривает ваш Mac, не нужно ничего устанавливать. Каждый инструмент в этой подборке уже входит в состав macOS. Ни один из них не требует доверять свой трафик третьей стороне, а все шесть вместе, если знать команды, занимают около десяти минут. Чего они не сделают — и это важно — так это не скажут вам, какие из этих соединений в порядке, а какие нет: для этого всё равно нужен контекст, и в конце статьи мы честно скажем, где эти инструменты останавливаются.

1. lsof — все открытые соединения прямо сейчас

В Unix сетевой сокет — это файл, а lsof (list open files) перечисляет открытые файлы. Man-страница macOS описывает флаг -i как выбор файлов, чей интернет-адрес соответствует заданной спецификации — если ничего не задано, выводятся все интернет-сокеты. Добавьте -n, чтобы не преобразовывать адреса в имена хостов, и -P, чтобы не преобразовывать порты в имена служб; оба флага делают команду быстрее, а вывод — точным, а не приблизительным.

$ 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

Читайте слева направо: имя процесса и PID, локальный адрес и порт, -> и удалённый адрес и порт, и состояние соединения. ESTABLISHED означает активное, двустороннее соединение прямо сейчас. Без sudo вы всё равно увидите свои собственные процессы; для процессов, принадлежащих root, sudo нужен. Чего эта команда не покажет: lsof — это снимок того момента, когда вы нажали Enter. Соединение, которое открылось, передало несколько килобайт и закрылось за полсекунды до того, как вы запустили команду, просто не попадёт в список — чтобы это поймать, нужно запускать команду повторно или перейти к следующему инструменту.

2. nettop — тот же обзор, но в реальном времени

nettop — это та же идея, но в реальном времени. Его man-страница описывает его как отображение «списка сокетов или маршрутов» с периодически обновляемой статистикой. -m route переключает вывод со списка сокетов на представление таблицы маршрутизации; -m tcp или -m udp ограничивают вывод одним протоколом.

$ 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

Добавьте -l 5, чтобы снять пять замеров и завершить работу вместо интерактивной сессии, — удобно, если вы хотите перенаправить вывод куда-то ещё. nettop решает проблему «снимка» у lsof: можно увидеть, как соединение появляется, передаёт данные и закрывается, — но у него тот же потолок: имя процесса и PID, ничего о том, кем подписан бинарный файл, и никакой памяти после закрытия терминала.

3. log stream — что сама система говорит о сети

macOS ведёт единый структурированный журнал того, чем занимается каждый процесс, и log stream позволяет наблюдать за ним в реальном времени, с фильтрацией. Man-страница описывает --predicate как фильтрацию записей с помощью условий в стиле NSPredicate по подсистеме, категории, процессу и содержимому сообщения.

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

Это самый труднодоступный из шести инструментов — объём вывода огромен, а синтаксис predicate требует привыкания, — но это также единственный инструмент, который показывает изменения сетевого состояния на уровне системы и события жизненного цикла соединений в момент их появления, на (почти) понятном языке, с указанием ответственной подсистемы. Относитесь к нему как к тому, что нужно фильтровать через grep, а не читать построчно: пропустите вывод через grep по имени интересующего вас процесса или по ключевому слову вроде "Wi-Fi" или "VPN".

4. scutil --dns и dig — что на самом деле разрешает ваш Mac

Перед тем как произойдёт соединение, обычно выполняется DNS-запрос. scutil --dns, согласно его man-странице, «сообщает текущую конфигурацию DNS»: какие резолверы настроены, какой из них используется по умолчанию, а какие применяются только к определённым доменам (раздельный DNS, обычное явление на 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 напрямую отвечает на один вопрос: во что прямо сейчас разрешается это имя. Его man-страница называет его «гибким инструментом для опроса DNS-серверов имён», ценимым за «гибкость, простоту использования и ясность вывода».

$ dig example.com +short
# example output
93.184.216.34

Ни один из этих инструментов не скажет, какое приложение вызвало запрос или что произошло дальше, — DNS даёт лишь адрес, к которому приложение собирается (или уже успело) подключиться; само соединение показывают lsof, nettop или журнал файрвола.

5. tcpdump — истина в последней инстанции, и единственный инструмент, которому нужен sudo

Всё описанное выше читает состояние, которое операционная система уже хранит. tcpdump устроен иначе: он перехватывает пакеты прямо на интерфейсе, поэтому его собственная документация прямо говорит о требовании — «для чтения пакетов с сетевого интерфейса может потребоваться наличие особых привилегий» — на практике, в macOS это sudo. Используйте -i, чтобы выбрать интерфейс, -n, чтобы адреса оставались в числовом виде, и выражение-фильтр вроде port 53, чтобы выделить 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)

Обратите внимание на закономерность: запрос уходит на порт 53, и сразу же приходит ответ. Если запустить dig в одном терминале, пока в другом работает tcpdump, можно увидеть точный запрос и ответ, порождённые вашей же командой, — хороший способ действительно убедиться в том, что говорят man-страницы, а не просто принять это на веру.

Бесплатный седьмой инструмент: Мониторинг системы

Стоит назвать и единственный графический вариант в этом списке, ведь не всё требует терминала. Вкладка «Сеть» в Мониторинге системы показывает итоговые цифры — объём данных, отправленных и полученных каждым процессом, и график пропускной способности в реальном времени, — что отлично подходит для случая «что-то жуёт канал, и я не знаю что». Это также самая наглядная иллюстрация потолка, общего для всех инструментов этой статьи: он скажет вам, что вспомогательный процесс за ночь передал два гигабайта, но у него нет столбца, куда эти два гигабайта ушли. Объём и адресат — два разных вопроса, и macOS отвечает на них двумя разными инструментами.

Собираем десять минут воедино

1. sudo lsof -i -n -P — получить текущий список открытых сокетов, один проход, тридцать секунд.
2. nettop -m route -l 5 — снять несколько живых замеров, чтобы поймать то, что упустил снимок lsof.
3. scutil --dns — убедиться, каким резолвером вы пользуетесь на самом деле, особенно если вы на VPN или в публичной Wi-Fi-сети.
4. dig <имя> +short — для всего незнакомого из шага 1, чтобы увидеть, во что оно сейчас разрешается.
5. sudo tcpdump -i en0 -n port 53, в течение шестидесяти секунд, чтобы увидеть «сырой» DNS-трафик, пока приложения занимаются своими делами.
6. log stream --predicate с фильтрацией по ключевому слову — если что-то из предыдущих шагов подняло вопрос, на который первые пять не ответили.

Разбор на примере

Допустим, шаг 1 выявил процесс с именем helperd, у которого открыто соединение с незнакомым вам адресом. Не останавливайтесь на этом. Запустите dig -x <адрес> для обратного разрешения — оно не всегда даёт что-то читаемое, но когда даёт, имя хоста вроде ads.example-cdn.net скажет вам за пять секунд больше, чем голый IP-адрес когда-либо скажет. Запустите nettop -m tcp -l 3 и посмотрите, остаётся ли то же соединение открытым спустя несколько секунд и действительно ли по нему идут байты или оно простаивает. Если оно простаивает и открывается заново через фиксированный интервал — это форма периодической проверки связи, а не разовой передачи данных: стоит это запомнить, но не обязательно сразу тревожиться, поскольку обычные проверки обновлений ведут себя точно так же. Затем проверьте scutil --dns, чтобы убедиться, что резолвер, выдавший адрес, к которому подключился helperd, был именно тем, которого вы ожидали, — особенно если вы в чужой Wi-Fi-сети. Пять команд, один процесс — и вы прошли путь от «я это не узнаю» до «вот что конкретно я знаю и чего не знаю об этом», а это и есть настоящая цель такого аудита, важнее, чем вердикт «хорошо» или «плохо».

Чего не скажет ни один из этих инструментов

Пройдите все шесть шагов — и всё равно останутся три реальных пробела. Во-первых, идентификация за пределами имени процесса: ничто здесь не проверяет, действительно ли бинарный файл с именем «Mail» — это Apple Mail, или же что-то переименовавшее себя, и подписан ли он вообще, — это отдельная проверка с помощью codesign и spctl. Во-вторых, память: как только окно терминала закрывается, вместе с ним исчезает всё, что вы узнали; журнала «к чему подключался мой Mac в прошлый вторник» не существует, если вы не создадите его сами. В-третьих, суждение: ни один из этих инструментов не имеет мнения о том, ожидаемо ли соединение. Приложение для заметок, подключающееся к адресу, к которому оно никогда раньше не обращалось, в lsof выглядит точно так же, как подключение к его обычному серверу синхронизации, — отличить одно от другого приходится либо вам самим, распознавая закономерности, либо инструменту, который должен делать это за вас.

Какое место здесь занимают FireAI и 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 — это собственный продукт HisnLabs: ИИ-файрвол, работающий прямо на вашем Mac. Он показывает простым языком каждое соединение, которое устанавливают ваши приложения, и позволяет вам решать, что покидает ваш Mac, — его ИИ работает локально, поэтому ваш трафик никогда не отправляется ни нам, ни кому-либо ещё. Команда исследователей безопасности HisnLabs — это те, кто поддерживает точность этих решений: они каталогизируют, какие домены являются обычной телеметрией, а какие — реальным сервисом, отслеживают страну и сеть, стоящие за соединением, и обучают локальную модель (функцию Autopilot) на реальных шаблонах трафика — и ничего из этого не покидает ваш Mac.

Вы можете прочитать о технических решениях, лежащих в его основе, или попробовать FireAI в течение 17 дней на странице FireAI от HisnLabs.