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

09 juin 2016, 09:18

Comme je l'ai déja écrit, il subsustera toujours sur le client à minima un secretqui permet d'ouvrir le coffre. Mais si ce secret un associé a une info liée à la machine elle même, cela rends plus compliqué son utilisation sur une autre machine.

09 juin 2016, 17:26

Re,
Merci en tout cas des conseils.
Voici comment j'ai procédé:

Sur la machine ou se trouve le script:

Le mot de passe crypté par clef openssl est dans un fichier.
La clef est déplacé sur une autre machine.

Le script contient seulement le login. Le mot de passe est récupéré avec cette commande:
pass=$(openssl rsautl -inkey $1 -decrypt <~/.cache/.pass);

Le script est convertit en binaire avec shc.

Je lance le script sur la machine distante avec:
cat ~/.ssh/key | ssh machine_distante '/chemin/vers/le/script.sh <(cat -)'

Je crois que comme ça je suis plutôt tranquille...
Reste soit à faire un nohup soit installer screen sur le client.

Ça vous semble sécurisé ?

10 juin 2016, 13:08

En tout cas, chapeau ...
Mais je ne comprends pas l'intérêt dans l'immédiat ... d'autant que tu encapsules dans un flux SSH, qui lui normalement demande une authentification, au mieux par clé authentifiée, au pire par mot-de-passe ... je dois assurément louper quelque chose, malgré les explications données plus haut !

10 juin 2016, 15:07

PengouinPdt a écrit :En tout cas, chapeau ...
Mais je ne comprends pas l'intérêt dans l'immédiat ... d'autant que tu encapsules dans un flux SSH, qui lui normalement demande une authentification, au mieux par clé authentifiée, au pire par mot-de-passe ... je dois assurément louper quelque chose, malgré les explications données plus haut !

Salut,
La connexion ssh est initiée sans mot de passe, par clef. La clef privée étant sur la machine qui initie la connexion, pas de problème de sécurité.
Le mot de passe est décrypté à la volée sur la machine distante après lecture de la clef encapsulée envoyée dans une commande ssh.
On a donc sur la machine qui exécute le script uniquement le mot de passe crypté, sans la clef.
Impossible, de retrouver le mot de passe en clair sans accès à la machine qui détient le clef.

Pour faire court:
Je lance un script distant via ssh.
La clef pour décrypter le mot de passe dont le script distant à besoin est envoyée dans la même commande qui lance le script.

10 juin 2016, 17:54

Donc ton MDP circule en clair entre les machines.

10 juin 2016, 18:05

Salut,

piratebab a écrit :Donc ton MDP circule en clair entre les machines.

Non, c'est la clef qui transite, et elle est encapsulée dans un tunnel ssh. Le mot de passe est dans un fichier crypté avec openssl sur la machine ou se trouve le script.
Elle se trouve (la clef) si je ne me trompe pas, temporairement dans une variable de la machine "cliente".
D'ailleurs ça me fait penser qu'il faut que je vide la variable à le fermeture du script.

Je sais bien que ce n'est peut-être pas parfait.
Mais d'après tout ce que j'ai pu lire et chercher sur le net, y'a pas 36 solutions. D'ailleurs je n'en ai trouvé aucune d'aussi satisfaisante que la mienne (en toute humilité évidemment...).

10 juin 2016, 19:15

Si, c'est intéressant en effet ...
Mais, étant donné que tu es déjà encapsulé dans ta connexion SSH, je trouve que tu rajoutes une couche de complexité, un niveau de sécurité ... tu n'es pas sûr de ta station ou du serveur ?!

Rassures-moi, ton niveau de chiffrement SSH est correct ?
4096 bits minimum ... ?
Les méthodes utilisées : absolument RSA, voire mieux ED25519 ?
Chiffrements utilisés : ok ?
Modes MAC EtM ?
Option "No Roaming", côté client désactivé ? (surtout si < v7.2) ...

10 juin 2016, 19:22

PengouinPdt a écrit :Si, c'est intéressant en effet ...
Mais, étant donné que tu es déjà encapsulé dans ta connexion SSH, je trouve que tu rajoutes une couche de complexité, un niveau de sécurité ... tu n'es pas sûr de ta station ou du serveur ?!

Je ne comprend pas. Quel niveau de complexité est en trop d'après toi ?

10 juin 2016, 19:26

Je ne dis pas que c'est en trop ... je trouve cela en trop ... pour un usage quotidien ... mais je comprends ton besoin.
D'où ma question concernant sur le fait que tu ne sois pas sûr de ton "serveur" alors que tu communiques en SSH, voire mes questions en rapport avec SSH !

ou, alors, c'est dans le but de faire exécuter cette commande, par SSH, par un tiers, sans qu'il connaisse le couple id/pass pour exécuter ladite commande ;)
là, cela a vraiment du sens :p

10 juin 2016, 19:39

La raison est simple:
Sur mon serveur j'héberge des sites Web dont les CMS peuvent être piratés. Ça arrive souvent, même quand on est prudent (il suffit d'un plug pas à jour).
Une fois le CMS piraté, en étant un peu malin tu peut accéder au système. Même si c'est juste en lecture ça peut être très dangereux; je pense notamment à des scripts qui contiendraient les mots de passe... (Dump SQL ou Backup FTP par exemple).
En cryptant les mots de passe et en stockant la clé de décryptage ailleurs, je limite énormément les risques.

Je n'ai pas de doutes sur la sécurité de mon serveur lui même (SSH, FTP et autres services sont blindés).
Par contre les CMS hébergés peuvent parfois être piratés. C'est d'ailleurs la cible préférée des scripts kiddies.

10 juin 2016, 19:53

Beh, voilà ... là, ça a du sens :p
Merci de tes explications :D

jim · 11 juin 2016, 10:17

11 juin 2016, 10:35

Salut,

Pour les fichiers de conf WP oui je ne vois pas de problème à ça.
Je ne me suis jamais penché dessus plus que ça, je crois que je ne risque pas grand chose:
- Le fichier de conf est une répertoire plus haut que la racine du site (et il ne contient que le mot de passe à une seule base de donnée, pas root évidemment)
- Le serveur SQL n'écoute que sur localhost

De plus maldet aime pas du tout les "eval(base64_decode..." dans les fichiers php... ça provoque plein d'alertes.
C'est le but de maldet tu me dira, mais les faux positifs risque de me faire passer à côté des vrais alertes.
Il faudrait donc que j'ajoute des exceptions pour chaque site. C'est faisable évidemment.

Dans le script bash je ne vois pas comment cacher la ligne qui contient la commande.