Não precisa de instalar nada para obter uma imagem real e atual daquilo com que o seu Mac está a falar. Todas as ferramentas deste laboratório vêm com o macOS. Nenhuma delas exige que confie a sua rede a terceiros, e as seis juntas demoram cerca de dez minutos a percorrer assim que se conhecem os comandos. O que não farão, e isto importa, é dizer-lhe quais dessas ligações estão bem e quais não estão — para isso continua a precisar de contexto, e no final seremos honestos sobre onde estas ferramentas param.
1. lsof — todas as ligações abertas, agora mesmo
Em Unix, um socket de rede é um ficheiro, e o lsof (list open files) lista-os. A página de manual do macOS descreve -i como a seleção dos ficheiros cujo endereço de internet corresponde a uma especificação dada — sem nenhuma indicada, todos os sockets de internet. Junte -n para saltar a resolução de endereços em nomes de anfitrião e -P para saltar a resolução de portas em nomes de serviço; ambos tornam 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, endereço e porta locais, -> e o endereço e porta remotos, e o estado da ligação. ESTABLISHED significa uma ligação ativa e bidirecional neste momento. Executado sem sudo ainda verá os seus próprios processos; os pertencentes à raiz precisam dele. O que isto não lhe pode dizer: o lsof é uma fotografia do instante em que carregou em Enter. Uma ligação que abriu, enviou alguns quilobytes e fechou meio segundo antes de executar o comando simplesmente não aparece ali — tem de o executar repetidamente, ou passar à ferramenta seguinte, para apanhar isso.
2. nettop — a mesma visão, mas ao vivo
O nettop é a versão ao vivo da mesma ideia. A sua página de manual descreve-o como algo que mostra "uma lista de sockets ou rotas" com estatísticas atualizadas periodicamente. -m route muda-o de listar sockets para listar a vista da tabela de encaminhamento; -m tcp ou -m udp restringem-no 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.4KJunte -l 5 para capturar cinco amostras e sair, em vez de manter uma sessão interativa — útil se quiser encaminhar a saída para outro sítio. O nettop resolve o problema da fotografia instantânea do lsof — pode observar uma ligação a aparecer, a transferir dados e a 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 de fechar o terminal.
3. log stream — o que o próprio sistema diz sobre a rede
O macOS mantém um registo unificado e estruturado do que cada processo está a fazer, e o log stream deixa-o observar isso ao vivo, filtrado. A página de manual descreve --predicate como a filtragem de entradas usando cláusulas ao 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"Esta é a menos acessível das seis ferramentas — o volume é elevado e a sintaxe dos predicados tem uma curva de aprendizagem — mas é também a única que revela alterações de estado de rede ao nível do sistema e eventos do ciclo de vida das ligações à medida que acontecem, em inglês (mais ou menos) simples, identificados pelo subsistema responsável. Trate-a como algo a filtrar com grep, não a ler linha a linha: encaminhe-a através de grep para 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 facto a resolver
Antes de uma ligação acontecer, há normalmente uma consulta DNS. O scutil --dns, segundo a sua página de manual, "reporta a configuração DNS atual": quais os resolvedores configurados, qual é o predefinido, 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 resolve este nome, agora mesmo. A sua página de manual chama-lhe "uma ferramenta flexível para interrogar servidores de nomes DNS", valorizada pela "flexibilidade, facilidade de uso e clareza da saída".
dig example.com +short
# example output
93.184.216.34Nenhuma das ferramentas lhe diz qual aplicação desencadeou a consulta nem o que aconteceu depois — o DNS só lhe dá o endereço a que uma aplicação está prestes a ligar (ou já ligou); a ligação em si é o que o lsof, o nettop ou um registo de firewall lhe mostram.
5. tcpdump — a verdade no terreno, e a que precisa de sudo
Tudo o que foi visto acima lê estado que o sistema operativo já mantém. O tcpdump é diferente: captura pacotes diretamente de uma interface, razão pela qual a sua própria documentação é direta quanto ao 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 a sair na porta 53 seguida imediatamente de uma resposta a chegar. Se executar dig num terminal enquanto o tcpdump corre noutro, pode observar a consulta e a resposta exatas que o seu próprio comando produziu — uma boa forma de realmente acreditar no que as páginas de manual dizem, em vez de as aceitar de olhos fechados.
Uma sétima ferramenta gratuita: o Monitor de Atividade
Vale a pena nomear a única opção gráfica desta lista, já que nem tudo precisa de um terminal. O separador Rede do Monitor de Atividade dá-lhe totais — dados enviados e recebidos por processo, e um gráfico de débito ao vivo — o que é o primeiro sítio certo para "algo está a consumir muita largura de banda e não sei o quê." É também a ilustração mais clara do limite que todas as ferramentas deste artigo partilham: pode dizer-lhe que um processo auxiliar moveu dois gigabytes durante a noite, e não tem nenhuma coluna para onde esses dois gigabytes foram. Volume e destino são duas perguntas diferentes, e o macOS responde-lhes com duas ferramentas diferentes.
Juntando os dez minutos
sudo lsof -i -n -P— obtenha a lista atual de sockets abertos, uma passagem, trinta segundos.nettop -m route -l 5— capture algumas amostras ao vivo para apanhar o que a fotografia do lsof possa ter deixado escapar.scutil --dns— confirme qual o resolvedor que está de facto a usar, especialmente se estiver numa VPN ou num Wi-Fi público.dig <nome> +short, em qualquer coisa desconhecida do passo 1, para ver para onde resolve atualmente.sudo tcpdump -i en0 -n port 53, durante sessenta segundos, para observar o tráfego DNS em bruto enquanto as aplicações seguem com a sua vida.log stream --predicatecom um grep de palavra-chave, se algo acima tiver levantado uma questão que os cinco passos anteriores não responderam.
Um exemplo trabalhado
Digamos que o passo 1 revela um processo chamado helperd a manter uma ligação aberta a um endereço que não reconhece. Não fique por aí. Execute dig -x <o endereço> para uma pesquisa inversa — nem sempre resolverá em algo legível, mas quando resolve, um nome de anfitrião como ads.example-cdn.net diz-lhe mais em cinco segundos do que o IP em bruto alguma vez dirá. Execute nettop -m tcp -l 3 e observe se essa mesma ligação continua aberta uns segundos depois, e se há de facto bytes a mover-se por ela ou se está parada. Se estiver parada e reabrir a intervalos fixos, isso tem a forma de uma verificação periódica em vez de uma transferência única — vale a pena lembrar, não vale automaticamente uma preocupação, já que os verificadores de atualizações normais se comportam da mesma forma. Depois verifique o scutil --dns para confirmar que o resolvedor que produziu o endereço a que o helperd se ligou era o que esperava, especialmente se estiver na rede Wi-Fi de outra pessoa. Cinco comandos, um processo, e passou de "não reconheço isto" para "eis exatamente o que sei e não sei sobre isto" — que é o verdadeiro objetivo de uma auditoria como esta, mais do que um veredicto de bom ou mau.
O que nenhuma destas ferramentas lhe dirá
Percorra as seis e continua com três lacunas reais. Primeiro, identidade para além de um nome de processo: nada aqui verifica se o binário chamado "Mail" é o Mail da Apple ou algo que se renomeou, nem se está sequer assinado — essa é uma verificação separada com codesign e spctl. Segundo, memória: assim que a janela do terminal fecha, também fecha tudo o que aprendeu; não há um registo de "a que se ligou o meu Mac na terça-feira passada" a menos que o construa você mesmo. Terceiro, juízo: nenhuma destas ferramentas tem opinião sobre se uma ligação é esperada. Uma aplicação de notas a ligar-se a um endereço a que nunca ligou antes parece exatamente igual, no lsof, a uma a ligar-se ao seu servidor de sincronização habitual — distinguir as duas é um reconhecimento de padrões que tem de trazer você mesmo, ou que uma ferramenta tem de trazer por si.
O papel do FireAI e da 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.
O FireAI é o produto da HisnLabs: uma firewall com IA que corre diretamente no seu Mac. Mostra, em linguagem clara, cada ligação que as suas aplicações fazem e deixa-o decidir o que sai do seu Mac — a IA funciona localmente, pelo que o seu tráfego nunca é enviado para nós nem para mais ninguém. A equipa de investigação em segurança da HisnLabs é quem mantém essas decisões fiáveis: cataloga que domínios são simples telemetria e quais são um serviço real, acompanha o país e a rede por detrás de uma ligação e treina o modelo local (a funcionalidade Autopilot) com padrões de tráfego reais, sem que nada disso saia do seu Mac.
Pode ler as decisões técnicas por detrás dele, ou experimentar o FireAI durante 17 dias, em FireAI, da HisnLabs.