In precedenza abbiamo spiegato come creare "scatola di hacking usa e getta" sicuri utilizzando il Raspberry Pi, ma abbiamo pensato che fosse ora di tornare indietro e dare un'occhiata al processo di nuovo. Con tutti i nuovi modelli Raspberry Pi e le modifiche a Kali rispetto all'ultima volta che ne abbiamo parlato, abbiamo scoperto che il vecchio processo necessitava di un aggiornamento.
Come recensione, quello che stiamo cercando di realizzare è creare un dispositivo autonomo che "lascia indietro" che, una volta scoperto, non renda facile capire cosa stavi facendo. Quindi utilizziamo la crittografia del disco completo LUKS insieme alla capacità di LUKS Nuke per mettere insieme questo. Se possiedi un Raspberry Pi 3 Model B+, o qualsiasi altro modello o dispositivo simile, sentiti libero di utilizzare le istruzioni seguenti per configurare il tuo sistema sicuro. Questo processo aggiornato si basa sulla nostra documentazione precedente e aggiornato con alcuni suggerimenti della community.
Panoramica del processo
Prima di immergerci nella tecnologia di ciò che cercheremo di realizzare, diamo una rapida occhiata ai nostri obiettivi sulla configurazione del nostro Raspberry Pi 3 Model B+ (d'ora in avanti chiamato "RPi"):
- Crea una normale installazione di Kali Linux RPi
- Prepara il sistema per l'avvio crittografato con sblocco disco remoto
- Crea un initramfs configurato con Dropbear e chiavi SSH per consentire lo sblocco
- Backup dei dati esistenti
- Configura le partizioni crittografate
- Ripristina i nostri dati
- Configura LUKS Nuke
- Trova via!
Potrebbe sembrare molto, ma è davvero piuttosto semplice e una volta completato, ci verrà lasciato un RPi che si avvierà, otterrà un IP da DHCP e Dropbear ci consentirà di connetterci tramite SSH per fornire la chiave LUKS. Questo ci consente di eseguire RPi senza testa, ma mantenendo i nostri dati al sicuro. Poi lungo la strada, quando avremo finito, possiamo recuperarlo o accedervi in remoto e distruggere i nostri dati con LUKS NUKE.
Preparazione del sistema Base
Per cominciare, dobbiamo scrivere l'immagine RPi su una scheda SD. Non ne parleremo qui, ma puoi trovare informazioni su come farlo nei nostri documenti.
Detto questo, inseriamo la scheda SD nell'RPi e lasciamo che si avvii. Al primo avvio, ridimensionerà la scheda SD e si riavvierà, dopodiché sarà pronta per l'uso. Successivamente, ci colleghiamo tramite SSH, aggiorniamo Kali e installiamo alcuni pacchetti di cui avremo bisogno.
apt update
apt dist-upgrade
apt install cryptsetup lvm2 busybox dropbear
Fare il Magic-Fu
L'RPi è tutto pronto e pronto per l'uso, quindi sporchiamoci le mani e tuffiamoci nelle cose. Prendi nota, una volta avviato questo processo, cambieremo una serie di file critici sulla nostra installazione RPi. È importante non riavviare il dispositivo o spegnere in altro modo il sistema finché non sei pronto o ti ritroverai con un sistema che non si avvia.
Prima di tutto, dobbiamo aggiungere una riga a /boot/config.txt :
echo initramfs initramfs.gz followkernel >> /boot/config.txt
Successivamente, vogliamo convalidare dove si trova il nostro dispositivo di filesystem root effettivo:
[email protected]:~# cat /etc/fstab
# proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
Prendi nota in particolare che il nostro filesystem di root risiede in /dev/mmcblk0p2 . Questo è ciò che useremo per i nostri esempi in futuro, quindi assicurati di aggiornare le istruzioni con il valore che hai ricevuto sul tuo sistema.
Ora che conosciamo la posizione del nostro filesystem di root, modificheremo il /boot/cmdline.txt . Per impostazione predefinita, contiene quanto segue:
[email protected]:~# cat /boot/cmdline.txt
dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait rootflags=noload net.ifnames=0
Prendi nota della voce che legge root=/dev/mmcblk0p2 . Lo aggiorneremo con un cryptdevice valore:
root=/dev/mapper/crypt cryptdevice=/dev/mmcblk0p2:crypt
Con la modifica apportata, il nostro file si presenta così:
[email protected]:~# cat /boot/cmdline.txt
dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mapper/crypt cryptdevice=/dev/mmcblk0p2:crypt rootfstype=ext4 rootwait rootflags=noload net.ifnames=0
Dobbiamo anche modificare /etc/fstab e sostituisci il dispositivo in cui il nostro filesystem di root deve essere attualmente /dev/mapper/crypt :
[email protected]:~# cat /etc/fstab
# proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mapper/crypt / ext4 defaults,noatime 0 1
#/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
Successivamente, dobbiamo creare un /etc/crypttab file contenente quanto segue:
crypt /dev/mmcblk0p2 none luks
Prestare particolare attenzione qui:i separatori tra le voci devono essere schede , non spazi. Ora, prima di iniziare a creare i nostri initramsfs, dobbiamo fare un piccolo trucco per forzare l'inclusione di cryptsetup. Per fare ciò, creeremo un filesystem LUKS falso. aggiungiamo un file vuoto, formattalo come LUKS, montalo e inseriscici un filesystem.
dd if=/dev/zero of=/tmp/fakeroot.img bs=1M count=20
cryptsetup luksFormat /tmp/fakeroot.img
cryptsetup luksOpen /tmp/fakeroot.img crypt
mkfs.ext4 /dev/mapper/crypt
Non preoccuparti troppo di impostare una password complessa per questo fakeroot poiché viene utilizzato solo in questo caso.
Configurazione di SSH e Initramfs
Ora siamo sulla linea di casa. Questa parte è davvero interessante, poiché normalmente all'avvio di un sistema che esegue LUKS, il processo di avvio si interrompe per consentirti di sbloccare l'HDD con la tua chiave LUKS. Se stai utilizzando un sistema headless, non è particolarmente conveniente.
Per ovviare a questo problema, configureremo Dropbear per l'avvio, consentirti di autenticarti con SSH e quindi collegarti per fornire la tua password LUKS, tutto da remoto!
Iniziamo creando un file in /etc/dropbear-initramfs/authorized_keys che contiene:
command="export PATH='/sbin:/bin/:/usr/sbin:/usr/bin'; /scripts/local-top/cryptroot && kill -9 \`ps | grep -m 1 'cryptroot' | cut -d ' ' -f 3\` && exit"
È importante notare che questo deve essere tutto su una riga. Nessuna interruzione di riga lì dentro. Se hai impostato correttamente questa configurazione, dovrebbe essere simile a questa:
[email protected]:~# cat /etc/dropbear-initramfs/authorized_keys
command="export PATH='/sbin:/bin/:/usr/sbin:/usr/bin'; /scripts/local-top/cryptroot && kill -9 `ps | grep -m 1 'cryptroot' | cut -d ' ' -f 3` && exit" ssh-rsa AAAAB3NzaC... [email protected]
Successivamente, apportiamo una piccola modifica a /usr/share/initramfs-tools/scripts/init-premount/dropbear . Questa modifica è dovuta al fatto che dobbiamo rallentare Dropbear per garantire che la rete sia configurata prima che Dropbear si attivi. Alla fine del file, dove si legge:
# On NFS mounts, wait until the network is configured. On local mounts,
# configure the network in the background (in run_dropbear()) so someone
# with console access can enter the passphrase immediately. (With the
# default ip=dhcp, configure_networking hangs for 5mins or so when the
# network is unavailable, for instance.)
[ "$BOOT" != nfs ] || configure_networking
run_dropbear &
echo $! >/run/dropbear.pid
Vogliamo aggiungere un semplice sonno dichiarazione in questo modo:
[ "$BOOT" != nfs ] || configure_networking
sleep 5
run_dropbear &
echo $! >/run/dropbear.pid
Fatto ciò, siamo finalmente pronti per creare i nostri initramfs!
mkinitramfs -o /boot/initramfs.gz
Prima di procedere, ci assicuriamo che le nostre modifiche personalizzate siano entrate nel nuovo initramfs:
lsinitramfs /boot/initramfs.gz | grep cryptsetup
lsinitramfs /boot/initramfs.gz | grep authorized
Una volta convalidato, ci assicuriamo che tutte le modifiche vengano scritte su disco e arrestiamo l'RPi.
sync && sync
init 0
Backup e ripristino
Rimuovi la scheda SD dal tuo RPi e torna al sistema che hai utilizzato inizialmente per scrivere la scheda SD. Prepariamo l'ambiente:
ls -al /mnt/{chroot,backup,encrypted}
# Please make sure there is nothing here first before you move on, otherwise you will have a bad day.
rm -rf /mnt/{chroot,backup,encrypted}
mkdir -p /mnt/{chroot,backup,encrypted}
Ora inserisci la scheda SD e convalida l'ID del dispositivo. Nel nostro caso, il dispositivo è /dev/sdc2 ma il tuo potrebbe essere diverso, quindi regola se necessario sul tuo sistema. Montiamo il dispositivo ed eseguiamo un backup del filesystem:
mount /dev/sdc2 /mnt/chroot/
rsync -avh /mnt/chroot/* /mnt/backup/
umount /mnt/chroot
Fatto ciò, eliminiamo la seconda partizione esistente sulla scheda SD e ne ricreiamo una vuota, che impostiamo per la crittografia LUKS.
echo -e "d\n2\nw" | fdisk /dev/sdc
echo -e "n\np\n2\n\n\nw" | fdisk /dev/sdc
Con le partizioni aggiornate, le ricarichiamo eseguendo partprobe e quindi configurare LUKS sulla nuova partizione:
cryptsetup -v -y --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdc2
cryptsetup -v luksOpen /dev/sdc2 crypt
mkfs.ext4 /dev/mapper/crypt
Detto questo, ripristiniamo il backup del filesystem di root sulla partizione ora crittografata.
mount /dev/mapper/crypt /mnt/encrypted/
rsync -avh /mnt/backup/* /mnt/encrypted/
sync
umount /mnt/encrypted/
cryptsetup luksClose /dev/mapper/crypt
In prova
Ora puoi reinserire la scheda SD nell'RPi e lasciarlo avviare. Se guardi l'avvio, dovresti vedere l'avvio di Dropbear. A quel punto, dovresti essere in grado di accedere a SSH nel sistema e sbloccare l'unità.
[email protected]:~# ssh -o "UserKnownHostsFile /dev/null" [email protected]
The authenticity of host '10.42.42.94 (10.42.42.94)' can't be established.
ECDSA key fingerprint is SHA256:L+QVP+OmncGDleuEoj77OlRGuCji2gp0c1gMYjUupU0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.42.42.94' (ECDSA) to the list of known hosts.
Please unlock disk /dev/mmcblk0p2 (crypt):
cryptsetup (crypt): set up successfully
Connection to 10.42.42.94 closed.
La versatilità di questi piccoli dispositivi unita alla potenza di Kali non finisce mai di stupirci. Ora ci resta un bel sistema headless in cui possiamo operare con relativa sicurezza che, anche se scoperto, non sarà troppo semplice entrarci.
Ma non abbiamo ancora finito! Aggiungiamo alcune funzionalità LUKS NUKE:
cryptsetup luksDump /dev/mmcblk0p2
cryptsetup luksAddNuke /dev/mmcblk0p2
Ora, quando entriamo in SSH, abbiamo una password che possiamo inserire per consentire alla scheda SD di sbloccarsi e continuare il processo di avvio e un'altra che distrugge l'intestazione LUKS, rendendo i dati inaccessibili. Se ti trovi in una situazione in cui non riesci a recuperare il dispositivo, questa opzione per masterizzare il dispositivo potrebbe essere molto utile. Se vuoi essere davvero elegante, puoi anche combinare questo con la trasformazione dell'RPi in un punto di accesso wireless, che ti consente di accedere a distanza e sbloccare/nucleare il sistema tutto tramite una connessione wireless. Questo è molto utile se non avrai un accesso diretto continuo alla rete a cui sarà collegato l'RPi.