Fuld-disk kryptering Windows Linux installerede systemer. Krypteret multiboot

Opdateret egen vejledning til fuld disk kryptering på nettet V0.2.

Cowboy-strategi:

[A] blokbaseret systemkryptering for Windows 7 installeret system;
[B] blokbaseret systemkryptering GNU/Linux (Debian) installeret system (inklusive /boot);
[C] GRUB2 konfiguration, beskyttelse af bootloader med digital signatur/authentificering/hashering;
[D] rydning – ødelæggelse af ukrypterede data;
[E] universel backup af krypterede OS;
[F] angreb

mål – GRUB2 bootloader;
[G] nyttig dokumentation.

╭───Schema #rum 40# :
├──╼ Windows 7 installeret – fuld systemkryptering, ikke skjult;
├──╼ GNU/Linux installeret (Debian og afledte distributioner) – fuld systemkryptering ikke skjult(/, inklusive /boot; swap);
├──╼ uafhængige bootloadere: VeraCrypt bootloader installeret i MBR, GRUB2 bootloader installeret i den udvidede partition;
├──╼ installation/geninstallation af OS er ikke nødvendig;
└──╼ brugt kryptografisk software: VeraCrypt; Cryptsetup; GnuPG; Seahorse; Hashdeep; GRUB2 – gratis.

Den ovenfor beskrevne skema løser delvist problemet med "ekstern boot på USB-stik", og gør det muligt at nyde krypterede OS Windows/Linux og udveksle data over "krypteret kanal" fra et OS til et andet.

Boot rækkefølge for PC (en af mulighederne):

• tænde maskinen;
• indlæsning af VeraCrypt bootloader (korrekt indtastning af adgangskode fortsætter indlæsningen af Windows 7);
• tryk på "Esc" tasten for at indlæse GRUB2 bootloader;
• GRUB2 bootloader (valg af distribution/GNU/Linux/CLI), vil kræve autentificering af GRUB2-superbruger ;
• efter succesfuld autentificering og valg af distribution, skal der indtastes adgangssætning for at låse "boot/initrd.img" op;
• efter indtastning af korrekte adgangskoder i GRUB2 vil det "kræve" indtastning af adgangskode (den tredje i rækken, BIOS adgangskode eller GNU/Linux brugerens adgangskode – ikke medregnet) for at låse og indlæse GNU/Linux, eller automatisk indsætte hemmelig nøgle (to adgangskoder + nøgle, eller adgangskode+nøgle);
• yderligere indtrængen i GRUB2 konfiguration fryser indlæsningsprocessen for GNU/Linux.

Besværligt? Okay, lad os automatisere processerne.

Ved partitionering af harddisken (MBR tabel) kan PC'en have højst 4 primære partitioner, eller 3 primære og en udvidet, samt ubeskyttet område. Den udvidede partition kan, i modsætning til den primære, indeholde undermapper. (logiske drev=udvidet partition). Med andre ord, "udvidet partition" på HDD erstatter LVM til den aktuelle opgave: fuld systemkryptering. Hvis din disk er partitioneret i 4 primære partitioner, skal du bruge lvm, eller omdanne (med formatering) partitionen fra primær til udvidet, eller klogt udnytte alle fire partitioner og lade det hele være, og opnå det ønskede resultat. Selv hvis du har én partition på disken, kan Gparted hjælpe med at opdele HDD (til ekstra partitioner) uden datatab, men stadig med en lille pris for sådanne handlinger.

Skemaet for partitionering af harddisken, som hele artiklen vil verbiere omkring, er præsenteret i tabellen nedenfor.

Tabel (nr. 1) over partitioner 1TB.

Noget lignende bør du også have.
sda1 — primær partition nr. 1 NTFS (krypteret);
sda2 — udvidet partition markør;
sda6 — logisk drev (hvor bootloader GRUB2 er installeret);
sda8 — swap (krypteret swapfil/ikke altid);
sda9 — test logisk drev;
sda5 — logisk drev til nysgerrige;
sda7 — OS GNU/Linux (flyttet OS til krypteret logisk drev);
sda3 — primær partition nr. 2 med OS Windows 7 (krypteret);
sda4 — primær partition nr. 3 (som havde ukrypteret GNU/Linux, bruges til backup/ikke altid).

[A] Block-kryptering af Windows 7

A1. VeraCrypt

Boot fra den officielle hjemmeside, eller fra et spejl sourceforge installationsversionen af det kryptografiske software VeraCrypt (på tidspunktet for publicering af artiklen v1.24-Update3, vil den bærbare version af VeraCrypt ikke være egnet til systemkryptering). Tjek kontrolsummen for den downloadede software

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

og sammenlign det opnåede resultat med den offentliggjorte kontrolsum på udviklerens hjemmeside VeraCrypt.

Hvis HashTab softwaren er installeret, er det endnu nemmere: højreklik (VeraCrypt Setup 1.24.exe)-egenskaber-hashværdier.

For at kontrollere programmets signatur skal softwaren og den offentlige pgp-nøgle fra udvikleren være installeret gnuPG; gpg4win.

A2. Installation/kørsel af VeraCrypt med administratorrettigheder

A3. Valg af indstillinger for systemkryptering af aktiv partitionVeraCrypt – System – Krypter systempartition/disk – Normal – Krypter Windows systempartition – Multiboot – (advarsel: "Uerfarne brugere anbefales ikke at bruge denne metode" og det er sandt, vi accepterer "Ja") – Boot-disk («ja», selv hvis det ikke er sådan, er det stadig «ja») – Antal systemdiske «2 eller flere» – Flere systemer på én disk «Ja» – Ikke Windows bootloader «Nej» (i virkeligheden «Ja», men bootloaders VeraCrypt/GRUB2 deler ikke MBR imellem sig, nærmere bestemt gemmes kun den mindste del af bootloader-koden i MBR/boot-sektoren, mens hoveddelen ligger inden for filsystemet) – Multiboot – Indstillinger for krypteringsparametre…

Hvis du afviger fra ovenstående fremgangsmåde (blokksystemkrypteringsskemaer), vil VeraCrypt vise en advarsel og forhindre kryptering af partitionen.

I næste trin, til målrettet beskyttelse af data, udfør en «Test» og vælg krypteringsalgoritmen. Hvis du har en ældre CPU, vil Twofish sandsynligvis være den hurtigste krypteringsalgoritme. Hvis CPU'en er kraftig, vil du mærke forskellen: AES — kryptering vil i testresultaterne være flere gange hurtigere end sine konkurrenter. AES er en populær krypteringsalgoritme, og den hardwaremæssige del af moderne CPU'er er specielt optimeret til både «hemmelig» og «krydsning».

VeraCrypt understøtter muligheden for at kryptere diske kaskadisk med AES(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (uden hardwareunderstøttelse af AES, kaskade kryptering A/T) reduktion i ydeevne er på væsentlig set usynlig. (på CPU'er fra AMD fra samme periode/~parametre — ydeevnen er lidt nedsat). OS kører dynamisk, og ressourceforbruget til gennemsigtig kryptering er usynlig. I modsætning til, for eksempel, den mærkbare reduktion i ydeevne på grund af det installerede ustabile desktop-miljø Mate v1.20.1 (eller v1.20.2 husker jeg ikke præcist) I GNU/Linux, eller på grund af telemetri-applikationen i Windows 7↑. Normalt udfører erfarne brugere ydeevnetests af hardwaren før kryptering. For eksempel i Aida64/Sysbench/systemd-analyze blame og sammenligner med resultaterne af de samme tests efter systemets kryptering, hvilket således modbeviser myten, "systemkryptering er skadelig". Maskinens bremse og besværet er tydeligt ved sikkerhedskopiering/gendannelse af krypterede data, fordi selve operationen "systematisk sikkerhedskopiering af data" måles ikke i ms, og de omtalte <dekryptere/kryptere on-the-fly> tilføjes. I sidste ende finder hver bruger, der har tilladelse til at eksperimentere med kryptografi, balancen mellem krypteringsalgoritmen i forhold til opfyldelse af de stillede opgaver, graden af sin paranoia, og brugervenligheden.

Parameteren PIM er bedst at lade være som standard, så man ikke skal indtaste de præcise iterationsværdier hver gang, OS starter. VeraCrypt anvender et enormt antal iterationer for at skabe en virkelig "langsommelig hash". Et angreb på en sådan "kryptoraan" med brute force/rainbow-tables giver kun mening ved en kort "simpel" adgangssætning og offerets personlige charset-liste. Betalingen for adgangskodens modstand er forsinkelsen ved korrekt indtastning af adgangskoden ved opstart af OS. (montering af VeraCrypt-volumener i GNU/Linux er betydeligt hurtigere).
Gratis software til at implementere brute force-angreb. (udtrækning af adgangssætningen fra VeraCrypt/LUKS-diskens header). Hashcat. John the Ripper kan ikke "bryde Veracrypt", og ved arbejde med LUKS forstår den ikke Twofish-kryptografi.

På grund af den kryptografiske modstand styrker, udvikler uheldige kryptofanatikere software med en anden angrebsvektor. For eksempel udtrækning af metadata/nøgler fra RAM. (kold bot-angreb/direkte adgang til hukommelsen), der findes specialiseret gratis og kommerciel software til disse formål.

Ved afslutningen af konfigurationen/genereringen af "unikke metadata" for det krypterede aktive partition, vil VeraCrypt foreslå at genstarte pc'en og teste funktionaliteten af sin bootloader. Efter reboot/start af Windows, vil VeraCrypt indlæse i standby-tilstand, og det vil kun være nødvendigt at bekræfte krypteringsprocessen — Y.

På det sidste trin af VeraCrypt's systemkryptering vil programmet tilbyde at oprette en sikkerhedskopi af headeren for den aktive krypterede partition i form af "veracrypt rescue disk.iso" – dette skal gøres uden undtagelse. i denne software er en sådan operation et krav. (i LUKS, som et krav – det er desværre undervurderet, men fremhævet i dokumentationen). Rescue-diske vil være nyttige for alle, og for nogle endda mere end én gang. Hvis du taber (overskrivning af headeren/MBR) vil manglen på en sikkerhedskopi af headeren permanent fjerne adgangen til den dekrypterede partition med Windows OS.

A4. Oprettelse af en VeraCrypt rescue USB/diskSom standard tilbyder VeraCrypt at brænde "metadata ~2-3MB" på en CD, men ikke alle har diske eller DVD-ROM-drev, og at oprette en bootbar flash-disk "VeraCrypt Rescue disk" kan være en teknisk overraskelse for nogen: Rufus/GUID dd-ROSA ImageWriter og anden lignende software kan ikke klare opgaven, fordi det udover at kopiere de forskudte metadata til den bootbare USB-flash, også kræver, at man skal lave en copy/paste uden for filsystemet på USB-drev. Kort sagt, korrekt kopiere MBR/sporet til drevet. Fra GNU/Linux OS kan du oprette en bootbar USB-flash ved hjælp af værktøjet "dd", ved at se på denne tabel.

Oprettelse af en rescue disk i Windows-miljøet – er anderledes. VeraCrypts udvikler har ikke inkluderet en løsning til denne opgave i den officielle dokumentationen om "rescue disk", men har foreslået en løsning på en anden måde: han har offentliggjort ekstra software til oprettelse af "usb rescue disk" gratis tilgængeligt på sit VeraCrypt forum. Arkivet til denne software til Windows er "oprettelse af usb veracrypt rescue disk". Efter gemning af rescue disk.iso begynder processen med blokbaseret systemkryptering af den aktive partition. Under krypteringen stopper OS ikke, og genstart af pc'en er ikke nødvendig. Når krypteringsprocessen er afsluttet, bliver den aktive partition fuldstændig krypteret, og du kan bruge den. Hvis VeraCrypt bootloader ikke vises ved opstart af pc'en, og header recovery operationen ikke hjælper, så tjek "boot" flaget, det skal være indstillet på den partition, hvor Windows er til stede. (uafhængigt af krypteringen og andre OS, se tabel nr. 1).
Dette afslutter beskrivelsen af blokbaseret systemkryptering med Windows OS.

[B] LUKS. Kryptering af GNU/Linux (~Debian) installeret OS. Algoritme og trin

For encrypting an installed Debian/derived distribution, it is necessary to map the prepared partition to a virtual block device, transfer it to the mapped disk GNU/Linux, and install/configure GRUB2. If you do not have a bare server and value your time, you should utilize a GUI, as most terminal commands described below are assumed to be entered in 'Chuck Norris mode.'

B1. Booting the PC from a live USB GNU/Linux

Conduct a crypto test on hardware performance

lscpu && cryptsetup benchmark

If you are a happy owner of a powerful machine with hardware AES support, the numbers will resemble the right side of the terminal; if you are fortunate but have ancient hardware, they will resemble the left side.

B2. Disk partitioning, mounting/formatting the filesystem of the logical HDD to Ext4 (Gparted)

B2.1. Creating an encrypted header for partition sda7I will describe partition names here and below according to my partition table posted above. Based on your disk layout, you should substitute your partition names.

Mapping the encryption of the logical disk (/dev/sda7 > /dev/mapper/sda7_crypt).
#Простое создание «LUKS-AES-XTS раздела»

cryptsetup -v -y luksFormat /dev/sda7

Options:

* luksFormat - initializing the LUKS header;
* -y - passphrase (not key/file);
* -v - verbosity (output information in the terminal);
* /dev/sda7 - your logical disk from the extended partition (the destination for moving/encrypting GNU/Linux).

By default, the encryption algorithm <LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom> (depends on the version of cryptsetup).

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

In the absence of AES support on the CPU, the best choice will be to create an extended 'LUKS-Twofish-XTS partition.'

B2.2. Extended creation of 'LUKS-Twofish-XTS partition'

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

Options:
* luksFormat - initializing the LUKS header;
* /dev/sda7 your future encrypted logical disk;
* -v verbosity;
* -y passphrase;
* -c choice of data encryption algorithm;
* -s size of the encryption key;
* -h hashing algorithm/crypto function, used by RNG (--use-urandom) til generering af en unik krypterings/dekrypteringsnøgle til logisk diskoverskrift, sekundær nøgleoverskrift (XTS); unik masternøgle, der opbevares i den krypterede diskoverskrift, sekundær XTS-nøgle, alle disse metadata og undersystemet til kryptering, der ved hjælp af masternøglen og den sekundære XTS-nøgle krypterer/dekrypterer alle data på partitionen (undtagen partitionsoverskriften) opbevares i ~3 MB på den valgte harddiskpartition.
* -i iterationer i millisekunder, i stedet for "antal" (tidsforsinkelse ved behandling af adgangskoden, påvirker OS-opstart og krypteringsstyrken af nøglerne). For at opretholde balancen i krypteringsstyrken ved en simpel adgangskode som "russian" skal værdien - (i) øges, ved en kompleks adgangskode som "?8dƱob/øfh" kan værdien reduceres.
* —use-urandom tilfældig talgenerator, genererer nøgler og salt.

Efter matchning af partitionen sda7 > sda7_crypt (operationen er hurtig, da der oprettes en krypteret overskrift med metadata ~3 MB, og det er alt), skal filsystemet sda7_crypt formateres og monteres.

B2.3. Matching

cryptsetup open /dev/sda7 sda7_crypt
#udførelsen af denne kommando anmoder om indtastning af den hemmelige adgangskode.

indstillinger:
* open - matche partitionen "med navnet";
* /dev/sda7 - logisk disk;
* sda7_crypt - matchingsnavn, der bruges til at montere den krypterede partition eller til at initialisere den ved OS-opstart.

B2.4. Formatering af filsystemet sda7_crypt til ext4. Montering af disken i OS(Bemærk: i Gparted kan man ikke længere arbejde med den krypterede partition)

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

indstillinger:
* -v - verbalisering;
* -L - disklabel (som vises i stifinder blandt andre diske).

Dernæst skal det virtuelle-krypterede blokdevice /dev/sda7_crypt monteres i systemet

mount /dev/mapper/sda7_crypt /mnt

Arbejdet med filer i mappen /mnt vil automatisk kryptere/dekryptere dataene i sda7.

Det er nemmere at matche og montere partitionen i stifinder (nautilus/caja GUI), partitionen vil allerede være på listen over valgte diske, der skal kun indtastes adgangskoden for at åbne/dekryptere disken. Det matchede navn vil blive valgt automatisk og ikke "sda7_crypt", men noget som /dev/mapper/Luks-xx-xx…

B2.5. Backup af diskoverskriften (metadata ~3MB)En af de vigtigste vigtige operationer, der skal udføres uden forsinkelse — backup af headeren "sda7_crypt". Hvis headeren overskrives/ødelægges (f.eks. ved installation af GRUB2 på partitionen sda7 osv.), vil de krypterede data gå tabt for altid uden mulighed for at gendanne dem, fordi det ikke vil være muligt at generere de samme nøgler igen, da nøglerne skabes unikt.

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

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

indstillinger:
* luksHeaderBackup —header-backup-file backup-kommando;
* luksHeaderRestore —header-backup-file gendannelseskommando;
* ~/Backup_DebSHIFR — backupfil;
* /dev/sda7 - partitionen, hvis krypterede diskheaderbackup skal gemmes.
I dette trin <oprettelse og redigering af krypteret partition> er afsluttet.

B3. Overførsel af GNU/Linux OS (sda4) til krypteret partition (sda7)

Opret mappen /mnt2 (Bemærk — vi arbejder stadig med live USB, på punktet /mnt er sda7_crypt monteret), og monter vores GNU/Linux i /mnt2, som skal krypteres.

mkdir /mnt2
mount /dev/sda4 /mnt2

Udfør korrekt overførsel af OS ved hjælp af Rsync-software

rsync -avlxhHX --progress /mnt2/ /mnt

Rsync-indstillingerne er beskrevet i punkt E1.

Derefter, it's necessary foretage fragmentering af den logiske diskpartition

e4defrag -c /mnt/ # efter kontrollen viser e4defrag, at graden af fragmentering af partitionen ~"0", dette er en misforståelse, som kan koste dig betydelig tab af ydeevne!
e4defrag /mnt/ # udfør fragmentering af den krypterede GNU/Linux

Tag det som en regel: at udføre e4defrag på krypteret GNU/Linux tid til anden, hvis du har HDD.
Overførslen og synkroniseringen [GNU/Linux > GNU/Linux-krypteret] er afsluttet på dette trin.

V4. Konfiguration af GNU/Linux på den krypterede partition sda7

Efter den vellykkede overførsel af OS /dev/sda4 > /dev/sda7 skal du logge ind på GNU/Linux på den krypterede partition og udføre yderligere konfiguration (uden at genstarte PC'en) i forhold til det krypterede system. Det vil sige at være i live USB, men at udføre kommandoer "relateret til roden af det krypterede OS". At simulere en sådan situation vil være "chroot". For hurtigt at få information om, hvilket OS du arbejder på nu (om det er krypteret eller ej, da dataene i sda4 og sda7 er synkroniseret), desynkroniser OS'er. Opret i de rodmapper (sda4/sda7_crypt) tomme markørfiler, f.eks. /mnt/krypteretOS og /mnt2/afkrypteretOS. Hurtig kontrol af, hvilket OS du er på (inklusive for fremtiden):

ls /<Tab-Tab>

B4.1. "Simulation af login til det krypterede OS"

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

B4.2. Kontrol, at arbejdet udføres i forhold til det krypterede system

ls /mnt 
#og vi ser filen "/krypteretOS"

history
#i terminalens output skal der vises en historik af kommandoerne fra den aktive OS.

B4.3. Oprettelse/konfiguration af krypteret swap, redigering af crypttab/fstabDa swap-filen formateres ved hver opstart af OS, giver det ikke mening at oprette og tilknytte swap til det logiske drev nu og indtaste kommandoer som i p.B2.2. For Swap vil der automatisk blive genereret nye midlertidige krypteringsnøgler ved hver opstart. Livscyklussen for swap-nøglerne: afmontering/deaktivering af swap-partitionen (+rensning af RAM); eller genstart af OS. Konfiguration af swap, vi åbner filen, der svarer til konfigurationen af blok-krypterede enheder (analog til fstab-filen, men der svarer til kryptografi).

nano /etc/crypttab 

redigerer

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

Muligheder
* swap -det tilknyttede navn ved kryptering af /dev/mapper/swap.
* /dev/sda8 -brug din logiske partition til swap.
* /dev/urandom -generator af tilfældige krypteringsnøgler for swap (ved hver ny opstart af OS — skabes der nye nøgler). Generatoren /dev/urandom er mindre tilfældig end /dev/random, da /dev/random anvendes under farlige paranoide forhold. Ved opstart af OS bremser /dev/random opstarten med et par ± minutter (se systemd-analyze).
* swap,cipher=twofish-xts-plain64,size=512,hash=sha512: -partitionen ved, at den er swap og formateres "svarende"; krypteringsalgoritmen.

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

redigerer

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

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

Alternativ krypteret swap
Hvis du af en eller anden grund ikke ønsker at afsætte en hel partition til swap-filen, kan du tage en alternativ og bedre vej: oprettelse af en swap-fil i en fil på den krypterede partition med OS.

fallocate -l 3G /swap #oprettelse af fil med størrelse 3GB (næsten øjeblikkelig operation)
chmod 600 /swap #indstilling af rettigheder
mkswap /swap #opretter swap fra fil
swapon /swap #aktiverer vores swap
free -m #tjekker, om swap-filen er aktiveret og fungerer
printf "/swap none swap sw 0 0" >> /etc/fstab #hvis nødvendigt vil swap være permanent efter genstart

Konfigurationen af swap-partitionen er afsluttet.

B4.4. Konfiguration af krypteret GNU/Linux (redigering af filer crypttab/fstab)Fil /etc/crypttab, som nævnt ovenfor, beskriver de krypterede blok-enheder, der konfigureres under systemstart.

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

hvis du tilknyttede partition sda7>sda7_crypt som i p.B2.1

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

hvis du har matchet partition sda7>sda7_crypt som i punkt 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

hvis du har matchet partition sda7>sda7_crypt som i punkt B2.1 eller B2.2, men ikke ønsker at indtaste adgangskoden for at låse op og starte OS, så kan du i stedet indsætte en hemmelig nøgle/random fil

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

Description
* none - angiver, at der ved opstart af OS skal indtastes en hemmelig adgangsfrase for at låse rodpartitionen op.
* UUID - er identifikatoren for partitionen. For at finde din identifikator skriver du i terminalen (en påmindelse, om at du hele denne tid og fremad, arbejder i terminalen i chroot-miljøet, og ikke i en anden live USB-terminal).

fdisk -l #kontrol af alle partitioner
blkid #det skal se nogenlunde sådan ud 

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

denne linje ses ved en blkid-anmodning fra terminalen live USB, når sda7_crypt er monteret).
UUID'en tager du direkte fra din sdaX (ikke sdaX_crypt!, UUID sdaX_crypt vil automatisk forsvinde under genereringen af config grub.cfg).
* cipher=twofish-xts-plain64,size=512,hash=sha512 - luks kryptering i udvidet tilstand.
* /etc/skey - hemmelig nøglefil, der indsættes automatisk for at låse op for opstart af OS (i stedet for at indtaste en 3. adgangskode). Filen kan være hvilken som helst op til 8 MB, men data vil blive læst <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 

Det vil se nogenlunde sådan ud:

(gør det selv, og du vil se).

cryptsetup luksKillSlot /dev/sda7 7 #fjernelse af nøgle/adgangskode fra 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

mulighed
* /dev/mapper/sda7_crypt - navnet på matchningen sda7>sda7_crypt, som er angivet i filen /etc/crypttab.
Konfigurationen af crypttab/fstab er afsluttet.

B4.5. Redigering af konfigurationsfiler. NøglepunktB4.5.1. Redigering af konfigurationen /etc/initramfs-tools/conf.d/resume

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

og kommenter (hvis det eksisterer) «#» linjen «resume». Filen skal være helt tom.

B4.5.2. Redigering af konfigurationen /etc/initramfs-tools/conf.d/cryptsetup

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

det skal svare til

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

B4.5.3. Redigering af konfigurationen /etc/default/grub (netop denne konfiguration ansvarer for at generere grub.cfg, når du arbejder med krypteret /boot)

nano /etc/default/grub

tilføjer linjen «GRUB_ENABLE_CRYPTODISK=y»
værdien 'y', grub-mkconfig og grub-install vil kontrollere tilstedeværelsen af krypterede drev og generere ekstra kommandoer, der kræves for adgang under opstart (insmod-ene ).
det skal være noget lignende

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. Redigering af konfigurationen /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

kontroller, at linjen er kommenteret .
I fremtiden (og selv nu har denne parameter ingen betydning, men nogle gange forhindrer den opdatering af initrd.img-billedet).

B4.5.5. Redigering af konfigurationen /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

tilføj

KEYFILE_PATTERN="/etc/skey"
UMASK=0077

Dette pakker den hemmelige nøgle "skey" ind i initrd.img, nøglen er nødvendig for at låse rodved op ved opstart af OS (hvis du ikke ønsker at indtaste adgangskoden igen, vil den automatiske nøgle "skey" blive anvendt).

B4.6. Opdatering /boot/initrd.img [version]For at pakke den hemmelige nøgle ind i initrd.img og anvende rettelserne fra cryptsetup, opdaterer vi billedet

update-initramfs -u -k all

ved opdatering af initrd.img (som det siges "Måske, men det er ikke sikkert") vil der komme advarsler relateret til cryptsetup, eller for eksempel en notifikation om tab af Nvidia-moduler — dette er normalt. Efter opdateringen af filen, tjek at den faktisk er blevet opdateret, se efter tid (i forhold til chroot-miljøet./boot/initrd.img). Opmærksomhed! før [update-initramfs -u -k all] skal du sikre dig, at cryptsetup open /dev/sda7 sda7_crypt — dette navn skal være, som det figurerer i /etc/crypttab, ellers vil der være en busybox-fejl efter genstart.
På dette trin er konfigurationen af konfigurationsfilerne afsluttet.

[C] Installation og konfiguration af GRUB2/Beskyttelse

C1. Formater den dedikerede partition til bootloaderen, hvis nødvendigt (partitionen skal være mindst 20 MB)

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

C2. Montering af /dev/sda6 i /mntSå vi arbejder i chroot, så der vil ikke være en mappe /mnt2 i roden, og mappen /mnt vil være tom.
monterer GRUB2-partitionen

mount /dev/sda6 /mnt

Hvis du har en ældre version af GRUB2, i mappen /mnt/boot/grub/i-386-pc (en anden platform kan være mulig, for eksempel ikke "i386-pc") mangler kryptomoduler (kort sagt, i mappen skal der være moduler, herunder disse .mod: cryptodisk; luks; gcry_twofish; gcry_sha512; signature_test.mod), i så fald skal GRUB2 opdateres.

apt-get update
apt-get install grub2 

Vigtigt! Under opdateringen af GRUB2-pakken fra repository, ved spørgsmålet "om valg" i hvilken placering bootloaderen skal installeres – skal installationen afvises (årsagen — forsøg på at installere GRUB2 — i "MBR" eller på live usb). Ellers vil du skade VeraCrypt-headeren/bootloaderen. Efter opdatering af GRUB2-pakkerne, og afvisning af installationen, skal bootloaderen installeres manuelt på den logiske disk, ikke i "MBR". Hvis din version af GRUB2 i repository er forældet, prøv at opdatere det fra den officielle hjemmeside – har ikke tjekket (arbejdede med friske GRUB 2.02 ~BetaX-loadere).

C3. Installation af GRUB2 i den udvidede partition [sda6]Du skal have monteret partitionen [p.C.2]

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

muligheder
* —force - installation af loaderen, og springer over alle advarsler, som næsten altid eksisterer og blokerer installationen (obligatorisk flag).
* —root-directory - opsætning af mappen <boot\/grub> til roden af sda6.
* \/dev\/sda6 -din sdaX partition (glem ikke < mellemrum > mellem \/mnt \/dev\/sda6).

C4. Oprettelse af konfigurationsfilen [grub.cfg]Glem kommandoen «update-grub2», og brug den fuldgyldige kommando til at generere konfigurationsfilen

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

efter afslutningen af genereringen/opdateringen af grub.cfg, skal der være linjer(i) i terminalen med fundne OS'er på disken («grub-mkconfig» vil måske finde og tilføje OS'er fra live usb, hvis du har en multiboot USB med Windows 10 og adskillige live-distributioner — det er normalt). Hvis terminalen er «tom», er filen «grub.cfg» ikke blevet genereret, så er dette det tilfældet, hvor der er fejl i GRUB (og sandsynligvis loaderen fra testgrenen af repositoriet), geninstaller GRUB2 fra pålidelige kilder.
Installation af «simpel konfiguration» og opsætning af GRUB2 er afsluttet.

C5. Proof-test af den krypterede OS GNU\/LinuxKorrekt afslut den kryptiske mission. Forlad forsigtigt den krypterede GNU\/Linux (udgang fra chroot-miljøet).

umount -a #afmontering af alle monterede partitioner i den krypterede GNU\/Linux
Ctrl+d #udgang fra chroot-miljøet
umount \/mnt\/dev
umount \/mnt\/proc
umount \/mnt\/sys
umount -a #afmontering af alle monterede partitioner på live usb
reboot

Efter genstart af PC'en skal VeraCrypt-loaderen starte op.


*Indtastning af adgangskoden for den aktive partition – dette vil starte op af Windows OS.
*Tryk på «Esc»-tasten vil overføre kontrol til GRUB2, når du vælger den krypterede GNU\/Linux – vil kræve adgangskode (sda7_crypt) for at låse op for \/boot\/initrd.img (hvis grub2 skriver uuid «ikke fundet» — så er det et problem med grub2-loaderen, det bør geninstalleres, f.eks. fra testgrenen/stabil og pd).


*Afhængigt af hvordan du har konfigureret systemet (se p.B4.4/4.5) efter korrekt indtastning af adgangskoden for at låse billedet \/boot\/initrd.img, vil der være behov for en adgangskode til at starte kernen/ruten af OS, eller den hemmelige nøgle «skey» vil automatisk blive anvendt, så man slipper for gentagen indtastning af adgangskoden.

(skærm «automatiske indtastning af hemmelig nøgle»).

*Derefter vil den velkendte GNU/Linux opstart med brugerautentificering finde sted.


*Efter brugerautentificering og indlogning i OS, skal /boot/initrd.img opdateres igen. (se V4.6).

update-initramfs -u -k all

Og i tilfælde af overflødige linjer i GRUB2-menuen (fra OS med live USB) fjerne dem

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

Kort opsummering om systemkryptering i GNU/Linux:

• GNU/Linux er fuldt ud krypteret, inklusive /boot/kernel og initrd;
• den hemmelige nøgle er pakket i initrd.img;
• den nuværende autentificeringsskema (indtastning af adgangskode for at låse initrd; adgangskode/nøgle til OS-opstart; adgangskode til Linux-brugerautentificering).

«Simpel GRUB2-konfiguration» for systemkryptering af blokpartitioner er afsluttet.

C6. Udvidet GRUB2-konfiguration. Beskyttelse af bootloader med digital signatur + beskyttelse gennem autentificeringGNU/Linux er fuldt ud krypteret, men bootloaderen kan ikke krypteres – denne betingelse er dikteret af BIOS. Af denne grund er kædekrypteret opstart med GRUB2 umuligt, men simpel kædekrypteret opstart er mulig/tilgængelig, når det gælder beskyttelse – [se P. F].
For «sårbar» GRUB2 har udviklerne implementeret en metode til beskyttelse af bootloaderen «med signatur/autentificering».

• Ved at beskytte bootloaderen «med sin egen digitale signatur» vil ekstern modifikation af filer eller forsøg på at indlæse yderligere moduler i denne bootloader føre til, at opstartsprocessen bliver blokeret.
• Ved at beskytte bootloaderen med autentificering vil der være behov for at indtaste superbrugerens login og adgangskode i GRUB2 for at vælge hvilken distribution der skal starte eller for at indtaste yderligere kommandoer i CLI.

C6.1. Beskyttelse af bootloaderen med autentificeringSørg for, at du arbejder i terminalen i det krypterede OS

ls / #find markørfilen

opret en superbrugeradgangskode til autentificering i GRUB2

grub-mkpasswd-pbkdf2 #indtast/ gentag superbrugerens adgangskode. 

Få adgangskodehashen. Noget der ligner dette

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

monter GRUB-partitionen

mount /dev/sda6 /mnt 

rediger konfiguration

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

kontroller filgranskningen, så der ikke er nogen indstillinger (» —unrestricted» «—user» i «grub.cfg»
tilføj til slut (før linjen ### END /etc/grub.d/41_custom ###)
«set superusers=»root»
password_pbkdf2 root hash».

Det skal være cirka sådan

# 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 ]; så
source $prefix/custom.cfg;
fi
set superusers=«root»
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
### END /etc/grub.d/41_custom ###
#

Hvis du ofte bruger kommandoen «grub-mkconfig -o /mnt/boot/grub/grub.cfg» og ikke ønsker at foretage ændringer i grub.cfg hver gang, så indtast de tidligere nævnte linjer (brugernavn/adgangskode) i den brugerspecifikke GRUB-script nederst

nano /etc/grub.d/41_custom 

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

Når du genererer konfigurationsfilen «grub-mkconfig -o /mnt/boot/grub/grub.cfg», vil linjerne ansvarlige for autentifikation blive tilføjet automatisk i grub.cfg.
På dette skridt er autentifikationen af GRUB2 konfigureret.

C6.2. Beskyttelse af bootloaderen med digital signaturDet antages, at du allerede har din personlige PGP-krypteringsnøgle (eller opret en sådan nøgle). Systemet skal have installeret kryptografisk software: gnuPG; kleopatra/GPA; Seahorse. Kryptoprogrammet vil i høj grad lette dine opgaver i sådanne sager. Seahorse – stabil version af pakken 3.14.0 (versioner over, f.eks. V3.20 – er begrænsede og har betydelige fejl).

PGP-nøglen skal genereres/køres/tilføjes kun i su-miljøet!

Generer en personlig krypteringsnøgle

gpg --gen-key

Eksportér din nøgle

gpg --export -o ~/perskey

Monter det logiske drev i OS, hvis det ikke allerede er monteret

mount /dev/sda6 /mnt #sda6 – partition for GRUB2

rens partitionen for GRUB2

rm -rf /mnt/

Installer GRUB2 på sda6, idet du placerer din personlige nøgle i hovedbilledet af GRUB «core.img»

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

muligheder
* —force -installation af bootloader, omgå alle advarsler, der altid er til stede (obligatorisk flag).
* —modules=«gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa» -instrukserer GRUB2 til at præ-laste de nødvendige moduler ved opstart af PC.
* -k ~/perskey -sti til «PGP-nøglen» (efter pakning af nøglen i billedet, kan den slettes).
* —root-directory -sætter boot-kataloget i roden af sda6
/dev/sda6 -ваш sdaХ раздел.

Genererer/opdaterer grub.cfg

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

Tilføj linjen «trust /boot/grub/perskey» til slutningen af filen «grub.cfg» (tvangsmæssigt bruge pgp-nøglen.) Da vi installerede GRUB2 med et sæt moduler, herunder signaturmodulet «signature_test.mod», slipper vi for at tilføje kommandoer som «set check_signatures=enforce» til konfigurationen.

Det skal se cirka sådan ud (slutlinjer i filen 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 ]; så
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 ###
#

Stien til «/boot/grub/perskey» behøver ikke at pege på et specifikt diskpartition, som hd0,6; for bootloaderen er «roden» standardstien til partitionen, hvor GRUB2 er installeret. (se set rot=..).

Vi underskriver GRUB2 (alle filer i alle mapper /GRUB) med din nøgle «perskey».
En enkel løsning til at underskrive (til filhåndterer nautilus/caja): installere udvidelsen «seahorse» fra arkivet til filhåndtereren. Nøglen skal tilføjes i su-miljøet.
Åbn filhåndtereren med sudo «/mnt/boot» – højreklik – underskriv. På skærmbilledet ser det sådan ud

Selve nøglefilen «/mnt/boot/grub/perskey» (kopier til grub-mappen) skal også være underskrevet med sin egen signatur. Kontroller, at der er dukket signaturfiler [*.sig] op i mappen/undermapperne.
Ved den beskrevne metode underskriver vi «/boot» (vores kernel, initrd). Hvis din tid er værdifuld, vil denne metode spare dig for at skrive et bash-script til at underskrive «mange filer».

For at fjerne alle underskrifter fra bootloaderen (hvis noget gik galt)

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

For ikke at skulle underskrive bootloaderen efter systemopdatering, fryser vi alle opdateringspakker, der relaterer til GRUB2.

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

På dette trin er <beskyttelse af bootloader med digital signatur> udvidet opsætning af GRUB2 afsluttet.

C6.3. Bevis-test af GRUB2 bootloader, beskyttet med digital signatur og autentificeringGRUB2. Ved valg af en hvilken som helst distribution af GNU/Linux eller adgang til CLI (kommandolinjen) kræves superbrugerautorisering. Efter indtastning af korrekt login/adgangskode kræves adgangskoden fra initrd.

Skærmbillede, succesfuld autentificering af GRUB2-superbruger.

Hvis nogen af GRUB2-filerne forfalskes/ændres i grub.cfg, eller hvis en fil/signatur fjernes, eller hvis en ondsindet modul.mod indlæses, vil der komme en tilsvarende advarsel. Indlæsningen af GRUB2 vil blive stoppet.

Skærmbillede, forsøg på at interferere med GRUB2 «udefra».

Ved «normal» indlæsning «uden indblanding» vil systemstatuskoden være «0». Derfor er det uklart, om beskyttelsen fungerer eller ej. (det vil sige «med bootloaderens signaturbeskyttelse eller uden» er status den samme «0» ved normal indlæsning – det er dårligt).

Hvordan tjekker man signaturbeskyttelsen?

En besværlig kontrolmetode: forfalske/fjerne den brugte GRUB2-modul, for eksempel, fjerne signaturen luks.mod.sig og få en fejl.

Den korrekte metode: gå ind i CLI fra bootloaderen og indtast kommandoen

trust_list

I svaret skal der være et fingeraftryk «perskey», hvis status er «0», betyder det, at beskyttelse med signatur ikke fungerer, tjek venligst p.C6.2.
På dette trin er den udvidede indstilling «GRUB2-beskyttelse med digital signatur og autentificering» færdig.

C7 Alternativ metode til beskyttelse af GRUB2-bootloader ved hjælp af hashingDen beskrevne metode «Beskyttelse af CPU-bootloader / Autentificering» er klassisk. På grund af GRUB2's utilstrækkelighed kan den i paranoide forhold udsættes for reelle angreb, som jeg vil præsentere nedenfor i p.[F]. Desuden skal bootloaderen gen-signeres efter opdatering af OS/kerne.

Beskyttelse af GRUB2-bootloader ved hjælp af hashing

Fordele i forhold til klassikeren:

• Højere pålidelighed (hashing / verifikation udføres kun med krypteret lokal ressource. Hele den dedikerede partition under GRUB2 kontrolleres for ændringer, og alt andet er krypteret, mens det i den klassiske schema med beskyttelse af CPU-bootloader / autentificering kun filerne kontrolleres, men ikke det frie rum, hvor «noget ondt» kan skrives ind).
• Krypteret logføring (en læsbar personlig krypteret log tilføjes til schemaet).
• Hastighed (beskyttelse / verifikation af hele partitionen dedikeret til GRUB2 sker stort set øjeblikkeligt).
• Automatisering af alle kryptografiske processer.

Ulemper i forhold til klassikeren.

• Falsk signatur (teoretisk set kan der findes en bestemt kollision af hash-funktionen).
• Forhøjet kompleksitetsniveau (sammenlignet med klassikeren kræver det lidt mere færdigheder inden for GNU/Linux OS).

Hvordan fungerer ideen med GRUB2-hashing / partitionen

Partitionen GRUB2 «signeres», når OS indlæses, sker der en kontrol af uændret partitionen af bootloaderen med efterfølgende logføring i et sikkert miljø (krypteret). I tilfælde af kompromittering af bootloaderen eller dens partition startes en sådan log for indtrængen.

Ting.

Fire gange om dagen sker der en lignende kontrol, der ikke belaster systemressourcerne.
Med kommandoen «-$ check_GRUB» kan der foregå en øjeblikkelig kontrol på ethvert tidspunkt uden logføring, men med udskrift af information i CLI.
Med kommandoen «-$ sudo sign_GRUB» kan bootloaderen GRUB2 / partitionen blive øjeblikkeligt gen-signeret og dens opdaterede logføring. (nødvendigt efter opdatering af OS / boot), og livet fortsætter.

Implementeringen af hash-metoden til bootloaderen og dens partition

0) Vi signerer bootloaderen/partitionen GRUB efter at have monteret den i /media/username

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

1) Vi opretter et script uden filtypenavn i roden af det krypterede OS ~/podpis, og anvender de nødvendige 744 sikkerhedsrettigheder og beskyttelse mod 'idioter'.

Vi fylder indholdet ud

#!/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

Vi kører scriptet fra su, der vil udføre en hashkontrol af GRUB-partitionen og dens bootloader, gemme loggen.

Lad os oprette eller kopiere, for eksempel, en 'skadelig fil' [virus.mod] til GRUB2-partitionen og starte en midlertidig test/

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

I CLI skal vi se indtrængningen i vores -citadel-#Урезанный лог в CLI

Ons jan 2 11::41 MSK 2020
/media/username/GRUB/boot/grub/virus.mod: Flyttet fra /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 fejlede
   Indtastede filer undersøgt: 0
  Kendte filer, der forventes: 0
          Matcherede filer: 325
Delvist matchende filer: 0
            Flyttede filer: 1
        Nye filer fundet: 0
  Kendte filer ikke fundet: 0

#как видим появилось «Files moved: 1 и Audit failed» означает, что проверка не прошла.
På grund af de specifikke egenskaber ved den testede partition, i stedet for 'New files found' > 'Files moved'

2) Vi lægger gif'en her > ~/warning.gif, og tildeler rettigheder 744.

3) Vi konfigurerer fstab til automatisk montering af GRUB-partitionen ved opstart

-$ sudo nano /etc/fstab

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

4) Vi udfører logrotation

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

/var/log/podpis.txt {
dagligt
rotér 50
størrelse 5M
dateext
komprimer
forsink komprimer
olddir /var/log/old
}

/var/log/vtorjenie.txt {
månedligt
rotér 5
størrelse 5M
dateext
olddir /var/log/old
}

5) Vi tilføjer en opgave til cron

-$ sudo crontab -e

reboot '/podpis'
0 * /6 * * * '/podpis

6) Vi opretter permanente aliaser

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

Efter opdatering af OS -$ apt-get upgrade vi underskriver vores GRUB-partition igen
-$ signature_GRUB
På dette trin er beskyttelse ved hash af GRUB-partitionen afsluttet.

[D] Rensning — ødelæggelse af ukrypterede data

Fjern dine personlige filer så grundigt, at 'selv Gud ikke kan læse dem', ifølge repræsentanten fra South Carolina, Trey Gowdy.

Som sædvanligt er der forskellige 'myter og legenderom datarekonstruktion efter deres sletning fra harddisken. Hvis du tror på cybertrylleri, eller er medlem af Dr. web-fællesskabet og aldrig har prøvet datarekonstruktion efter deres sletning/overskrivning (for eksempel datarekonstruktion med R-studio), så vil den foreslåede metode næppe passe til dig, brug det, der er nærmere for dig.

Efter den vellykkede overførsel af GNU/Linux til en krypteret partition, skal den gamle kopi slettes uden mulighed for at gendanne data. En universel metode til rensning: software til Windows/Linux, gratis GUI-software. BleachBit.
Hurtigt formaterer partitionen, hvor dataene skal destrueres (ved hjælp af Gparted), starter BleachBit, vælger "Rensning af ledig plads" – vælg partitionen (dit sdaX med den tidligere kopi af GNU/Linux), processen til rensning vil starte. BleachBit – sletter disken i ét forsøg – det er præcis, hvad "vi har brug for", men! Dette virker kun i teorien, hvis du har formateret disken og renset med BB v2.0.

Bemærk! BB sletter disken, men efterlader metadata, filnavne bevares ved sletning af data (Ccleaner – efterlader ikke metadata).

Og myten om muligheden for at gendanne data er ikke helt en myte.Bleachbit V2.0-2 var en ustabil pakke til Debian OS (og enhver anden lignende software: sfill; wipe-Nautilus - er også blevet bemærket i denne skumle handel) havde faktisk en kritisk fejl: funktionen "rensning af ledig plads" fungerer ikke korrekt på HDD/USB-nøgler (ntfs/ext4). Denne type software ved rensning af ledig plads overskriver ikke hele disken, som mange brugere tror. Og nogle (mange) slettede data fra OS/software betragter disse data som ikke-slettede/brugerdata og springer disse filer over ved rensning af "RLP". Problemet er, at efter en sådan langvarig rensning af disken "slettede filer" kan gendannes selv efter 3+ gennemgange af sletning af disken.
På GNU/Linux fungerer Bleachbit pålideligt med funktionerne til definitiv sletning af filer og mapper, men ikke rensning af ledig plads. Til sammenligning fungerer funktionen "RLP for ntfs" i CCleaner på Windows korrekt, og Gud vil virkelig ikke være i stand til at læse de slettede data. 2.0-2 Så for grundigt at slette

"kompromitterende" gamle ukrypterede data, er det nødvendigt at have direkte adgang til disse data fra Bleachbit , og dernæst bruge funktionen "definitiv sletning af filer/mappen".For at slette "slettede filer med standardværktøjer i OS" i Windows, brug CCleaner/BB med funktionen "RLP". I GNU/Linux skal du selv få erfaring med dette
(sletning af slettede filer) og du skal ikke stole på softwareversionen (hvis der ikke er bagdør, så er der en fejl)) Du skal erhverve dig erfaringen på egen hånd (sletning af data + selvstændig forsøg på at genoprette dem, og man skal ikke stole på softwareversionen (hvis der ikke er en back-up, så er der en fejl)), kun på den måde kan du forstå mekanismen bag dette problem og fuldstændigt blive af med de slettede data.

Bleachbit v3.0 er ikke blevet testet, det er muligt, at problemet allerede er rettet.
Bleachbit v2.0 fungerer pålideligt.

På dette trin er "diskrensningen" afsluttet.

[E] Universel backup af krypterede operativsystemer

Hver bruger har sin egen backupmetode, men krypterede data fra "System OS" kræver en lidt anden tilgang. Unified software, som eksempelvis "Clonezilla" og lignende software kan ikke arbejde direkte med krypterede data.

Opgavesætning for backup af krypterede blokenheder:

1. universelhed — den samme algoritme/software til backup for Windows/Linux;
2. mulighed for at arbejde i konsollen med enhver live usb GNU/Linux uden behov for at downloade ekstra software (men jeg anbefaler stadig GUI);
3. backup-sikkerhed — de gemte "billeder" skal være krypterede/adgangskodede;
4. størrelsen af de krypterede data skal svare til størrelsen af de faktiske kopierede data;
5. nem ekstraktion af de nødvendige filer fra backupen (uden krav om først at skulle dekryptere hele partitionen).

For eksempel backup/gendannelses via "dd" værktøjet

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

Overholder næsten alle punkter i opgaveformuleringen, men punkt 4 er kritisabel, da det kopierer hele partitionen, inklusive det ledige rum — ikke interessant.

For eksempel backup af GNU/Linux via arkivværktøjet [tar» | gpg] er praktisk, men til Windows backup er det nødvendigt at finde en anden løsning — ikke interessant.

E1. Universel backup af Windows/Linux. Kombinationen rsync (Grsync) + VeraCrypt volumenAlgoritme til oprettelse af backup:

1. oprettelse af et krypteret container (volumen/fil) VeraCrypt til OS;
2. overførsel/synkronisering af OS ved hjælp af Rsync software til den krypterede container VeraCrypt;
3. ved behov kan VeraCrypt volumenet startes i www.

Oprettelse af en krypteret VeraCrypt container har sine særskaber:
oprettelse af en dynamisk volumen (dynamisk volumen kan kun oprettes i Windows, men kan bruges i GNU/Linux);
oprettelse af en almindelig volumen, men der er et krav om "paranoid natur" (ifølge udvikleren) – formatering af containeren.

Et dynamisk volumen oprettes næsten øjeblikkeligt i Windows OS, men ved kopiering af data fra GNU/Linux OS > VeraCrypt DT, reduceres den samlede ydeevne af backup-operationen væsentligt.

Et almindeligt Twofish volumen på 70 GB oprettes (lad os sige, på en PC med gennemsnitlig ydeevne) på HDD ~ på en halv time (genindskrivning af tidligere data i containeren i én gennemgang, som følger af sikkerhedskrav). Fra VeraCrypt Windows/Linux er funktionen til hurtig formatering af volumener ved oprettelse blevet fjernet, så oprettelse af en container er kun mulig ved 'genindskrivelse i én omgang', eller ved oprettelse af et lavtydende dynamisk volumen.

Lad os oprette et almindeligt VeraCrypt volumen (ikke dynamisk/ntfs), der bør ikke opstå nogen problemer.

Vi konfigurerer/opretter/åbner containeren i VeraCrypt GUI > GNU/Linux live usb (volumenet vil automatisk blive monteret i /media/veracrypt2, Windows OS volumenet monteres i /media/veracrypt1). Vi opretter en krypteret backup af Windows OS ved hjælp af GUI rsync (grsync), ved at sætte flueben.

Vent på, at processen afsluttes. Når backup'en er færdig, vil vi have én krypteret fil.

Opret også en backup af GNU/Linux OS ved at fjerne fluebenet i GUI rsync 'kompatibilitet med Windows'.

Bemærk! Opret ikke en Veracrypt-container til 'backup GNU/Linux' i filsystemet procfs. Hvis du laver en backup i en ntfs-container, mister du alle rettigheder/grupper til dine data ved gendannelse af en sådan kopi.

Alle operationer kan udføres i terminalen. De grundlæggende muligheder for rsync:
* -g -bevar grupper;
* -P —progress — status for arbejdstid på filen;
* -H -kopier hardlinks som de er;
* -a -arkivtilstand (flere flag rlptgoD);
* -v -udfyldelse.

Hvis du ønsker at montere 'Windows VeraCrypt volumen' via konsol i cryptsetup-software, kan du oprette et 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

Nu, når du skriver 'veramount pictures', vil du blive bedt om at indtaste adgangskoden, og det krypterede systemvolume fra Windows vil blive undermontret.

At matche/montiere systemvolumenet VeraCrypt i cryptsetup kommando

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

At matche/montiere partition/containeren VeraCrypt i cryptsetup kommando

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

I stedet for et alias vil vi tilføje (script i opstart) en systempartition med Windows OS og en logisk krypteret NTFS-disk i opstart af GNU/Linux

Vi opretter et script og gemmer det i ~/VeraOpen.sh

printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sda3 Windows_crypt && mount /dev/mapper/Windows_crypt /media/Winda7 #dekoder passwordet fra base64 (bob) og sender det til anmodning om password ved montering af systempartitionen med Windows OS.
printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --type tcrypt /dev/sda1 ntfscrypt && mount /dev/mapper/ntfscrypt /media/ContainerNTFS #på samme måde, men monterer den logiske NTFS-disk.

Vi tildeler de "korrekte" rettigheder:

sudo chmod 100 /VeraOpen.sh

Vi opretter to identiske filer (samme navn!) i /etc/rc.local og ~/etc/init.d/rc.local
Vi fylder filerne

#!/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

Vi tildeler de "korrekte" rettigheder:

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

Det er det, nu skal vi ikke indtaste passwords for at montere krypterede NTFS-diske, diske monteres automatisk ved opstart af GNU/Linux.

En note kort om det, der er beskrevet ovenfor i punkt E1 trin for trin (men nu for OS GNU/Linux)
1) Opret en partition i fs ext4 > 4gb (til filen) Linux i Veracrypt [Krypteringsboks].
2) Genstart til live USB.
3) ~$ cryptsetup open /dev/sda7 Lunux #tilknytning af den krypterede partition.
4) ~$ mount /dev/mapper/Linux /mnt #montering af den krypterede partition i /mnt.
5) ~$ mkdir mnt2 #opretter en mappe til fremtidig backup.
6) ~$ cryptsetup open --veracrypt --type tcrypt ~/Krypteringsboks Krypteringsboks && mount /dev/mapper/Krypteringsboks /mnt2 #tilknytning af Veracrypt-partitionen med navnet "Krypteringsboks" og montering af krypteringsboksen i /mnt2.
7) ~$ rsync -avlxhHX --progress /mnt /mnt2/ #backup operation af den krypterede partition til den krypterede Veracrypt-partition.

(p/s/ Bemærk! Hvis du flytter krypteret GNU/Linux fra én arkitektur/maskine til en anden, for eksempel Intel > AMD (det vil sige, at du udvider en backup fra én krypteret partition til en anden krypteret partition Intel > AMD), glem ikke efter flytningen af det krypterede OS at redigere den hemmelige indsatte nøgle i stedet for passwordet, da den tidligere nøgle ~/etc/skey - ikke længere vil passe til en anden krypteret partition, og det er uønsket at oprette en ny nøgle med "cryptsetup luksAddKey" fra chroot - der kan opstå et glitch, bare i ~/etc/crypttab angiv i stedet for "~/etc/skey" midlertidigt "none", efter reboot og adgang til OS genskab din hemmelige indsatte nøgle igen).

Som IT-veteraner må vi ikke glemme at lave separate backups af overskrifterne for krypterede partitioner af Windows/Linux, ellers vil krypteringen vende sig mod dig selv.
På dette trin er backup af de krypterede OS afsluttet.

[F] Angreb på GRUB2-loaderen

DetaljerHvis du har beskyttet din loader med en digital signatur og/eller autentificering (se p.C6.), vil fysisk adgang ikke beskytte mod dette. Krypterede data vil stadig være utilgængelige, men omgåelse af beskyttelsen (nulstilling af den digitale signaturbeskyttelse) GRUB2 tillader en cyberkriminel at indsætte sin kode i loaderen uden at vække mistanke (medmindre brugeren manuelt overvåger tilstanden af loaderen, eller opdager sin egen robuste skriptkode til grub.cfg).

Angrebsalgoritme. Angriber

* Starter PC'en med live USB. Enhver ændring (af forbryderen) af filer vil udløse en notifikation til den reelle ejer af PC'en om indtrængen i loaderen. Men simpel geninstallation af GRUB2 med bevarelse af grub.cfg (og den efterfølgende mulighed for at redigere den) giver angriberen mulighed for at redigere alle filer (i dette tilfælde, når GRUB2 starter, vil der ikke ske en notifikation til den reelle bruger. Status forbliver den samme )
* Monterer den ukrypterede partition, gemmer " /mnt/boot/grub/grub.cfg".
* Geninstallerer loaderen (kaster "perskey" ud af core.img-billedet)

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

* Gendanner "grub.cfg" > " /mnt/boot/grub/grub.cfg", redigerer den om nødvendigt, for eksempel ved at tilføje sin egen modul "keylogger.mod" i mappen med loadermodulerne, i "grub.cfg" > linjen "insmod keylogger". Eller, hvis fjenden er snedig, efter geninstallationen af GRUB2 (alle signaturer forbliver på plads) indsamler han det primære billede af GRUB2 ved hjælp af "grub-mkimage med optionen (-s)." Optionen "-s" muliggør indlæsning af sin konfiguration inden indlæsningen af den primære "grub.cfg". Konfigurationen kan bestå af blot én linje: omdirigering til enhver "modern.cfg", blandet, for eksempel med ~400 filer (moduler+signaturer) i mappen " /boot/grub/i386-pc". Under dette kan gerningsmanden indføre vilkårlig kode og indlæse moduler uden at berøre " /boot/grub/grub.cfg", selvom brugeren har anvendt "hashsum" på filen og midlertidigt har vist den på skærmen.
Det er ikke nødvendigt for angriberen at bryde ind i superbrugerens GRUB2-login/ordbog, det skal blot kopiere linjerne (der svarer til autentificering) " /boot/grub/grub.cfg" til sin egen "modern.cfg".

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

Og for PC'ens ejer vil autentificeringen af superbrugeren GRUB2 stadig være gældende.

Kædeloading (loaderen loader en anden loader), som nævnt tidligere, giver ikke mening (den er beregnet til et andet formål). På grund af BIOS kan den krypterede bootloader ikke indlæses (ved kædemontering genstarter GRUB2 > den krypterede GRUB2, fejl!). Men hvis man stadig vil udnytte ideen fra kædemontering, kan man være sikker på, at det faktisk er den krypterede (ikke opgraderet) «grub.cfg» fra den krypterede partition. Og dette giver også en falsk følelse af sikkerhed, fordi alt, hvad der er angivet i den krypterede «grub.cfg» (indlæsning af moduler) kombineres med de moduler, der indlæses fra den ukrypterede GRUB2.

Hvis du vil kontrollere dette, kan du markere/kryptere endnu en partition sdaY, kopiere GRUB2 til den (operationen grub-install på den krypterede partition er umulig) og i «grub.cfg» (den ukrypterede konfig) ændre linjer som disse

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
}

linjer
* insmod - indlæsning af nødvendige moduler til arbejde med den krypterede disk;
* GRUBx2 - navnet på den viste linje i GRUB2 bootmenu;
* cryptomount -u 15c47d1c4bd34e5289df77bcf60ee838 - se fdisk -l (sda9);
* set root - indstilling af roden;
* normal /boot/grub/grub.cfg - eksekverbar konfigurationsfil på den krypterede partition.

Forsikringen om, at den krypterede «grub.cfg» faktisk indlæses — det er en positiv reaktion på indtastningen af adgangskoden/aflåse «sdaY» ved valg af linjen «GRUBx2» i GRUB-menuen.

Når man arbejder i CLI, for at undgå forvirring (og for at kontrollere, om miljøvariablen «set root» fungerede), skal du oprette tomme markeringsfiler, f.eks. i den krypterede partition «/shifr_grub», i den ukrypterede partition «/noshifr_grub». Kontrol i CLI

cat /Tab-Tab

Som nævnt tidligere, vil dette ikke forhindre indlæsning af ondsindede moduler, hvis sådanne moduler er på din PC. For eksempel en keylogger, der kan gemme tasteindgange i en fil og blande sig med andre filer i «~/i386», indtil en angriber downloader det med fysisk adgang til PC'en.

Den enkleste måde at kontrollere, at digital signaturbeskyttelsen aktivt fungerer (ikke nulstillet), og at ingen har trængt ind i bootloaderen, i CLI indtastes kommandoen

list_trusted

i svaret får vi et aftryk af vores «perskey», eller vi får ingenting, hvis vi er blevet angrebet (det er også nødvendigt at tjekke «set check_signatures=enforce»).
En væsentlig ulempe ved dette skridt er, at man skal indtaste kommandoerne manuelt. Hvis man tilføjer denne kommando til «grub.cfg» og beskytter konfigurationen med en digital signatur, så er den forudgående output af nøgleaftryk på skærmen alt for kort tidsmæssigt, så man kan risikere ikke at kunne se output, hvilket resulterer i en GRUB2-boot.
Man kan ikke klage over nogen specifikt: udvikleren angiver i sin dokumentationen p.18.2 officielt

«Vær opmærksom på, at selv med GRUB adgangskodebeskyttelse, kan GRUB ikke forhindre nogen med fysisk adgang til maskinen fra at ændre maskinens firmware (f.eks. Coreboot eller BIOS) konfiguration for at få maskinen til at starte fra en anden (angriber-kontrolleret) enhed. GRUB er i bedste fald kun et led i en sikker boot kæde».

GRUB2 er for meget overbelastet med funktioner, som kan give en falsk følelse af sikkerhed, og dets udvikling er allerede blevet mere funktionel end OS MS-DOS, og det er trods alt kun en boot-loader. Det er sjovt, at GRUB2 - «i morgen» kan blive et OS, mens de GNU/Linux virtuelle maskiner er til det.

En lille video om, hvordan jeg fjernede digital signaturbeskyttelsen i GRUB2 og anmeldte mit indtrængen til den rigtige bruger (jeg skræmte, og i stedet for det, der vises i videoen - kan man skrive ikke harmløs vilkårlig kode/.mod).

Konklusioner:

1) Blockbaseret systemkryptering til Windows er lettere at implementere, og beskyttelse med ét kodeord er mere bekvemt end beskyttelse med flere kodeord ved blokbaseret systemkryptering i GNU/Linux, retfærdigvis: det sidste er automatiseret.

2) Artiklen blev skrevet som relevant, detaljeret simpel vejledning til fuldkryptering af VeraCrypt/LUKS på én hjemme-maskine, som i dag er den bedste i det russiske internet (IMHO). Vejledningen har > 50k tegn, derfor blev nogle interessante kapitler ikke behandlet: om kryptografer, der forsvinder/holder sig i skyggen; om det, der ikke skrives meget i forskellige bøger om GNU/Linux om kryptografi; om artikel 51 i den russiske forfatning; om licensering/запрете af kryptografi i Rusland, om hvorfor det er nødvendigt at kryptere «rod/boot». Vejledningen er stort set uden at være omfangsrig, men detaljeret (som beskriver selv enkle trin), på sin side sparer det dig en masse tid, når du går i gang med «rigtig kryptering».

3) Fuldkryptering udførte jeg på Windows 7 64; GNU/Linux Parrot 4x; GNU/Debian 9.0/9.5.

4) Udførte et vellykket angreb på min GRUB2 bootloader.

5) Tutorialen er oprettet for at hjælpe alle paranoikere i CIS, hvor arbejde med kryptering er lovligt. Og især for dem, der ønsker at implementere fuld diskkryptering uden at slette deres konfigurerede systemer.

6) Jeg har revideret og opdateret min vejledning, som er relevant i 2020.

[G] Nyttig dokumentation

1. Brugervejledning til TrueCrypt (februar 2012 DK)
2. VeraCrypt-dokumentation
3. /usr/share/doc/cryptsetup(-run) [локальный ресурс] (officiel detaljeret dokumentation til opsætning af kryptering på GNU/Linux ved hjælp af cryptsetup)
4. Officiel FAQ for cryptsetup (kort dokumentation til opsætning af kryptering på GNU/Linux ved hjælp af cryptsetup)
5. LUKS-enhedskryptering (archlinux-dokumentation)
6. Detaljeret beskrivelse af cryptsetup-syntaks (manualside for arch)
7. Detaljeret beskrivelse af crypttab (manualside for arch)
8. Officiel dokumentation for GRUB2.

Tags: fuld diskkryptering, partitionskryptering, fuld diskkryptering Linux, fuld systemkryptering LUKS1.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.

Krypterer du?

• 17,1%Jeg krypterer alt, hvad der er muligt. Jeg er paranoid.

• 34,2%Jeg krypterer kun vigtige data.

• 14,6%Nogle gange krypterer jeg, nogle gange glemmer jeg.

• 34,2%Nej, jeg krypterer ikke, det er ubelejligt og kostbart.

82 brugere stemte. 22 brugere afholdt sig.

Kilde: habr.com