Seu Mac está conversando agora mesmo. Não é metáfora: neste instante, várias dezenas de processos mantêm sockets abertos para servidores dos quais você nunca ouviu falar, e a maior parte disso é normal. Verificações de atualização, sincronização, notificações push, telemetria, uma fonte sendo baixada. O objetivo do monitoramento de rede não é entrar em pânico com o volume, mas conseguir responder a uma única pergunta sobre qualquer linha individual: qual aplicativo, para quem, e por quê. O macOS oferece três ferramentas gratuitas que cobrem parte do caminho. Este artigo explica o que cada uma mostra, onde ela para, e o que um firewall por aplicativo acrescenta por cima.
Monitor de Atividade: totais, não destinos
Abra o Monitor de Atividade, clique na aba Rede e você tem a visão geral honesta para a qual a Apple o projetou. O guia da Apple descreve o painel inferior: pacotes recebidos e enviados, dados recebidos e enviados em megabytes, e um gráfico que você pode alternar entre vazão de pacotes e de dados. A lista de processos acima informa quanto cada processo enviou e recebeu. O que ela não informa é para onde. Não há coluna para o host remoto, nem porta, nem país. O Monitor de Atividade responde a “algo está usando muita banda?” e para por aí. É a ferramenta certa para perceber que um processo auxiliar enviou dois gigabytes durante a noite, e a ferramenta errada para descobrir para quem.
lsof: um retrato de cada socket aberto
A ferramenta de linha de comando lsof lista arquivos abertos, e no Unix um socket de rede é um arquivo. Com a opção -i, que a página man do macOS descreve como a seleção dos arquivos cujo endereço de internet corresponde, você obtém todas as conexões abertas com o nome do processo dono, seu ID de processo, o protocolo, e o endereço e a porta locais e remotos. Adicione -n e -P para manter endereços e portas em formato numérico em vez de esperar pelo DNS reverso. O resultado é o quadro gratuito mais completo que você pode ter do momento presente, e a ênfase está em momento: o lsof é um retrato. Uma conexão que abriu, enviou um kilobyte e fechou no meio segundo antes de você apertar Enter simplesmente não está lá. Ele também identifica o processo pelo nome e pelo PID, não por quem o assinou, então um binário chamado “Adobe Update Helper” numa pasta temporária parece exatamente igual ao verdadeiro.
nettop: a mesma visão, atualizada ao vivo
O nettop é o que há de mais próximo de um monitor de conexões ao vivo que o macOS traz de fábrica. Sua página man o descreve como uma ferramenta que exibe uma lista de sockets ou rotas com estatísticas de rede atualizadas periodicamente. Na prática, você vê cada processo, suas conexões abertas, bytes recebidos e enviados por conexão, a interface em uso e o estado da conexão, com atualização a cada segundo. Ele resolve o problema do retrato do lsof e continua sendo a melhor resposta nativa para “o que aquele aplicativo está fazendo agora”. Seus limites são os mesmos do lsof em todos os outros aspectos: nenhuma identidade além do nome do processo, nenhuma noção de país ou organização por trás de um endereço, nenhuma memória do que aconteceu uma hora atrás, e nenhuma forma de dizer não. Com o nettop você pode observar uma conexão; não pode interrompê-la.
O firewall embutido não ajuda aqui
Muita gente supõe que ativar o firewall nos Ajustes do Sistema resolve isso. Não resolve. O guia da própria Apple é cuidadoso com as palavras: o firewall do macOS protege seu Mac de contatos indesejados iniciados por outros computadores. É um filtro de entrada. Ele não tem nada a dizer sobre o que seus aplicativos enviam para fora, que é a direção para onde aponta cada pergunta deste artigo. Para o controle de saída, por aplicativo, a Apple oferece o framework Network Extension, cujos content filter providers permitem que um aplicativo de terceiros veja e filtre fluxos de rede com a identidade do aplicativo que os gerou. Essa é a base sobre a qual os firewalls por aplicativo modernos no macOS são construídos, e é o que transforma uma lista de sockets em uma lista de decisões.
O que um firewall por aplicativo acrescenta
Quatro coisas, concretamente. Identidade: um fluxo é atribuído a um aplicativo assinado, então uma regra para o Slack se aplica ao Slack e não a qualquer coisa que por acaso compartilhe o nome; as regras por aplicativo do FireAI seguem a assinatura de código do aplicativo por esse motivo. Visibilidade: cada conexão é mostrada no momento em que acontece, inclusive as que duram meio segundo. Contexto: o endereço IP bruto é resolvido para a organização e o país por trás dele, que o FireAI mostra em um mapa-múndi ao vivo com as conexões bloqueadas em vermelho. E controle: uma conexão pode ser permitida ou negada por host, domínio, IP ou porta, e um aplicativo desconhecido precisa pedir antes da primeira conexão, com o motivo do veredito do modelo local exibido no aviso. Se você discordar de uma decisão tomada pela IA, é só desfazê-la, e o desfazer vira uma regra visível que você pode ler depois ou exportar como arquivo de texto.
O FireAI também aceita ordens em linguagem natural, em inglês ou francês, como “block Microsoft Teams”, o que é um jeito mais rápido de escrever uma regra do que uma caixa de diálogo com quatro campos. O que ele não faz merece ser dito com a mesma clareza: ele não inspeciona o conteúdo do tráfego criptografado, não escaneia arquivos e não examina processos ou memória. Ele trabalha no nível de quem se conecta a quê, e é honesto sobre essa fronteira.
Como ler uma conexão
Pegue qualquer linha do nettop ou do log de um firewall e faça três perguntas. Primeiro, a empresa: quem é o dono do endereço? A maior parte do tráfego vai para um punhado de provedores de hospedagem e redes de distribuição de conteúdo, e um aplicativo de música conversando com a Amazon ou a Cloudflare normalmente está apenas conversando com o próprio backend. O padrão a observar é a incoerência: um aplicativo de anotações se conectando a uma rede de publicidade, ou um utilitário de captura de tela se conectando a um provedor de hospedagem que não tem motivo para usar. Segundo, o país: não porque um servidor estrangeiro seja ruim, mas porque uma mudança é informativa. Um aplicativo que se conectou à Irlanda por um ano e hoje se conecta pela primeira vez a um novo país mudou alguma coisa. Terceiro, a porta. A 443 é HTTPS e cobre quase tudo; a 80 é HTTP sem criptografia e deveria ser rara em 2026; a 53 é DNS; a 22 é SSH; a 445 é compartilhamento de arquivos SMB; a 5353 é Bonjour na rede local. Um aplicativo de consumo abrindo a porta 22 ou 445 para um endereço na internet é incomum o bastante para justificar uma pergunta.
Padrões que merecem uma segunda olhada
- Beaconing: o mesmo processo contatando o mesmo endereço em intervalos fixos, a cada sessenta segundos ou a cada dez minutos, com cargas minúsculas. O MITRE ATT&CK descreve comando e controle como a tentativa do adversário de se comunicar com sistemas comprometidos para controlá-los, e um batimento regular é a forma mais comum que isso assume. Verificações de atualização também fazem beaconing, então a pista é um processo desconhecido, não o ritmo sozinho.
- Nós de saída Tor: o Tor Project publica sua lista de nós de saída, e não há motivo comum para um aplicativo de produtividade alcançar um deles. O FireAI aplica essa lista localmente como um de seus feeds de threat intelligence.
- HTTP sem criptografia carregando credenciais: um formulário de login, uma chave de API ou um número de cartão enviados pela porta 80 podem ser lidos por qualquer pessoa no caminho. A proteção de dados não criptografados do FireAI foi construída exatamente para esse caso e impede que números de cartão, senhas e chaves de API saiam por HTTP sem criptografia.
- Uma primeira conexão de um aplicativo instalado há muito tempo: um aplicativo que ficou em silêncio por meses e de repente abre um socket foi atualizado, substituído ou sequestrado por um plugin. Vale a pena saber qualquer um dos três.
- Binários não assinados ou desconhecidos acessando a internet, ponto: em um Mac onde tudo o que você usa é assinado, um binário não assinado fazendo sua primeira conexão é o alerta mais útil que um firewall pode emitir. Os modos de segurança mais rígidos do FireAI, Paranoid e Under attack, bloqueiam aplicativos não assinados de imediato.
- Endereços em listas de bloqueio publicadas: a Spamhaus descreve sua lista DROP como faixas tão perigosas que a disponibiliza gratuitamente para quem quiser essa camada de proteção; a FireHOL agrega e documenta feeds públicos de IP focados em ataques e abusos; a abuse.ch mantém plataformas de threat intelligence movidas pela comunidade. O FireAI aplica esses feeds localmente, como listas de bloqueio de IP em todo o sistema, sem enviar seu tráfego para lugar nenhum.
Filtragem de DNS, com honestidade
O DNS é onde vivem muitos produtos de filtragem de rede, então é justo perguntar onde o FireAI se posiciona. Hoje, o FireAI filtra a própria conexão: aplica feeds de threat intelligence e listas de bloqueio de IP aos endereços que seus aplicativos realmente alcançam, e as regras por aplicativo podem corresponder a um nome de host ou de domínio. O que ele ainda não faz é atuar como seu resolvedor de DNS ou oferecer DNS criptografado próprio; isso está planejado, e preferimos dizer isso a deixar implícito. Há uma consequência prática a entender. O DNS criptografado, especificado como DNS over TLS na RFC 7858 e DNS over HTTPS na RFC 8484, e com suporte em todo o sistema no macOS desde a sessão da WWDC 2020 da Apple sobre a ativação do DNS criptografado, esconde suas consultas de qualquer pessoa no caminho da rede. Isso é bom para a privacidade e também significa que um filtro que só observa consultas DNS fica cego quando um navegador usa seu próprio resolvedor DoH. Um filtro que atua sobre o endereço de destino continua vendo a conexão, porque o aplicativo ainda precisa abri-la. Nenhuma das abordagens é completa sozinha, e é por isso que a posição honesta é “ambas, com o tempo” em vez de afirmar que uma substitui a outra.
Uma rotina prática
Você não precisa vigiar a rede o dia inteiro. Uma rotina viável são três minutos uma vez por semana: abra a lista de conexões do FireAI, percorra-a aplicativo por aplicativo e olhe para as que você não reconhece. Confira a empresa e o país por trás de qualquer novidade. Escreva uma regra para o que decidir, para nunca revisar a mesma conexão duas vezes, e exporte suas regras de vez em quando, para que um Mac novo comece com as suas decisões em vez de começar do zero. As ferramentas gratuitas sempre estarão lá quando você quiser a visão bruta; um firewall por aplicativo é o que transforma essa visão em algo sobre o qual você pode agir.
Onde FireAI e HisnLabs entram nessa história
O lsof e o nettop mostram um retrato; o que eles não conseguem fazer é interromper uma conexão, lembrar a sua decisão, ou dizer em palavras simples qual empresa e qual país estão por trás de um endereço IP — e é exatamente essa lacuna que o FireAI foi construído para preencher.
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.