Você não precisa instalar nada para ter uma visão real e atual do que o seu Mac está conversando. Toda ferramenta deste laboratório já vem com o macOS. Nenhuma delas exige que você confie o seu tráfego a terceiros, e as seis juntas levam cerca de dez minutos para rodar, uma vez que você conheça os comandos. O que elas não vão fazer, e isso importa, é dizer quais dessas conexões são normais e quais não são — para isso você ainda precisa de contexto, e no final vamos ser honestos sobre onde essas ferramentas param.
1. lsof — cada conexão aberta, agora
No Unix, um socket de rede é um arquivo, e o lsof (list open files) lista esses arquivos. A página de manual do macOS descreve -i como a seleção de arquivos cujo endereço de internet corresponde a uma especificação dada — sem nenhuma especificação, todos os sockets de internet. Acrescente -n para pular a resolução de endereços em nomes de host e -P para pular a resolução de portas em nomes de serviço; os dois deixam o comando mais rápido e a saída exata em vez de aproximada.
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 *:5353Leia da esquerda para a direita: nome do processo e PID, o endereço e a porta locais, -> e o endereço e a porta remotos, e o estado da conexão. ESTABLISHED significa uma conexão ativa e bidirecional agora mesmo. Rodado sem sudo, você ainda verá seus próprios processos; os que pertencem ao root exigem o comando com privilégio. O que isso não consegue mostrar: o lsof é um retrato do instante em que você apertou Enter. Uma conexão que abriu, enviou alguns quilobytes e fechou meio segundo antes de você rodar o comando simplesmente não vai aparecer — é preciso rodar várias vezes, ou passar para a próxima ferramenta, para capturar isso.
2. nettop — a mesma visão, mas ao vivo
O nettop é a versão ao vivo da mesma ideia. Sua página de manual o descreve como exibindo "uma lista de sockets ou rotas" com estatísticas atualizadas periodicamente. -m route muda o modo de listagem de sockets para a visão da tabela de roteamento; -m tcp ou -m udp restringem a exibição a um único protocolo.
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.4KAcrescente -l 5 para capturar cinco amostras e encerrar em vez de manter uma sessão interativa, útil se você quiser encaminhar a saída para outro lugar. O nettop resolve o problema do retrato instantâneo do lsof — você consegue ver uma conexão aparecer, transferir dados e fechar —, mas herda o mesmo limite: um nome de processo e um PID, nada sobre quem assinou o binário, e nenhuma memória depois que você fecha o terminal.
3. log stream — o que o próprio sistema está dizendo sobre a rede
O macOS mantém um registro unificado e estruturado do que cada processo está fazendo, e o log stream deixa você acompanhá-lo ao vivo, com filtros. A página de manual descreve --predicate como um filtro de entradas usando cláusulas no estilo NSPredicate contra subsistema, categoria, processo e conteúdo da mensagem.
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"Essa é a menos acessível das seis ferramentas — o volume é alto e a sintaxe do predicado tem uma curva de aprendizado —, mas também é a única que expõe mudanças de estado de rede em nível de sistema e eventos do ciclo de vida das conexões conforme acontecem, em um inglês relativamente claro, marcado pelo subsistema responsável. Trate-a como algo para filtrar com grep, não para ler linha por linha: encaminhe a saída para o grep procurando um nome de processo que lhe interesse, ou uma palavra-chave como "Wi-Fi" ou "VPN".
4. scutil --dns e dig — o que o seu Mac está de fato resolvendo
Antes de uma conexão acontecer, geralmente há uma consulta DNS. O scutil --dns, segundo sua página de manual, "relata a configuração atual de DNS": quais resolvedores estão configurados, qual é o padrão e quais se aplicam apenas a domínios específicos (DNS dividido, comum em 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)O dig responde diretamente a uma única pergunta: para onde esse nome resolve, agora. Sua página de manual o chama de "uma ferramenta flexível para interrogar servidores de nomes DNS", valorizada por "flexibilidade, facilidade de uso e clareza da saída".
dig example.com +short
# example output
93.184.216.34Nenhuma das duas ferramentas diz qual aplicativo disparou a consulta ou o que aconteceu depois — o DNS só entrega o endereço para o qual um aplicativo está prestes a se conectar (ou já se conectou); a conexão em si é o que o lsof, o nettop ou um log de firewall mostram.
5. tcpdump — a verdade no nível dos pacotes, e a única que exige sudo
Tudo acima lê estados que o sistema operacional já mantém. O tcpdump é diferente: ele captura pacotes diretamente de uma interface, e é por isso que a própria documentação é direta sobre o requisito — "Ler pacotes de uma interface de rede pode exigir privilégios especiais" — na prática, sudo no macOS. Use -i para escolher a interface, -n para manter os endereços numéricos, e uma expressão de filtro como port 53 para isolar o tráfego 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)O padrão a observar: uma consulta saindo pela porta 53 imediatamente seguida por uma resposta voltando. Se você rodar o dig em um terminal enquanto o tcpdump roda em outro, poderá ver a consulta e a resposta exatas que o seu próprio comando gerou — uma boa forma de realmente confirmar o que as páginas de manual dizem, em vez de simplesmente confiar nelas.
Uma sétima ferramenta gratuita: o Monitor de Atividade
Vale citar a única opção gráfica desta lista, já que nem tudo precisa de terminal. A aba Rede do Monitor de Atividade mostra totais — dados enviados e recebidos por processo, e um gráfico de taxa de transferência ao vivo —, o que é o primeiro lugar certo para "alguma coisa está consumindo muita banda e eu não sei o quê". É também a ilustração mais clara do limite que toda ferramenta deste artigo compartilha: ele pode dizer que um processo auxiliar moveu dois gigabytes durante a noite, mas não tem coluna nenhuma para para onde esses dois gigabytes foram. Volume e destino são duas perguntas diferentes, e o macOS as responde com duas ferramentas diferentes.
Juntando os dez minutos
sudo lsof -i -n -P— obtenha a lista atual de sockets abertos, uma passada, trinta segundos.nettop -m route -l 5— capture algumas amostras ao vivo para pegar qualquer coisa que o retrato instantâneo do lsof tenha perdido.scutil --dns— confirme qual resolvedor você está de fato usando, especialmente se estiver em uma VPN ou em Wi-Fi público.dig <nome> +short, em qualquer coisa desconhecida do passo 1, para ver para onde ela resolve atualmente.sudo tcpdump -i en0 -n port 53, por sessenta segundos, para observar o tráfego DNS em estado bruto enquanto os aplicativos seguem com suas atividades.log stream --predicatecom uma palavra-chave filtrada por grep, se algo acima levantou uma dúvida que os cinco passos anteriores não responderam.
Um exemplo prático
Digamos que o passo 1 mostre um processo chamado helperd mantendo uma conexão aberta com um endereço que você não reconhece. Não pare por aí. Rode dig -x <o endereço> para uma consulta reversa — nem sempre ela vai resolver para algo legível, mas quando resolve, um nome de host como ads.example-cdn.net diz mais em cinco segundos do que o IP bruto jamais diria. Rode nettop -m tcp -l 3 e observe se essa mesma conexão continua aberta alguns segundos depois, e se bytes estão de fato se movendo por ela ou se ela está ociosa. Se estiver ociosa e reabrir em um intervalo fixo, esse é o formato típico de uma verificação periódica, não de uma transferência única — vale lembrar disso, mas não é motivo automático de preocupação, já que verificadores de atualização comuns se comportam da mesma forma. Depois, confira o scutil --dns para confirmar que o resolvedor que produziu o endereço ao qual o helperd se conectou era o que você esperava, especialmente se estiver no Wi-Fi de outra pessoa. Cinco comandos, um processo, e você foi de "não reconheço isso" a "aqui está exatamente o que eu sei e não sei sobre isso" — que é o real objetivo de uma auditoria como essa, mais do que um veredito de bom ou ruim.
O que nenhuma dessas ferramentas vai lhe dizer
Rode as seis e você ainda terá três lacunas reais. Primeiro, identidade além do nome do processo: nada aqui verifica se o binário chamado "Mail" é o Mail da Apple ou algo que se renomeou, nem se ele está sequer assinado — isso é uma consulta separada com codesign e spctl. Segundo, memória: assim que a janela do terminal fecha, tudo o que você descobriu desaparece junto; não existe um registro de "com o que meu Mac se conectou na terça-feira passada" a menos que você mesmo construa um. Terceiro, julgamento: nenhuma dessas ferramentas tem opinião sobre se uma conexão é esperada. Um aplicativo de anotações se conectando a um endereço que nunca usou antes aparece exatamente igual, no lsof, a um se conectando ao seu servidor de sincronização de sempre — distinguir os dois é um reconhecimento de padrão que você precisa trazer, ou que uma ferramenta precisa trazer por você.
Onde FireAI e HisnLabs entram nessa história
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.
O FireAI é o produto da HisnLabs: um firewall com IA que roda direto no seu Mac. Ele mostra, em linguagem simples, cada conexão que seus aplicativos fazem e deixa você decidir o que sai do seu Mac — a IA roda localmente, então seu tráfego nunca é enviado para nós nem para ninguém. A equipe de pesquisa em segurança da HisnLabs é quem mantém essas decisões confiáveis: cataloga quais domínios são telemetria comum e quais são um serviço de verdade, rastreia o país e a rede por trás de uma conexão e treina o modelo local (o recurso Autopilot) com padrões reais de tráfego, sem que nada disso saia do seu Mac.
Você pode ler as decisões técnicas por trás dele, ou testar o FireAI por 17 dias, em FireAI, da HisnLabs.