Pourquoi j'ai créé une application qui protège automatiquement la frontière réseau de votre Mac

Tout a commencé par une question anodine sur le Wi-Fi d'un fast-food

Un jour, alors que je travaillais sur un Wi-Fi public, je me suis soudain demandé : « À quoi ressemble mon Mac, sur ce Wi-Fi, pour la personne à la table d'à côté ? » — et j'ai commencé à creuser.

« Même sur un Wi-Fi public, si l'isolation des clients (isolation AP) est active, on ne peut pas communiquer avec les autres appareils, donc c'est sûr. » Je l'ai cru longtemps, mais en y regardant de plus près, cette hypothèse était plus fragile que prévu. L'isolation des clients n'est pas activée sur tous les Wi-Fi. Même quand elle l'est, elle peut être contournée par une technique appelée « AirSnitch », signalée par le SANS Institute. Je n'ai aussi mesuré à quel point mon Mac diffuse des informations en clair via Bonjour (mDNS) qu'après avoir lancé moi-même dns-sd et lsof.

La conclusion était simple. Il y a deux contre-mesures : réduire la surface exposée et partir du principe que personne ne change les réglages à la main à chaque changement de réseau. Presque personne ne revoit ses réglages chaque fois qu'il arrive dans un café (moi non plus). J'ai donc créé une application macOS qui distingue automatiquement les réseaux de confiance des autres et réduit automatiquement la surface exposée sur les réseaux inconnus. C'est ainsi que RoamSwitch est né.

Les serveurs de développement souffraient en fait du même problème

En me penchant sur les Wi-Fi publics, je me suis aussi demandé ce qu'il en était des serveurs de développement, et j'ai creusé. Je supposais vaguement que « un serveur de développement n'écoute que sur localhost, donc il est sûr vis-à-vis de l'extérieur », mais en réalité cela varie selon le framework, et certaines valeurs par défaut sont contre-intuitives.

next dev se lie à 0.0.0.0 si l'on ne précise pas hostname. python -m http.server écoute lui aussi par défaut sur toutes les interfaces. Vite utilise localhost par défaut, mais tout le monde a déjà ajouté --host pour tester sur un vrai smartphone. Il existe aussi CVE-2023-34092 (traversée de chemin, CVSS 7.5), qui vise précisément cela. Avec -p de Docker, un port peut même être publié sur 0.0.0.0 en contournant les réglages du pare-feu de l'hôte.

Cela mène à la même conclusion. Plutôt que de compter sur chacun pour penser à fermer les ports à chaque fois, il est plus réaliste de bloquer automatiquement les accès extérieurs dès la connexion à un réseau non fiable. C'est d'ailleurs l'un des usages de RoamSwitch les plus souvent signalés. Il audite passivement les ports ouverts et signale le risque, et sur les réseaux non enregistrés, il bloque l'accès depuis le LAN externe avec le filtre de paquets du noyau.

Le contrôle du pare-feu (pf/socketfilterfw), la détection d'usurpation ARP et l'assistant privilégié (XPC) de RoamSwitch reposent sur une expérience de terrain. J'ai travaillé comme SE dans une entreprise informatique étrangère et dans un grand groupe de fabricants d'électronique, puis, une fois indépendant, j'ai fourni des services ASP à des administrations, des universités et des instituts de recherche. Je développe aujourd'hui « RoamSwitch » seul et j'écris sur Zenn ce que je découvre.