Ajouter une authentification par nom d’utilisateur à Dante

Passez d’un accès SOCKS fondé uniquement sur la source à une vérification explicite du compte dans Dante 1.4.4, tout en conservant les restrictions de source et de destination.

Dans Dante 1.4.4, les règles client acceptent la connexion avant la négociation SOCKS, tandis que les règles SOCKS décident quelles requêtes authentifiées peuvent poursuivre. Une connexion provenant d’une source autorisée peut donc encore exiger un nom d’utilisateur à la seconde étape.

Pour une authentification avec les utilisateurs du système d’exploitation, examinez les identités du service ainsi que la méthode. La lecture de la base des comptes peut nécessiter une identité privilégiée :

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

Utilisez le véritable compte de service à faibles privilèges installé pour Dante. Créez ou choisissez un compte client autorisé compatible avec le mécanisme d’authentification par nom d’utilisateur ; l’identité du service et la connexion du client ont des rôles distincts.

Conserver les limites des requêtes

Après la règle client restrictive existante, exigez le compte sur la route SOCKS autorisée :

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

Les adresses et le nom du compte sont des exemples. Cela autorise une source, une destination, une commande et l’utilisateur authentifié indiqué. Ne remplacez pas cette limite par des sources sans restriction sous prétexte qu’un mot de passe a été ajouté.

Les paramètres de méthode globaux et ceux de la règle doivent concorder. Recherchez une ancienne règle n’autorisant que none, héritée d’une configuration limitée au contrôle de la source. Conservez aussi les restrictions prévues du point d’écoute et du pare-feu.

Tester séparément la négociation et l’accès

Avant de démarrer le serveur, vérifiez le fichier avec le mode de contrôle de configuration de la version installée. Utilisez ensuite un client autorisé qui prend réellement en charge la négociation SOCKS5 par nom d’utilisateur et mot de passe. Testez l’absence d’identifiants, des identifiants incorrects et un compte autorisé demandant une cible interdite.

La sous-négociation par nom d’utilisateur et mot de passe définie dans la RFC 1929 ne chiffre pas le mot de passe. Une session HTTPS ultérieure avec la destination ne protège pas cet échange préalable avec le proxy. Utilisez un trajet convenablement protégé entre client et serveur.

Un contrôle de configuration réussi confirme la syntaxe et les identités, pas la base des comptes ni le chemin réseau. Consultez les journaux du serveur pour savoir à quelle étape un test réel a été rejeté.

Articles similaires