Quel processus VPN cette découverte de vulnérabilité concerne-t-elle ?

Le résultat d’un scanner nomme une adresse, un port et quelque chose qui y a été négocié. Il ne nomme pas le processus derrière cette socket, et sur un hôte VPN plusieurs processus peuvent partager la machine alors qu’un seul d’entre eux est le tunnel. Lire une chaîne de version dans un utilitaire annexe ou trouver un fichier de bibliothèque sur le disque ajoute des preuves sur l’hôte, pas sur l’écouteur. La découverte ne devient exploitable que lorsqu’elle est rattachée à un composant en cours d’exécution, puis confrontée à la portée qu’un avis énonce réellement.

L’ordre compte : le composant d’abord, l’avis ensuite, la remédiation en dernier.

Le rapport nomme un port, pas un programme

Partez du point de terminaison réellement évalué. Une sonde sur le port d’administration HTTPS a mesuré le service web, sa pile TLS et le proxy qui le précède ; elle n’a rien appris de l’écouteur OpenVPN ou WireGuard sur un autre port. Les proxys inverses et les agents de gestion aggravent la situation, car le certificat et la bannière peuvent appartenir au frontal tandis que la bibliothèque vulnérable se trouve derrière, dans un processus backend.

Consignez la destination, le transport, le port et le nom du service avec le résultat, afin que la portée voyage avec la découverte.

Ce qu’est réellement la version en cours d’exécution

Sur un hôte polyvalent, le paquet installé et la bibliothèque chargée sont deux questions distinctes. Une base de paquets peut lister une version corrigée alors qu’un démon de longue date détient encore l’ancien objet partagé en mémoire, et une image d’appliance intégrée peut embarquer ses propres bibliothèques qu’aucun gestionnaire de paquets ne signale. Demandez au gestionnaire de services ce qui tourne, puis inspectez le processus et ses liaisons.

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

L’heure de démarrage dans la liste des processus est le détail que l’on saute. Un démon lancé avant la dernière mise à jour de paquets exécute encore la version chargée au démarrage, et c’est exactement le cas où un inventaire dit corrigé et où la socket dit le contraire.

Faire correspondre la version à la portée d’un avis

Les avis décrivent des produits, des versions et parfois des conditions requises, et ces trois champs ne s’alignent pas toujours sur la version d’un paquet. L’avis Heartbleed d’OpenVPN d’avril 2014 est un exemple historique utile, car il sépare les versions d’Access Server touchées des services web et des démons VPN, qui avaient une exposition différente. La leçon est de lire quel composant le texte couvre plutôt que de faire correspondre le mot OpenSSL par motif.

Cet avis est aussi daté. Ses numéros de version corrigés ne sont plus un conseil d’installation, et une faille corrigée en 2014 ne dit rien des problèmes ultérieurs dans la branche que vous exploitez aujourd’hui.

Résoudre le désaccord, puis fermer l’exposition

Lorsque l’inventaire et l’évaluation divergent, vérifiez si les deux décrivent le même point de terminaison et le même environnement d’exécution : une autre adresse, un proxy frontal, un second service, un ancien processus encore lié au port ou une bibliothèque intégrée que le gestionnaire de paquets n’a jamais vue. Réglez cela à la frontière avant de réécrire un rapport.

Appliquez la correction prise en charge, redémarrez le service concerné et confirmez que la nouvelle version est bien celle qui tourne maintenant. Un fichier corrigé sur le disque alors que l’ancien processus sert encore le trafic n’est pas une remédiation.

Traitez ensuite ce que le composant a pu contenir pendant la fenêtre d’exposition. Le correctif et le remplacement des identifiants répondent à des questions différentes, et un certificat stocké près de l’hôte touché n’est pas en soi la liste de ce qui a fuité. Suivez la procédure du responsable de l’incident pour la révocation, la suppression de sessions et la mise à jour des clients, et consignez quel composant a été touché, pourquoi les preuves s’appliquaient et ce qui a clos le dossier. C’est cette trace qu’une revue ultérieure lira.