Votre passerelle VPN est compromise : ce qui est réellement exposé

Une passerelle VPN se situe à l’extrémité du tunnel qu’elle protège, ce qui signifie qu’elle termine ce chiffrement au lieu de le laisser passer. Si un attaquant contrôle l’hôte, le tunnel continue de paraître sain de l’extérieur tandis que la machine au milieu n’est plus digne de confiance. La question utile n’est pas de savoir si tout est déchiffré. Elle est de savoir ce que cet hôte pouvait voir, jusqu’où il pouvait atteindre et quels secrets y étaient réellement stockés. Ces trois réponses diffèrent beaucoup, et la réponse diffère avec elles.

La passerelle termine le tunnel, donc elle voit à l’intérieur

Le chiffrement dans un VPN se fait de saut en saut, et la passerelle est le saut. Elle retire la couche externe, applique la politique et transmet le paquet interne, si bien que chaque paquet transporté existe à un moment donné sous forme lisible dans la mémoire de cet hôte. C’est la conception et non un défaut. C’est aussi pourquoi la compromission de la passerelle est un événement différent de la compromission de la cryptographie du tunnel.

Ce que l’attaquant gagne d’abord, c’est une position : la capacité d’observer le trafic transporté, de modifier le transfert ou de répondre à la place d’un backend. Ce qu’il gagne ensuite dépend de l’hôte, et c’est là que les gens surestiment. L’accès à la passerelle seul ne livre pas les clés de session TLS d’un navigateur, car elles n’ont jamais été sur la passerelle.

Trois expositions qui n’ont pas la même taille

Séparez la question en trafic transporté, systèmes joignables et secrets stockés, puis répondez à chacune séparément.

La ligne du milieu est celle que l’on saute. Une passerelle dispose généralement d’une route vers des réseaux privés et d’une adresse source à laquelle les backends font déjà confiance, donc la question intéressante est ce que ces backends autorisent depuis cette adresse. Une politique d’accès client étroite est un bon contrôle, mais un attaquant sur l’hôte n’est pas limité à l’interface qu’utiliserait un client normal.

La ligne du bas décide de la durée de l’incident. Une clé de serveur et une clé de CA ont des rayons d’action complètement différents, tout comme un compte administrateur local et un jeton de supervision en lecture seule.

HTTPS dans le tunnel reste HTTPS

Le TLS de l’application se termine dans l’application, pas à la passerelle VPN, donc une passerelle compromise observe du texte chiffré pour ces flux. C’est une limite réelle à ce que l’attaquant obtient, et il vaut la peine de le dire clairement, car l’affirmation inverse répand la panique et de mauvaises décisions. Deux conditions la brisent. Si un composant d’inspection doté d’un certificat de confiance se trouve sur le chemin, la passerelle peut voir du texte en clair par conception. Si le point de terminaison de l’application lui-même est compromis, le tunnel est sans importance.

La réponse à ce qu’ils ont vu est donc conditionnelle, et elle devrait être consignée sous forme de conditions plutôt qu’annoncée comme un verdict.

Ce qui doit changer avant de lui refaire confiance

Reconstruire l’hôte est nécessaire et rarement suffisant. Un attaquant qui détient encore un compte d’administration, un identifiant de déploiement ou une clé de signature peut remettre l’hôte dans l’état qu’il souhaite. La reprise doit partir d’un chemin d’administration qui ne dépend pas de la machine compromise.

Inventoriez ce qui s’y trouvait avant de décider quoi faire tourner. Clés, comptes de service, jetons d’API, utilisateurs locaux, tâches planifiées, relations de confiance et pipeline de déploiement sont tous candidats, et chacun a un propriétaire qui devrait le confirmer.

ss -lntup
getent passwd
crontab -l
ip route show table all

Cette liste est le moyen le plus rapide de voir ce que l’hôte offrait et jusqu’où il pouvait atteindre. Préservez d’abord les preuves, selon le processus du responsable de la réponse, car une reconstruction détruit exactement ce dont une enquête a besoin. NIST SP 800-61 Révision 3 traite la préparation, la détection, la réponse et la reprise comme des parties d’un seul processus de risque, et non comme une consigne de redémarrage.

Des frontières qui rendent la suivante moins coûteuse

Quatre frontières valent la peine d’être construites avant d’en avoir besoin. Gardez un chemin de reprise indépendant qui ne s’authentifie pas via la passerelle. Gardez l’autorité de signature séparée de l’hôte qui sert le trafic. Limitez jusqu’où la passerelle peut atteindre, afin qu’une passerelle compromise ne soit pas automatiquement un réseau d’administration compromis. Et consignez à qui appartient chaque identifiant, afin que la rotation soit un appel téléphonique plutôt qu’un projet d’archéologie.

Aucune de ces mesures n’empêche la compromission. Elles la bornent et font la différence entre une mauvaise semaine et un mauvais trimestre.