Auditer les ports d’écoute d’un Mac cloud et réduire son exposition

Après plusieurs cycles de build sur un Mac distant, des outils de développement, serveurs de débogage, gestionnaires de paquets et scripts temporaires peuvent laisser des ports en écoute. Le véritable problème n’est pas leur nombre, mais l’impossibilité de répondre à trois questions : quel processus écoute, sur quelle adresse est-il lié et réapparaîtra-t-il après le redémarrage de la machine ? Voici une procédure d’audit reproductible et en lecture seule, fondée sur les outils intégrés à macOS, qui permet ensuite de réduire progressivement la surface d’exposition.

Établir une référence des ports en écoute

Commencez par relever l’état TCP et UDP lorsque le nœud est inactif et qu’aucune tâche de débogage temporaire n’est en cours. L’option -nP évite la résolution des noms et la conversion des numéros de port en noms de service, ce qui produit une sortie plus facile à conserver et à comparer.

mkdir -p "$HOME/audit/network"
stamp="$(date -u +%Y%m%dT%H%M%SZ)"

sudo lsof -nP -iTCP -sTCP:LISTEN \
  > "$HOME/audit/network/tcp-$stamp.txt"

sudo lsof -nP -iUDP \
  > "$HOME/audit/network/udp-$stamp.txt"

netstat -anv -p tcp \
  > "$HOME/audit/network/netstat-tcp-$stamp.txt"

Ne vous limitez pas au numéro de port. Les champs COMMAND, PID, USER et NAME doivent être examinés ensemble : un même serveur de développement exécuté par un utilisateur standard et un programme inconnu exécuté en tant que root n’ont pas du tout le même niveau de priorité.

L’état LISTEN ne signifie pas nécessairement que le service est accessible depuis l’extérieur. L’adresse d’écoute, le pare-feu de l’hôte et la politique réseau du nœud déterminent ensemble l’accessibilité réelle. Une adresse générique indique toutefois que le processus a volontairement élargi son périmètre de réception et doit donc être expliquée en priorité.

Relier chaque port à son processus et à son élément de démarrage

Une fois le PID identifié, utilisez ps pour vérifier la commande complète, le processus parent et la durée d’exécution, puis recherchez si le processus provient d’un élément de démarrage persistant.

pid=1234
ps -p "$pid" -o pid,ppid,user,lstart,command
sudo lsof -nP -p "$pid"

launchctl print "gui/$(id -u)" > "$HOME/audit/network/launch-gui.txt"
sudo launchctl print system > "$HOME/audit/network/launch-system.txt"

find "$HOME/Library/LaunchAgents" \
  /Library/LaunchAgents \
  /Library/LaunchDaemons \
  -maxdepth 1 -name '*.plist' -print 2>/dev/null

Pour tout fichier plist suspect, exécutez plutil -p chemin_du_fichier afin d’examiner Program, ProgramArguments, RunAtLoad et KeepAlive. Un processus lancé temporairement par un script de build doit s’arrêter à la fin de la tâche. Si KeepAlive le redémarre continuellement, une simple commande kill ne résoudra pas le problème.

Tenir un registre des mesures à prendre

Pour chaque écoute non système, consignez au minimum la fonction du service, son responsable, son mode de démarrage, son adresse de liaison et la raison justifiant son maintien. Lorsqu’un processus ne peut pas être attribué, arrêtez d’abord la tâche correspondante et conservez sa ligne de commande, le chemin de ses journaux et le contenu de son fichier plist. Ne supprimez pas immédiatement les fichiers, au risque de perdre le contexte nécessaire au diagnostic.

Restreindre d’abord l’adresse de liaison plutôt que bloquer le port

Lorsqu’un service de développement est réservé à l’utilisateur actuel, la correction la plus directe consiste à le lier à l’adresse de bouclage. Ainsi, même si les règles du pare-feu changent, le processus n’acceptera pas de connexions provenant d’autres interfaces.

python3 -m http.server 8080 --bind 127.0.0.1

HOST=127.0.0.1 PORT=8080 ./run-development-server

Pour y accéder depuis votre propre ordinateur, utilisez une redirection locale SSH comme point d’entrée :

ssh -N \
  -L 127.0.0.1:9000:127.0.0.1:8080 \
  "$REMOTE_USER@$REMOTE_HOST"

Accédez ensuite à 127.0.0.1:9000 sur votre machine locale. Vérifiez également que le service distant écoute toujours uniquement sur 127.0.0.1:8080 et qu’un paramètre de démarrage non pris en compte ne l’a pas fait revenir à *:8080.

Restreindre l’adresse de liaison est généralement plus facile à valider que l’ajout de règles de blocage, et présente moins de risques d’interrompre accidentellement les connexions d’administration à distance. Le pare-feu constitue une deuxième couche de contrôle et ne doit pas remplacer une configuration d’écoute correcte du service.

Vérifier en lecture seule les deux couches de pare-feu

Le pare-feu applicatif de macOS et pf ne couvrent pas les mêmes aspects. Lors de l’audit, commencez par consulter leur état sans remplacer directement les règles depuis une session distante.

sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps

sudo pfctl -s info
sudo pfctl -sr
sudo pfctl -sn

La liste du pare-feu applicatif permet d’identifier les programmes autorisés à recevoir des connexions entrantes. La sortie de pf sert à examiner les règles de filtrage et de traduction d’adresses. En cas d’anomalie, enregistrez d’abord l’intégralité de la sortie, puis déterminez si les règles proviennent de la configuration système, d’une procédure d’exploitation ou d’une expérimentation temporaire.

Lors d’une modification distante de pf, le principal risque n’est pas une erreur de syntaxe, mais le blocage de la connexion d’administration en cours. En l’absence d’un second chemin d’accès préalablement validé, limitez-vous aux vérifications en lecture seule. Si une modification est indispensable, sauvegardez d’abord les règles, définissez précisément la commande de restauration et vérifiez en continu l’accessibilité de la console depuis une autre session.

Détecter par comparaison la réapparition des ports

Un nettoyage ponctuel ne couvre pas les futures mises à niveau d’outils, les modifications des scripts de build ni l’ajout de nouveaux éléments de démarrage. Il est recommandé d’enregistrer une référence approuvée une fois l’initialisation de l’environnement terminée, puis d’effectuer un nouveau relevé après chaque changement important.

latest_tcp="$(ls -t "$HOME"/audit/network/tcp-*.txt | head -n 1)"
diff -u "$HOME/audit/network/tcp-approved.txt" "$latest_tcp"

latest_udp="$(ls -t "$HOME"/audit/network/udp-*.txt | head -n 1)"
diff -u "$HOME/audit/network/udp-approved.txt" "$latest_udp"

Lorsqu’une comparaison fait apparaître un nouvel élément, suivez toujours le même ordre : identifiez le propriétaire du processus, vérifiez l’adresse d’écoute, déterminez l’origine du démarrage, évaluez la nécessité d’un accès distant, puis décidez de conserver le service, de le lier uniquement à la machine locale ou de le désactiver. Ne cessez pas le suivi après avoir ajouté le numéro de port à une liste blanche statique, car différents programmes peuvent prendre le contrôle d’un même port.

Sur les nœuds physiques dédiés d’OwnAMac, cette procédure s’applique également aux agents de build, serveurs de prévisualisation, processus de rappel de test et services temporaires de partage de fichiers. Une fois l’audit terminé, conservez les instantanés bruts, le registre des mesures prises et les résultats de la vérification. Lors du prochain changement d’environnement, vous pourrez repartir des différences constatées au lieu de devoir reconstituer l’état actuel.

Questions fréquentes