Nessus derrière un VPN : où placer le scanner avant le premier scan

Une icône VPN à côté du navigateur ne dit rien du processus qui envoie les paquets de scan. Si la console et le scanner tournent sur des hôtes différents, le tunnel du navigateur est un chemin et la source du scan en est un autre. Commencez par le point d’exécution, puis remontez vers la route, l’autorisation et les identifiants. Cette distinction figure en première position de la liste pour une bonne raison.

Il s’agit d’une liste de contrôle avant lancement, pas d’un tutoriel de scan. Chaque étape produit un fait que vous pouvez consigner dans le dossier de mission avant qu’un paquet ne quitte le scanner.

Point un : localiser le processus qui envoie les sondes

Dessinez explicitement les trois rôles : le navigateur sur l’ordinateur portable A, la console de scan sur l’hôte B et la cible privée C. Si B exécute aussi le moteur de scan, le navigateur n’a besoin que d’un chemin vers B. Si une appliance de scan distincte fait le travail, cette appliance a besoin du chemin vers C.

Browser on laptop A -> console on host B
Scanner process on B (or another appliance) -> private target C

Un navigateur connecté au VPN peut atteindre la console alors que le scanner derrière lui n’a toujours aucune route vers C. L’inverse est possible aussi : le scanner est dans le réseau privé et la console est distante. Découvrez quelle configuration vous exploitez réellement avant de modifier un contrôle réseau. Nommez l’appliance dans la configuration du scan avant d’accuser le réseau.

Si le scanner tourne sur A, l’hôte du navigateur et le scanner partagent un contexte, mais seulement tant que ce processus conserve le même espace de noms et la même table de routage. Un conteneur ou un compte de service peut ne pas hériter de ce que voit le navigateur interactif. La console est une surface d’administration, pas le moteur de scan.

Point deux : prouver la route et le DNS du scanner

Exécutez la vérification de route sur l’hôte du scanner, pas sur l’ordinateur portable. Demandez au noyau quelle interface et quelle passerelle il utiliserait pour l’adresse cible, puis répétez pour le nom d’hôte de la cible. Une route qui existe pour l’IP et un nom qui résout vers une autre adresse sont deux pannes différentes.

Confirmez l’adresse source qui apparaîtra à la cible. Un client VPN peut attribuer une adresse différente de celle qu’attend le pare-feu de la cible, et un dispositif NAT peut la réécrire à nouveau. Le propriétaire de la cible a besoin de la source observée, pas de l’adresse imprimée dans le profil VPN.

Vérifiez aussi le chemin de retour. Un scanner qui atteint la cible mais ne reçoit aucune réponse a un problème de routage ou de pare-feu sur le retour, et cela ressemble exactement à une cible hors service.

Point trois : faire autoriser le périmètre et le point de vue

Demandez au propriétaire de la cible de nommer par écrit les systèmes, les services, l’environnement, la source et la fenêtre temporelle. Décidez quel point de vue l’évaluation représente : un utilisateur VPN externe, un client interne admis ou un segment de scanner précis.

Une route privée n’est pas une autorisation de tester les réseaux adjacents. Gardez la liste des cibles étroite, énumérez les systèmes exclus et convenez de conditions d’arrêt et d’un contact capable d’interrompre l’exécution. Le scanner sondera volontiers tout ce qu’il peut atteindre, et c’est précisément pourquoi le périmètre doit être explicite.

Consignez la source approuvée dans le même document. Si la source observée du scanner diffère de celle qui a été approuvée, l’exécution ne représente pas le point de vue convenu, même lorsque la liste des cibles est correcte.

Point quatre : adapter les identifiants à la profondeur de l’évaluation

Une vérification d’accessibilité et une évaluation authentifiée sont des tests différents. Une réponse de port prouve que quelque chose a répondu ; elle ne prouve pas que des contrôles authentifiés ont été exécutés ni que l’application a autorisé le compte.

N’utilisez des identifiants dédiés que lorsque le périmètre convenu exige des contrôles authentifiés. Confirmez les autorisations et la politique de verrouillage du compte, et décidez comment les constats seront stockés et partagés avant que le scan ne les produise.

Si les identifiants échouent, ne basculez pas silencieusement vers une exécution non authentifiée et n’étiquetez pas le rapport comme l’évaluation prévue. Le résultat est un test différent avec une signification différente, et cette différence doit figurer dans le rapport.

Point cinq : enregistrer le plan, puis lancer délibérément

Dans le flux de travail des scans Nessus, choisir un modèle, configurer les paramètres et enregistrer ou lancer le scan sont des étapes distinctes. Servez-vous de cette séparation pour revoir la liste des cibles, la source et la planification avant que tout trafic ne démarre.

Avant d’autoriser le lancement, vérifiez quelle source le VPN autorise, quel trafic il transporte et comment il récupère après la chute d’un tunnel. N’élargissez pas l’accès au pare-feu simplement parce qu’une connexion préliminaire a échoué ; trouvez la couche qui l’a refusée et corrigez cette couche.

Après l’exécution, consignez l’hôte du scanner, sa source observée, la liste des cibles et tout contrôle qui n’a pas pu aboutir. Un rapport produit depuis une autre source ou sans les identifiants prévus ne représente pas le plan d’origine, et le dire fait partie du livrable.

Retirez les accès de mission et traitez les résultats conservés selon le processus convenu. La liste de contrôle n’est terminée que lorsque les preuves correspondent au chemin que vous avez approuvé, pas lorsque le scan a simplement renvoyé des résultats.