Пълно дисково шифроване на Windows и Linux инсталирани системи. Шифрован многозадачен старт.

Актуализирано собствено ръководство за пълно дисково шифроване в рунета V0.2.

Ковбойска стратегия:

[A] блочно системно шифроване на инсталираната система Windows 7;
[B] блочно системно шифроване на GNU/Linux (Debian) инсталирана система (включително /boot);
[C] настройка на GRUB2, защита на буутлоудера с цифров подпис/аутентификация/хеширане;
[D] почистване — унищожаване на нешифровани данни;
[E] универсално резервно копие на шифровани ОС;
[F] атака цел — буутлоудер GRUB2;
[G] полезна документация.

╭───Схема #стая 40# :
├──╼ Windows 7 инсталирана — пълно системно шифроване, не скрито;
├──╼ GNU/Linux инсталирана (Debian и производни дистрибуции) — пълно системно шифроване не скрито(/, включително /boot; swap);
├──╼ независими буутлоудери: буутлоудер VeraCrypt инсталиран в MBR, буутлоудер GRUB2 инсталиран в разширен дял;
├──╼ инсталация/преинсталация на ОС не е необходима;
└──╼ използвано криптографско ПО: VeraCrypt; Cryptsetup; GnuPG; Seahorse; Hashdeep; GRUB2 – свободно/безплатно.

По-гореописаната схема частично решава проблема „изнасяне на boot на флашка“, позволява да се наслаждавате на шифровани ОС Windows/Linux и да обменяте данни по „шифрован канал“ от една ОС в друга.

Порядък на стартиране на ПК (един от вариантите):

• включване на машината;
• стартиране на буутлоудера VeraCrypt (въведете правилно паролата, за да продължите зареждането на Windows 7);
• натискане на клавиша „Esc“ ще стартира буутлоудера GRUB2;
• буутлоудер GRUB2 (избор на дистрибуция/ GNU/Linux/CLI), ще изиска аутентикация на суперпотребител на GRUB2 ;
• след успешна аутентикация и избор на дистрибуция, ще бъде необходимо да се въведе паролата за отключване на „/boot/initrd.img“;
• след въвеждане на правилни пароли в GRUB2 ще е „необходимо“ въвеждане на парола (третата по ред, парола на BIOS или парола на профила на потребителя на GNU/Linux – не се взима предвид) за отключване и стартиране на ОС GNU/Linux, или автоматично подставяне на секретния ключ (две пароли + ключ, или парола + ключ);
• външна намеса в конфигурацията на GRUB2 ще замрази процеса на зареждане на GNU/Linux.

Трудно? Ок, да автоматизираме процесите.

При разпределяне на твърдия диск (таблица MBR) ПК може да има не повече от 4 основни раздела, или 3 основни и един разширен, както и неразмечена област. Разширеният раздел, за разлика от основния, може да съдържа подраздели. (логични дискове=разширен раздел). С други думи, "разширеният раздел" на HDD замества LVM за текущата задача: пълно системно криптиране. Ако вашият диск е размечен на 4 основни раздела, ще трябва да използвате lvm, или да трансформирате (с форматиране) раздел от основен на разширен, или правилно да се възползвате от всички четири раздела и да оставите всичко както е, получавайки желаното. Дори ако на диска имате само един раздел, Gparted ще помогне да разделите HDD (на допълнителни раздели) без загуба на данни, но все пак с малка цена за тези действия.

Схемата на разпределение на твърдия диск, относно която ще се проведе вербализацията на цялата статия, е представена в таблицата по-долу.

Таблица (№1) на разделите 1Тб.

Нещо подобно трябва да имате и вие.
sda1 — основен раздел №1 NTFS (криптиран);
sda2 — разширен раздел маркер;
sda6 — логичен диск (на него е инсталиран зареждачът GRUB2);
sda8 — swap (криптиран файл за размяна/не винаги);
sda9 — тестов логичен диск;
sda5 — логичен диск за любопитните;
sda7 — ОС GNU/Linux (пренесена ОС на криптиран логичен диск);
sda3 — основен раздел №2 с ОС Windows 7 (криптиран);
sda4 — основен раздел №3 (в него е разположена некриптирана GNU/Linux, използва се за бекъп/не винаги).

[А] Блочно системно криптиране Windows 7

А1. VeraCrypt

Зареждане от официалния сайт, или от огледалото sourceforge инсталационната версия на криптографското ПО VeraCrypt (по време на публикуването на статията v1.24-Update3, портативната версия на VeraCrypt не е подходяща за системно криптиране). Проверете контролното сума на изтегления софтуер

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

и сравнете получения резултат с публикуваната КС на сайта на разработчика VeraCrypt.

Ако е инсталирано ПО HashTab, още по-лесно: ПКМ (VeraCrypt Setup 1.24.exe)-свойства-хеш суми на файловете.

За проверка на подписа на програмата в системата трябва да са инсталирани ПО и публичния pgp ключ на разработчика gnuPG; gpg4win.

А2. Инсталация/стартиране на ПО VeraCrypt с права на администратор

А3. Избор на параметри за системно криптиране на активния разделVeraCrypt – Система – Шифрирайте системния дял/диск – Обикновен – Шифриране на системния дял Windows – Мултизареждане – (предупреждение: «Неопитните потребители не трябва да използват този метод» и това е вярно, съгласяваме се «Да») – Зареждащ диск («да», дори и да не е така, все пак «да») – Брой системни дискове «2 и повече» – Няколко системи на един диск «Да» – Не Windows bootloader «Не» (по същество «Да», но зареждачите VeraCrypt/GRUB2 не споделят MBR помежду си, по-точно, в MBR/зареждащата пътека се съхранява само най-малката част от кода на зареждача, основната му част се намира в границите на файловата система) – Мултизареждане – Настройки на параметрите за шифроване…

Ако се отклоните от описаните по-горе стъпки (схеми за блоково системно шифроване), VeraCrypt ще изведе предупреждение и няма да позволи шифроване на дяла.

На следващата стъпка, за целенасочена защита на данните, проведете «Тест» и изберете алгоритъм за шифроване. Ако имате остарял CPU, вероятно най-бързият алгоритъм за шифроване ще бъде Twofish. Ако CPU-то е мощно, ще забележите разликата: AES – шифроването според резултатите от теста ще бъде много по-бързо от своите криптоконкуренти. AES – популярен алгоритъм за шифроване, хардуерната част на съвременните CPU е специално оптимизирана за «тайна», така и за «хакване».

VeraCrypt поддържа възможността за шифроване на дискове каскадно AES(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (без хардуерна поддръжка за AES, шифроване каскадно А/T) снижаването на производителността е практически незабележимо. (при CPU AMD от същата епоха/~параметри – производителността е леко снижена). ОС работи динамично и потреблението на ресурси за прозрачно шифроване е незабележимо. За разлика от, например, забележимо снижаване на производителността поради установен тестов нестабилен работен среда Mate v1.20.1 (или v1.20.2 точния не помня) в GNU/Linux, или заради работата на подсистемата за телеметрия в Windows7↑. Обикновено опитните потребители преди криптирането провеждат тестове за производителност на хардуера. Например, в Aida64/Sysbench/systemd-analyze blame и сравняват с резултатите от същите тестове след криптиране на системата, опровергавайки за себе си мита, че "системното криптиране е вредно". Забавянето на машината и неудобството са осезаеми при резервно копиране/възстановяване на криптирани данни, защото самата операция по "системно резервно копиране на данни" не се измерва в мс, и се добавят именно онези <разшифроване/криптиране на летящо>. В крайна сметка всеки потребител, който има право да се занимава с криптография, установява баланс между алгоритъма за криптиране, удовлетворяването на поставените задачи, степента на собствената си параноя и удобството на ползването.

Параметърът PIM е най-добре да остане по подразбиране, за да не се въвеждат точни стойности на итерациите всеки път при зареждане на ОС. VeraCrypt прилага огромно количество итерации за създаване на наистина "бавен хеш". Атаката срещу такава "криптоуличка" чрез метод Brute force/радужни таблици има смисъл само при кратка "проста" паролна фраза и персонален charset списък на жертвата. Цената за устойчивост на паролата е забавянето при верно въвеждане на паролата при зареждане на ОС. (монтиране на томове VeraCrypt в GNU/Linux — значително по-бързо).
Свободен софтуер за реализиране на brute force атака. (извличане на паролната фраза от заглавката на диска VeraCrypt/LUKS). Hashcat. John the Ripper не може да "ламва Veracrypt", а при работа с LUKS не разбира криптографията Twofish.

Поради криптографската устойчивост на алгоритмите за криптиране, неуморимите шифропанкове разработват софтуер с друга векторна атака. Например, извличане на метаданни/ключове от ОЗУ. (атака с "студен ботуш"/прям достъп до паметта), съществува специализирано свободно и несвободно ПО за тези цели.

След завършване на конфигурацията/генерацията на "уникални метаданни" на криптирания активен дял, VeraCrypt ще предложи да рестартира компютъра и да тества работоспособността на своя бут loader. След reboot-а/старт на Windows, VeraCrypt ще се зареди в режим на изчакване, остава само да потвърдите процеса на криптиране — Y.

На финалната стъпка на системното криптиране VeraCrypt ще предложи да създадете резервно копие на заглавието на активния криптиран дял в форма на «veracrypt rescue disk.iso», което е задължително да бъде направено. в този софтуер такава операция е изискване. (в LUKS, като изискване – това е жалко, че е пропуснато, но е подчертано в документацията).. Спасителният диск ще бъде полезен на всички, а за някои и не само веднъж. Загубата (перезапис на заглавието/MBR) на резервното копие на заглавието завинаги ще лиши достъпа до декриптирания дял с OS Windows.

А4. Създаване на спасителен usb/диск VeraCryptПо подразбиране VeraCrypt предлага да запише «метаданни ~2-3мБ» на компактдиск, но не всички хора разполагат с дискове или DWD-ROM устройства, а създаването на стартираща флашка «VeraCrypt Rescue disk» за някого ще се окаже техническа изненада: Rufus/GUIdd-ROSA ImageWriter и друг подобен софтуер – няма да могат да се справят с поставената задача, тъй като освен копирането на изместените метаданни на стартиращата флашка, трябва да се направи копиране/поставяне извън файловата система на usb-накопителя, по-кратко, правилно да се копира MBR/пътя на ключа. От ОС GNU/Linux можете да създадете стартираща флашка, използвайки утилитата «dd», като следите тази таблица.

Създаването на спасителен диск в среда Windows е различно. Разработчикът VeraCrypt не е включил решение за този проблем в официалната документацията документация по «rescue disk», но предложи решение по друг начин: предостави допълнителен софтуер за създаване на «usb rescue disk» на своя форум VeraCrypt. Архиваторът на този софтуер за Windows – «създаване на usb veracrypt rescue disk». След запазването на rescue disk.iso ще започне процесът на блочно системно криптиране на активния дял. По време на криптирането работата на ОС не спира, не е необходимо рестартиране на PC. След завършване на криптирането, активният дял става напълно криптиран и може да се използва. Ако при стартиране на PC не се появява зареждачът на VeraCrypt, и операцията по възстановяване на заглавието не помага, проверете флага «boot», той трябва да бъде настроен на дяла, където е наличен Windows (независимо от криптирането и другите ОС, вижте таблица №1).
На това описание на блочно системно криптиране с OS Windows приключва.

[B] LUKS. Криптиране на GNU/Linux (~Debian) инсталирана ОС. Алгоритъм и Стъпки

За да се криптира инсталиран Debian/производен дистрибутив, е необходимо да се свърже подготвеният дял с виртуално блочно устройство, да се прехвърли на свързания диск GNU/Linux и да се инсталира/настрои GRUB2. Ако нямате гол сървър и цените времето си, трябва да използвате GUI, а повечето терминални команди, описани по-долу, се подразбира, че ще се изпълняват в „режима Чак-Норис“.

B1. Загрузка на ПК с live usb GNU/Linux

„Провеждане на криптотест за производителност на хардуера“

lscpu && cryptsetup benchmark

Ако сте щастлив притежател на мощен компютър с хардуерна поддръжка на AES, числата ще изглеждат като дясната част на терминала, а ако сте щастлив, но с античен хардуер — на лявата част.

B2. Разделяне на диска. Монтирование/форматирование на логическия дял HDD в Ext4 (Gparted)

B2.1. Създаване на криптиран заглавен дял sda7Ще описвам имената на дяловете, тук и по-нататък, съобразно с моята таблица на дяловете, публикувана по-горе. В зависимост от вашата структура на диска, трябва да въвеждате своите имена на дялове.

Създаване на свързване на криптирането на логическия диск (/dev/sda7 > /dev/mapper/sda7_crypt).
#Простое создание «LUKS-AES-XTS раздела»

cryptsetup -v -y luksFormat /dev/sda7

Опции:

* luksFormat - инициализация на заглавието LUKS;
* -y - паролна фраза (не ключ/файл);
* -v - вербализация (изход на информация в терминала);
* /dev/sda7 - вашият логически диск от разширения дял (там, където се планира прехвърляне/криптиране на GNU/Linux).

По подразбиране алгоритмът за криптиране <LUKS1: aes-xts-plain64, Ключ: 256 бита, хеширане на заглавието LUKS: sha256, RNG: /dev/urandom> (зависи от версията на cryptsetup).

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

При липса на хардуерна поддръжка на AES на CPU, най-добрият избор ще бъде създаването на разширен „LUKS-Twofish-XTS-дял“.

B2.2. Разширено създаване на „LUKS-Twofish-XTS-дял“

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

Опции:
* luksFormat - инициализация на заглавието LUKS;
* /dev/sda7 вашият бъдещ криптиран логически диск;
* -v вербализация;
* -y паролна фраза;
* -c избор на алгоритъм за криптиране на данни;
* -s размер на ключа за криптиране;
* -h алгоритъм за хеширане/криптографска функция, използваща ГСЧ (—use-urandom) за генериране на уникален ключ за криптиране/декриптиране на заглавието на логическия диск, вторичен ключ на заглавието (XTS); уникален главен ключ, съхранен в криптираното заглавие на диска, вторичен XTS ключ, всички тези метаданни и подпрограма за криптиране, която с помощта на главния ключ и вторичния XTS ключ криптира/декриптира всякакви данни на разреза. (освен заглавието на разреза) се съхраняват в ~3мБ на избрания разрез на харддиска.
* -i итерации в милисекунди, вместо „количеството“ (забавяне във времето при обработка на паролата, влияе на зареждането на ОС и криптографската устойчивост на ключовете). За запазване на баланса на криптографската устойчивост при проста парола от типа „russian“ е необходимо да се увеличи стойността на -(i), при сложна парола от типа „?8dƱob/øfh“ стойността може да се намалява.
* —use-urandom генератор на случайни числа, генерира ключове и сол.

След съпоставянето на разреза sda7 > sda7_crypt (операцията е бърза, тъй като се създава криптирано заглавие с метаданни ~3 мБ и това е всичко), трябва да се форматира и монтира файловата система sda7_crypt.

B2.3. Съответствието

cryptsetup open /dev/sda7 sda7_crypt
#изпълнението на тази команда изисква въвеждане на секретната парола.

опции:
* open -съответства на разреза "с име";
* /dev/sda7 -логически диск;
* sda7_crypt -съответствие на името, което се използва за монтиране на криптирания разрез или неговата инициализация при зареждане на ОС.

B2.4. Форматиране на файловата система sda7_crypt в ext4. Монтиране на диска в ОС(Забележка: в Gparted работа с криптирания разрез вече няма да е възможна)

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

опции:
* -v -вербализация;
* -L -етикет на диска (който се показва в файловия мениджър сред другите дискове).

Следва да се монтира виртуалното криптирано блочно устройство /dev/sda7_crypt в системата

mount /dev/mapper/sda7_crypt /mnt

Работата с файловете в папката /mnt ще доведе до автоматично криптиране/декриптиране на данните в sda7.

По-удобно е да се съответства и монтира разреза в файловия мениджър (nautilus/caja GUI), разрезът вече ще бъде в списъка с избор на дискове, остава единствено да се въведе паролата за отваряне/декриптиране на диска. Съответстващото име ще бъде избрано автоматично и няма да е „sda7_crypt“, а нещо от сорта на /dev/mapper/Luks-xx-xx…

B2.5. Резервно копие на заглавието на диска (метаданни ~3мБ)Една от най- важните операции, която е необходимо да се направи, без да се отлага — резервно копие на заглавието «sda7_crypt». Ако се презапише/повреди заглавието (например, инсталиране на GRUB2 в раздел sda7 и т.н.), криптираните данни ще бъдат загубени окончателно без възможност за възстановяване, тъй като не е възможно да се генерират отново идентични ключове, ключовете се създават уникални.

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

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

опции:
* luksHeaderBackup —header-backup-file - команда за резервно копие;
* luksHeaderRestore —header-backup-file - команда за възстановяване;
* ~\/Бэкап_DebSHIFR — файл за резервно копие;
* \/dev\/sda7 - раздел, чийто резервно копие на криптираното заглавие на диска трябва да се запази.
На тази стъпка <създаване и редактиране на криптиран раздел> приключи.

B3. Пренос на ОС GNU\/Linux (sda4) на криптиран раздел (sda7)

Създаваме папка \/mnt2 (Забележка — все още работим с live USB, в точка \/mnt е монтиран sda7_crypt), и монтираме нашето GNU\/Linux в \/mnt2, което трябва да бъде криптирано.

mkdir \/mnt2
mount \/dev\/sda4 \/mnt2

Извършваме коректен пренос на ОС с помощта на софтуер Rsync

rsync -avlxhHX --progress \/mnt2\/ \/mnt

Опциите на Rsync са описани в п.Е1.

По-нататък, необходимо да се проведе дефрагментация на раздела на логическия диск

e4defrag -c \/mnt\/ # след проверка, e4defrag ще покаже, че степента на дефрагментация на раздела ~"0", това е заблуждение, което може да ви струва съществена загуба на производителност!
e4defrag \/mnt\/ # провеждаме дефрагментация на криптираното GNU\/Linux

Взимайте за правило: да правите e4defrag на криптираното GNU\/Linux от време на време, ако имате HDD.
Преносът и синхронизацията [GNU\/Linux > GNU\/Linux-криптирано] на тази стъпка са завършени.

В4. Настройка на GNU\/Linux на криптирания раздел sda7

След успешния пренос на ОС \/dev\/sda4 > \/dev\/sda7 е необходимо да влезете в GNU\/Linux на криптирания раздел и да извършите допълнителни настройки (без да рестартирате компютъра) относно криптираната система. Тоест, да се намирате в live USB, но командите да се изпълняват «относно корена на криптираната ОС». Симулирането на подобна ситуация ще бъде «chroot». За да получавате информация за коя ОС в момента работите (криптирана или не, тъй като данните в sda4 и sda7 са синхронизирани), разсинхронизирайте ОС-ите. Създайте в кореновите директории (sda4\/sda7_crypt) празни файлове-маркери, например, \/mnt\/криптиранаОС и \/mnt2\/дешифриранаОС. Бърза проверка в коя ОС се намирате (включително и за бъдещето):

ls \/<Tab-Tab>

B4.1. «Симулация на вход в криптирана ОС»

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

B4.2. Проверка, че работата се извършва относно криптираната система

ls /mnt 
#и виждаме файла "/криптиранаОС"

history
#в изхода на терминала трябва да се появи история на командите su на работещата ОС.

B4.3. Създаване/настройка на криптиран swap, редактиране на crypttab/fstabТъй като файла за подкачка се форматира при всяко стартиране на ОС, няма смисъл да създаваме и свързваме swap с логическия диск в момента и да въвеждаме команди, както е в п.B2.2. За Swap при всяко стартиране ще се генерират автоматично свои времеви криптографски ключове. Жизненият цикъл на ключовете на swap: демонтиране/изключване на swap-раздела. (+изчистване на RAM); или рестартиране на ОС. Настройка на swap, отваряме файла, който отговаря за конфигурацията на блочните криптирани устройства (аналог на fstab файла, но отговарящ за крипто).

nano /etc/crypttab 

редактираме

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

Опции
* swap -сопоставеното име при криптиране /dev/mapper/swap.
* /dev/sda8 -използвайте вашия логически раздел за swap.
* /dev/urandom -генератор на случайни ключове за криптиране за swap (с всяко ново зареждане на ОС — създадени нови ключове). Генераторът /dev/urandom е по-малко случаен от /dev/random, все пак /dev/random се използва в опасни параноидни обстоятелства. При зареждане на ОС /dev/random забавя зареждането с няколко ± минути (вж. systemd-analyze).
* swap,cipher=twofish-xts-plain64,size=512,hash=sha512: -разделът знае, че е swap и се форматира «съответно»; алгоритъм на криптиране.

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

редактираме

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

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

Алтернативен криптиран swap
Ако по някакви причини не искате да отделяте цял дял за файла за подкачка, можете да последвате алтернативен и по-добър път: създаване на файл за подкачка в файл на криптирания дял с ОС.

fallocate -l 3G /swap #създаване на файл с размер 3Гб (почти мигновена операция)
chmod 600 /swap #настройка на правата
mkswap /swap #от файла създаваме файла за подкачка
swapon /swap #включваме нашия swap
free -m #проверяваме, че файлът за подкачка е активиран и работи
printf "/swap none swap sw 0 0" >> /etc/fstab #при необходимост след рестартиране swap ще бъде постоянен

Настройката на раздела за подкачка завърши.

B4.4. Настройка на криптирана GNU/Linux (редактиране на файловете crypttab/fstab)Файлът /etc/crypttab, както написах по-горе, описва криптираните блочни устройства, които се настройват по време на зареждане на системата.

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

ако сте свързали дяла sda7>sda7_crypt, както е в п.B2.1

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

ако сте свързали дяла sda7>sda7_crypt, както е в п.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

ако сте свързали дяла sda7>sda7_crypt, както е в п.B2.1 или B2.2, но не искате да въвеждате отново паролата за отключване и зареждане на ОС, можете вместо паролата да поставите секретен ключ/случаен файл

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

Описание
* none - указва, че при зареждане на ОС, за отключване на корена е необходимо да се въведе секретната парола.
* UUID - идентификаторът на дяла. За да разберете вашия идентификатор, наберете в терминала (напомняне, че през всичкото това време и по-нататък работите в терминала в среда chroot, а не в друг терминал live usb).

fdisk -l # проверка на всички дялове
blkid # трябва да бъде нещо подобно 

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

тази линия е видима при заявка blkid от терминала live usb, когато sda7_crypt е монтиран).
UUID вземате именно от вашето sdaX (не sdaX_crypt!, UUID sdaX_crypt – автоматично ще изчезне при генерирането на конфигурацията grub.cfg).
* cipher=twofish-xts-plain64,size=512,hash=sha512 - luks криптиране в разширен режим.
* /etc/skey - секретен файл-ключ, който автоматично се поставя за отключване на зареждането на ОС (вместо въвеждане на 3-та парола). Файлът може да бъде произволен до 8MB, но данните ще се четат <1MB.

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

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

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

Ще изглежда приблизително така:

(направете сами и сами ще видите).

cryptsetup luksKillSlot /dev/sda7 7 # изтриване на ключа/паролата от 7 слот

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

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

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

опция
* /dev/mapper/sda7_crypt - име на свързването sda7>sda7_crypt, което е посочено в файла /etc/crypttab.
Конфигурацията на crypttab/fstab приключи.

B4.5. Редактиране на конфигурационни файлове. Ключов моментB4.5.1. Редактиране на конфигурацията /etc/initramfs-tools/conf.d/resume

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

и коментирайте (ако съществува) строка «#» «resume». Файлът трябва да бъде напълно празен.

B4.5.2. Редактиране на конфигурацията /etc/initramfs-tools/conf.d/cryptsetup

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

трябва да отговаря на

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

B4.5.3. Редактиране на конфигурацията /etc/default/grub (точно този конфиг отговаря за способността да генерира grub.cfg при работа със зашифрени /boot)

nano /etc/default/grub

добавяме реда «GRUB_ENABLE_CRYPTODISK=y»
стойността ‘y’, grub-mkconfig и grub-install ще проверяват наличието на зашифрени дискове и генерират допълнителни команди, необходими за достъпа им по време на зареждане (insmod-ове ).
трябва да бъде нещо подобно

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. Редактиране на конфигурационния файл /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

Уверете се, че редът е коментиран .
В бъдеще (и дори вече сега, този параметър няма да има значение, но понякога пречи на обновяването на образа initrd.img).

B4.5.5. Редактиране на конфигурационния файл /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

добавяме

KEYFILE_PATTERN="/etc/skey"
UMASK=0077

Това ще опакова секретния ключ "skey" в initrd.img, ключът е необходим за отключването на корена при зареждане на ОС (ако не желаете да въвеждате паролата отново, автоматично се подставя ключът "skey").

B4.6. Обновление на /boot/initrd.img [версия]За да опаковате секретния ключ в initrd.img и да приложите корекциите в cryptsetup, обновете образа

update-initramfs -u -k all

при обновяване на initrd.img (както се казва "Възможно е, но не е сигурно") ще се появят предупреждения, свързани с cryptsetup, или например известие за загуба на Nvidia модули — това е нормално. След обновяване на файла, проверете, че той действително е обновен см. по времето (относно chroot среда./boot/initrd.img). Внимание! преди [update-initramfs -u -k all] задължително проверете, че cryptsetup open /dev/sda7 sda7_crypt — точно това име трябва да фигурира в /etc/crypttab, иначе след reboot ще получите грешка busybox)
На този етап конфигурацията на файловете завършва.

[С] Инсталация и настройка на GRUB2/Защита

C1. При необходимост форматирайте отделения дял за зареждача (на дяла е достатъчно поне 20MB)

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

C2. Монтиране на /dev/sda6 в /mntТака работим в chroot, то в корена няма да има директория /mnt2, а папката /mnt ще е празна.
монтираме дяла GRUB2

mount /dev/sda6 /mnt

Ако имате стари версии на GRUB2, в директорията /mnt/boot/grub/i386-pc (възможна е друга платформа, например, не "i386-pc") липсват криптомодули (накратко, в папката трябва да има модули, включително тези .mod: cryptodisk; luks; gcry_twofish; gcry_sha512; signature_test.mod), в такъв случай GRUB2 трябва да се обнови.

apt-get update
apt-get install grub2 

Важно! По време на обновяването на пакета GRUB2 от репозитория, на въпроса "за избор" в кое място да се инсталира зареждача – трябва да се откаже от инсталацията (причина — опит за инсталация на GRUB2 — в "MBR" или на live usb)В противен случай ще повредите заглавието/зареждача на VeraCrypt. След актуализация на пакетите GRUB2 и деинсталиране, зареждача трябва да бъде инсталиран ръчно на логическия диск, а не в «MBR». Ако в хранилището ви има остаряла версия на GRUB2, опитайте да го актуализирате от официалния сайт – не съм проверявал (работил съм със свежи зареждачи GRUB 2.02 ~BetaX).

C3. Инсталиране на GRUB2 в разширения дял [sda6]Трябва да имате монтиран дял [п.С.2]

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

опции
* —force - инсталиране на зареждача, подминавайки всички предупреждения, които почти винаги съществуват и блокират инсталацията (задължителен флаг).
* —root-directory - задаване на директорията в корена на sda6.
* /dev/sda6 - вашият sdaХ дял (не пропускайте между /mnt /dev/sda6).

C4. Създаване на конфигурационен файл [grub.cfg]Забравете за командата «update-grub2» и използвайте пълна команда за генериране на конфигурационен файл

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

след завършване на генерирането/актуализацията на файла grub.cfg, в терминала трябва да се появят редове с намерените ОС на диска («grub-mkconfig» може да намери и подхване ОС с live usb, ако имате мултизареждаща флашка с Windows 10 и множество живи дистрибуции — това е нормално). Ако терминалът е «празен», файлът «grub.cfg» не е генериран, то това е именно случаят, когато в системата има бъгове на GRUB (и вероятно зареждача е от тестовата версия на хранилището), преинсталирайте GRUB2 от надеждни източници.
Инсталирането на «простата конфигурация» и настройването на GRUB2 е завършено.

C5. Проверка на криптирана ОС GNU/LinuxКоректно завършваме криптомисията. Внимателно напускане на криптираната GNU/Linux (изход от среда chroot).

umount -a # размонтиране на всички монтирани дялове на криптираната GNU/Linux
Ctrl+d # изход от среда chroot
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount -a # размонтиране на всички монтирани дялове на live usb
reboot

След перезареждане на ПК, зареждача VeraCrypt трябва да се стартира.


* Въвеждане на паролата за активния дял – започва зареждането на ОС Windows.
* Натискането на клавиша «Esc» ще предаде управлението на GRUB2, при избора на криптирана GNU/Linux – ще е необходима парола (sda7_crypt) за отключване на /boot/initrd.img (ако grub2 пише, че uuid «не е намерен» – това е проблем на зареждача grub2, той трябва да бъде преинсталиран, например, от тестовата версия/стабилен и пд).


*В зависимост от начина, по който сте настроили системата (вж. п. B4.4/4.5) след успешно въвеждане на паролата за отключване на образа /boot/initrd.img, ще е необходима парола за стартиране на ядрото/корена на ОС, или автоматично ще се подстави секретният ключ «skey», освобождавайки от повторно въвеждане на паролата.

(снимка «автоматично подставяне на секретния ключ»).

*Следва познатият процес на зареждане на GNU/Linux с удостоверяване на потребителския акаунт.


*След удостоверяване на потребителя и влизане в ОС, трябва да актуализирате отново /boot/initrd.img (вж. В4.6).

update-initramfs -u -k all

А в случай на излишни редове в менюто GRUB2 (от подхващане на ОС с live usb) да се избавите от тях

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

Кратък итог по системното шифроване на GNU/Linux:

• GNU/Linux е напълно шифрован, включително /boot/kernel и initrd;
• секретният ключ е опакован в initrd.img;
• текущата схема на удостоверяване (въвеждане на паролата за отключване на initrd; парола/ключ за стартиране на ОС; парола за удостоверяване на потребителския акаунт на Linux).

«Проста конфигурация GRUB2» системното шифроване на блочен дял е завършено.

С6. Разширена настройка на GRUB2. Защита на зареждача с цифров подпис + защита с удостоверяванеGNU/Linux е напълно шифрован, но зареждача не може да се шифрова – това условие е продиктувано от BIOS. Поради тази причина верижното шифровано зареждане на GRUB2 е невъзможно, но е възможно/достъпно простото верижно зареждане, от гледна точка на защитата – не е необходимо [вж. П. F].
За «уязвимия» GRUB2 разработчиците са реализирали алгоритъм за защита на зареждача с «подпис/удостоверяване».

• При защита на зареждача «със собствен цифров подпис» външната модификация на файловете или опитът за зареждане на допълнителни модули в този зареждач ще доведе до блокиране на процеса на зареждане.
• При защита на зареждача с удостоверяване за избор на зареждане на определен дистрибутив или въвеждане на допълнителни команди в CLI, ще е необходимо да се въведе потребителското име и парола на суперпотребителя-GRUB2.

С6.1. Защита на зареждача с удостоверяванеУверете се, че работите в терминала на шифрованата ОС

ls / #открийте файл-маркер

създайте парола за суперпотребителя за удостоверяване в GRUB2

grub-mkpasswd-pbkdf2 #въведете/повторете паролата на суперпотребителя. 

Получете хеш на паролата. Нещо като това

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

монтирайте раздел GRUB

mount /dev/sda6 /mnt 

редактирайте конфиг

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

проверете в файла, че във «grub.cfg» няма флагове (» —unrestricted» «—user»)
добавете в края (преди реда ### END /etc/grub.d/41_custom ###)
«set superusers=»root»
password_pbkdf2 root хеш».

Трябва да изглежда по този начин

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

Ако често използвате командата «grub-mkconfig -o /mnt/boot/grub/grub.cfg» и не искате да правите промени в grub.cfg всеки път, добавете гореспоменатите редове (логин/парола) в потребителския скрипт на GRUB най-долу

nano /etc/grub.d/41_custom 

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

При генерирането на конфига «grub-mkconfig -o /mnt/boot/grub/grub.cfg», редовете, отговорни за удостоверяването, ще се добавят автоматично в grub.cfg.
На тази стъпка настройката на удостоверяването в GRUB2 е завършена.

С6.2. Защита на зареждача с цифров подписПредполага се, че вече имате вашия личен pgp-ключ за шифроване (или създайте такъв ключ). В системата трябва да бъде инсталирано криптографско ПО: gnuPG; kleopatra/GPA; Seahorse. Крипто-ПО значително ще улесни живота ви в подобни случаи. Seahorse — стабилна версия на пакета 3.14.0 (по-високите версии, например, V3.20 – са непълноценни и имат съществени бъгове).

PGP-ключът трябва да бъде генериран/стартиран/добавен само в среда su!

Генерирайте персонален шифровален ключ

gpg --gen-key

Изнесете ключа си

gpg --export -o ~/perskey

Монтирайте логическия диск в ОС, ако все още не е монтиран

mount /dev/sda6 /mnt #sda6 – раздел GRUB2

изчистете раздела GRUB2

rm -rf /mnt/

Инсталирайте GRUB2 в sda6, поставяйки личния си ключ в основния образ на GRUB «core.img»

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

опции
* —force - инсталация на зареждача, пропускаща всички предупреждения, които винаги съществуват (задължителен флаг).
* —modules=«gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa» - инструктира GRUB2 да предварително зареди необходимите модули при стартиране на ПК.
* -k ~/perskey - път до «PGP-ключа» (след като ключът е опакован в образа, може да бъде изтрит).
* —root-directory - инсталиране на каталога boot в корена на sda6
/dev/sda6 -ваш sdaХ раздел.

Генерираме/обновяваме grub.cfg

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

Добавяме в края на файла «grub.cfg» реда «trust /boot/grub/perskey» (незабавно да използвате pgp-ключ.) Тъй като инсталирахме GRUB2 с набор от модули, включително модула за подписване «signature_test.mod», това освобождава от добавянето в конфигурацията на команди като «set check_signatures=enforce».

Трябва да изглежда приблизително така (крайни редове в файла 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 ###
#

Пътят към «/boot/grub/perskey» не е необходимо да бъде посочен на конкретен раздел на диска, например hd0,6, за самия загрузчик «коренът» е по подразбиране пътят на раздела, на който е инсталиран GRUB2. (вж. set rot=..).

Подписваме GRUB2 (всички файлове във всички директории /GRUB) с нашия ключ «perskey».
Просто решение за подписване (за файловия мениджър nautilus/caja): инсталираме от репозитория разширението «seahorse» за файловия мениджър. Ключът ви трябва да бъде добавен в средата на su.
Отваряте файловия мениджър с sudo «/mnt/boot» – десен клик – подписване. На екрана го виждате така

Самият ключ «/mnt/boot/grub/perskey» (да се копира в каталога grub) също трябва да бъде подписан със собствената си подпись. Проверете, че в каталога/подкаталозите са се появили подписи на файловете [*.sig].
С горепосочения начин подписваме «/boot» (нашите kernel, initrd). Ако времето ви струва нещо, този метод спестява написването на bash-скрипт за подписване на «множество файлове».

За да премахнете всички подписи на загрузчика (ако нещо е тръгнало не така)

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

За да не подписвате загрузчика след обновление на системата, замразявате всички пакети за обновление, свързани с GRUB2.

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

На тази стъпка разширената настройка на GRUB2 е завършена.

C6.3. Испитване на загрузчика GRUB2, защитен с цифрова подписка и автентикацияGRUB2. При избор на определен дистрибутив GNU/Linux или вход в CLI (командния ред) е необходима авторизация на суперпотребителя. След въвеждане на правилно потребителско име/парола ще трябва паролата от initrd.

Скрин, успешна автентикация на суперпотребителя GRUB2.

Ако се подправи някой от файловете GRUB2/направи промени в grub.cfg, или се изтрие файл/подпис, да се зареди злонамерен модул.mod, ще се появи съответното предупреждение. Зареждането на GRUB2 ще бъде спряно.

Скрин, опит за намеса в GRUB2 «отвън».

При «нормално» зареждане «без намеса», системният статус на изходния код е «0». Затова не е известно дали защитата работи или не. (тоест «с защита на зареждача с подпис или без него» при нормално зареждане статусът е един и същ «0» — това е лошо).

Как да проверим защитата с цифров подпис?

Непрактичен начин за проверка: фалшифициране/изтриване на използвания GRUB2 модул, например, изтриване на подписа на luks.mod.sig и получаване на грешка.

Правилният начин: влезте в CLI на зареждача и напишете командата

trust_list

В отговор трябва да получите отпечатък «perskey», ако статусът е «0», значи защитата с подпис не работи, проверете отново п.C6.2.
На тази стъпка разширената настройка за «Защита на GRUB2 с цифров подпис и аутентификация» е завършена.

С7 Алтернативен метод за защита на зареждача GRUB2 чрез хеширане.Описаният по-горе метод «Защита на зареждача ЦП/Аутентификация» е класика. Поради несъвършенството на GRUB2, в параноидни условия той е подложен на реална атака, която ще приведя по-долу в п.[F]. Освен това, след обновяване на ОС/ядрото е необходимо да се преподпише зареждача.

Защита на зареждача GRUB2 чрез хеширане.

Предимства пред класиката:

• По-високо ниво на надеждност. (хеширането/проверка преминава само с криптиран локален ресурс. Контролира се целият раздел, отреден за GRUB2, за всякакви промени, а всичко останало е криптирано, в класическата схема с защита на зареждача ЦП/Аутентификация се контролират само файловете, но не свободното пространство, в което «нещо зловещо» може да бъде добавено).
• Криптирано логиране. (в схемата се добавя четим личен криптиран лог).
• Скорост (защитата/проверка на целия раздел, отреден под GRUB2, протича практически незабавно).
• Автоматизация на всички криптографски процеси.

Недостатъци на класиката.

• Фалшифициране на подпис. (теоретично, възможно е намиране на зададена колизия на хеш функция).
• Повишено ниво на сложност. (в сравнение с класиката, изисква се малко повече умения в ОС GNU/Linux).

Как работи идеята с хеширането на GRUB2/раздела.

Раздел GRUB2 „Подписывается“, при загрузке ОС происходит проверка неизменности раздела загрузчика с последующим логированием в безопасной среде (зашифрованной). В случае компрометации загрузчика или его раздела, в дополнение к логу вторжения запускается такая

Штука.

Четыре раза в день происходит аналогичная проверка, которая не нагружает ресурсы системы.
С помощью команды „-$ проверка_GRUB“ происходит мгновенная проверка в любой момент времени без логирования, но с выводом информации в CLI.
С помощью команды „-$ sudo подпись_GRUB“ происходит мгновенное переподписание загрузчика GRUB2/раздела и его обновленное логирование (необходимо после обновления ОС/boot), и жизнь продолжается дальше.

Реализация метода хэширования загрузчика и его раздела

0) Подпишем загрузчик/раздел GRUB, предварительно смонтировав его в /media/username

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

1) Создаем скрипт без расширения в корне зашифрованной ОС ~/podpis, применяем к нему нужные права 744 секьюрити и защита от „дурака“.

Наполняем его содержимое

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

Запускаем скрипт от su, произойдет проверка хэширования раздела GRUB и его загрузчика, save лог.

Создадим или скопируем, например, „вредоносный файл“ [virus.mod] в раздел GRUB2 и запустим временную проверку/тестирования:

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

В CLI должны увидеть вторжение в нашу -цитадель-#Урезанный лог в CLI

Ср янв  2 11::41 MSK 2020
/media/username/GRUB/boot/grub/virus.mod: Мoved from /media/username/GRUB/1nononoshifr
/media/username/GRUB/boot/grub/i386-pc/mda_text.mod: Ok
/media/username/GRUB/boot/grub/grub.cfg: Ok
hashdeep: Audit failed
   Input files examined: 0
  Known files expecting: 0
          Files matched: 325
Files partially matched: 0
            Files moved: 1
        New files found: 0
  Known files not found: 0

#как видим появилось «Files moved: 1 и Audit failed» означает, что проверка не прошла.
Из-за особенностей тестируемого раздела вместо „New files found“ > „Files moved“

2) Кладём гифку сюда > ~/warning.gif, задаем права 744.

3) Настраиваем fstab на автомонтирование раздела GRUB при загрузке

-$ sudo nano /etc/fstab

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

4) Проводим ротацию лога

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

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

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

5) Добавляем задание в cron

-$ sudo crontab -e

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

6) Создаем постоянные алиасы

-$ 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

После обновления ОС -$ apt-get upgrade переподписываем наш раздел GRUB
-$ подпись_GRUB
На този етап защитата чрез хеширане на GRUB раздела е завършена.

[D] Почистване — унищожаване на нешифровани данни

Изтрийте личните си файлове толкова напълно, че „дори Бог не може да ги прочете“, според представителя на Южна Каролина Трей Гауди.

Както обикновено, съществуват различни „митове и легенди“, относно възстановяването на данни след изтриването им от хард диск. Ако вярвате в киберколдовство или сте член на общността на Dr Web и никога не сте опитвали възстановяване на данни след тяхното изтриване/преписване (например, възстановяване с R-studio), тогава предложеното решение едва ли ще ви подхожда, ползвайте това, което ви е по-близо.

След успешното прехвърляне на GNU/Linux на криптирания раздел, старата копия трябва да бъде изтрита без възможност за възстановяване на данни. Универсален метод за почистване: софтуер за Windows/Linux свободно GUI ПО BleachBit.
Бързо форматираме раздела, данните на който трябва да бъдат унищожени (с помощта на Gparted), стартираме BleachBit, избираме „Почистване на свободното пространство“ – избираме раздела (вашето sdaX с предишната копия на GNU/Linux), ще стартира процеса на почистване. BleachBit – изтрива диска в един проход – това е, което „ни трябва“, Но! така работи само в теорията, ако форматирате диска и чистите в BB v2.0.

Внимание! BB изтрива диска, оставяйки метаданни, имената на файловете при ликвидацията на данните се запазват (Ccleaner — не оставя метаданни).

И митът за възможността за възстановяване на данни не е съвсем мит.Bleachbit V2.0-2 бивш пакет unstable OS Debian (и всякакъв друг подобен софтуер: sfill; wipe-Nautilus - също са забелязвани в това грозно дело) в действителност имаше критичен проблем: функцията „почистване на свободно пространство“ работи неправилно на HDD/флашки (ntfs/ext4). Софтуер от този тип при почистване на свободното място презаписва не целия диск, както много потребители си мислят. И някои (много) изтрити данни ОС/софт считат тези данни за неизтрити/потребителски и при почистване на „ОСП“ пропускат тези файлове. Проблемът е, че след такова, дълго по време, почистване на диска „изтритите файлове“ могат да бъдат възстановени дори след 3+ прохода почистване на диска.
На GNU/Linux в Bleachbit 2.0-2 надеждно работят функциите за безвъзвратно изтриване на файлове и каталог, но не и почистването на свободното пространство. За сравнение: в Windows в софтуера CCleaner функцията „ОСП за ntfs“ работи правилно и Бог наистина не може да прочете изтритите данни.

И така, за да изтриете основно „компрометиращи“ стари нешифровани данни, необходим е директен достъп на Bleachbit до тези данни, след това, да се възползвате от функцията „безвъзвратно изтриване на файлове/каталози“.
За изтриване на „изтритите файлове със стандартните средства на ОС“ в Windows използвайте CCleaner/BB с функцията „ОСП“. В GNU/Linux трябва (изтриване на изтритите файлове) да получите практика сами (изтриване на данни+самостоятелна опит за възстановяване и не трябва да разчитате на версията на софтуера (ако не е уязвимост, то е бъг)), само в такъв случай ще можете да разберете механизма на този проблем и окончателно да се отървете от изтритите данни.

Bleachbit v3.0 не е тестван, възможно е проблемът вече да е поправен.
Bleachbit v2.0 работи честно.

На тази стъпка „изчистването на диска“ е завършено.

[E] Универсално архивиране на шифровани ОС

Всеки потребител има свой метод за архивиране на данни, но шифрованите данни на „Системните ОС“ изискват малко по-различен подход към задачата. Уеднаквено ПО, като например „Clonezilla“ и подобен софтуер, не могат да работят директно с шифровани данни.

Формулиране на задача за архивиране на шифровани блочни устройства:

1. универсалност — един и същи алгоритъм/ПО за архивиране за Windows/Linux;
2. възможност за работа в конзолата с всяка live usb GNU/Linux без необходимост от допълнително изтегляне на софтуер (но все пак препоръчвам GUI);
3. сигурност на архивите — съхраняваните „образи“ трябва да бъдат шифровани/с парола;
4. размерът на шифрованите данни трябва да отговаря на размера на реално копираните данни;
5. удобно извличане на необходимите файлове от архив (липса на изискване първо да се дешифрира целият дял).

Например, архивиране/възстановяване чрез утилитата „dd“

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

Отговаря почти на всичките условия на поставената задача, но по точка 4 не издържа на критика, тъй като копира целия раздел на диска, включително и свободното пространство — не е интересно.

Например, резервната копия на GNU/Linux чрез архиватор [tar» | gpg] е удобна, но за бекап на Windows трябва да се търси друго решение — не е интересно.

E1. Универсално резервно копиране на Windows/Linux. Връзка rsync (Grsync)+VeraCrypt том.Алгоритъм за създаване на резервна копия:

1. създаване на криптиран контейнер (том/файл) VeraCrypt за ОС;
2. пренос/синхронизация на ОС с помощта на софтуер Rsync в криптоконтейнера VeraCrypt;
3. при необходимост зареждане на тома VeraCrypt в www.

Създаването на криптиран контейнер VeraCrypt има свои особености:
създаване на динамичен том (създаването на ДТ е достъпно само в Windows, но може да се използва и в GNU/Linux);
създаване на обикновен том, но съществува изискване с "параноиден характер" (по думите на разработчика) – форматиране на контейнера.

Динамичният том се създава практически мигновено в ОС Windows, но при копиране на данни от ОС GNU/Linux > VeraCrypt ДТ, производителността на операцията за резервно копиране значително спада.

Обикновен том Twofish с 70 Гб се създава (да кажем, на средноголям компютър) на HDD ~ за половин час (презаписване на предишни данни в контейнера в един проход, поради изисквания за сигурност). От VeraCrypt Windows/Linux е премахната функцията за бързо форматиране на тома при създаването му, затова създаването на контейнера е възможно само чрез "презапис в един проход" или създаването на слабо производителен динамичен том.

Създаваме обикновен том VeraCrypt (не динамичен/ntfs), не би трябвало да възникнат проблеми.

Настройваме/създаваме/откриваме контейнера в VeraCrypt GUI> GNU/Linux live usb (томът ще бъде автоматично монтиран в /media/veracrypt2, томът на ОС Windows е монтиран в /media/veracrypt1). Създаваме криптирана резервна копия на ОС Windows с помощта на GUI rsync (grsync), отбелязвайки отметките.

Изчакваме завършването на процеса. След приключване на резервното копиране, ще имаме един криптиран файл.

По същия начин създаваме резервна копия на ОС GNU/Linux, като махнем отметката в GUI rsync "съвместимост с Windows".

Внимание! контейнерът Veracrypt за "бекап на GNU/Linux" трябва да бъде създаден в файловата система ext4. Ако направите бекап в контейнер ntfs, при възстановяване на такова копие ще загубите всички права/групи на всички ваши данни.

Все операции могат да бъдат извършвани и в терминала. Основни опции за rsync:
* -g - запази групите;
* -P — progress — статус на времето за работа с файл;
* -H - копирайте хардлинкове, както са;
* -а - архивен режим (няколко флага rlptgoD);
* -v - вербализация.

Ако искате да монтирате “Windows VeraCrypt том” чрез конзолата в софтуера cryptsetup, може да създадете 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

Сега с командата “veramount pictures” ще се появи запитване за въвеждане на паролата, и в ОС ще бъде монтиран криптирания системен том Windows.

Команда за свързване/монтиране на системен том VeraCrypt в cryptsetup

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

Команда за свързване/монтиране на дял/контейнер VeraCrypt в cryptsetup

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

Вместо alias добавяме (скрипт за автозапуск) системен том с ОС Windows и логически криптиран диск ntfs в автозапуск GNU/Linux

Създаваме скрипт и го запазваме в ~/VeraOpen.sh

printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sda3 Windows_crypt && mount /dev/mapper/Windows_crypt /media/Winda7 # декодираме паролата от base64 (bob) и я изпращаме на запитването за въвеждане на парола при монтиране на системния диск на ОС Windows.
printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --type tcrypt /dev/sda1 ntfscrypt && mount /dev/mapper/ntfscrypt /media/КонтейнерНтфс # аналогично, но монтираме логически диск ntfs.

Разпределяме "правилни" права:

sudo chmod 100 /VeraOpen.sh

Създаваме два еднакви файла (със същото име!) в /etc/rc.local и ~/etc/init.d/rc.local
Запълваме файловете

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

Разпределяме "правилни" права:

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

Всичко, сега при стартиране на GNU/Linux не е нужно да въвеждаме пароли за монтиране на криптирани дискове ntfs, дисковете се монтират автоматично.

Забележка накратко относно това, което е описано по-горе в п. E1 стъпка по стъпка (но сега за ОС GNU/Linux)
1) Създайте том в fs ext4 > 4gb (за файл) Linux в Veracrypt [Криптоящик].
2) Рестартирайте в live usb.
3) ~$ cryptsetup open /dev/sda7 Lunux # свързване на криптирания дял.
4) ~$ mount /dev/mapper/Linux /mnt # монтиране на криптирания дял в /mnt.
5) ~$ mkdir mnt2 # създаване на каталог за бъдещ бекъп.
6) ~$ cryptsetup open --veracrypt --type tcrypt ~/Криптоящик Криптоящик && mount /dev/mapper/Криптоящик /mnt2 # Свързване на тома VeraCrypt с името "Криптоящик" и монтиране на Криптоящика в /mnt2.
7) ~$ rsync -avlxhHX --progress /mnt /mnt2/ # операция за резервно копиране на криптирания дял в криптирания том VeraCrypt.

(p/s/ Внимание! Ако прехвърляте криптирана GNU/Linux от една архитектура/машина на друга, например, Intel > AMD (т.е. разгръщате backup от един криптиран дял на друг криптиран дял Intel > AMD), не забравяйте след прехвърлянето на криптираната ОС да промените секретния подставящ ключ вместо паролата, т.к. предишният ключ ~ /etc/skey – вече няма да подхожда на друг криптиран дял, а новият ключ „cryptsetup luksAddKey“ не е желателно да се създава от chroot – възможен е глюк, просто в ~ /etc/crypttab посочете вместо „/etc/skey“ временно „none“, след rebot-а и влизане в ОС отново създайте своя секретен подставящ ключ.

Като ветерани в ИТ, не забравяйте отделно да правите backup на заглавията на криптираните дялове на ОС Windows/Linux, или криптирането ще се обърне против вас самите.
На този етап резервното копиране на криптираните ОС е завършено.

[F] Атака на GRUB2 bootloader

ПодробностиАко сте защитили своя bootloader с цифров подпис и/или аутентификация (вижте п.C6.), то от физически достъп това по никакъв начин не защитава. Криптираните данни ще останат недостъпни, но заобикалянето на защитата (нулиране на защита на цифровия подпис) GRUB2 позволява на кибер злодея да внедри своя код в bootloader, без да подозира. (освен ако потребителят ръчно не следи състоянието на bootloader-а или не измисли свой здрав произволен-скрипт-код за grub.cfg).

Алгоритъм на атаката. Злоумишленикът

* Зарежда ПК с live USB. Всяка промяна (от нарушителя) на файловете ще доведе до уведомление на реалния собственик на ПК за опит за нахлуване в bootloader. Но просто преинсталиране на GRUB2 със запазване на grub.cfg (и последваща възможност за редактиране) ще позволи на злоумишленика да редактира всякакви файлове (при такава ситуация, при зареждане на GRUB2, уведомление на реалния потребител няма да последва. Статусът остава същият )
* Монтирува незакрит дял, запазва у себе си „/mnt/boot/grub/grub.cfg“.
* Премахва bootloader-а (изключвайки „perskey“ от образа core.img)

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

* Връща „grub.cfg“ > „/mnt/boot/grub/grub.cfg“, при необходимост го редактира, например, добавяйки своя модул „keylogger.mod“ в папката с модулите на bootloader-а, в „grub.cfg“ > ред „insmod keylogger“. Или, например, ако врагът е коварен, след преинсталирането на GRUB2 (всички подписи остават на място) Той събира основния образ на GRUB2, използвайки «grub-mkimage с опция (-с).» Опцията «-с» позволява да заредите своя конфигурационен файл преди зареждането на основния «grub.cfg». Конфигурацията може да се състои само от един ред: пренасочване към всеки «modern.cfg», смесен, например, с около 400 файла (модули+подписи) в папката «/boot/grub/i386-pc». При това атакуващият може да внася произволен код и да зарежда модули, без да засяга «/boot/grub/grub.cfg», дори ако потребителят е приложил «hashsum» към файла и временно го е извел на екран.
На нападателя не му е нужно да хаква логин/парола на суперпотребителя GRUB2, просто трябва да копира редовете (отговарящи за аутентификацията) «/boot/grub/grub.cfg» в своя «modern.cfg»

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

И за собственика на ПК все още ще важи проверката за автентичност на суперпотребителя GRUB2.

Цепочна зареждане (резултатът от зареждача зарежда друг зареждач), както писах по-горе, няма смисъл (тя е предназначена за друга цел). Поради BIOS не може да се зареди криптиран зареждач (при цепочна зареждане се извършва рестартиране GRUB2 > криптиран GRUB2, грешка!). Но ако все пак се възползвате от идеята за цепочно зареждане, можете да сте сигурни, че се зарежда точно криптираният (не модернизиран) «grub.cfg» от криптираната секция. И това също е фалшиво чувство за безопасност, защото всичко, което е посочено в криптирания «grub.cfg» (зареждане на модули) се комбинира с модулите, които се зареждат от незашифрован GRUB2.

Ако искате да проверите това, отделете/криптирайте още една секция sdaY, копирайте GRUB2 върху нея (операция grub-install на криптирана секция е невъзможна) и в «grub.cfg» (незашифрована конфигурация) променете редовете, подобни на тези

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
}

редове
* insmod - зареждане на необходимите модули за работа с криптирания диск;
* GRUBx2 - название на изведената линия в меню на зареждане GRUB2;
* cryptomount -u 15c47d1c4bd34e5289df77bcf60ee838 - вижте fdisk -l (sda9);
* set root - задаване на корен;
* normal /boot/grub/grub.cfg - изпълняем файл на конфигурация на криптирана секция.

Увереността, че се зарежда именно криптирания "grub.cfg" е положителен отговор на въвеждането на паролата/разблокирането на "sdaY" при избиране на реда "GRUBx2" в менюто на GRUB.

При работа в CLI, за да не се обърквате (и да проверите дали е сработила променливата "set root"), създайте празни файл-маркери, например в криптираното разделение "\/shifr_grub", в некриптираното разделение "\/noshifr_grub". Проверка в CLI

cat \/Tab-Tab

Както беше отбелязано по-горе, това няма да помогне срещу зареждането на злонамерени модули, ако такива модули се окажат на вашия ПК. Например, кейлоггер, който може да записва натисканията на клавишите във файл и да се смесва с други файлове в "~\/i386", докато нападателят го изтегли с физически достъп до ПК.

Най-простият начин да проверите, че защитата на цифровия подпис активно работи (не е нулирана), и никой не е нахлул в зареждача, в CLI въвеждаме команда

list_trusted

в отговор получаваме отпечатък на нашия "perskey", или нищо не получаваме, ако сме нападнати (също е необходимо да проверите "set check_signatures=enforce").
Същественият минус на този подход е, че трябва да въвеждате командите ръчно. Ако добавите тази команда в "grub.cfg" и защитите конфигурацията с цифров подпис, предварителният извеждане на отпечатъка на ключа на екрана е твърде кратък по тайминг и можете да не успеете да видите извода, получавайки зареждане на GRUB2.
Няма към кого конкретно да предявявате претенции: разработчикът в своя документацията п.18.2 официално заявява

"Обърнете внимание, че дори с паролна защита на GRUB, GRUB сам по себе си не може да предотврати някой с физически достъп до машината да променя конфигурацията на фърмуера (например Coreboot или BIOS), за да накара машината да се зареди от друго (контролирано от нападателя) устройство. GRUB във всеки случай е само една връзка в безопасната верига за зареждане."

GRUB2 е твърде пренаситен с функции, които могат да придадат усещане за фалшива сигурност, а развитието му вече надминава функционалността на операционната система MS-DOS, а в крайна сметка това е само зареждач. Забавно е, че GRUB2 утре може да стане операционна система, а зарежданите GNU\/Linux виртуални машини за него.

Небольшой видеоролик, в котором я сбросил защиту цифровой подписью GRUB2 и сообщил о своем вмешательстве реальному пользователю (напугал, а вместо того, что показано на ролике – можно написать не безобидный произвольный код\/ .mod).

Изводи:

1) Блоково системно криптиране за Windows – по-лесно е да се реализира, а защита с една парола е по-удобна, отколкото защитата с множество пароли при блоково системно криптиране на GNU\/Linux, справедливост е: последното е автоматизирано.

2) Статията е написана като релевантно, подробно просто ръководство за пълно дискодно криптиране VeraCrypt/LUKS на един домашен компютър, което в момента е най-доброто в руската интернет среда (IMHO). В ръководството има > 50к знака, затова не са разгледани някои интересни глави: за криптографите, които изчезват/остават в сянка; за това, че в различни книги за GNU/Linux малко/не пишат за криптография; за чл. 51 от Конституцията на Руската федерация; за лицензиране/запрете на криптирането в РУ, защо е необходимо да криптирате "root/boot". Ръководството е и без това значително, но подробно (описващо дори простите стъпки), и в случая това ще ви спести много време, когато се заемете с "истинското криптиране."

3) Пълното дискодно криптиране проведох на Windows 7 64; GNU/Linux Parrot 4x; GNU/Debian 9.0/9.5.

4) Извърших успешна атака на моя загрузчик GRUB2.

5) Уроците са създадени, за да помогнат на всички параноици от СНГ, където работата с криптиране е разрешена на законодателно ниво. И на първо място за тези, които желаят да внедрят пълно дискодно криптиране, без да изтриват своите настроени системи.

6) Преработих и актуализирах моето ръководство, което е актуално през 2020 година.

[G] Полезна документация

1. Ръководство за потребителя TrueCrypt (февруари 2012 RU)
2. Документация за VeraCrypt
3. /usr/share/doc/cryptsetup(-run) [локальный ресурс] (официална подробна документация за настройка на криптиране в GNU/Linux с помощта на cryptsetup)
4. Официален FAQ cryptsetup (кратка документация за настройка на криптиране в GNU/Linux с помощта на cryptsetup)
5. Криптиране на устройство LUKS (документация от archlinux)
6. Подробно описание на синтаксиса на cryptsetup (страница на ръководството arch)
7. Подробно описание на crypttab (страница на ръководството arch)
8. Официалната документация за GRUB2.

Тагове: пълно криптиране на диска, криптиране на дял, пълно дискодно криптиране Linux, пълно системно криптиране LUKS1.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.

Криптирате ли?

• 17,1%Криптирам всичко, което е възможно. Имам параноя.14

• 34,2%Криптирам само важни данни.28

• 14,6%Понякога криптирам, понякога забравям.12

• 34,2%Не, не криптирам, неудобно е и изисква разходи.28

Гласували 82 потребители. Въздържаха се 22 потребители.

Източник: habr.com