Pourquoi un scan de ports change lorsqu’il est lancé avec sudo

Nmap n’envoie pas toujours le paquet que vous croyez avoir demandé. Quand les sockets raw ne sont pas disponibles, il remplace le scan SYN par défaut par un scan TCP connect, si bien qu’une exécution en tant qu’utilisateur ordinaire et une exécution sous sudo peuvent répondre à des questions différentes sur le même port. Les résultats ressemblent à un problème de privilèges, et ce sont généralement un changement de méthode. Rendre la méthode explicite est le seul moyen de comparer les deux exécutions.

Deux sondes, un port, des chemins de code différents

Un scan SYN construit lui-même l’en-tête TCP, l’envoie depuis un socket raw et lit la réponse sur le réseau avant que la pile TCP du noyau n’enregistre jamais une connexion établie. Un scan connect demande au système d’exploitation d’ouvrir un socket ordinaire et rapporte ce que connect() renvoie. Les deux peuvent qualifier un port d’ouvert, mais un seul laisse une tentative à demi ouverte et un seul est soumis à une politique au niveau du socket liée au processus émetteur.

Le chemin raw exige CAP_NET_RAW, ce qui explique pourquoi le scan par défaut se dégrade silencieusement quand cette capacité manque. La référence des techniques de scan de Nmap documente la substitution : le scan connect est le repli parce qu’il ne nécessite aucun privilège particulier. La substitution se produit sans avertissement dans la plupart des exécutions, et c’est ce qui la rend si facile à mal lire. Une fois que l’on sait que le repli existe, « ouvert en root, fermé en utilisateur » cesse de ressembler à un bug de permissions et commence à ressembler à deux mesures différentes.

Ce que sudo change réellement dans le scan

Élever les privilèges restaure le chemin du socket raw, et cela change plus que le verdict. Le choix du port source, le timing des paquets, le comportement de retransmission et la façon dont une réponse filtrée est classée viennent tous d’un code différent. Un équipement intermédiaire qui limite le débit des SYN traite les deux exécutions de manière inégale même lorsque l’hôte de destination est identique.

La journalisation côté destination diverge aussi. Une poignée de main terminée est visible pour le service et pour toute comptabilité de sockets, alors qu’une sonde à demi ouverte réinitialisée ne l’est souvent pas. Si vous comparez des exécutions vers un hôte dont vous lisez aussi les journaux, une partie de la différence observée est l’observation elle-même.

Gardez la méthode constante dans les deux exécutions

Forcez la même technique dans les deux appels et la comparaison commence à signifier quelque chose. L’indicateur -sT demande explicitement un scan connect, -Pn supprime la découverte d’hôtes, -n supprime la résolution de noms, et un seul -p supprime les différences de liste de ports.

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

Remplacez l’adresse et le port par un hôte que vous êtes autorisé à tester ; la plage de documentation ci-dessus est un exemple, pas une cible. Si les deux exécutions concordent maintenant, la différence initiale venait de la méthode de scan. Si elles divergent encore, autre chose classe le trafic, et la section suivante indique où regarder.

Le contexte du compte n’est pas qu’un indicateur de privilèges

Un déploiement VPN peut classer les paquets par UID, par cgroup ou par une règle liée au processus qui a ouvert le socket. Le trafic root et le trafic utilisateur sortent alors par des tables de routage différentes ou rencontrent des jeux de règles différents, et aucune discipline de méthode de scan ne les réconcilie.

Inspectez la politique plutôt que le privilège. Sous Linux, nftables l’exprime avec meta skuid et iptables avec la correspondance de propriétaire, et l’un ou l’autre peut envoyer un seul UID dans un tunnel pendant que l’autre continue d’utiliser la route physique par défaut.

sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77

Confirmez la sonde avant de comparer les résultats

Avant de conclure, prouvez quelle sonde a été exécutée. Nmap nomme la technique dans sa propre sortie, et --reason ajoute la preuve derrière chaque état, ce qui est la partie qui vous dit si une poignée de main s’est réellement terminée.

nmap --reason -sT -Pn -n -p 8443 198.51.100.77
sudo nmap --reason -sS -Pn -n -p 8443 198.51.100.77
getcap "$(command -v nmap)"
capsh --print | grep -i net_raw

Deux exécutions qui rapportent le même état pour des raisons différentes ne sont pas une contradiction, et deux exécutions qui rapportent des états différents pour la même raison pointent vers le routage ou la politique plutôt que vers le scan. Gardez la destination, le port, l’espace de noms et le timing identiques, puis changez une variable à la fois. Exécuter le service en root n’est pas la réparation d’une inadéquation de politique ; l’exprimer par le propriétaire du service l’est.