O seu Mac está a falar neste preciso momento. Não é uma metáfora: agora mesmo, várias dezenas de processos mantêm sockets abertos para servidores de que nunca ouviu falar, e a maior parte disso é perfeitamente normal. Verificações de actualizações, sincronização, notificações push, telemetria, um tipo de letra a ser descarregado. O objectivo da monitorização de rede não é entrar em pânico com o volume, mas conseguir responder a uma única pergunta sobre qualquer linha individual: que aplicação, para quem, e porquê. O macOS dá-lhe três ferramentas gratuitas que o levam a meio caminho. Este artigo explica o que cada uma mostra, onde pára, e o que uma firewall por aplicação acrescenta por cima.
Monitor de Actividade: totais, não destinos
Abra o Monitor de Actividade, clique no separador Rede e obtém a visão geral honesta para que a Apple o desenhou. O guia da Apple descreve o painel inferior: pacotes recebidos e enviados, dados recebidos e enviados em megabytes, e um gráfico que pode alternar entre débito de pacotes e de dados. A lista de processos acima diz-lhe quanto cada processo enviou e recebeu. O que não lhe diz é para onde. Não há coluna para o anfitrião remoto, nem porta, nem país. O Monitor de Actividade responde a «há algo a usar muita largura de banda?» e pára aí. É a ferramenta certa para reparar que um processo auxiliar carregou dois gigabytes durante a noite, e a ferramenta errada para descobrir para quem.
lsof: uma fotografia de cada socket aberto
A ferramenta de linha de comandos lsof lista ficheiros abertos, e em Unix um socket de rede é um ficheiro. Com a opção -i, que a página man do macOS descreve como a selecção dos ficheiros cujo endereço de internet corresponde, obtém todas as ligações abertas com o nome do processo proprietário, o seu ID de processo, o protocolo, e o endereço e porta locais e remotos. Acrescente -n e -P para manter endereços e portas em forma numérica em vez de esperar pelo DNS inverso. O resultado é a imagem gratuita mais completa que pode obter do momento presente, e a ênfase está em momento: o lsof é uma fotografia. Uma ligação que abriu, enviou um kilobyte e fechou no meio segundo antes de carregar em Enter simplesmente não está lá. Além disso, identifica o processo pelo nome e pelo PID, não por quem o assinou, pelo que um binário chamado «Adobe Update Helper» numa pasta temporária parece exactamente igual ao verdadeiro.
nettop: a mesma vista, actualizada em directo
O nettop é o que o macOS inclui de mais próximo de um monitor de ligações em directo. A sua página man descreve-o como uma ferramenta que apresenta uma lista de sockets ou rotas com estatísticas de rede actualizadas periodicamente. Na prática, vê cada processo, as suas ligações abertas, bytes recebidos e enviados por ligação, a interface em uso e o estado da ligação, com actualização a cada segundo. Resolve o problema da fotografia do lsof e continua a ser a melhor resposta integrada à pergunta «o que está aquela aplicação a fazer agora». Os seus limites são os mesmos do lsof em todos os outros aspectos: nenhuma identidade além do nome do processo, nenhuma noção do país ou da organização por detrás de um endereço, nenhuma memória do que aconteceu há uma hora, e nenhuma forma de dizer não. Com o nettop pode observar uma ligação; não pode travá-la.
A firewall integrada não ajuda aqui
Muitas pessoas assumem que activar a firewall nas Definições do Sistema cobre isto. Não cobre. O guia da própria Apple é cuidadoso nas palavras: a firewall do macOS protege o seu Mac de contactos indesejados iniciados por outros computadores. É um filtro de entrada. Não tem nada a dizer sobre o que as suas aplicações enviam para fora, que é a direcção para onde aponta cada pergunta deste artigo. Para o controlo de saída, por aplicação, a Apple disponibiliza a framework Network Extension, cujos content filter providers permitem a uma aplicação de terceiros ver e filtrar fluxos de rede com a identidade da aplicação que os criou. É essa a base sobre a qual assentam as firewalls por aplicação modernas no macOS, e é o que transforma uma lista de sockets numa lista de decisões.
O que uma firewall por aplicação acrescenta
Quatro coisas, em concreto. Identidade: um fluxo é atribuído a uma aplicação assinada, pelo que uma regra para o Slack aplica-se ao Slack e não a qualquer coisa que por acaso partilhe o nome; as regras por aplicação do FireAI seguem a assinatura de código da aplicação por esta razão. Visibilidade: cada ligação é mostrada à medida que acontece, incluindo as que duram meio segundo. Contexto: o endereço IP em bruto é resolvido para a organização e o país por detrás dele, que o FireAI mostra num mapa-múndi em directo com as ligações bloqueadas a vermelho. E controlo: uma ligação pode ser permitida ou negada por anfitrião, domínio, IP ou porta, e uma aplicação desconhecida tem de pedir antes da sua primeira ligação, com a razão do veredicto do modelo local mostrada no pedido. Se discordar de uma decisão tomada pela IA, anula-a, e a anulação torna-se uma regra visível que pode ler mais tarde ou exportar como ficheiro de texto.
O FireAI aceita também ordens em linguagem natural, em inglês ou francês, como «block Microsoft Teams», o que é uma forma mais rápida de escrever uma regra do que uma caixa de diálogo com quatro campos. O que não faz merece ser dito com a mesma clareza: não inspecciona o conteúdo do tráfego cifrado, não analisa ficheiros e não examina processos ou memória. Trabalha ao nível de quem se liga a quê, e é honesto quanto a essa fronteira.
Como ler uma ligação
Pegue em qualquer linha do nettop ou do registo de uma firewall e faça três perguntas. Primeiro, a empresa: a quem pertence o endereço? A maior parte do tráfego vai para um punhado de fornecedores de alojamento e redes de distribuição de conteúdos, e uma aplicação de música a falar com a Amazon ou a Cloudflare está normalmente apenas a falar com o seu próprio backend. O padrão a notar é a incongruência: uma aplicação de notas a ligar-se a uma rede de publicidade, ou um utilitário de capturas de ecrã a ligar-se a um fornecedor de alojamento que não tem motivo para usar. Segundo, o país: não porque um servidor estrangeiro seja mau, mas porque uma mudança é informativa. Uma aplicação que se ligou à Irlanda durante um ano e hoje se liga pela primeira vez a um novo país mudou algo. Terceiro, a porta. A 443 é HTTPS e cobre quase tudo; a 80 é HTTP em claro e deveria ser rara em 2026; a 53 é DNS; a 22 é SSH; a 445 é partilha de ficheiros SMB; a 5353 é Bonjour na rede local. Uma aplicação de consumo a abrir a porta 22 ou 445 para um endereço na internet é suficientemente invulgar para justificar uma pergunta.
Padrões que merecem uma segunda olhadela
- Beaconing: o mesmo processo a contactar o mesmo endereço a um intervalo fixo, a cada sessenta segundos ou a cada dez minutos, com cargas minúsculas. O MITRE ATT&CK descreve o comando e controlo como a tentativa do adversário de comunicar com sistemas comprometidos para os controlar, e um batimento regular é a forma mais comum que isso assume. As verificações de actualizações também fazem beaconing, por isso a pista é um processo desconhecido, não o ritmo por si só.
- Nós de saída Tor: o Tor Project publica a sua lista de nós de saída, e não há razão comum para uma aplicação de produtividade chegar a um deles. O FireAI aplica essa lista localmente como um dos seus feeds de threat intelligence.
- HTTP em claro a transportar credenciais: um formulário de início de sessão, uma chave de API ou um número de cartão enviados pela porta 80 são legíveis por qualquer pessoa no caminho. A protecção de dados não cifrados do FireAI foi construída exactamente para este caso e impede que números de cartão, palavras-passe e chaves de API saiam por HTTP em claro.
- Uma primeira ligação de uma aplicação instalada há muito tempo: uma aplicação que esteve silenciosa durante meses e de repente abre um socket foi actualizada, substituída, ou sequestrada por um plugin. Vale a pena saber qualquer uma das três.
- Binários não assinados ou desconhecidos a ir à internet, ponto final: num Mac onde tudo o que usa é assinado, um binário não assinado a fazer a sua primeira ligação é o alerta mais útil que uma firewall pode dar. Os modos de segurança mais rigorosos do FireAI, Paranoid e Under attack, bloqueiam de imediato as aplicações não assinadas.
- Endereços em listas de bloqueio publicadas: a Spamhaus descreve a sua lista DROP como intervalos tão perigosos que os disponibiliza gratuitamente a quem quiser essa camada de protecção; a FireHOL agrega e documenta feeds públicos de IP centrados em ataques e abusos; a abuse.ch gere plataformas de threat intelligence impulsionadas pela comunidade. O FireAI aplica estes feeds localmente, como listas de bloqueio de IP a nível do sistema, sem enviar o seu tráfego para lado nenhum.
Filtragem de DNS, com honestidade
O DNS é onde vivem muitos produtos de filtragem de rede, por isso é justo perguntar onde se situa o FireAI. Hoje, o FireAI filtra a própria ligação: aplica feeds de threat intelligence e listas de bloqueio de IP aos endereços que as suas aplicações realmente alcançam, e as regras por aplicação podem corresponder a um nome de anfitrião ou de domínio. O que ainda não faz é actuar como o seu resolvedor de DNS ou oferecer DNS cifrado próprio; isso está planeado, e preferimos dizê-lo a deixá-lo implícito. Há uma consequência prática a compreender. O DNS cifrado, especificado como DNS over TLS na RFC 7858 e DNS over HTTPS na RFC 8484, e suportado a nível do sistema no macOS desde a sessão da WWDC 2020 da Apple sobre a activação do DNS cifrado, esconde as suas consultas de qualquer pessoa no caminho da rede. Isso é bom para a privacidade e significa também que um filtro que só observa consultas DNS fica cego quando um navegador usa o seu próprio resolvedor DoH. Um filtro que actua sobre o endereço de destino continua a ver a ligação, porque a aplicação continua a ter de a abrir. Nenhuma das abordagens é completa por si só, 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
Não precisa de vigiar a rede o dia inteiro. Uma rotina exequível são três minutos uma vez por semana: abra a lista de ligações do FireAI, percorra-a aplicação a aplicação e olhe para as que não reconhece. Verifique a empresa e o país por detrás de qualquer novidade. Escreva uma regra para o que decidir, para nunca rever a mesma ligação duas vezes, e exporte as 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 estarão sempre lá quando quiser a vista em bruto; uma firewall por aplicação é o que torna essa vista algo sobre o qual pode agir.
O papel do FireAI e da HisnLabs
O lsof e o nettop mostram-lhe uma fotografia; o que não conseguem fazer é travar uma ligação, lembrar-se da sua decisão, ou dizer-lhe em palavras simples que empresa e que país estão por detrás de um endereço IP — e é exactamente essa lacuna que o FireAI foi construído para preencher.
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.