Choisir les méthodes d'authentification SOCKS5 dans Dante

Avec SOCKS5, l'authentification est négociée avant que le client envoie sa demande de destination. Cela fait d'un échec précoce des identifiants un événement différent d'un échec FTP, HTTPS ou d'une autre application au-delà du proxy.

Le message d'accueil du client énumère les méthodes d'authentification qu'il prend en charge. Le serveur choisit une méthode dans cette liste et renvoie la sélection. Une valeur 0xff signifie qu'aucune méthode proposée n'est acceptable et que la connexion doit être fermée. Le client n'essaie pas simplement toutes les méthodes côté serveur après l'échec d'un mot de passe.

Ce que contrôle l'ordre dans Dante

Dante 1.4.x nomme le réglage au niveau du protocole socksmethod. Sa documentation indique que les méthodes sont listées par ordre de préférence. Pour une politique qui autorise les deux méthodes, cette déclaration préfère le nom d'utilisateur/mot de passe lorsque le client le propose :

socksmethod: username none

Inverser la liste préfère l'accès non authentifié lorsque les deux méthodes sont proposées :

socksmethod: none username

Ce sont des déclarations de méthodes alternatives, pas des configurations complètes de serveur. Les interfaces d'écoute, les clients autorisés, les règles de destination et toute contrainte d'authentification propre à une règle comptent toujours.

Autoriser none a une conséquence concrète : un client qui ne propose que l'absence d'authentification peut être accepté selon les règles applicables. Placer username en premier ne transforme pas une liste contenant none en obligation pour tous de fournir un mot de passe.

Choisissez d'abord l'exigence

Si chaque client autorisé doit s'authentifier par nom d'utilisateur/mot de passe, configurez cette exigence de manière cohérente dans les règles globales et applicables au lieu d'ajouter none comme correctif de compatibilité général. Si l'accès anonyme est intentionnel pour un groupe restreint de clients, rendez le groupe et ses destinations autorisées explicites.

Dante dispose aussi de clientmethod, qui concerne les contrôles effectués lorsque le client TCP se connecte, avant la négociation SOCKS. C'est une couche distincte des méthodes échangées dans le message d'accueil SOCKS5. Les extraits de configuration utilisant un mot-clé method plus ancien doivent être lus à la lumière du manuel de la version de Dante installée.

Lorsque deux clients se comportent différemment, comparez ce que chacun propose, ce que Dante sélectionne et si la sous-négociation de la méthode choisie réussit. Inspectez ensuite la réponse de destination SOCKS. Cette séquence identifie un rappel d'identifiants manquant sans attribuer chaque échec à FTP ni modifier aveuglément la politique d'authentification du serveur.

Enfin, l'authentification par nom d'utilisateur/mot de passe de SOCKS5 ne chiffre pas l'échange du mot de passe. Utilisez un transport ou un réseau protégé de manière appropriée lorsque ces identifiants exigent la confidentialité.