De la bonne pratique de protéger vos scripts et mots de passe

[lol]

Salut,

Comment faites vous pour protéger vos scripts, et protégez les mots de passes que vous devez utiliser dans ces scripts ?

Jusqu’à présent j'utilisais shc de Francisco Javier Rosales García, mais ce n'est pas tout à fait la panacée étant donné qu'il est possible de récupérer le script en clair via un "segmentation fault".

Comment pratiquez vous, quels conseils peut-on donner pour protéger le contenu de ses scripts, comment gérer dans les scripts les mots de passe dont on a nécessairement besoin ?

Ne pas mettre les mots de passe en clair dans les scripts ?
Placer les mots de passe dans des fichiers placés en dehors des répertoires accessibles ?
Utiliser un système de cryptage des mots de passe (comment faites-vous) ?
S'assurer que les droits sur les fichiers ne soient pas trop permissifs ?

[piratebab]

On ne doit normalement stocker que des hash de mots de passe, mais si je comprends ton problème, tu doit remplacer le MDP que saisi normalement l'utilisateur au clavier.
Donc quoi que tu fasses, le MDP transitera en clair entre le client et le serveur.
Pour éviter cela, il faut que le client et le serveur échange des clefs au préalable.
Regarde par exemple le mécanisme utilisé par les clients ssh, et utilise le entre ton script (le client) et ton serveur de MDP.

[Dunatotatos]

Hum, peut-être que je comprends ;al la question, ou la réponse. Mais je crois que tu ne réponds pas à la question de lol. Stocker des hashs de mots de passe, c'est bien quand tu veux vérifier la validité d'un mot de passe. Mais comment faire pour qu'un script client connaisse le mot de passe à envoyer au serveur ?

Il y a un système que j'aime bien chez Django. Tu as une clef secrète unique pour tout ton projet. Les mots de passe sont chiffrés grâce à cette clef secrète.
Évidemment, quand c'est possible, les paires de clefs sont toujours plus maniables.

[piratebab]

je propose un serveur de mot de passes. Mais au final, il faut une clef coté client (le script), donc ça ne résoud pas complétement le problème initial.

[lol]

Salut,
Oui, la question sous-jacente, c'est comment utiliser un mot de passe dans un script.
De sauvegarde par exemple :DUMP SQL et Transfert FTP.
Dans les deux cas ci-dessus dump et envoie FTP distant, il faut s'identifier par mot de passe.

Il doit bien y avoir une "bonne" pratique pour faire ça.
Le mieux que je vois, c'est stocker un mdp crypté dans un fichier situé dans un répertoire normalement protégé (/root par exemple) et aller le chercher avec un script qui le décryptera à la volée.

[BelZéButh]

Salut,

comment gérer dans les scripts les mots de passe dont on a nécessairement besoin ?

Pourquoi faudrait-il joindre un mdp dans un script ?
À mes yeux, c'est une faille non négligeable.

la question sous-jacente, c'est comment utiliser un mot de passe dans un script.
De sauvegarde par exemple :DUMP SQL et Transfert FTP.
Dans les deux cas ci-dessus dump et envoie FTP distant, il faut s'identifier par mot de passe.

Cela sous-entend des tâches cron¹, non ?
Sachant que rsync et ssh sont indissociables.
rsync est un très bon commercial, il fait dans l'import-export, une partition, un répertoire ou un simple fichier.

De fait¹, ces scripts sont exécutables sur la machine distante.
Ces crons terminés.
Nous importerons (depuis local) ou exporterons (depuis distant) le² répertoire ou le² fichier à l'aide de rsync vers la destination appropriée.


-------

² ou les

[lol]

Salut,

Pourquoi faudrait-il joindre un mdp dans un script ?

Tu ne répond pas à la question.
Je parle de FTP et de Dump SQL ,tu me parle de rsync et ssh. Faudrait lire avant de répondre.

Comment automatise tu un DUMP local sans passer le mot de passe ?
Comment envoie tu des fichiers sur un FTP (si j'avais la possibilité de la faire en SCP je n'aurais pas posé la question...) sans passer le mot de passe ?

[BelZéButh]

Faudrait lire avant de répondre.

J'ai lu, et de haut en bas avant de te soumettre mon point de vue et ma façon d'opérer.
Reconsidères ton point de vue sur rsync avant de gueuler.
Comme dit, il fait de l'import ou de l'export.

Comment automatise tu un DUMP local sans passer le mot de passe ?

Via une tâche cron, nan ?
Vraisemblablement, c'est un dump distant, donc un cron distant.
Deuxième cron, rsync export ou import.

Comment envoie tu des fichiers sur un FTP

Je n'utilise pas de FTP (mdp en clair), à toi d'adapter en conséquence.
Debian étant suffisamment flexible.

-------

* edit*

PS : prends un peu de recul (rsync) et cogites la-dessus, tu verras que l'idée n'est pas si con qu'elle n'y paraît. De plus, elle très simple à mettre en place.

[lol]

PS : prends un peu de recul (rsync) et cogites la-dessus, tu verras que l'idée n'est pas si con qu'elle n'y paraît. De plus, elle très simple à mettre en place.

Je peux prendre tout le recul que je veux, un DUMP SQL local ne peut se faire sans mot de passe. Et un DUMP ne se fera pas avec Rsync et SSH...
Aussi flexible que Debian soit, je suis obligé de passer un mot de passe dans mon script pour envoyer des fichiers sur un FTP distant (sur une machine qui ne m'offre que du FTP).
Si tu n'arrive à envoyer des fichiers sur un serveur FTP distant sans mot de passe avec Rsync fais moi signe il faut absolumenbt que la communauté en profite..

Tout aussi merveilleux soient ils, rsync et ssh ne me servent à rien.
Je te remercie de tes précieux conseils, mais tu es hors sujet.

Donc si tu n'a rien à proposer pour essayer de rendre un peu sécurisé des scripts qui contiennent/utilisent des mots de passe passe ton chemin.
Merci.

[thuban]

Je m'abonne au fil, ça m'intéresse :)
Car non, je n'ai pas de solutions à proposer. À mon avis ça va dépendre de chaque service/programme concerné. Tant qu'on n'a pas de truc aussi fiable que les clés SSH, ça reste une forme de bricole.

[BelZéButh]

un DUMP SQL local ne peut se faire sans mot de passe.

C'est exact.

Et un DUMP ne se fera pas avec Rsync et SSH...

Je ne pense pas avoir évoqué le fait de lancer un DUMP depuis une session rsync.
Bien au contraire.
J'ai invoqué deux tâches crons, en faisant abstraction des conditions préalables.

Si tu n'arrive à envoyer des fichiers sur un serveur FTP distant sans mot de passe

Je réitère, je n'utilise (et n'utiliserai jamais) de service FTP.

Je te remercie de tes précieux conseils, mais tu es hors sujet.

Que tu dis et penses, mais ...

Donc situ n'a rien à proposer pour essayer de rendre un peu sécurisé [...] passe ton chemin.

Fait !

[piratebab]

Quelle que soit la méthode utilisée, à un moment ou a un autre, il faut un secret stocké sur la machine locale pour l'identifier. Y compris en ssh.
SSH va te protéger contre une usurpation d'identité, pas contre le vol du secret sur ta machine.
lol, ton problème n'a à mon avis pas de solution.
La sécurité doit combiner é chose:
- ce que j'ai
- ce que je sais
Le script ne fait pas la différence entre ce qu'il a et ce qu'il sait. il faut bien qu'a un moment ou a un autre, un humain amène ce qu'il sait (mot de passe) pour s'assurer de la cohérence avec ce qu'il a (la machine avec le secret).
A la rigeur, tu peux utiliser l'adresse mac, ou le numéro de série du proc pour donner accès ou mdp stocké haché. Ton script ne tournera que sur cette machine.. Mais même ça, c'est contournable.
Pour durcir, tu peux ajouter une fenétre temporelle courte (tu as 10sec à partir de minuit pour décoder le MP).

[lol]

Je m'abonne au fil, ça m'intéresse :)
Car non, je n'ai pas de solutions à proposer. À mon avis ça va dépendre de chaque service/programme concerné. Tant qu'on n'a pas de truc aussi fiable que les clés SSH, ça reste une forme de bricole.

J'ai beau tourner le truc dans tous les sens, je ne vois pas de moyen 100% sécurisé.
shc est ce qui se ferait de mieux (conversion du script en binaire) mais ce n'est pas complètement sécurisé malheureusement.
Il faudrait mixer shc avec un fichier crypté contenant les identifiants placé dans un répertoire sécurisé. Ça diminue nettement la possibilité de vol de mot de passe, mais ce n'est pas parfait, loin s'en faut.

Pour durcir, tu peux ajouter une fenétre temporelle courte (tu as 10sec à partir de minuit pour décoder le MP).

C'est bon ça! Comment ça se met en place ?
Il suffit que le script se lance dans la bonne fenêtre et ça complique encore bien la difficulté de trouver le mdp...

[piratebab]

J'ai souvent des idées tordues.
tu stockes le MDP en distant, sur le serveur. Tu lances et arrête le serveur ssh pendant 1 mn avec un cron.
Ton client se connecte sur le serveur pendant la période d'activité du démon ssh, et récupère le mdp.

[sv0t]

D'après ce que je lis ici plutôt que de stocker le mdp dans le script, pourquoi pas avoir un script qui lirais le mdp dans un fichier caché, avant de faire le job demandé....

Abonnement

[piratebab]

Plus j'y réfléchi, plus je me dis que stocker le MDP sur le client n'est pas une bonne idée, qu'elle que soit la solution.Comme dans le protocole ssh, c'est le serveur qui doit initier la séquence. Et le client réponds avec ce qu'il possède (n° de série du proc ou de la CG).
client: contacte moi
serveur: voici une clef de chiffrement aléatoire, chiffre ton n° de série (ou ta clef privée) avec ça
client: OK voici
serveur: OK c'est bien toi, voici une clef de cession pour chiffrer tout nos messages (à décoder avec ta clef privée)

[lol]

Compliqué à mettre en place avec un serveur qui n'offre que du ftp en face.
Éventuellement se servir de la réponse à l'initiation de la connexion comme clef pour déchiffrer le mot de passe stocké localement ?

[piratebab]

Tu peux regrouper tes MDP sur un seul serveur, ça réduira la surface d'attaque. Considère le comme un coffre fort, avec accès limité à une machine (IP, ou numéro de série d'un composant), sur une fenêtre temporelle donnée, + connaissance d'une clef privée sur le client.
Tu peux rajouter du port knoking par dessus.
Le client fait une demandes d’accès au serveur (c'est là que tu mets le port knoking), et c'est le serveur qui déclenche l'authentification.
Même Mack giver mettra des mois récupérer les mots de passe.

[lol]

Oui, pas mal comme idée.
L'astuce serait d'avoir le mot de passe (crypté) sur une machine et la clef de decryptages sur une autre.
Et le script convertit en binaire avec shc (ça complique bien les choses pour trouver le chemin des fichiers de mots de passe et de clefs...).
Je creuse ce truc qui m'a l'aire d'être "LA" meilleure solution.
Le "seul" bémol étant la disponibilité des mots de passe et des clefs...

[lol]

J'ai une autre idée.
Une machine distante dépose clef et mot de passe crypté dans /temp quelques minutes avant que le script ne se lance. Puis les efface quelques minutes plus tard.
Ainsi même si on arrive à lire le binaire et qu'on trouve le chemin des clefs et mots de passes, il est la plupart du temps vide...