Déverrouillage automatique du conteneur racine LUKS après un démarrage à chaud

Pourquoi les gens chiffrent-ils généralement les lecteurs de leurs ordinateurs personnels et parfois leurs serveurs? Il est clair que personne n'a volé les photos de leurs chats préférés sur le disque! C'est juste de la malchance: un lecteur crypté vous oblige à entrer une phrase clé à partir du clavier à chaque démarrage, et c'est long et ennuyeux. Le supprimer pour qu'au moins parfois il ne soit pas nécessaire de le recruter. Oui, afin que le sens du cryptage ne soit pas perdu.

Eh bien, supprimez-le complètement, cela ne fonctionnera pas. Vous pouvez à la place créer un fichier clé sur une clé USB et cela fonctionnera également. Et sans clé USB (et sans deuxième ordinateur sur le réseau) est-ce possible? Si vous avez de la chance avec le BIOS, vous pouvez presque! Sous la coupe sera un guide sur la façon de configurer le chiffrement du disque via LUKS avec les propriétés suivantes:

1. La phrase secrète ou le fichier de clé n'est stocké nulle part sous forme ouverte (ou sous la forme équivalente à open) lorsque l'ordinateur est éteint.
2. La première fois que vous allumez votre ordinateur, vous devez saisir une phrase secrète.
3. Lors des redémarrages ultérieurs (avant l'arrêt), une phrase secrète n'est pas requise.

Les instructions ont été testées sur CentOS 7.6, Ubuntu 19.04 et openSUSE Leap 15.1 sur des machines virtuelles et sur du matériel réel (ordinateur de bureau, ordinateur portable et deux serveurs). Ils devraient travailler sur d'autres distributions qui ont une version fonctionnelle de Dracut.

Et oui, dans le bon sens, cela aurait dû se retrouver dans le hub «administration du système anormal», mais il n'y a pas un tel hub.

Je suggère d'utiliser un emplacement séparé dans le conteneur LUKS et d'y stocker la clé ... en RAM!

Le BIOS sur la plupart des cartes mères ne nettoie pas la mémoire lors du redémarrage, ou vous pouvez le configurer pour ne pas nettoyer (exception connue: "Intel Corporation S1200SP / S1200SP, BIOS S1200SP.86B.03.01.0042.013020190050 01/30/2019"). Par conséquent, vous pouvez y stocker la clé. Lorsque l'alimentation est coupée, le contenu de la RAM elle-même est effacé après un certain temps, avec une copie non protégée de la clé.

Alors allons-y.

Première étape: installer le système sur un disque chiffré à l'aide de LUKS

Dans ce cas, la partition de disque (par exemple, /dev/sda1 ) montée dans /boot doit rester non chiffrée, et l'autre partition sur laquelle tout le reste (par exemple, /dev/sda2 ) doit être chiffrée. Le système de fichiers sur la partition chiffrée peut être n'importe lequel, vous pouvez également utiliser LVM pour que le système de fichiers racine, le volume de swap et tout le reste, sauf /boot dans le même conteneur. Cela correspond au partitionnement de disque par défaut dans CentOS 7 et Debian lors du choix de l'option de chiffrement. SUSE fait tout différemment (chiffre /boot ) et nécessite donc un partitionnement manuel du disque.

Le résultat devrait ressembler à ceci:

 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 10G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 9G 0 part └─luks-d07a97d7-3258-408c-a17c-e2fb56701c69 253:0 0 9G 0 crypt ├─centos_centos--encrypt2-root 253:1 0 8G 0 lvm / └─centos_centos--encrypt2-swap 253:2 0 1G 0 lvm [SWAP] 

Dans le cas de l'utilisation d'UEFI, il y aura également une partition système EFI.

Pour les utilisateurs Debian et Ubuntu: remplacez le paquet initramfs-tools par dracut .

 # apt install --no-install-recommends dracut 

initramfs-tools implémente une logique incorrecte dans notre cas, appliquée aux sections chiffrées avec un fichier clé. Ces sections sont soit complètement ignorées, soit le contenu du fichier de clés est copié sur initramfs (c'est-à-dire, par conséquent, sur le disque) en clair, ce dont nous n'avons pas besoin.

Étape 2: créer un fichier de clé qui sera utilisé pour déverrouiller automatiquement le lecteur après un redémarrage à chaud

128 bits aléatoires nous suffisent, soit 16 octets. Le fichier sera stocké sur un disque crypté, donc personne qui ne connaît pas la clé de cryptage et n'a pas d'accès root au système chargé ne la lira pas.

 # touch -m 0600 /root/key # head -c16 /dev/urandom > /root/key 

Il y a suffisamment de bits vraiment aléatoires dans le fichier de clé pour que l'algorithme PBKDF lent, qui crée une clé de chiffrement difficile à choisir à partir d'une phrase clé potentiellement faible, ne soit pas vraiment nécessaire. Par conséquent, lorsque vous ajoutez une clé, vous pouvez réduire le nombre d'itérations:

 # cryptsetup luksAddKey --key-slot=6 --iter-time=1 /dev/sda2 /root/key Enter any existing passphrase: 

Comme vous pouvez le voir, le fichier de clé est stocké sur un disque crypté et ne pose donc aucun risque de sécurité si l'ordinateur est éteint.

Étape 3: Allouer de l'espace dans la mémoire physique pour stocker la clé

Linux possède au moins trois pilotes différents qui vous permettent d'accéder à la mémoire physique à une adresse connue. Il s'agit de linux/drivers/char/mem.c , qui est également responsable du périphérique /dev/mem , ainsi que des modules phram (émule une puce MTD, donne le périphérique /dev/mtd0 ) et nd_e820 (utilisé lorsque vous travaillez avec NVDIMM, donne /dev/pmem0 ). Ils ont tous leurs caractéristiques désagréables:

• /dev/mem pas accessible en écriture lors de l'utilisation de Secure Boot si la distribution utilise l'ensemble de correctifs LOCKDOWN de Matthew Garrett (et cet ensemble de correctifs est requis si la distribution va prendre en charge Secure Boot avec un chargeur de démarrage signé par Microsoft);
• phram pas disponible sur CentOS et Fedora - le responsable n'a tout simplement pas activé l'option correspondante lors de la construction du noyau;
• nd_e820 doit réserver au moins 128 mégaoctets de mémoire - c'est ainsi que fonctionne NVDIMM. Mais c'est la seule option fonctionnant sur CentOS avec Secure Boot.

Puisqu'il n'y a pas d'option idéale, les trois sont considérés ci-dessous.

Lors de l'utilisation de l'une des méthodes, un soin extrême est nécessaire afin de ne pas affecter accidentellement les périphériques ou les plages de mémoire autres que ce qui est nécessaire. Cela est particulièrement vrai pour les ordinateurs qui ont déjà des puces MTD ou des modules NVDIMM. A savoir, /dev/mtd0 ou /dev/pmem0 peut ne pas être le périphérique qui correspond à la zone de mémoire réservée au stockage de la clé. La numérotation des périphériques existants, sur lesquels s'appuient les fichiers de configuration et les scripts, peut également être confondue. Par conséquent, il est recommandé de désactiver temporairement tous les services qui dépendent des périphériques existants /dev/mtd* et /dev/pmem* .

La mémoire physique de Linux est memmap en passant l'option memmap au memmap . Nous sommes intéressés par deux types de cette option:

• memmap=4K$0x10000000 réserves (c'est-à-dire, marques réservées pour que le noyau lui-même n'utilise pas) 4 kilo-octets de mémoire, en commençant par l'adresse physique 0x10000000;
• memmap=128M!0x10000000 marque 128 mégaoctets de mémoire physique, en commençant à l'adresse 0x10000000, en tant que NVDIMM (évidemment faux, mais cela fera l'affaire pour nous).

L'option c $ peut être utilisée avec /dev/mem et phram , l'option c ! - pour nd_e820 . Lors de l'utilisation de $ adresse de départ de la mémoire réservée doit être un multiple de 0x1000 (soit 4 kilo-octets), lors de l'utilisation ! - un multiple de 0x8000000 (soit 128 mégaoctets).

Important: le signe dollar ( $ ) dans les fichiers de configuration de GRUB est un caractère spécial et doit être échappé. Et deux fois: une fois - lors de la génération de grub.cfg partir de /etc/default/grub , une deuxième fois - lors de l'interprétation du fichier de configuration résultant à l'étape de démarrage. C'est-à-dire dans /etc/default/grub , la ligne suivante devrait finalement apparaître:

 GRUB_CMDLINE_LINUX="memmap=4K\\\$0x10000000 ...  ..." 

Sans double échappement du signe $ , le système ne démarre tout simplement pas, car il pensera qu'il n'a que 4 kilo-octets de mémoire. Il n'y a pas de telles difficultés avec un point d'exclamation:

 GRUB_CMDLINE_LINUX="memmap=128M!0x10000000 ...  ..." 

La carte mémoire physique (et il est nécessaire de savoir quelles adresses réserver) est accessible à l' root dans le pseudo- /proc/iomem :

 # cat /proc/iomem ... 000f0000-000fffff : reserved 000f0000-000fffff : System ROM 00100000-7ffddfff : System RAM 2b000000-350fffff : Crash kernel 73a00000-7417c25e : Kernel code 7417c25f-747661ff : Kernel data 74945000-74c50fff : Kernel bss 7ffde000-7fffffff : reserved 80000000-febfffff : PCI Bus 0000:00 fd000000-fdffffff : 0000:00:02.0 ... 

La RAM est marquée "System RAM", il nous suffit de réserver une de ses pages pour stocker la clé. Deviner quelle partie de la mémoire du BIOS ne touche pas au redémarrage ne fonctionnera pas de manière fiable à l'avance. Sauf s'il existe un autre ordinateur avec exactement la même version du BIOS et la même configuration de mémoire sur laquelle ce manuel a déjà été complété. Par conséquent, dans le cas général, il faudra agir par essais et erreurs. En règle générale, lorsque le BIOS redémarre, il modifie les données uniquement au début et à la fin de chaque plage de mémoire. Il suffit généralement de retirer 128 mégaoctets ( 0x8000000 ) des bords. Pour les machines virtuelles KVM avec 1 Go de mémoire ou plus, les options proposées ( memmap=4K$0x10000000 et memmap=128M!0x10000000 ) fonctionnent.

Lorsque vous utilisez le module phram , phram besoin d'un autre paramètre de ligne de commande du noyau, qui, en fait, indique au module quel morceau de mémoire physique utiliser - le nôtre, réservé. Le paramètre est appelé phram.phram et contient trois parties: le nom (arbitraire jusqu'à 63 caractères, sera visible dans sysfs ), l'adresse de départ et la longueur. L'adresse et la longueur de départ doivent être les mêmes que dans memmap , mais les suffixes K et M ne M pas pris en charge.

 GRUB_CMDLINE_LINUX="memmap=4K\\\$0x10000000 phram.phram=savedkey,0x10000000,4096 ..." 

Après avoir édité /etc/default/grub vous devez régénérer le fichier de configuration réel que GRUB lit au démarrage. La commande correcte pour cela dépend de la distribution.

 # grub2-mkconfig -o /boot/grub2/grub.cfg # CentOS (Legacy BIOS) # grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg # CentOS (UEFI) # update-grub # Debian, Ubuntu # update-bootloader --reinit # SUSE 

Après avoir mis à jour la configuration GRUB, l'ordinateur doit être redémarré, mais nous le ferons plus tard lorsque nous mettrons à jour initramfs.

Quatrième étape: configurer LUKS pour lire la clé de la mémoire

/etc/crypttab paramètres de chiffrement des /etc/crypttab sont stockés dans le /etc/crypttab . Chaque ligne se compose de quatre champs:

• l'appareil à obtenir lors du déverrouillage,
• appareil crypté
• où obtenir le fichier clé ( none signifie entrer une phrase clé à partir du clavier),
• champ facultatif pour les options.

Si le fichier de clés existe mais ne convient pas, Dracut demande la phrase clé. Ce qui, en fait, sera nécessaire au premier démarrage.

Un exemple du /etc/crypttab d'une distribution fraîchement installée:

 # cat /etc/crypttab #   luks-d07....69 UUID=d07....69 none 

Le fichier clé dans notre cas sera un morceau de mémoire physique. C'est-à-dire /dev/mem , /dev/mtd0 ou /dev/pmem0 , selon la technologie d'accès à la mémoire sélectionnée. Des options sont nécessaires pour indiquer quelle partie du fichier est la clé.

 # cat /etc/crypttab #   #   /dev/mem: luks-d07....69 UUID=d07....69 /dev/mem keyfile-offset=0x10000000,keyfile-size=16 #   phram: luks-d07....69 UUID=d07....69 /dev/mtd0 keyfile-size=16 #   nd_e820: luks-d07....69 UUID=d07....69 /dev/pmem0 keyfile-size=16 

C'est juste que ça ne marchera pas comme ça.

Le point est de savoir comment systemd détermine quand un appareil peut être déverrouillé. À savoir, il prend l'appareil de la troisième colonne et attend que l'unité d'appareil correspondante devienne active. Cela semble logique: cela n'a aucun sens d'essayer de déverrouiller le conteneur LUKS jusqu'à ce qu'un périphérique avec un fichier de clé apparaisse. Mais l'unité de l'appareil n'est pas la même que l'appareil lui-même. Par défaut, Systemd crée des unités de périphérique uniquement pour les périphériques du noyau liés aux sous-systèmes de périphériques de bloc et aux interfaces réseau. Les périphériques /dev/mem et /dev/mtd0 sont caractère par caractère, ils ne sont donc pas surveillés par défaut et ne seront jamais reconnus comme prêts.

Vous devrez dire à systemd qu'il doit les suivre en créant des règles udev dans le fichier /etc/udev/rules.d/99-mem.rules :

 # /dev/mem KERNEL=="mem", TAG+="systemd" # /dev/mtd* KERNEL=="mtd*", TAG+="systemd" #  /dev/pmem*       

Cinquième étape: régénérer les initramfs

Je vous rappelle: cet article ne traite que des distributions utilisant Dracut. Y compris ceux où il n'est pas utilisé par défaut, mais est accessible et efficace.

Vous devez régénérer initramfs pour y mettre à jour le fichier /etc/crypttab . Et aussi - pour y inclure des modules de noyau supplémentaires et des règles udev. Sinon, le périphérique /dev/mtd0 ou /dev/pmem0 ne sera pas créé. Le paramètre de configuration Dracut force_drivers est responsable de l'activation et du chargement de modules de noyau supplémentaires, et install_items est responsable des fichiers supplémentaires. Nous créons le fichier /etc/dracut.conf.d/mem.conf avec le contenu suivant (un espace après le guillemet d'ouverture est requis, c'est un séparateur):

 #   /dev/mem: install_items+=" /etc/udev/rules.d/99-mem.rules" #   phram: install_items+=" /etc/udev/rules.d/99-mem.rules" force_drivers+=" phram" #   nd_e820: force_drivers+=" nd_e820 nd_pmem" 

Initramfs de régénération en fait:

 # dracut -f 

Pour les utilisateurs Debian et Ubuntu, le mainteneur a mis un rake: le fichier résultant est appelé de manière incorrecte. Vous devez le renommer afin qu'il soit nommé de la même manière que celui prescrit dans la configuration GRUB:

 # mv /boot/initramfs-5.0.0-19-generic.img /boot/initrd.img-5.0.0-19-generic 

Lors de l'installation de nouveaux noyaux, la création automatique d'initramfs via Dracut s'effectue correctement, le bug n'affecte que le lancement manuel de dracut -f .

Étape six: redémarrez votre ordinateur

Un redémarrage est nécessaire pour que les modifications apportées à la configuration GRUB et Dracut prennent effet.

 # reboot 

À ce stade, il n'y a pas de clé en mémoire, vous devrez donc saisir une phrase secrète.

Après le redémarrage, vous devez vérifier si la sauvegarde de la mémoire a fonctionné correctement. Au minimum, dans le pseudo- /proc/iomem mémoire requise doit être marquée comme "réservée" (lors de l'utilisation de /dev/mem ou phram ) ou comme "Mémoire persistante (héritée)".

Même lorsque vous utilisez phram ou nd_e820 vous devez vous assurer que le périphérique /dev/mtd0 ou /dev/pmem0 fait vraiment référence à la zone de mémoire précédemment réservée, et non à autre chose.

 # cat /sys/class/mtd/mtd0/name #  : "savedkey" # cat /sys/block/pmem0/device/resource #     

Si ce n'est pas le cas, vous devez trouver lequel des périphériques /dev/mtd* ou /dev/pmem* "le nôtre", puis corriger / etc / crypttab, régénérer initramfs et revérifier le résultat après un autre redémarrage.

Septième étape: configurer la copie du fichier clé dans la mémoire

Le fichier clé sera copié en mémoire avant de redémarrer. L'une des façons d'exécuter une commande au stade de l'arrêt du système consiste à l'enregistrer dans la directive ExecStop du service systemd. Pour que systemd comprenne qu'il ne s'agit pas d'un démon et ne jure pas de l'absence de la directive ExecStart , vous devez spécifier le type de service en tant que oneshot et suggérer également que le service est considéré comme en cours d'exécution, même si aucun processus de travail ne lui est associé. Voici donc le fichier /etc/systemd/system/savekey.service . Il est nécessaire de ne laisser qu'une des variantes données de la directive ExecStop .

 [Unit] Description=Saving LUKS key into RAM Documentation=https://habr.com/ru/post/457396/ [Service] Type=oneshot RemainAfterExit=true #   /dev/mem: ExecStop=/bin/sh -c 'dd if=/root/key of=/dev/mem bs=1 seek=$((0x10000000))' #   /dev/mtd0: ExecStop=/bin/dd if=/root/key of=/dev/mtd0 #   /dev/pmem0: ExecStop=/bin/dd if=/root/key of=/dev/pmem0 [Install] WantedBy=default.target 

La construction avec /bin/sh nécessaire car dd ne comprend pas la notation hexadécimale.

Nous activons le service, vérifions:

 # systemctl enable savekey # systemctl start savekey # reboot 

Lors du redémarrage suivant, vous n'avez pas besoin de saisir la phrase secrète à partir du disque. Et si nécessaire, cela signifie généralement que l'adresse de début de la zone de mémoire réservée n'est pas sélectionnée correctement. Vous pouvez corriger et régénérer plusieurs fichiers et redémarrer l'ordinateur deux fois.

Lorsque vous utilisez phram ou nd_e820 seule la configuration GRUB devra être modifiée. Lorsque vous utilisez /dev/mem adresse de départ est également mentionnée dans /etc/crypttab (par conséquent, initramfs devra être régénéré) et dans le service systemd.

Mais ce n'est pas tout.

Problèmes de sécurité

Toute discussion sur les problèmes de sécurité est basée sur un modèle de menace. C'est-à-dire sur les buts et les moyens de l'attaquant. Je suis conscient que certains des exemples ci-dessous sont farfelus.

Les situations avec un accès physique à un ordinateur éteint ne sont pas différentes de celles sans stockage de clé configuré en mémoire. Il existe les mêmes types d'attaques visant à obtenir des phrases clés, y compris Evil Maid , et les mêmes fonctionnalités de sécurité . Nous ne nous arrêtons pas à eux, car il n'y a rien de nouveau.

Les situations les plus intéressantes sont lorsque l'ordinateur est allumé.

Situation 1 . L'attaquant n'a pas d'accès physique à l'ordinateur, ne connaît pas la phrase secrète, mais dispose d'un accès root via ssh. L'objectif est la clé pour déchiffrer le disque. Par exemple, pour accéder aux anciennes sauvegardes secteur par secteur d'une image disque de machine virtuelle.

En fait, la clé de la soucoupe se trouve dans le fichier /root/key . La question est de savoir comment cela se rapporte à ce qui s'est passé avant la mise en œuvre de cette instruction. Réponse: pour luks1, la menace n'est pas nouvelle. Il existe une commande dmsetup table --target crypt --showkeys qui affiche la clé principale, c'est-à-dire également des données qui permettent d'accéder aux anciennes sauvegardes. Pour luks2, la réduction de sécurité dans ce scénario a vraiment lieu: les clés dm-crypt sont stockées dans le trousseau au niveau du noyau, et il est impossible de les regarder depuis l'espace utilisateur.

Situation 2 . L'attaquant peut utiliser le clavier et regarder l'écran, mais n'est pas prêt à ouvrir le boîtier. Par exemple, j'ai utilisé le mot de passe divulgué d'IPMI ou intercepté une session noVNC dans le cloud. Il ne connaît pas la phrase clé, il ne connaît pas d'autre mot de passe non plus. L'objectif est l'accès root.

Veuillez redémarrer via Ctrl-Alt-Del , l'ajout de l'option de noyau init=/bin/sh via GRUB est fait. La phrase secrète n'était pas nécessaire, car la clé a été lue avec succès dans la mémoire. Pour vous protéger de cela, vous devez empêcher GRUB de charger ce qui n'est pas dans le menu. Malheureusement, cette fonctionnalité est implémentée différemment dans différentes distributions.

À partir de la version 7.2, CentOS a la grub2-setpassword , qui protège réellement GRUB avec un mot de passe. D'autres distributions peuvent avoir leurs propres utilitaires pour la même tâche. Si ce n'est pas le cas, vous pouvez directement modifier les fichiers dans le répertoire grub.cfg et régénérer grub.cfg .

Dans le fichier /etc/grub.d/10_linux , changez la variable CLASS, ajoutez l'option --unrestricted à la fin, si elle n'était pas là:

 CLASS="--class gnu-linux --class gnu --class os --unrestricted" 

Dans le fichier /etc/grub.d/40_custom , ajoutez les lignes spécifiant le nom d'utilisateur et le mot de passe nécessaires pour modifier la ligne de commande du noyau:

 set superusers="root" password_pbkdf2 root grub.pbkdf2....... #    grub2-mkpasswd-pbkdf2 

Ou, si une telle fonctionnalité doit être désactivée, voici une ligne comme celle-ci:

 set superusers="" 

Situation 3 . L'attaquant a accès à l'ordinateur inclus, vous permettant de démarrer à partir d'un média non fiable. Il peut s'agir d'un accès physique sans ouvrir le boîtier ou d'un accès via IPMI. L'objectif est l'accès root.

Il peut charger son GRUB à partir d'un lecteur flash USB ou d'un CD-ROM et ajouter init=/bin/sh à vos paramètres de noyau, comme dans l'exemple précédent. En conséquence, le démarrage à partir de tout support horrible doit être interdit dans le BIOS. Et protégez également les changements de paramètres du BIOS avec un mot de passe.

Situation 4 . L'attaquant a un accès physique à l'ordinateur inclus, y compris la possibilité d'ouvrir le boîtier. Le but est de trouver la clé ou d'obtenir un accès root.

En général, c'est de toute façon une situation perdante. L'attaque des modules de mémoire en les refroidissant ( attaque de démarrage à froid ) n'a pas été annulée. Également théoriquement (ne pas cocher), vous pouvez profiter du fait que les disques SATA modernes prennent en charge la reconnexion à chaud. Lorsque l'ordinateur redémarre, déconnectez le disque, modifiez grub.cfg pour init=/bin/sh , reconnectez-vous, laissez le système redémarrer. Il s'avère (si je comprends bien) l'accès root.

À peu près la même chose peut être faite par un employé peu scrupuleux d'un hébergement cloud en créant un instantané d'une machine virtuelle avec sa modification ultérieure.

AUTRES QUESTIONS

Garder la clé en mémoire lors d'un redémarrage est une moquerie. Utilisation après libération dans sa forme la plus pure. Une solution plus propre consiste à utiliser kexec et à ajouter la clé aux initramfs générés dynamiquement. Il protège également contre le remplacement des paramètres du noyau . Oui, si kexec fonctionne. Les distributions modernes ont rendu la configuration de kexec trop compliquée .

Dans les centres de données, et plus encore dans le cloud, l'alimentation ne disparaît jamais. Il s'avère que la phrase clé n'est plus nécessaire? En effet, si vous en êtes si sûr, vous pouvez le supprimer. Il se révélera être un serveur qui fonctionne, la clé du disque dont personne ne sait¹ et ne sera donc pas distribuée, mais le système sur lequel il peut être mis à jour régulièrement. — sudo poweroff .

¹ /root/key — , cron.

? IPMI, . IPMI Java. .

? SSH . ! . , sudo reboot , ?

, . SSH , . , , .