Obscurer le mot de passe du proxy réseau dans des fichiers texte en clair sur Linux / UNIX-like

Généralement, dans un grand réseau, un ordinateur doit fonctionner derrière un proxy authentifié – toute connexion au monde extérieur nécessite un nom d’utilisateur / mot de passe, souvent le mot de passe qu’un utilisateur utilise pour se connecter au courrier électronique, au poste de travail, etc.

Cela signifie que vous apt.conf mettre le mot de passe du réseau dans le fichier apt.conf , ainsi que les variables d’environnement http_proxy, ftp_proxy et https_proxy définies dans ~/.profile

Je me rends compte qu’avec apt.conf , vous pouvez définir chmod 600 (ce qui n’est pas par défaut sur Ubuntu / Debian!) Mais sur notre système, il y a des personnes qui ont besoin de privilèges root.

Je me rends également compte qu’il est techniquement impossible de sécuriser un mot de passe de quelqu’un qui a un access root, mais je me demandais s’il y avait un moyen de masquer le mot de passe pour empêcher une découverte accidentelle. Windows fonctionne avec les utilisateurs en tant qu’administrateurs, mais stocke en quelque sorte les mots de passe réseau (probablement stockés profondément dans le registre, de quelque manière que ce soit), de sorte que vous ne les rencontrerez pas en texte clair

Je ne demande que depuis l’autre jour, j’ai tout à fait découvert par hasard quelqu’un de cette manière lors de la comparaison de fichiers de configuration entre systèmes.

@monjardin – L’authentification par clé publique n’est pas une alternative sur ce réseau. De plus, je doute que cela soit supporté par la majorité des outils en ligne de commande.

@Neall – Cela ne me dérange pas que les autres utilisateurs aient access au Web, ils peuvent utiliser mes identifiants pour accéder au Web, mais je ne veux tout simplement pas qu’ils surviennent avec mon mot de passe en texte brut.

Avec l’approche suivante, vous ne devez jamais enregistrer votre mot de passe proxy en texte brut. Il vous suffit de saisir un mot de passe de manière interactive dès que vous avez besoin d’un access http / https / ftp:

  • Utilisez openssl pour chiffrer votre mot de passe proxy en texte brut dans un fichier, avec par exemple le chiffrement AES256:

openssl enc -aes-256-cbc -in pw.txt -out pw.bin

  • Utilisez un mot de passe (différent) pour protéger le fichier encodé
  • Supprimer le texte brut pw.txt
  • Créez un alias par exemple ~ / .alias pour définir vos variables d’environnement http_proxy / https_proxy / ftp_proxy (définissez les valeurs appropriées pour $ USER / proxy / $ PORT)

alias myproxy = ‘PW = `openssl aes-256-cbc -d -in pw.bin`; PROXY = “http: // $ USER: $ PW @ proxy: $ PORT”; export http_proxy = $ PROXY; exporter https_proxy = $ PROXY; exportation ftp_proxy = $ PROXY ‘

  • vous devriez trouver ce fichier dans votre environnement shell normal (sur certains systèmes, cela se fait automatiquement)
  • tapez «myproxy» et entrez votre mot de passe openssl que vous avez utilisé pour chiffrer le fichier
  • terminé.

Remarque: le mot de passe est disponible (et lisible) dans l’environnement utilisateur pendant toute la durée de la session shell. Si vous souhaitez le nettoyer de l’environnement après utilisation, vous pouvez utiliser un autre alias:

alias clearproxy = ‘export http_proxy =; exporter https_proxy =; exportation ftp_proxy = ‘

Préférez les applications qui s’intègrent à Gnome Keyring . Une autre possibilité consiste à utiliser un tunnel SSH sur une machine externe et à exécuter des applications via celui-ci. Jetez un coup d’œil à l’option -D pour créer une interface proxy SOCKS locale, au lieu de -L unique vers l’avant.

Il existe de nombreuses manières de masquer un mot de passe: vous pouvez stocker les informations d’identification au format rot13 ou BASE64 ou utiliser le même algorithme de brouillage de mot de passe que CVS utilise. Le vrai truc, cependant, est de rendre vos applications conscientes de l’algorithme de brouillage.

Pour les variables d’environnement de ~/.profile vous pouvez les stocker puis les décoder avant de définir les variables, par exemple:

 encodedcreds="sbbone:cnffjbeq" creds=`echo "$encodedcreds" | tr n-za-mN-ZA-M a-zA-Z` 

Cela va définir creds sur foobar:password , que vous pouvez ensuite incorporer dans http_proxy etc.

Je suppose que vous le savez, mais il convient de le répéter: cela n’ajoute aucune sécurité. Il protège simplement contre la consultation par inadvertance du mot de passe d’un autre utilisateur.

J’ai fait une solution modifiée:

éditez /etc/bash.bashrc et ajoutez les lignes suivantes:

 alias myproxy='read -p "Username: " USER;read -s -p "Password: " PW PROXY="$USER:[email protected]:80"; export http_proxy=http://$PROXY;export Proxy=$http_proxy;export https_proxy=https://$PROXY;export ftp_proxy=ftp://$PROXY' 

A partir de la prochaine connexion, entrez myproxy et entrez votre combinaison utilisateur / mot de passe! Maintenant, travaillez avec sudo -E

-E, –preserve-env Indique à la politique de sécurité que l’utilisateur souhaite réserver ses variables d’environnement existantes.

eg sudo -E apt-get update

Remarque: les parameters de proxy ne sont valides que pendant la session shell

À moins que les outils spécifiques que vous utilisez n’autorisent un format obscurci, ou que vous puissiez créer une sorte de workflow pour passer du format obscur au format simple à la demande, vous n’avez probablement pas de chance.

Une chose que j’ai vue dans des cas comme celui-ci est la création d’informations d’identification dédiées par serveur, par utilisateur ou par serveur / par utilisateur, qui n’ont access qu’au proxy à partir d’une adresse IP spécifique. Cela ne résout pas votre problème de base d’obfuscation, mais cela atténue les effets de la consultation du mot de passe par une personne qui en vaut si peu.

En ce qui concerne cette dernière option, nous avons créé un encodage de mot de passe “reverse crypt” au travail que nous utilisons pour des choses comme ça. Il n’y a que l’obscurcissement car toutes les données nécessaires au décodage du fichier pw sont stockées dans la chaîne codée, mais empêchent les utilisateurs de voir accidentellement des mots de passe en clair. Vous pouvez, par exemple, stocker l’un des mots de passe ci-dessus dans ce format, puis écrire un wrapper pour apt qui construit apt.conf de manière dynamic, appelle le apt réel et à la sortie supprime apt.conf. Vous vous retrouvez toujours avec le pw en texte brut pendant un petit moment, mais cela minimise la fenêtre.

L’authentification par clé publique est-elle une alternative valable pour vous?

Tant que ces trois choses sont vraies, vous n’avez pas de chance:

  1. Le serveur a besoin d’un access Web
  2. Les utilisateurs ont besoin d’un contrôle absolu sur le serveur (root)
  3. Vous ne voulez pas que les utilisateurs aient un access Web au serveur

Si vous ne pouvez pas supprimer # 2 ou # 3, votre seul choix est de supprimer # 1. Configurez un serveur interne qui héberge toutes les mises à jour logicielles. Gardez celui-ci bloqué par vos autres utilisateurs et ne permettez pas aux autres serveurs d’avoir access au Web.

Tout ce que vous essayez de faire est de vous tromper.

Nous avons résolu ce problème en ne demandant pas de mots de passe proxy sur rpm, apt ou autres mises à jour similaires (bases de données de virus, éléments Windows, etc.). Une petite liste blanche de référentiels connus à append au proxy.

Je suppose que vous pourriez créer un proxy local, pointer ces outils à travers cela, puis demander au proxy local de demander interactivement à l’utilisateur le mot de passe proxy externe qu’il appliquerait ensuite. Il pourrait éventuellement s’en souvenir pendant quelques minutes dans un stockage interne obscurci.

Un vecteur d’attaque évident serait qu’un utilisateur privilégié modifie ce proxy local pour faire autre chose avec le mot de passe saisi (comme il pourrait le faire avec n’importe quel autre client de messagerie qui le demande ou le système de fenêtrage lui-même). d être à l’abri de la visualisation par inadvertance.