ike-scan ne reçoit aucune réponse d’une passerelle IPsec en fonctionnement

La passerelle sert des téléphones et des ordinateurs portables chaque jour, et pourtant ike-scan signale qu’aucun hôte n’a répondu. Cette sortie ressemble à la preuve qu’IPsec manque sur l’appareil. Habituellement, cela signifie que l’appareil a écarté chaque proposition de la sonde et a choisi de ne rien répondre. Le silence est une réponse, et c’est la moins informative que l’outil puisse vous donner.

Traitez trois questions distinctes : le paquet est-il arrivé, une proposition a-t-elle correspondu, et autre chose a-t-il refusé le pair ?

Étape 1 : lire la proposition que l’outil envoie

Le mode principal commence par une charge SA qui énumère les transformations que l’initiateur acceptera, et ike-scan remplit cette liste à partir d’un jeu par défaut compilé. Le jeu par défaut est délibérément ancien : DES et 3DES pour le chiffrement, MD5 et SHA1 pour le hachage, les groupes 1 et 2 pour l’échange de clés, des clés prépartagées pour l’authentification. Pas d’AES, pas de SHA-2, pas de groupe 14. Une passerelle configurée pour AES-256 avec SHA-256 et modp2048 ne partage rien avec cela.

Certaines implémentations répondent à une sonde non concordante par une notification NO-PROPOSAL-CHOSEN. D’autres la rejettent simplement, ce qui est courant sur les équipements qui traitent les pairs inconnus comme du bruit. Quoi qu’il en soit, le scan n’imprime rien, et ce rien est identique à ce que donne à voir un UDP 500 filtré de l’extérieur, comme la documentation du projet ike-scan le précise pour le jeu par défaut.

Étape 2 : proposer une proposition moderne

Remplacez le jeu par défaut par --trans. La forme attributaire reprend directement les numéros d’attribut IKE : 1 pour le chiffrement, 2 pour le hachage, 3 pour l’authentification, 4 pour le groupe, et 14 pour la longueur de clé quand l’algorithme en accepte une. Ce qui sort est une ligne que vous pouvez lire à voix haute en revue de changement.

La forme positionnelle porte les mêmes valeurs dans l’ordre et évite les crochets, ce qui compte une fois que la commande passe par un shell.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

Une proposition par paquet est lent quand vous énumérez, alors parcourez les valeurs plausibles : chiffrement 5, 7/128, 7/192, 7/256 ; hachage 1, 2, 5, 6, 7 ; groupes 1, 2, 5, 14, 15, 19, 20, 21 ; authentification 1 pour une clé prépartagée et 3 pour les signatures RSA. Imprimez chaque commande avant de l’exécuter pour que la transcription montre ce qui a été proposé et dans quel ordre.

Étape 3 : interpréter une réponse

Une réponse prouve exactement deux choses : un répondeur IKE est joignable à cette adresse, et une proposition offerte était acceptable. Elle ne dit rien de la clé prépartagée, de la couche L2TP, ni de l’existence d’un compte utilisateur. Un scan réussi est entièrement compatible avec l’échec de toute étape ultérieure.

Sur une passerelle que vous exploitez, c’est la partie réellement utile. Le scan vous dit quelles propositions l’appareil accepte encore, et un résultat limité à des transformations anciennes est un constat sur la politique de l’appareil, non une raison d’affaiblir le client.

Étape 4 : interpréter le silence

Le silence est une preuve plus faible qu’il n’y paraît. Chaque proposition a peut-être été rejetée, UDP 500 et 4500 sont peut-être filtrés, la source est peut-être limitée en débit après une rafale, ou le service écoute peut-être à une autre adresse que celle que vous avez scannée. Comparez le journal IKE de la passerelle à un client qui se connecte déjà avec des identifiants valides avant de conclure quoi que ce soit sur la boîte.

Le comportement en rafale appartient à cette liste, car l’énumération génère beaucoup de paquets en peu de temps. Une passerelle qui répond aux premières tentatives puis se tait décrit sa politique anti-DoS plutôt que son jeu de propositions.

Étape 5 : consigner ce que vous avez prouvé

Écrivez la combinaison acceptée à côté de la version du micrologiciel, puis comparez-la aux transformations que les clients qui vous importent offrent par défaut. L’écart entre ces deux listes est le problème de configuration, et le scan n’a fait que le rendre visible. Si les seules propositions acceptées sont celles que vous ne choisiriez pas, le correctif relève de la politique de la passerelle ou d’un profil client, jamais de la sonde.

Une sonde qui n’a jamais répondu a tout de même répondu quelque chose : elle montre quelles propositions cet appareil accepte de discuter et lesquelles il préférerait laisser tomber.