Полнодисковое шифрование Windows Linux установленных систем. Зашифрованная мультизагрузка

Загрузка с официального сайта, либо с зеркала 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.

Если отклониться от вышеописанных шагов (схемы блочного системного шифрования), то VeraCrypt выкатит предупреждение и не позволит шифровать раздел.

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

VeraCrypt поддерживает возможность криптовать диски каскадом AES(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (без аппаратной поддержки AES, шифрование каскадом А/Т) снижение производительности в сущности незаметное. (у CPU AMD той же эпохи/~параметров —производительность немного снижена). ОС работает в динамике и потребление ресурсов на прозрачное шифрование – незаметное. В отличие, как например, заметное снижение производительности из-за установленного тестового нестабильного desktop environment 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 предложит перезагрузить ПК и протестировать работоспособность своего загрузчика. После reboot-а/старта Windows, VeraCrypt подгрузится в режиме ожидания, останется лишь подтвердить процесс шифрования — Y.

На финальном шаге системного шифрования VeraCrypt предложит создать резервную копию заголовка активного зашифрованного раздела в виде «veracrypt rescue disk.iso» — сделать нужно обязательно — в этом софте такая операция является требованием (в LUKS, как требование – это к сожалению, опущено, но подчеркнуто в документации). Rescue disk пригодится всем, а кому-то и не один раз. Утеря (перезапись заголовка/MBR) резервной копии заголовка навсегда лишит доступа к дешифрованному разделу с OS Windows.

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

Сопоставление шифрования логического диска (/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, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom> (зависит от версии cryptsetup).

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

При отсутствии аппаратной поддержки AES на CPU, лучшим выбором будет создание расширенного «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.

cryptsetup open /dev/sda7 sda7_crypt
#выполнение данной команды запрашивает ввод секретной парольной фразы.

опции:
* open -сопоставить раздел «с именем»;
* /dev/sda7 -логический диск;
* sda7_crypt -сопоставление имени, которое используется для монтирования зашифрованного раздела или его инициализации при загрузке ОС.

#форматирование блочного шифрованного устройства
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…

#Бэкап заголовка раздела
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 -раздел, чью резервную копия шифрованного заголовка диска требуется сохранить.
На этом шаге <создание и редактирование зашифрованного раздела> закончено.

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

ls /mnt<Tab-Tab> 
#и видим файл "/шифрованнаяОС"

history
#в выводе терминала должна появиться история команд su рабочей ОС.

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 будет постоянный

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

#правим /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 or 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-го пароля). Файл можно указать любой до 8мБ, но считываться данные будут <1мБ.

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

#Если у вас ранее был активирован 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-ы <cryptomount/set root>).
должно быть подобие

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

проверьте, что строка <CRYPTSETUP=y> закомментирована <#>.
В будущем (и даже уже сейчас, этот параметр не будет иметь никакого значения, но иногда он мешает обновлять образ 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»).

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-a ошибка busybox)
На этом шаге настройка файлов конфигурации завершена.

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

mount /dev/sda6 /mnt

Если у вас установлена старая версия GRUB2, в каталоге /mnt/boot/grub/i-386-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).

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

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

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

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

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/Linuxinux зашифрован полностью, включая /boot/kernel and initrd;
• секретный ключ упакован в initrd.img;
• текущая схема авторизации (ввод пароля на разблокировку initrd; пароль/ключ на загрузку ОС; пароль авторизации учетки Linux).

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

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

ls /<Tab-Tab> #обнаружить файл-маркер

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

mount /dev/sda6 /mnt 

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

nano /etc/grub.d/41_custom 

gpg - -gen-key

gpg --export -o ~/perskey

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

rm -rf /mnt/

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

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

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

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

trust_list

Защита загрузчика 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, произойдет подписание загрузчика GRUB2, контроль раздела, лог.

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

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

Ср янв  2 11::41 MSK 2020
/media/username/GRUB/boot/grub/virus.mod: Moved 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

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 завершена.

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

Bleachbit v3.0 не проверял, возможно, проблему уже поправили.

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, диски монтируются автоматом.

Заметка кратко о том, что описано выше по шагам (но теперь для OS GNU/Linux)
1) Создать том в фс ext4 > 4gb (для файла) Linux в Veracrypt [Криптоящик].
2) Reboot в 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 (то есть разворачиваете бэкап с одного шифрованного раздела на другой шифрованный раздел Intel > AMD), не забывайте после переноса шифрованной ОС править секретный подставляемый ключ вместо пароля, тк. предыдущий ключ ~/etc/skey — уже не подойдет к другому шифрованном разделу, а новый ключ «cryptsetup luksAddKey» нежелательно создавать из под chroot — возможен глюк, просто в ~/etc/crypttab укажите вместо "/etc/skey" временно «none», после rebot-а и входа в ОС пересоздайте свой секретный подставляемый ключ заново).

Как ветераны IT незабываем отдельно делать бэкапы заголовков зашифрованных разделов ОС Windows/Linux, или шифрование обернется против Вас самих.
На данном шаге резервное копирование зашифрованных ОС закончено.

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

* Загружает ПК с live usb. Любое изменение (нарушителем) файлов приведет к оповещению реального хозяина ПК о вторжении в загрузчик. Но простая переустановка GRUB2 с сохранением grub.cfg (и последующей возможностью его редактирования) позволит злоумышленнику редактировать любые файлы (при таком раскладе, при загрузке GRUB2, оповещение реальному пользователю не последует. Статус тот же <0>)
* Монтирует незашифрованный раздел, сохраняет у себя "/mnt/boot/grub/grub.cfg".
* Переустанавливает загрузчик (выбрасывая «perskey» из образа core.img)

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

* Возвращает «grub.cfg» > "/mnt/boot/grub/grub.cfg", при необходимости его редактирует, например, добавляя свой модуль «keylogger.mod» в папку с модулями загрузчика, в «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 официально заявляет

«Note that even with GRUB password protection, GRUB itself cannot prevent someone with physical access to the machine from altering that machine’s firmware (e.g., Coreboot or BIOS) configuration to cause the machine to boot from a different (attacker-controlled) device. GRUB is at best only one link in a secure boot chain».

GRUB2 — слишком перегружен функциями, которые могут дать чувство ложной безопасности, а его развитие уже опередило по функциональности ОС MS-DOS, а ведь это всего лишь загрузчик. Забавно, что GRUB2 — «завтра» может стать ОС, а загружаемые GNU/Linux виртуальными машинами для него.

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