Szyfrowanie pełnodyskowe Windows Linux zainstalowanych systemów. Zaszyfrowany wielonik.

Zaktualizowana własna instrukcja dotycząca pełnego szyfrowania dysku w Runecie V0.2.

Strategia kowbojska:

[A] blokowe szyfrowanie systemu Windows 7 zainstalowanego systemu;
[B] blokowe szyfrowanie GNU/Linux (Debian) zainstalowanego systemu (w tym /boot);
[C] konfiguracja GRUB2, ochrona bootloadera cyfrowym podpisem/autoryzacją/haszowaniem;
[D] czyszczenie — niszczenie niezaszyfrowanych danych;
[E] uniwersalne tworzenie kopii zapasowych zaszyfrowanych systemów operacyjnych;
[F] atak cel — bootloader GRUB2;
[G] przydatna dokumentacja.

╭───Schemat #komory 40# :
├──╼ zainstalowany Windows 7 — pełne szyfrowanie systemowe, nieukryte;
├──╼ zainstalowany GNU/Linux (Debian i pochodne dystrybucje) — pełne szyfrowanie systemowe nieukryte(/, w tym /boot; swap);
├──╼ niezależne bootloadery: bootloader VeraCrypt zainstalowany w MBR, bootloader GRUB2 zainstalowany w rozszerzonej partycji;
├──╼ instalacja/ponowna instalacja systemu operacyjnego nie jest wymagana;
└──╼ używane oprogramowanie kryptograficzne: VeraCrypt; Cryptsetup; GnuPG; Seahorse; Hashdeep; GRUB2 – darmowe.

Powyższy schemat częściowo rozwiązuje problem „zewnętrznego bootowania na pendrive”, umożliwia korzystanie z zaszyfrowanych systemów Windows/Linux oraz wymianę danych przez „zaszyfrowany kanał” z jednej OS do drugiej.

Kolejność ładowania PC (jedna z opcji):

• włączenie maszyny;
• ładowanie bootloadera VeraCrypt (prawidłowe wprowadzenie hasła kontynuuje ładowanie Windows 7);
• naciśnięcie klawisza „Esc” załadowuje bootloader GRUB2;
• bootloader GRUB2 (wybór dystrybucji/GNU/Linux/CLI), zażąda autoryzacji superużytkownika GRUB2 ;
• po pomyślnej autoryzacji i wyborze dystrybucji, konieczne będzie wprowadzenie frazy hasła w celu odblokowania „/boot/initrd.img”;
• po wprowadzeniu poprawnych haseł w GRUB2 „konieczne” będzie wprowadzenie hasła (trzeciego z kolei, hasło BIOS lub hasło konta użytkownika GNU/Linux – nie wchodzi w rachubę) w celu odblokowania i załadowania systemu GNU/Linux, lub automatyczna podstawienie klucza tajnego (dwa hasła + klucz, albo hasło + klucz);
• zewnętrzna ingerencja w konfigurację GRUB2 zamrozi proces ładowania GNU/Linux.

Uciążliwe? W porządku, idziemy zautomatyzować procesy.

Przy formatowaniu dysku twardego (tabela MBR) PC może mieć nie więcej niż 4 główne partycje, lub 3 główne i jedną rozszerzoną, a także nieprzydzieloną przestrzeń. Rozszerzona partycja w przeciwieństwie do głównej może zawierać podpartycje. (dyski logiczne=rozszerzona partycja). Innymi słowy, „rozszerzona partycja” na dysku HDD zastępuje LVM do aktualnego zadania: pełnego zaszyfrowania systemu. Jeśli twój dysk jest podzielony na 4 główne partycje, musisz użyć lvm, lub przekształcić (z formatowaniem) partycję główną na rozszerzoną, lub mądrze wykorzystać wszystkie cztery partycje i zostawić wszystko jak jest, otrzymując pożądany wynik. Nawet jeśli masz na dysku jedną partycję, Gparted pomoże podzielić HDD (na dodatkowe partycje) bez utraty danych, ale jednak z niewielką zapłatą za takie działania.

Schemat podziału dysku twardego, w odniesieniu do którego będzie przebiegać werbalizacja całego artykułu, jest przedstawiony w tabeli poniżej.

Tabela (nr 1) partycji 1TB.

Coś takiego powinno być i u ciebie.
sda1 — główna partycja nr 1 NTFS (zaszyfrowana);
sda2 — partycja rozszerzona znacznik;
sda6 — dysk logiczny (na nim zainstalowany jest bootloader GRUB2);
sda8 — swap (zaszyfrowany plik wymiany/nigdy nie zawsze);
sda9 — testowy dysk logiczny;
sda5 — dysk logiczny dla ciekawskich;
sda7 — system operacyjny GNU/Linux (przeniesiony system na zaszyfrowany dysk logiczny);
sda3 — główna partycja nr 2 z systemem Windows 7 (zaszyfrowana);
sda4 — główna partycja nr 3 (w niej znajdowała się niezabezpieczona GNU/Linux, używana jako backup/nigdy nie zawsze).

[A] Blokowe szyfrowanie systemowe Windows 7

A1. VeraCrypt

Rozruch z oficjalnej strony, lub z lustra sourceforge wersji instalacyjnej oprogramowania kryptograficznego VeraCrypt (w momencie publikacji artykułu v1.24-Update3, przenośna wersja VeraCrypt nie nadaje się do szyfrowania systemowego). Sprawdź sumę kontrolną pobranego oprogramowania

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

i porównaj uzyskany wynik z opublikowaną sumą kontrolną na stronie dewelopera VeraCrypt.

Jeśli zainstalowane jest oprogramowanie HashTab, jeszcze łatwiej: PPM (VeraCrypt Setup 1.24.exe)-właściwości-sumy kontrolnej plików.

Aby sprawdzić podpis programu w systemie, muszą być zainstalowane oprogramowanie i publiczny klucz pgp dewelopera gnuPG; gpg4win.

A2. Instalacja/uruchomienie oprogramowania VeraCrypt z prawami administratora

A3. Wybór parametrów szyfrowania systemowego aktywnej partycjiVeraCrypt – System – Szyfruj partycję/system dysk – Zwykły – Szyfruj partycję systemową Windows – Multiboot – (ostrzeżenie: „Nieopróżnionym użytkownikom nie zaleca się stosowania tej metody” i to prawda, zgadzamy się „Tak”) – Dysk rozruchowy („tak“, nawet jeśli nie tak, to i tak „tak“) – Liczba dysków systemowych „2 lub więcej” – Kilka systemów na jednym dysku „Tak” – Nie Windows bootloader „Nie” (faktycznie „Tak”, ale bootloadery VeraCrypt/GRUB2 nie będą dzielić MBR między sobą, dokładniej, w MBR/śladzie rozruchowym przechowywana jest tylko najmniejsza część kodu bootloadera, główna jego część znajduje się w granicach systemu plików) – Wielokrotne uruchamianie – Ustawienia parametrów szyfrowania…

Jeśli odstąpisz od powyżej opisanych kroków (schematy blokowego szyfrowania systemu), to VeraCrypt wyświetli ostrzeżenie i nie pozwoli na zaszyfrowanie partycji.

Na następnym kroku, przy ukierunkowanej ochronie danych, wykonaj „Test” i wybierz algorytm szyfrowania. Jeśli masz nie nowoczesny CPU, to najprawdopodobniej najszybszym algorytmem szyfrowania będzie Twofish. Jeśli CPU jest mocny, różnicę zauważysz: AES — szyfrowanie według wyników testu będzie kilkakrotnie szybsze od swoich konkurentów kryptograficznych. AES to popularny algorytm szyfrowania, sprzęt współczesnych CPU jest specjalnie zoptymalizowany pod kątem „sekretu” oraz „łamania”.

VeraCrypt obsługuje możliwość szyfrowania dysków kaskadowo AES(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (bez wsparcia sprzętowego dla AES, szyfrowanie kaskadowe A/T) spadek wydajności w zasadzie niezauważalny. (w przypadku CPU AMD tej samej epoki/~parametrów — wydajność nieco obniżona). System operacyjny działa dynamicznie, a zużycie zasobów na przejrzyste szyfrowanie – niezauważalne. W przeciwieństwie, jak na przykład zauważalny spadek wydajności z powodu zainstalowanego testowego, niestabilnego środowiska graficznego Mate v1.20.1 (lub v1.20.2, dokładnie nie pamiętam) W GNU/Linux, lub z powodu działania podprogramu telemetrycznego w Windows 7↑. Zwykle zaawansowani użytkownicy przeprowadzają testy wydajności hardware'u przed szyfrowaniem. Na przykład, w Aida64/Sysbench/systemd-analyze blame i porównują wyniki tych samych testów po zaszyfrowaniu systemu, tym samym obalają mit, że „szyfrowanie systemowe jest szkodliwe”. Spowolnienie maszyny i dyskomfort są odczuwalne podczas tworzenia kopii zapasowych/przywracania zaszyfrowanych danych, ponieważ sama operacja „szyfrowania danych” nie mierzy się w milisekundach i dodają się te same <odszyfrować/szyfrować w locie>. Ostatecznie każdy użytkownik, któremu pozwala się na zabawę z kryptografią, ustala równowagę algorytmu szyfrowania w stosunku do zadowolenia z realizacji zadań, stopnia własnej paranoi i wygody użytkowania.

Parametr PIM lepiej pozostawić domyślnie, aby przy ładowaniu systemu operacyjnego za każdym razem nie wprowadzać dokładnych wartości iteracji. VeraCrypt stosuje ogromną liczbę iteracji, aby stworzyć naprawdę „wolny hash”. Atak na taką „krypto-zabawę” metodą Brute force/tablic tęczowych ma sens tylko przy krótkiej „prostej” frazie hasłowej i osobistej liście charset ofiary. Cennik za wytrzymałość hasła to opóźnienie przy poprawnym wprowadzeniu hasła przy ładowaniu systemu operacyjnego. (montowanie woluminów VeraCrypt w GNU/Linux — znacznie szybciej).
Darmowe oprogramowanie do realizacji ataku brute force (wydobywanie frazy hasłowej z nagłówka dysku VeraCrypt/LUKS) Hashcat. John the Ripper nie potrafi „łamac Veracrypt”, a podczas pracy z LUKS nie rozumie kryptografii Twofish.

Z powodu kryptograficznej wytrzymałości algorytmów szyfrowania, niepowstrzymani szifro-panki opracowują oprogramowanie z innym wektorem ataku. Na przykład, wydobywanie metadanych/kluczy z pamięci RAM (atak zimnym botem/dostęp do pamięci), istnieje specjalistyczne darmowe i płatne oprogramowanie do tych celów.

Po zakończeniu konfiguracji/generacji „unikalnych metadanych” szyfrowanej aktywnej partycji, VeraCrypt zaproponuje ponowne uruchomienie komputera i przetestowanie działania swojego bootloadera. Po rebootowaniu/startcie Windows, VeraCrypt załadowany w trybie oczekiwania, wystarczy potwierdzić proces szyfrowania — Y.

Na ostatnim etapie szyfrowania systemowego VeraCrypt zaoferuje utworzenie kopii zapasowej nagłówka aktywnej zaszyfrowanej partycji w postaci „veracrypt rescue disk.iso” — należy to zrobić obowiązkowo — w tym oprogramowaniu taka operacja jest wymagana (w LUKS, jako wymaganie – to niestety zostało pominięte, ale podkreślone w dokumentacji). Płyta ratunkowa przyda się wszystkim, a niektórym nawet wielokrotnie. Utrata (nadpisanie nagłówka/MBR) kopii zapasowej nagłówka na zawsze pozbawi dostępu do odszyfrowanej partycji z systemem Windows.

A4. Tworzenie ratunkowego usb/dysku VeraCryptDomyślnie VeraCrypt oferuje nagranie „metadanych ~2-3MB” na płycie CD, ale nie wszyscy mają płyty lub napędy DVD-ROM, a stworzenie bootowalnego pendrive'a „VeraCrypt Rescue disk” dla niektórych będzie techniczną niespodzianką: Rufus/GUIdd-ROSA ImageWriter i inne podobne oprogramowanie — nie poradzą sobie z postawionym zadaniem, ponieważ oprócz skopiowania przesuniętych metadanych na bootowalnego pendrive'a, trzeba z obrazu zrobić copy/paste poza system plików pamięci USB, krótko mówiąc, poprawnie skopiować MBR/ścieżkę na pendrive. Z poziomu systemu GNU/Linux można utworzyć bootowalnego pendrive'a, korzystając z narzędzia „dd”, spoglądając na tę tabelkę.

Tworzenie ratunkowego dysku w środowisku Windows — jest inaczej. Twórca VeraCrypt nie uwzględnił rozwiązania tej kwestii w oficjalnej dokumentację dokumencie „rescue disk”, ale zaproponował rozwiązanie inną drogą: udostępnił dodatkowe oprogramowanie do stworzenia „usb rescue disk” w wolnym dostępie na swoim forum VeraCrypt. Archiwum tego oprogramowania dla Windows – „tworzenie usb veracrypt rescue disk”. Po zapisaniu rescue disk.iso rozpocznie się proces blokowego szyfrowania systemowego aktywnej partycji. Podczas szyfrowania praca systemu nie jest przerywana, ponowne uruchomienie komputera nie jest wymagane. Po zakończeniu operacji szyfrowania, aktywna partycja staje się całkowicie zaszyfrowana i można z niej korzystać. Jeśli podczas uruchamiania komputera nie pojawia się bootloader VeraCrypt, a operacja przywracania nagłówka nie pomaga, sprawdź flagę „boot”, powinna być ustawiona na partycję, gdzie znajduje się Windows (niezależnie od szyfrowania i innych systemów operacyjnych, patrz tabela nr 1).
Na tym kończy się opis blokowego szyfrowania systemowego z systemem Windows.

[B] LUKS. Szyfrowanie GNU/Linux (~Debian) zainstalowanego systemu operacyjnego. Algorytm i Kroki

Aby zaszyfrować zainstalowany system Debian lub jego pochodną, należy powiązać przygotowaną partycję z wirtualnym urządzeniem blokowym, przenieść na zamontowany dysk GNU/Linux i zainstalować/konfigurować GRUB2. Jeśli masz serwer, który nie jest goły, i cenisz swój czas, warto używać GUI, podczas gdy większość poniżej opisanych poleceń terminala należy wprowadzać w "trybie Chucka Norrisa".

B1. Uruchamianie komputera z live USB GNU/Linux

„Przeprowadzenie testu kryptograficznego wydajności sprzętu”

lscpu && cryptsetup benchmark

Jeśli jesteś szczęśliwym posiadaczem mocnej maszyny z wsparciem sprzętowym AES, liczby będą podobne do prawej części terminala, jeśli jesteś szczęśliwy, ale z antycznym sprzętem – do lewej części.

B2. Partycjonowanie dysku. Montowanie/formatujący system plików partycji HDD w Ext4 (Gparted)

B2.1. Tworzenie zaszyfrowanego nagłówka partycji sda7Nazwy partycji będą opisane zgodnie z moją tabelą partycji, przedstawioną powyżej. Zgodnie z twoim układem dysku, powinieneś podstawiać swoje nazwy partycji.

Przypisanie szyfrowania logicznego dysku (dev/sda7 > dev/mapper/sda7_crypt).
#Простое создание «LUKS-AES-XTS раздела»

cryptsetup -v -y luksFormat /dev/sda7

Opcje:

* luksFormat - inicjalizacja nagłówka LUKS;
* -y - fraza hasłowa (nie klucz/plik);
* -v - werbalizacja (wyświetlanie informacji w terminalu);
* /dev/sda7 - twój logiczny dysk z rozszerzonej partycji (tam, gdzie planowane jest przeniesienie/szyfrowanie GNU/Linux).

Domyślnie algorytm szyfrowania <LUKS1: aes-xts-plain64, Klucz: 256 bitów, haszowanie nagłówka LUKS: sha256, RNG: /dev/urandom> (zależy od wersji cryptsetup).

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

W przypadku braku wsparcia sprzętowego AES w CPU, najlepszym wyborem będzie stworzenie rozszerzonej partycji "LUKS-Twofish-XTS".

B2.2. Rozszerzone tworzenie partycji „LUKS-Twofish-XTS”

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

Opcje:
* luksFormat - inicjalizacja nagłówka LUKS;
* /dev/sda7 twój przyszły zaszyfrowany logiczny dysk;
* -v werbalizacja;
* -y fraza hasłowa;
* -c wybór algorytmu szyfrowania danych;
* -s rozmiar klucza szyfrowania;
* -h algorytm haszowania/krótkofalowa funkcja, używana przez RNG (—use-urandom) do generowania unikalnego klucza szyfrowania/odszyfrowania nagłówka logicznego dysku, drugiego klucza nagłówka (XTS); unikalnego klucza głównego przechowywanego w zaszyfrowanym nagłówku dysku, drugiego klucza XTS, wszystkie te metadane i podprogram szyfrowania, które za pomocą klucza głównego i drugiego klucza XTS szyfrują/odszyfrowują wszelkie dane na partycji (oprócz nagłówka partycji) są przechowywane w ~3MB na wybranej partycji dysku twardego.
* -i iteracje w milisekundach, zamiast „liczby” (opóźnienie przy przetwarzaniu hasła, wpływa na uruchamianie systemu operacyjnego i odporność kryptograficzną kluczy). Aby zachować równowagę odporności kryptograficznej przy prostym haśle takim jak „russian”, należy zwiększyć wartość -(i), przy złożonym haśle takim jak „?8dƱob/øfh” wartość można zmniejszać.
* —use-urandom generator liczb losowych, generuje klucze i sól.

Po mapowaniu partycji sda7 > sda7_crypt (operacja szybka, ponieważ tworzony jest zaszyfrowany nagłówek z metadanymi ~3 MB i to wszystko), należy sformatować i zamontować system plików sda7_crypt.

B2.3. Mapowanie

cryptsetup open /dev/sda7 sda7_crypt
#wykonanie tej komendy wymaga wprowadzenia tajnego hasła.

opcje:
* open - mapować partycję „znaną jako”;
* /dev/sda7 - logiczny dysk;
* sda7_crypt - mapa nazwy używanej do montowania zaszyfrowanej partycji lub jej inicjalizacji podczas uruchamiania systemu operacyjnego.

B2.4. Formatowanie systemu plików sda7_crypt w ext4. Montowanie dysku w systemie operacyjnym(Uwaga: w Gparted praca z zaszyfrowaną partycją nie będzie już możliwa)

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

opcje:
* -v - werbalizacja;
* -L - etykieta dysku (która jest wyświetlana w menedżerze plików wśród innych dysków).

Następnie należy zamontować wirtualne zaszyfrowane urządzenie blokowe /dev/sda7_crypt w systemie

mount /dev/mapper/sda7_crypt /mnt

Praca z plikami w folderze /mnt spowoduje automatyczne szyfrowanie/odszyfrowanie danych w sda7.

Wygodniej jest mapować i montować partycję w menedżerze plików (nautilus/caja GUI), partycja już będzie na liście dostępnych dysków, wystarczy wprowadzić hasło do otwarcia/odszyfrowania dysku. Mapa nazwy zostanie wybrana automatycznie i nie będzie to „sda7_crypt”, a coś w rodzaju /dev/mapper/Luks-xx-xx…

B2.5. Kopia zapasowa nagłówka dysku (metadane ~3MB)Jedna z najważniejszych rzeczy operacja, którą należy wykonać nie odkładając — kopia zapasowa nagłówka «sda7_crypt». Jeśli nagłówek zostanie nadpisany/uszkodzony (na przykład przez zainstalowanie GRUB2 w partycji sda7 itd.), zaszyfrowane dane zostaną ostatecznie utracone bez jakiejkolwiek możliwości ich odzyskania, ponieważ nie będzie można ponownie wygenerować tych samych kluczy, klucze są tworzone unikalnie.

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

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

opcje:
* luksHeaderBackup —header-backup-file -komenda do tworzenia kopii zapasowej;
* luksHeaderRestore —header-backup-file -komenda do przywracania;
* ~~/Backup_DebSHIFR — plik kopii zapasowej;
* /dev/sda7 -partyj, którego kopia zapasowa zaszyfrowanego nagłówka dysku musi być zachowana.
Na tym etapie jest zakończone.

B3. Przenoszenie systemu GNU/Linux (sda4) na zaszyfrowaną partycję (sda7)

Tworzymy folder /mnt2 (Uwaga — nadal pracujemy z live usb, w punkcie /mnt zamontowany jest sda7_crypt), i montujemy nasz system GNU/Linux w /mnt2, który należy zaszyfrować.

mkdir /mnt2
mount /dev/sda4 /mnt2

Dokonujemy prawidłowego przeniesienia systemu za pomocą oprogramowania Rsync

rsync -avlxhHX --progress /mnt2/ /mnt

Opcje Rsync są opisane w p.E1.

Następnie, jest wymagane przeprowadzić defragmentację partycji logicznego dysku

e4defrag -c /mnt/ #po sprawdzeniu, e4defrag wyda, że stopień defragmentacji partycji ~"0", to nieporozumienie, które może cię kosztować znaczne straty wydajności!
e4defrag /mnt/ #przeprowadzamy defragmentację zaszyfrowanego GNU/Linux

Zasadą powinna być: przeprowadzać e4defrag na zaszyfrowanym GNU/Linux od czasu do czasu, jeśli masz HDD.
Przeniesienie i synchronizacja [GNU/Linux > GNU/Linux-zaszyfrowana] na tym etapie są zakończone.

B4. Konfiguracja GNU/Linux na zaszyfrowanej partycji sda7

Po pomyślnym przeniesieniu systemu /dev/sda4 > /dev/sda7 należy zalogować się do GNU/Linux na zaszyfrowanej partycji i przeprowadzić dalszą konfigurację (bez restartowania PC) w odniesieniu do zaszyfrowanego systemu. To znaczy, że znajdujesz się w live usb, ale komendy wykonujesz „względnie do korzenia zaszyfrowanego OS”. Symulować podobną sytuację będzie „chroot”. Aby szybko uzyskać informację, z jakim systemem aktualnie pracujesz (w zaszyfrowanym czy nie, ponieważ dane w sda4 i sda7 są synchronizowane), zsynchronizuj OS-y. Utwórz w katalogach głównych (sda4/sda7_crypt) puste pliki-marker, na przykład /mnt/zszyfrowanyOS i /mnt2/niezszyfrowanyOS. Szybka kontrola, w jakim OS obecnie się znajdujesz (w tym także na przyszłość):

ls /

B4.1. „Symulacja logowania do zaszyfrowanego OS”

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

B4.2. Sprawdzenie, czy prace są prowadzone w odniesieniu do zaszyfrowanego systemu

ls /mnt 
#i widzimy plik "/zaszyfrowanyOS"

history
#w terminalu powinna pojawić się historia poleceń su systemu roboczego.

B4.3. Tworzenie/konfiguracja zaszyfrowanego swap, edytowanie crypttab/fstabPonieważ plik wymiany jest formatowany przy każdym starcie systemu, nie ma sensu teraz tworzyć i mapować swap do logicznego dysku i wpisywać polecenia tak jak w p.B2.2. Dla swap-u przy każdym starcie będą automatycznie generowane własne tymczasowe klucze szyfrujące. Cykl życia kluczy swap: odmontowanie/wyłączenie partycji swap (+czyszczenie RAM); lub ponowne uruchomienie systemu. Konfiguracja swap, otwierając plik odpowiedzialny za konfigurację zablokowanych urządzeń szyfrujących (analog fstab, ale odpowiedzialny za szyfrowanie).

nano /etc/crypttab 

edytujemy

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

Opcje
* swap - przypisane imię przy szyfrowaniu /dev/mapper/swap.
* /dev/sda8 - użyj swojej logicznej partycji pod swap.
* /dev/urandom - generator losowych kluczy szyfrujących dla swap (przy każdym nowym uruchomieniu systemu — tworzone nowe klucze). Generator /dev/urandom jest mniej losowy niż /dev/random, ponieważ /dev/random jest używane w niebezpiecznych, paranoidalnych warunkach. Przy uruchamianiu systemu /dev/random spowalnia rozruch o kilka ± minut (zob. systemd-analyze).
* swap,cipher=twofish-xts-plain64,size=512,hash=sha512: - partycja wie, że jest swap i formatowana jest «odpowiednio»; algorytm szyfrujący.

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

edytujemy

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

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

Alternatywny zaszyfrowany swap
Jeśli z jakiegoś powodu nie chcesz przeznaczać całej partycji na plik wymiany, możesz pójść alternatywną i lepszą drogą: stworzenie pliku wymiany w pliku na zaszyfrowanej partycji z systemem.

fallocate -l 3G /swap #tworzenie pliku o rozmiarze 3GB (prawie natychmiastowa operacja)
chmod 600 /swap #ustawianie uprawnień
mkswap /swap #tworzymy plik wymiany z pliku
swapon /swap #uruchamiamy nasz swap
free -m #sprawdzamy, czy plik wymiany został aktywowany i działa
printf "/swap none swap sw 0 0" >> /etc/fstab #jeśli to konieczne, swap będzie stały po ponownym uruchomieniu

Konfiguracja partycji wymiany zakończona.

B4.4. Konfiguracja zaszyfrowanego GNU/Linux (edycja plików crypttab/fstab)Plik /etc/crypttab, jak wspomniałem wcześniej, opisuje zaszyfrowane urządzenia blokowe, które są konfigurowane podczas uruchamiania systemu.

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

jeżeli mapowano partycję sda7>sda7_crypt jak w p.B2.1

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

jeśli porównywaliście partycję sda7>sda7_crypt jak w p.B2.2

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

jeśli porównywaliście partycję sda7>sda7_crypt jak w p.B2.1 lub B2.2, ale nie chcecie ponownie wprowadzać hasła do odblokowania i uruchomienia systemu, to zamiast hasła można wprowadzić klucz tajny/losowy plik

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

Opis
* none - informuje, że podczas uruchamiania systemu operacyjnego, do odblokowania root wymagana jest znajomość tajnej frazy hasłowej.
* UUID - identyfikator partycji. Aby poznać swój identyfikator, wpisz w terminalu (przypomnienie, że przez cały ten czas i dalej pracujesz w terminalu w środowisku chroot, a nie w innym terminalu live usb).

fdisk -l # sprawdzenie wszystkich partycji
blkid # powinno być coś podobnego 

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

ten wiersz jest widoczny podczas wywoływania blkid z terminala live usb przy zamontowanym sda7_crypt).
UUID bierzcie dokładnie z waszego sdaX (nie sdaX_crypt!, UUID sdaX_crypt – automatycznie zniknie przy generowaniu configu grub.cfg).
* cipher=twofish-xts-plain64,size=512,hash=sha512 - luks szyfrowanie w trybie rozszerzonym.
* /etc/skey - tajny plik-klucz, który jest automatycznie podstawiany do odblokowania uruchomienia systemu operacyjnego (zamiast wprowadzenia 3. hasła). Plik może być dowolny do 8 mB, ale dane będą odczytywane <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 

Będzie to wyglądać mniej więcej tak:

(zrób samodzielnie i sam zobaczysz).

cryptsetup luksKillSlot /dev/sda7 7 # usunięcie klucza/hasła z 7 slotu

/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

opcja
* /dev/mapper/sda7_crypt - nazwa odwzorowania sda7>sda7_crypt, która jest podana w pliku /etc/crypttab.
Konfiguracja crypttab/fstab zakończona.

B4.5. Edytowanie plików konfiguracyjnych. Kluczowy momentB4.5.1. Edytowanie konfiguracji /etc/initramfs-tools/conf.d/resume

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

i zakomentuj (jeśli istnieje) „#” wiersz „resume”. Plik powinien być całkowicie pusty.

B4.5.2. Edytowanie konfiguracji /etc/initramfs-tools/conf.d/cryptsetup

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

powinno odpowiadać

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

B4.5.3. Edytowanie konfiguracji /etc/default/grub (to właśnie ten config odpowiada za możliwość generowania grub.cfg przy pracy z zaszyfrowanym /boot)

nano /etc/default/grub

dodajemy linię „GRUB_ENABLE_CRYPTODISK=y”
wartość ‘y’, grub-mkconfig i grub-install będą sprawdzać obecność zaszyfrowanych dysków i generować dodatkowe polecenia potrzebne do ich dostępu podczas uruchamiania (insmod-y <cryptomount/set root>).
powinno być coś podobnego

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. Edytowanie pliku konfiguracyjnego /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

sprawdź, czy linia jest zakomentowana .
W przyszłości (a nawet już teraz, ten parametr nie będzie miał żadnego znaczenia, ale czasami utrudnia aktualizację obrazu initrd.img).

B4.5.5. Edytowanie pliku konfiguracyjnego /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

dodajemy

KEYFILE_PATTERN="/etc/skey"
UMASK=0077

To spakuję tajny klucz „skey” w initrd.img, klucz jest potrzebny do odblokowania systemu podczas uruchamiania OS (jeśli nie chcesz ponownie wprowadzać hasła, automatycznie podstawiony jest klucz „skey”).

B4.6. Aktualizacja /boot/initrd.img [wersja]Aby spakować tajny klucz w initrd.img i zastosować poprawki cryptsetup, aktualizujemy obraz

update-initramfs -u -k all

podczas aktualizacji initrd.img (jak mówi przysłowie „Możliwe, ale to niepewne”) pojawią się ostrzeżenia związane z cryptsetup lub na przykład powiadomienie o utracie modułów Nvidia — to normalne zjawisko. Po aktualizacji pliku sprawdź, czy rzeczywiście został zaktualizowany, patrząc na czas (w odniesieniu do środowiska chroot. /boot/initrd.img). Uwaga! przed [update-initramfs -u -k all] koniecznie sprawdź, czy cryptsetup open /dev/sda7 sda7_crypt — właśnie ta nazwa powinna figurować w /etc/crypttab, w przeciwnym razie po restarcie wystąpi błąd busybox)
Na tym etapie konfiguracja plików konfiguracyjnych jest zakończona.

[S] Instalacja i konfiguracja GRUB2/Ochrona

C1. W razie potrzeby sformatuj wydzieloną partycję dla bootloadera (partycji wystarczy co najmniej 20MB)

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

C2. Zamontuj /dev/sda6 w /mntPonieważ pracujemy w chroot, w katalogu nie będzie katalogu /mnt2, a folder /mnt będzie pusty.
montujemy partycję GRUB2

mount /dev/sda6 /mnt

Jeśli masz zainstalowaną starą wersję GRUB2, w katalogu /mnt/boot/grub/i-386-pc (może być inna platforma, na przykład nie „i386-pc”) brak modułów kryptograficznych (krócej, w folderze powinny znajdować się moduły, w tym te .mod: cryptodisk; luks; gcry_twofish; gcry_sha512; signature_test.mod), w takim przypadku trzeba zaktualizować GRUB2.

apt-get update
apt-get install grub2 

Ważne! Podczas aktualizacji pakietu GRUB2 z repozytorium, na pytanie „o wybór”, gdzie zainstalować bootloader – należy odmówić instalacji (przyczyna — próba instalacji GRUB2 — w „MBR” lub na live usb). W przeciwnym razie uszkodzisz nagłówek/bootloader VeraCrypt. Po aktualizacji pakietów GRUB2 i rezygnacji z instalacji, bootloader należy zainstalować ręcznie na dysku logicznym, a nie w „MBR”. Jeśli w Twoim repozytorium jest przestarzała wersja GRUB2, spróbuj zaktualizować z oficjalnej strony – nie sprawdzałem (pracowałem z nowymi bootloaderami GRUB 2.02 ~BetaX).

C3. Instalacja GRUB2 w rozszerzonej partycji [sda6]Musisz zamontować partycję [p.C.2]

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

opcje
* —force - instalacja bootloadera, omijając wszystkie ostrzeżenia, które praktycznie zawsze istnieją i blokują instalację (flaga obowiązkowa).
* —root-directory - ustanowienie katalogu <boot\/grub> w korzeniu sda6.
* \/dev\/sda6 - twoja partycja sdaX (nie pomiń <przestrzeni> między \/mnt \/dev\/sda6).

C4. Tworzenie pliku konfiguracyjnego [grub.cfg]Zapomnij o poleceniu „update-grub2” i użyj pełnej komendy generacji pliku konfiguracyjnego

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

po zakończeniu generacji/aktualizacji pliku grub.cfg, w terminalu wyjściowym powinny pojawić się linijki(z) z wykrytymi systemami operacyjnymi na dysku („grub-mkconfig” może znaleźć i przechwycić system operacyjny z live usb, jeśli masz multibootowy pendrive z Windows 10 i wieloma dystrybucjami live – to normalne). Jeśli w terminalu „pusto”, plik „grub.cfg” nie został wygenerowany, to jest to ten przypadek, gdy w systemie GRUB są błędy (i najprawdopodobniej bootloader z testowej gałęzi repozytoriów), przeinstaluj GRUB2 z zaufanych źródeł.
Instalacja „prosta konfiguracja” i konfiguracja GRUB2 zakończona.

C5. Test dowodowy zaszyfrowanego systemu GNU/LinuxPrawidłowo kończymy kryptomisyjny proces. Ostrożnie opuszczamy zaszyfrowany GNU/Linux (wyjście z środowiska chroot).

umount -a #odmontowanie wszystkich zamontowanych partycji zaszyfrowanego GNU/Linux
Ctrl+d #wyjście z środowiska chroot
umount \/mnt\/dev
umount \/mnt\/proc
umount \/mnt\/sys
umount -a #odmontowanie wszystkich zamontowanych partycji na live usb
reboot

Po ponownym uruchomieniu komputera powinien uruchomić się bootloader VeraCrypt.


*Wprowadzenie hasła dla aktywnej partycji – rozpocznie się ładowanie systemu Windows.
*Naciśnięcie klawisza „Esc” przekaże kontrolę GRUB2, przy wyborze zaszyfrowanego GNU/Linux – będzie wymagane hasło (sda7_crypt) do odblokowania \/boot\/initrd.img (jeśli grub2 wyświetla uuid „nie znaleziono” – to jest problem bootloadera grub2, należy go przeinstalować, na przykład z testowej gałęzi/stabilnej i p.d.).


*W zależności od tego, jak skonfigurowałeś system (patrz p.B4.4/4.5) po poprawnym wprowadzeniu hasła do odblokowania obrazu \/boot\/initrd.img, potrzebne będzie hasło do załadowania jądra/katalogu systemu, lub automatycznie podstawiony zostanie tajny klucz „skey”, eliminując konieczność ponownego wprowadzenia hasła.

(zrzut ekranu „automatyczna podstawa tajnego klucza”).

*Następnie rozpocznie się znany proces ładowania GNU/Linux z uwierzytelnieniem konta użytkownika.


*Po autoryzacji użytkownika i zalogowaniu się do systemu operacyjnego należy ponownie zaktualizować /boot/initrd.img (zob. B4.6).

update-initramfs -u -k all

W przypadku dodatkowych linii w menu GRUB2 (z podłączenia OS z live USB) należy je usunąć

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

Krótki podsumowanie dotyczące systemowego szyfrowania GNU/Linux:

• GNU/Linux jest w pełni zaszyfrowany, w tym /boot/kernel i initrd;
• sekretny klucz jest zapakowany w initrd.img;
• aktualny schemat autoryzacji (wprowadzenie hasła do odblokowania initrd; hasło/klucz do uruchomienia systemu operacyjnego; hasło autoryzacji konta Linux).

„Prosta konfiguracja GRUB2” szyfrowania systemowego partycji zostało zakończone.

C6. Rozszerzona konfiguracja GRUB2. Ochrona bootloadera podpisem cyfrowym + ochrona uwierzytelnianiemGNU/Linux jest w pełni zaszyfrowany, ale bootloader nie może być szyfrowany – ten warunek narzuca BIOS. Z tego powodu łańcuchowe zaszyfrowanie GRUB2 jest niemożliwe, ale dostępne jest proste łańcuchowe uruchamianie, z punktu widzenia ochrony – nie trzeba [zob. P. F].
Dla „wrażliwego” GRUB2 deweloperzy wprowadzili algorytm ochrony bootloadera „podpisem/uwierzytelnieniem”.

• Przy ochronie bootloadera „własnym podpisem cyfrowym” zewnętrzna modyfikacja plików lub próba załadowania dodatkowych modułów w tym bootloaderze – doprowadzi proces ładowania do blokady.
• Przy ochronie bootloadera uwierzytelnieniem, aby wybrać uruchomienie jakiegoś dystrybucji lub wprowadzić dodatkowe komendy w CLI, konieczne będzie wprowadzenie loginu i hasła superużytkownika-GRUB2.

C6.1. Ochrona bootloadera uwierzytelnieniemUpewnij się, że pracujesz w terminalu w zaszyfrowanym systemie operacyjnym

ls / #zlokalizować plik znacznikowy

utwórz hasło superużytkownika do autoryzacji w GRUB2

grub-mkpasswd-pbkdf2 #wpisz/powtórz hasło superużytkownika. 

Uzyskaj skrót hasła. Coś takiego jak to

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

montujemy partycję GRUB

mount /dev/sda6 /mnt 

edytujemy konfigurację

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

sprawdź, czy w pliku „grub.cfg” nie ma gdziekolwiek flag (» —unrestricted» „—user”,
dodaj na samym końcu (przed linią ### END /etc/grub.d/41_custom ###)
„set superusers=„root”
password_pbkdf2 root hash”.

Powinno być mniej więcej tak

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

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

Jeśli często korzystasz z polecenia «grub-mkconfig -o /mnt/boot/grub/grub.cfg» i nie chcesz za każdym razem wprowadzać zmian w grub.cfg, umieść powyższe linie (login/hasło) w skrypcie użytkownika GRUB na samym dole

nano /etc/grub.d/41_custom 

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

Podczas generowania konfiguracji «grub-mkconfig -o /mnt/boot/grub/grub.cfg», linie dotyczące autoryzacji będą automatycznie dodawane do grub.cfg.
Na tym etapie konfiguracja autoryzacji GRUB2 jest zakończona.

C6.2. Ochrona bootloadera podpisem cyfrowymZakłada się, że masz już swój osobisty klucz szyfrowania pgp (lub stwórz taki klucz). W systemie musi być zainstalowane oprogramowanie kryptograficzne: gnuPG; kleopatra/GPA; Seahorse. Oprogramowanie kryptograficzne znacznie ułatwi ci życie w takich sprawach. Seahorse — stabilna wersja pakietu 3.14.0 (wersje wyższe, np. V3.20 – są niekompletne i mają poważne błędy).

Klucz PGP należy generować/uruchamiać/dodawać tylko w środowisku su!

Wygeneruj osobisty klucz szyfrujący

gpg --gen-key

Wyeksportuj swój klucz

gpg --export -o ~/perskey

Zamontuj dysk logiczny w systemie operacyjnym, jeśli jeszcze nie jest zamontowany

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

wyczyść partycję GRUB2

rm -rf /mnt/

Zainstaluj GRUB2 w sda6, umieszczając swój osobisty klucz w głównym obrazie GRUB «core.img»

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

opcje
* —force -instalacja bootloadera, omijając wszystkie ostrzeżenia, które zawsze istnieją (flaga obowiązkowa).
* —modules="gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa" - instruuje GRUB2 do wstępnego załadowania niezbędnych modułów podczas uruchamiania komputera.
* -k ~/perskey -ścieżka do «klucza PGP» (po spakowaniu klucza w obraz można go usunąć).
* —root-directory -ustawienie katalogu boot na korzeń sda6
/dev/sda6 -ваш sdaХ раздел.

Generujemy/aktualizujemy grub.cfg

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

Dodaj na końcu pliku «grub.cfg» linię «trust /boot/grub/perskey» (wymuszenie użycia klucza pgp.) Ponieważ zainstalowaliśmy GRUB2 z zestawem modułów, w tym modułem podpisu «signature_test.mod», to eliminuje potrzebę dodawania do konfiguracji polecenia typu «set check_signatures=enforce».

Powinno to wyglądać mniej więcej tak (końcowe linie w pliku grub.cfg)

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

Nie musisz wskazywać ścieżki do „/boot/grub/perskey” konkretnej partycji dysku, na przykład hd0,6, dla bootloadera „root” jest domyślną ścieżką do partycji, na której zainstalowano GRUB2. (patrz set rot=..).

Podpisujemy GRUB2 (wszystkie pliki we wszystkich katalogach /GRUB) swoim kluczem „perskey”.
Proste rozwiązanie, jak podpisać (dla menedżera plików nautilus/caja): instalujemy z repozytorium rozszerzenie „seahorse” dla menedżera plików. Klucz powinien być dodany do środowiska su.
Otwierasz menedżera plików jako sudo „/mnt/boot” – PPM – podpisz. Na zrzucie ekranu wygląda to tak

Sam klucz „/mnt/boot/grub/perskey” (skopiować do katalogu grub) też musi być podpisany swoim własnym podpisem. Sprawdź, czy w katalogu/podkatalogach pojawiły się podpisy plików [*.sig].
Podpisujemy „/boot” opisanym powyżej sposobem (nasze kernel, initrd). Jeśli Twój czas jest cenny, ta metoda pozwala uniknąć pisania skryptu bash do podpisywania „wielu plików”.

Aby usunąć wszystkie podpisy bootloadera (jeśli coś poszło nie tak)

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

Aby nie podpisywać bootloadera po aktualizacji systemu, zamrażamy wszystkie pakiety aktualizacji związane z GRUB2.

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

Na tym etapie zaawansowana konfiguracja GRUB2 została zakończona.

C6.3. Testowanie dowodowe bootloadera GRUB2, zabezpieczonego podpisem cyfrowym i uwierzytelnianiemGRUB2. Przy wyborze jakiejkolwiek dystrybucji GNU/Linux lub wejściu do CLI (wiersza poleceń) wymagana będzie autoryzacja superużytkownika. Po wprowadzeniu poprawnej nazwy użytkownika/hasła wymagane będzie hasło od initrd.

Zrzut ekranu, pomyślna autoryzacja superużytkownika GRUB2.

Jeśli zmienisz którykolwiek z plików GRUB2/wprowadzisz zmiany w grub.cfg lub usuniesz plik/podpis, załadujesz złośliwy moduł .mod, pojawi się odpowiednie ostrzeżenie. Ładowanie GRUB2 zostanie wstrzymane.

Zrzut ekranu, próba ingerencji w GRUB2 „z zewnątrz”.

Podczas „normalnego” uruchomienia „bez ingerencji” status kodu wyjścia systemu wynosi „0”. Dlatego nie wiadomo, czy ochrona działa, czy nie (czyli „z ochroną bootloadera podpisem lub bez niej” podczas normalnego uruchomienia status jest taki sam „0” — to źle).

Jak sprawdzić ochronę podpisem cyfrowym?

Niewygodny sposób sprawdzenia: podmiana/usunięcie używanego modułu GRUB2, na przykład, usunięcie podpisu luks.mod.sig i otrzymanie błędu.

Poprawny sposób: wejść do CLI bootloadera i wpisać polecenie

trust_list

W odpowiedzi powinien być wydruk „perskey”, jeśli status wynosi „0”, oznacza to, że ochrona podpisem nie działa, proszę sprawdzić p.C6.2.
Na tym etapie rozszerzona konfiguracja „Ochrona GRUB2 podpisem cyfrowym i autoryzacją” została zakończona.

C7 Alternatywna metoda ochrony bootloadera GRUB2 za pomocą haszowaniaOpisany powyżej sposób „Ochrona bootloadera CPU/Autoryzacją” to klasyka. Z powodu niedoskonałości GRUB2, w warunkach paranoidalnych jest on podatny na rzeczywiste ataki, które opiszę poniżej w p.[F]. Ponadto, po aktualizacji systemu operacyjnego/jądra konieczne jest ponowne podpisanie bootloadera.

Ochrona bootloadera GRUB2 za pomocą haszowania

Zalety w porównaniu do klasyki:

• Wyższy poziom niezawodności (haszowanie/weryfikacja odbywa się tylko z zaszyfrowanego lokalnego zasobu. Kontrolowana jest cała przypisana partycja pod GRUB2 pod kątem jakichkolwiek zmian, a wszystko inne jest zaszyfrowane, w klasycznym schemacie z ochroną bootloadera CPU/Autoryzacją kontrolowane są jedynie pliki, ale nie wolna przestrzeń, do której można dopisać „coś złowrogiego”).
• Zaszyfrowane logowanie (do schematu dodawany jest czytelny osobisty zaszyfrowany dziennik).
• Szybkość (ochrona/weryfikacja całej partycji przypisanej pod GRUB2 odbywa się praktycznie natychmiastowo).
• Automatyzacja wszystkich procesów kryptograficznych.

Wady w porównaniu do klasyki.

• Fałszowanie podpisu (teoretycznie możliwe jest znalezienie określonej kolizji funkcji haszującej).
• Zwiększony poziom trudności (w porównaniu do klasyki wymagana jest nieco większa umiejętność obsługi w systemie GNU/Linux).

Jak działa koncepcja z haszowaniem GRUB2/partycji

„Podpisywana” jest partycja GRUB2, podczas ładowania systemu operacyjnego następuje weryfikacja niezmienności partycji bootloadera z późniejszym logowaniem w bezpiecznym środowisku (zaszyfrowanym). W przypadku skompromitowania bootloadera lub jego partycji, oprócz logu incydentu uruchamiana jest taka

Rzecz.

Cztery razy dziennie odbywa się podobna kontrola, która nie obciąża zasobów systemu.
Za pomocą polecenia „-$ sprawdzenie_GRUB” można przeprowadzić natychmiastową kontrolę w dowolnym momencie bez logowania, ale z wyjściem informacji w CLI.
Za pomocą polecenia „-$ sudo podpis_GRUB” można natychmiastowo ponownie podpisać bootloader GRUB2/partycję i zaktualizować jej logowanie (konieczne po aktualizacji systemu operacyjnego/boot), a życie toczy się dalej.

Implementacja metody haszowania bootloadera i jego partycji

0) Podpiszemy bootloader/partycję GRUB, uprzednio montując go w /media/username

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

1) Tworzymy skrypt bez rozszerzenia w katalogu głównym zaszyfrowanego OS ~ /podpis, nadajemy mu odpowiednie prawa 744 oraz zabezpieczenia przed „głupcem”.

Wypełniamy jego zawartość

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

Uruchamiamy skrypt z su, nastąpi sprawdzenie haszowania partycji GRUB i jego bootloadera, zapisz log.

Stwórzmy lub skopiujmy, na przykład, „złośliwy plik” [virus.mod] do partycji GRUB2 i uruchomimy tymczasowe sprawdzenie/testowanie:

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

W CLI powinniśmy zobaczyć inwazję na naszą -cyadelę-#Урезанный лог в CLI

Śr sty  2 11:41 MSK 2020
/media/username/GRUB/boot/grub/virus.mod: Przeniesiono z /media/username/GRUB/1nononoshifr
/media/username/GRUB/boot/grub/i386-pc/mda_text.mod: Ok
/media/username/GRUB/boot/grub/grub.cfg: Ok
hashdeep: Audyt się nie powiódł
   Sprawdzone pliki wejściowe: 0
  Oczekiwane pliki znane: 0
          Dopasowane pliki: 325
Pliki częściowo dopasowane: 0
            Przeniesione pliki: 1
        Znalezione nowe pliki: 0
  Znane pliki nie znalezione: 0

#как видим появилось «Files moved: 1 и Audit failed» означает, что проверка не прошла.
Z powodu szczególności testowanej partycji zamiast „Znalezione nowe pliki” > „Przeniesione pliki”

2) Umieszczamy gif tutaj > ~/warning.gif, nadajemy prawa 744.

3) Konfigurujemy fstab na automatyczne montowanie partycji GRUB przy starcie

-$ sudo nano /etc/fstab

LABEL=GRUB /media/username/GRUB ext4 domyślne 0 0

4) Przeprowadzamy rotację logu

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

/var/log/podpis.txt {
codziennie
rotacja 50
rozmiar 5M
dataext
compress
opóźniony kompres
stara_dyrekcja /var/log/old
}

/var/log/vtorjenie.txt {
miesięcznie
rotacja 5
rozmiar 5M
dataext
stara_dyrekcja /var/log/old
}

5) Dodajemy zadanie do cron

-$ sudo crontab -e

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

6) Tworzymy stałe aliasy

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

Po aktualizacji systemu -$ apt-get upgrade ponownie podpisujemy naszą partycję GRUB
-$ podpis_GRUB
Na tym etapie zabezpieczenie haszowaniem partycji GRUB zostało zakończone.

[D] Oczyszczenie — zniszczenie niezaszyfrowanych danych

Usuń swoje osobiste pliki tak całkowicie, że „nawet Bóg nie może ich przeczytać”, jak powiedział przedstawiciel Karoliny Południowej Trey Gowdy.

Jak zwykle istnieją różne „mity i legendy” o przywracaniu danych po ich usunięciu z dysku twardego. Jeśli wierzysz w cyberczary, lub jesteś członkiem społeczności Dr web i nigdy nie próbowałeś przywracania danych po ich usunięciu/ponownym zapisaniu (na przykład, przywracanie za pomocą R-studio), wtedy zaproponowana metoda raczej ci nie odpowiada, korzystaj z tego, co jest ci bliższe.

Po udanym przeniesieniu GNU/Linux na zaszyfrowany dysk, starą kopię należy usunąć w sposób uniemożliwiający odzyskanie danych. Uniwersalny sposób na czyszczenie: oprogramowanie dla Windows/Linux, darmowe oprogramowanie GUI. BleachBit.
Szybko formatujemy partycję, z której dane należy zniszczyć (z użyciem Gparted), uruchamiamy BleachBit, wybieramy „Czyszczenie wolnego miejsca” – wybieramy partycję (wasz sdaX z poprzednią kopią GNU/Linux), rozpocznie się proces czyszczenia. BleachBit – przetrze dysk jednym przejściem – to właśnie to, czego „potrzebujemy”, Ale! tak działa tylko w teorii, jeśli sformatowano dysk i czyszczono w BB v2.0.

Uwaga! BB przetrze dysk, pozostawiając metadane, nazwy plików podczas usuwania danych są zachowywane (Ccleaner – nie pozostawia metadanych).

I mit o możliwości odzyskania danych nie jest do końca mitem.Bleachbit V2.0-2 był nieaktualnym pakietem systemu Debian (i każde inne podobne oprogramowanie: sfill; wipe-Nautilus - również zauważono w tym brudnym interesie) w rzeczywistości miało krytyczny błąd: funkcja „czyszczenia wolnego miejsca” nie działa poprawnie na HDD/pendrive'ach (ntfs/ext4). Oprogramowanie tego rodzaju podczas czyszczenia wolnego miejsca nie nadpisuje całego dysku, jak wielu użytkowników myśli. I niektóre (wiele) usuniętych danych system operacyjny/oprogramowanie uznaje za dane nieusunięte/użytkownika i podczas czyszczenia „WSP” pomija te pliki. Problem polega na tym, że po tak długim czyszczeniu dysku „usunięte pliki” można odzyskać nawet po 3+ przejściach przetarcia dysku.
Na GNU/Linux w Bleachbit 2.0-2 działają niezawodnie funkcje nieodwracalnego usuwania plików i katalogów, ale nie czyszczenie wolnego miejsca. Dla porównania: na Windows w programie CCleaner funkcja „WSP dla ntfs” działa poprawnie i Bóg naprawdę nie będzie mógł odczytać usuniętych danych.

Aby zatem dokładnie usunąć „kompromitujące” stare niezaszyfrowane dane, niezbędny jest bezpośredni dostęp Bleachbit do tych danych, następnie skorzystać z funkcji „usuwania plików/katalogów na zawsze”.
Aby usunąć „usunięte pliki przy użyciu standardowych środków systemu operacyjnego” w Windows, użyj CCleaner/BB z funkcją „WSP”. W GNU/Linux nad tą kwestią (usuwanie usuniętych plików) musisz zdobyć praktykę samodzielnie (usuwanie danych + samodzielna próba ich odzyskania i nie należy polegać na wersji oprogramowania (jeśli nie wprowadzenie, to błąd)), tylko w ten sposób zrozumiesz mechanizm tego problemu i na zawsze pozbędziesz się usuniętych danych.

Bleachbit v3.0 nie był sprawdzany, być może problem został już rozwiązany.
Bleachbit v2.0 działa poprawnie.

Na tym etapie proces „czyszczenia dysku” jest zakończony.

[E] Uniwersalne tworzenie kopii zapasowych zaszyfrowanych systemów operacyjnych

Każdy użytkownik ma swoją metodę tworzenia kopii zapasowych danych, ale zaszyfrowane dane „systemów operacyjnych” wymagają nieco innego podejścia do zadania. Ujednolicone oprogramowanie, takie jak „Clonezilla” i podobne, nie mogą działać bezpośrednio z zaszyfrowanymi danymi.

Określenie problemu tworzenia kopii zapasowej zaszyfrowanych urządzeń blokowych:

1. uniwersalność — ten sam algorytm/oprogramowanie do tworzenia kopii zapasowych dla Windows/Linux;
2. możliwość pracy w konsoli z dowolnym live usb GNU/Linux bez konieczności dodatkowego pobierania oprogramowania (ale jednak polecam GUI);
3. bezpieczeństwo kopii zapasowych — przechowywane „obrazy” powinny być zaszyfrowane/hasłowane;
4. rozmiar zaszyfrowanych danych powinien odpowiadać rozmiarowi rzeczywistych kopiowanych danych;
5. wygodne wydobywanie potrzebnych plików z kopii zapasowej (brak wymogu wcześniejszego odszyfrowania całej partycji).

Na przykład, tworzenie kopii zapasowej/przywracanie za pomocą narzędzia „dd”

dd if=/dev/sda7 of=/ścieżka/sda7.img bs=7M conv=sync,noerror
dd if=/ścieżka/sda7.img of=/dev/sda7 bs=7M conv=sync,noerror

Spełnia prawie wszystkie punkty określonego zadania, ale z punktu 4 nie wytrzymuje krytyki, ponieważ kopiuje całą partycję dysku, w tym wolne miejsce — to nie jest interesujące.

Na przykład, tworzenie kopii zapasowej GNU/Linux przez archiwizator [tar» | gpg] jest wygodne, ale do kopii zapasowej Windows trzeba szukać innego rozwiązania — to nie jest interesujące.

E1. Uniwersalne tworzenie kopii zapasowych Windows/Linux. Połączenie rsync (Grsync)+VeraCrypt wolumenAlgorytm tworzenia kopii zapasowej:

1. tworzenie zaszyfrowanego kontenera (wolumen/pliki) VeraCrypt dla systemu operacyjnego;
2. przenoszenie/synchronizacja systemu operacyjnego za pomocą oprogramowania Rsync do kontenera kryptograficznego VeraCrypt;
3. w razie potrzeby ładowanie woluminu VeraCrypt w www.

Tworzenie zaszyfrowanego kontenera VeraCrypt ma swoje cechy:
tworzenie dynamicznego woluminu (możliwość tworzenia DT tylko w Windows, można używać również w GNU/Linux);
tworzenie zwykłego woluminu, ale istnieje wymaganie „paranoidalnego charakteru” (według słów twórcy) – formatowanie kontenera.

Dynamiczny wolumin jest tworzony niemal natychmiast w systemie Windows, ale przy kopiowaniu danych z systemu GNU/Linux > VeraCrypt DT, wydajność operacji tworzenia kopii zapasowej znacznie spada.

Standardowy wolumin Twofish o pojemności 70 GB jest tworzony (powiedzmy na średniej klasy komputerze) na HDD w około pół godziny (ponowne zapisanie wcześniejszych danych kontenera w jednym przebiegu, wynikającym z wymogów bezpieczeństwa). W VeraCrypt dla Windows/Linux usunięto funkcję szybkiego formatowania woluminu podczas jego tworzenia, dlatego utworzenie kontenera jest możliwe tylko poprzez 'jednoetapowe nadpisanie' lub stworzenie mniej wydajnego dynamicznego woluminu.

Tworzymy zwykły wolumin VeraCrypt (nie dynamiczny/ntfs), nie powinno pojawić się żadnych problemów.

Konfigurujemy/tworzymy/otwieramy kontener w interfejsie VeraCrypt > GNU/Linux live usb (wolumin będzie automatycznie zamontowany w /media/veracrypt2, wolumin OS Windows zamontowany w /media/veracrypt1). Tworzymy zaszyfrowaną kopię zapasową systemu Windows za pomocą GUI rsync (grsync), zaznaczając odpowiednie opcje.

Czekamy na zakończenie procesu. Po zakończeniu tworzenia kopii zapasowej, otrzymamy jeden zaszyfrowany plik.

Podobnie tworzymy kopię zapasową systemu GNU/Linux, odznaczając w GUI rsync opcję 'kompatybilność z Windows'.

Uwaga! kontener Veracrypt do 'kopii zapasowej GNU/Linux' należy tworzyć w systemie plików ext4. Jeśli zrobisz kopię zapasową w kontenerze ntfs, to podczas przywracania takiej kopii utracisz wszystkie prawa/grupy do wszystkich swoich danych.

Wszystkie operacje można przeprowadzić także w terminalu. Główne opcje dla rsync:
* -g -zachowuje grupy;
* -P —progress — status czasu pracy nad plikiem;
* -H -kopiuje dowiązania twarde takimi, jakie są;
* -a -tryb archiwizacji (kilka flag rlptgoD);
* -v -werbalizacja.

Jeśli chcesz zamontować 'wolumin Windows VeraCrypt' przez konsolę w oprogramowaniu cryptsetup, możesz stworzyć 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

Teraz, używając komendy 'veramount pictures', pojawi się prośba o wprowadzenie hasła, a zaszyfrowany systemowy wolumin Windows będzie zamontowany w systemie.

Montaż systemowego woluminu VeraCrypt w cryptsetup komenda

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

Montaż partycji/kontenera VeraCrypt w cryptsetup komenda

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

Zamiast aliasu dodajemy (skrypt do autostartu) systemowy wolumin z systemem Windows i logiczny zaszyfrowany dysk ntfs do autostartu GNU/Linux.

Tworzymy skrypt i zapisujemy go w ~/VeraOpen.sh.

printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sda3 Windows_crypt && mount /dev/mapper/Windows_crypt /media/Winda7 # dekodujemy hasło z base64 (bob) i przesyłamy je jako zapytanie o hasło przy montowaniu systemowego dysku Windows.
printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --type tcrypt /dev/sda1 ntfscrypt && mount /dev/mapper/ntfscrypt /media/KontenerNtfz # analogicznie, ale montujemy logiczny dysk ntfs.

Przyznajemy "właściwe" uprawnienia:

sudo chmod 100 /VeraOpen.sh

Tworzymy dwa identyczne pliki (ta sama nazwa!) w /etc/rc.local i ~/etc/init.d/rc.local.
Wypełniamy pliki.

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

Przyznajemy "właściwe" uprawnienia:

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

Wszystko, teraz podczas uruchamiania GNU/Linux nie musimy wprowadzać haseł do montowania zaszyfrowanych dysków ntfs, dyski montują się automatycznie.

Krótka notatka o tym, co opisano powyżej w p.E1 krok po kroku (ale teraz dla systemu GNU/Linux).
1) Utwórz wolumin w fs ext4 > 4gb (na plik) Linux w Veracrypt [Kryptoskrzynka].
2) Uruchom ponownie z live USB.
3) ~$ cryptsetup open /dev/sda7 Lunux # mapowanie zaszyfrowanej partycji.
4) ~$ mount /dev/mapper/Linux /mnt # montowanie zaszyfrowanej partycji w /mnt.
5) ~$ mkdir mnt2 # utwórz katalog do przyszłego backupu.
6) ~$ cryptsetup open --veracrypt --type tcrypt ~/Kryptoskrzynka Kryptoskrzynka && mount /dev/mapper/Kryptoskrzynka /mnt2 # Mapowanie woluminu Veracrypt o nazwie „Kryptoskrzynka” i montowanie Kryptoskrzynki w /mnt2.
7) ~$ rsync -avlxhHX --progress /mnt /mnt2/ # operacja tworzenia kopii zapasowej zaszyfrowanej partycji w zaszyfrowanym woluminie Veracrypt.

(p/s/ Uwaga! Jeśli przenosisz zaszyfrowany system GNU/Linux z jednej architektury/maszyny na inną, na przykład Intel > AMD (to znaczy przywracasz backup z jednej zaszyfrowanej partycji na inną zaszyfrowaną partycję Intel > AMD), nie zapomnij po przeniesieniu zaszyfrowanego systemu zmienić wstawiany klucz zamiast hasła, ponieważ poprzedni klucz ~/etc/skey — już nie będzie pasował do innej zaszyfrowanej partycji, a nowy klucz „cryptsetup luksAddKey” nie jest zalecany do tworzenia z poziomu chroot — mogą wystąpić problemy, po prostu w ~/etc/crypttab tymczasowo wskaż zamiast „/etc/skey” „none”, po reboocie i zalogowaniu do systemu stwórz ponownie swój tajny klucz.

Jak weterani IT, nie zapominajmy osobno tworzyć kopii zapasowych nagłówków zaszyfrowanych partycji systemów Windows/Linux, bo szyfrowanie obróci się przeciwko wam samym.
Na tym etapie tworzenie kopii zapasowej zaszyfrowanych systemów zostało zakończone.

[F] Atak na loader GRUB2

SzczegółyJeśli zabezpieczyłeś swój loader cyfrowym podpisem i/lub autoryzacją (por. p.C6.), to fizyczny dostęp nie zapewni żadnej ochrony. Zaszyfrowane dane pozostaną niedostępne, ale obejście ochrony (zresetowanie ochrony cyfrowego podpisu) GRUB2 pozwala cyberprzestępcy wprowadzić swój kod do bootloadera, nie wzbudzając podejrzeń (chyba że użytkownik ręcznie monitoruje stan loadera lub wymyśla własny, solidny skrypt do grub.cfg).

Algorytm ataku. Napastnik

* Uruchamia komputer z live usb. Jakiekolwiek zmiany (sprawcy) plików spowodują powiadomienie rzeczywistego właściciela komputera o naruszeniu bootloadera. Jednak prosta reinstalacja GRUB2 przy zachowaniu grub.cfg (i późniejsza możliwość jego edytowania) umożliwi napastnikowi edytowanie dowolnych plików (w takim układzie, podczas uruchamiania GRUB2, rzeczywisty użytkownik nie zostanie powiadomiony. Status pozostaje ten sam )
* Montuje niezaszyfrowaną partycję, zachowując „/mnt/boot/grub/grub.cfg”.
* Reinstaluje bootloader (wyrzucając „perskey” z obrazu core.img)

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

* Przywraca „grub.cfg” > „/mnt/boot/grub/grub.cfg”, w razie potrzeby go edytuje, na przykład, dodając swój moduł „keylogger.mod” do folderu z modułami bootloadera, w „grub.cfg” > linię „insmod keylogger”. Lub, na przykład, jeśli wróg jest podstępny, to po reinstalacji GRUB2 (wszystkie podpisy pozostają na miejscu) zbiera główny obraz GRUB2, używając „grub-mkimage z opcją (-s).” Opcja „-s” pozwala ładować swój konfigurację przed załadowaniem głównego „grub.cfg”. Konfiguracja może składać się z zaledwie jednej linii: przekierowanie do dowolnego „modern.cfg”, zmieszanego na przykład z ~400 plikami (moduły + podpisy) w folderze „/boot/grub/i386-pc”. Przy tym sprawca może wprowadzać dowolny kod i podładować moduły, nie naruszając „/boot/grub/grub.cfg”, nawet jeśli użytkownik zastosował „hashsum” do pliku i tymczasowo wyświetlał go na ekranie.
Haker nie będzie musiał włamywać się do loginu/hasła superużytkownika GRUB2, będzie musiał po prostu skopiować linie (odpowiadające za autoryzację) „/boot/grub/grub.cfg” do swojego „modern.cfg”

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

A dla właściciela komputera nadal będzie obowiązywać autoryzacja superużytkownika GRUB2.

Bootowanie łańcuchowe (bootloader ładuje inny bootloader), jak już wcześniej wspomniano, nie ma sensu (jest przeznaczone do innego celu). Z powodu BIOS nie można załadować zaszyfrowanego bootloadera (podczas łańcuchowego ładowania następuje ponowne uruchomienie GRUB2 > zaszyfrowany GRUB2, błąd!). Jednak, jeśli zdecydujesz się skorzystać z pomysłu łańcuchowego ładowania, można być pewnym, że załadowany zostanie właśnie zaszyfrowany (nie zaktualizowany) „grub.cfg” z zaszyfrowanej partycji. I to również daje fałszywe poczucie bezpieczeństwa, ponieważ wszystko, co jest wskazane w zaszyfrowanym „grub.cfg” (ładowanie modułów) łączy się z modułami, które są ładowane z niezabezpieczonego GRUB2.

Jeśli chcesz to sprawdzić, wyodrębnij/zaszyfruj jeszcze jedną partycję sdaY, a następnie skopiuj na nią GRUB2 (operacja grub-install na zaszyfrowanej partycji jest niemożliwa) i w „grub.cfg” (niezabezpieczona konfiguracja) zmień linijki podobne do tych

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
}

linie
* insmod - ładowanie niezbędnych modułów do pracy z zaszyfrowanym dyskiem;
* GRUBx2 - nazwa wyświetlanej linii w menu ładowania GRUB2;
* cryptomount -u 15c47d1c4bd34e5289df77bcf60ee838 - zobacz fdisk -l (sda9);
* set root - ustawienie korzenia;
* normal /boot/grub/grub.cfg - plik wykonywalny konfiguracji na zaszyfrowanej partycji.

Pewność, że załadowany jest właśnie zaszyfrowany „grub.cfg” - to pozytywna reakcja na wprowadzenie hasła/odblokowanie „sdaY” przy wyborze pozycji „GRUBx2” w menu GRUB.

Pracując w CLI, aby nie wpaść w pułapkę (i sprawdzić, czy zmienna środowiskowa „set root” działa), utwórz puste pliki znaczników, na przykład w zaszyfrowanej partycji „/shifr_grub”, w niezabezpieczonej partycji „/noshifr_grub”. Weryfikacja w CLI

cat /Tab-Tab

Jak wspomniano wcześniej, to nie pomoże w ochronie przed ładowaniem złośliwych modułów, jeśli takie moduły znajdą się na twoim komputerze. Na przykład, keylogger, który może zapisywać naciśnięcia klawiszy w pliku i mieszać się z innymi plikami w „~/i386”, dopóki nie zostanie pobrany przez atakującego mającego fizyczny dostęp do sprzętu.

Najprostszy sposób sprawdzenia, czy ochrona przed podpisem cyfrowym działa aktywnie (nie została zresetowana), i nikt nie wkradł się do bootloadera, w CLI wpisujemy komendę

list_trusted

w odpowiedzi otrzymujemy odcisk naszego „perskey”, lub nic nie otrzymujemy, jeśli zostaliśmy zaatakowani (należy również sprawdzić „set check_signatures=enforce”).
Istotnym minusem tego kroku jest ręczne wprowadzanie poleceń. Jeśli dodasz to polecenie do „grub.cfg” i zabezpieczysz cyfrowym podpisem konfigurację, to wstępny wyświetlacz klucza na ekranie jest zbyt krótki czasowo, aby zdążyć dostrzec wynik, co prowadzi do załadowania GRUB2.
Nie ma nikogo, komu można by mógłby postawić zarzuty: deweloper w swoim dokumentacji pkt. 18.2 oficjalnie stwierdza

„Należy zauważyć, że nawet zabezpieczenie hasłem GRUB nie może uniemożliwić komuś z fizycznym dostępem do maszyny zmiany konfiguracji oprogramowania układowego tej maszyny (np. Coreboot lub BIOS), aby spowodować, że maszyna uruchomi się z innego (kontrolowanego przez atakującego) urządzenia. GRUB jest w najlepszym razie tylko jednym ogniwem w bezpiecznym łańcuchu rozruchowym”.

GRUB2 jest zbyt przeciążony funkcjami, które mogą dawać poczucie fałszywego bezpieczeństwa, a jego rozwój już wyprzedził funkcjonalnością system operacyjny MS-DOS, a to przecież tylko program ładujący. Zabawnym jest, że GRUB2 — „jutrzejszy” może stać się systemem operacyjnym, podczas gdy GNU/Linux wirtualne maszyny dla niego.

Krótki filmik o tym, jak zdejmowałem zabezpieczenie cyfrowym podpisem GRUB2 i ogłosiłem swoje włamanie prawdziwemu użytkownikowi (przestraszyłem, a zamiast tego, co pokazano w filmiku – można napisać niebezpieczny dowolny kod/.mod).

Wnioski:

1) Blokowe szyfrowanie systemu dla Windows — łatwiej do zrealizowania, a ochrona jednym hasłem jest wygodniejsza niż ochrona kilkoma hasłami przy blokowym szyfrowaniu GNU/Linux, dla sprawiedliwości: to ostatnie jest zautomatyzowane.

2) Artykuł napisałem jako stosowny, szczegółowy prosty przewodnik do pełnodyskowego szyfrowania VeraCrypt/LUKS na jednej domowej maszynie, który obecnie jest najlepszy w Sieci (IMHO). W przewodniku > 50k znaków, dlatego nie omówiono niektórych interesujących rozdziałów: o kryptografach, którzy znikają/zostają w cieniu; o tym, że w różnych książkach GNU/Linux niewiele/nic nie piszą o kryptografii; o art. 51 konstytucji RF; o licencjonowaniu/запрете szyfrowania w RF, o tym, dlaczego należy szyfrować „root/boot”. Przewodnik był i tak spory, ale szczegółowy (opisujący nawet proste kroki), co z kolei zaoszczędzi ci mnóstwo czasu, gdy zajmiesz się „prawdziwym szyfrowaniem”.

3) Pełnodyskowe szyfrowanie przeprowadzałem na Windows 7 64; GNU/Linux Parrot 4x; GNU/Debian 9.0/9.5.

4) Zrealizowałem udany atak na mój program ładujący GRUB2.

5) Poradnik został stworzony, aby pomóc wszystkim paranoików w krajach WNP, gdzie praca z szyfrowaniem jest dozwolona na mocy prawa. I przede wszystkim dla tych, którzy chcą wdrożyć szyfrowanie całego dysku bez usuwania swoich skonfigurowanych systemów.

6) Przerobiłem i zaktualizowałem swoje wytyczne, które są aktualne w 2020 roku.

[G] Przydatna dokumentacja

1. Podręcznik użytkownika TrueCrypt (luty 2012 RU)
2. Dokumentacja VeraCrypt
3. /usr/share/doc/cryptsetup(-run) [локальный ресурс] (oficjalna szczegółowa dokumentacja dotycząca konfiguracji szyfrowania GNU/Linux za pomocą cryptsetup)
4. Oficjalne FAQ cryptsetup (skrócona dokumentacja dotycząca konfiguracji szyfrowania GNU/Linux za pomocą cryptsetup)
5. Szyfrowanie urządzenia LUKS (dokumentacja archlinux)
6. Szczegółowy opis składni cryptsetup (strona podręcznika arch)
7. Szczegółowy opis crypttab (strona podręcznika arch)
8. Oficjalna dokumentacja GRUB2.

Tagi: pełne szyfrowanie dysku, szyfrowanie partycji, szyfrowanie całego dysku Linux, pełne szyfrowanie systemu LUKS1.

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.

Szyfrujesz?

• 17,1%Szyfruję wszystko, co możliwe. Mam paranoję.

• 34,2%Szyfruję tylko ważne dane.

• 14,6%Czasami szyfruję, czasami zapominam.

• 34,2%Nie, nie szyfruję, to niewygodne i kosztowne.

Głosowało 82 użytkowników. 22 użytkowników wstrzymało się.

Źródło: habr.com