Crittografia completa del disco per Windows e Linux installati. Avvio multiplo crittografato.

Guida aggiornata sulla crittografia a disco completo nel runet V0.2.

Strategia cowboy:

[A] crittografia di sistema a blocchi del sistema Windows 7 installato;
[B] crittografia di sistema a blocchi GNU/Linux (Debian) sistema installato (incluso /boot);
[C] configurazione di GRUB2, protezione del bootloader con firma digitale/autenticazione/hash;
[D] pulizia — distruzione dei dati non crittografati;
[E] backup universale dei sistemi operativi crittografati;
[F] attacco obiettivo — bootloader GRUB2;
[G] documentazione utile.

╭───Schema #camera 40# :
├──╼ Windows 7 installato — crittografia completa di sistema, non nascosta;
├──╼ GNU/Linux installato (Debian e distribuzioni derivate) — crittografia completa di sistema non nascosta(/, incluso /boot; swap);
├──╼ bootloader indipendenti: bootloader VeraCrypt installato in MBR, bootloader GRUB2 installato nella partizione estesa;
├──╼ installazione/reinstallazione del sistema operativo non richiesta;
└──╼ software crittografico utilizzato: VeraCrypt; Cryptsetup; GnuPG; Seahorse; Hashdeep; GRUB2 – libero/gratuito.

Lo schema sopra descritto risolve parzialmente il problema del "boot esterno su USB flash", consentendo di utilizzare i sistemi operativi crittografati Windows/Linux e di scambiare dati tramite un "canale crittografato" da un sistema operativo all'altro.

Ordine di avvio del PC (una delle opzioni):

• accensione della macchina;
• caricamento del bootloader VeraCrypt (l'inserimento corretto della password continuerà il caricamento di Windows 7);
• premere il tasto "Esc" caricherà il bootloader GRUB2;
• bootloader GRUB2 (scelta della distribuzione/GNU/Linux/CLI), richiederà l'autenticazione dell'utente root GRUB2 ;
• dopo un'autenticazione riuscita e la scelta della distribuzione, sarà necessario inserire la frase di accesso per sbloccare "/boot/initrd.img";
• dopo l'inserimento di password corrette in GRUB2, sarà "richiesto" di inserire la password (la terza password, password BIOS o password account utente GNU/Linux – non considerata) per sbloccare e avviare il sistema operativo GNU/Linux, oppure perl'inserimento automatico della chiave segreta (due password + chiave, oppure password+chiave);
• l'intrusione esterna nella configurazione GRUB2 bloccherà il processo di avvio di GNU/Linux.

Troppo lavoro? Ok, cominciamo a automatizzare i processi.

Durante la partizione del disco rigido (tabella MBR) un PC può avere non più di 4 partizioni primarie o 3 primarie e una estesa, oltre a uno spazio non partizionato. A differenza della primaria, la partizione estesa può contenere sotto-partizioni. (dischi logici=partizione estesa). In altre parole, la «partizione estesa» su HDD sostituisce LVM per gli attuali scopi: la crittografia completa del sistema. Se il tuo disco è suddiviso in 4 partizioni primarie, devi utilizzare lvm, oppure trasformare (con formattazione) la partizione da primaria a estesa, oppure utilizzare correttamente tutte e quattro le partizioni e lasciare tutto com'è, ottenendo il risultato desiderato. Anche se hai solo una partizione sul disco, Gparted ti aiuterà a suddividere l'HDD (in partizioni aggiuntive) senza perdita di dati, ma comunque con un piccolo costo per tali azioni.

Lo schema di partizionamento del disco rigido, rispetto al quale si svilupperà tutta la verbalizzazione dell'articolo, è presentato nella tabella qui sotto.

Tabella (n. 1) delle partizioni da 1TB.

Qualcosa di simile dovrebbe esserci anche da te.
sda1 — partizione primaria n. 1 NTFS (cifrata);
sda2 — partizione estesa marcatore;
sda6 — disco logico (su cui è installato il bootloader GRUB2);
sda8 — swap (file di paging cifrato/non sempre);
sda9 — disco logico di prova;
sda5 — disco logico per curiosi;
sda7 — OS GNU/Linux (sistema trasferito su disco logico cifrato);
sda3 — partizione primaria n. 2 con OS Windows 7 (cifrata);
sda4 — partizione primaria n. 3 (in cui si trovava GNU/Linux non cifrato, usato per backup/non sempre).

[A] Crittografia a blocchi del sistema Windows 7

A1. VeraCrypt

Avvio da sito ufficiale, oppure da uno specchio sourceforge della versione di installazione del software crittografico VeraCrypt (al momento della pubblicazione dell'articolo v1.24-Update3, la versione portatile di VeraCrypt non è adatta per la crittografia di sistema). Controlla il checksum del software scaricato

$ Certutil -hashfile "C:VeraCrypt Setup 1.24.exe" SHA256

e confronta il risultato ottenuto con il checksum pubblicato sul sito dello sviluppatore di VeraCrypt.

Se è installato il software HashTab, è ancora più semplice: tasto destro (VeraCrypt Setup 1.24.exe)-proprietà-hash dei file.

Per controllare la firma del programma, devono essere installati il software e la chiave pubblica pgp dello sviluppatore gnuPG; gpg4win.

A2. Installazione/avvio del software VeraCrypt con diritti di amministratore

A3. Scelta delle opzioni per la crittografia del sistema della partizione attivaVeraCrypt – Sistema – Crittografa partizione/disco di sistema – Normale – Crittografa partizione Windows – Multiboot – (avviso: «È sconsigliato per gli utenti inesperti utilizzare questo metodo» e questo è vero, accettiamo «Sì») – Disco di avvio («sì», anche se non è così, comunque «sì») – Numero di dischi di sistema «2 o più» – Più sistemi su un unico disco «Sì» – Nessun bootloader Windows «No» (in pratica «Sì», ma i bootloader VeraCrypt/GRUB2 non condivideranno l'MBR tra di loro, per essere precisi, nell'MBR/nella traccia di avvio si trova solo la parte più piccola del codice del bootloader, la parte principale è collocata all'interno del file system) – Multiboot – Impostazioni dei parametri di crittografia…

Se ti discosti dai passaggi sopra descritti (schemi di crittografia a blocchi di sistema), VeraCrypt emetterà un avviso e non ti consentirà di crittografare la partizione.

Nella fase successiva, per la protezione mirata dei dati, esegui un «Test» e scegli l'algoritmo di crittografia. Se hai una CPU non moderna, probabilmente l'algoritmo di crittografia più veloce risulterà essere Twofish. Se la CPU è potente, noterai la differenza: AES — la crittografia, in base ai risultati del test, sarà diverse volte più veloce rispetto ai suoi concorrenti crittografici. AES è un algoritmo di crittografia popolare, la parte hardware delle moderne CPU è ottimizzata appositamente sia per il «segreto» che per il «furto».

VeraCrypt supporta la possibilità di crittografare dischi in cascata AES(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (senza supporto hardware per AES, crittografia in cascata A/T) il calo delle prestazioni è praticamente impercettibile. (per CPU AMD della stessa epoca/presunto — prestazioni leggermente ridotte). Il sistema operativo funziona dinamicamente e il consumo di risorse per la crittografia trasparente è trascurabile. A differenza, per esempio, di una riduzione delle prestazioni evidente dovuta a un ambiente desktop instabile testato, come Mate v1.20.1 (o v1.20.2 non ricordo esattamente) In GNU/Linux, o a causa del funzionamento del sottoprogramma di telemetria in Windows 7↑. Di solito, gli utenti esperti effettuano test delle prestazioni dell'hardware prima di crittografare. Ad esempio, in Aida64/Sysbench/systemd-analyze blame e confrontano i risultati di questi stessi test dopo la crittografia del sistema, smentendo così per sé stessi il mito che «la crittografia di sistema è dannosa». Il rallentamento della macchina e l'inconveniente sono evidenti durante il backup/ripristino di dati crittografati, poiché l'operazione stessa di «backup dei dati di sistema» non si misura in millisecondi, e si aggiungono le operazioni di . Alla fine, ogni utente autorizzato a cimentarsi con la crittografia stabilisce un equilibrio tra l'algoritmo di crittografia, la soddisfazione degli obiettivi prefissati, il proprio grado di paranoia e la facilità d'uso.

È meglio lasciare il parametro PIM impostato su valore predefinito, in modo da non dover inserire ogni volta valori precisi delle iterazioni al caricamento del sistema operativo. VeraCrypt utilizza un'enorme quantità di iterazioni per creare un vero «hash lento». Un attacco a questo «crypto-lumaca» tramite brute force/tabelle arcobaleno ha senso solo con una breve «frase di password» semplice e un charset personale della vittima. Il prezzo della robustezza della password è un ritardo nell'immissione corretta della password durante il caricamento del sistema operativo. (il montaggio dei volumi VeraCrypt in GNU/Linux è notevolmente più veloce).
Software libero per implementare attacchi di brute force (estrazione della frase di password dall'intestazione del disco VeraCrypt/LUKS) Hashcat. John the Ripper non può «crackare Veracrypt», e non comprende la crittografia Twofish quando si lavora con LUKS.

A causa della robustezza crittografica degli algoritmi di crittografia, gli hacker crittografici sviluppano software con un'altra vettore d'attacco. Ad esempio, l'estrazione di metadati/chiavi dalla RAM (attacco cold boot/accesso diretto alla memoria), esiste software libero e closed source specializzato per questi scopi.

Al termine della configurazione/generazione di «metadati unici» della partizione attiva crittografata, VeraCrypt proporrà di riavviare il PC e testare il funzionamento del proprio bootloader. Dopo il reboot/avvio di Windows, VeraCrypt si caricherà in modalità attesa, resterà solo da confermare il processo di crittografia — Y.

Nell'ultima fase della crittografia di sistema, VeraCrypt offrirà di creare un backup dell'intestazione della partizione crittografata attiva sotto forma di "veracrypt rescue disk.iso" — questo è obbligatorio — in questo software tale operazione è un requisito (in LUKS, come requisito – purtroppo, questo è trascurato, ma sottolineato nella documentazione). Il disco di salvataggio sarà utile a tutti, e per alcuni anche più di una volta. La perdita (riscrittura dell'intestazione/MBR) di un backup dell'intestazione priverebbe per sempre l'accesso alla partizione decrittografata con OS Windows.

A4. Creazione di un usb/disco di salvataggio VeraCryptDi default, VeraCrypt offre di masterizzare "metadati ~2-3mB" su un CD, ma non tutti hanno dischi o unità DVD-ROM, e la creazione di una chiavetta USB avviabile "VeraCrypt Rescue disk" sarà per alcuni una sorpresa tecnica: Rufus/GUIdd-ROSA ImageWriter e altri software simili — non saranno in grado di affrontare il compito, perché oltre a copiare metadati spostati sulla chiavetta USB, è necessario eseguire un copia/incolla al di fuori del file system dell'unità USB, insomma, copiare correttamente l'MBR/il percorso sulla chiavetta. Da un'OS GNU/Linux, si può creare una chiavetta USB avviabile utilizzando l'utilità "dd", seguendo questa tabella.

La creazione di un disco di salvataggio in ambiente Windows è diversa. Lo sviluppatore di VeraCrypt non ha incluso la soluzione per questo problema nel suo ufficiale la documentazione documento "rescue disk", ma ha proposto la soluzione in altro modo: ha reso disponibile un software aggiuntivo per la creazione di un "usb rescue disk" sul proprio forum VeraCrypt. L'archivio di questo software per Windows è "creazione usb veracrypt rescue disk". Dopo aver salvato rescue disk.iso, inizierà il processo di crittografia di sistema a blocchi della partizione attiva. Durante la crittografia, il sistema operativo non si ferma, non è necessaria la riavvio del PC. Al termine dell'operazione di crittografia, la partizione attiva diventa completamente crittografata e può essere utilizzata. Se all'avvio del PC non appare il bootloader di VeraCrypt e l'operazione di ripristino dell'intestazione non aiuta, controlla il flag "boot", deve essere impostato sulla partizione in cui è presente Windows (indipendentemente dalla crittografia e da altre OS, vedi tabella n. 1).
A questo punto, la descrizione della crittografia di sistema a blocchi con OS Windows è terminata.

[B] LUKS. Crittografia GNU/Linux (~Debian) OS installata. Algoritmo e Fasi

Per crittografare una distribuzione Debian o derivata installata, è necessario associare la partizione preparata con un dispositivo a blocchi virtuale, trasferire su disco GNU/Linux associato e installare/configurare GRUB2. Se non avete un server nudo e tenete al vostro tempo, dovrete utilizzare l'interfaccia grafica, e si presume che la maggior parte dei comandi terminale descritti di seguito siano inseriti in "modalità Chuck Norris".

B1. Avvio del PC da live usb GNU/Linux

«Eseguire un test crittografico sulle prestazioni dell'hardware»

lscpu && cryptsetup benchmark

Se siete felici possessori di una potente macchina con supporto hardware per AES, i numeri appariranno simili alla parte destra del terminale, se siete fortunati, ma con hardware antiquato — a sinistra.

B2. Partizionamento del disco. Montaggio/formattazione del file system del disco logico HDD in Ext4 (Gparted)

B2.1. Creazione dell'intestazione crittografata della partizione sda7Descriverò i nomi delle partizioni, qui e in seguito, in base alla mia tabella delle partizioni pubblicata sopra. In base alla vostra partizione, dovrete inserire i vostri nomi delle partizioni.

Associazione della crittografia del disco logico ( /dev/sda7 > /dev/mapper/sda7_crypt).
#Простое создание «LUKS-AES-XTS раздела»

cryptsetup -v -y luksFormat /dev/sda7

Opzioni:

* luksFormat - inizializzazione dell'intestazione LUKS;
* -y - frase di accesso (non chiave/file);
* -v - verbosità (output delle informazioni nel terminale);
* /dev/sda7 - il vostro disco logico dalla partizione estesa (dove si prevede di trasferire/crittografare GNU/Linux).

Per impostazione predefinita, l'algoritmo di crittografia <LUKS1: aes-xts-plain64, Chiave: 256 bit, Hashing intestazione LUKS: sha256, RNG: /dev/urandom> (dipende dalla versione di cryptsetup).

#Проверка default-алгоритма шифрования
cryptsetup  --help #самая последняя строка в выводе терминала.

In assenza di supporto hardware per AES sulla CPU, la scelta migliore sarà la creazione della partizione estesa "LUKS-Twofish-XTS".

B2.2. Creazione estesa della partizione "LUKS-Twofish-XTS"

cryptsetup luksFormat /dev/sda7 -v -y -c twofish-xts-plain64 -s 512 -h sha512 -i 1500 --use-urandom

Opzioni:
* luksFormat - inizializzazione dell'intestazione LUKS;
* /dev/sda7 il vostro futuro disco logico crittografato;
* -v verbosità;
* -y frase di accesso;
* -c selezione dell'algoritmo di crittografia dei dati;
* -s dimensione della chiave di crittografia;
* -h algoritmo di hashing/crittografia, utilizzato RNG (—use-urandom) per generare una chiave di crittografia/decrittografia unica per l'intestazione del disco logico, la chiave secondaria dell'intestazione (XTS); la chiave master unica memorizzata nell'intestazione crittografata del disco, la chiave XTS secondaria, tutti questi metadata e la sottoprogramma di crittografia, che tramite la chiave master e la chiave XTS secondaria crittografa/decrittografa qualsiasi dato nella partizione (esclusa l'intestazione della partizione) occupano circa 3 MB nella partizione selezionata del disco rigido.
* -i iterazioni in millisecondi, invece di "numero" (ritardo temporale nel trattamento della frase di accesso, influisce sul caricamento del sistema operativo e sulla resistenza crittografica delle chiavi). Per mantenere un equilibrio nella resistenza crittografica con una password semplice come "russian", è necessario aumentare il valore di -(i); con una password complessa come "?8dƱob/øfh", il valore può essere diminuito.
* —use-urandom generatore di numeri casuali, genera chiavi e sale.

Dopo aver associato la partizione sda7 > sda7_crypt (l'operazione è rapida, poiché viene creato un'intestazione crittografata con metadata di circa 3 MB e tutto finisce qui), è necessario formattare e montare il file system sda7_crypt.

B2.3. Associazione

cryptsetup open /dev/sda7 sda7_crypt
#l'esecuzione di questo comando richiede l'inserimento della frase segreta.

opzioni:
* open -associa la partizione "con il nome";
* /dev/sda7 -disco logico;
* sda7_crypt -nome di associazione utilizzato per montare la partizione crittografata o per la sua inizializzazione al momento dell'avvio del sistema operativo.

B2.4. Formattazione del file system sda7_crypt in ext4. Montaggio del disco nel sistema operativo(Nota: con Gparted non sarà più possibile lavorare con la partizione crittografata)

#форматирование блочного шифрованного устройства
mkfs.ext4 -v -L DebSHIFR /dev/mapper/sda7_crypt 

opzioni:
* -v -verbalizzazione;
* -L -etichetta del disco (che viene visualizzata nell'esplora file tra altri dischi).

Successivamente, è necessario montare il dispositivo a blocchi virtuale-critto in /dev/sda7_crypt nel sistema

mount /dev/mapper/sda7_crypt /mnt

Lavorare con i file nella cartella /mnt porterà alla crittografia/decrittografia automatica dei dati in sda7.

È più comodo associare e montare la partizione nell'esplora file (nautilus/caja GUI), la partizione sarà già nella lista di selezione dei dischi, sarà sufficiente inserire solo la frase di accesso per aprire/decrittografare il disco. Il nome di associazione sarà scelto automaticamente e non sarà "sda7_crypt", ma qualcosa come /dev/mapper/Luks-xx-xx…

B2.5. Backup dell'intestazione del disco (metadata ~3MB)Uno dei più importanti operazioni che devono essere eseguite senza indugi: backup dell'intestazione «sda7_crypt». Se si sovrascrive/danneggia l'intestazione (ad esempio, installando GRUB2 nella partizione sda7, ecc.), i dati crittografati verranno persi definitivamente senza alcuna possibilità di recuperarli, poiché non sarà possibile rigenerare le stesse chiavi, le chiavi vengono create come uniche.

#Бэкап заголовка раздела
cryptsetup luksHeaderBackup --header-backup-file ~/Бэкап_DebSHIFR /dev/sda7 

#Восстановление заголовка раздела
cryptsetup luksHeaderRestore --header-backup-file <file> <device>

opzioni:
* luksHeaderBackup —header-backup-file -comando di backup;
* luksHeaderRestore —header-backup-file -comando di ripristino;
* ~ / Backup_DebSHIFR — file di backup;
* / dev / sda7 -partizione per la quale è necessario salvare il backup dell'intestazione crittografata del disco.
In questo passaggio è completato.

B3. Trasferimento del sistema operativo GNU / Linux (sda4) nella partizione crittografata (sda7)

Creiamo la cartella /mnt2 (Nota – stiamo ancora lavorando con un live usb, nella posizione /mnt è montato sda7_crypt), e montiamo il nostro GNU / Linux in /mnt2, che deve essere crittografato.

mkdir /mnt2
mount /dev/sda4 /mnt2

Effettuiamo il trasferimento corretto del sistema operativo utilizzando il software Rsync

rsync -avlxhHX --progress /mnt2/ /mnt

Le opzioni di Rsync sono descritte in p.E1.

Dopo, è necessario eseguire la deframmentazione della partizione del disco logico

e4defrag -c /mnt/ # dopo il controllo, e4defrag indicherà che il grado di deframmentazione della partizione è ~ "0", questa è una convinzione errata che può costarti una perdita significativa di prestazioni!
e4defrag /mnt/ # eseguiamo la deframmentazione di GNU / Linux crittografato

Fai attenzione: eseguire e4defrag su GNU / Linux crittografato di tanto in tanto se hai un HDD.
Il trasferimento e la sincronizzazione [GNU / Linux > GNU / Linux-crittografato] sono completati in questo passaggio.

B4. Configurazione di GNU / Linux sulla partizione crittografata sda7

Dopo aver trasferito con successo il sistema operativo /dev/sda4 > /dev/sda7, è necessario accedere a GNU / Linux nella partizione crittografata e completare la configurazione (senza riavviare il PC) relativamente al sistema crittografato. In altre parole, essere in live usb, ma eseguire i comandi "rispetto alla radice del sistema operativo crittografato". Simulare una situazione simile sarà "chroot". Per ottenere rapidamente informazioni su quale sistema operativo stai attualmente utilizzando (in crittografato o no, poiché i dati in sda4 e sda7 sono sincronizzati), disincronizza i sistemi operativi. Crea nelle directory radice (sda4 / sda7_crypt) file vuoti di marcatura, ad esempio, /mnt / crittografatoOS e /mnt2 / decrittografatoOS. Verifica rapida in quale sistema operativo ti trovi (compreso per il futuro):

ls /

B4.1. "Simulazione di accesso al sistema operativo crittografato"

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

B4.2. Verifica che il lavoro venga eseguito in relazione al sistema crittografato

ls /mnt 
#e vediamo il file "/sistemaCrittografato"

history
#nell'output del terminale dovrebbe apparire la cronologia dei comandi su del sistema operativo principale.

B4.3. Creazione/impostazione di swap crittografato, modifica di crypttab/fstabPoiché il file di swap viene formattato ad ogni avvio del sistema operativo, non ha senso creare e mappare lo swap con il disco logico adesso, e digitare comandi come in 2.2. Per lo swap, verranno generati automaticamente nuove chiavi di crittografia temporanee ad ogni avvio. Ciclo di vita delle chiavi dello swap: smontaggio/disattivazione della partizione di swap (+pulizia della RAM); oppure riavvio del sistema operativo. Configurazione dello swap, apriamo il file responsabile della configurazione dei dispositivi crittografati a blocchi (analogo al file fstab, ma responsabile per la crittografia).

nano /etc/crypttab 

modifichiamo

#«target name» «source device» «key file» «options»
swap /dev/sda8 /dev/urandom swap,cipher=twofish-xts-plain64,size=512,hash=sha512

Opzioni
* swap - nome associato alla crittografia /dev/mapper/swap.
* /dev/sda8 - utilizza la tua partizione logica per lo swap.
* /dev/urandom - generatore di chiavi di crittografia casuali per lo swap (ad ogni nuovo avvio del sistema operativo — sono create nuove chiavi). Il generatore /dev/urandom è meno casuale di /dev/random, dato che /dev/random è utilizzato in circostanze pericolose e paranoiche. All'avvio del sistema operativo, /dev/random rallenta il boot di alcuni ± minuti (vedi systemd-analyze).
* swap,cipher=twofish-xts-plain64,size=512,hash=sha512: - la partizione sa di essere swap e viene formattata «di conseguenza»; algoritmo di crittografia.

#Открываем и правим fstab
nano /etc/fstab

modifichiamo

# swap was on /dev/sda8 during installation
/dev/mapper/swap none swap sw 0 0

/dev/mapper/swap -имя , которое задали в crypttab.

Swap crittografato alternativo
Se per qualche motivo non vuoi riservare un'intera partizione per il file di swap, puoi optare per un'alternativa migliore: creare un file di swap all'interno di un file su una partizione crittografata del sistema operativo.

fallocate -l 3G /swap #crea un file di dimensioni 3Gb (operazione quasi istantanea)
chmod 600 /swap #configura i permessi
mkswap /swap #crea file di swap dal file
swapon /swap #attiva il nostro swap
free -m #verifica che il file di swap sia attivato e funzionante
printf "/swap none swap sw 0 0" >> /etc/fstab #se necessario, dopo il riavvio lo swap sarà permanente

Configurazione della partizione di swap completata.

B4.4. Configurazione di GNU/Linux crittografato (modifica dei file crypttab/fstab)Il file /etc/crypttab, come scritto sopra, descrive i dispositivi a blocchi crittografati che vengono configurati durante l'avvio del sistema.

#правим /etc/crypttab 
nano /etc/crypttab 

se hai mappato la partizione sda7>sda7_crypt come in 2.1

# «target name» «source device» «key file» «options»
sda7_crypt UUID=81048598-5bb9-4a53-af92-f3f9e709e2f2 none luks

se hai confrontato la partizione sda7>sda7_crypt come in p.B2.2

# «target name» «source device» «key file» «options»
sda7_crypt UUID=81048598-5bb9-4a53-af92-f3f9e709e2f2 none cipher=twofish-xts-plain64,size=512,hash=sha512

se hai confrontato la partizione sda7>sda7_crypt come in p.B2.1 o B2.2, ma non vuoi reinserire la password per sbloccare e avviare il sistema operativo, allora puoi sostituire la password con una chiave segreta/file casuale

# «target name» «source device» «key file» «options»
sda7_crypt UUID=81048598-5bb9-4a53-af92-f3f9e709e2f2 /etc/skey luks

Descrizione
* none -indica che all'avvio del sistema operativo, è necessaria l'inserimento di una frase di password segreta per sbloccare la root.
* UUID - identificatore della partizione. Per scoprire il tuo identificatore digita nel terminale (un promemoria che per tutto questo tempo e oltre, stai lavorando nel terminale in ambiente chroot, e non in un altro terminale live usb).

fdisk -l #verifica tutte le partizioni
blkid #dovrebbe essere qualcosa di simile 

/dev/sda7: UUID=«81048598-5bb9-4a53-af92-f3f9e709e2f2» TYPE=«crypto_LUKS» PARTUUID=«0332d73c-07»
/dev/mapper/sda7_crypt: LABEL=«DebSHIFR» UUID=«382111a2-f993-403c-aa2e-292b5eac4780» TYPE=«ext4»

questa riga è visibile quando si richiede blkid dal terminale live usb con sda7_crypt montato).
l'UUID lo prendi proprio dal tuo sdaX (non sdaX_crypt!, l'UUID sdaX_crypt verrà automaticamente rimosso durante la generazione del file di configurazione grub.cfg).
* cipher=twofish-xts-plain64,size=512,hash=sha512 - crittografia luks in modalità avanzata.
* /etc/skey - file-chiave segreto, che viene sostituito automaticamente per sbloccare l'avvio del sistema operativo (invece di inserire la terza password). Il file può essere di qualsiasi tipo fino a 8 MB, ma i dati saranno letti <1 MB.

#Создание "генерация" случайного файла <секретного ключа> размером 691б.
head -c 691 /dev/urandom > /etc/skey

#Добавление секретного ключа (691б) в 7-й слот заголовка luks
cryptsetup luksAddKey --key-slot 7 /dev/sda7 /etc/skey

#Проверка слотов "пароли/ключи luks-раздела"
cryptsetup luksDump /dev/sda7 

Dovrebbe apparire circa così:

(fallo tu stesso e lo vedrai).

cryptsetup luksKillSlot /dev/sda7 7 #rimozione della chiave/password dallo slot 7

/etc/fstab содержит описательную информацию о различных файловых системах.

#Правим /etc/fstab
nano /etc/fstab

# «file system» «mount poin» «type» «options» «dump» «pass»
# / was on /dev/sda7 during installation
/dev/mapper/sda7_crypt / ext4 errors=remount-ro 0 1

opzione
* /dev/mapper/sda7_crypt - nome di mappatura sda7>sda7_crypt, che è specificato nel file /etc/crypttab.
La configurazione di crypttab/fstab è completata.

B4.5. Modifica dei file di configurazione. Punto chiaveB4.5.1. Modifica del file di configurazione /etc/initramfs-tools/conf.d/resume

#Если у вас ранее был активирован swap раздел, отключите его. 
nano /etc/initramfs-tools/conf.d/resume

e commenta (se esiste) la riga «#» «resume». Il file deve essere completamente vuoto.

B4.5.2. Modifica del file di configurazione /etc/initramfs-tools/conf.d/cryptsetup

nano /etc/initramfs-tools/conf.d/cryptsetup

deve corrispondere a

# /etc/initramfs-tools/conf.d/cryptsetup
CRYPTSETUP=yes
export CRYPTSETUP

B4.5.3. Modifica del file di configurazione /etc/default/grub (proprio questo file di configurazione è responsabile della generazione di grub.cfg quando si lavora con /boot crittografato)

nano /etc/default/grub

aggiungiamo la riga «GRUB_ENABLE_CRYPTODISK=y»
il valore ‘y’, grub-mkconfig e grub-install verificheranno la presenza di dischi crittografati e genereranno comandi aggiuntivi necessari per il loro accesso durante l'avvio (insmod-ы <cryptomount/set root>).
deve essere simile

GRUB_DEFAULT=0
GRUB_TIMEOUT=1
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=«acpi_backlight=vendor»
GRUB_CMDLINE_LINUX=«quiet splash noautomount»
GRUB_ENABLE_CRYPTODISK=y

B4.5.4. Modifica del file di configurazione /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

verifica che la riga sia commentata .
In futuro (e già ora, questo parametro non avrà alcun effetto, ma a volte impedisce l'aggiornamento dell'immagine initrd.img).

B4.5.5. Modifica del file di configurazione /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

aggiungiamo

KEYFILE_PATTERN=»/etc/skey»
UMASK=0077

Questo impacchetterà la chiave segreta «skey» in initrd.img, chiave necessaria per sbloccare la root all'avvio del sistema operativo (se non si desidera inserire nuovamente la password, la chiave «skey» verrà inserita automaticamente).

B4.6. Aggiornamento di /boot/initrd.img [version]Per impacchettare la chiave segreta in initrd.img e applicare le correzioni di cryptsetup, aggiorniamo l'immagine

update-initramfs -u -k all

durante l'aggiornamento di initrd.img (come si dice «Forse, ma non è sicuro») potrebbero apparire avvisi relativi a cryptsetup o, ad esempio, notifiche sulla perdita di moduli Nvidia — è del tutto normale. Dopo l'aggiornamento del file, controlla che sia effettivamente stato aggiornato secondo l'orario (riguardo all'ambiente chroot /boot/initrd.img). Attenzione! prima di [update-initramfs -u -k all] assicurati che cryptsetup open /dev/sda7 sda7_crypt — è esattamente questo il nome che deve comparire in /etc/crypttab, altrimenti dopo il reboot si verificherà un errore di busybox)
A questo punto, la configurazione dei file di configurazione è completata.

[C] Installazione e configurazione di GRUB2/Protezione

C1. Se necessario, formatta la partizione designata per il bootloader (è sufficiente una dimensione di almeno 20MB)

mkfs.ext4 -v -L GRUB2 /dev/sda6

C2. Montaggio di /dev/sda6 in /mntEssendo in chroot, la root non avrà la cartella /mnt2, mentre la cartella /mnt sarà vuota.
monta la partizione GRUB2

mount /dev/sda6 /mnt

Se hai installato una vecchia versione di GRUB2, nella cartella /mnt/boot/grub/i-386-pc (può esserci un'altra piattaforma, ad esempio, non «i386-pc») mancano i moduli crittografici (in breve, nella cartella devono essere presenti moduli, inclusi questi .mod: cryptodisk; luks; gcry_twofish; gcry_sha512; signature_test.mod), in tal caso è necessario ripristinare GRUB2.

apt-get update
apt-get install grub2 

Importante! Durante l'aggiornamento del pacchetto GRUB2 dal repository, alla domanda «di scelta» su dove installare il bootloader – è necessario rifiutare l'installazione (motivo — tentativo di installare GRUB2 in «MBR» o su live usb). In caso contrario, si danneggerà l'intestazione/bootloader di VeraCrypt. Dopo l'aggiornamento dei pacchetti GRUB2 e la revoca dell'installazione, il bootloader deve essere installato manualmente su un disco logico, non nel «MBR». Se nel tuo repository è presente una versione obsoleta di GRUB2, prova ad aggiornare non ho controllato sul sito ufficiale (ho lavorato con i caricatori recenti GRUB 2.02 ~BetaX).

C3. Installazione di GRUB2 nella partizione estesa [sda6]Devi montare la partizione [p.C.2]

grub-install --force --root-directory=\/mnt \/dev\/sda6

opzioni
* —force - installazione del bootloader, bypassando tutti i messaggi di avviso che praticamente ci sono sempre e bloccano l'installazione (flag obbligatorio).
* —root-directory - impostazione della directory nella radice sda6.
* \/dev\/sda6 - la tua partizione sdaX (non dimenticare tra \/mnt \/dev\/sda6).

C4. Creazione del file di configurazione [grub.cfg]Dimentica il comando «update-grub2», e usa il comando completo per generare il file di configurazione

grub-mkconfig -o \/mnt\/boot\/grub\/grub.cfg

dopo aver completato la generazione/aggiornamento del file grub.cfg, nel terminale di output dovrebbero apparire righe con i sistemi operativi trovati sul disco («grub-mkconfig» potrebbe trovare e raccogliere anche i sistemi operativi da un live usb, se hai una chiavetta multiboot con Windows 10 e molti live distro — è normale). Se nel terminale c'è «vuoto», il file «grub.cfg» non è stato generato, allora è proprio quel caso in cui ci sono bug nel sistema GRUB (e molto probabilmente il bootloader proviene dal ramo di test del repository), reinstalla GRUB2 da fonti affidabili.
L'installazione della «configurazione semplice» e la configurazione di GRUB2 sono completate.

C5. Test di prova del sistema operativo GNU/Linux crittografatoTerminiamo correttamente la missione crittografica. Uscendo con attenzione da GNU/Linux crittografato (uscita dall'ambiente chroot).

umount -a # smontare tutte le partizioni montate di GNU/Linux crittografato
Ctrl+d # uscita dall'ambiente chroot
umount \/mnt\/dev
umount \/mnt\/proc
umount \/mnt\/sys
umount -a # smontare tutte le partizioni montate sulla live usb
reboot

Dopo il riavvio, il PC deve avviare il bootloader VeraCrypt.


*Immettere la password per la partizione attiva - verrà avviato il sistema operativo Windows.
*Premere il tasto «Esc» trasferirà il controllo a GRUB2, e nella scelta di GNU/Linux crittografato sarà richiesta la password (sda7_crypt) per sbloccare \/boot\/initrd.img (se grub2 scrive uuid «non trovato» — è un problema del bootloader grub2, dovrebbe essere reinstallato, ad esempio, dal ramo di test / stabile e pd).


*A seconda di come hai configurato il sistema (vedi p.B4.4/4.5) dopo l'immissione corretta della password per sbloccare l'immagine \/boot\/initrd.img, sarà necessaria la password per caricare il kernel/radice del sistema operativo, oppure verrà automaticamente fornita la chiave segreta «skey», eliminando la necessità di reinserire la frase di password.

(screenshot «automatico riempimento della chiave segreta»).

*Poi si avvierà il processo di caricamento di GNU/Linux con l'autenticazione dell'account utente.


*Dopo l'autorizzazione dell'utente e l'accesso al sistema operativo, è necessario aggiornare nuovamente /boot/initrd.img (vedi V4.6).

update-initramfs -u -k all

E nel caso di righe non necessarie nel menu GRUB2 (dalla cattura del sistema operativo con live usb) eliminarle

mount /dev/sda6 /mnt
grub-mkconfig -o /mnt/boot/grub/grub.cfg

Breve riepilogo sulla crittografia di sistema GNU/Linux:

• GNU/Linux è completamente crittografato, compresi /boot/kernel e initrd;
• la chiave segreta è inserita in initrd.img;
• lo schema di autorizzazione attuale (inserimento della password per sbloccare initrd; password/chiave per l'avvio del sistema operativo; password di autorizzazione dell'account Linux).

«Configurazione semplice di GRUB2» la crittografia del partizionamento del disco è completata.

C6. Configurazione avanzata di GRUB2. Protezione del bootloader con firma digitale + protezione tramite autenticazioneGNU/Linux è completamente crittografato, ma non è possibile crittografare il bootloader – questa condizione è imposta dal BIOS. Per questo motivo, il caricamento crittografato a catena di GRUB2 è impossibile, ma esiste un caricamento a catena semplice, dal punto di vista della protezione – non è necessario [vedi P. F].
Per il «GRUB2 vulnerabile», gli sviluppatori hanno implementato un algoritmo di protezione del bootloader con «firma/autenticazione».

• Con la protezione del bootloader «con la propria firma digitale», una modifica esterna dei file o un tentativo di caricare moduli aggiuntivi in questo bootloader porterà il processo di avvio al blocco.
• Con la protezione del bootloader tramite autenticazione, per selezionare l'avvio di una distribuzione qualsiasi o per inserire comandi aggiuntivi nel CLI, sarà necessario inserire il login e la password dell'utente root-GRUB2.

C6.1. Protezione del bootloader tramite autenticazioneAssicurati di lavorare nel terminale in un sistema operativo crittografato

ls / #per trovare il file marker

crea una password per superutente per l'autenticazione in GRUB2

grub-mkpasswd-pbkdf2 #inserisci/ripeti la password del superutente. 

Ottieni l'hash della password. Qualcosa di simile a questo

grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8

montiamo la partizione GRUB

mount /dev/sda6 /mnt 

modifichiamo il conf

nano -$ /mnt/boot/grub/grub.cfg 

verifica la ricerca nel file, assicurati che in «grub.cfg» non ci siano bandiere (» —unrestricted» «—user»,
aggiungi in fondo (prima della riga ### END /etc/grub.d/41_custom ###)
«set superusers=»root»
password_pbkdf2 root hash».

Dovrebbe essere più o meno così

# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the ‘exec tail’ line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
### END /etc/grub.d/41_custom ###
#

Se utilizzi spesso il comando "grub-mkconfig -o /mnt/boot/grub/grub.cfg" e non vuoi apportare ogni volta modifiche a grub.cfg, puoi inserire le righe sopra descritte (login/password) in uno script utente di GRUB in fondo

nano /etc/grub.d/41_custom 

cat << EOF
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
EOF

Durante la generazione della configurazione "grub-mkconfig -o /mnt/boot/grub/grub.cfg", le righe relative all'autenticazione verranno aggiunte automaticamente a grub.cfg.
In questo passaggio, la configurazione dell'autenticazione GRUB2 è completata.

C6.2. Protezione del caricatore di avvio con una firma digitaleSi presume che tu abbia già la tua chiave PGP di crittografia personale (oppure crea una chiave del genere). Il sistema deve avere installato un software crittografico: gnuPG; kleopatra/GPA; Seahorse. Il software crittografico ti faciliterà notevolmente la vita in tutte queste situazioni. Seahorse - versione stabile del pacchetto 3.14.0 (versioni superiori, ad esempio, V3.20 - non complete e con bug significativi).

La chiave PGP deve essere generata/avviata/aggiunta solo in ambiente su!

Genera una chiave di crittografia personale

gpg --gen-key

Esporta la tua chiave

gpg --export -o ~/perskey

Monta il disco logico nel sistema operativo se non è già montato

mount /dev/sda6 /mnt #sda6 - partizione GRUB2

pulisci la partizione di GRUB2

rm -rf /mnt/

Installa GRUB2 in sda6, posizionando la tua chiave personale nell'immagine principale di GRUB "core.img"

grub-install --force --modules="gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa" -k ~/perskey --root-directory=/mnt /dev/sda6

opzioni
* --force - installazione del caricatore di avvio, saltando tutti gli avvisi che esistono sempre (flag obbligatorio).
* --modules="gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa" - istruisce GRUB2 a caricare preliminarmente i moduli necessari all'avvio del PC.
* -k ~/perskey - percorso per "chiave PGP" (dopo aver impacchettato la chiave nell'immagine, può essere eliminata).
* --root-directory - imposta la directory di avvio nella radice di sda6
/dev/sda6 -ваш sdaХ раздел.

Generiamo/aggiorniamo grub.cfg

grub-mkconfig -o /mnt/boot/grub/grub.cfg

Aggiungi alla fine del file "grub.cfg" la riga "trust /boot/grub/perskey" (usa forzatamente la chiave PGP.) Poiché abbiamo installato GRUB2 con un insieme di moduli, incluso il modulo di firma "signature_test.mod", questo elimina la necessità di aggiungere al config comandi come "set check_signatures=enforce".

Dovrebbe apparire più o meno così (righe finali nel file grub.cfg)

### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
trust /boot/grub/perskey
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
### END /etc/grub.d/41_custom ###
#

Non è necessario specificare il percorso a «/boot/grub/perskey» su una partizione disco specifica, come hd0,6, per il bootloader «root» è il percorso predefinito della partizione su cui è installato GRUB2. (vedi set rot=..).

Firmiamo GRUB2. (tutti i file in tutte le directory /GRUB) con la propria chiave «perskey».
Una soluzione semplice, come firmare (per il file manager nautilus/caja): installiamo l'estensione «seahorse» per il file manager. La chiave deve essere stata aggiunta nell'ambiente su.
Aprite il file manager da sudo «/mnt/boot» – clic destro – firmare. Nello screenshot appare così.

La chiave «/mnt/boot/grub/perskey» (copiare nella directory grub) deve anch'essa essere firmata con la propria firma. Controllate che nella directory e nelle sottodirectory siano apparse le firme dei file [*.sig].
Firmiamo «/boot» come descritto sopra (i nostri kernel, initrd). Se il vostro tempo vale qualcosa, questo metodo evita di scrivere uno script bash per la firma di «numerosi file».

Per rimuovere tutte le firme del bootloader (se qualcosa è andato storto)

rm -f $(find /mnt/boot/grub -type f -name '*.sig')

Per non dover firmare il bootloader dopo l'aggiornamento del sistema, congeliamo tutti i pacchetti di aggiornamento relativi a GRUB2.

apt-mark hold grub-common grub-pc grub-pc-bin grub2 grub2-common

A questo punto <protezione del bootloader con firma digitale> la configurazione avanzata di GRUB2 è completata.

C6.3. Test di prova del bootloader GRUB2, protetto da firma digitale e autenticazione.GRUB2. Quando si sceglie una distribuzione GNU/Linux o si accede al CLI (la riga di comando) è richiesta l'autorizzazione dell'utente super. Dopo aver inserito la corretta login/password sarà necessario il password per initrd.

Screenshot, autenticazione riuscita dell'utente super di GRUB2.

Se viene falsificato uno qualsiasi dei file GRUB2/modificare grub.cfg, o eliminare un file/firma, caricare un modulo malicioso.mod, apparirà un avviso corrispondente. Il caricamento di GRUB2 verrà sospeso.

Screenshot, tentativo di interferire con GRUB2 «dall'esterno».

Durante il caricamento «normale» «senza intrusioni», il codice di stato del sistema è «0». Pertanto, non si sa se la protezione funziona o meno. (ossia «con la protezione del bootloader con firma o senza» durante il caricamento normale lo stato è lo stesso «0» — questo è problematico).

Come controllare la protezione con firma digitale?

Modo scomodo di controllare: falsificare/eliminare il modulo GRUB2 utilizzato, ad esempio, eliminare la firma luks.mod.sig e ottenere un errore.

Modo corretto: entrare nel CLI del bootloader e digitare il comando

trust_list

In risposta, si deve ricevere l'impronta «perskey». Se lo stato è «0», significa che la protezione con la firma non funziona, ricontrolla p.C6.2.
In questo passaggio, la configurazione avanzata «Protezione GRUB2 con firma digitale e autenticazione» è terminata.

C7 Metodo alternativo di protezione del caricatore GRUB2 tramite hashingIl metodo descritto sopra «Protezione del caricatore CPU/Autenticazione» è una classica. A causa delle imperfezioni di GRUB2, in condizioni paranoiche può essere soggetto a un attacco reale, che illustrerò di seguito in p.[F]. Inoltre, dopo l'aggiornamento del sistema operativo/nucleo, è necessario risignare il caricatore.

Protezione del caricatore GRUB2 tramite hashing

Vantaggi rispetto alla classica:

• Livello di affidabilità superiore (l'hashing/verifica avviene solo da una risorsa locale crittografata. Tutto il partizionamento dedicato a GRUB2 è monitorato per eventuali modifiche, e tutto il resto è crittografato; nella classica protezione del caricatore CPU/Autenticazione vengono monitorati solo i file, ma non gli spazi liberi, dove «qualcosa di sinistro» potrebbe essere scritto).
• Registrazione crittografata (il sistema include un registro personale crittografato leggibile).
• Velocità (la protezione/verifica dell'intera partizione dedicata a GRUB2 avviene praticamente in tempo reale).
• Automazione di tutti i processi crittografici.

Svantaggi rispetto alla classica.

• Falsificazione della firma (teoricamente, è possibile trovare una collisione predeterminata nella funzione hash).
• Livello di complessità aumentato (rispetto alla classica, è richiesto un po' più di abilità nell'uso del sistema operativo GNU/Linux).

Come funziona l'idea con l'hashing GRUB2/partizione

La partizione GRUB2 viene «firmata», durante il caricamento del sistema operativo avviene un controllo dell'immutabilità della partizione del caricatore con successiva registrazione in un ambiente sicuro (critto). In caso di compromissione del caricatore o della sua partizione, oltre al registro di intrusione, viene avviata una

Cosa.

Quattro volte al giorno avviene un controllo analogo, che non carica le risorse del sistema.
Con il comando «-$ controllo_GRUB» si esegue un controllo istantaneo in qualsiasi momento senza registrazione, ma con output delle informazioni nel CLI.
Con il comando «-$ sudo firma_GRUB» si esegue la risignatura istantanea del caricatore GRUB2/partizione e la sua registrazione aggiornata (necessaria dopo l'aggiornamento del sistema operativo/boot), e la vita continua.

Implementazione del metodo di hashing per il bootloader e la sua sezione

0) Firmiamo il bootloader/sezione GRUB, montandolo prima in /media/username

-$ hashdeep -c md5 -r /media/username/GRUB > /podpis.txt

1) Creiamo uno script senza estensione nella radice del sistema operativo crittografato ~/podpis, applicando i diritti necessari 744 per la sicurezza e protezione contro l'«errore dell'utente».

Popoliamo il suo contenuto

#!/bin/bash

#Проверка всего раздела выделенного под загрузчик GRUB2 на неизменность.
#Ведется лог "о вторжении/успешной проверке каталога", короче говоря ведется полный лог с тройной вербализацией. Внимание! обратить взор на пути: хранить ЦП GRUB2 только на зашифрованном разделе OS GNU/Linux. 
echo -e "******************************************************************n" >> '/var/log/podpis.txt' && date >> '/var/log/podpis.txt' && hashdeep -vvv -a -k '/podpis.txt' -r '/media/username/GRUB' >> '/var/log/podpis.txt'

a=`tail '/var/log/podpis.txt' | grep failed` #не использовать "cat"!! 
b="hashdeep: Audit failed"

#Условие: в случае любых каких-либо изменений в разделе выделенном под GRUB2 к полному логу пишется второй отдельный краткий лог "только о вторжении" и выводится на монитор мигание gif-ки "warning".
if [[ "$a" = "$b" ]] 
then
echo -e "****n" >> '/var/log/vtorjenie.txt' && echo "vtorjenie" >> '/var/log/vtorjenie.txt' && date >> '/var/log/vtorjenie.txt' & sudo -u username DISPLAY=:0 eom '/warning.gif' 
fi

Eseguiamo lo script da su, verrà eseguito un controllo dell'hashing della sezione GRUB e del suo bootloader, salva il log.

Creiamo o copiamo, ad esempio, un «file malevolo» [virus.mod] nella sezione GRUB2 e avviamo un controllo/test temporaneo:

-$ hashdeep -vvv -a -k '/podpis.txt' -r '/media/username/GRUB

Nel CLI dovremmo vedere un'intrusione nella nostra -cittadella-#Урезанный лог в CLI

Mer gen  2 11::41 MSK 2020
/media/username/GRUB/boot/grub/virus.mod: Spostato da /media/username/GRUB/1nononoshifr
/media/username/GRUB/boot/grub/i386-pc/mda_text.mod: Ok
/media/username/GRUB/boot/grub/grub.cfg: Ok
hashdeep: Audit fallito
   File di input esaminati: 0
  File noti attesi: 0
          File corrispondenti: 325
File parzialmente corrispondenti: 0
            File spostati: 1
        Nuovi file trovati: 0
  File noti non trovati: 0

#как видим появилось «Files moved: 1 и Audit failed» означает, что проверка не прошла.
A causa delle peculiarità della sezione testata, invece di «Nuovi file trovati» > «File spostati»

2) Mettiamo il gif qui > ~/warning.gif, impostiamo i diritti 744.

3) Configuriamo fstab per il montaggio automatico della sezione GRUB all'avvio

-$ sudo nano /etc/fstab

LABEL=GRUB /media/username/GRUB ext4 defaults 0 0

4) Eseguiamo la rotazione del log

-$ sudo nano /etc/logrotate.d/podpis 

/var/log/podpis.txt {
daily
rotate 50
size 5M
dateext
compress
delaycompress
olddir /var/log/old
}

/var/log/vtorjenie.txt {
monthly
rotate 5
size 5M
dateext
olddir /var/log/old
}

5) Aggiungiamo un'attività in cron

-$ sudo crontab -e

reboot ‘/podpis’
0 */6 * * * ‘/podpis

6) Creiamo alias permanenti

-$ sudo su
-$ echo "alias подпись_GRUB='hashdeep -c md5 -r /media/username/GRUB > /podpis.txt'" >> /root/.bashrc && bash
-$ echo "alias проверка_GRUB='hashdeep -vvv -a -k '/podpis.txt' -r /media/username/GRUB'" >> .bashrc && bash

Dopo l'aggiornamento del sistema operativo -$ apt-get upgrade firmiamo nuovamente la nostra sezione GRUB
-$ подпись_GRUB
In questo passaggio, la protezione tramite hashing della sezione GRUB è completata.

[D] Pulizia — distruzione dei dati non crittografati

Elimina i tuoi file personali in modo tale che «nemmeno Dio possa leggerli», secondo quanto affermato dal rappresentante della Carolina del Sud, Trey Gowdy.

Come al solito ci sono diversi «miti e leggende», sul recupero dei dati dopo la loro eliminazione dal disco rigido. Se credi nella cybermagia, o sei un parrocchiano della comunità Dr web e non hai mai provato il recupero dei dati dopo la loro eliminazione/sovrascrittura (ad esempio, recupero tramite R-studio), allora il metodo proposto difficilmente ti sarà utile, usa quello con cui ti senti più a tuo agio.

Dopo aver trasferito con successo GNU/Linux su una partizione crittografata, è necessario eliminare la vecchia copia in modo che i dati non possano essere ripristinati. Un modo universale per la pulizia: software GUI gratuito per Windows/Linux BleachBit.
Veloce formattiamo la partizione, i cui dati devono essere distrutti (con Gparted), avviamo BleachBit, selezioniamo «Pulizia dello spazio libero» – selezioniamo la partizione (il vostro sdaX con la vecchia copia di GNU/Linux), si avvierà il processo di pulizia. BleachBit pulisce il disco in un solo passaggio – è ciò di cui «abbiamo bisogno», ma! funziona solo in teoria, se avete formattato il disco e pulito con il software BB v2.0.

Attenzione! BB pulisce il disco, lasciando i metadati, i nomi dei file vengono conservati durante l'eliminazione dei dati (Ccleaner non lascia metadati).

E il mito della possibilità di recuperare i dati non è esattamente un mito.Bleachbit V2.0-2 era un pacchetto unstable OS Debian (e qualsiasi altro software simile: sfill; wipe-Nautilus – sono stati notati anche in questa sporca faccenda) aveva realmente un errore critico: la funzione «pulizia dello spazio libero» non funziona correttamente su HDD/chiavette USB (ntfs/ext4). Software di questo tipo, durante la pulizia dello spazio libero, non sovrascrivono l'intero disco come molti utenti pensano. E alcuni (molti) dati eliminati dal sistema operativo/software considerano questi dati non eliminati/utenti e durante la pulizia dell'«OSP» ignorano questi file. Il problema è che dopo una lunga pulizia del disco i «file eliminati» possono essere recuperati anche dopo 3+ passaggi di pulizia del disco.
Su GNU/Linux, in Bleachbit 2.0-2 funzionano dignitosamente le funzioni di eliminazione definitiva di file e cartelle, ma non la pulizia dello spazio libero. A titolo di confronto: su Windows, nel software CCleaner, la funzione «OSP per ntfs» funziona correttamente, e Dio in effetti non potrà leggere i dati eliminati.

E quindi, per eliminare in modo definitivo dati "compromettenti" vecchi dati non crittografati, è necessaria l'accesso diretto di Bleachbit a questi dati,poi, utilizzare la funzione «eliminazione di file/cartelle in modo permanente».
Per eliminare «file eliminati con i mezzi standard del sistema operativo» in Windows, utilizzate CCleaner/BB con la funzione «OSP». In GNU/Linux su questo problema (eliminazione di file eliminati) dovete praticare da soli (eliminazione dei dati + tentativo autonomo di recuperarli e non dovete contare sulla versione del software (se non è una backdoor, è un bug)), solo in questo modo potrai capire il meccanismo di questo problema e liberarti definitivamente dei dati eliminati.

Bleachbit v3.0 non è stato testato, potrebbe essere che il problema sia già stato risolto.
Bleachbit v2.0 funziona in modo corretto.

In questo passaggio, la "pulizia del disco" è completata.

[E] Backup universale di sistemi operativi crittografati

Ogni utente ha il proprio metodo di backup dei dati, ma i dati crittografati dei "Sistemi operativi" richiedono un approccio leggermente diverso al compito. Software unificato, come ad esempio "Clonezilla" e software simili, non possono lavorare direttamente con dati crittografati.

Definizione del compito di backup per dispositivi a blocchi crittografati:

1. universalità - algoritmo/software di backup identico per Windows/Linux;
2. possibilità di lavorare da console con qualsiasi live usb GNU/Linux senza la necessità di scaricare software aggiuntivo (ma consiglio comunque un'interfaccia grafica);
3. sicurezza dei backup - le "immagini" salvate devono essere crittografate/protette da password;
4. la dimensione dei dati crittografati deve corrispondere alla dimensione dei dati effettivamente copiati;
5. estrazione facile dei file necessari dal backup (assenza di requisiti per decrittografare prima l'intera partizione).

Ad esempio, backup/ripristino tramite l'utilità "dd"

dd if=/dev/sda7 of=/path/sda7.img bs=7M conv=sync,noerror
dd if=/path/sda7.img of=/dev/sda7 bs=7M conv=sync,noerror

Corrisponde quasi a tutti i punti indicati, ma per il punto 4 non regge, poiché copia l'intera partizione del disco, incluso lo spazio libero - non interessante.

Ad esempio, backup di GNU/Linux tramite compressore [tar» | gpg] è comodo, ma per il backup di Windows è necessario cercare un'altra soluzione - non interessante.

E1. Backup universale Windows/Linux. Integrazione rsync (Grsync)+volume VeraCryptAlgoritmo per la creazione del backup:

1. creazione di un contenitore crittografato (volume/file) VeraCrypt per il sistema operativo;
2. trasferimento/sincronizzazione del sistema operativo utilizzando il software Rsync nel contenitore crittografato VeraCrypt;
3. se necessario, caricamento del volume VeraCrypt in www.

La creazione di un contenitore crittografato VeraCrypt ha le sue peculiarità:
creazione di un volume dinamico (è possibile creare un volume dinamico solo in Windows, utilizzabile anche in GNU/Linux);
creazione di un volume normale, ma è presente una richiesta di "carattere paranoico" (secondo le parole dello sviluppatore) – formattazione del contenitore.

Il volume dinamico viene creato praticamente in un istante su Windows, ma durante la copia dei dati da un sistema operativo GNU/Linux > VeraCrypt DT, in generale le prestazioni dell'operazione di backup diminuiscono notevolmente.

Un volume Twofish da 70 GB viene creato (diciamo su un PC di potenza media) su HDD in circa mezz'ora (riscrivendo i dati precedenti del contenitore in un solo passaggio, a causa dei requisiti di sicurezza). Da VeraCrypt per Windows/Linux è stata rimossa la funzione di formattazione rapida del volume durante la sua creazione, quindi la creazione di un contenitore è possibile solo tramite 'riscrittura in un solo passaggio', oppure creando un volume dinamico a basse prestazioni.

Creiamo un volume normale di VeraCrypt (non dinamico/ntfs), non dovrebbero sorgere problemi.

Configuriamo/creiamo/apriamo il contenitore nell'interfaccia grafica di VeraCrypt > GNU/Linux live usb (il volume sarà automaticamente montato in /media/veracrypt2, il volume di Windows sarà montato in /media/veracrypt1). Creiamo un backup crittografato di Windows usando l'interfaccia grafica rsync (grsync), selezionando le opzioni.

Aspettiamo la fine del processo. Al termine del backup, avremo un file crittografato.

Analogamente, creiamo un backup del sistema operativo GNU/Linux, deselezionando l'opzione di 'compatibilità con Windows' nell'interfaccia grafica di rsync.

Attenzione! Il contenitore Veracrypt per 'backup GNU/Linux' deve essere creato nel sistema files ext4. Se si esegue un backup in un contenitore ntfs, perderai tutti i permessi/gruppi su tutti i tuoi dati durante il ripristino di tale copia.

Tutte le operazioni possono essere eseguite anche nel terminale. Le opzioni principali per rsync sono:
* -g -salva i gruppi;
* -P —progress — stato del tempo di lavoro sul file;
* -H -copia i collegamenti hard così come sono;
* -a -modalità archivio (alcuni flag rlptgoD);
* -v -verbosità.

Se si desidera montare 'il volume Windows VeraCrypt' tramite console nel software cryptsetup, è possibile creare un alias (su)

echo "alias veramount='cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sdaX Windows_crypt && mount /dev/mapper/ Windows_crypt /media/veracrypt1'" >> .bashrc && bash

Ora, al comando 'veramount pictures' verrà richiesto di inserire la frase di accesso, e il volume di sistema Windows crittografato sarà montato nel sistema.

Montare/associarsi al volume di sistema VeraCrypt con il comando di cryptsetup

cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sdaX Windows_crypt
mount /dev/mapper/Windows_crypt /mnt

Montare/associarsi alla partizione/contenitore VeraCrypt con il comando di cryptsetup

cryptsetup open --veracrypt --type tcrypt /dev/sdaY test_crypt
mount /dev/mapper/test_crypt /mnt

Invece di aggiungere un alias, incorporiamo (script all'avvio automatico) il volume di sistema con il sistema operativo Windows e il disco logico crittografato ntfs all'avvio di GNU/Linux

Creiamo uno script e lo salviamo in ~/VeraOpen.sh

printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sda3 Windows_crypt && mount /dev/mapper/Windows_crypt /media/Winda7 #decodifichiamo la password da base64 (bob) e la inviamo come richiesta per l'inserimento della password durante il montaggio del disco di sistema di Windows.
printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --type tcrypt /dev/sda1 ntfscrypt && mount /dev/mapper/ntfscrypt /media/КонтейнерНтфс #analogamente, ma montiamo il disco logico ntfs.

Assegniamo i "veri" permessi:

sudo chmod 100 /VeraOpen.sh

Creiamo due file identici (stesso nome!) in /etc/rc.local e ~/etc/init.d/rc.local
Compiliamo i file

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will «exit 0» on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

sh -c "sleep 1 && '/VeraOpen.sh'" #после загрузки ОС, ждём ~ 1с и только потом монтируем диски.
exit 0

Assegniamo i "veri" permessi:

sudo chmod 100 /etc/rc.local && sudo chmod 100 /etc/init.d/rc.local 

Tutto, ora all'avvio di GNU/Linux non dobbiamo inserire password per montare i dischi ntfs crittografati, i dischi montano automaticamente.

Nota sintetica su quanto descritto sopra nel p.E1 a passi (ma ora per OS GNU/Linux)
1) Creare un volume in fs ext4 > 4gb (per file) Linux in Veracrypt [Криптоящик].
2) Riavviare in live usb.
3) ~$ cryptsetup open /dev/sda7 Lunux #associazione della partizione crittografata.
4) ~$ mount /dev/mapper/Linux /mnt #montaggio della partizione crittografata in /mnt.
5) ~$ mkdir mnt2 #creazione di una directory per il futuro backup.
6) ~$ cryptsetup open --veracrypt --type tcrypt ~/Криптоящик Криптоящик && mount /dev/mapper/Криптоящик /mnt2 #Associazione del volume Veracrypt denominato "Криптоящик" e montaggio di Криптоящик in /mnt2.
7) ~$ rsync -avlxhHX --progress /mnt /mnt2/ #operazione di backup della partizione crittografata in volume crittografato Veracrypt.

(p/s/ Attenzione! Se trasferite GNU/Linux crittografato da un'architettura/macchina a un'altra, ad esempio, Intel > AMD (cioè ripristinate un backup da una partizione crittografata a un'altra partizione crittografata Intel > AMD), non dimenticate dopo il trasferimento del sistema operativo crittografato di modificare la chiave segreta sostitutiva anziché la password, poiché la chiave precedente ~/etc/skey non funzionerà per l'altra partizione crittografata, e una nuova chiave "cryptsetup luksAddKey" è sconsigliabile crearla da chroot - ci possono essere problemi, basta nella ~/etc/crypttab indicare temporaneamente "none" invece di "/etc/skey", dopo il riavvio e l'accesso al sistema operativo ricreate la vostra chiave segreta sostitutiva da zero).

Come veterani IT, non dimenticate di fare backup separati degli header delle partizioni crittografate di Windows/Linux, altrimenti la crittografia si ritorcerà contro di voi.
A questo punto, il backup dei sistemi operativi crittografati è completato.

[F] Attacco al bootloader GRUB2

DettagliSe hai protetto il tuo bootloader con una firma digitale e/o autenticazione (cfr. p.C6.), l'accesso fisico non lo proteggerà in alcun modo. I dati crittografati rimarranno comunque inaccessibili, ma il bypass della protezione (reset della protezione della firma digitale) GRUB2 consente a un malintenzionato di inserire il proprio codice nel bootloader senza destare sospetti (a meno che l'utente non monitori manualmente lo stato del bootloader o non crei un proprio codice di script robusto per grub.cfg).

Algoritmo dell'attacco. L'attaccante

* Avvia il PC tramite un live USB. Qualsiasi modifica (da parte del trasgressore) dei file porterà a una segnalazione al vero proprietario del PC riguardo a un'intrusione nel bootloader. Ma una semplice reinstallazione di GRUB2 mantenendo grub.cfg (e successivamente la possibilità di modificarlo) permetterà al malintenzionato di modificare qualsiasi file (in questo scenario, durante il caricamento di GRUB2, non ci sarà alcuna segnalazione all'utente reale. Lo stato rimane lo stesso )
* Monta una partizione non crittografata, salvando su " /mnt/boot/grub/grub.cfg ".
* Reinstalla il bootloader (escludendo "perskey" dall'immagine core.img)

grub-install --force --root-directory=\/mnt \/dev\/sda6

* Ripristina "grub.cfg" > " /mnt/boot/grub/grub.cfg ", modificandolo se necessario, ad esempio aggiungendo il proprio modulo "keylogger.mod" nella cartella con i moduli del bootloader, in "grub.cfg" > riga "insmod keylogger". Oppure, ad esempio, se il nemico è astuto, dopo la reinstallazione di GRUB2 (tutte le firme rimangono al loro posto) riunisce l'immagine principale di GRUB2, utilizzando "grub-mkimage con l'opzione (-s)." L'opzione "-s" consentirà di caricare la propria configurazione prima di caricare il principale "grub.cfg". La configurazione può consistere in una sola riga: un reindirizzamento a qualsiasi "modern.cfg", mischiato, ad esempio, con ~400 file (moduli+firme) nella cartella " /boot/grub/i386-pc ". In questo modo il trasgressore può inserire codice arbitrario e caricare moduli, senza toccare " /boot/grub/grub.cfg ", anche se l'utente ha applicato "hashsum" al file e lo ha temporaneamente visualizzato.
Per l'attaccante non sarà necessario violare il login/password dell'utente root di GRUB2, sarà sufficiente copiare le righe (responsabili per l'autenticazione) " /boot/grub/grub.cfg " nel proprio "modern.cfg"

set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8

E per il proprietario del PC continuerà a esserci il controllo sull'autenticità dell'utente root di GRUB2.

Boot chaining (il bootloader carica un altro bootloader), come detto sopra, non ha senso (è destinato a scopi diversi). A causa del BIOS non è possibile caricare un bootloader crittografato (in avvio a catena si verifica il riavvio di GRUB2 > GRUB2 crittografato, errore!). Tuttavia, se si desidera comunque sfruttare l'idea dell'avvio a catena, si può essere certi che viene caricato proprio il crittografato (non aggiornato) «grub.cfg» nella partizione crittografata. E questo è anche un falso senso di sicurezza, perché tutto ciò che è indicato nel «grub.cfg» crittografato (caricamento moduli) si combina con i moduli caricati da GRUB2 non crittografato.

Se desideri verificarlo, allora evidenzia/crittografa un'altra partizione sdaY, copiala in GRUB2 (l'operazione grub-install sulla partizione crittografata non è possibile) e in «grub.cfg» (configurazione non crittografata) modifica righe simili a queste

menuentry ‘GRUBx2’ —class parrot —class gnu-linux —class gnu —class os $menuentry_id_option ‘gnulinux-simple-382111a2-f993-403c-aa2e-292b5eac4780’ {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod cryptodisk
insmod luks
insmod gcry_twofish
insmod gcry_twofish
insmod gcry_sha512
insmod ext2
cryptomount -u 15c47d1c4bd34e5289df77bcf60ee838
set root=’cryptouuid/15c47d1c4bd34e5289df77bcf60ee838‘
normal /boot/grub/grub.cfg
}

righe
* insmod -caricamento dei moduli necessari per lavorare con il disco crittografato;
* GRUBx2 -nome della riga visualizzata nel menu di avvio di GRUB2;
* cryptomount -u 15c47d1c4bd34e5289df77bcf60ee838 -vedi fdisk -l (sda9);
* set root -impostazione della radice;
* normal /boot/grub/grub.cfg -file di configurazione eseguibile nella partizione crittografata.

Essere certi che venga caricato proprio il «grub.cfg» crittografato è una risposta positiva all'inserimento della password/sblocco di «sdaY» quando si sceglie la riga «GRUBx2» nel menu GRUB.

Lavorando in CLI, per non confondersi (e verificare se è stato applicato il variabile d'ambiente «set root»), crea file vuoti delimitatori, ad esempio, nella partizione crittografata «/shifr_grub», nella partizione non crittografata «/noshifr_grub». Verifica in CLI

cat /Tab-Tab

Come sopra evidenziato, questo non proteggerà dall'avvio di moduli dannosi se tali moduli si trovano sul tuo PC. Ad esempio, un keylogger che può salvare le pressioni dei tasti in un file e mescolarsi con altri file in «~/i386», finché non viene scaricato da un attaccante con accesso fisico al PC.

Il modo più semplice per verificare che la protezione della firma digitale sia attiva (non ripristinata), e che nessuno sia entrato nel bootloader, in CLI digitiamo il comando

list_trusted

in risposta otteniamo una copia della nostra «perskey», o non otteniamo nulla se siamo stati attaccati (è necessario anche verificare «set check_signatures=enforce»).
Un aspetto fondamentale di questo passo è dover immettere manualmente i comandi. Se aggiungiamo questo comando in «grub.cfg» e proteggiamo la configurazione con una firma digitale, allora l'output preliminare della chiave sullo schermo è troppo breve per il timing, e si potrebbe non avere il tempo di leggere l'output, ricevendo il caricamento di GRUB2.
Non c'è nessuno a cui presentare reclami: lo sviluppatore nella sua documentazione p.18.2 dichiara ufficialmente

«Nota che anche con la protezione password di GRUB, GRUB stesso non può impedire a qualcuno con accesso fisico alla macchina di modificare la configurazione del firmware di quella macchina (ad esempio, la configurazione di Coreboot o BIOS) per far avviare la macchina da un dispositivo diverso (controllato dall'attaccante). GRUB è al massimo solo un anello nella catena di avvio sicura».

GRUB2 è troppo sovraccarico di funzionalità che possono dare una falsa sensazione di sicurezza, e il suo sviluppo ha già superato in funzionalità il sistema operativo MS-DOS, eppure è solo un bootloader. È divertente che GRUB2, il «domani», possa diventare un sistema operativo, mentre le macchine virtuali GNU/Linux per esso.

Un breve video su come ho aggirato la protezione della firma digitale di GRUB2 e ho dichiarato la mia intrusione a un utente reale (ho spaventato, e invece di ciò che è mostrato nel video, si può scrivere codice/mod non convenzionale).

Conclusioni:

1) La crittografia del disco di sistema per Windows è più facile da implementare, e la protezione con una password è più comoda rispetto alla protezione con più password nella crittografia del disco di sistema GNU/Linux; va detto per correttezza: quest'ultima è automatizzata.

2) Ho scritto l'articolo come rilevante, dettagliato semplice manuale sulla crittografia completa dei dischi VeraCrypt/LUKS su una macchina domestica, che è attualmente il migliore nel Runet (IMHO). Il manuale contiene più di 50k caratteri, quindi non sono stati trattati alcuni capitoli interessanti: sui crittografi che scompaiono/rimangono nell'ombra; sul fatto che nei vari libri su GNU/Linux si scrive poco o nulla sulla crittografia; sull'art.51 della Costituzione della Federazione Russa; su licenze/запрете della crittografia nella Federazione Russa, e sul perché è necessario crittografare il «root/boot». Il manuale è risultato già piuttosto voluminoso, ma dettagliato (descrivendo anche i semplici passaggi), il che, a sua volta, ti farà risparmiare un sacco di tempo quando ti dedicherai alla «vera crittografia».

3) La crittografia completa dei dischi è stata condotta su Windows 7 64; GNU/Linux Parrot 4x; GNU/Debian 9.0/9.5.

4) Ho realizzato un attacco di successo sul mio bootloader GRUB2.

5) Il tutorial è stato creato per aiutare tutti i paranoici della CIS, dove il lavoro con la crittografia è consentito a livello legislativo. E soprattutto per coloro che desiderano implementare la crittografia a disco intero senza cancellare i propri sistemi configurati.

6) Ho rielaborato e aggiornato la mia guida, che è attuale nel 2020.

[G] Documentazione utile

1. Guida dell'utente TrueCrypt (febbraio 2012 RU)
2. Documentazione VeraCrypt
3. /usr/share/doc/cryptsetup(-run) [локальный ресурс] (documentazione ufficiale dettagliata per la configurazione della crittografia GNU/Linux tramite cryptsetup)
4. FAQ ufficiale di cryptsetup (documentazione breve per la configurazione della crittografia GNU/Linux tramite cryptsetup)
5. Crittografia del dispositivo LUKS (documentazione archlinux)
6. Descrizione dettagliata della sintassi di cryptsetup (pagina della guida arch)
7. Descrizione dettagliata di crypttab (pagina della guida arch)
8. Documentazione ufficiale GRUB2.

Etichette: crittografia dell'intero disco, crittografia della partizione, crittografia a disco intero Linux, crittografia di sistema completo LUKS1.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.

Stai crittografando?

• 17,1%Crittografo tutto ciò che è possibile. Ho la paranoia.14

• 34,2%Crittografo solo i dati importanti.28

• 14,6%A volte crittografo, a volte dimentico.12

• 34,2%No, non crittografo, è scomodo e costoso.28

Hanno votato 82 utenti. 22 utenti si sono astenuti.

Fonte: habr.com