Chiffrement Debian

Bonjour,

j’ai utilisé l’installeur Debian permettant de chiffrer des volumes logiques grâce à une passphrase au démarrage de l’OS.
Le serveur DEBIAN étant situé physiquement sur un lieu sensible (vol de la machine possible), cette solution m’est apparu la meilleure.
Le problème est qu’a chaque re-démarrage du serveur, je suis obligé de donner la passphrase à un utilisateur local afin qu’il démarrer le serveur.
Ma question est :
est-il possible de modifier cette passphrase une fois le serveur démarrer et connecté à distance dessus afin que la passphrase ne soit pas connu des utilisateurs locaux?
ou
Avez-vous une autre solution à me proposer ?

Merci par avance pour vos réponses.

ps:je suis débutant sous linux…

Existe-t-il une ligne de commande pour changer ce mot de passe au démarrage du serveur?
Merci par avance

[quote]est-il possible de modifier cette passphrase une fois le serveur démarrer et connecté à distance dessus afin que la passphrase ne soit pas connu des utilisateurs locaux?
[/quote]
Je ne comprends pas bien ton probleme. Pourquoi vouloir changer le mot de passe a chaque demarrage de la machine ?

Detaille un peu plus ton probleme.

À chaque fois qu’il donne la phrase, cela fait un utilisateur qui peut trouver ces données. Le problème n’est pas simple, qu’utilises tu comme système de chiffrage?

Avec ecryptfs, c’est possible via ecryptfs-rewrap-passphrase mais je ne connais pas bien.

La passephrase de montage elle ne peut être modifiée. Quelqu’un de connecté connaissant la phrase peut en déduire la clef de montage via ecryptfs-unwrap-passphrase. Il y a donc de toute façon un souci de sécurité à moins de limiter fortement les accès à cet utilitaire.

[quote=“fran.b”]À chaque fois qu’il donne la phrase, cela fait un utilisateur qui peut trouver ces données. Le problème n’est pas simple, qu’utilises tu comme système de chiffrage?

Avec ecryptfs, c’est possible via ecryptfs-rewrap-passphrase mais je ne connais pas bien.

La passephrase de montage elle ne peut être modifiée. Quelqu’un de connecté connaissant la phrase peut en déduire la clef de montage via ecryptfs-unwrap-passphrase. Il y a donc de toute façon un souci de sécurité à moins de limiter fortement les accès à cet utilitaire.[/quote]

Le mieux qu’il est à faire c’est nous faire un topo exact de la situation de son serveur ( quelle utilisation ? ) qui travail sur quoi et comment, enfin bref du gros détails histoire que l’on puisse le conseiller au mieux ).

Dans l’absolu, il faudrait peut-être chiffrer le disque non pas avec une passphrase, mais avec une clef symétrique quelconque.
Et là, toi tu chiffres cette clef avec une passphrase que tu peux donc changer à chaque démarrage. Ainsi, tu t’affranchis du problème en ajoutant une couche supplémentaire.

Je réponds théoriquement, après je ne sais pas comment on peut le mettre en oeuvre…

Bonjour à tous et merci de vous intéressez à mon cas :041 .
Je vais essayer d’expliquer un peu mieux mon cas:
J’ai un serveur Nagios avec une configuration personnelle sous debian sur un site distant.
Ce serveur est protégée par un mot de passe de session.(root)
Les données ainsi que l’ensemble du serveur sont considérés sensibles.
Je cherche une solution pour qu’en cas de vol du serveur aucune données ne soit visible si le disque est démonté puis monté sur un autre serveur.
Le serveur étant amener à redémarrer en cas de coupure courant ou de maintenance, une personne sur place devra démarrer physiquement le serveur.
Pouvez-vous m’apporter une solution ?

Mais dans ce cas, quel est l’intérêt du mot de passe pour monter la partition ?

Si tu chiffres tes partitions avec clé aléatoire, il faut booter sur le système installé pour pouvoir les déchiffrer.
Depuis un live CD et/où en mettant le disque dans une autre machine, pas d’accès aux données puisque ce disque est chiffré.

Un mot de passe root ‘fort’, un mot de passe d’accès au BIOS, le CD et USB désactivés dans celui ci et un script de firewall suffisent amplement à protéger ton serveur, sans t’embêter avec le mot de passe de montage des partitions qui, comme tu l’expliques, pose problème lors des reboots.

Dans ton cas actuel, tu pourras mettre toute la sécurité que tu veux, le maillon faible est le fait que tu doives transmettre le mot de passe à un tiers. Même si tu changes ce mot de passe une fois la machine démarrée, tu ne pourrais certifier qu’aucun acte malveillant ne puisse être effectué entre le temps où tu transmets le mot de passe et celui où tu le changes.

Il ne faut pas perdre de vue que la majorité des vols de données sont le fait d’individus internes à la société.
Trop de sécurité tue la sécurité (Ce qui est ton cas, tu tue complètement ta sécurité avec cet échange de mot de passe).

Ce que tu peux faire, c’est separer le “/home” du reste du systeme et ne chiffrer que le “/home”.
Ainsi, ton systeme peut booter sans probleme, lancer les services reseaux et SSH, et a ce moment la tu peux te connecter en SSH et fournir la cle qui va bien pour ouvrir une session sur le “/home” qui lui est chiffre.

Comme je t’ai raconté une bêtise plus haut (On ne peut pas chiffrer avec une clé aléatoire autre chose que des partitions qui seront perdues à chaque reboot), je t’ai trouvé cela dans la documentation cryptsetup (zless /usr/share/doc/cryptsetup/README.remote.gz) :

[quote]unlocking rootfs via ssh login in initramfs

You can unlock your rootfs on bootup from remote, using ssh to log in to the
booting system while it’s running with the initramfs mounted.

Setup

For remote unlocking to work, the following packages have to be installed
before building the initramfs: dropbear busybox

The file /etc/initramfs-tools/initramfs.conf holds the configuration options
used when building the initramfs. It should contain BUSYBOX=y (this is set as
the default when the busybox package is installed) to have busybox installed
into the initramfs, and should not contain DROPBEAR=n, which would disable
installation of dropbear to initramfs. If set to DROPBEAR=y, dropbear will
beinstalled in any case; if DROPBEAR isn’t set at all, then dropbear will only
be installed in case of an existing cryptroot setup.

The host keys used for the initramfs are dropbear_dss_host_key and
dropbear_rsa_host_key, both located in/etc/initramfs-tools/etc/dropbear/.
If they do not exist when the initramfs is compiled, they will be created
automatically. Following are the commands to create them manually:

dropbearkey -t dss -f /etc/initramfs-tools/etc/dropbear/dropbear_dss_host_key

dropbearkey -t rsa -f /etc/initramfs-tools/etc/dropbear/dropbear_rsa_host_key

As the initramfs will not be encrypted, publickey authentication is assumed.
The key(s) used for that will be taken from
/etc/initramfs-tools/root/.ssh/authorized_keys.
If this file doesn’t exist when the initramfs is compiled, it will be created
and /etc/initramfs-tools/root/.ssh/id_rsa.pub will be added to it.
If the latter file doesn’t exist either, it will be generated automatically -
you will find the matching private key which you will later need to log in to
the initramfs under /etc/initramfs-tools/root/.ssh/id_rsa (or id_rsa.dropbear
in case you need it in dropbear format). Following are the commands to do the
respective steps manually:

To create a key (in dropbear format):

dropbearkey -t rsa -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear

To convert the key from dropbear format to openssh format:

/usr/lib/dropbear/dropbearconvert dropbear openssh \

/etc/initramfs-tools/root/.ssh/id_rsa.dropbear \
/etc/initramfs-tools/root/.ssh/id_rsa

To extract the public key:

dropbearkey -y -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear | \

grep "^ssh-rsa " > /etc/initramfs-tools/root/.ssh/id_rsa.pub

To add the public key to the authorized_keys file:

cat /etc/initramfs-tools/root/.ssh/id_rsa.pub >> /etc/initramfs-tools/root/.ssh/authorized_keys

In case you want some interface to get configured using dhcp, setting DEVICE= in
/etc/initramfs-tools/initramfs.conf should be sufficient. The initramfs should
also honour the ip= kernel parameter.
In case you use grub, you probably might want to set it in /boot/grub/menu.lst,
either in the ‘# kopt=’ line or appended to specific ‘kernel’ line(s).
The ip= kernel parameter is documented in Documentation/nfsroot.txt in the
kernel source tree.

Issues

Don’t forget to run update-initramfs when you changed the config to make it
effective!

Collecting enough entropy for the ssh daemon sometimes seems to be an issue.
Startup of the ssh daemon might be delayed until enough entropy has been
retrieved. This is non-blocking for the startup process, so when you are at the
console you won’t have to wait for the sshd to complete its startup.

Unlocking procedure

To unlock from remote, you could do something like this:

ssh -o “UserKnownHostsFile=~/.ssh/known_hosts.initramfs” \

-i "~/id_rsa.initramfs" [root@initramfshost.example.com](mailto:root@initramfshost.example.com) \
"echo -ne \"secret\" >/lib/cryptsetup/passfifo"

This example assumes that you have an extra known_hosts file
"~/.ssh/known_hosts.initramfs" which hold’s the cryptroot system’s host-key,
that you have a file “~/id_rsa.initramfs” which holds the authorized-key for
the cryptroot system, that the cryptroot system’s name is
"initramfshost.example.com", and that the cryptroot passphrase is “secret”

debian@x.ray.net, Wed, 30 Sep 2009
[/quote]

J’ai testé la solution DropBear.

Il subsiste un problème : DropBear ne permets de déverrouiller QUE la partition /.
Pour le déverrouillage des autres partitions, je te revoies vers ces docs.

http://wejn.org/how-to-make-passwordless-cryptsetup.html
http://blog.nibbles.fr/162

En créant des clés pour le déverrouillage des partitions supplémentaires et en les stockant dans /etc (A la place de les stocker sur une clé USB), cela ne devrais pas poser de problème de sécurité, puisque ces clés seront inaccessibles sans avoir au préalable déverrouillé /.

Ce n’est pas la solution ‘clé en main’ mais le cheminement à mettre en œuvre est là.

Comme je te l’ai dit, tout dépend de ta méthode de chiffrage. Avec ecryptfs, tu peux modifier la passphrase servant à crypter la clef de codage, ça répond donc à ton problème. la seule chose est de ne pas donner l’accès à ecryptfs-unwrap-passphrase qui permet de récupérer la clef de codage si on connait la passphrase. Si tu veux te protéger contre le vol c’est la seule solution.

Ecryptfs est certes très pratique pour chiffrer son dossier perso, mais est quasiment inutilisable pour chiffrer un système complet.
J’avais fait des tests sur un serveur de sauvegarde rsync.
Là où la sauvegarde du répertoire /home d’une machine prenait moins de 10mn sur une partition ext3 non chiffrée, j’ai stoppé le test après plus d’une heure de rsync dans un dossier chiffré par ecryptfs coté serveur. Je suis ensuite passé à un chiffrement de partition Luks et là, je n’ai pas vu de différence notable comparé à une partition non chiffrée.

Donc, pour résumer :

Chiffrement d’un dossier unique au sein d’un système de fichiers -> ecryptfs
Chiffrement d’un système de fichiers complet -> Luks.

Il faut aussi comprendre que les deux chiffrements n’ont pas la même finalité : Ecryptfs protège un dossier spécifique de tout accès tant extérieur que par d’autres utilisateurs du système. Luks protège un disque/partition de tout accès extérieur (Vol de machine, accès depuis un CD), mais absolument pas d’un accès d’un utilisateur de la machine, puisque le système de fichiers est monté au niveau système, contrairement à Ecryptfs qui est lui monté au niveau utilisateur individuel.

@ NooP : Tu me ferais sauter au plafond en proposant quelques liens pour les deux outils sus nommé même si je connais déjà luks ( on ne connais jamais assez bien :083 ).

Je n’ai pas spécialement de docs concernant ces deux systèmes de chiffrement.
Les plus utiles concernant Luks, j’en ai donné les liens dans un message précédent.
Pour eCryptfs, j’avais bookmarké ceux ci :

publib.boulder.ibm.com/infocente … rmount.htm
cepcasa.info/parted/ecryptfs.html
blog.rom1v.com/2010/05/chiffrer- … us-ubuntu/
bodhizazen.net/Tutorials/Ecryptfs
wiki.archlinux.fr/Encryption_avec_eCryptfs

Et pour Luks :

code.google.com/p/cryptsetup/
doc.ubuntu-fr.org/cryptsetup
madduck.net/docs/cryptdisk/
raftaman.net/?p=300
wejn.org/how-to-make-passwordles … setup.html
binblog.info/2008/12/04/using-a- … assphrase/
blog.nibbles.fr/162
roland.entierement.nu/blog/2010/ … b-key.html

Voila tout ce que j’ai en ma possession. J’espère que tu ne te fracasseras pas le crâne au plafond :wink:

:023 nickel chrome :023

creer-et-utiliser-une-partition-cryptee-t5281.html

sinon.