Votre Mac parle en ce moment même. Pas au sens figuré : à cet instant, plusieurs dizaines de processus gardent des sockets ouverts vers des serveurs dont vous n’avez jamais entendu parler, et l’essentiel est parfaitement normal. Vérifications de mise à jour, synchronisation, notifications push, télémétrie, une police récupérée à la volée. L’intérêt de la surveillance réseau n’est pas de paniquer devant le volume, mais de pouvoir répondre à une seule question pour n’importe quelle ligne : quelle app, vers qui, et pourquoi. macOS fournit trois outils gratuits qui font une partie du chemin. Cet article explique ce que chacun montre, où il s’arrête, et ce qu’un pare-feu par application ajoute par-dessus.
Moniteur d’activité : des totaux, pas des destinations
Ouvrez Moniteur d’activité, cliquez sur l’onglet Réseau, et vous obtenez la vue d’ensemble honnête pour laquelle Apple l’a conçu. Le guide d’Apple décrit le panneau du bas : paquets entrants et sortants, données reçues et envoyées en mégaoctets, et un graphique que l’on peut basculer entre débit en paquets et en données. La liste des processus au-dessus indique combien chacun a envoyé et reçu. Ce qu’elle ne dit pas, c’est vers où. Aucune colonne pour l’hôte distant, ni le port, ni le pays. Moniteur d’activité répond à « quelque chose consomme-t-il beaucoup de bande passante ? » et s’arrête là. C’est le bon outil pour repérer qu’un processus auxiliaire a envoyé deux gigaoctets pendant la nuit, et le mauvais pour découvrir à qui.
lsof : un instantané de chaque socket ouvert
L’outil en ligne de commande lsof liste les fichiers ouverts, et sous Unix, un socket réseau est un fichier. Avec l’option -i, que la page de manuel macOS décrit comme sélectionnant les fichiers dont l’adresse internet correspond, vous obtenez chaque connexion ouverte avec le nom du processus propriétaire, son identifiant, le protocole, et les adresses et ports locaux et distants. Ajoutez -n et -P pour garder adresses et ports sous forme numérique plutôt que d’attendre la résolution DNS inverse. Le résultat est l’image gratuite la plus complète que vous puissiez avoir de l’instant présent, et l’accent est sur instant : lsof est un instantané. Une connexion qui s’est ouverte, a envoyé un kilooctet et s’est refermée dans la demi-seconde précédant votre appui sur Entrée n’y figure tout simplement pas. Il identifie aussi le processus par son nom et son PID, pas par son signataire, si bien qu’un binaire nommé « Adobe Update Helper » dans un dossier temporaire ressemble exactement au vrai.
nettop : la même vue, mise à jour en direct
nettop est ce que macOS fournit de plus proche d’un moniteur de connexions en direct. Sa page de manuel le décrit comme affichant une liste de sockets ou de routes avec des statistiques réseau mises à jour périodiquement. En pratique, vous voyez chaque processus, ses connexions ouvertes, les octets entrants et sortants par connexion, l’interface utilisée et l’état de la connexion, rafraîchis chaque seconde. Il corrige le problème d’instantané de lsof et reste la meilleure réponse intégrée à « que fait cette app en ce moment ». Ses limites sont les mêmes que celles de lsof sur tous les autres points : aucune identité au-delà d’un nom de processus, aucune notion de pays ou d’organisation derrière une adresse, aucun souvenir de ce qui s’est passé il y a une heure, et aucun moyen de dire non. Avec nettop, vous pouvez regarder une connexion ; vous ne pouvez pas l’arrêter.
Le pare-feu intégré n’aide pas ici
On suppose souvent qu’activer le pare-feu dans Réglages Système couvre cela. Ce n’est pas le cas. Le guide d’Apple choisit ses mots avec soin : le pare-feu de macOS protège votre Mac des contacts indésirables initiés par d’autres ordinateurs. C’est un filtre entrant. Il n’a rien à dire sur ce que vos applications envoient, qui est pourtant la direction vers laquelle pointe chaque question de cet article. Pour le contrôle sortant, par application, Apple fournit le framework Network Extension, dont les fournisseurs de filtrage de contenu permettent à une app tierce de voir et de filtrer les flux réseau avec l’identité de l’application qui les a créés. C’est le socle sur lequel les pare-feu par application modernes s’appuient sur macOS, et c’est ce qui transforme une liste de sockets en liste de décisions.
Ce qu’ajoute un pare-feu par application
Quatre choses, concrètement. L’identité : un flux est attribué à une application signée, si bien qu’une règle pour Slack s’applique à Slack et non à ce qui partage son nom par hasard ; les règles par application de FireAI suivent la signature de code de l’app pour cette raison. La visibilité : chaque connexion est affichée au moment où elle se produit, y compris celles qui durent une demi-seconde. Le contexte : l’adresse IP brute est résolue en organisation et en pays, que FireAI affiche sur une carte du monde en direct, avec les connexions bloquées en rouge. Et le contrôle : une connexion peut être autorisée ou refusée par hôte, domaine, IP ou port, et une app inconnue doit demander avant sa première connexion, la raison du verdict du modèle embarqué étant affichée dans la demande. Si vous n’êtes pas d’accord avec une décision prise par l’IA, vous l’annulez, et cette annulation devient une règle visible que vous pouvez relire plus tard ou exporter en fichier texte.
FireAI accepte aussi des ordres en langage courant, en anglais ou en français, comme « bloque Microsoft Teams », ce qui est plus rapide qu’un formulaire à quatre champs pour écrire une règle. Ce qu’il ne fait pas mérite d’être dit tout aussi clairement : il n’inspecte pas le contenu du trafic chiffré, n’analyse pas les fichiers, et n’examine ni les processus ni la mémoire. Il travaille au niveau de qui se connecte à quoi, et il est honnête sur cette frontière.
Comment lire une connexion
Prenez n’importe quelle ligne de nettop ou d’un journal de pare-feu et posez trois questions. D’abord, la société : à qui appartient l’adresse ? La majorité du trafic va vers une poignée d’hébergeurs et de réseaux de diffusion de contenu, et une app de musique qui parle à Amazon ou à Cloudflare parle en général simplement à son propre backend. Le motif à repérer, c’est le décalage : une app de prise de notes qui se connecte à une régie publicitaire, ou un utilitaire de capture d’écran qui contacte un hébergeur qu’il n’a aucune raison d’utiliser. Ensuite, le pays : non parce qu’un serveur étranger serait mauvais, mais parce qu’un changement est informatif. Une app qui s’est connectée en Irlande pendant un an et qui, aujourd’hui, joint un nouveau pays pour la première fois a changé quelque chose. Enfin, le port. Le 443, c’est HTTPS et cela couvre presque tout ; le 80, c’est HTTP en clair et cela devrait être rare en 2026 ; le 53, c’est le DNS ; le 22, SSH ; le 445, le partage de fichiers SMB ; le 5353, Bonjour sur le réseau local. Une app grand public qui ouvre le port 22 ou 445 vers une adresse sur internet est assez inhabituelle pour justifier une question.
Les motifs qui méritent un second regard
- Le balisage : le même processus qui contacte la même adresse à intervalle fixe, toutes les soixante secondes ou toutes les dix minutes, avec de minuscules charges utiles. MITRE ATT&CK décrit la commande et le contrôle comme l’adversaire cherchant à communiquer avec les systèmes compromis pour les piloter, et un battement régulier en est la forme la plus courante. Les vérifications de mise à jour balisent aussi ; l’indice, c’est donc un processus inconnu, pas le rythme seul.
- Les nœuds de sortie Tor : le Tor Project publie la liste de ses nœuds de sortie, et il n’existe aucune raison ordinaire pour qu’une app de productivité en joigne un. FireAI applique cette liste en local comme l’un de ses flux de renseignement sur les menaces.
- Du HTTP en clair transportant des identifiants : un formulaire de connexion, une clé d’API ou un numéro de carte envoyé sur le port 80 est lisible par quiconque se trouve sur le chemin. La protection des données non chiffrées de FireAI existe précisément pour ce cas et empêche numéros de carte, mots de passe et clés d’API de sortir en HTTP non chiffré.
- Une première connexion d’une app installée depuis longtemps : une app silencieuse pendant des mois qui ouvre soudain un socket a été mise à jour, remplacée, ou détournée par un plugin. Les trois valent la peine d’être sus.
- Des binaires non signés ou inconnus qui vont en ligne, tout court : sur un Mac où tout ce que vous utilisez est signé, un binaire non signé qui établit sa première connexion est l’alerte la plus utile qu’un pare-feu puisse lever. Les modes de sécurité les plus stricts de FireAI, Paranoïaque et Sous attaque, bloquent purement et simplement les apps non signées.
- Des adresses figurant sur des listes de blocage publiées : Spamhaus décrit sa liste DROP comme des plages si dangereuses qu’il la fournit gratuitement à quiconque veut cette couche de protection ; FireHOL agrège et documente des flux d’IP publics centrés sur les attaques et les abus ; abuse.ch fait tourner des plateformes de renseignement communautaires. FireAI applique ces flux en local, comme listes de blocage d’IP à l’échelle du système, sans envoyer votre trafic nulle part.
Le filtrage DNS, honnêtement
Le DNS est l’endroit où vivent beaucoup de produits de filtrage réseau, il est donc légitime de demander où se situe FireAI. Aujourd’hui, FireAI filtre sur la connexion elle-même : il applique les flux de renseignement sur les menaces et les listes de blocage d’IP aux adresses que vos apps atteignent réellement, et les règles par application peuvent viser un hôte ou un nom de domaine. Ce qu’il ne fait pas encore, c’est servir de résolveur DNS ou proposer son propre DNS chiffré ; c’est prévu, et nous préférons le dire plutôt que de le laisser entendre. Il y a une conséquence pratique à comprendre. Le DNS chiffré, spécifié comme DNS over TLS dans la RFC 7858 et DNS over HTTPS dans la RFC 8484, et pris en charge à l’échelle du système sur macOS depuis la session WWDC 2020 d’Apple consacrée à son activation, cache vos requêtes à quiconque se trouve sur le chemin réseau. C’est bon pour la vie privée, et cela signifie aussi qu’un filtre qui ne regarde que les requêtes DNS devient aveugle quand un navigateur utilise son propre résolveur DoH. Un filtre qui agit sur l’adresse de destination voit toujours la connexion, parce que l’app doit quand même l’ouvrir. Aucune des deux approches n’est complète seule, et c’est pourquoi la position honnête est « les deux, à terme » plutôt que la prétention que l’une remplace l’autre.
Une routine pratique
Vous n’avez pas besoin de surveiller le réseau toute la journée. Une routine tenable, c’est trois minutes une fois par semaine : ouvrir la liste des connexions de FireAI, la parcourir application par application, et regarder celles que vous ne reconnaissez pas. Vérifier la société et le pays derrière tout ce qui est nouveau. Écrire une règle pour ce que vous décidez, afin de ne jamais réexaminer deux fois la même connexion, et exporter vos règles de temps en temps pour qu’un Mac neuf démarre avec vos décisions plutôt que de zéro. Les outils gratuits seront toujours là quand vous voudrez la vue brute ; un pare-feu par application est ce qui rend cette vue exploitable.
Le rôle de FireAI et de HisnLabs
lsof et nettop vous montrent un instantané ; ce qu’ils ne peuvent pas faire, c’est arrêter une connexion, retenir votre décision, ou vous dire en clair quelle société et quel pays se trouvent derrière une adresse IP — et c’est précisément ce vide que FireAI a été conçu pour combler.
FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction Autopilot) sur du trafic réel, sans que rien ne quitte votre Mac.
Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.