L’autre soir, ma sauvegarde s’est arrêtée en plein milieu. Kopia, mon outil de backup, tournait comme d’habitude, il empaquetait mes fichiers, il ouvrait la connexion vers mon espace S3 chez Infomaniak, un nouveau chemin que je venais de mettre en place, et puis plus rien. Une fenêtre Little Snitch, au premier plan, qui me demandait poliment si j’autorisais ce process à sortir.

Mon premier réflexe, et il était faux, ça a été de me dire, tiens, Kopia a dû être mis à jour avec une signature différente. C’est pour ça que Little Snitch le tient en joue ?

La belle histoire toute prête, l’outil open source qui tourne chez moi depuis des mois et que le pare-feu se met d’un coup à soupçonner faute de signature valide. J’y ai cru une bonne minute. J’avais tort, et c’est justement ça qui est instructif.

Parce que j’ai vérifié. codesign et spctl sur la machine, deux commandes, verdict sans appel. Kopia est signé Developer ID et notarisé par Apple, Team ID stable à la clé. Signature intacte, celle de l’éditeur d’origine, aucune substitution. Alors si la signature était en règle, pourquoi cette alerte ?

La réponse tient en une distinction que presque personne ne fait, et qui change tout dans ta façon de réagir. Une alerte Little Snitch de première connexion n’est pas un verdict sur la signature. C’est le comportement normal du mode Alerte pour un process que tu n’as encore couvert par aucune règle, signé ou pas.

Le vrai rôle de la signature est ailleurs, plus profond, et c’est le même fil qui relie Little Snitch à Santa, l’autre garde de ton Mac. Suis le fil, tu ne regarderas plus jamais une popup de pare-feu de la même façon.

Deux gardes, un seul critère

Sur un Mac durci sérieusement, un binaire passe deux contrôles indépendants avant de faire quoi que ce soit d’utile.

Le premier a lieu à l’exécution. Tu double-cliques, le système appelle execve, et là un garde intercepte, il regarde qui est ce binaire, et il décide s’il a le droit de tourner. Ce garde, c’est Santa. Sa question est simple, ce binaire est-il autorisé à s’exécuter ?

Le second a lieu à la sortie réseau. Le process tourne déjà, il a passé la première porte, et il tente d’ouvrir une connexion vers un serveur quelque part sur Internet. Un autre garde intercepte, il regarde quel process parle et à qui, et il décide s’il a le droit de sortir. Ce garde, c’est Little Snitch. Sa question, elle aussi, est simple, ce process a-t-il le droit de parler dehors ?

Deux gardes, deux questions, deux moments. Santa contrôle l’entrée, ce qui a le droit de s’exécuter. Little Snitch contrôle la sortie, ce qui a le droit de communiquer.

Et le lien entre les deux, celui que personne ne te montre, c’est qu’ils s’ancrent sur la même chose. Pas le nom du binaire, pas son chemin sur le disque, sa signature. La preuve cryptographique qu’il vient bien de l’éditeur qu’il prétend être, et qu’il n’a pas été modifié depuis. C’est cette ancre commune qui rend un binaire gouvernable, des deux côtés, par une règle qui tient.

Santa, le videur à la porte

Santa est un système de contrôle d’exécution pour macOS. Son principe est un renversement, il ne cherche pas les binaires malveillants, il n’autorise que les binaires connus. Une allowlist, pas une liste noire. Ce qui n’est pas explicitement autorisé ne tourne pas.

Pour reconnaître un binaire, Santa dispose de plusieurs identifiants, qu’il évalue par ordre de précédence, du plus précis au plus large. Le CDHash, l’empreinte du contenu paginé. Le hash binaire, un SHA-256 du fichier entier. Puis les identifiants tirés de la signature, le Signing ID d’une application précise, le Certificate, et le Team ID d’un éditeur entier.

Les deux premiers cassent à chaque mise à jour de l’app. Les identifiants de signature, eux, sont le bon niveau pour une allowlist qui tient dans le temps, tu fais confiance à la signature d’un éditeur, et toutes ses applications signées passent, mises à jour comprises.

C’est là que la signature paie. Un outil signé avec un Team ID stable, comme Kopia et son certificat Developer ID, tu l’autorises une fois par ce Team ID, et il reste autorisé à travers ses versions. Un binaire vraiment non signé, lui, n’a ni Signing ID ni Team ID, aucune identité cryptographique à présenter au videur.

En mode Lockdown, celui qui verrouille pour de bon, un binaire sans autorisation ni signature reconnue est refusé à l’exécution, purement et simplement. En mode Monitor, il passe, mais Santa journalise que, le jour du verrouillage, celui-là tombera. Un troisième mode, Standalone, laisse l’utilisateur trancher au coup par coup via une invite, à toi de voir si tu le déploies.

C’est déjà une couche de souveraineté énorme, et elle mérite son propre mode d’emploi.

À lire : Santa sur tes Mac, le binaire non invité reste à la porte

Retiens juste ceci pour la suite, aux yeux de Santa, la signature n’est pas un détail cosmétique, c’est la clé d’identité stable qui rend un binaire autorisable une bonne fois plutôt qu’à chaque version.

Little Snitch, la douane à la sortie

Change de garde. Le binaire a passé la porte, il tourne, et il veut sortir sur le réseau. C’est le terrain de Little Snitch, le pare-feu sortant qui filtre les connexions non pas par adresse IP, mais par process et par destination.

Commençons par tuer l’idée reçue, la mienne il y a cinq minutes. Non, une alerte Little Snitch ne veut pas dire « ce binaire est louche ou pas signé ». Little Snitch a plusieurs modes de fonctionnement, et le comportement dépend d’abord de celui que tu as choisi.

1. Le mode Alerte, celui par défaut, te demande ton avis à chaque nouvelle connexion qu’aucune règle ne couvre encore.

2. Le mode silencieux, autoriser les connexions, laisse passer sans rien te demander tout ce qui n’est pas couvert par une règle, et enregistre.

3. Le mode silencieux, refuser les connexions, fait l’inverse, il bloque en silence. Il n’y a pas de « mode observe », c’est une confusion, et c’est exactement celle dans laquelle j’étais tombé.

En mode Alerte, la première connexion d’un process pas encore couvert déclenche une popup, que le binaire soit signé, notarisé, ou non. Kopia, mon backup pourtant signé Developer ID, n’avait juste encore aucune règle à son nom pour joindre mon hébergeur. Première sortie, première alerte. Rien d’anormal, rien qui accuse sa signature. Si j’avais été en mode silencieux autoriser, il serait passé sans un bruit.

Alors quel est le vrai rôle de la signature ici ? Ce n’est pas de déclencher ou d’étouffer l’alerte. C’est de servir d’ancre à tes règles. Quand tu crées une règle « autorise ce process », Little Snitch peut la verrouiller sur la signature de l’éditeur plutôt que sur le simple chemin du fichier.

Et c’est là que ça devient malin, si un malware remplace un jour ton binaire légitime par un faux au même emplacement sur le disque, la signature ne colle plus, la règle ancrée cesse de s’appliquer, et Little Snitch te réalerte au lieu de laisser l’imposteur profiter d’une autorisation qui ne le concerne pas.

Voilà le vrai lien entre la signature et le réseau. Pas « pas de signature égale alerte ». Mais « la signature garantit qu’une autorisation ne couvre que le binaire authentique, et saute dès qu’on le substitue ». L’attaque que ça bloque a un nom précis, la substitution de binaire. Un chemin sur le disque, ça se squatte. Une signature valide, non.

Ma sauvegarde ne s’est donc pas arrêtée parce que Kopia était suspect. Elle s’est arrêtée parce que j’étais en mode Alerte et que ce nouveau chemin S3 était une destination qu’aucune règle ne couvrait encore, un couple process plus destination inédit. Little Snitch faisait exactement son travail, me montrer une connexion inédite pour que je décide comment la cadrer, une bonne fois.

Si tu hésites encore sur l’outil de pare-feu sortant lui-même, le match est ailleurs.

À lire : Little Snitch vs LuLu, quel pare-feu sortant pour ton Mac

La signature, l’ancre commune des deux couches

C’est là que le parallèle sert à quelque chose, pas juste une jolie symétrie.

Regarde ce que la signature fait des deux côtés, et tu vois qu’elle joue le même rôle. Côté Santa, elle te permet d’autoriser un éditeur par son Team ID, une fois, et de couvrir toutes ses versions signées sans y revenir. Côté Little Snitch, elle te permet d’ancrer une règle réseau sur cet éditeur, de sorte qu’elle ne s’applique qu’au binaire authentique et saute à la moindre substitution. Même clé, deux serrures. La signature est l’ancre commune qui rend un binaire gouvernable par règle, à l’entrée comme à la sortie.

Et c’est précisément ce qu’un binaire vraiment non signé te retire. Pas une alerte de plus, non, une ancre en moins. À l’exécution, Santa n’a pas de signature stable à autoriser, il te reste les empreintes exactes qui cassent à chaque mise à jour, et en Lockdown il refuse tout net. Au réseau, Little Snitch peut toujours créer une règle par chemin, mais elle est plus faible, un chemin ça se squatte, elle ne détectera pas une substitution comme le ferait une règle ancrée sur signature. Le binaire non signé n’est pas « bloqué deux fois », il est simplement moins gouvernable aux deux postes.

Le point à emporter est là. Choisir des outils signés, ou signer les tiens, ce n’est pas qu’une formalité pour calmer Gatekeeper au premier lancement. C’est ce qui donne à tout ton dispositif de sécurité, contrôle d’exécution et contrôle réseau, une prise durable sur ce binaire, plutôt qu’une identité fragile qu’il faut réévaluer à chaque version.

La souveraineté sur tes binaires, ce n’est pas juste décider ce qui tourne. C’est aussi décider ce qui sort. Et les deux tiennent mieux quand il y a une signature à laquelle accrocher tes règles.

Le cas Kopia, en pratique

Reprenons ma sauvegarde, parce que c’est le cas le plus parlant, celui où une popup me fait tirer la mauvaise conclusion avant que je vérifie.

Kopia est un excellent outil de sauvegarde, open source, que j’utilise pour pousser mes fichiers chiffrés vers un stockage objet. Et contrairement à ce que j’avais supposé, il était bien signé Developer ID et notarisé, Team ID stable. Côté Santa, ça tombe bien, je peux l’autoriser proprement par ce Team ID et couvrir ses futures versions.

Côté Little Snitch, l’alerte que j’ai vue n’était que la première connexion vers mon nouvel endpoint en mode Alerte, pas un procès en illégitimité.

La vraie question n’était donc pas « pourquoi se méfie-t-il ? », mais « comment je cadre cette connexion pour qu’elle soit autorisée juste ce qu’il faut ? ».

Le réflexe paresseux, c’est de cliquer pour autoriser toute connexion de ce process et de passer à autre chose. Mauvaise idée, même pour un binaire signé. Tu viens de lui donner un blanc-seing pour joindre n’importe quel serveur sur Internet. Le jour où il est compromis, ou remplacé par un imposteur, tu as toi-même ouvert la porte en grand.

Le fix propre tient en une règle spécifique, cadrée serré.

1. Cible le binaire par son chemin exact, pas une règle globale. La règle vaut pour l’exécutable à cet emplacement précis, rien d’autre.
2. Autorise la seule destination utile. Dans le popup, quand Little Snitch te propose la portée de la connexion, choisis le domaine de ton hébergeur plutôt que l’option la plus large, « Any Connection ». Kopia a besoin de joindre ton stockage, il n’a aucune raison de parler à autre chose.
3. Rien de plus. Pas de wildcard généreux, pas d’autorisation permanente sur tout le réseau.

Le résultat, c’est le bon compromis. Ta sauvegarde tourne sans t’interrompre, et le process reste enfermé dans le seul couloir dont il a besoin. Tu n’as pas contourné la sécurité, tu l’as réglée. La différence entre « je clique oui pour avoir la paix » et « j’autorise exactement ce qu’il faut » est toute la différence entre subir tes outils et les gouverner.

Ce que ça change, et ce que ça ne change pas

Le durcissement d’un Mac ne se pense pas garde par garde, mais comme une chaîne. Santa et Little Snitch ne font pas le même travail, ils gardent deux portes distinctes, mais ils lisent le même passeport. Comprendre ça change ta façon de réagir à une alerte, tu ne paniques plus, tu ne cliques plus « autoriser tout » par réflexe, tu te demandes d’abord si c’est simplement une première connexion à cadrer.

Idée reçue

Une alerte ne veut pas dire « binaire suspect ». C’est le piège dans lequel je suis tombé avec Kopia. En mode Alerte, Little Snitch te sollicite pour toute première connexion non couverte, signé ou pas, notarisé ou pas. La popup n’est pas un verdict sur la signature, c’est une question de cadrage. Et dans l’autre sens, non signé ne veut pas dire malveillant non plus, une quantité de logiciels libres excellents ne sont pas signés par Apple parce que le certificat Developer est un service payant qu’un projet bénévole ne prend pas toujours. Deux confusions à éviter, la même leçon, ne confonds jamais « je ne connais pas encore ce process » avec « ce process est louche ».

Les vraies limites

Santa ne lit pas tout. Il contrôle l’exécution de binaires, pas le contenu d’un script Python ou d’un shell lancé par un interpréteur déjà autorisé. C’est sa limite connue, et elle est réelle. Le duo exécution plus réseau la réduit sans la supprimer, un script exfiltrant des données devra toujours ouvrir une connexion, et là Little Snitch reprend la main.

Little Snitch ne partage pas la place. macOS n’autorise qu’un seul fournisseur de filtrage de contenu réseau actif à la fois, le fameux slot du filtre de données. C’est Little Snitch ou LuLu, pas les deux ensemble, ils se disputent la même extension. Attention à ne pas confondre avec un profil DNS chiffré, qui relève d’une autre catégorie d’extension réseau et ne consomme pas ce slot, tu peux donc l’avoir en plus. C’est une contrainte Apple, pas un défaut de l’outil, mais elle conditionne ton architecture.

Rien de tout ça n’annule le principe. Ces deux couches se complètent, chacune ferme un angle mort de l’autre, et pour aller plus loin sur les réglages qui durcissent le poste au quotidien, la base est ailleurs.

À lire : La privacy sur macOS, les paramètres à changer immédiatement

En résumé

Une alerte de pare-feu n’est pas un verdict sur la signature d’un binaire. Le plus souvent, c’est juste une première connexion à cadrer, en mode Alerte, pour un process qu’aucune règle ne couvre encore. J’ai cru le contraire pour mon backup, j’ai vérifié, et Kopia était signé et notarisé depuis le début. La vraie fonction de la signature n’est pas de déclencher l’alerte, c’est de servir d’ancre commune, à Santa pour autoriser un éditeur une bonne fois, à Little Snitch pour qu’une règle ne couvre que le binaire authentique et saute dès qu’on le substitue.

Concrètement, trois réflexes. Devant une alerte, ne clique jamais « Any Connection » par facilité, demande-toi si c’est simplement une première connexion, puis écris une règle par chemin vers le seul domaine utile. Quand tu choisis un logiciel, la signature n’est pas un luxe, c’est ce qui le rend gouvernable par tout ton dispositif, Team ID stable côté Santa, ancre de règle côté Little Snitch. Et quand tu penses durcissement, pense aux deux bouts, ce qui s’exécute et ce qui sort, reliés par le même passeport, la signature du binaire.

À lire pour la suite : Ton SIEM souverain, lis-le vraiment puis fais-le passer à l’action, là où les décisions que Santa journalise deviennent quelque chose que tu regardes vraiment.

La suite logique, une fois Santa posé en mode Monitor, c’est de faire remonter ce qu’il journalise dans ton SIEM. Ce sera l’objet du prochain épisode, brancher Santa sur Wazuh et corréler ce qui s’exécute avec ce qui bloque.

Sources

Pour creuser toi-même, les documentations primaires plutôt que les forums de seconde main.

• Santa, modes et identifiants : documentation officielle North Pole Security
• Little Snitch, concepts de règles : help.obdev.at, concepts-rules
• Little Snitch, signature de code comme ancre de règle : help.obdev.at, adv-code-signature
• Little Snitch, modes de fonctionnement : help.obdev.at, intro-opmodes
• Le slot unique de filtrage réseau macOS : documentation Apple NEFilterManager
• Kopia, installation : kopia.io/docs/installation
• Kopia, dépôt source : github.com/kopia/kopia