Questa è la prima parte di una serie di 3 post sul blog sull'utilizzo di Kali sui dispositivi Raspberry Pi. Questo primo post riguarderà l'abilitazione di Full Disk Encryption (FDE) su un Raspberry Pi, la seconda parte riguarderà la connessione remota ad esso e, infine, la terza parte tratterà i problemi di debug che abbiamo riscontrato durante la realizzazione di questi post, in modo che altri possano imparare come fare così pure.

Con tutto quello che è successo nel mondo negli ultimi anni, sempre più persone lavorano da remoto. Non facciamo eccezione e oggi rivisiteremo la nostra macchina "drop box", che è stata crittografata rendendo così più difficile identificare se scoperta .

L'obiettivo è creare un "lasciarsi alle spalle" autonomo senza testa dispositivo che, se/quando scoperto, non rende facile capire cosa stavamo facendo poiché i nostri dati sono al sicuro sempre. A tal fine, utilizzeremo Full Disk Encryption (FDE) e consentirne lo sblocco remoto (se il dispositivo viene riavviato per qualsiasi motivo). Ci sarà anche la possibilità di utilizzare LUKS Nuke capacità se desideriamo rendere il disco inaccessibile in qualsiasi momento dopo aver finito con esso. Lo faremo su un Raspberry Pi 4 Model B+, ma è stato testato anche su un Raspberry Pi 3 Model B. Dovresti essere in grado di utilizzare la maggior parte delle marche/modelli di dispositivi simili, potrebbe richiedere solo un po' di adattamenti/aggiustamenti creativi per proteggere il tuo sistema.

Questo è un processo aggiornato poiché abbiamo già trattato parte di questo in precedenza. Questa volta includiamo ulteriori sviluppi, con alcuni contributi della community. Vorremmo ringraziare Richard Nelson (@unixabg) per il suo script automatizzato. Toccheremo questo dopo aver esaminato il metodo manuale, poiché ti consigliamo sempre di capire cosa sta succedendo sotto il cofano.

Panoramica di livello superiore

Prima di approfondire i dettagli tecnici di livello inferiore di ciò che stiamo per realizzare, diamo una rapida occhiata ai nostri obiettivi che vogliamo raggiungere e analizziamoli:

• Installa Kali Linux su un Raspberry Pi 4 (d'ora in poi chiamato "RPi")
• Prepara il sistema per l'avvio crittografato pronto per lo sblocco del disco remoto
• Imposta le chiavi SSH per consentire lo sblocco remoto (usando initramfs e Dropbear)
• Esegui il backup di tutti i dati esistenti
• Configura le partizioni crittografate
• Ripristina i nostri dati
• Hackera via !

Potrebbe sembrare molto, ma è piuttosto semplice anche se ci sono pochi passaggi. Una volta completato, avremo un RPi che:

• Avvio
• Ottieni un IP da DHCP
• Aspetta che ci connettiamo tramite SSH utilizzando le chiavi
• Permettici di fornire le passphrase di sblocco LUKS o LUKS Nuke

Poi lungo la strada, quando avremo finito con qualunque cosa vogliamo fare, l'unica cosa rimasta è recuperarla …a nostro piacimento!

Installazione di Kali Linux su un RPi

Se stai seguendo, assicurati di sapere dove stai creando l'immagine del file e sostituisci /dev/sdX . Non copiare/incollare alla cieca!

Creeremo la nostra macchina drop box su un'installazione Kali esistente. Dovrebbe essere molto facile usare altre distribuzioni basate su Debian e abbastanza semplice per altri sistemi operativi (tranne gli utenti Windows!)

Per prima cosa scaricheremo l'ultima immagine stabile di Kali RPi. Al momento in cui scrivo, questo è Kali 2022.2. Abbiamo anche scelto l'immagine a 64 bit, poiché abbiamo più di 4 GB di RAM e non utilizziamo alcun HAT (Hardware Attached on Top). I passaggi per 32 bit sarebbero gli stessi, dopo aver modificato i nomi dei file:

$ 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

Preparazione del sistema

Preparazione del chroot

Successivamente prepareremo le cose per un chroot. Creiamo dove vogliamo montare la scheda microSD, quindi montiamola:

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

Gli ultimi due comandi torneranno utili pronti per initramfs in seguito.

Installazione dei pacchetti richiesti

Ora che il nostro sistema è configurato, possiamo utilizzare il chroot per configurare l'immagine RPi per la crittografia. Per prima cosa entriamo nel chroot e installiamo alcuni pacchetti necessari:

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

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

Vogliamo assicurarci di avere il kernel più recente prima di iniziare, quindi assicuriamoci anche di averli installati:

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

Opzioni di avvio

Successivamente modificheremo /boot/cmdline.txt e cambia il percorso principale. Il /boot/cmdline.txt file su un dispositivo RPi viene utilizzato per passare le opzioni della riga di comando del kernel. Vorremo cambiare il percorso di root in /dev/mapper/crypt , quindi aggiungeremo cryptdevice=PARTUUID=$partuuid:crypt subito dopo.

La ragione di ciò è che il kernel deve sapere dove si trova il filesystem di root, per montarlo e usarlo, e poiché crittograferemo i rootfs più avanti nel post, durante l'avvio non può nemmeno vedere il dispositivo non crittografato , a causa della crittografia! Mentre stiamo cambiando il nome qui in "crypt", puoi chiamarlo come vuoi.

Il risultato finale dovrebbe assomigliare a questo:

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

Layout delle partizioni

Ora dobbiamo aggiornare il /etc/fstab file, questo è un file di configurazione sul sistema che contiene tutti i dischi disponibili, le partizioni del disco e le opzioni da utilizzare durante la loro gestione.

Attualmente è popolato con l'UUID del filesystem di root e abbiamo bisogno che punti al filesystem crittografato che creeremo. In questo esempio, abbiamo commentato l'UUID del dispositivo root precedente e abbiamo indicato /dev/mapper/crypt che è come verrà montato il nostro filesystem crittografato, una volta creato:

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

Configura le partizioni crittografate

Quando si utilizzano partizioni crittografate, è necessario modificare o creare, se non esiste, il /etc/crypttab file, che viene utilizzato da cryptsetup per sapere quali opzioni sono necessarie per sbloccare il dispositivo crittografato.

Poiché questo file non esiste, creeremo il /etc/crypttab file e riempilo con le opzioni di cui abbiamo bisogno:

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

Ora facciamo un piccolo trucco del file system. Creiamo un falso file system LUKS che consentirà di includere cryptsetup in initramfs perché vede una partizione crittografata. Quando formatti una partizione LUKS, ti verrà richiesta una password, e mentre normalmente utilizzerai una password complessa, perché la stiamo usando solo come un trucco per includere cryptsetup nel nostro initramfs, la password che crei a questo prompt non lo farà essere necessario o utilizzato dopo questi passaggi, quindi puoi impostarlo su qualcosa di breve/veloce da digitare. Questo accadrà al cryptsetup luksFormat passaggio e ti verrà richiesta la password che hai impostato durante cryptsetup luksFormat quando esegui cryptsetup luksOpen passo.

Non vedrai alcun input digitato quando inserisci la password

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

Configurazione delle chiavi SSH

Dopodiché dobbiamo copiare O generare una nuova chiave ssh da aggiungere al authorized_keys di Dropbear file.

Se abbiamo già una chiave esistente su cui copiare:

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

In alternativa per generare una nuova chiave:

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

Non vedrai alcun input digitato quando inserisci una passphrase

Configurazione per la crittografia

Tornando al chroot, dobbiamo creare alcuni nuovi file.

Il primo è il zz-cryptsetup hook che aggiunge i file di cui abbiamo bisogno per cryptsetup nel initramfs . Perché funzioni, deve essere contrassegnato come eseguibile in modo che mkinitramfs eseguirà l'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

Se desideri disabilitarlo in qualsiasi momento in futuro per qualsiasi motivo, rimuovi semplicemente il bit eseguibile.

Modifichiamo il file dei moduli per initramfs-tools in modo da includere il dm-crypt module e cat il file per verificare che sia corretto:

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

Configurazione dello sblocco SSH remoto

Crea un unlock.sh script con i seguenti contenuti, quindi contrassegnalo come eseguibile in modo che lo script venga eseguito nel 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

Quindi dobbiamo aggiungere quanto segue all'inizio di /etc/dropbear/initramfs/authorized_keys , che gli dice di eseguire questo comando quando entriamo in SSH se la chiave corrisponde a:

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

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

Dopo averlo fatto, possiamo aggiungere la chiave SSH su cui abbiamo copiato e quindi rimuoverla dalla scheda:

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

Al termine, /etc/dropbear/initramfs/authorized_keys dovrebbe assomigliare a questo:

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

Tutto nel authorized_keys file dovrebbe essere una riga, così come uno spazio tra la fine del comando " e la chiave ssh (ad es. [...]exit" ssh-rsa[...] )

Ora dobbiamo modificare /usr/share/initramfs-tools/scripts/init-premount/dropbear per aggiungere un timer di spegnimento, ciò consente l'avvio della rete prima Dropbear lo fa. È importante notare che quando ci sono aggiornamenti al dropbear-initramfs pacchetto, questa modifica dovrà essere aggiunta di nuovo:

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

Ora abilitiamo 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

Kernel

Il passo successivo è importante per le persone che stanno seguendo. Cosa selezionare, dipende dal dispositivo RPi che stai utilizzando, sarà . Di seguito sono riportati cinque nomi/edizioni/sapori del kernel di cui è necessario selezionare uno per le proprie esigenze (prestare attenzione!) :

• Re4son+ è per dispositivi ARMEL armv6 a 32 bit, ad esempio RPi1, RPi0 o RPi0w
• Re4son-v7+ è per dispositivi ARMHF armv7 a 32 bit, ad esempio RPi2 v1.2, RPi3 o RPi02w
• Re4son-v8+ è per dispositivi ARM64 armv8 a 64 bit, ad esempio RPi2 v1.2, RPi3 o RPi02w
• Re4son-v7l+ è per dispositivi ARMHF armv7 a 32 bit, ad esempio dispositivi RPi4 o RPi400
• Re4son-v8l+ è per dispositivi ARM64 armv8 a 64 bit, ad esempio dispositivi RPi4 o RPi400

Il l nel nome sta per lpae - Large Physical Address Extension

Come promemoria, stiamo usando l'immagine RPi4, a 64 bit. Quindi avremmo bisogno di Re4son-v8l+ . Assicurati di adattarti al tuo dispositivo. Quindi ora sappiamo quale nome del kernel usare, ora dobbiamo trovare quale versione del kernel. Questo cambierà da dispositivo a dispositivo e cambierà anche man mano che Kali riceve aggiornamenti Al momento della scrittura, è 5.15.44 per il nostro RPi:

Tieni presente che le versioni del kernel potrebbero cambiare, tuttavia il nome non cambierà:

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

Tieni presente le versioni del kernel (5.15.44 ) può cambiare, tuttavia il nome del kernel (Re4son-v8l+ ) non lo farà.

Ora dobbiamo creare il initramfs . È qui che entra in gioco la versione del kernel:

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

Ora vogliamo assicurarci di aver creato il initramfs correttamente. Se non ci sono risultati, allora qualcosa è andato storto:

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

Disabilita servizi

Prima di poter eseguire il backup, dobbiamo assicurarci che rpi-resizerootfs è disabilitato. Questo è un servizio che in genere eseguiamo su tutti i nostri dispositivi ARM che ridimensiona la partizione del filesystem di root per aumentare la dimensione della partizione alla dimensione completa del dispositivo di archiviazione su cui si trova. Dato che stiamo facendo questo passaggio manualmente, vogliamo disabilitarlo, in modo che potenzialmente non elimini il nostro filesystem di root e lo ricomponga.

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

Esegui il backup di tutti i dati esistenti

Ora possiamo assicurarci che tutte le modifiche siano scritte, quindi possiamo crittografare il 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

Configura le partizioni crittografate

A seconda del dispositivo che stai utilizzando, dovrai utilizzare uno dei due comandi. Se stai usando un RPi4 con 4 GB o più, usa questo comando:

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

Altrimenti vorrai usare quanto segue che usa una versione precedente di LUKS:

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

Ripristina i nostri dati

Successivamente puoi completare il ripristino dei dati nella partizione ora crittografata:

$ 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

Gli ultimi passaggi che dobbiamo fare sono riparare il /etc/fstab per il nuovo UUID LUKS, oppure puoi lasciarlo come /dev/mapper/crypt e sostituire l'UUID nel nostro script di sblocco e rifare il file initramfs, questo passaggio è importante in quanto non si avvierà correttamente se non viene eseguito, perché non avrà le informazioni per utilizzare il filesystem crittografato! Ricordati di inserire le informazioni da TUO sistema, poiché l'UUID sarà diverso per ogni 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+

Se ricevi un errore di cryptsetup qui, simile a cryptsetup: ERROR: Couldn't resolve device PARTUUID=ed889dad-02 ciò significa che non hai modificato il /etc/crypttab file e inserisci il PARTUUID corretto. L'avviso di non esistere fsck.luks può essere ignorato, poiché non esiste una cosa del genere.

Ora possiamo smontare e chiudere tutto:

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

In precedenza, abbiamo menzionato la capacità di LUKS Nuke. Se prevedi di usarlo, mentre sei avviato sul tuo rootfs RPi appena crittografato, esegui semplicemente il seguente comando per aggiungere la password Nuke e segui il prompt:

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

Resta sintonizzato per la seconda parte in cui tratteremo la connessione remota al Raspberry Pi come dispositivo dropbox!

Automatizza!

Ora che ne dici di automatizzarlo? Grazie a Richard Nelson (@unixabg), chiunque voglia impostare tutto questo in molto meno tempo rispetto al metodo manuale e molto più semplice, può!

Per prima cosa, scarichiamo lo script cryptmypi di unixabg:

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

Tuttavia, ci sono un certo numero di cose che vogliamo fare prima di poter eseguire gli script di compilazione. Esaminiamoli insieme ora:

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

Ora dobbiamo modificare cryptmypi.conf per modificare alcune impostazioni nella fase-2. Queste impostazioni saranno personali, ma facciamo solo un esempio:

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

Ciò che abbiamo modificato qui è il dispositivo a blocchi, la password di crittografia LUKS e la password di root. L'URL dell'immagine può essere modificato se desideri utilizzare un file immagine diverso, quindi assicurati di farlo ora, se necessario.

Ora l'unica cosa che resta da fare è eseguire gli script di entrambe le fasi e seguire le istruzioni. Alla fine, avrai un file system completamente crittografato con accesso SSH Dropbear!