Esta es la primera parte de una serie de 3 partes de publicaciones de blog sobre el uso de Kali en dispositivos Raspberry Pi. Esta primera publicación cubrirá la habilitación de Full Disk Encryption (FDE) en una Raspberry Pi, la segunda parte cubrirá la conexión remota y, finalmente, la tercera parte cubrirá los problemas de depuración que encontramos al hacer estas publicaciones, para que otros puedan aprender cómo hacerlo. así también.

Con todo lo que ha estado pasando en el mundo en los últimos años, más personas están trabajando de forma remota. No somos una excepción a esto, y hoy vamos a revisar nuestra máquina de "buzón", que ha sido encriptada, por lo que es más difícil de identificar si se descubre .

El objetivo es crear un headless independiente "dejar atrás" dispositivo que, si/cuando se descubre, no hace que sea fácil averiguar lo que estábamos haciendo ya que nuestros datos están seguros en todo momento. Para lograr esto, utilizaremos Full Disk Encryption (FDE) y permitiremos que se desbloquee de forma remota. (en caso de que el dispositivo se reinicie por algún motivo). También habrá la opción de usar LUKS Nuke capacidad en caso de que deseemos hacer que el disco sea inaccesible en cualquier momento después de que hayamos terminado con él. Haremos esto en una Raspberry Pi 4 Model B+, pero también se probó en una Raspberry Pi 3 Model B. Debería poder usar la mayoría de las marcas y modelos de dispositivos similares; es posible que solo requiera un poco de adaptaciones o ajustes creativos para proteger su propio sistema.

Este es un proceso actualizado ya que anteriormente hemos cubierto parte de esto. Esta vez incluimos desarrollos adicionales, con algunas contribuciones de la comunidad. Nos gustaría agradecer a Richard Nelson (@unixabg) por su script automatizado. Hablaremos de esto después de pasar por el método manual, ya que siempre recomendamos que comprenda lo que sucede debajo del capó.

Resumen de nivel superior

Antes de sumergirnos en los niveles más bajos de los detalles técnicos de lo que vamos a lograr, echemos un vistazo rápido a los objetivos que queremos lograr y desglosarlos:

• Instale Kali Linux en una Raspberry Pi 4 (en adelante, "RPi")
• Preparar el sistema para arranque encriptado listo para desbloqueo de disco remoto
• Configure las claves SSH para permitir que ocurra el desbloqueo remoto (usando initramfs y Dropbear)
• Copia de seguridad de los datos existentes
• Configurar las particiones cifradas
• Restaurar nuestros datos
• Hackear !

Esto puede parecer mucho, pero es bastante sencillo incluso si hay unos pocos pasos. Una vez completado, tendremos un RPi que:

• Arranque
• Obtener una IP de DHCP
• Espere a que nos conectemos vía SSH usando claves
• Permítanos proporcionar el desbloqueo de LUKS o las frases de contraseña de LUKS Nuke

Luego, en el futuro, cuando hayamos terminado con lo que sea que queramos hacer, ¡lo único que queda es recuperarlo …en nuestro tiempo libre!

Instalación de Kali Linux en una RPi

Si está siguiendo, asegúrese de saber dónde está creando la imagen del archivo y reemplace /dev/sdX . ¡No copie/pegue a ciegas!

Crearemos nuestra máquina de buzón en una instalación Kali existente. Debería ser muy fácil usar otras distribuciones basadas en Debian y bastante sencillo para otros sistemas operativos (¡excepto los usuarios de Windows!)

Primero descargaremos la última imagen estable de Kali RPi. Al momento de escribir, eso es Kali 2022.2. También elegimos la imagen de 64 bits, ya que tenemos más de 4 GB de RAM y no usamos ningún HAT (hardware adjunto en la parte superior). Los pasos para 32 bits serían los mismos, después de ajustar los nombres de archivo:

$ 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

Preparando el sistema

Preparando el chroot

A continuación, prepararemos las cosas para un chroot. Vamos a crear dónde queremos montar la tarjeta microSD, luego montarla:

$ 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/

Los dos últimos comandos serán útiles listos para initramfs más adelante.

Instalación de paquetes necesarios

Ahora que nuestro sistema está configurado, podemos usar el chroot para configurar la imagen RPi para el cifrado. Primero ingresemos al chroot e instalemos algunos paquetes necesarios:

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

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

Queremos asegurarnos de que estamos en el kernel más reciente antes de comenzar, así que también asegurémonos de tenerlos instalados:

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

Opciones de arranque

A continuación vamos a editar /boot/cmdline.txt y cambiar la ruta raíz. El /boot/cmdline.txt El archivo en un dispositivo RPi se usa para pasar las opciones de la línea de comandos del kernel. Querremos cambiar la ruta raíz para que sea /dev/mapper/crypt , y luego agregaremos cryptdevice=PARTUUID=$partuuid:crypt justo después de eso.

La razón de esto es que el núcleo necesita saber dónde está el sistema de archivos raíz para poder montarlo y usarlo, y dado que estamos encriptando el rootfs más adelante en la publicación, durante el arranque tampoco puede ver el dispositivo no encriptado. , debido a la encriptación! Mientras cambiamos el nombre aquí a "crypt", puedes llamarlo como quieras.

El resultado final debería verse así:

┌──(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

Diseño de partición

Ahora necesitamos actualizar el /etc/fstab archivo, este es un archivo de configuración en el sistema que contiene todos los discos disponibles, particiones de disco y qué opciones usar al manejarlos.

Actualmente se completa con el UUID del sistema de archivos raíz y necesitamos que apunte al sistema de archivos encriptado que crearemos. En este ejemplo, hemos comentado cuál es el UUID del dispositivo raíz anterior y apuntamos a /dev/mapper/crypt que es como se montará nuestro sistema de archivos cifrados, una vez que lo creamos:

┌──(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

Configure las particiones cifradas

Cuando usamos particiones encriptadas, necesitamos editar o crear, si no existe, el /etc/crypttab archivo, que cryptsetup utiliza para saber qué opciones se necesitan para desbloquear el dispositivo cifrado.

Como este archivo no existe, crearemos el /etc/crypttab y rellénelo con las opciones que necesitamos:

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

Ahora hacemos un pequeño truco con el sistema de archivos. Creamos un sistema de archivos LUKS falso que permitirá que cryptsetup se incluya en initramfs porque ve una partición cifrada. Cuando formatee cualquier partición LUKS, se le solicitará una contraseña y, aunque normalmente utilizará una contraseña segura, ya que solo estamos usando esto como un truco para incluir cryptsetup en nuestro initramfs, la contraseña que cree en este indicador no ser necesario o utilizado más allá de estos pasos, por lo que puede configurarlo en algo corto/rápido para escribir. Esto sucederá en el cryptsetup luksFormat paso, y se le pedirá la contraseña que estableció durante cryptsetup luksFormat cuando ejecutas el cryptsetup luksOpen paso.

No verá que se escriba ninguna entrada al ingresar la contraseña

┌──(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

Configuración de claves SSH

Después de eso, debemos copiar O generar una nueva clave ssh para agregarla al authorized_keys de Dropbear archivo.

Si ya tenemos una clave existente para copiar:

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

Alternativamente para generar una nueva clave:

$ 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/

No verá que se escriba ninguna entrada al ingresar una frase de contraseña

Configuración para encriptación

Volviendo al chroot, necesitamos crear algunos archivos nuevos.

Primero está el zz-cryptsetup gancho que agrega los archivos que necesitamos para cryptsetup en el initramfs . Para que funcione, debe marcarse como ejecutable para que mkinitramfs ejecutará el gancho:

$ 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 desea desactivarlo en algún momento en el futuro por cualquier motivo, simplemente elimine el bit ejecutable.

Editamos el archivo de módulos para initramfs-tools para que incluyamos el dm-crypt module, y busque el archivo para verificar que sea correcto:

┌──(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

Configuración de desbloqueo SSH remoto

Crea un unlock.sh script con los siguientes contenidos y luego márquelo como ejecutable para que el script se ejecute en el 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

A continuación debemos añadir lo siguiente al principio de /etc/dropbear/initramfs/authorized_keys , que le dice que ejecute este comando cuando ingresemos SSH si la clave coincide:

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

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

Después de hacerlo, podemos agregar la clave SSH que copiamos y luego eliminarla de la tarjeta:

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

Una vez que hayas terminado, /etc/dropbear/initramfs/authorized_keys debería verse así:

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

Todo en el authorized_keys El archivo debe tener una línea, así como un espacio entre el final del comando " y la clave ssh (por ejemplo, [...]exit" ssh-rsa[...] )

Ahora necesitamos editar /usr/share/initramfs-tools/scripts/init-premount/dropbear para agregar un temporizador de suspensión, esto permite que la red comience antes Dropbear lo hace. Es importante tener en cuenta que cuando haya actualizaciones en el dropbear-initramfs paquete, será necesario volver a agregar esta edición:

┌──(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

Ahora habilitamos 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

Núcleo

El siguiente paso es importante para las personas que lo siguen. Qué seleccionar, depende del dispositivo RPi que esté utilizando, será . A continuación hay cinco nombres/ediciones/sabores de kernel de los cuales debe seleccionar uno para sus necesidades (¡preste atención!) :

• Re4son+ es para dispositivos ARMEL armv6 de 32 bits, es decir, RPi1, RPi0 o RPi0w
• Re4son-v7+ es para dispositivos ARMHF armv7 de 32 bits, es decir, RPi2 v1.2, RPi3 o RPi02w
• Re4son-v8+ es para dispositivos ARM64 armv8 de 64 bits, es decir, RPi2 v1.2, RPi3 o RPi02w
• Re4son-v7l+ es para dispositivos ARMHF armv7 de 32 bits, es decir, dispositivos RPi4 o RPi400
• Re4son-v8l+ es para dispositivos ARM64 armv8 de 64 bits, es decir, dispositivos RPi4 o RPi400

El l en el nombre significa lpae - Extensión de dirección física grande

Como recordatorio, estamos usando la imagen RPi4 de 64 bits. Entonces necesitaríamos Re4son-v8l+ . Asegúrese de ajustarse a su dispositivo. Entonces, ahora que sabemos qué nombre de kernel usar, ahora necesitamos encontrar qué versión de kernel. Esto cambiará de un dispositivo a otro, y también cambiará a medida que Kali reciba actualizaciones. Al momento de escribir, es 5.15.44 para nuestro RPi:

Tenga en cuenta que las versiones del kernel pueden cambiar, sin embargo, el nombre no:

┌──(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

Tenga en cuenta las versiones del kernel (5.15.44 ) puede cambiar, sin embargo, el nombre del kernel (Re4son-v8l+ ) no lo hará.

Ahora necesitamos crear el initramfs . Aquí es donde entra en juego la versión del kernel:

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

Ahora queremos asegurarnos de haber creado el initramfs correctamente. Si no hay ningún resultado, entonces algo salió mal:

┌──(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

Deshabilitar servicios

Antes de que podamos hacer una copia de seguridad, debemos asegurarnos de que rpi-resizerootfs está desactivado. Este es un servicio que normalmente ejecutamos en todos nuestros dispositivos ARM que cambia el tamaño de la partición del sistema de archivos raíz para aumentar el tamaño de la partición al tamaño completo del dispositivo de almacenamiento en el que se encuentra. Como estamos haciendo este paso manualmente, queremos deshabilitarlo, para que no elimine potencialmente nuestro sistema de archivos raíz y lo vuelva a hacer.

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

Copia de seguridad de cualquier dato existente

Ahora podemos asegurarnos de que se escriben todos los cambios, luego podemos cifrar el disco:

┌──(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

Configurar las particiones cifradas

Dependiendo del dispositivo que esté usando, tendrá que usar uno de dos comandos. Si está usando un RPi4 con 4GB o más, use este comando:

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

De lo contrario, querrá usar lo siguiente que usa una versión anterior de LUKS:

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

Restaurar nuestros datos

Luego puede terminar de restaurar los datos a la partición ahora encriptada:

$ 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

Los pasos finales que tenemos que hacer son arreglar el /etc/fstab archivo para el nuevo UUID de LUKS, o puede dejarlo como /dev/mapper/crypt y reemplace el UUID en nuestro script de desbloqueo y rehaga el archivo initramfs, este paso es importante ya que no se iniciará correctamente si no se realiza, ¡porque no tendrá la información para usar el sistema de archivos encriptado! Recuerda poner la información de TU sistema, ya que el UUID será diferente para cada sistema:

$ 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 obtiene un error de configuración de cifrado aquí, similar a cryptsetup: ERROR: Couldn't resolve device PARTUUID=ed889dad-02 eso significa que no editaste el /etc/crypttab e ingrese el PARTUUID correcto. La advertencia sobre la ausencia de fsck.luks puede ignorarse, ya que no existe tal cosa.

Ahora podemos desmontar y cerrar todo:

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

Anteriormente, mencionamos la capacidad de LUKS Nuke. Si planea usarlo, mientras arranca en sus rootfs RPi recién encriptados, simplemente ejecute el siguiente comando para agregar la contraseña de Nuke y siga las instrucciones:

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

¡Estén atentos a la segunda parte donde cubrimos la conexión remota a Raspberry Pi como un dispositivo de Dropbox!

¡Automatizar!

Ahora, ¿qué tal si automatizamos esto? Gracias a Richard Nelson (@unixabg), ¡cualquiera que quiera configurar todo esto en mucho menos tiempo que con el método manual y mucho más fácil, puede hacerlo!

Lo primero es lo primero, descarguemos el script cryptmypi de unixabg:

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

Sin embargo, hay una serie de cosas que queremos hacer antes de poder ejecutar los scripts de compilación. Vamos a repasarlos juntos ahora:

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

Ahora necesitamos editar cryptmypi.conf para cambiar algunos ajustes en la etapa 2. Estas configuraciones serán personales, pero vamos a darles un ejemplo:

$ 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"

Lo que cambiamos aquí es el dispositivo de bloqueo, la contraseña de cifrado de LUKS y la contraseña de root. La URL de la imagen se puede cambiar si desea utilizar un archivo de imagen diferente, así que asegúrese de hacerlo ahora si es necesario.

Ahora lo único que queda por hacer es ejecutar los scripts de ambas etapas y seguir las instrucciones. ¡Al final, tendrá un sistema de archivos completamente encriptado con acceso Dropbear SSH!