Teljes lemezes titkosítás Windows Linux telepített rendszerekhez. Titkosított többindítás.

A frissített, teljes lemez titkosítási útmutató az orosz hálón V0.2.

Kunyhó stratégia:

[A] blokk alapú rendszer titkosítás Windows 7 telepített rendszer;
[B] blokk alapú rendszer titkosítás GNU/Linux (Debian) telepített rendszer (beleértve a /boot-ot);
[C] GRUB2 beállítása, a betöltő védelme digitális aláírással/autentikációval/hash-al;
[D] törlés — titkosítatlan adatok megsemmisítése;
[E] univerzális biztonsági másolat titkosított operációs rendszerekről;
[F] támadás cél — GRUB2 betöltő;
[G] hasznos dokumentáció.

╭───Szoba séma 40# :
├──╼ Windows 7 telepített — teljes rendszer titkosítás, nem rejtett;
├──╼ GNU/Linux telepített (Debian és annak származékai) — teljes rendszer titkosítás, nem rejtett(/, beleértve a /boot-ot; swap);
├──╼ független betöltők: VeraCrypt betöltő telepítve MBR-be, GRUB2 betöltő telepítve a kiterjesztett szakaszba;
├──╼ operációs rendszer telepítése/újratelepítése nem szükséges;
└──╼ használt kriptográfiai szoftver: VeraCrypt; Cryptsetup; GnuPG; Seahorse; Hashdeep; GRUB2 – szabad/ingyenes.

A fent leírt séma részben megoldja a "külső boot flashre" problémát, lehetővé téve a titkosított Windows/Linux operációs rendszerek élvezetét és az adatok cseréjét "titkosított csatornán" egyik operációs rendszerről a másikra.

A PC indítási sorrendje (az egyik lehetőség):

• a gép bekapcsolása;
• a VeraCrypt betöltő betöltése (a helyes jelszó megadása folytatja a Windows 7 betöltést);
• az "Esc" billentyű megnyomása a GRUB2 betöltőt indítja;
• GRUB2 betöltő (disztribúció/ GNU/Linux/CLI kiválasztás), Szükség lesz a GRUB2 superuser autentikálására ;
• a sikeres autentikálás és a disztribúció kiválasztása után szükséges a titkosító kifejezés megadása a "/boot/initrd.img" feloldásához;
• a GRUB2-ben megadott hibátlan jelszavak után "kérni fogja" a jelszó megadását (a harmadik, BIOS jelszó vagy GNU/Linux felhasználói fiók jelszava – nem számít) a GNU/Linux operációs rendszer feloldásához és betöltéséhez, vagy automatikus titkos kulcs beillesztés (két jelszó + kulcs, vagy jelszó + kulcs);
• a GRUB2 konfigurációba való külső beavatkozás megfagyasztja a GNU/Linux betöltési folyamatát.

Fárasztó? Rendben, automatizáljuk a folyamatokat.

A merevlemez particionálása (MBR táblázat) A PC legfeljebb 4 fő partíciót, vagy 3 fő és egy kiterjesztettet, valamint egy nem particionált területet tartalmazhat. A kiterjesztett szakasz a főhöz képest lehet alpartíciókat is tartalmazni. (logikai lemezek=kiterjesztett partíció). Más szavakkal, a "kiterjesztett partíció" az HDD-n helyettesíti az LVM-et a jelenlegi feladathoz: a teljes rendszerszintű titkosításhoz. Ha a lemezed négy elsődleges partícióra van osztva, használnod kell az LVM-et, vagy átalakítani (formázással) a fő partíciót kiterjesztetté, vagy okosan kell kihasználni mind a négy partíciót és úgy hagyni mindent, hogy megkapd a kívánt eredményt. Még ha egy partíciód van is a lemezen, a Gparted segít felosztani az HDD-t (további partíciókra) adatvesztés nélkül, de mégis van egy kis ára ezeknek a műveleteknek.

A merevlemez partícionálási sémája, amely körül a cikk összes verbális megfogalmazása történik, az alábbi táblázatban van bemutatva.

Táblázat (1. sz.) 1 TB partíciói.

Valami hasonlónak kell lennie nálatok is.
sda1 — 1. számú fő partíció NTFS (titkosított);
sda2 — jelzett kiterjesztett partíció;
sda6 — logikai lemez (erre van telepítve a GRUB2 bootloader);
sda8 — swap (titkosított swap fájl/nem mindig);
sda9 — teszt logikai lemez;
sda5 — logikai lemez a kíváncsiak számára;
sda7 — GNU/Linux OS (áthelyezett OS titkosított logikai lemezre);
sda3 — 2. számú fő partíció Windows 7 OS-sel (titkosított);
sda4 — 3. számú fő partíció (itt volt a nem titkosított GNU/Linux, biztonsági másolatként használva/nem mindig).

[A] Windows 7 blokkszintű rendszer titkosítása

A1. VeraCrypt

Indítás Microsoft. Mint mindig, a cég fokozatosan vezeti be az új frissítést. Ezért a hír írása idején a Windows frissítési központban nem biztos, hogy elérhető a Chromium-alapú Edge böngésző letöltési ajánlata. A telepítés után a rendszer újraindítást kér., vagy tükörből sourceforge a VeraCrypt titkosító szoftver telepítőverziójából (a cikk megjelenésekor v1.24-Update3, a VeraCrypt hordozható verzió nem alkalmas rendszerszintű titkosításra). Ellenőrizd a letöltött szoftver ellenőrző összegét

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

és hasonlítsd össze az eredményt a VeraCrypt fejlesztőjének webhelyén közzétett összeggel.

Ha telepítve van a HashTab szoftver, még egyszerűbb: jobb klikk (VeraCrypt Setup 1.24.exe)-tulajdonságok-fájlok hash összege.

A program aláírásának ellenőrzéséhez a rendszerben telepítve kell lennie a szoftvernek és a fejlesztő nyilvános pgp kulcsának gnuPG; gpg4win.

A2. VeraCrypt szoftver telepítése / futtatása adminisztrátori jogokkal

A3. A rendszer titkosításának paramétereinek kiválasztása az aktív partíciónVeraCrypt – Rendszer – Rendszerpartíció/lemezt titkosítani – Normál – Windows rendszerszintű titkosítása – Több indítás – (figyelmeztetés: „Tapasztalatlan felhasználóknak nem ajánlott ezt a módszert használni”, és ez igaz, egyetértek „Igen”) – Indítólemez („igen”, még ha nem is így van, akkor is „igen”) – Rendszerlemez száma „2 vagy több” – Több rendszer egy lemezen „Igen” – Nem Windows rendszerindító „Nem” (tulajdonképpen „Igen”, de a VeraCrypt/GRUB2 indítók nem osztják meg a MBR-t egymással, pontosabban, a MBR/indító sávban csak a betöltő kód legkisebb része tárolódik, a fő része a fájlrendszer határain belül helyezkedik el) – Többindítás – A titkosítási beállítások…

Ha eltér a fent leírt lépésektől (blokkos rendszer titkosítási sémák), akkor a VeraCrypt figyelmeztetést ad és nem engedi a partíció titkosítását.

A következő lépésnél, a célzott adatvédelemhez, végezzen egy „Tesztet” és válassza ki a titkosítási algoritmust. Ha elavult CPU-ja van, akkor valószínűleg a Twofish titkosítási algoritmus a leggyorsabb. Ha a CPU erős, észre fogja venni a különbséget: az AES – a teszteredmények alapján a titkosítás sokkal gyorsabb lesz, mint kriptográfiai riválisai. Az AES egy népszerű titkosítási algoritmus, a modern CPU-k hardveres részei kifejezetten optimalizáltak a „titkosításra” és a „feltörésre”.

A VeraCrypt lehetőséget biztosít lemezek AES kaszkádban való titkosítására(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (AES hardveres támogatás nélkül, A/T kaszkádban való titkosítás) a teljesítménycsökkenés lényegében észrevehetetlen. (az AMD CPU-k esetében ugyanazzal a korosztállyal/~paraméterekkel – a teljesítmény kissé csökkent). Az operációs rendszer dinamikusan működik és az erőforrás-fogyasztás az átlátszó titkosításhoz – észrevétlen. Ezzel szemben, például a telepített tesztelő, instabil desktop környezet Mate v1.20.1 miatt észlelhető teljesítménycsökkenés. (vagy v1.20.2, pontosan nem emlékszem) A GNU/Linux operációs rendszerben, vagy a Windows 7 telemetria alprogramja miatt. Általában a tapasztalt felhasználók a titkosítás előtt hardver teljesítménytesztet végeznek. Például az Aida64/Sysbench/systemd-analyze blame segítségével, és összehasonlítják ezeknek a teszteknek az eredményeit a rendszer titkosítása után, így megcáfolva a mítoszt, hogy a „rendszerszintű titkosítás káros”. A gép lassulása és a kényelmetlenség érzékelhető a titkosított adatok biztonsági másolatának készítése/felépítése során, mivel a „rendszerszintű adatmentés” művelet nem ezredmásodpercekben mérhető, és hozzáadódnak a „titkosítás/dekódolás valós időben” műveletek. Végül minden felhasználó, aki engedélyt kap a kriptográfiával való foglalkozásra, meghatározza a titkosító algoritmus egyensúlyát az elvárt feladatok, a paranoia fokozata és a használat kényelme mérlegelése alapján.

A PIM paramétert jobb az alapértelmezett értéken hagyni, hogy az operációs rendszer indításakor ne kelljen minden alkalommal pontos iterációs értékeket megadni. A VeraCrypt óriási számú iterációt alkalmaz a valóban „lassú hash” létrehozására. Egy ilyen „kriptováltozat” brute force/rainbow table támadása csak rövid „egyszerű” jelszófrázis és a célpont személyes charset-listája esetén érdemes. A jelszó erősségéért cserébe késleltetés lép fel a jelszó helyes megadása során az operációs rendszer indításakor. (A VeraCrypt kötetek GNU/Linux alatti csatlakoztatása lényegesen gyorsabb).
Ingyenes szoftver brute force támadás végrehajtására. (Jelszófrázis kinyerése a VeraCrypt/LUKS lemez fejlécéből). Hashcat. A John the Ripper nem tudja „feltörni a Veracryptet”, és a LUKS kezelése során nem érti a Twofish kriptográfiát.

A titkosítási algoritmusok kriptográfiai szilárdsága miatt a megállíthatatlan kriptografikák olyan szoftvert fejlesztenek ki, amely más támadási irányt céloz. Például a metaadatok/jelszavak kinyerése a RAM-ból. (Hideg lábbal/távoli memóriához való közvetlen hozzáférés támadás), speciális, ingyenes és nem ingyenes szoftverek állnak rendelkezésre ezekhez a célokhoz.

A titkosítandó aktív partíció „egyedi metaadatainak” beállítása/generálása után a VeraCrypt azt javasolja, hogy indítsuk újra a számítógépet, és teszteljük a saját betöltőprogramjának működését. Az újraindítás után a Windows-ban a VeraCrypt várakozási módban fog betöltődni, csak meg kell erősíteni a titkosítási folyamatot — Y.

A VeraCrypt végső lépésében a rendszer titkosítása javasolja, hogy készítsen egy biztonsági másolatot az aktívan titkosított partíció fejlécéről "veracrypt rescue disk.iso" formájában – ezt mindenképpen el kell végezni – ebben a szoftverben egy ilyen művelet követelmény. (a LUKS-ban, mint követelmény – ezt sajnos elhanyagolták, de a dokumentációban hangsúlyozták). A mentőlemez mindenkinek hasznos lesz, és egyeseknek akár többször is. Elveszett (a fejléc / MBR felülírása) a fejléc biztonsági másolata örökre megfoszt a hozzáféréstől a Windows operációs rendszert titkosító partícióhoz.

A4. VeraCrypt mentő USB / lemez létrehozásaAlapértelmezés szerint a VeraCrypt "2-3 MB metadatas" kiírását javasolja egy CD-re, de nem mindenki rendelkezik CD-kkel vagy DVD-ROM meghajtókkal, és a "VeraCrypt Rescue disk" indítható flash meghajtó létrehozása technikai meglepetés lehet néhány ember számára: a Rufus / GUIdd-ROSA ImageWriter és hasonló szoftverek nem tudják megoldani a kitűzött feladatot, mert a shiftelt metadaták másolása mellett az indító flash meghajtón a fájlrendszeren kívül kell másolni / beilleszteni, vagyis helyesen kell lemásolni az MBR-t / sávot a kulcsra. GNU / Linux OS alatt az "dd" segédprogram használatával készíthet indítható flash meghajtót, ehhez nézze meg ezt a táblázatot.

A mentőlemez létrehozása Windows környezetben – más. A VeraCrypt fejlesztője nem építette be a feladat megoldását hivatalosan a a dokumentációval "rescue disk"-be, de más módon javasolt megoldást: közzétette a "usb rescue disk" létrehozásához szükséges további szoftvert szabad hozzáférésre, a VeraCrypt fórumán. Ennek a Windows szoftvernek az archívuma – "usb veracrypt rescue disk létrehozása". A rescue disk.iso mentése után megkezdődik az aktív partíció blokkszintű titkosítása. Titkosítás alatt az operációs rendszer működése nem áll meg, nem szükséges a PC újraindítása. A titkosítási folyamat befejezése után az aktív partíció teljesen titkosítva lesz, használhatóvá válik. Ha a PC indításakor nem jelenik meg a VeraCrypt bootloader, és a fejléc helyreállítási művelete sem segít, ellenőrizze a "boot" kereket, amelynek be kell állítva lennie arra a partícióra, ahol a Windows található. (függetlenül a titkosítástól és más OS-ektől, lásd az 1. táblázatot).
Ezzel befejeződött a blokkszintű rendszer titkosításának leírása Windows operációs rendszeren.

[B] LUKS. GNU / Linux titkosítás (~Debian) telepített OS. Algoritmus és lépések

Ahhoz, hogy titkosítani tudjuk a telepített Debian/járulékos disztribúciót, párosítani kell a felkészített partíciót a virtuális blokkeszközhöz, át kell vinni a párosított lemezre a GNU/Linux-ot, és telepíteni/beállítani a GRUB2-t. Ha nem egy üres szerverről van szó, és értékeli az idejét, akkor a GUI-t érdemes használni, a legtöbb alábbi terminálember parancsot a „Chuck Norris üzemmódban” kell beírni.

B1. Indítsa el a számítógépet live USB GNU/Linux-ról

„Végezze el a kriptotesztest a hardver teljesítményére”

lscpu && cryptsetup benchmark

Ha Ön a hatalmas gép boldog tulajdonosa AES hardvertámogatással, akkor a számadatok a terminál jobb oldalához hasonlóak lesznek, ha boldog, de antik hardvere van — a bal oldalhoz.

B2. A lemez partícionálása. A logikai lemez HDD fájlrendszerének Ext4-re történő csatolása/formázása (Gparted)

B2.1. Az sda7 partíció titkosított fejlécének létrehozásaA partíciók nevét a saját partíciós táblázatom alapján fogom leírni, amely fent található. A lemezpartíciózásának megfelelően a saját partícióneveit kell behelyettesítenie.

A logikai lemez titkosításának párosítása ( /dev/sda7 > /dev/mapper/sda7_crypt).
#Простое создание «LUKS-AES-XTS раздела»

cryptsetup -v -y luksFormat /dev/sda7

Opciók:

* luksFormat - LUKS fejléc inicializálása;
* -y - jelszó (nem kulcs/fájl);
* -v - verbális kimenet (információ a terminál kimenetén);
* /dev/sda7 - az Ön logikai lemeze a kiterjesztett partícióból (oda, ahová a GNU/Linux átkerül/ titkosítva lesz).

Alapértelmezés szerint a titkosítási algoritmus <LUKS1: aes-xts-plain64, Kulcs: 256 bites, LUKS fejléc hash értéke: sha256, RNG: /dev/urandom> (a cryptsetup verziójától függően).

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

Ha az CPU nem rendelkezik AES hardvertámogatással, a legjobb választás a kiterjesztett „LUKS-Twofish-XTS-partíció” létrehozása lesz.

B2.2. Kiterjesztett „LUKS-Twofish-XTS-partíció” létrehozása

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

Opciók:
* luksFormat - LUKS fejléc inicializálása;
* /dev/sda7 - a jövőbeli titkosított logikai lemeze;
* -v - verbális kimenet;
* -y - jelszó;
* -c - az adatok titkosítási algoritmusának kiválasztása;
* -s - a titkosítási kulcs mérete;
* -h - hash algoritmus/kriptográfiai funkció, használt véletlenszám-generátor (—use-urandom) a logikai lemez fejlécének titkosításához/dekódolásához szükséges egyedi kulcsot, a másodlagos fejléc kulcsát (XTS); az egyedi mesterkulcs, amely a lemez titkosított fejlécében van, másodlagos XTS kulcs, mindez a metaadatok és a titkosító alprogram, amely az mesterkulccsal és a másodlagos XTS kulccsal titkosítja/dekódolja a partíción lévő adatokat (kivétel a partíció fejlécétől) kb. 3 MB méretben tárolódnak a kiválasztott merevlemezen.
* -i iterációk milliszekundumban, a "mennyiség" helyett (időbeli késlekedés a jelszó feldolgozásakor, hatással van az operációs rendszer betöltésére és a kulcsok kriptográfiai ellenállóságára). Az egyszerű "orosz" típusú jelszó kriptográfiai ellenállóságának megőrzéséhez növelni kell a -(i) értékét, míg a bonyolult jelszó, mint a "?8dƱob/øfh" esetében csökkenteni lehet.
* —use-urandom véletlenszám-generátor, kulcsokat és sót generál.

A partíció sda7 > sda7_crypt társítása után (a művelet gyors, mivel egy titkosított fejlécet hoz létre metaadatokkal ~3 MB méretben, és ezzel vége is), formázni és csatolni kell a sda7_crypt fájlrendszert.

B2.3. Társítás

cryptsetup open /dev/sda7 sda7_crypt
#a parancs végrehajtása jelszó beírását kéri.

opciók:
* open - a partíció "nevének" társítása;
* /dev/sda7 - logikai lemez;
* sda7_crypt - a társított név, amelyet a titkosított partíció csatolásakor vagy operációs rendszer indulásakor használnak.

B2.4. sda7_crypt fájlrendszer formázása ext4-re. A lemez csatolása az operációs rendszerbe(Megjegyzés: Gparted használatakor már nem lehet dolgozni a titkosított partícióval)

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

opciók:
* -v - verbális kimenet;
* -L - a lemez címkéje (amely a fájlkezelőben látható a többi lemez között).

Ezután a virtuális-titkosított blokkeszközt /dev/sda7_crypt csatlakoztatni kell a rendszerhez

mount /dev/mapper/sda7_crypt /mnt

A /mnt mappában lévő fájlokkal végzett munka automatikusan titkosítja/dekódolja az adatokat a sda7-en.

Poharasabb a partíciót társítani és csatolni a fájlkezelőben (nautilus/caja GUI), a partíció már a lemezek választási listájában lesz, csak a jelszót kell megadni a lemez megnyitásához/dekódolásához. Az azonosító név automatikusan választható, és nem "sda7_crypt", hanem valami hasonló: /dev/mapper/Luks-xx-xx...

B2.5. A lemez fejlécének biztonsági mentése (metaadatok ~3 MB)Az egyik legfontosabb dolog azonnali el kell végezni a műveleteket — a „sda7_crypt” fejléc biztonsági mentése. Ha a fejlécet felülírjuk/vagy megsérül, (például a GRUB2 telepítése az sda7 partícióra stb.), a titkosított adatok véglegesen elvesznek, nulla lehetőség van visszaállítani őket, mert lehetetlen újra generálni az azonos kulcsokat, a kulcsok egyediek.

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

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

opciók:
* luksHeaderBackup —header-backup-file -biztonsági mentési parancs;
* luksHeaderRestore —header-backup-file -visszaállítási parancs;
* ~/Bébackup_DebSHIFR — a biztonsági mentés fájlja;
* /dev/sda7 -az a partíció, amelynek a titkosított fejléc biztonsági mentését el kell végezni.
Ezen a lépésen <a titkosított partíció létrehozása és szerkesztése> véget ért.

B3. GNU/Linux operációs rendszer áttelepítése (sda4) titkosított partícióra (sda7)

Hozzuk létre a mappát /mnt2 (Megjegyzés — még mindig live USB-vel dolgozunk, az sda7_crypt be van mount-olva az /mnt-re), és mount-oljuk a GNU/Linux-unkat a /mnt2-be, amelyet titkosítani kell.

mkdir /mnt2
mount /dev/sda4 /mnt2

Helyesen végezzük el az operációs rendszer átvitelét az Rsync szoftverrel

rsync -avlxhHX --progress /mnt2/ /mnt

Az Rsync opciók a p.E1-ben találhatók.

Ezután szükséges defragmentálni kell a logikai lemez partícióját

e4defrag -c /mnt/ # miután ellenőriztük, az e4defrag jelezni fogja a partíció defragmentációs fokát, amely ~"0", ez egy tévhit, ami jelentős teljesítménycsökkenést okozhat! 
e4defrag /mnt/ # defragmentáljuk a titkosított GNU/Linux-ot

Állítsa be, hogy e4defragot végezzen a titkosított GNU/Linux-on időről időre, ha HDD-je van.
A [GNU/Linux > GNU/Linux-titkosított] átvitel és szinkronizálás ezen a lépésen véget ért.

V4. GNU/Linux beállítása a sda7 titkosított partíción

A sikeres rendszeráttelepítést követően /dev/sda4 > /dev/sda7 be kell lépni a titkosított partícióval rendelkező GNU/Linux-ba, és el kell végezni a további beállításokat (a PC újraindítása nélkül) a titkosított rendszer szempontjából. Vagyis a live USB-n kell lennie, de a parancsokat „a titkosított operációs rendszer gyökérszerkezete alapján” kell végrehajtania. Ehhez a „chroot” parancs használható. Az aktuális operációs rendszerről információt kapni (titkosított vagy sem, mert az adatok az sda4 és sda7 között szinkronban vannak), szinkronizálják az OS-t. Hozzon létre üres fájlokat a gyökérkönyvtárakban (sda4/sda7_crypt) jelölőfájlokat, például /mnt/titkosítottOS és /mnt2/lemondottOS. Gyors ellenőrzés arról, hogy melyik operációs rendszerben tartózkodik (a jövő igényeit is figyelembe véve):

ls /<Tab-Tab>

B4.1. „Belépés szimulálása a titkosított OS-be”

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

B4.2. A munka ellenőrzése titkosított rendszer viszonylatában

ls /mnt
# és látjuk a fájlt "/titkosítottOS"

history
#a terminál kimenetében meg kell, hogy jelenjen a su parancsok története a munkakörnyezetben.

B4.3. Titkosított swap létrehozása/beállítása, crypttab/fstab szerkesztéseMivel a swap fájl a rendszer minden indításakor formázásra kerül, így nincs értelme most swapot létrehozni és logikai egységgel társítani, és parancsokat adni, mint a B2.2-ben. A Swap esetében minden indításnál automatikusan saját ideiglenes titkosító kulcsokat generálnak. A swap kulcsok élettartama: a swap partíció leválasztása/kikapcsolása (+ a RAM tisztítása); vagy a rendszer újraindítása. A swap beállítása, megnyitjuk a fájlt, amely a blokk titkosított eszközök konfigurációjáért felelős (az fstab fájl analógja, de a kriptográfiáért felelős).

nano /etc/crypttab 

szerkesztjük

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

Opciók
* swap - a titkosítás alatti társított név /dev/mapper/swap.
* /dev/sda8 - használja a swaphoz logikai partíciójáról.
* /dev/urandom - a titkosítási kulcsok véletlenszerű generátora swap számára (minden új rendszerindítással — új kulcsok jönnek létre). A /dev/urandom generátor kevésbé véletlenszerű, mint a /dev/random, végül is a /dev/random a veszélyes paranoiás körülmények között működik. A rendszer indításakor a /dev/random néhány ± perc késlekedést okoz az indításban (lásd: systemd-analyze).
* swap,cipher=twofish-xts-plain64,size=512,hash=sha512: - a partíció tudja, hogy ő swap és „megfelelően” formázódik; a titkosítási algoritmus.

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

szerkesztjük

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

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

Alternatív titkosított swap
Ha valamilyen okból nem szeretné az egész partíciót a swap fájlnak átadni, akkor létezhet alternatív és jobb út: swap fájl létrehozása egy fájlban a titkosított OS partíción.

fallocate -l 3G /swap # 3GB méretű fájl létrehozása (szinte azonnali művelet)
chmod 600 /swap # jogosultságok beállítása
mkswap /swap # fájlból swap fájl létrehozása
swapon /swap # a swap bekapcsolása
free -m # ellenőrizzük, hogy a swap fájl aktív és működik-e
printf "/swap none swap sw 0 0" >> /etc/fstab # szükség esetén a rendszer újraindítása után a swap állandó lesz

A swap partíció beállítása befejeződött.

B4.4. Titkosított GNU/Linux beállítása (crypttab/fstab fájlok szerkesztése)Az /etc/crypttab fájl, ahogy az előbb említettem, a rendszerindításkor konfigurálandó titkosított blokk eszközöket írja le.

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

ha a sda7>sda7_crypt partíciót társították, mint a B2.1-ben

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

ha az sda7>sda7_crypt partíciót hasonlították össze, mint a B2.2. pontban

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

ha az sda7>sda7_crypt partíciót hasonlították össze, mint a B2.1 vagy B2.2 pontban, de nem szeretné újra megadni a jelszót az operációs rendszer feloldásához és betöltéséhez, akkor a jelszó helyett megadható egy titkos kulcs/random fájl.

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

Leírás
* none - ez jelzi, hogy az operációs rendszer betöltésekor a gyökér feloldásához titkos jelszó kifejezés megadása szükséges.
* UUID - a partíció azonosítója. A saját azonosítód megismeréséhez használd a terminált (Emlékeztető, hogy ez idő alatt és a továbbiakban a terminálban a chroot környezetben dolgozol, nem egy másik élő usb terminálban).

fdisk -l # az összes partíció ellenőrzése
blkid # valami ilyesmire kell számítani 

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

ez a sor látható a blkid parancs kéréséből az élő usb terminálban, amikor a sda7_crypt van csatolva).
Az UUID-t kifejezetten a saját sdaX-ból veszed (ne az sdaX_crypt!-t, az sdaX_crypt UUID automatikusan eltűnik a grub.cfg konfiguráció generálásakor).
* cipher=twofish-xts-plain64,size=512,hash=sha512 - a luks titkosítás kiterjesztett módja.
* /etc/skey - a titkos kulcs fájl, amely automatikusan beillesztésre kerül az operációs rendszer betöltésének feloldásához (a 3. jelszó megadása helyett). A fájl bármilyen, legfeljebb 8MB méretű lehet, de az adatok <1MB méretben olvashatók.

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

Hasonlóképpen fog kinézni:

(csináld meg magad, és meglátod).

cryptsetup luksKillSlot /dev/sda7 7 # a kulcs/jelszó eltávolítása a 7. slotból

/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

beállítás
* /dev/mapper/sda7_crypt - a sda7>sda7_crypt hozzárendelés neve, amely a /etc/crypttab fájlban szerepel.
A crypttab/fstab beállítás befejeződött.

B4.5. Fájlok konfigurálása. Kulcsfontosságú pontB4.5.1. Az /etc/initramfs-tools/conf.d/resume konfigurálásának szerkesztése

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

és kommentáld ki (ha létezik) a «#» sort a «resume». A fájl teljesen üres kell, hogy legyen.

B4.5.2. Az /etc/initramfs-tools/conf.d/cryptsetup konfigurálásának szerkesztése

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

meg kell, hogy feleljen

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

B4.5.3. Az /etc/default/grub konfigurálásának szerkesztése (ez a konfiguráció felelős azért, hogy a grub.cfg generálva legyen titkosított /boot használatakor)

nano /etc/default/grub

hozzáadjuk a «GRUB_ENABLE_CRYPTODISK=y» sort
az ‘y’ érték, a grub-mkconfig és a grub-install ellenőrizni fogja a titkosított lemezek meglétét és további parancsokat generál a hozzáférésük sürgősségi óvintézkedéseként a kezdés során. (insmod-ök ).
valaminek hasonlónak kell lennie

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. A konfig fájl szerkesztése /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

ellenőrizze, hogy a sor kommentálva van .
A jövőben (és már most sem lesz ennek a paraméternek jelentősége, de néha megnehezítheti az initrd.img frissítését).

B4.5.5. A konfig fájl szerkesztése /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

hozzáadjuk

KEYFILE_PATTERN="/etc/skey"
UMASK=0077

Ez a "skey" titkos kulcsot csomagolja az initrd.img-be, a kulcs szükséges a gyökérhely feloldásához az OS indításakor (ha nem akarja újra megadni a jelszót, akkor automatikusan a "skey" kulcs kerül beállításra).

B4.6. Frissítés /boot/initrd.img [version]A titkos kulcs csomagolásához az initrd.img-be és a cryptsetup javítások alkalmazásához frissítjük a képet

update-initramfs -u -k all

az initrd.img frissítésekor (ahogy mondani szokták: "Lehetséges, de nem biztos") figyelmeztetések jelenhetnek meg a cryptsetup-mal kapcsolatban, vagy például értesítés a Nvidia modulok hiányáról - ez normális jelenség. A fájl frissítése után ellenőrizze, hogy valóban frissült-e az idő alapján (a chroot környezetre vonatkozóan. /boot/initrd.img). Figyelem! az [update-initramfs -u -k all] előtt mindenképpen ellenőrizze, hogy cryptsetup open /dev/sda7 sda7_crypt — ez az a név, amelynek szerepelnie kell a /etc/crypttab-ban, különben újraindítás után busybox hiba lép fel)
Ezen a lépésen a konfigurációs fájlok beállítása befejeződött.

[C] GRUB2 telepítése és beállítása / Védelem

C1. Szükség esetén formázza meg a bootloaderhez kijelölt partíciót (a partíciónak legalább 20 MB-nak kell lennie)

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

C2. A /dev/sda6 csatolása a /mnt könyvtárbaMivel chroot-ban dolgozunk, a gyökérben nem lesz /mnt2 könyvtár, a /mnt mappa pedig üres lesz.
csatoljuk a GRUB2 partíciót

mount /dev/sda6 /mnt

Ha régebbi GRUB2 verziót telepítettek, a /mnt/boot/grub/i-386-pc könyvtárban (más platform is lehetséges, például nem "i386-pc") hiányoznak a kriptomodulok (egyszerűen, a könyvtárban moduloknak kell lenniük, beleértve ezeket a .mod fájlokat: cryptodisk; luks; gcry_twofish; gcry_sha512; signature_test.mod), ebben az esetben frissíteni kell a GRUB2-t.

apt-get update
apt-get install grub2 

Fontos! A GRUB2 csomag frissítésekor a kérdésre, hogy hova telepítsék a bootloadert – el kell utasítani az installálást (az ok — a GRUB2 telepítési kísérlete a "MBR"-be vagy live usb-re). Ellenkező esetben károsítja a VeraCrypt fejléceit/bootloadereit. A GRUB2 csomagok frissítése után és az installálás visszautasítása után a bootloadert kézzel kell telepíteni logikai lemezre, nem a "MBR"-be. Ha a tárolójában elavult GRUB2 verziót talál, próbálja meg frissíteni a hivatalos weboldalról – nem ellenőriztem (friss GRUB 2.02 ~BetaX betöltőkkel dolgoztam).

C3. GRUB2 telepítése a kibővített partícióra [sda6]A [p.C.2] partíciót csatolni kell.

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

opciók
* —force - a betöltő telepítése, figyelmen kívül hagyva az összes figyelmeztetést, amelyek szinte mindig léteznek és blokkolják a telepítést (kötelező jelző).
* —root-directory - a <boot\/grub> mappa telepítése a sda6 gyökérébe.
* \/dev\/sda6 - az Ön sdaX partíciója (ne hagyja ki a <szóközt> a \/mnt \/dev\/sda6 között).

C4. A konfigurációs fájl [grub.cfg] létrehozásaNe feledkezzen meg az 'update-grub2' parancsról, hanem használja a konfigurációs fájl generálására vonatkozó teljes parancsot

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

a grub.cfg fájl generálása/frissítése után a terminál kimenetében számsor(ok)nak kell megjelenni az lemezen talált OS-ekkel (a 'grub-mkconfig' valószínűleg megtalálja és meglátja az OS-t egy élő USB-ről, ha többindítós USB-je van Windows 10-nel és rengeteg élő disztribúcióval – ez normális). Ha a terminál 'üres', a 'grub.cfg' fájl nem lett generálva, akkor ez az az eset, amikor a GRUB hibák vannak a rendszerben (és valószínűleg a teszt ág repójából való betöltő) telepítse újra a GRUB2-t megbízható forrásból.
A 'egyszerű konfiguráció' telepítése és a GRUB2 beállítása befejeződött.

C5. A titkosított GNU/Linux OS teszteléseHelyesen befejezzük a titkosítást. Gondosan hagyjuk el a titkosított GNU/Linux-ot (kilépés a chroot környezetből).

umount -a # a titkosított GNU/Linux összes csatolt partíciójának leválasztása
Ctrl+d # kilépés a chroot környezetből
umount \/mnt\/dev
umount \/mnt\/proc
umount \/mnt\/sys
umount -a # a live USB-n lévő összes csatolt partíció leválasztása
újraindítás

Az újraindítás után a PC-nek el kell indítania a VeraCrypt betöltőt.


*Jelszó megadása az aktív partícióhoz – megkezdődik a Windows OS betöltése.
*Az 'Esc' billentyű megnyomása átadja az irányítást a GRUB2-nek, a titkosított GNU/Linux kiválasztásakor jelszót (sda7_crypt) kell kérni a \/boot\/initrd.img feloldásához (ha a grub2 az uuid-t 'nem találta' – ez a grub2 betöltő problémája, újra kell telepíteni, például a teszt ág/stabil és p.d.).


*Attól függően, hogy hogyan állította be a rendszert (lásd p.B4.4/4.5), a megfelelő jelszó megadása után a \/boot\/initrd.img kép feloldásához, szükséges a kernel/rendszer betöltéséhez jelszó, vagy automatikusan be lesz állítva a titkos kulcs 'skey', amely megszabadít a jelszó újbóli megadásától.

(kép az 'automatikus titkos kulcs beállításáról').

*Ezután megkezdődik a GNU/Linux betöltési folyamata a felhasználói fiók hitelesítésével.


*A felhasználó bejelentkezése és a rendszerbe való belépés után újra frissíteni kell a /boot/initrd.img-t. (lásd V4.6).

update-initramfs -u -k all

Ha felesleges sorok vannak a GRUB2 menüben, (élő USB-ről indított OS-ből). meg kell szabadulni tőlük.

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

Rövid összefoglaló a GNU/Linux rendszer titkosításáról:

• A GNU/Linux teljesen titkosítva van, beleértve a /boot/kernel-t és initrd-t;
• a titkos kulcs az initrd.img-be van csomagolva;
• a jelenlegi hitelesítési séma (a jelszó beírása az initrd feloldásához; a jelszó/kulcs az OS betöltéséhez; Linux fiók hitelesítési jelszó).

A "GRUB2 egyszerű konfigurációja" a blokkszintű partíció titkosítása befejeződött.

C6. GRUB2 kiterjesztett beállítása. A bootloader védelme digitális aláírással + hitelesítéssel.A GNU/Linux teljesen titkosítva van, de a bootloader nem titkosítható – ezt a BIOS követelménye diktálja. Ezért a GRUB2 láncban való titkos betöltése lehetetlen, de elérhető/e egyszerű láncbeli betöltés, védelmi szempontból nem szükséges [lásd P. F].
A "sebezhető" GRUB2 védelme érdekében a fejlesztők egy "aláírással/hitelesítéssel" történő bootloader védelmi algoritmust valósítottak meg.

• Ha a bootloadert "saját digitális aláírásával" védik, a fájlok külső módosítása vagy további modulok betöltése ezen a bootloaderen a betöltési folyamat leállásához vezet.
• Ha a bootloadert hitelesítéssel védik, akkor bármely disztribúció kiválasztásához vagy további parancsok beírásához a CLI-ben meg kell adnia a GRUB2 superfelhasználó felhasználónevét és jelszavát.

C6.1. A bootloader védelme hitelesítéssel.Győződjön meg róla, hogy titkosított OS termináljában dolgozik.

ls / #nyisson meg egy marker fájlt.

Hozzon létre egy superfelhasználói jelszót a GRUB2 hitelesítéséhez.

grub-mkpasswd-pbkdf2 #írd be/ismételd meg a superfelhasználói jelszót. 

Kapja meg a jelszó hash-ét. Valami ilyesmi:

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

Mountoljuk a GRUB partíciót.

mount /dev/sda6 /mnt 

Szerkeszti a konfigurációt.

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

Ellenőrizze a fájlban, hogy a 'grub.cfg'-ben sehol sincsenek címkék ("—unrestricted" "—user",
Adja hozzá a legvégére. (a sor előtt ### END /etc/grub.d/41_custom ###)
"set superusers='root'"
password_pbkdf2 root hash.

Körülbelül így kellene kinéznie.

# 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
ha [ -z «${config_directory}» -a -f $prefix/custom.cfg ]; akkor
forrás $prefix/custom.cfg;
fi
állítsa be a szuperhasználókat=«root»
jelszó_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
### END /etc/grub.d/41_custom ###
#

Ha gyakran használja a „grub-mkconfig -o /mnt/boot/grub/grub.cfg” parancsot, és nem akarja mindig módosítani a grub.cfg-t, adja hozzá a fenti sorokat (felhasználónév/jelszó) a GRUB felhasználói szkript végére

nano /etc/grub.d/41_custom 

cat << EOF
állítsa be a szuperhasználókat=«root»
jelszó_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
EOF

A „grub-mkconfig -o /mnt/boot/grub/grub.cfg” konfiguráció generálásakor a hitelesítéssel kapcsolatos sorok automatikusan hozzáadódnak a grub.cfg-hez.
Ezen a lépésen a GRUB2 hitelesítése befejeződött.

C6.2. A rendszerindító védelme digitális aláírássalFeltételezzük, hogy már rendelkezik a saját titkosító pgp-kulcsával (vagy készítsen egy ilyen kulcsot). A rendszernek telepítve kell lennie a titkosító szoftverekkel: gnuPG; kleopatra/GPA; Seahorse. A titkosító szoftver jelentősen megkönnyíti az ilyen ügyeket. A Seahorse a csomag stabil verziója 3.14.0 (a fentiekhez képest újabb verziók, például V3.20 – nem teljes és jelentős hibákat tartalmaz).

A PGP-kulcsot csak su környezetben kell generálni/elindítani/ hozzáadni!

Generálja le a saját titkosító kulcsát

gpg --gen-key

Exportálja a kulcsát

gpg --export -o ~/perskey

Csatlakoztassa a logikai lemezt az OS-hez, ha még nincs csatlakoztatva

mount /dev/sda6 /mnt #sda6 – GRUB2 partíció

törölje a GRUB2 partíciót

rm -rf /mnt/

Telepítse a GRUB2-t az sda6-ra, helyezze a saját kulcsát a GRUB fő képébe „core.img”

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

opciók
* —force - a betöltő telepítése, megkerülve minden figyelmeztetést, ami mindig van (kötelező jelző).
* —modules=«gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa» - utasítja a GRUB2-t a szükséges modulok előzetes betöltésére a PC indításakor.
* -k ~/perskey - a „PGP-kulcs” elérési útja (a kulcs képként való csomagolása után eltávolítható).
* —root-directory - a boot mappa telepítése az sda6 gyökerébe
/dev/sda6 -ваш sdaХ раздел.

Generálja/Frissítse a grub.cfg-t

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

Adja hozzá a fájl végéhez a „grub.cfg” sorhoz a „trust /boot/grub/perskey” sort (a pgp-kulcs kényszerített használata). Mivel a GRUB2-t modulokkal telepítettük, beleértve a „signature_test.mod” modult is, ez megszünteti olyan parancsok hozzáadásának szükségességét a konfigurációhoz, mint a „set check_signatures=enforce”.

Jónak kell kinéznie valahogy így (a végső sorok a grub.cfg fájlban)

### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
ha [ -z «${config_directory}» -a -f $prefix/custom.cfg ]; akkor
forrás $prefix/custom.cfg;
fi
trust /boot/grub/perskey
állítsa be a szuperhasználókat=«root»
jelszó_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
### END /etc/grub.d/41_custom ###
#

A "path to '/boot/grub/perskey'" does not need to specify a specific disk partition, for example hd0,6; for the bootloader, the 'root' is the default path for the partition where GRUB2 is installed. (see set rot=..).

Signing GRUB2 (all files in all directories /GRUB) with your key 'perskey'.
A simple solution to sign (for the nautilus/caja file manager): install the 'seahorse' extension from the repository for the file manager. Your key should be added in the su environment.
Open the file manager with sudo '/mnt/boot' – right-click – sign. It looks like this in the screenshot.

The key '/mnt/boot/grub/perskey' (copy into the grub directory) also must be signed with its own signature. Check that signatures for files [*.sig] have appeared in the directory/subdirectories.
Using the method described above, sign '/boot' (our kernel, initrd). If your time is worth something, this method avoids writing a bash script for signing 'multiple files'.

To remove all bootloader signatures (if something goes wrong)

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

To avoid signing the bootloader after system updates, freeze all update packages related to GRUB2.

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

At this step, the advanced GRUB2 configuration is complete.

C6.3. Proof-test of the GRUB2 bootloader protected by digital signature and authenticationGRUB2. When selecting any GNU/Linux distribution or entering the CLI (command line) superuser authorization will be required. After entering the correct login/password, the password from initrd will be asked.

Screenshot, successful authentication of GRUB2 superuser.

If any GRUB2 files are forged/modified in grub.cfg, or a file/signature is deleted, or a malicious module.mod is loaded, a corresponding warning will appear. The loading of GRUB2 will be paused.

Screenshot, an attempt to interfere with GRUB2 'from the outside'.

During 'normal' loading 'without intrusion', the system exit status code is '0'. Therefore, it is unknown whether the protection works or not. (that is, 'with bootloader protection by signature or without it', the normal loading status is the same '0' — this is bad).

How to check the protection with a digital signature?

An inconvenient way to check: forge/delete the used GRUB2 module, for example, delete the signature luks.mod.sig and receive an error.

The correct way: enter the CLI of the bootloader and type the command

trust_list

A válaszként a „perskey” lenyomatot kell kapni, ha a státusz „0”, akkor a védelem aláírása nem működik, ellenőrizze újra a p.C6.2-t.
Ezen a lépésen befejeződött a „GRUB2 védelme digitális aláírással és hitelesítéssel” kiterjesztett beállítása.

C7 Alternatív módszer a GRUB2 indító védelméről hashing segítségévelA fent leírt mód a „CPU indító védelme/hitelesítés” klasszikusnak számít. A GRUB2 tökéletlensége miatt paranoid körülmények között valós támadásnak van kitéve, amelyről az alábbiakban írok p.[F]. Ezen kívül az operációs rendszer/kernel frissítése után újra alá kell írni az indítót.

A GRUB2 indító védelme hashing segítségével

Előnyök a klasszikus módszerhez képest:

• Magasabb megbízhatósági szint (a hashing/ellenőrzés csak a titkosított helyi forrásból történik. Az egész GRUB2-nek fenntartott partíciót ellenőrzik minden változásra, míg a klasszikus indítóvédelmi/hitelesítési rendszerben csak a fájlokat ellenőrzik, de nem az üres teret, ahová „valami gonosz” hozzáadható).
• Titkosított naplózás (a rendszer egy olvasható, személyes titkosított naplót ad hozzá).
• Sebesség (a GRUB2-nek fenntartott egész partíció védelme/ellenőrzése gyakorlatilag azonnal zajlik).
• Minden kriptográfiai folyamat automatizálása.

Hátrányok a klasszikus módszerhez képest.

• Aláírás hamisítása (elméletileg lehetséges, hogy megtalálják a megadott hash funkció ütközését).
• Emelkedett bonyolultsági szint (a klasszikus módszerhez képest kicsivel több GNU/Linux OS ismeretre van szükség).

Hogyan működik a hashing ötlet a GRUB2/partícióban

A GRUB2 partíció „alá van írva”, a rendszer indításakor ellenőrzésre kerül az indító partíció változatlansága, a bejegyzéssel együtt biztonságos (titkosított) környezetben. Indító vagy annak partíció kompromittálása esetén a napló valamikor elindít egy ilyen

Dolgot.

Napi négyszer hasonló ellenőrzés zajlik, amely nem terheli meg a rendszer erőforrásait.
A „-$ check_GRUB” paranccsal bármikor azonnali ellenőrzést végezhet naplózás nélkül, de CLI információt ad.
A „-$ sudo sign_GRUB” paranccsal azonnali újraaláírást végez az GRUB2 indítón/partíción, és frissített naplózást végez. (frissítés után szükséges az OS/boot-hoz), és az élet tovább folytatódik.

A betöltő és annak szakaszának hash-elési módszereinek megvalósítása

0) Aláírjuk a GRUB betöltőt/szakaszt, miután csatlakoztattuk a /media/username mappába

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

1) Készítünk egy kiterjesztés nélküli szkriptet az encrypted OS gyökerében ~ /podpis, alkalmazzuk rá a szükséges 744 jogosultságokat a biztonság és a 'túl okos' védelem érdekében.

Töltsük ki a tartalmát

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

Futtatjuk a szkriptet su, a GRUB szakasz és betöltőjének hash-ellenőrzése történik, log mentés.

Hozzunk létre vagy másoljunk be például egy 'rosszindulatú fájlt' [virus.mod] a GRUB2 szakaszba, és indítsunk el egy ideiglenes ellenőrzést/tesztelést:

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

A CLI-ben látnunk kell, hogy betörtek a -citadellánkba-#Урезанный лог в CLI

Sze  jan  2 11::41 MSK 2020
/media/username/GRUB/boot/grub/virus.mod: Áthelyezve innen: /media/username/GRUB/1nononoshifr
/media/username/GRUB/boot/grub/i386-pc/mda_text.mod: Rendben
/media/username/GRUB/boot/grub/grub.cfg: Rendben
hashdeep: Ellenőrzés nem sikerült
   Vizsgált bemeneti fájlok: 0
  Ismert fájlok elvárt: 0
          Megfelelő fájlok: 325
Részben megfelelő fájlok: 0
            Fájlok áthelyezve: 1
        Új fájlok találva: 0
  Ismert fájlok nem találhatóak: 0

#как видим появилось «Files moved: 1 и Audit failed» означает, что проверка не прошла.
A tesztelt szakasz sajátosságai miatt a 'New files found' helyett 'Files moved'

2) Ide helyezzük a gif-et > ~ /warning.gif, jogosultságokat állítunk be 744.

3) Beállítjuk az fstab-ot a GRUB szakasz automatikus csatlakoztatására indításkor

-$ sudo nano /etc/fstab

LABEL=GRUB /media/username/GRUB ext4 alapértelmezett 0 0

4) Végrehajtjuk a log rotációt

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

/var/log/podpis.txt {
napi
rotálás 50
méret 5M
dateext
tömörít
késleltetett tömörítés
olddir /var/log/old
}

/var/log/vtorjenie.txt {
havonta
rotálás 5
méret 5M
dateext
olddir /var/log/old
}

5) Hozzáadunk egy ütemezett feladatot a cronhoz

-$ sudo crontab -e

újraindítás ‘/podpis’
0 * /6 * * * ‘/podpis

6) Létrehozunk állandó aliasokat

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

A rendszer frissítése után -$ apt-get upgrade újra aláírjuk a GRUB szakaszunkat
-$ подпись_GRUB
Ezen a lépésen a GRUB szakasz hash-védelemmel történő védelme befejeződik.

[D] Tisztítás — nem titkosított adatok megsemmisítése

Törölje a személyes fájljait olyan mértékben, hogy 'még Isten sem tudja őket elolvasni', mondja Trey Gowdy, Dél-Karolina képviselője.

Mint általában, léteznek különböző 'mítoszok és legenden» az adatok visszaállításáról azok törlése után a merevlemezről. Ha hisz az kiber-kultúrában, vagy tagja a Dr web közösségnek, és sosem próbálta a törlés/még rekonstrukció után (például helyreállítás R-studio segítségével), akkor a javasolt módszer aligha lesz Önnek megfelelő, használja azt, ami közelebb áll Önnek.

A sikeres GNU/Linux titkosított partícióra való átvitele után a régi másolatot úgy kell törölni, hogy az adatok helyreállítása lehetetlen legyen. A törlés univerzális módja: Windows/Linux számára készült ingyenes GUI szoftver. BleachBit.
Gyors formátumozzuk a partíciót, amelyen az adatokat el kell tüntetni (a Gparted segítségével), indítjuk a BleachBit-et, kiválasztjuk az "Üres tér tisztítása" lehetőséget – kiválasztjuk a partíciót (a korábbi GNU/Linux másolatod sdaX-a), elindul a törlési folyamat. A BleachBit egy átmeneti törlést végez – ez az, amire szükségünk van, de! elméletben így működik, ha a lemezt formázva és a BB 2.0 szoftverben tisztítva használtuk.

Figyelem! A BB törli a lemezt, miközben megőrzi a metaadatokat, az fájlnevek megmaradnak az adatok eltüntetésénél (a Ccleaner nem hagy metaadatokat).

És a helyreállítás lehetősége nem teljesen mítosz.A Bleachbit V2.0-2 egy korábbi instabil Debian OS csomag (és bármely más hasonló szoftver: sfill; wipe-Nautilus – szintén észleltek ebben a rusnyaságban) tulajdonképpen kritikus hibát tartalmazott: az "üres tér tisztítása" funkció helytelenül működik HDD-n/Flash drive-okon (ntfs/ext4). Az ilyen típusú szoftverek az üres hely tisztításakor nem írják felül a teljes lemezt, ahogy sok felhasználó gondolja. És néhány (sok) törölt adatot az OS/szoftver ezeknek az adatoknak a töröltnek/használónak tart, és az üres tér törlésekor átugorja ezeket a fájlokat. A probléma az, hogy ilyen hosszú időn át tartó törlés után "törölt fájlok" helyreállíthatók még 3+ törlési átmenet után is.
A GNU/Linux alatt a Bleachbit 2.0-2 megbízhatóan működik a fájlok és mappák véglegesen törlésének funkciója, de az üres tér tisztítása nem. Összehasonlításként: Windows alatt a CCleaner szoftver üres tér törlése "ntfs"-ben hibátlanul működik, és az Úr valóban nem tudná elolvasni a törölt adatokat.

Ezért, hogy alaposan eltüntessük "kompromittáló" régi titkosítatlan adatokat, közvetlen hozzáférés szükséges a Bleachbithez ezekhez az adatokhoz, majd használni a "fájlok/mappák végleges törlése" funkciót.
A Windows rendszerében az "atiklusos törölt fájlok törlése" a CCleaner / BB használatával az "üres tér törlés" funkcióval végezhető. A GNU/Linux esetében ezzel a problémával (törölt fájlok eltávolítása) önálló tapasztalatokat kell szerezned (adattörlés + önálló helyreállítási kísérlet, nem szabad a szoftver verziójára támaszkodnod (ha nem bug, akkor hiba)), csak így értheti meg ennek a problémának a mechanizmusát, és végleg megszabadulhat a törölt adatoktól.

A Bleachbit v3.0 nem volt tesztelve, lehet, hogy a problémát már megoldották.
A Bleachbit v2.0 korrektül működik.

Ez a lépés a "meghajtó tisztítása" befejeződött.

[E] Univerzális biztonsági másolat titkosított operációs rendszerekhez

Minden felhasználónak megvan a saját módszere az adatok biztonsági mentésére, de a titkosított "operációs rendszerek" esetén kicsit eltérő megközelítést igényel a feladat. Az egységes szoftverek, mint például a "Clonezilla" és hasonló programok nem tudnak közvetlenül dolgozni a titkosított adatokkal.

A titkosított blokkeszközök biztonsági másolatának problémája:

1. univerzalitás — azonos algoritmus/szoftver biztonsági mentéshez Windows/Linux számára;
2. lehetőség parancssoros munkavégzésre bármilyen élő USB GNU/Linux rendszeren, anélkül, hogy külön szoftvert kellene letölteni (de azért javaslom a GUI használatát);
3. a biztonsági másolatok biztonsága — a tárolt "képeknek" titkosítva/jelszóval védve kell lenniük;
4. a titkosított adatok méretének meg kell egyeznie a valós másolt adatok méretével;
5. kényelmes fájlok kinyerése a biztonsági másolatból (nincs szükség a teljes rész titkosítására először).

Például biztonsági másolat/helyreállítás a "dd" segédprogrammal

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

Szinte minden pontot teljesít a megfogalmazott feladatból, de a 4. pontban kritikán aluli, mert az egész lemezt, beleértve a szabad teret is, másolja — ez nem érdekes.

Például, a GNU/Linux biztonsági másolat [tar» | gpg] segítségével kényelmes, de a Windows biztonsági mentésére más megoldást kell keresni — ez nem érdekes.

E1. Univerzális biztonsági másolat Windows/Linux. Az rsync (Grsync)+VeraCrypt kötet összekapcsolásaA biztonsági másolat készítésének algoritmusa:

1. titkosított konténer létrehozása (kötet/fájl) VeraCrypt az operációs rendszerhez;
2. az operációs rendszer átvitele/szinkronizálása az Rsync szoftver segítségével VeraCrypt titkosított konténerbe;
3. szükség esetén a VeraCrypt kötet betöltése a www.-ra.

A VeraCrypt titkosított konténer létrehozásának sajátosságai vannak:
dinamikus kötet létrehozása (a dinamikus kötet létrehozása csak Windows-ban elérhető, GNU/Linux alatt is használható);
normál kötet létrehozása, de "paranoiás jellegű" követelmények vannak (a fejlesztő szavai szerint) – a konténer formázása.

A dinamikus kötet gyakorlatilag azonnal létrejön Windows OS alatt, de a GNU/Linux > VeraCrypt D.T. rendszerből történő adatmásoláskor az adatmentés teljesítménye jelentősen csökken.

A Twofish szokásos kötet 70 GB méretben készül el (mondjuk, egy közepes teljesítményű számítógépen) HDD-n körülbelül fél óra alatt (a régi adatok egy lépésben történő felülírása, a biztonsági követelmények miatt). A VeraCrypt Windows/Linux rendszerből eltávolították a kötet gyorsformázási funkcióját a létrehozás során, ezért a konténer létrehozása csak "egylépéses felülíráson" vagy egy gyengén teljesítő dinamikus kötet létrehozásával lehetséges.

Létrehozunk egy szokásos VeraCrypt köteget (nem dinamikus/ntfs), nem szabad, hogy bármilyen probléma merüljön fel.

Beállítjuk/létrehozzuk/megnyitjuk a konténert VeraCrypt GUI> GNU/Linux élő USB alatt (a kötet automatikusan csatlakozik a /media/veracrypt2-hoz, a Windows OS kötet csatlakozik a /media/veracrypt1-hez). Létrehozunk egy titkosított biztonsági másolatot a Windows OS-ről a GUI rsync segítségével (grsync), bepipálva a megfelelő lehetőségeket.

Várja meg a folyamat befejezését. A biztonsági másolat elkészülte után egy titkosított fájlunk lesz.

Hasonlóan készítsen biztonsági másolatot a GNU/Linux OS-ről, hagyva üresen a GUI rsync "Windows kompatibilitás" jelölőnégyzetét.

Figyelem! A VeraCrypt konténer „GNU/Linux biztonsági másolathoz” csak fájlrendszer alatt hozható létre. ext4Ha ntfs konténerbe készít biztonsági másolatot, a másolat visszaállítása során elveszíti az összes jogot/csoportot minden egyes adatára.

Minden műveletet terminálban is el lehet végezni. Az rsync főbb opciói:
* -g -csoportok megőrzése;
* -P —progress — a fájlra fordított munkaidő állapota;
* -H -a kemény linkek másolása változatlanul;
* -a -archiválási mód (több jelző rlptgoD);
* -v -kibővített jelzés.

Ha szeretné csatlakoztatni a "Windows VeraCrypt kötetet" a cryptsetup szoftver segítségével, létrehozhat egy alias-t (su)

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

Most a "veramount pictures" parancs kiadásakor megjelenik a jelszó beírására vonatkozó kérés, és a Windows titkosított rendszerkötete is csatlakozik.

A VeraCrypt rendszerkötetet cryptsetup-ban csatlakoztatni az alábbi parancs:

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

VeraCrypt partíció/konténer csatlakoztatására cryptsetup-ban használandó parancs:

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

Ahelyett, hogy alias-t használnánk, hozzáadunk egy (indításkor futó) rendszerpartíciót Windows OS-sel és egy logikai titkosított NTFS lemezt a GNU/Linux indítási folyamatához.

Létrehozunk egy szkriptet és elmentjük a ~\/VeraOpen.sh fájlba.

printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --tcrypt-system --type tcrypt \/dev\/sda3 Windows_crypt && mount \/dev\/mapper\/Windows_crypt \/media\/Winda7 # dekódoljuk a jelszót base64-ből (bob) és elküldjük a jelszóbeviteli kérelemhez a Windows OS rendszerpartíciójának csatolásakor.
printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --type tcrypt \/dev\/sda1 ntfscrypt && mount \/dev\/mapper\/ntfscrypt \/media\/KonténerNtf #{analóg módon, de logikai NTFS lemezt csatolunk}.

Beállítjuk a „helyes” jogosultságokat:

sudo chmod 100 \/VeraOpen.sh

Két azonos fájlt (azonos névvel!) készítünk a \/etc\/rc.local és a ~\/etc\/init.d\/rc.local fájlban.
Kitöltjük a fájlokat.

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

Beállítjuk a „helyes” jogosultságokat:

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

Kész, most a GNU/Linux indításakor nem kell beírnunk a jelszavakat a titkosított NTFS lemezek csatolásához, a lemezek automatikusan csatolódnak.

Megjegyzés röviden arról, ami a fenti p.E1-ben lépésről lépésre le van írva (de most GNU/Linux-ra vonatkozóan).
1) Hozzunk létre egy ext4 fájlrendszerű, 4 GB-nál nagyobb (fájlhoz) Linux partíciót a Veracrypt [Kripto doboz] alatt.
2) Indítsuk újra a rendszert live USB módba.
3) ~$ cryptsetup open \/dev\/sda7 Lunux # a titkosított partíció hozzárendelése.
4) ~$ mount \/dev\/mapper\/Linux \/mnt # a titkosított partíció csatolása a \/mnt mappába.
5) ~$ mkdir mnt2 # mappa létrehozása a jövőbeli biztonsági mentéshez.
6) ~$ cryptsetup open --veracrypt --type tcrypt ~\/Kripto doboz Kripto doboz && mount \/dev\/mapper\/Kripto doboz \/mnt2 # A Veracrypt tétele a "Kripto doboz" néven és a Kripto doboz csatolása a \/mnt2-be.
7) ~$ rsync -avlxhHX --progress \/mnt \/mnt2\/ # a titkosított partíció biztonsági mentési művelete a titkosított Veracrypt tárolóra.

(p\/s\/ Figyelem! Ha titkosított GNU/Linux rendszert transzferál egyik architektúráról/másikra, például Intel-ről AMD-re (vagyis egy titkosított partíció biztonsági mentését átvisszük egy másik titkosított Intel partícióra), ne feledje miután átvitte a titkosított OS-t, hogy módosítsa a titkos kulcsot a jelszó helyett, mivel a korábbi kulcs ~\/etc\/skey már nem illik egy másik titkosított partícióhoz, és az új kulcs "cryptsetup luksAddKey" nem kívánatos, ha chroot alól készítik — lehet, hogy hibás, egyszerűen a ~\/etc\/crypttab-ban ideiglenesen módosítsa a "\/etc\/skey"-t "none"-ra, az újraindítás után és a rendszerbe való belépés után állítsa elő újra a titkos kulcsát.)

IT veteránokként soha ne felejtsük el külön biztonsági mentéseket készíteni a Windows/Linux OS titkosított partíciójának fejlécéről, különben a titkosítás ellened fordulhat.
Ezen a lépésen a titkosított OS-ek biztonsági mentése befejeződött.

[F] A GRUB2 indítóprogram támadása

RészletekHa védte az indítóprogramját digitális aláírással és/vagy hitelesítéssel (lásd a 6. p.),akkor a fizikai hozzáféréstől nem véd meg. Az encryptált adatok továbbra is elérhetetlenek lesznek, de a védelem kikerülése (a digitális aláírás eltávolítása) a GRUB2 lehetővé teszi a kiberbűnözők számára, hogy kódot injektáljanak az indítóprogramba anélkül, hogy gyanút keltenének (kivéve, ha a felhasználó manuálisan nem követi nyomon az indítóprogram állapotát, vagy nem talál ki egy saját, erős, tetszőleges szkriptkódot a grub.cfg-hez).

A támadás algoritmus. A támadó

* Élő USB-ről indítja a számítógépet. Bármilyen módosítás (a támadó által) a fájlok figyelmezteti a számítógép valós tulajdonosát az indítóprogramba való behatolásról. De a GRUB2 egyszerű újratelepítése grub.cfg megőrzésével (és a későbbi szerkesztés lehetősége) lehetővé teszi a támadó számára, hogy bármilyen fájlt szerkesszen (ebben az esetben, a GRUB2 indításakor, a valódi felhasználónak nem lesz figyelmeztetés. A státusz ugyanaz ) * Felsorolt egy titkosítatlan partíciót, és elmenti a "mnt/boot/grub/grub.cfg"-t.
* Újratelepíti az indítóprogramot
(kihajítva a "perskey"-t a core.img képből) * Visszaadja a "grub.cfg"-t > "mnt/boot/grub/grub.cfg", szükség esetén szerkeszti, például hozzáadva a saját modulját "keylogger.mod" a modulok mappába az indítóprogramban, a "grub.cfg" > sor "insmod keylogger"-hez. Vagy például, ha a támadó ravasz, akkor a GRUB2 újratelepítése után

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

(minden aláírás a helyén marad) megszerzi a GRUB2 fő képét, használva a "grub-mkimage"-t (-c opcióval)." A "-c" opció lehetővé teszi a saját konfiguráció betöltését az alap "grub.cfg" betöltése előtt. A konfiguráció állhat mindössze egy sorból: átirányítás bármely "modern.cfg"-re, mely például kb. 400 fájllal keverve, (modulok+aláírások) a "boot/grub/i386-pc" mappában. Ezenkívül a támadó tetszőleges kódot adhat meg és modulokat tölthet le, anélkül, hogy a "boot/grub/grub.cfg"-t érintené, még akkor is, ha a felhasználó "hashsum"-ot alkalmazott a fájlra, és ideiglenesen megjelenítette a képernyőn. A GRUB2 szuperfelhasználói bejelentkezési/jelszó hackelésére a támadó számára nem lesz szüksége, csupán a következő sorokat kell másolnia
(melyek a hitelesítésért felelősek) "boot/grub/grub.cfg"-ből a saját "modern.cfg"-jébe És a számítógép tulajdonosa számára továbbra is érvényes lesz a GRUB2 szuperfelhasználó hitelesítése.

állítsa be a szuperhasználókat=«root»
jelszó_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8

Láncolt indítás

(az indítóprogram egy másik indítóprogramot indít) , ahogy fentebb írtam, nem értelmes(más célra szolgál) (az más célra készült). A BIOS miatt nem lehet betölteni a titkosított indítót. (láncolt indítás esetén a GRUB2 újraindítása > titkosított GRUB2, hiba!). Azonban ha mégis szeretnénk élni a láncolt indítás ötletével, akkor biztosak lehetünk benne, hogy valóban a titkosított (nem frissített) «grub.cfg» a titkosított partícióról. Ez is téves biztonságérzetet ad, mert mindaz, ami a titkosított «grub.cfg»-ben szerepel, (modulok betöltése) együtt van a nem titkosított GRUB2-ből betöltődő modulokkal.

Ha ezt ellenőrizni szeretné, különítse el/titkosítsa egy másik partíciót sdaY, másolja rá a GRUB2-t, (a grub-install művelet titkosított partícióra nem lehetséges) és a «grub.cfg»-ben (nem titkosított konfiguráció) változtassa meg az alábbi sorokhoz hasonló sorokat

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
}

sorok
* insmod - a szükséges modulok betöltése a titkosított lemezzel való munkához;
* GRUBx2 - a GRUB2 indítómenüben megjelenő sor neve;
* cryptomount -u 15c47d1c4bd34e5289df77bcf60ee838 - lásd; fdisk -l (sda9);
* set root - a gyökér beállítása;
* normal /boot/grub/grub.cfg - a titkosított partíción található konfigurációs fájl végrehajtása.

A bizalom abban, hogy valóban a titkosított «grub.cfg»-t töltjük be - ez egy pozitív válasz a jelszó bevitelére/titkosítatlan ‘sdaY’ kiválasztásakor a GRUB menü ‘GRUBx2’ választásakor.

CLI használata közben, hogy ne zavarodjunk össze (és ellenőrizzük, hogy működik-e a ‘set root’ környezeti változó), hozzon létre üres markereket tartalmazó fájlokat, például a titkosított partíción ‘/shifr_grub’, a nem titkosított partíción ‘/noshifr_grub’. Ellenőrzés a CLI-ben

cat /Tab-Tab

Ahogy már említettük, ez nem fog segíteni a rosszindulatú modulok betöltésében, ha ilyen modulok vannak a számítógépén. Például egy billentyűleütéseket rögzítő program, amely a ‘~/i386’ mappába keveredik más fájlokkal, amíg azt egy fizikailag hozzáférő támadó le nem tölti a gépről.

A legegyszerűbb módja annak, hogy ellenőrizzük, hogy a digitális aláírás védelme aktívan működik (nincs visszaállítva), és senki sem tört be az indítóba, a CLI-ben írja be a parancsot

list_trusted

válaszként megkapjuk a ‘perskey’ másolatát, vagy semmit nem kapunk, ha támadtak minket. (szükség van a «set check_signatures=enforce» ellenőrzésére is).
Az ilyen lépés jelentős hátránya, hogy a parancsokat manuálisan kell beírni. Ha ezt a parancsot a „grub.cfg”-ben adjuk meg, és digitális aláírással védjük a konfigurációt, akkor a kulcs másolásának előzetes kimenete a képernyőn túl rövid időzítéssel jelenik meg, és lehet, hogy nem tudjuk időben megtekinteni a kimenetet, ami a GRUB2 betöltését eredményezi.
Különösebb panaszt senkire sem lehet benyújtani: a fejlesztő a saját dokumentáció 18.2. pontban hivatalosan kijelenti

Megjegyzendő, hogy még GRUB jelszóvédelem mellett is, a GRUB önmagában nem tudja megakadályozni, hogy valaki, aki fizikailag hozzáfér a géphez, megváltoztassa a gép firmware-jét (pl. Coreboot vagy BIOS), hogy más (támadó által irányított) eszközről indítsa el a gépet. A GRUB legjobb esetben is csak egy link a biztonságos indítási láncban.

A GRUB2 túlzsúfolt olyan funkciókkal, amelyek hamis biztonságérzetet adhatnak, és a fejlődése már túlszárnyalta a funkciókat az MS-DOS operációs rendszeren, pedig csak egy bootloader. Vicces, hogy a GRUB2 – „a holnap” operációs rendszerré válhat, míg a GNU/Linux által virtuálisan indított gépek számára.

Egy rövid videó arról, hogyan törtem fel a GRUB2 digitális aláírását, és bejelentettem beavatkozásomat egy valódi felhasználónak. (megijesztettem, és amit a videón mutatnak – nem ártalmatlan saját kódot írni / .mod).

Következtetések:

1) A Windows blokkos rendszer titkosítása könnyebben megvalósítható, és egy jelszóval kényelmesebb, mint több jelszó használata a GNU/Linux blokkos rendszer titkosításával, a tisztesség kedvéért: az utóbbi automatizált.

2) A cikket relevánsnak és részletesnek írtam. Egyszerű útmutató a VeraCrypt / LUKS teljes lemezes titkosításához egy otthoni gépen, amely jelenleg a legjobb az orosz weben (IMHO). Az útmutató > 50k karakter, ezért nem tárgyalja néhány érdekes fejezetet: a kriptográfusokról, akik eltűnnek / árnyékban élnek; arról, hogy a különböző GNU/Linux könyvekben kevés / nem írnak a kriptográfiáról; az orosz alkotmány 51. cikkéről; a licencelésről/запрете titkosítás Oroszországban, arról, hogy miért fontos a „root / boot” titkosítása. Az útmutató már így is jelentős lett, de részletes (még az egyszerű lépéseket is leírva), ez pedig rengeteg időt fog megspórolni, amikor a „valódi titkosítással” foglalkozik.

3) A teljes lemezes titkosítást Windows 7 64-en; GNU/Linux Parrot 4x; GNU/Debian 9.0/9.5 rendszeren végeztem.

4) Sikeres támadást hajtottam végre a saját GRUB2 bootloaderem ellen.

5) A bemutató célja, hogy segítsen a CIS térség paranoiásainak, ahol a titkosítással való munka jogilag engedélyezett. Elsősorban azok számára készült, akik teljes lemezes titkosítást szeretnének alkalmazni anélkül, hogy törölnék a beállított rendszereiket.

6) Átdolgoztam és frissítettem az útmutatómat, amely 2020-ban aktuális.

[G] Hasznos dokumentáció

1. TrueCrypt felhasználói kézikönyv (2012 február RU)
2. VeraCrypt dokumentáció
3. /usr/share/doc/cryptsetup(-run) [локальный ресурс] (hivatalos részletes dokumentáció a GNU/Linux titkosítás beállításáról a cryptsetup segítségével)
4. Hivatalos cryptsetup FAQ (rövid dokumentáció a GNU/Linux titkosítás beállításáról a cryptsetup segítségével)
5. LUKS eszköz titkosítása (archlinux dokumentáció)
6. Részletes leírás a cryptsetup szintaxisáról (arch kézikönyv oldal)
7. Részletes leírás a crypttab-ról (arch kézikönyv oldal)
8. Hivatalos GRUB2 dokumentáció.

Címkék: teljes lemezes titkosítás, particionálás titkosítása, Linux teljes lemezes titkosítás, LUKS1 teljes rendszer titkosítás.

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.

Titkosítasz?

• 17,1%Mindent titkosítok, amit csak lehet. Paranoiás vagyok.

• 34,2%Csak a fontos adatokat titkosítom.

• 14,6%Néha titkosítok, néha elfelejtem.

• 34,2%Nem, nem titkosítok, az kényelmetlen és költséges.

82 felhasználó szavazott. 22 felhasználó tartózkodott.

Forrás: habr.com