Sommaire
Contexte
À mon taf actuel, on nous demande que les disques durs de données de nos serveurs soient chiffrés. L'objectif est avant tout de se protéger d'un vol d'un disque par un technicien de l'opérateur qui nous héberge, ou d'un mauvais effaçage après recyclage du disque en cas d'incident.
Mais du coup, comment conjuguer ça avec la volonté d'avoir un serveur capable de redémarrer "seul" en cas d'incident ?
Afin d'avoir une solution où la passphrase ne se retrouve pas dans un fichier en clair sur le serveur ou dans l'initramfs, le plus simple reste d'utiliser un élément qui reste quelque peu honni par ses origines : le TPM.
Le TPM est une puce de chiffrement, similaire à une carte à puce, intégrée sur la carte mère des machines (et requis pour Windows), qui permettra de déchiffrer des secrets si l'état d'intégrité de la machine n'est pas altéré. Concrètement, si la signature du firmware, du bootloader ou du noyau n'est pas bonne, les secrets sont inaccessibles. C'est le principe de Secure Boot.
Dans notre cas, l'intérêt est surtout de lier les disques à une machine. La probabilité du vol d'un serveur complet est considérée négligeable face au risque du vol d'un disque.
Utilisation
Du coup, étape 1 : activer Secure Boot. Bonne chance, ça dépend du firmware de chaque machine, et si, en prime, vous avez installé en mode "legacy" au lieu d'UEFI, vous allez avoir une ou deux étapes de souffrance additionnelle (ajouter une partition ESP, changer de grub…)
Par contre, une fois Secure Boot activé, vous avez normalement au boot ceci :
# dmesg | grep secureboot
[ 0.000000] secureboot: Secure boot enabled
Ce qui veut dire que le TPM est normalement accessible, en avant pour la suite !
Étape 2 : créer un volume avec LUKS et une passphrase. Cette opération est classique, je ne vais pas tout détailler. Grosso modo: crypsetup luksFormat /dev/mapper/mon-volume
Et notez bien la passphrase, elle vous servira de clé de secours en cas de perte du TPM (imaginez un instant que votre hébergeur ait une fuite sur son refroidissement et que votre carte mère soit sous l'eau…)
Étape 3 : installer les éléments requis pour avoir le TPM fonctionnel. Dans mon cas, il s'agit d'un serveur en bullseye, or il est bien plus simple d'utiliser le systemd de bookworm pour ce qui suit (il faut beaucoup plus bidouiller cryptsetup pour qu'il utilise le TPM), du coup, activons les backports et apt install -t bullseye-backports systemd. En complément, pour le TPM : apt install libtss2-esys-3.0.2-0 libtss2-rc0
Désormais, la commande systemd-cryptenroll --tpm2-device=list devrait lister un TPM disponible pour ce qui suit
Étape 4 : enroller le TPM dans le luks. C'est facile, systemd-cryptenroll s'en charge: systemd-cryptenroll --tpm2-device=/dev/tpmrm0 --tpm2-pcrs=7 /dev/mapper/mon-volume
Bien sûr, la passphrase sera demandée pour pouvoir ajouter le TPM.
Étape 5 : enjoy and profit.
Pour vérifier que ça fonctionne, il suffit de faire /usr/lib/systemd/systemd-cryptsetup attach volume-clear /dev/mapper/mon-volume - tpm2-device=/dev/tpmrm0
Normalement, le volume sera accessible en clair sur /dev/mapper/volume-clear.
Pour le monter au boot, il suffit alors d'ajouter dans /etc/crypttab quasiment ce que l'on vient de saisir, à savoir:
volume-clear /dev/mon/volume - tpm2-device=/dev/tpmrm0
Facile, n'est-ce-pas ?
Au secours, j'ai perdu ma passphrase…
Ça peut arriver à tout le monde, donc pour votre sécurité, j'ai décidé de supprimer ma passphrase et pourtant de réussir à en rajouter une nouvelle grâce à la clé du TPM… (Oui bon ça arrive à tout le monde une fausse manip, ça va, puis j'ai fait ça en recette, pas en prod)
Tout d'abord, un rappel : comment marche LUKS. C'est très simple, un en-tête est ajouté sur le volume, qui contient un ensemble de données en JSON (sigh). Dans ces données se trouvent surtout des slots. Chaque slot permet de déchiffrer une clé de volume, qui elle permet de déchiffrer les données du reste du disque. Dans la procédure qui précède, nous avons donc deux slots : le slot 0 avec notre passphrase, le slot 1 pour le TPM.
On peut donc avoir une dizaine de passphrases différentes, les révoquer… sans pour autant rechiffrer tout le disque, heureusement.
Par contre si on fuite la clé du volume, là effectivement il va falloir travailler un peu plus, mais c'est pas le sujet ici.
Historiquement, il était d'ailleurs assez simple de récupérer la clé du volume sur un volume déjà monté, mais depuis un certain temps elle est stockée dans un keyring noyau interdit d'accès à l'espace utilisateur, il va donc falloir faire autrement.
systemd-cryptenroll permet d'ajouter une passphrase, un TPM, un FIDO ou autre, mais il faut systématiquement lui donner une passphrase existante pour accéder au volume. Il refuse d'utiliser un TPM pour ajouter une passphrase, limite d'implémentation je suppose.
MAIS… rien ne nous interdit d'aller avec gdb voir la clé utilisée pour déverrouiller le volume avec le TPM, non ?
C'est parti, apt install gdb systemd-dbgsym…
sudo gdb /usr/lib/systemd/systemd-cryptsetup
Quand on regarde le code source de systemd et le code de la libcryptsetup, on voit une fonction au nom fort tentant qui est utilisée pour ouvrir le volume : crypt_activate_by_passphrase.
Cf. https://github.com/systemd/systemd/blob/v252/src/cryptsetup/cryptsetup.c#L1177-L1186
Un breakpoint bien placé devrait nous aider…
b crypt_activate_by_passphrase
r attach volume-test /dev/mapper/mon-volume - tpm2-device=/dev/tpmrm0
Et hop, notre breakpoint s'active ! Par contre j'ai pas les symboles de debug de libcryptsetup moi…
up
Et je suis dans le code de systemd…
p base64_encoded
Et voilà la passphrase. Je n'ai plus qu'à l'utiliser pour ajouter une nouvelle passphrase, et le tour est joué.
# Remplacer TPM par le réseau
Posté par cg . Évalué à 7.
Il existe aussi des méthodes pour déverrouiller LUKS par le réseau : voir entre autres le wiki Archlinux. Parce que la probabilité de te faire voler le réseau complet est plus faible que celle de te faire piquer un serveur complet ;).
[^] # Re: Remplacer TPM par le réseau
Posté par Katyucha (site web personnel) . Évalué à 4.
https://github.com/latchset/clevis sinon pour le déchiffrement automatique
# Rapport coût/bénéfice
Posté par arnaudus . Évalué à 6.
Par curiosité, est-ce que le rapport coût/bénéfice est bien raisonnable? Quelle est la probabilité qu'un technicien random pique un disque au pif dans une baie, sans trop savoir ce qu'il y a dessus? Quelle est la probabilité que ce technicien arrive à identifier un ou des fichiers sensibles parmi des To de données inintéressantes, et que ce tech soit connecté aux réseaux du côté obscur de la Force qui serait à même de valoriser ces données sur un marché noir? Si en face il y a des gens assez motivés pour aller placer des agents dans les data centers qui vont aller voler des disques de manière ciblée, alors il semble assez envisageable pour de telles organisation d'aller rentre visite à un admin sys pour lui demander poliment la passphrase.
Parce qu'en face, il n'y a pas rien. Il y a le coût de la mise en place du chiffrage (mettre en place le protocole décrit ci-dessus pour chaque nouveau serveur) et de la maintenance (serrer les fesses à chaque mise à jour), et surtout le risque de perdre des données si quelque chose se passe mal. Je ne prétends pas qu'il n'existe pas de données qui méritent ce genre de traitement, mais elles doivent être assez rares, non?
[^] # Re: Rapport coût/bénéfice
Posté par Pinaraf . Évalué à 5.
Coût : tu l'as dit.
Bénéfice : ne pas perdre des (gros) clients qui exigent ça parce que c'est dans la liste des cases à cocher…
Donc… oui c'est raisonnable, même si c'est assez idiot d'en arriver à mettre ça en place.
[^] # Re: Rapport coût/bénéfice
Posté par arnaudus . Évalué à 8.
Ah OK, je n'avais pas compris ça. Évidemment, si un client parano paye, autant entrer dans son jeu. Tu lui factures l'option "vol de disque", et pour "vol de serveur" c'est plus cher. Le niveau suivant, c'est "vol de data center complet avec 18 hélicoptères".
Le pire, c'est que ce genre de protocole ne doit pas trop empêcher que les clés trainent sur un post-it dans le bureau des admin sys.
[^] # Re: Rapport coût/bénéfice
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ce n'est pas idiot si ça répond à un/une besoin/demande …et que des gens payent pour ça.
Prochaine étape : revoir la chaîne de déploiement pour que ce ne soit pas tout manuel (sauf s'il y a ce genre d'installation que tous les cinq à dix ans) et surtout que les clefs soient bien dans un coffre (vault) etc.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Rapport coût/bénéfice
Posté par freem . Évalué à 6. Dernière modification le 18 avril 2023 à 08:25.
Tu as oublié le xkcd qui va bien!
Mais bon, sinon, ça a aussi le côté fun de bosser avec des trucs tarabiscotés non? Quand il n'y a plus de problèmes a résoudre, s'en créer quelques uns ne fait pas de mal, ça occupe :D
Il y a aussi le fait que, OK, sur un serveur, c'est douteux, mais pour une machine portative, nettement moins, et j'imagine que la même méthode s'applique.
[^] # Re: Rapport coût/bénéfice
Posté par wismerhill . Évalué à 6.
Sauf que la situation est très différente.
Dans les serveurs, les disques ou SSD sont généralement accessibles en façade, sans ouvrir le capot. Donc voler un disque en vitesse est effectivement beaucoup plus crédible qu'emporter le serveur complet.
Alors que pour un ordinateur portable, c'est plus simple d'emporter le tout, plutôt que l'ouvrir à la volée.
Donc s'il suffit de l'allumer pour déverrouiller les partitions cryptées, autant considérer qu'il n'est pas protégé contre le vol de données.
Pour ce cas de figure, il vaut mieux avoir un support physique quelconque, qui contient la clé de déchiffrement, mais qu'on garde sur sois.
[^] # Re: Rapport coût/bénéfice
Posté par freem . Évalué à 4.
Mais du coup, il y a beaucoup de différence de commandes entre le cas d'une machine avec une "clé physique" et le cas présenté ici?
[^] # Re: Rapport coût/bénéfice
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
ça ne sera pas un TPM mais par exemple une carte à puces (accessible avec PC/SC) ou une Yubikey. Les outils et bibliothèques à utiliser ne sont pas les mêmes, ça serait trop facile :(
[^] # Re: Rapport coût/bénéfice
Posté par freem . Évalué à 3.
J'aurai cru qu'il serait possible de demander au TPM d'accéder à la carte à puce, justement? J'ai bien une machine avec un tel système pour le taf, mais bon, c'est pour le taf, j'ai pas le droit de bricoler dessus :)
[^] # Re: Rapport coût/bénéfice
Posté par arnaudus . Évalué à 6.
Mouais, il faut quand même rentrer dans le datacenter, trouver le ou les bons serveurs, piquer un disque sans connaitre la probabilité d'avoir des données exploitables dessus, ressortir du datacenter avec le disque dans la poche, et espérer que personne ne s'aperçoive de rien, qu'il ne va pas y avoir de plainte ni de visionnage des vidéos… tout ça pour peut-être avoir piqué le disque avec /bin et /etc dessus. Ça demande beaucoup, beaucoup d'organisation pour un résultat bien incertain…
Pour un ordinateur portable, la situation est différente. Ça parait un peu paradoxal de laisser des gens se ballader avec des fichiers sensibles sur des ordinateurs portables (puisqu'on peut partir du principe que se faire voler est un destin probable pour un portable qui bouge beaucoup), mais d'essayer de mitiger le truc par un chiffrage avec une clé sur un support physique. Si tu ne veux pas que le portable ait constamment la clé USB vissée dessus, il faut de toutes manières que tu ne chiffres que certains fichiers. Autrement, si tout le disque est chiffré, il faudra mettre la clé dès que tu veux lire tes emails à l'aéroport ou que tu veux montrer la dernière plaquette promotionnelle à un client; autrement dit, la clé sera soudée à l'ordinateur.
[^] # Re: Rapport coût/bénéfice
Posté par claudex . Évalué à 4.
Le cas classique d'un technicien qui change un disque en RMA en fait. (tu as des contrats où tu peux garder les disques défectueux, mais c'est plus cher)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Rapport coût/bénéfice
Posté par freem . Évalué à 2.
Franchement à l'usage, ce n'est pas ce que je constate. Bon, dans mon cas, c'est une carte à puce, qui sert aussi à ouvrir des portes, mais justement: une carte à puce ça ne dépasse quasiment pas de la machine, et la partie qui dépasse, on s'en fiche un peu.
Et pourtant sur les sites ou j'interviens, la majorité des gens récupèrent la carte quand ils s'absentent. C'est bien plus pratique que de devoir verrouiller sa session à la main, et devoir taper un code à rallonge pour se relog, je pense que ça aide pas mal (la carte nécessite un code pin bien entendu, mais c'est très court et se tape en 2s).
Je ne dis pas que personne ne laisse la carte dans la machine en ma présence, mais en même temps je suis tout le temps amené à manipuler la session des utilisateurs (tech support), donc si biais il y a, il serait plutôt en faveur que les gens vont laisser la carte si je suis dans le bureau que l'inverse.
Après, il ne s'agit que de mon expérience personnelle, bien sûr, et vu que je suis backup, ok je vois plusieurs sites, mais je peux difficilement prétendre avoir une vision précise de chaque site. A prendre avec les pincettes qui vont bien quoi, de la même manière que n'importe quelle supposition ou affirmation dans le vent :)
[^] # Re: Rapport coût/bénéfice
Posté par Mikis . Évalué à 3.
Si tu n'as pas de bol, ton disque est volé, vendu/acheté et fini sur youtube (c'est une série de 3, lien vers la 3e vidéo).
[^] # Re: Rapport coût/bénéfice
Posté par ocroquette . Évalué à 2. Dernière modification le 18 mai 2023 à 22:45.
J’ajouterais l’aspect probabiliste: en multipliant la probabilité faible par le nombre de disques élevés au niveau national ou mondial, tu arrives à des fuites régulières de données sensibles, détectées ou non. Et au plus il y a de disques non-chiffrés, au plus les disques volés ou d’occasion deviennent intéressants pour des personnes malintentionnées. C’est un peu comme mettre la clef de la maison sous le paillasson…
J’avais cherché récemment comment placer la clef de déchiffrement sur le réseau privé. L’idée est que chaque système sur le réseau interne peut accéder aux données, mais qu’elles sont inaccessibles à quelqu’un d’extérieur. Mais je n’avais rien trouvé de simple.
# Démarrage BIOS legacy mais avec compatibilité UEFI
Posté par damaki . Évalué à 3.
Pour éviter la mésaventure de devoir migrer vers UEFI et refaire le partitionnement à un moment inopportun, j'ai tendance à utiliser le mode de compatibilité BIOS avec GPT. C'est pas très compliqué et ça permet ensuite de migrer très facilement vers de l'UEFI si le besoin se fait sentir, par exemple si vous changez de serveur mais voulez garder les mêmes disques sans les repartitionner.
# disques RAID
Posté par eric gerbier (site web personnel) . Évalué à 2.
Sur mes serveurs, les disques sont en LVM + RAID 6, sur une carte controleur proprio (RAID hardware). Je doute que l'on puisse récupérer des données sur un seul disque. Qu'est-ce que vous en pensez ?
[^] # Re: disques RAID
Posté par Elfir3 . Évalué à 3. Dernière modification le 20 avril 2023 à 09:47.
A priori, rien n'empêche certains fichiers d'être leakés. J'connais pas vraiment l'implémentation de LVM, mais de ce que je lis sur wikipedia du raid 6, si les blocs sont suffisamment grands, tu peux avoir un fichier qui contient des données sensibles sur un des disques.
Tu ne pourras sans doute pas lire le disque directement, mais il existe des outils qui permettent de retrouver des fichiers sans faire confiance au système de fichier sur base de signatures présentes dans les fichiers. Bref… t'es pas pour autant à l'abri.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.