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

Guida aggiornata al full disk encryption nel Runet V0.2.

Strategia Cowboy:

[A] crittografia di sistema a blocchi per Windows 7 installato;
[B] crittografia di sistema a blocchi per GNU/Linux (Debian) sistema installato (incluso /boot);
[C] configurazione GRUB2, protezione del bootloader tramite 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 del sistema, non nascosta;
├──╼ GNU/Linux installato (Debian e distribuzioni derivate) — crittografia completa del sistema non nascosta(/, inclusa /boot; swap);
├──╼ bootloader indipendenti: bootloader VeraCrypt installato in MBR, bootloader GRUB2 installato nella partizione estesa;
├──╼ installazione/reinstallazione del sistema operativo non necessaria;
└──╼ software crittografico utilizzato: VeraCrypt; Cryptsetup; GnuPG; Seahorse; Hashdeep; GRUB2 – libero/gratuito.

Lo schema sopra descritto risolve parzialmente il problema del «boot esterno su USB», permettendo di godere di sistemi operativi Windows/Linux criptati e di scambiare dati attraverso un «canale criptato» da un OS all'altro.

Ordine di avvio del PC (una delle opzioni):

• accensione della macchina;
• avvio del bootloader VeraCrypt (l'inserimento corretto della password continuerà il caricamento di Windows 7);
• premere il tasto «Esc» caricherà il bootloader GRUB2;
• bootloader GRUB2 (selezione della distribuzione/GNU/Linux/CLI), richiederà l'autenticazione dell'utente superuser GRUB2 <login/password>;
• dopo una corretta autenticazione e selezione della distribuzione, sarà necessario inserire la passphrase per sbloccare «/boot/initrd.img»;
• dopo aver inserito correttamente le password in GRUB2 «sarà necessario» inserire la password (la terza password, la password del BIOS o la password dell'account utente GNU/Linux – non considerare) per sbloccare e avviare il sistema operativo GNU/Linux, oppure la sostituzione automatica della chiave segreta (due password + chiave, oppure password+chiave);
• un'intrusione esterna nella configurazione di GRUB2 congelerà il processo di avvio di GNU/Linux.

Complicato? Bene, procediamo ad automatizzare i processi.

Quando si partiziona il disco rigido (tabella MBR) Il PC può avere al massimo 4 partizioni primarie, o 3 primarie e una estesa, oltre a uno spazio non allocato. A differenza della partizione primaria, la partizione estesa può contenere sottopartizioni. (dischi logici=partizione estesa). In altre parole, la «partizione estesa» su un HDD sostituisce LVM per l'attuale compito: la crittografia completa del sistema. Se il tuo disco è partizionato in 4 partizioni primarie, dovrai usare lvm, oppure trasformare (con formattazione) una partizione primaria in estesa, oppure sfruttare correttamente tutte e quattro le partizioni e lasciare tutto com'è, ottenendo il risultato desiderato. Anche se hai solo una partizione sul disco, Gparted può aiutarti a suddividere l'HDD (in ulteriori partizioni) senza perdita di dati, ma con un piccolo prezzo da pagare per tali azioni.

Lo schema di partizionamento del disco rigido, rispetto al quale si svilupperà tutta l'articolo, è presentato nella tabella sottostante.

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

Qualcosa di simile dovrebbe esserci anche per te.
sda1 — partizione primaria n°1 NTFS (criptata);
sda2 — partizione estesa marcata;
sda6 — disco logico (su cui è installato il bootloader GRUB2);
sda8 — swap (file di paging crittografato/non sempre);
sda9 — disco logico di prova;
sda5 — disco logico per i curiosi;
sda7 — sistema operativo GNU/Linux (sistema operativo trasferito su disco logico crittografato);
sda3 — partizione principale №2 con sistema operativo Windows 7 (crittografato);
sda4 — partizione principale №3 (vi è un GNU/Linux non crittografato, utilizzato per backup/non sempre).

[А] Crittografia di sistema a blocchi Windows 7

A1. VeraCrypt

Avvio da sito ufficiale, oppure da mirror sourceforge versione di installazione del software crittografico VeraCrypt (alla data di pubblicazione dell'articolo v1.24-Update3, la versione portatile di VeraCrypt non è adatta per la crittografia di sistema). Controlla l'hash del software scaricato

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

e confronta il risultato ottenuto con l'hash pubblicato sul sito dello sviluppatore VeraCrypt.

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

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

A2. Installazione/esecuzione di VeraCrypt con diritti di amministratore

A3. Selezione delle opzioni di crittografia di sistema per la partizione attivaVeraCrypt – Sistema – Cripta la partizione/disk di sistema – Standard – Cripta la partizione Windows – Multiavvio – (avviso: «Questo metodo non è raccomandato per gli utenti inesperti» e questo è vero, siamo d'accordo «Sì») – Disco avviabile («sì», anche se non è così, comunque «sì») – Numero di dischi di sistema «2 o più» – Più sistemi su un disco «Sì» – Non Windows bootloader «No» (in effetti «Sì», ma i bootloader VeraCrypt/GRUB2 non condivideranno l'MBR, in realtà, nell'MBR/settore di avvio è memorizzata solo la parte più piccola del codice del bootloader, la parte principale si trova all'interno del file system) – Multiavvio – Impostazioni parametri di crittografia…

Se si devia dai passaggi sopra descritti (schemi di crittografia sistematica a blocchi), VeraCrypt emetterà un avviso e non permetterà di crittografare la partizione.

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

VeraCrypt supporta la possibilità di crittografare i dischi in cascata AES(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (senza supporto hardware AES, crittografia in cascata A/T) la riduzione delle prestazioni è praticamente impercettibile. (sui CPU AMD della stessa epoca/~parametri — le prestazioni sono leggermente inferiori). Il sistema operativo funziona dinamicamente e il consumo di risorse per la crittografia trasparente è impercettibile. A differenza, ad esempio, di una riduzione delle prestazioni evidente a causa dell'installazione di un ambiente desktop di test instabile come Mate v1.20.1 (o v1.20.2 non ricordo esattamente) in GNU/Linux, oppure a causa del funzionamento del sottoprogramma di telemetria in Windows7↑. Di solito, gli utenti esperti effettuano test sulle prestazioni dell'hardware prima della crittografia. Ad esempio, in Aida64/Sysbench/systemd-analyze blame e confrontano con i risultati degli stessi test dopo la crittografia del sistema, confutando così il mito che "la crittografia del sistema è dannosa". Il rallentamento della macchina e il disagio sono evidenti durante il backup/ripristino dei dati crittografati, poiché l'operazione di "backup dei dati di sistema" non viene misurata in millisecondi, e si aggiungono quelle famose . In definitiva, ogni utente autorizzato a lavorare con la crittografia stabilisce un equilibrio tra l'algoritmo di crittografia rispetto alla soddisfazione degli obiettivi prefissati, al grado della propria paranoia e alla comodità d'uso.

È meglio lasciare il parametro PIM impostato su predefinito, in modo da non dover inserire ogni volta i valori esatti delle iterazioni durante il caricamento del sistema operativo. VeraCrypt applica un numero enorme di iterazioni per creare un vero "hash lento". Un attacco a tale "crittografia in asta" tramite brute force/tabelle arcobaleno ha senso solo se la frase di accesso è breve e nel charset personale della vittima. Il prezzo da pagare per la robustezza della password è un ritardo nell'inserimento corretto della password durante il caricamento del sistema operativo. (il montaggio dei volumi VeraCrypt in GNU/Linux è significativamente più veloce).
Software libero per la realizzazione di attacchi brute force. (estrazione della frase di accesso dall'intestazione del disco VeraCrypt/LUKS). Hashcat. John the Ripper non riesce a "decifrare VeraCrypt", e quando si lavora con LUKS non comprende la crittografia Twofish.

A causa della robustezza crittografica degli algoritmi di crittografia, i crittografi senza limiti sviluppano software con un altro vettore d'attacco. Ad esempio, l'estrazione di metadati/chiavi dalla RAM. (attacco con attrezzatura fredda/accesso diretto alla memoria), esiste software specializzato, sia libero che proprietario, per questi scopi.

Al termine della configurazione/generazione dei "metadati unici" della partizione criptata attiva, VeraCrypt offrirà di riavviare il PC e testare il funzionamento del suo bootloader. Dopo il reboot/avvio di Windows, VeraCrypt si caricherà in modalità attesa, sarà necessario solo confermare il processo di crittografia — Y.

Nell'ultimo passaggio della crittografia di sistema, VeraCrypt offrirà di creare una copia di sicurezza dell'intestazione della partizione criptata attiva sotto forma di "veracrypt rescue disk.iso" — è obbligatorio farlo — in questo software tale operazione è un requisito (nel LUKS, come requisito – questo purtroppo è stato omesso, ma sottolineato nella documentazione). Il disco di salvataggio sarà utile a tutti, e a qualcuno anche più di una volta. La perdita (riscrittura dell'intestazione/MBR) della copia di sicurezza dell'intestazione priverà per sempre l'accesso alla partizione decrittata con OS Windows.

A4. Creazione di un disco USB/disk di salvataggio VeraCryptPer impostazione predefinita, VeraCrypt offre di scrivere "metadati ~2-3 MB" su un disco, ma non tutti hanno dischi o unità DWD-ROM, e creare una chiavetta USB avviabile "VeraCrypt Rescue disk" può risultare una sorpresa tecnica per qualcuno: Rufus/GUIdd-ROSA ImageWriter e altri software simili non riescono a portare a termine il compito, poiché oltre a copiare i metadati spostati sulla chiavetta USB avviabile, è necessario fare un copy/paste al di fuori del file system dell'unità USB, in breve, copiare correttamente MBR/parte sulla chiavetta. Da un sistema operativo GNU/Linux, è possibile creare una chiavetta USB avviabile utilizzando l'utilità "dd", consultando questa tabella.

La creazione di un disco di salvataggio in ambiente Windows è diversa. Il sviluppatore di VeraCrypt non ha incluso una soluzione per questo problema nell'officiale documentazione sul "disco di emergenza", ma ha proposto una soluzione alternativa: ha reso disponibile un software aggiuntivo per creare un "usb rescue disk" in libero accesso, sul suo forum VeraCrypt. L'archivio di questo software per Windows è "creazione usb veracrypt rescue disk". Dopo il salvataggio di rescue disk.iso inizierà il processo di crittografia del sistema a blocchi della partizione attiva. Durante la crittografia, il funzionamento del sistema operativo non si interrompe, non è necessario riavviare il 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", che deve essere impostato sulla partizione dove è presente Windows. (indipendentemente dalla crittografia e da altri sistemi operativi, vedi tabella n. 1).
Questa è la descrizione della crittografia a blocchi del sistema operativoo Windows.

[B] LUKS. Crittografia GNU/Linux (~Debian) sistema operativo installato. Algoritmo e Passi

Per crittografare una distribuzione Debian o derivata installata, è necessario mappare la partizione preparata a un dispositivo a blocchi virtuale, trasferire sul disco GNU/Linux mappato e installare/configurare GRUB2. Se non hai un server nudo e tieni al tuo tempo, è consigliabile utilizzare un'interfaccia grafica, mentre la maggior parte dei comandi da terminale descritti di seguito si intende vengano inseriti in «modalità Chuck Norris».

B1. Avvio del PC con live usb GNU/Linux

«Eseguire un crypto test sulle prestazioni dell'hardware»

lscpu && cryptsetup benchmark

Se sei un fortunato possessore di una macchina potente con supporto hardware per AES, i numeri saranno simili a quelli della parte destra del terminale; se sei fortunato ma hai hardware antico, saranno simili a quelli della parte sinistra.

B2. Partizionamento del disco. montaggio/formattazione del filesystem del disco rigido logico in Ext4 (Gparted)

B2.1. Creazione dell'intestazione crittografata della partizione sda7Descriverò i nomi delle partizioni qui e in seguito secondo la mia tabella delle partizioni, pubblicata sopra. Secondo la tua configurazione del disco, dovresti sostituire i tuoi nomi delle partizioni.

Mappatura 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 passaggio (non chiave/file);
* -v - verbosità (output delle informazioni nel terminale);
* /dev/sda7 - il tuo disco logico dall'unità 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 AES sulla CPU, la scelta migliore sarà creare una partizione estesa "LUKS-Twofish-XTS".

B2.2. Creazione avanzata di una 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 tuo futuro disco logico crittografato;
* -v verbosità;
* -y frase di passaggio;
* -c scelta dell'algoritmo di crittografia dei dati;
* -s dimensione della chiave di crittografia;
* -h algoritmo di hashing/crypto funzione, utilizza il RNG (—use-urandom) per generare una chiave di crittografia/decrittografia unica per l'intestazione della partizione logica, una chiave secondaria dell'intestazione (XTS); una chiave principale unica memorizzata nell'intestazione crittografata del disco, chiave secondaria XTS, tutti questi metadati e la sottoprogramma di crittografia, che con la chiave principale e la chiave secondaria XTS crittografano/decrittografano qualsiasi dato nella partizione (esclusa l'intestazione della partizione) sono memorizzati in ~3 MB nella partizione selezionata del disco rigido.
* -i iterazioni in millisecondi, invece di «quantità» (ritardo temporale durante l'elaborazione della passphrase, influisce sul caricamento del sistema operativo e sulla robustezza crittografica delle chiavi). Per mantenere un equilibrio di robustezza crittografica con una password semplice come «russian» è necessario aumentare il valore di -(i), mentre con una password complessa come «?8dƱob/øfh» il valore può essere ridotto.
* —use-urandom generatore di numeri casuali, genera chiavi e sale.

Dopo l'abbinamento della partizione sda7 > sda7_crypt (l'operazione è veloce, poiché viene creato un'intestazione crittografata con metadati ~3 MB e basta), è necessario formattare e montare il filesystem sda7_crypt.

B2.3. Abbinamento

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

opzioni:
* open -assegnare la partizione con "nome";
* /dev/sda7 -disco logico;
* sda7_crypt -nome assegnato, utilizzato per montare la partizione cifrata o per inizializzarla all'avvio del sistema operativo.

B2.4. Formattazione del filesystem sda7_crypt in ext4. Montaggio del disco nel sistema operativo(Nota: in Gparted non sarà possibile lavorare con la partizione cifrata)

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

opzioni:
* -v -verbalizzazione;
* -L -etichetta del disco (che appare nell'esplora risorse tra gli altri dischi).

Dopo, è necessario montare il dispositivo di blocco virtuale cifrato /dev/sda7_crypt nel sistema

mount /dev/mapper/sda7_crypt /mnt

Lavorare con i file nella cartella /mnt porterà automaticamente alla cifratura/decrittazione dei dati in sda7.

È più comodo assegnare e montare la partizione nell'esplora risorse (nautilus/caja GUI), la partizione sarà già nella lista delle scelte dei dischi, sarà sufficiente inserire solo la frase segreta per aprire/decrittare il disco. Il nome assegnato verrà scelto automaticamente e non sarà "sda7_crypt", ma qualcosa come /dev/mapper/Luks-xx-xx…

B2.5. Backup dell'intestazione del disco (metadati ~3MB)Uno dei più importanti Operazioni che devono essere effettuate senza indugi: eseguire il backup dell'intestazione «sda7_crypt». Se scrivi nuovamente/danneggi l'intestazione (ad esempio, installando GRUB2 nella partizione sda7, ecc.), i dati crittografati saranno persi definitivamente senza alcuna possibilità di recuperarli, poiché non sarà possibile rigenerare le stesse chiavi, che vengono create in modo unico.

#Бэкап заголовка раздела
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 di cui è necessario salvare la copia di backup dell'intestazione crittografata del disco.
A questo punto è completata.

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

Creiamo la cartella /mnt2 (Nota: stiamo ancora lavorando con USB live, nella directory /mnt è montata sda7_crypt), e montiamo il nostro GNU/Linux in /mnt2, che deve essere crittografato.

mkdir /mnt2
mount /dev/sda4 /mnt2

Effettuiamo il corretto trasferimento del sistema operativo usando il software Rsync

rsync -avlxhHX --progress /mnt2/ /mnt

Le opzioni di Rsync sono descritte nel p.E1.

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

e4defrag -c /mnt/ #dopo la verifica, e4defrag mostrerà che il grado di deframmentazione della partizione~"0", è un'illusione che può costarti una significativa perdita di prestazioni!
e4defrag /mnt/ #effettuare la deframmentazione del GNU/Linux criptato

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

V4. Configurare GNU/Linux sulla partizione criptata sda7

Dopo il trasferimento riuscito del sistema operativo /dev/sda4 > /dev/sda7, è necessario accedere a GNU/Linux sulla partizione criptata e procedere con la configurazione (senza riavviare il PC) relativamente al sistema criptato. Cioè, trovarsi in live USB, ma eseguire i comandi 'rispetto alla radice del sistema operativo criptato'. Simulare una situazione simile sarà 'chroot'. Per ricevere informazioni in tempo reale su quale sistema operativo stai utilizzando attualmente (se è criptato o meno, poiché i dati in sda4 e sda7 sono sincronizzati), disincronizza i sistemi operativi. Crea nelle directory principali (sda4/sda7_crypt) file vuoti di marcatura, ad esempio, /mnt/sistemaCriptato e /mnt2/sistemaDecifrato. Controllo rapido su quale sistema operativo ti trovi (incluso per il futuro):

ls /

B4.1. «Simulazione dell'accesso a un 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 avvenga rispetto al sistema crittografato

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

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

B4.3. Creazione/impostazione dello 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 sul disco logico ora e inserire i comandi come in p.B2.2. Per lo swap, a ogni avvio verranno generati automaticamente delle chiavi di crittografia temporanee. Il ciclo di vita delle chiavi dello swap: smontaggio/disattivazione della partizione swap (+pulizia della RAM); o 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 durante la crittografia /dev/mapper/swap.
* /dev/sda8 - utilizza la tua partizione logica per lo swap.
* /dev/urandom - generatore di chiavi casuali per la crittografia dello swap (ad ogni nuovo avvio del sistema operativo — vengono creati nuove chiavi). Il generatore /dev/urandom è meno casuale di /dev/random, in quanto /dev/random viene utilizzato in circostanze paranoiche pericolose. Durante l'avvio del sistema operativo, /dev/random rallenta il caricamento di alcuni ± minuti. (vedi systemd-analyze).
* swap,cipher=twofish-xts-plain64,size=512,hash=sha512: - la partizione sa che è 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 volete dedicare un'intera partizione a un file di swap, potete optare per un metodo alternativo e migliore: creare un file di swap all'interno di un file su una partizione crittografata con il sistema operativo.

fallocate -l 3G /swap #creazione di un file di dimensione 3GB (operazione quasi istantanea)
chmod 600 /swap #impostazione dei permessi
mkswap /swap #creiamo un file di swap dal file
swapon /swap #attiviamo il nostro swap
free -m #verifichiamo che il file di swap sia attivo 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 menzionato in precedenza, descrive i dispositivi a blocchi crittografati che vengono configurati durante l'avvio del sistema.

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

se hai associato la partizione sda7>sda7_crypt come in p.B2.1

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

se hai associato 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 associato 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 durante l'avvio del sistema operativo, per sbloccare la radice è necessario inserire una frase segreta.
* UUID - identificatore della partizione. Per conoscere il tuo identificatore, digita nel terminale (ricorda che per tutto questo tempo e oltre, stai lavorando nel terminale in ambiente chroot, e non in un altro terminale live usb).

fdisk -l # controlla tutte le partizioni
blkid # dovrebbe apparire 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 esattamente dal tuo sdaX (non sdaX_crypt!, UUID sdaX_crypt verrà automaticamente escluso durante la generazione del file di configurazione grub.cfg).
* cipher=twofish-xts-plain64,size=512,hash=sha512 -luks crittografia in modalità avanzata.
* /etc/skey - file segreto della chiave, che viene automaticamente utilizzato per sbloccare il caricamento del sistema operativo (invece di inserire la terza password). È possibile specificare un file di qualsiasi grandezza fino a 8MB, ma i dati verranno letti <1MB.

#Создание "генерация" случайного файла <секретного ключа> размером 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ì:

(fate da soli e vedrete).

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

/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 mappato sda7>sda7_crypt, che è specificato nel file /etc/crypttab.
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 commentare (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 che si occupa di generare 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 accedervi durante il boot (insmod-ys ).
deve esserci una somiglianza

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 anche adesso, questo parametro non avrà alcun effetto, ma a volte ostacola 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

aggiungerla

KEYFILE_PATTERN=»/etc/skey»
UMASK=0077

Questo impacchetterà la chiave segreta «skey» in initrd.img, la chiave è necessaria per sbloccare la radice durante il boot del sistema operativo (se non si desidera immettere la password di nuovo, la chiave «skey» verrà inserita automaticamente).

B4.6. Aggiornamento /boot/initrd.img [versione]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 è certo») possono apparire avvisi relativi a cryptsetup, o ad esempio, una notifica di perdita dei moduli Nvidia — è un fenomeno normale. Dopo aver aggiornato il file, controlla che sia effettivamente aggiornato vedi per tempo (relativamente all'ambiente chroot./boot/initrd.img). Attenzione! prima di [update-initramfs -u -k all] assicurati di controllare che cryptsetup open /dev/sda7 sda7_crypt — questo è il nome che deve figurare in /etc/crypttab, altrimenti dopo il reboot si verificherà l'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 (la partizione deve avere almeno 20 MB)

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

C2. Montare /dev/sda6 in /mntDal momento che stiamo lavorando in chroot, non ci sarà una cartella /mnt2 nella radice, mentre la cartella /mnt sarà vuota.
montiamo la partizione GRUB2

mount /dev/sda6 /mnt

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

apt-get update
apt-get install grub2 

Importante! Durante l'aggiornamento del pacchetto GRUB2 dal repository, alla domanda "dove installare il bootloader" è necessario rifiutare l'installazione. (motivo - tentativo di installazione di GRUB2 - in "MBR" o su live usb). Altrimenti, danneggerai l'intestazione/bootloader di VeraCrypt. Dopo aver aggiornato i pacchetti GRUB2 e annullato l'installazione, dovrai installare il bootloader manualmente sul disco logico, e non in "MBR". Se nel tuo repository è presente una versione obsoleta di GRUB2, prova ad aggiornarlo dal sito ufficiale - non ho verificato (ho lavorato con i bootloader GRUB 2.02 ~BetaX recenti).

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

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

opzioni
* —force - installa il bootloader ignorando tutti i messaggi di avviso, che di solito sono presenti e bloccano l'installazione (flag obbligatorio).
* —root-directory - imposta la directory nella radice di 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 utilizza il comando completo per generare il file di configurazione

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

dopo il completamento della generazione/aggiornamento del file grub.cfg, nel terminale dovrebbero apparire righe con i sistemi operativi trovati sul disco («grub-mkconfig» potrebbe trovare e includere sistemi operativi da live usb, se avete una chiavetta multiboot con Windows 10 e vari live distro — è normale). Se nel terminale c'è «vuoto», il file «grub.cfg» non è stato generato, questo è il caso in cui ci sono bug nel sistema GRUB (e probabilmente il bootloader è dalla versione sperimentale del repository), reinstallate GRUB2 da fonti affidabili.
Installazione della «configurazione semplice» e configurazione di GRUB2 completata.

C5. Test di prova del sistema operativo GNU/Linux crittografatoConcludiamo correttamente la missione crittografica. Uscire 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 su live usb
reboot

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


*Inserire la password per la partizione attiva — inizierà il caricamento del sistema operativo Windows.
*La pressione del tasto «Esc» trasferirà il controllo a GRUB2; per scegliere GNU/Linux crittografato sarà necessaria una password (sda7_crypt) per sbloccare /boot/initrd.img (se grub2 riporta uuid «non trovato» — si tratta di un problema del bootloader grub2, che dovrebbe essere reinstallato, ad esempio, dalla branch di test/stabile e p.d.).


*A seconda di come hai configurato il sistema (vedi p.B4.4/4.5) dopo aver inserito correttamente la password per sbloccare l'immagine /boot/initrd.img, sarà necessaria una password per caricare il kernel/root OS, oppure verrà automaticamente inserita la chiave segreta «skey», eliminando la necessità di reinserire la frase di accesso.

(screenshot «inserimento automatico della chiave segreta»).

*Dopo seguirà il consueto processo di avvio di GNU/Linux con l'autenticazione dell'utente.


*Dopo l'autenticazione 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 superflue nel menu GRUB2 (dal rilevamento dell'OS con live usb) eliminarle

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

Riassunto sul crittografamento del sistema GNU/Linux:

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

«Configurazione semplice di GRUB2» crittografia del volume blocco completata.

C6. Configurazione avanzata di GRUB2. Protezione del bootloader con firma digitale + protezione tramite autenticazioneGNU/Linux è completamente crittografato, ma il bootloader non può essere crittografato – tale condizione è dettata dal BIOS. Per questo motivo, il caricamento crittografato in catena di GRUB2 non è possibile, ma un caricamento in catena semplice è disponibile; in termini di protezione – non è necessario [vedi P. F].
Per il GRUB2 'vulnerabile', gli sviluppatori hanno implementato un algoritmo di protezione del bootloader tramite 'firma/autenticazione'.

• Con la protezione del bootloader 'con la propria firma digitale', la modifica esterna dei file, o tentativi di caricare moduli aggiuntivi in questo bootloader, porteranno a un blocco del processo di avvio.
• Con la protezione del bootloader tramite autenticazione, per scegliere di avviare un determinato sistema operativo, o per immettere comandi aggiuntivi nel CLI, sarà necessaria l'immissione delle credenziali dell'utente super-GRUB2.

C6.1. Protezione del bootloader tramite autenticazioneVerifica di lavorare nel terminale su un sistema operativo crittografato

ls / #rileva file marker

crea una password di superutente per l'autenticazione in GRUB2

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

Ottieni l'hash della password. Qualcosa del genere

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

montare la partizione GRUB

mount /dev/sda6 /mnt 

modificare la configurazione

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

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

Dovrebbe essere circa 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, aggiungi le righe sopra descritte (login/password) in uno script personalizzato 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 che gestiscono l'autenticazione verranno aggiunte automaticamente a grub.cfg.
In questo passaggio, la configurazione dell'autenticazione GRUB2 è completata.

C6.2. Protezione del bootloader con firma digitaleSi presume che tu abbia già la tua chiave PGP personale per la crittografia (oppure crea una chiave del genere). Nel sistema deve essere installato il software crittografico: gnuPG; kleopatra/GPA; Seahorse. Il software crittografico ti semplificherà notevolmente la vita in tutte queste operazioni. Seahorse è la versione stabile del pacchetto 3.14.0 (versioni superiori, come V3.20 – incomplete e con bug significativi).

La chiave PGP deve essere generata/eseguita/aggiunta solo nell'ambiente su!

Generare una chiave di crittografia personale

gpg --gen-key

Esportare la propria chiave

gpg --export -o ~/perskey

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

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

pulire la partizione GRUB2

rm -rf /mnt/

Installare GRUB2 in sda6, mettendo la tua chiave personale nell'immagine principale 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 bootloader, ignorando tutti i warning che ci sono sempre. (flag obbligatorio).
* —modules="gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa" -istruisce GRUB2 a caricare in anticipo i moduli necessari all'avvio del PC.
* -k ~/perskey -percorso fino alla "chiave PGP". (dopo aver impacchettato la chiave nell'immagine, può essere rimossa).
* —root-directory -imposta la directory boot nella radice di sda6.
/dev/sda6 -ваш sdaХ раздел.

Generiamo/aggiorniamo grub.cfg.

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

Aggiungiamo alla fine del file "grub.cfg" la riga "trust /boot/grub/perskey". (utilizzare 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 comandi al config 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 un particolare partizione del disco per il percorso a "/boot/grub/perskey", poiché per il bootloader "radice" è il percorso predefinito della partizione su cui è installato GRUB2. (vedi set rot=..).

Firmiamo GRUB2. (tutti i file in tutte le directory /GRUB). con la nostra chiave "perskey".
Una soluzione semplice per firmare. (per il file manager nautilus/caja): installiamo l'estensione «seahorse» per il file manager dal repository. La chiave dovrebbe essere aggiunta all'ambiente su.
Aprite il file manager come sudo «/mnt/boot» – clic destro – firmare. Nell'immagine appare in questo modo

La chiave «/mnt/boot/grub/perskey» (copiare nella directory grub) deve anche essere firmata con la propria firma. Verificate 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 ha valore, questo metodo elimina la necessità di scrivere uno script bash per firmare «molti file».

Per rimuovere tutte le firme del bootloader (se qualcosa non va)

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

Per evitare di firmare il bootloader dopo un aggiornamento di sistema, blocchiamo 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 tramite firma digitale> l'impostazione avanzata di GRUB2 è completata.

C6.3. Test di prova del bootloader GRUB2, protetto da firma digitale e autenticazioneGRUB2. Quando si seleziona una distribuzione GNU/Linux o si accede alla CLI (linea di comando) è necessaria l'autenticazione dell'utente super. Dopo aver inserito correttamente il login/password, sarà richiesto la password per initrd

Screenshot, autenticazione GRUB2 super utente riuscita.

Se si modifica uno qualsiasi dei file GRUB2/si apportano modifiche a grub.cfg, o si elimina un file/firma, si carica un modulo dannoso .mod, verrà visualizzato un avviso corrispondente. Il caricamento di GRUB2 sarà sospeso.

Screenshot, tentativo di interferire con GRUB2 "dall'esterno".

Durante un caricamento "normale" "senza interferenze", il codice di stato del sistema in uscita è "0". Quindi non è chiaro se la protezione funzioni o meno. (vale a dire "con protezione del bootloader tramite firma o senza di essa" durante un caricamento normale, lo stato è lo stesso "0" — questo è negativo).

Come verificare la protezione tramite firma digitale?

Metodo scomodo per la verifica: modificare/eliminare il modulo GRUB2 utilizzato, ad esempio, eliminare la firma luks.mod.sig e ricevere un errore.

Metodo corretto: accedere al CLI del bootloader e digitare il comando

trust_list

Dovrebbe rispondere con l'impronta "perskey", se lo stato è "0", significa che la protezione tramite firma non funziona, ricontrollare p.C6.2.
A questo punto, la configurazione avanzata "Protezione GRUB2 tramite firma digitale e autenticazione" è completata.

C7 Metodo alternativo per la protezione del bootloader GRUB2 tramite hashingIl metodo descritto sopra "Protezione del bootloader CPU/Autenticazione" è un classico. A causa delle imperfezioni di GRUB2, in situazioni paranoiche è soggetto a un attacco reale, che descriverò di seguito nella p.[F]. Inoltre, dopo un aggiornamento del sistema operativo/nucleo è necessario risignare il bootloader.

Protezione del bootloader GRUB2 tramite hashing

Vantaggi rispetto al classico:

• Un livello di affidabilità superiore (l'hashing/verifica avviene solo da una risorsa locale crittografata. Viene controllata l'intera partizione dedicata a GRUB2 per eventuali modifiche, mentre tutto il resto è crittografato; nel classico schema di protezione del bootloader CPU/Autenticazione vengono controllati solo i file, ma non lo spazio libero in cui si potrebbe scrivere "qualcosa di sinistro").
• Registrazione crittografata (viene aggiunto un registro crittografato personale leggibile).
• Velocità (la protezione/verifica dell'intera partizione dedicata a GRUB2 avviene praticamente in tempo reale).
• Automazione di tutti i processi crittografici.

Svantaggi rispetto al classico.

• Falsificazione della firma (teoreticamente, è possibile trovare una collisione di funzione hash).
• Livello di difficoltà elevato (rispetto alla versione classica, è richiesto un po' più di skill nell'uso di GNU/Linux).

Come funziona l'idea di hash di GRUB2/partizione

La partizione di GRUB2 viene "firmata"; al caricamento del sistema operativo, avviene un controllo dell'integrità della partizione di avvio con conseguente registrazione in un ambiente sicuro (cifrato). In caso di compromissione del bootloader o della sua partizione, oltre al log degli accessi, viene avviato un controllo.

Cosa.

Quattro volte al giorno si effettua un controllo analogo che non grava sulle risorse di sistema.
Utilizzando il comando «-$ controllo_GRUB» si può effettuare un controllo immediato in qualsiasi momento senza registrazione, ma con output di informazioni nel CLI.
Utilizzando il comando «-$ sudo firma_GRUB» si effettua una nuova firma immediata del bootloader GRUB2/partizione e la sua registrazione aggiornata (necessario dopo l'aggiornamento del sistema operativo/boot) e la vita continua.

Implementazione del metodo di hash del bootloader e della sua partizione

0) Firmiamo il bootloader/partizione GRUB, montandolo preventivamente 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, assegnando i permessi di sicurezza 744 e protezione contro l'«idiota».

Riempirne il 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

Avviamo lo script da su, verrà eseguita la verifica dell'hashing della partizione GRUB e del suo bootloader, salva il log.

Creiamo o copiamo, ad esempio, un «file dannoso» [virus.mod] nella partizione GRUB2 e avviamo una verifica/test temporanea:

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

Nel CLI dobbiamo 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 partizione in fase di test, invece di «Nuovi file trovati» > «File spostati»

2) Mettiamo la gif qui > ~/warning.gif, impostiamo i permessi 744.

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

-$ sudo nano /etc/fstab

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

4) Effettuiamo 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 job in cron

-$ sudo crontab -e

riavvia ‘/podpis’
0 */6 * * * ‘/podpis

6) Creiamo alias permanenti

-$ sudo su
-$ echo "alias firma_GRUB='hashdeep -c md5 -r /media/username/GRUB > /podpis.txt'" >> /root/.bashrc && bash
-$ echo "alias verifica_GRUB='hashdeep -vvv -a -k '/podpis.txt' -r /media/username/GRUB'" >> .bashrc && bash

Dopo l'aggiornamento del sistema operativo -$ apt-get upgrade ripetiamo la firma della nostra partizione GRUB
-$ firma_GRUB
A questo punto, la protezione tramite hashing della partizione GRUB è completata.

[D] Pulizia — distruzione di dati non criptati

Elimina i tuoi file personali in modo tale che «anche Dio non possa leggere», secondo il rappresentante della Carolina del Sud, Trey Gowdy.

Come sempre, esistono diversi «miti e leggende» sulla possibilità di recuperare dati dopo che sono stati eliminati dal disco rigido. Se credi nel recupero dei dati, o sei un membro della comunità Dr Web e non hai mai provato a recuperare dati dopo che sono stati eliminati/sovrascritti (ad esempio, recupero tramite R-studio), allora il metodo proposto difficilmente ti sarà utile, utilizza ciò che ti si addice di più.

Dopo il trasferimento riuscito di GNU/Linux su una partizione crittografata, la vecchia copia deve essere eliminata senza possibilità di recupero. Un metodo universale di pulizia: software per Windows/Linux, software GUI gratuito BleachBit.
Veloce formattiamo la partizione, i cui dati devono essere distrutti (con Gparted), avviamo BleachBit, selezioniamo «Pulizia dello spazio libero» – scegliamo la partizione (il tuo sdaX con la passata copia di GNU/Linux), si avvierà il processo di pulizia. BleachBit pulisce il disco in un solo passaggio — è proprio ciò di cui «abbiamo bisogno». Ma! funziona così solo in teoria, se hai formattato il disco e pulito con il software BB v2.0.

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

E il mito sulla possibilità di recupero dei dati non è del tutto un mito.Bleachbit V2.0-2 era un pacchetto unstable di OS Debian (e qualsiasi altro software simile: sfill; wipe-Nautilus -sono stati notati anche in questo affare sporco) aveva in realtà 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 vengono considerati dal sistema operativo/software come dati non eliminati/utenti e durante la pulizia «OSR» questi file vengono saltati. Il problema è che dopo una tale pulizia prolungata del disco i «file eliminati» possono essere recuperati anche dopo 3+ passaggi di pulizia del disco.
Su GNU/Linux in Bleachbit 2.0-2 funzioni di eliminazione permanente di file e directory funzionano in modo affidabile, ma non la pulizia dello spazio libero. A titolo di confronto: su Windows nel software CCleaner la funzione "Wipe for ntfs" funziona correttamente, e Dio non potrà davvero leggere i dati eliminati.

Quindi, per eliminare definitivamente dati "compromessi" non crittografati, Bleachbit necessita di accesso diretto a questi dati, quindi utilizzare la funzione "eliminazione file/directory permanentemente".
Per eliminare i "file eliminati con gli strumenti di sistema OS" in Windows, utilizzare CCleaner/BB con la funzione "Wipe". Su GNU/Linux, su questo problema (eliminazione di file eliminati) dovete esercitarvi autonomamente (eliminazione dei dati + tentativo autonomo di recupero e non dovrete fare affidamento sulla versione del software (se non un backdoor, allora un bug)), solo in questo modo capirete il meccanismo di questo problema e potrete sbarazzarvi dei dati eliminati definitivamente.

Bleachbit v3.0 non è stato testato, potrebbe che il problema sia già stato risolto.
Bleachbit v2.0 funziona onestamente.

A questo punto, la "pulizia del disco" è completata.

[E] Backup universale per sistemi operativi crittografati

Ogni utente ha il proprio metodo per il backup dei dati, ma i dati crittografati dei "sistemi operativi" richiedono un approccio leggermente diverso. Software unificati, come ad esempio "Clonezilla" e strumenti simili non possono lavorare direttamente con dati crittografati.

Obiettivi del backup di dispositivi a blocchi crittografati:

1. università — lo stesso algoritmo/software di backup per Windows/Linux;
2. possibilità di operare in console con qualsiasi live USB GNU/Linux senza dover scaricare software aggiuntivo (ma consiglio comunque un'interfaccia grafica);
3. sicurezza dei backup — le "immagini" memorizzate 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 (senza la necessità di decifrare prima l'intero 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 a quasi tutti i punti richiesti, ma per il punto 4 non regge alla critica, poiché copia l'intera sezione del disco, compreso lo spazio libero — non interessante.

Ad esempio, il backup di GNU/Linux tramite l'archiviatore [tar» | gpg] è comodo, ma per il backup di Windows è necessario cercare una soluzione alternativa — non interessante.

E1. Backup universale Windows/Linux. Integrazione rsync (Grsync) + VeraCrypt volume.Algoritmo di creazione del backup:

1. creazione di un contenitore crittografato (volume/file) VeraCrypt per OS;
2. trasferimento/sincronizzazione del sistema operativo tramite 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 (la creazione di un DV è disponibile solo in Windows, ma può essere utilizzato anche in GNU/Linux);
creazione di un volume normale, ma c'è un requisito di "natura paranoica" (secondo le parole dello sviluppatore) – formattazione del contenitore.

Il volume dinamico viene creato praticamente istantaneamente in Windows, ma durante il trasferimento dei dati da GNU/Linux > VeraCrypt DV, in generale, le prestazioni dell'operazione di backup diminuiscono notevolmente.

Un volume standard 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'unica passata, a causa di requisiti di sicurezza). In VeraCrypt Windows/Linux è stata rimossa la funzione di formattazione rapida del volume durante la creazione, quindi il contenitore può essere creato solo tramite 'riscrittura in un'unica passata', oppure creando un volume dinamico a bassa potenza.

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

Configuriamo/costruiamo/apriamo il contenitore nell'interfaccia GUI di VeraCrypt> USB live GNU/Linux (il volume sarà montato automaticamente in /media/veracrypt2, il volume OS Windows montato in /media/veracrypt1). Creiamo un backup crittografato del sistema operativo Windows utilizzando l'interfaccia GUI rsync (grsync), selezionando le caselle.

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

In modo analogo, creare un backup del sistema operativo GNU/Linux, disattivando la casella di compatibilità con Windows nell'interfaccia GUI rsync.

Attenzione! il contenitore Veracrypt per il 'backup di GNU/Linux' deve essere creato nel file system ext4. Se eseguite il backup in un contenitore ntfs, perderete tutti i diritti/gruppi su tutti i vostri dati al momento del ripristino di quella copia.

È possibile eseguire tutte le operazioni anche nel terminale. Le principali opzioni per rsync:
* -g -salvare i gruppi;
* -P —progress — stato del tempo di lavoro sul file;
* -H -copiare i hard link così come sono;
* -a -modalità archivio (più flag rlptgoD);
* -v -verbalizzazione.

Se desideri montare il "volume Windows VeraCrypt" tramite la console nel software cryptsetup, puoi 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, con il comando «veramount pictures», verrà richiesta l'immissione della password, e il volume di sistema Windows crittografato sarà montato nel sistema operativo.

Comando per associare/montare il volume di sistema VeraCrypt in cryptsetup

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

Comando per associare/montare la partizione/contenitore VeraCrypt in cryptsetup

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

Invece di un alias, aggiungiamo (script all'avvio automatico) il volume di sistema con OS Windows e il disco crittografato logico ntfs all'avvio automatico 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 #decodifica la password da base64 (bob) e la invia alla richiesta di 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/ContenitoreNtfs #in modo simile, ma montiamo il disco logico ntfs.

Impostiamo i diritti "corretti":

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

Impostiamo i diritti "corretti":

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

Tutto, ora all'avvio di GNU/Linux non dobbiamo inserire le password per montare i dischi cifrati ntfs, i dischi si monteranno automaticamente.

Nota sintetica su quanto descritto sopra nel p.E1 passo dopo passo (ma ora per OS GNU/Linux)
1) Creare un volume in fs ext4 > 4gb (per il file) Linux in Veracrypt [Cassetta Critica].
2) Riavviare con live usb.
3) ~$ cryptsetup open /dev/sda7 Lunux #mappatura 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 ~/Crittobox Crittobox && mount /dev/mapper/Crittobox /mnt2 #Mappatura del volume Veracrypt chiamato «Crittobox» e montaggio del Crittobox in /mnt2.
7) ~$ rsync -avlxhHX —progress /mnt /mnt2/ #operazione di backup della partizione crittografata nel volume crittografato Veracrypt.

(p/s/ Attenzione! Se stai trasferendo GNU/Linux crittografato da un'architettura/macchina all'altra, ad esempio, da Intel > AMD (cioè ripristinando un backup da una partizione crittografata all'altra partizione crittografata Intel > AMD), non dimenticare dopo aver trasferito il sistema operativo crittografato, di modificare la chiave segreta sostitutiva invece della password, poiché la chiave precedente ~/etc/skey — non funzionerà più sulla nuova partizione crittografata, e non è consigliabile creare una nuova chiave con «cryptsetup luksAddKey» da chroot — potrebbe causare problemi, quindi in ~/etc/crypttab indica temporaneamente «none» al posto di «/etc/skey», dopo il riavvio e l'accesso al sistema operativo crea nuovamente la tua chiave segreta sostitutiva.

Come veterani IT, non dimenticate di fare backup separati degli header delle partizioni crittografate dei sistemi operativi Windows/Linux, oppure la crittografia potrebbe rivoltarsi contro di voi.
A questo punto, il backup dei sistemi operativi crittografati è completo.

[F] Attacco al bootloader GRUB2

DettagliSe hai protetto il tuo boot loader con una firma digitale e/o autenticazione (v. p.C6.), questo non proteggerà dalla accesso fisico. I dati crittografati rimarranno inaccessibili, ma la protezione può essere elusa (reset della protezione della firma digitale) GRUB2 consente a un cybercriminale di inserire il proprio codice nel boot loader senza suscitare sospetti (a meno che l'utente non monitori manualmente lo stato del boot loader o non sviluppi un codice di script robusto e arbitrario per grub.cfg).

Algoritmo di attacco. L'aggressore

* Avvia il PC con live usb. Qualsiasi modifica (da parte dell'aggressore) dei file porterà a una notifica al legittimo proprietario del PC circa un'intrusione nel boot loader. Ma una semplice reinstallazione di GRUB2 mantenendo grub.cfg (e successivamente la possibilità di modificarlo) consentirà all'aggressore di modificare qualsiasi file (in questa situazione, al riavvio di GRUB2, non ci sarà notifica all'utente reale. Lo stato rimane lo stesso )
* Monta la partizione non crittografata, salvando "/mnt/boot/grub/grub.cfg".
* Reinstalla il boot loader (escludendo "perskey" dall'immagine core.img)

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

* Restituisce «grub.cfg» > «/mnt/boot/grub/grub.cfg», modificandolo se necessario, ad esempio aggiungendo il proprio modulo «keylogger.mod» nella cartella dei moduli di avvio, nella riga «insmod keylogger» di «grub.cfg». Oppure, per esempio, se il nemico è subdolo, dopo la reinstallazione di GRUB2. (tutte le firme rimangono al loro posto) raccoglie l'immagine principale di GRUB2 utilizzando «grub-mkimage con l'opzione (-s).» L'opzione «-s» consentirà di caricare la propria configurazione prima del caricamento del principale «grub.cfg». La configurazione può consistere in una sola riga: reindirizzamento verso qualsiasi «modern.cfg», miscelato, ad esempio, con ~400 file (moduli+firme) nella cartella «/boot/grub/i386-pc». In questo modo, un intruso 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 forzare il login/password dell'amministratore di GRUB2, l'attaccante non avrà bisogno di superare l'autenticazione, sarà sufficiente copiare le righe (che rispondono 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 rimarrà valida l'autenticazione dell'amministratore di GRUB2.

Boot chaining (il bootloader carica un altro bootloader), come detto prima, non ha senso (è destinata a un altro scopo). A causa del BIOS, non è possibile caricare un bootloader crittografato (nella catena di avvio si verifica il riavvio di GRUB2 > GRUB2 crittografato, errore!). Tuttavia, se si decide di utilizzare l'idea del caricamento a catena, si può essere certi che si sta caricando effettivamente il crittografato (non aggiornato) «grub.cfg» dalla partizione crittografata. E questo è anche un falso senso di sicurezza, perché tutto ciò che è indicato nel «grub.cfg» crittografato (caricamento di moduli) si combina con i moduli che vengono caricati da un GRUB2 non crittografato.

Se vuoi verificare questo, puoi isolare/ criptare un'altra partizione sdaY, copiarci dentro GRUB2 (l'operazione grub-install su una partizione crittografata non è possibile) e in «grub.cfg» (del config non crittografato) modificare le 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
}

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

Avere la certezza che si stia caricando esattamente il «grub.cfg» crittografato è una risposta positiva all'inserimento della password/sblocco di «sdaY» quando si seleziona la voce «GRUBx2» nel menu GRUB.

Quando si lavora in CLI, per non confondersi (e verificare se è stato attivato l'ambiente variabile «set root»), crea file marker vuoti, ad esempio, nella partizione crittografata «/shifr_grub», nella partizione non crittografata «/noshifr_grub». Verifica in CLI

cat /Tab-Tab

Come accennato sopra, questo non aiuterà a prevenire il caricamento di moduli dannosi, se tali moduli sono presenti sul tuo PC. Ad esempio, un keylogger che potrebbe salvare le sequenze di tasti in un file e mescolarsi con altri file in «~/i386», finché non viene scaricato dall'attaccante con accesso fisico al PC.

Il modo più semplice per controllare che la protezione della firma digitale funzioni attivamente (non disabilitata), e che nessuno sia entrato nel bootloader, nel CLI immetti il comando

list_trusted

in risposta otteniamo un'istantanea del nostro «perskey», oppure non otteniamo nulla se siamo stati attaccati (è necessario anche verificare «set check_signatures=enforce»).
Un svantaggio sostanziale di questo passo è dover digitare i comandi manualmente. Se si aggiunge questo comando in «grub.cfg» e si protegge la configurazione con una firma digitale, l'output preliminare dell'istantanea della chiave sullo schermo è troppo breve in termini di tempo, e potrebbe non essere possibile visualizzarlo, risultando in un avvio di GRUB2.
Non c'è nessuno a cui presentare reclami: lo sviluppatore nella sua documentazione p.18.2 dichiara ufficialmente

«Si noti 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 della macchina (ad esempio, Coreboot o BIOS) per costringere la macchina a avviarsi da un dispositivo diverso (controllato dall'attaccante). GRUB è al massimo solo un anello in una catena di avvio sicura».

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

Un breve video su come ho disabilitato la protezione con firma digitale di GRUB2 e dichiarato la mia intrusione a un utente reale (ha spaventato, mentre al posto di quello mostrato nel video – si può scrivere un codice personalizzato non banale/.mod).

Conclusioni:

1) La crittografia del sistema a blocchi per Windows è più semplice da implementare, e la protezione con una sola password è più comoda rispetto alla protezione con più password nella crittografia del sistema a blocchi GNU/Linux; per la verità, quest'ultima è automatizzata.

2) L'articolo è stato scritto come un documento pertinente e dettagliato semplice guida alla crittografia completa del disco VeraCrypt/LUKS su un'unica macchina domestica, che è, ad oggi, la migliore disponibile in rete (IMHO). La guida ha più di 50k caratteri, quindi non sono stati trattati alcuni capitoli interessanti: sui crittografi che scompaiono/restano nell'ombra; su ciò che nei vari libri di GNU/Linux si scrive poco o nulla sulla crittografia; sull'art.51 della Costituzione della Federazione Russa; sul licenziamento/запрете della crittografia in Russia, su perché sia necessario crittografare il ‘root/boot’. La guida è già di per sé discreta, ma dettagliata (che descrive anche passaggi semplici), il che vi farà risparmiare un sacco di tempo quando vi dedicherete alla ‘vera crittografia’.

3) La crittografia completa del disco è stata eseguita su Windows 7 64; GNU/Linux Parrot 4x; GNU/Debian 9.0/9.5.

4) Ho eseguito con successo un attacco al mio bootloader GRUB2.

5) Questo tutorial è stato creato per aiutare tutti i paradosi dell'Asia centrale, dove il lavoro con la crittografia è consentito dalla legge. È rivolto in particolare a coloro che desiderano implementare la crittografia del disco completo senza cancellare i propri sistemi configurati.

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

[G] Documentazione utile

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

Etichette: crittografia del disco completo, crittografia della partizione, crittografia del disco completo Linux, crittografia completa del sistema LUKS1.

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

Stai crittografando?

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

• 34,2%Crittografo solo i dati importanti.

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

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

Hanno votato 82 utenti. 22 utenti si sono astenuti.

Fonte: habr.com