Ceci est la première partie d'une série d'articles de blog en 3 parties concernant l'utilisation de Kali sur les appareils Raspberry Pi. Ce premier article couvrira l'activation du chiffrement complet du disque (FDE) sur un Raspberry Pi, la deuxième partie couvrira la connexion à distance à celui-ci, et enfin, la troisième partie couvrira les problèmes de débogage que nous avons rencontrés lors de la rédaction de ces messages, afin que d'autres puissent apprendre comment faire donc aussi.

Avec tout ce qui s'est passé dans le monde ces dernières années, de plus en plus de personnes travaillent à distance. Nous ne faisons pas exception à cela, et aujourd'hui, nous allons revoir notre machine "boîte de dépôt", qui a été cryptée, ce qui rend plus difficile l'identification en cas de découverte .

L'objectif est de créer un "laisser derrière" autonome sans tête appareil qui, s'il est découvert, ne permet pas de comprendre facilement ce que nous faisions car nos données sont sécurisées de tout temps. Pour ce faire, nous utiliserons le chiffrement complet du disque (FDE) et lui permettrons d'être déverrouillé à distance (si l'appareil doit être redémarré pour une raison quelconque). Il y aura également la possibilité d'utiliser LUKS Nuke capacité si nous souhaitons rendre le disque inaccessible à tout moment une fois que nous en avons terminé. Nous le ferons sur un Raspberry Pi 4 modèle B +, mais il a également été testé sur un Raspberry Pi 3 modèle B également. Vous devriez pouvoir utiliser la plupart des marques/modèles d'appareils similaires, cela peut nécessiter quelques adaptations/ajustements créatifs afin de sécuriser votre propre système.

Il s'agit d'un processus mis à jour, car nous en avons déjà couvert une partie auparavant. Cette fois, nous incluons des développements supplémentaires, avec quelques contributions de la communauté. Nous aimerions remercier Richard Nelson (@unixabg) pour son script automatisé. Nous aborderons ce sujet après avoir suivi la méthode manuelle, car nous vous recommandons toujours de comprendre ce qui se passe sous le capot.

Vue d'ensemble de niveau supérieur

Avant de plonger dans les détails techniques de ce que nous allons accomplir, examinons rapidement nos objectifs que nous voulons atteindre et décomposons-les :

• Installer Kali Linux sur un Raspberry Pi 4 (ci-après appelé "RPi")
• Préparer le système pour un démarrage chiffré prêt pour le déverrouillage à distance du disque
• Configurez les clés SSH pour permettre le déverrouillage à distance (en utilisant initramfs et Dropbear)
• Sauvegarder toutes les données existantes
• Configurer les partitions chiffrées
• Restaurer nos données
• Piratage !

Cela peut sembler beaucoup, mais c'est assez simple même s'il y a quelques étapes. Une fois terminé, nous aurons un RPi qui :

• Démarrer
• Obtenir une adresse IP à partir de DHCP
• Attendez que nous nous connections via SSH à l'aide de clés
• Permettez-nous de fournir soit le déverrouillage LUKS, soit les phrases secrètes LUKS Nuke

Ensuite, lorsque nous en aurons fini avec tout ce que nous voulons faire, il ne nous reste plus qu'à le récupérer … à notre guise !

Installer Kali Linux sur un RPi

Si vous suivez, assurez-vous de savoir où vous imagez le fichier et remplacez /dev/sdX . Ne faites pas de copier/coller aveuglément !

Nous allons créer notre machine de boîte de dépôt sur une installation Kali existante. Il devrait être très facile d'utiliser d'autres distributions basées sur Debian, et assez simple pour d'autres systèmes d'exploitation (à l'exception des utilisateurs de Windows !)

Nous allons d'abord télécharger la dernière image stable de Kali RPi. Au moment d'écrire ces lignes, c'est Kali 2022.2. Nous avons également choisi l'image 64 bits, car nous avons plus de 4 Go de RAM et n'utilisons aucun HAT (Hardware Attached on Top). Les étapes pour 32 bits seraient les mêmes, après avoir ajusté les noms de fichiers :

$ wget https://kali.download/arm-images/kali-2022.2/kali-linux-2022.2-raspberry-pi-arm64.img.xz
$ xzcat kali-linux-2022.2-raspberry-pi-arm64.img.xz | sudo dd of=/dev/sdX bs=512k status=progress

Préparation du système

Préparer le chroot

Nous allons ensuite préparer les choses pour un chroot. Créons l'endroit où nous voulons monter la carte microSD, puis montons-la :

$ sudo mkdir -vp /mnt/chroot/
$ sudo mount /dev/sdX2 /mnt/chroot/
$ sudo mount /dev/sdX1 /mnt/chroot/boot/
$ sudo mount -t proc none /mnt/chroot/proc
$ sudo mount -t sysfs none /mnt/chroot/sys
$ sudo mount -o bind /dev /mnt/chroot/dev
$ sudo mount -o bind /dev/pts /mnt/chroot/dev/pts
$ sudo apt install -y qemu-user-static
$ sudo cp /usr/bin/qemu-aarch64-static /mnt/chroot/usr/bin/

Les deux dernières commandes seront utiles pour initramfs plus tard.

Installation des packages requis

Maintenant que notre système est configuré, nous pouvons utiliser le chroot pour configurer l'image RPi pour le chiffrement. Entrons d'abord dans le chroot et installons quelques packages nécessaires :

$ sudo env LANG=C chroot /mnt/chroot/
┌──(root㉿kali)-[/]
└─# apt update

┌──(root㉿kali)-[/]
└─# apt install -y busybox cryptsetup dropbear-initramfs lvm2

Nous voulons nous assurer que nous sommes sur le dernier noyau avant de commencer, alors assurons-nous également qu'ils sont installés :

┌──(root㉿kali)-[/]
└─# apt install -y kalipi-kernel kalipi-bootloader kalipi-re4son-firmware

Options de démarrage

Ensuite, nous allons modifier /boot/cmdline.txt et modifier le chemin racine. Le /boot/cmdline.txt fichier sur un périphérique RPi est utilisé pour transmettre les options de ligne de commande du noyau. Nous voudrons changer le chemin racine pour être /dev/mapper/crypt , puis nous ajouterons cryptdevice=PARTUUID=$partuuid:crypt juste après.

La raison en est que le noyau a besoin de savoir où se trouve le système de fichiers racine, afin de le monter et de l'utiliser, et puisque nous chiffrons le rootfs plus tard dans le post, pendant le démarrage, il ne peut pas non plus voir le périphérique non chiffré , à cause du cryptage ! Pendant que nous changeons le nom ici en "crypte", vous pouvez l'appeler comme vous voulez.

Le résultat final devrait ressembler à ceci :

┌──(root㉿kali)-[/]
└─# vim /boot/cmdline.txt

┌──(root㉿kali)-[/]
└─# cat /boot/cmdline.txt
dwc_otg.fiq_fix_enable=2 console=serial0,115200 kgdboc=serial0,115200 console=tty1 root=/dev/mapper/crypt cryptdevice=PARTUUID=ed889dad-02:crypt rootfstype=ext4 fsck.repair=yes rootwait net.ifnames=0

Disposition des partitions

Nous devons maintenant mettre à jour le /etc/fstab fichier, il s'agit d'un fichier de configuration sur le système qui contient tous les disques disponibles, les partitions de disque et les options à utiliser lors de leur manipulation.

Actuellement, il est rempli avec l'UUID du système de fichiers racine, et nous en avons besoin pour pointer vers le système de fichiers chiffré que nous allons créer. Dans cet exemple, nous avons commenté l'UUID du périphérique racine précédent et pointé sur /dev/mapper/crypt c'est ce que notre système de fichiers chiffré montera une fois que nous l'aurons créé :

┌──(root㉿kali)-[/]
└─# vim /etc/fstab

┌──(root㉿kali)-[/]
└─# cat /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults          0       0

/dev/mapper/crypt /               ext4 errors=remount-ro 0       0
#UUID=747bfa7c-edd2-471f-8fff-0ecafc2d3791 /               ext4 errors=remount-ro 0       1
LABEL=BOOT      /boot           vfat    defaults          0       2

Configurer les partitions chiffrées

Lors de l'utilisation de partitions chiffrées, nous devons modifier ou créer, s'il n'existe pas, le /etc/crypttab fichier, qui est utilisé par cryptsetup pour savoir quelles options sont nécessaires pour déverrouiller l'appareil chiffré.

Comme ce fichier n'existe pas, nous allons créer le /etc/crypttab fichier, et remplissez-le avec les options dont nous avons besoin :

┌──(root㉿kali)-[/]
└─# echo -e 'crypt\tPARTUUID=ed889dad-02\tnone\tluks' > /etc/crypttab

Maintenant, nous faisons une petite astuce avec le système de fichiers. Nous créons un faux système de fichiers LUKS qui permettra à cryptsetup d'être inclus dans initramfs car il voit une partition chiffrée. Lorsque vous formatez des partitions LUKS, vous serez invité à entrer un mot de passe, et bien que vous utilisiez normalement un mot de passe fort, car nous ne l'utilisons que comme un hack pour inclure cryptsetup dans notre initramfs, le mot de passe que vous créez à cette invite ne sera pas être nécessaire ou utilisé après ces étapes, vous pouvez donc le définir sur quelque chose de court/rapide à taper. Cela se produira au cryptsetup luksFormat étape, et vous serez invité à entrer le mot de passe que vous avez défini pendant cryptsetup luksFormat lorsque vous exécutez le cryptsetup luksOpen étape.

Vous ne verrez aucune entrée saisie lors de la saisie du mot de passe

┌──(root㉿kali)-[/]
└─# dd if=/dev/zero of=/tmp/fakeroot.img bs=1M count=20

┌──(root㉿kali)-[/]
└─# exit
$ sudo cryptsetup luksFormat /mnt/chroot/tmp/fakeroot.img
$ sudo cryptsetup luksOpen /mnt/chroot/tmp/fakeroot.img crypt
$ sudo mkfs.ext4 /dev/mapper/crypt

Configuration des clés SSH

Après cela, nous devons copier OU générer une nouvelle clé ssh à ajouter au authorized_keys de Dropbear. fichier.

Si nous avons déjà une clé existante à copier :

$ sudo cp ~/.ssh/id_rsa.pub /mnt/chroot/

Alternativement pour générer une nouvelle clé :

$ ssh-keygen -t rsa -b 4096
[...]
Enter file in which to save the key (/home/kali/.ssh/id_rsa): /home/kali/.ssh/id_rsa_dropbear
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/kali/.ssh/id_rsa_dropbear
Your public key has been saved in /home/kali/.ssh/id_rsa_dropbear.pub
[...]
$ sudo cp ~/.ssh/id_rsa_dropbear.pub /mnt/chroot/

Vous ne verrez aucune entrée saisie lors de la saisie d'une phrase de passe

Configuration du chiffrement

Pour en revenir au chroot, nous devons créer quelques nouveaux fichiers.

Le premier est le zz-cryptsetup crochet qui ajoute les fichiers dont nous avons besoin pour cryptsetup dans le initramfs . Pour que cela fonctionne, il doit être marqué comme exécutable afin que mkinitramfs lancera le hook :

$ sudo env LANG=C chroot /mnt/chroot/
┌──(root㉿kali)-[/]
└─# vim /etc/initramfs-tools/hooks/zz-cryptsetup

┌──(root㉿kali)-[/]
└─# cat /etc/initramfs-tools/hooks/zz-cryptsetup
#!/bin/sh
set -e

PREREQ=""
prereqs()
{
	echo "${PREREQ}"
}

case "${1}" in
	prereqs)
		prereqs
		exit 0
		;;
esac

. /usr/share/initramfs-tools/hook-functions

mkdir -p ${DESTDIR}/cryptroot || true
cat /etc/crypttab >> ${DESTDIR}/cryptroot/crypttab
cat /etc/fstab >> ${DESTDIR}/cryptroot/fstab
cat /etc/crypttab >> ${DESTDIR}/etc/crypttab
cat /etc/fstab >> ${DESTDIR}/etc/fstab
copy_file config /etc/initramfs-tools/unlock.sh /etc/unlock.sh

┌──(root㉿kali)-[/]
└─# chmod +x /etc/initramfs-tools/hooks/zz-cryptsetup

Si vous souhaitez le désactiver à tout moment dans le futur pour une raison quelconque, supprimez simplement le bit exécutable.

Nous éditons le fichier modules pour initramfs-tools pour que nous incluions le dm-crypt module, et cat le fichier pour vérifier qu'il est correct :

┌──(root㉿kali)-[/]
└─# grep -q dm_crypt /etc/initramfs-tools/modules || echo dm_crypt >> /etc/initramfs-tools/modules

┌──(root㉿kali)-[/]
└─# cat /etc/initramfs-tools/modules
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax:  module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod
dm_crypt

Configuration du déverrouillage SSH à distance

Créer un unlock.sh script avec le contenu suivant, puis marquez-le comme exécutable afin que le script s'exécute dans le initramfs :

┌──(root㉿kali)-[/]
└─# vim /etc/initramfs-tools/unlock.sh

┌──(root㉿kali)-[/]
└─# cat /etc/initramfs-tools/unlock.sh
#!/bin/sh

export PATH='/sbin:/bin:/usr/sbin:/usr/bin'

while true; do
	test -e /dev/mapper/crypt && break || cryptsetup luksOpen /dev/disk/by-uuid/$REPLACE_LATER crypt
done

/scripts/local-top/cryptroot
for i in $(ps aux | grep 'cryptroot' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep 'askpass' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep 'ask-for-password' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep '\\-sh' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
exit 0

┌──(root㉿kali)-[/]
└─# chmod +x /etc/initramfs-tools/unlock.sh

Ensuite, nous devons ajouter ce qui suit au début de /etc/dropbear/initramfs/authorized_keys , qui lui dit d'exécuter cette commande lorsque nous nous connectons en SSH si la clé correspond :

┌──(root㉿kali)-[/]
└─# vim /etc/dropbear/initramfs/authorized_keys

┌──(root㉿kali)-[/]
└─# cat /etc/dropbear/initramfs/authorized_keys
command="/etc/unlock.sh; exit"

Après cela, nous pouvons ajouter la clé SSH que nous avons copiée, puis la supprimer de la carte :

┌──(root㉿kali)-[/]
└─# cat id_rsa.pub >> /etc/dropbear/initramfs/authorized_keys && rm -v id_rsa.pub

Une fois que vous avez terminé, /etc/dropbear/initramfs/authorized_keys devrait ressembler à ceci :

┌──(root㉿kali)-[/]
└─# cat /etc/dropbear/initramfs/authorized_keys
command="/etc/unlock.sh; exit" ssh-rsa <key> [email protected]

Tout dans le authorized_keys le fichier doit être une ligne, ainsi qu'un espace entre la fin de la commande " et la clé ssh (par exemple [...]exit" ssh-rsa[...] )

Nous devons maintenant modifier /usr/share/initramfs-tools/scripts/init-premount/dropbear pour ajouter une minuterie de mise en veille, cela permet au réseau de démarrer avant Dropbear le fait. Il est important de noter que lorsqu'il y a des mises à jour du dropbear-initramfs package, cette modification devra être rajoutée :

┌──(root㉿kali)-[/]
└─# vim /usr/share/initramfs-tools/scripts/init-premount/dropbear

┌──(root㉿kali)-[/]
└─# cat /usr/share/initramfs-tools/scripts/init-premount/dropbear
[ "$BOOT" != nfs ] || configure_networking
sleep 5
run_dropbear &
echo $! >/run/dropbear.pid

Maintenant, nous activons cryptsetup :

┌──(root㉿kali)-[/]
└─# echo CRYPTSETUP=y >> /etc/cryptsetup-initramfs/conf-hook

┌──(root㉿kali)-[/]
└─# tail /etc/cryptsetup-initramfs/conf-hook
#
# Whether to include the askpass binary to the initramfs image.  askpass
# is required for interactive passphrase prompts, and ASKPASS=y (the
# default) is implied when the hook detects that same device needs to be
# unlocked interactively (i.e., not via keyfile nor keyscript) at
# initramfs stage.  Setting ASKPASS=n also skips `cryptroot-unlock`
# inclusion as it requires the askpass executable.

#ASKPASS=y
CRYPTSETUP=y

Noyau

La prochaine étape est importante pour les personnes qui suivent. Ce qu'il faut sélectionner, dépend de l'appareil RPi que vous utilisez, . Vous trouverez ci-dessous cinq noms/éditions/saveurs de noyau dont vous devez sélectionner l'un pour vos besoins (veuillez faire attention !) :

• Re4son+ est pour les appareils ARMEL armv6 32 bits - c'est-à-dire RPi1, RPi0 ou RPi0w
• Re4son-v7+ est pour les appareils ARMHF armv7 32 bits - c'est-à-dire RPi2 v1.2, RPi3 ou RPi02w
• Re4son-v8+ est pour les appareils ARM64 armv8 64 bits - c'est-à-dire RPi2 v1.2, RPi3 ou RPi02w
• Re4son-v7l+ est pour les appareils ARMHF armv7 32 bits - c'est-à-dire les appareils RPi4 ou RPi400
• Re4son-v8l+ est pour les appareils ARM64 armv8 64 bits - c'est-à-dire les appareils RPi4 ou RPi400

Le l dans le nom signifie lpae - Large Physical Address Extension

Pour rappel, nous utilisons l'image RPi4, 64 bits. Nous aurions donc besoin de Re4son-v8l+ . Assurez-vous de vous adapter à votre appareil. Maintenant que nous savons quel nom de noyau utiliser, nous devons maintenant trouver quelle version du noyau. Cela changera d'un appareil à l'autre, et cela changera également au fur et à mesure que Kali recevra des mises à jour Au moment de la rédaction, il s'agit de 5.15.44 pour notre RPi :

Gardez à l'esprit que les versions du noyau peuvent changer, mais pas le nom :

┌──(root㉿kali)-[/]
└─# ls -l /lib/modules/ | awk -F" " '{print $9}'
5.15.44-Re4son+
5.15.44-Re4son-v7+
5.15.44-Re4son-v7l+
5.15.44-Re4son-v8+
5.15.44-Re4son-v8l+

┌──(root㉿kali)-[/]
└─# echo "initramfs initramfs.gz followkernel" >> /boot/config.txt

Gardez à l'esprit les versions du noyau (5.15.44 ) peut changer, cependant le nom du noyau (Re4son-v8l+ ) ne le fera pas.

Maintenant, nous devons créer le initramfs . C'est là que la version du noyau entre en jeu :

┌──(root㉿kali)-[/]
└─# mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+

Maintenant, nous voulons nous assurer que nous avons créé le initramfs correctement. S'il n'y a pas de résultat, alors quelque chose s'est mal passé :

┌──(root㉿kali)-[/]
└─# lsinitramfs /boot/initramfs.gz | grep cryptsetup
usr/lib/aarch64-linux-gnu/libcryptsetup.so.12
usr/lib/aarch64-linux-gnu/libcryptsetup.so.12.7.0
usr/lib/cryptsetup
usr/lib/cryptsetup-nuke-password
usr/lib/cryptsetup-nuke-password/crypt
usr/lib/cryptsetup/askpass
usr/lib/cryptsetup/askpass.cryptsetup
usr/lib/cryptsetup/functions
usr/sbin/cryptsetup

┌──(root㉿kali)-[/]
└─# lsinitramfs /boot/initramfs.gz | grep authorized
root-Q2iWOODUwk/.ssh/authorized_keys

┌──(root㉿kali)-[/]
└─# lsinitramfs /boot/initramfs.gz | grep unlock.sh
etc/unlock.sh

Désactiver les services

Avant de pouvoir sauvegarder, nous devons nous assurer que rpi-resizerootfs est désactivé. Il s'agit d'un service que nous exécutons généralement sur tous nos périphériques ARM qui redimensionne la partition racine du système de fichiers pour augmenter la taille de la partition à la taille complète du périphérique de stockage sur lequel elle se trouve. Puisque nous effectuons cette étape manuellement, nous voulons la désactiver, afin qu'elle ne supprime pas potentiellement notre système de fichiers racine et ne le recrée pas.

┌──(root㉿kali)-[/]
└─# systemctl disable rpi-resizerootfs

Sauvegarder toutes les données existantes

Nous pouvons maintenant nous assurer que toutes les modifications sont écrites, puis nous pouvons chiffrer le disque :

┌──(root㉿kali)-[/]
└─# sync

┌──(root㉿kali)-[/]
└─# exit
$ sudo umount /mnt/chroot/{boot,sys,proc,dev/pts,dev}
$ sudo mkdir -vp /mnt/{backup,encrypted}
$ sudo rsync -avh /mnt/chroot/* /mnt/backup/
$ sudo cryptsetup luksClose crypt
$ sudo umount /mnt/chroot
$ echo -e "d\n2\nw" | sudo fdisk /dev/sdX
$ echo -e "n\np\n2\n\n\nw" | sudo fdisk /dev/sdX

Configurer les partitions chiffrées

Selon l'appareil que vous utilisez, vous devrez utiliser l'une des deux commandes. Si vous utilisez un RPi4 avec 4 Go ou plus, utilisez cette commande :

$ sudo cryptsetup -v -y --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdX2

Sinon, vous voudrez utiliser ce qui suit qui utilise une ancienne version de LUKS :

$ sudo cryptsetup -v -y --pbkdf pbkdf2 --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdX2

Restaurer nos données

Ensuite, vous pouvez terminer la restauration des données sur la partition désormais chiffrée :

$ sudo cryptsetup -v luksOpen /dev/sdX2 crypt
$ sudo mkfs.ext4 /dev/mapper/crypt
$ sudo mount /dev/mapper/crypt /mnt/encrypted/
$ sudo rsync -avh /mnt/backup/* /mnt/encrypted/
$ sync

Les étapes finales que nous devons faire sont de réparer le /etc/fstab fichier pour le nouvel UUID LUKS, ou vous pouvez le laisser sous la forme /dev/mapper/crypt et remplacez l'UUID dans notre script de déverrouillage et recréez le fichier initramfs, cette étape est importante car elle ne démarrera pas correctement si elle n'est pas effectuée, car elle n'aura pas les informations nécessaires pour utiliser le système de fichiers chiffré ! N'oubliez pas de mettre les informations de VOTRE système, car l'UUID sera différent pour chaque système :

$ sudo mount /dev/sdX1 /mnt/encrypted/boot/
$ sudo mount -t proc none /mnt/encrypted/proc
$ sudo mount -t sysfs none /mnt/encrypted/sys
$ sudo mount -o bind /dev /mnt/encrypted/dev
$ sudo mount -o bind /dev/pts /mnt/encrypted/dev/pts
$ sudo env LANG=C chroot /mnt/encrypted
┌──(root㉿kali)-[/]
└─# blkid /dev/sdX2
/dev/sdX2: UUID="173e2de4-0501-4d8e-9039-a4923bfa5ee7" TYPE="crypto_LUKS" PARTUUID="e1750e08-02"

┌──(root㉿kali)-[/]
└─# cat /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults          0       0

UUID=173e2de4-0501-4d8e-9039-a4923bfa5ee7 /               ext4 errors=remount-ro 0       1
LABEL=BOOT      /boot           vfat    defaults          0       2

┌──(root㉿kali)-[/]
└─# vim /etc/initramfs-tools/unlock.sh

┌──(root㉿kali)-[/]
└─# cat /etc/initramfs-tools/unlock.sh
#!/bin/sh

export PATH='/sbin:/bin:/usr/sbin:/usr/bin'

while true; do
	test -e /dev/mapper/crypt && break || cryptsetup luksOpen /dev/disk/by-uuid/173e2de4-0501-4d8e-9039-a4923bfa5ee7 crypt
done

/scripts/local-top/cryptroot
for i in $(ps aux | grep 'cryptroot' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep 'askpass' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep 'ask-for-password' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep '\\-sh' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
exit 0

┌──(root㉿kali)-[/]
└─# vim /etc/crypttab

┌──(root㉿kali)-[/]
└─# cat /etc/crypttab
crypt	PARTUUID=e1750e08-02	none	luks

┌──(root㉿kali)-[/]
└─# mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+

Si vous obtenez une erreur cryptsetup ici, semblable à cryptsetup: ERROR: Couldn't resolve device PARTUUID=ed889dad-02 cela signifie que vous n'avez pas modifié le /etc/crypttab fichier et mettez le PARTUUID correct. L'avertissement concernant l'absence de fsck.luks existant peut être ignoré, car il n'y a rien de tel.

Nous pouvons maintenant tout démonter et tout fermer :

┌──(root㉿kali)-[/]
└─# exit
$ sudo umount /mnt/encrypted/{boot,sys,proc,dev/pts,dev}
$ sudo umount /mnt/encrypted
$ sudo cryptsetup luksClose crypt

Plus tôt, nous avons mentionné la capacité LUKS Nuke. Si vous prévoyez de l'utiliser, tout en démarrant sur votre rootfs RPi fraîchement crypté, exécutez simplement la commande suivante pour ajouter le mot de passe Nuke et suivez l'invite :

[email protected]:~$ sudo dpkg-reconfigure cryptsetup-nuke-password

Restez à l'écoute pour la deuxième partie où nous couvrirons la connexion à distance au Raspberry Pi en tant qu'appareil Dropbox !

Automatiser !

Maintenant, que diriez-vous d'automatiser cela ? Grâce à Richard Nelson (@unixabg), tous ceux qui souhaitent configurer tout cela en beaucoup moins de temps que la méthode manuelle et beaucoup plus facilement, le peuvent !

Tout d'abord, téléchargeons le script cryptmypi d'unixabg :

$ git clone https://github.com/unixabg/cryptmypi.git
$ cd cryptmypi/

Cependant, il y a un certain nombre de choses que nous voulons faire avant de pouvoir exécuter les scripts de construction. Examinons-les ensemble maintenant :

$ cp cryptmypi.conf config/.
$ cat ~/.ssh/id_rsa.pub >> config/authorized_keys

Maintenant, nous devons éditer cryptmypi.conf pour modifier certains paramètres à l'étape 2. Ces paramètres seront personnels, mais donnons juste un exemple :

$ vim config/cryptmypi.conf
$ cat config/cryptmypi.conf
##################
## cryptmypi settings
##################
# export prefix for hooks
export _VER="2.2-beta"

# base and build
export _BASEDIR=$(pwd)
export _BUILDDIR=${_BASEDIR}/cryptmypi-build

##################
## Stage-1
##################
_IMAGEURL=https://kali.download/arm-images/kali-2022.2/kali-linux-2022.2-raspberry-pi-arm64.img.xz

# compose package actions
export _PKGSPURGE=""
export _PKGSINSTALL=""

# iodine settings
_IODINE_PASSWORD="your iodine password goes here"
_IODINE_DOMAIN="your iodine domain goes here"

# final package actions
export _FINALPKGPURGE=""
export _FINALPKGINSTALL="telnet dsniff bettercap"

##################
## Stage-2
##################
# block device
_BLKDEV="/dev/sdb"

# luks encryption cipher
_LUKSCIPHER="aes-cbc-essiv:sha256"

# luks encryption password
_LUKSPASSWD="toor"

# root password
export _ROOTPASSWD="toor"

Ce que nous avons changé ici, c'est le périphérique de bloc, le mot de passe de chiffrement LUKS et le mot de passe root. L'URL de l'image peut être modifiée si vous souhaitez utiliser un fichier image différent, alors assurez-vous de le faire maintenant si nécessaire.

Maintenant, la seule chose à faire est d'exécuter les scripts des deux étapes et de suivre les instructions. À la fin, vous aurez un système de fichiers entièrement crypté avec un accès Dropbear SSH !