Обновленное свое же руководство по полнодисковому шифрованию в рунете V0.2.
Ковбойская стратегия:
[A] блочное системное шифрование Windows 7 установленной системы;
[B] блочное системное шифрование GNU/Linux (Debian) установленной системы (включая /boot);
[C] настройка GRUB2, защита загрузчика цифровой подписью/аутентификацией/хэшированием;
[D] зачистка — уничтожение нешифрованных данных;
[E] универсальное резервное копирование зашифрованных ОС;
[F] атака <на п.[C6]> цель — загрузчик GRUB2;
[G] полезная документация.
?---Схема #комнаты 40# <BIOS/MBR/1HDD без lvm>:
+--? Windows 7 установленная — шифрование полное системное, не скрытое;
+--? GNU/Linux установленная (Debian и производные дистрибутивы) — шифрование полное системное не скрытое(/, включая /boot; swap);
+--? независимые загрузчики: загрузчик VeraCrypt установлен в MBR, загрузчик GRUB2 установлен в расширенный раздел;
+--? установка/переустановка ОС не требуется;
L--? используемое криптографическое ПО: VeraCrypt; Cryptsetup; GnuPG; Seahorse; Hashdeep; GRUB2 – свободное/бесплатное.
Вышеописанная схема частично решает проблему «выносной boot на флэшку», позволяет наслаждаться зашифрованными OS Windows/Linux и обмениваться данными по «зашифрованному каналу» из одной ОС в другую.
Порядок загрузки ПК (один из вариантов):
- включение машины;
- загрузка загрузчика VeraCrypt (верный ввод пароля продолжит загрузку Windows 7);
- нажатие клавиши «Esc» загрузит загрузчик GRUB2;
- загрузчик GRUB2 (выбор дистрибутива/ GNU/Linux/CLI), затребует аутентификацию GRUB2-суперпользователя <логин/пароль>;
- после успешной аутентификации и выбора дистрибутива, потребуется ввод парольной фразы для разблокировки "/boot/initrd.img";
- после ввода безошибочных паролей в GRUB2 «потребуется» ввод пароля (третьего по счету, пароль BIOS или пароль учётки пользователя GNU/Linux – not consider) для разблокирования и загрузки ОС 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 не подойдет для системного шифрования). Чекните контрольную сумму загруженного софта
и сравните полученный результат с выложенной КС на сайте разработчика VeraCrypt.
Если установлено ПО HashTab, еще проще: ПКМ (VeraCrypt Setup 1.24.exe)-свойства-хэш суммы файлов.
Для проверки подписи программы в системе должны быть установлены ПО и публичный pgp ключ разработчика gnuPG; gpg4win.
Загрузка с официального сайта, либо с зеркала 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 загрузчик «Нет» (по факту «Да», но загрузчики VeraCrypt/GRUB2 не поделят MBR между собой, точнее, в MBR/загрузочной дорожке хранится лишь наименьшая часть кода загрузчика, основная его часть располагается в пределах файловой системы) – Мультизагрузка – Настройки параметров шифрования…
Если отклониться от вышеописанных шагов (схемы блочного системного шифрования), то VeraCrypt выкатит предупреждение и не позволит шифровать раздел.
На следующем шаге, к целенаправленной защите данных, проведите «Тест» и выбирайте алгоритм шифрования. Если у вас несовременный CPU, то скорее всего самым быстрым окажется алгоритм шифрования Twofish. Если CPU современный, разницу заметите: AES — шифрование по результатам теста будет в несколько раз скоростнее своих криптоконкурентов. AES — популярный алгоритм шифрования, аппаратная часть современных CPU специально оптимизирована на «секрет»так и на «взлом».
VeraCrypt поддерживает возможность криптовать диски каскадом AES(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (без аппаратной поддержки AES-NI, шифрование каскадом А/Т) снижение производительности в сущности незаметное. (у 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.
Если отклониться от вышеописанных шагов (схемы блочного системного шифрования), то VeraCrypt выкатит предупреждение и не позволит шифровать раздел.
На следующем шаге, к целенаправленной защите данных, проведите «Тест» и выбирайте алгоритм шифрования. Если у вас несовременный CPU, то скорее всего самым быстрым окажется алгоритм шифрования Twofish. Если CPU современный, разницу заметите: AES — шифрование по результатам теста будет в несколько раз скоростнее своих криптоконкурентов. AES — популярный алгоритм шифрования, аппаратная часть современных CPU специально оптимизирована на «секрет»
VeraCrypt поддерживает возможность криптовать диски каскадом AES(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (без аппаратной поддержки AES-NI, шифрование каскадом А/Т) снижение производительности в сущности незаметное. (у CPU AMD той же эпохи/~параметров —производительность немного снижена). ОС работает в динамике и потребление ресурсов на прозрачное шифрование – незаметное. В отличие, как например, заметное снижение производительности из-за установленного тестового нестабильного desktop environment Mate v1.20.1 (или v1.20.2 точно не помню) в GNU/Linux, или из-за работы подпрограммы телеметрии в Windows7^. Обычно искушенные пользователи до шифрования проводят тесты на производительность железа. Например, в Aida64/Sysbench/systemd-analyze blameи сравнивают с результатами этих же тестов после криптования системы, тем самым, для себя опровергая миф, «системное шифрование — это вредно». Замедление машины и неудобство ощутимо при резервном копировании/восстановлении зашифрованных данных, потому что сама по себе операция «системного резервного копирования данных» измеряется не в мс, и добавляются те самые <расшифровать/зашифровать на лету>. В конечном итоге каждый пользователь, которому разрешено возиться с криптографией, устанавливает баланс алгоритма шифрования относительно удовлетворения поставленных задач, степени своей паранойи и удобством пользования.
Параметр PIM лучше оставить по умолчанию, чтобы при загрузке ОС каждый раз не вводить точные значения итераций. VeraCrypt применяет огромное кол-во итераций для создания действительно «медленного хэша». Атака на такую «криптоулитку» методом Brute force/радужных таблиц имеет смысл только при
Свободный софт для реализации 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.
А4. Создание спасательного usb/диска VeraCrypt
По умолчанию VeraCrypt предлагает прожечь «метаданные ~2-3мБ» на компакт-диск, но не у всех людей есть диски или приводы DWD-ROM-ы, а создание загрузочной флэшки «VeraCrypt Rescue disk» для кого-то окажется техническим сюрпризом: Rufus/GUIdd-ROSA ImageWriter и другой подобный софт — не смогут справиться с поставленной задачей, потому что помимо копирования смещенных метаданных на загрузочную флэшку, нужно из образа сделать copy/paste за пределами файловой системы usb-накопителя, короче, правильно скопировать MBR/дорожу на брелок. Из-под ОС GNU/Linux создать загрузочную флэшку, можно воспользовавшись утилитой «dd», глядя на эту табличку.
Создание спасательного диска в среде Windows — иначе. Разработчик VeraCrypt не включил решение этой задачки в официальную документацию по «rescue disk», но предложил решение другим путем: выложил дополнительное ПО по созданию «usb rescue disk» в свободный доступ, на своем форуме VeraCrypt. Архивариус этого ПО для Windows – «создание usb veracrypt rescue disk». После сохранения rescue disk.iso начнется процесс блочного системного шифрования активного раздела. Во время шифрования работа ОС не останавливается, перезагрузка ПК не требуется. По завершению операции криптования, активный раздел становится полностью зашифрованным, можно пользоваться. Если при запуске ПК не появляется загрузчик VeraCrypt, и не помогает операция восстановления заголовка, то проверьте флаг «boot», он должен быть установлен на раздел, где присутствует Windows (независимо от шифрования и других ОС, см. таблица №1).
На этом описание блочного системного шифрования с ОС Windows закончено.
Создание спасательного диска в среде Windows — иначе. Разработчик VeraCrypt не включил решение этой задачки в официальную документацию по «rescue disk», но предложил решение другим путем: выложил дополнительное ПО по созданию «usb rescue disk» в свободный доступ, на своем форуме VeraCrypt. Архивариус этого ПО для Windows – «создание usb veracrypt rescue disk». После сохранения rescue disk.iso начнется процесс блочного системного шифрования активного раздела. Во время шифрования работа ОС не останавливается, перезагрузка ПК не требуется. По завершению операции криптования, активный раздел становится полностью зашифрованным, можно пользоваться. Если при запуске ПК не появляется загрузчик VeraCrypt, и не помогает операция восстановления заголовка, то проверьте флаг «boot», он должен быть установлен на раздел, где присутствует Windows (независимо от шифрования и других ОС, см. таблица №1).
На этом описание блочного системного шифрования с ОС Windows закончено.
[B] LUKS. Шифрование GNU/Linux (~Debian) установленной ОС. Алгоритм и Шаги
Для того чтобы зашифровать установленный Debian/производный дистрибутив, требуется сопоставить подготовленный раздел с виртуальным блочным устройством, перенести на сопоставленный диск GNU/Linux, и установить/настроить GRUB2. Если у вас не голый сервер, и вы дорожите своим временем, то пользоваться необходимо GUI, а большинство терминальных команд, описанных ниже, подразумевается водить в «режиме Чак-Норрис».
B1. Загрузка ПК с live usb GNU/Linux
«Провести криптотест на производительность железа»
lscpu && сryptsetup benchmark
Если вы счастливый владелец мощной тачки с аппаратной поддержкой AES-NI, то цифры будут похожи на правую часть терминала, если вы счастливый, но с античным железом — на левую часть.
B2. Разметка диска. монтирование/форматирование фс логического диска HDD в Ext4 (Gparted)
B2.1. Создание зашифрованного заголовка раздела sda7
Описывать имена разделов, здесь и далее, буду согласно относительно своей таблицы разделов, выложенной выше. Согласно вашей разметке диска, вы должны подставлять свои имена разделов.
Сопоставление шифрования логического диска (/dev/sda7 > /dev/mapper/sda7_crypt).
#Простое создание «LUKS-AES-XTS раздела»
Опции:
* luksFormat -инициализация LUKS заголовка;
* -y -парольная фраза (не ключ/файл);
* -v -вербализация (вывод информации в терминале);
* /dev/sda7 -ваш логический диск из расширенного раздела (туда, куда планируется перенос/шифрование GNU/Linux).
По умолчанию алгоритм шифрования <LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom> (зависит от версии cryptsetup).
При отсутствии аппаратной поддержки AES на CPU, лучшим выбором будет создание расширенного «LUKS-Twofish-XTS-раздела».
Сопоставление шифрования логического диска (/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-раздела».
B2.2. Расширенное создание «LUKS-Twofish-XTS-раздела»
Опции:
* luksFormat -инициализация LUKS заголовка;
* /dev/sda7 ваш будущий зашифрованный логический диск;
* -v вербализация;
* -y парольная фраза;
* -c выбор алгоритма шифрования данных;
* -s размер ключа шифрования;
* -h алгоритм хеширования/криптофункция, используется ГСЧ (--use-urandom) для генерации уникального ключа шифрования/дешифрирования заголовка логического диска, вторичного ключа заголовка (XTS); уникального мастер ключа хранящегося в зашифрованном заголовке диска, вторичного XTS ключа, все эти метаданные и подпрограмма шифрования, которая с помощью мастер ключа и вторичного XTS-ключа шифруют/дешифруют любые данные на разделе (кроме заголовка раздела) хранятся в ~3мБ на выбранном разделе жесткого диска.
* -i итерации в миллисекундах, вместо «количества» (задержка по времени при обработке парольной фразы, влияет на загрузку ОС и криптостойкость ключей). Для сохранения баланса криптостойкости при простом пароле типа «russian» требуется увеличивать значение -(i), при сложном пароле типа «?8d?ob/ofh» значение можно уменьшать.
* --use-urandom генератор случайных чисел, генерирует ключи и соль.
После сопоставления раздела sda7 > sda7_crypt (операция быстрая, так как создается зашифрованный заголовок с метаданными ~3 мБ и на этом всё), нужно отформатировать и смонтировать файловую систему sda7_crypt.
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/ofh» значение можно уменьшать.
* --use-urandom генератор случайных чисел, генерирует ключи и соль.
После сопоставления раздела sda7 > sda7_crypt (операция быстрая, так как создается зашифрованный заголовок с метаданными ~3 мБ и на этом всё), нужно отформатировать и смонтировать файловую систему sda7_crypt.
B2.3. Сопоставление
опции:
* open -сопоставить раздел «с именем»;
* /dev/sda7 -логический диск;
* sda7_crypt -сопоставление имени, которое используется для монтирования зашифрованного раздела или его инициализации при загрузке ОС.
cryptsetup open /dev/sda7 sda7_crypt
#выполнение данной команды запрашивает ввод секретной парольной фразы.
опции:
* open -сопоставить раздел «с именем»;
* /dev/sda7 -логический диск;
* sda7_crypt -сопоставление имени, которое используется для монтирования зашифрованного раздела или его инициализации при загрузке ОС.
B2.4. Форматирование файловой системы sda7_crypt в ext4. Монтирование диска в ОС
(Примечание: в Gparted работать с шифрованным разделом уже не получится)
опции:
* -v -вербализация;
* -L -метка диска (которая отображается в проводнике среди других дисков).
Далее, следует примонтировать виртуальное-шифрованное блочное устройство /dev/sda7_crypt в систему
Работа с файлами в папке /mnt приведет к автоматическому шифрованию/дешифрированию данных в sda7.
Удобнее сопоставлять и монтировать раздел в проводнике (nautilus/caja GUI), раздел уже будет в списке выбора дисков, останется ввести только парольную фразу для открытия/расшифрования диска. Сопоставляемое имя при этом будет выбрано автоматически и не «sda7_crypt», а что-то вроде /dev/mapper/Luks-xx-xx…
#форматирование блочного шифрованного устройства
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 и тд.), зашифрованные данные будут потеряны окончательно без какой-либо возможности их восстановить, потому что невозможно будет повторно сгенерировать одинаковые ключи, ключи создаются уникальные.
опции:
* luksHeaderBackup --header-backup-file -команда бэкап;
* luksHeaderRestore --header-backup-file -команда восстановления;
* ~/Бэкап_DebSHIFR — файл резервной копии;
* /dev/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 описаны в п.E1.
Далее, необходимо провести дефрагментацию раздела логического диска
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<Tab-Tab>
#и видим файл "/шифрованнаяОС"
history
#в выводе терминала должна появиться история команд su рабочей ОС.B4.3. Создание/настройка зашифрованного swap, правка crypttab/fstab
Так как файл подкачки при каждом старте ОС форматируется, то не имеет смысла создавать и сопоставлять swap с логическим диском сейчас, и набивать команды, как в п.B2.2. Для Swap-а при каждом старте будут автоматически генерироваться свои временные шифровальные ключи. Жизненный цикл ключей swap-a: размонтирование/отключение swap-раздела (+очистка ОЗУ); или перезапуск ОС. Настройка swap, открываем файл, отвечающий за конфигурацию блочных шифрованных устройств (аналог fstab-файла, но отвечающий за крипто).
правим
Опции
* 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 и форматируется «соответственно»; алгоритм шифрования.
правим
/dev/mapper/swap -имя , которое задали в crypttab.
Альтернативный зашифрованный swap
Если по каким-то причинам вы не хотите отдавать целый раздел под файл подкачки, то можно пойти альтернативным и лучшим путём: создание файла подкачки в файле на зашифрованном разделе с ОС.
Настройка раздела подкачки завершена.
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, как написал выше, описывает зашифрованные блочные устройства, которые настраиваются во время загрузки системы.
если сопоставляли раздел sda7>sda7_crypt как в п.B2.1
если сопоставляли раздел sda7>sda7_crypt как в п.B2.2
если сопоставляли раздел sda7>sda7_crypt как в п.B2.1 or B2.2, но не хотите повторно вводить пароль для разблокировки и загрузки ОС, то вместо пароля можно подставить секретный ключ/случайный файл
Описание
* none -сообщает, что при загрузке ОС, для разблокировки корня требуется ввод секретной парольной фразы.
* UUID -идентификатор раздела. Чтобы узнать свой идентификатор набираете в терминале (напоминание, что все это время и далее, вы работаете в терминале в среде chroot, а не в другом терминале live usb).
эту строчку видно при запросе 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мБ.
Выглядеть будет примерно так:
/etc/fstab содержит описательную информацию о различных файловых системах.
опция
* /dev/mapper/sda7_crypt -имя сопоставления sda7>sda7_crypt, которое указано в файле /etc/crypttab.
Настройка crypttab/fstab закончена.
#правим /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 закончена.
B4.5. Редактирование файлов конфигурации. Ключевой момент
B4.5.1. Редактирование конфига /etc/initramfs-tools/conf.d/resume
и закомментируйте (если существует) "#" строчку «resume». Файл должен быть полностью пустой.
B4.5.2. Редактирование конфига /etc/initramfs-tools/conf.d/cryptsetup
должно соответствовать
B4.5.3. Редактирование конфига /etc/default/grub (именно этот конфиг отвечает за умение генерировать grub.cfg при работе с зашифрованным /boot)
добавляем строку «GRUB_ENABLE_CRYPTODISK=y»
значение 'y', grub-mkconfig и grub-install будут проверять наличие зашифрованных дисков и генерировать дополнительные команды, необходимые для их доступа во время загрузки (insmod-ы <cryptomount/set root>).
должно быть подобие
B4.5.4. Редактирование конфига /etc/cryptsetup-initramfs/conf-hook
проверьте, что строка <CRYPTSETUP=y> закомментирована <#>.
В будущем (и даже уже сейчас, этот параметр не будет иметь никакого значения, но иногда он мешает обновлять образ initrd.img).
B4.5.5. Редактирование конфига /etc/cryptsetup-initramfs/conf-hook
добавляем
Это упакует секретный ключ «skey» в initrd.img, ключ необходим для разблокировки корня при загрузке ОС (если нет желания вводить пароль повторно, авто подставляется ключ «skey»).
#Если у вас ранее был активирован 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»).
B4.6. Обновление /boot/initrd.img [version]
Чтобы упаковать секретный ключ в initrd.img и применить исправления cryptsetup, обновляем образ
при обновлении initrd.img (как говорится «Возможно, но это не точно») появятся предупреждения, связанные с cryptsetup, или, например, уведомление о потере модулей Nvidia — это нормальное явление. После обновления файла, проверяйте, что он действительно обновился см. по времени (относительно chroot среды./boot/initrd.img). Внимание! перед [update-initramfs -u -k all] обязательно проверить, что cryptsetup open /dev/sda7 sda7_crypt — именно это имя должно быть, которое фигурирует в /etc/crypttab, иначе после reboot-a ошибка busybox)
На этом шаге настройка файлов конфигурации завершена.
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)
На этом шаге настройка файлов конфигурации завершена.
[С] Установка и настройка GRUB2/Защита
C1. При необходимости отформатируйте выделенный раздел для загрузчика (разделу достаточно не менее 20мБ)
mkfs.ext4 -v -L GRUB2 /dev/sda6C2. Монтирование /dev/sda6 в /mnt
Так мы работаем в chroot, то в корне не будет каталога /mnt2, а папка /mnt — будет пустой.
монтируем раздел GRUB2
Если у вас установлена старая версия GRUB2, в каталоге /mnt/boot/grub/i-386-pc (возможна другая платформа, например, не «i386-pc») отсутствуют криптомодули (короче, в папке должны находиться модули, включая эти .mod: cryptodisk; luks; gcry_twofish; gcry_sha512; signature_test.mod), в таком случае GRUB2 необходимо встряхнуть.
Важно! Во время обновления пакета GRUB2 из репозитория, на вопрос «о выборе» в какое место устанавливать загрузчик – необходимо отказаться от инсталляции (причина — попытка установки GRUB2 — в «MBR» или на live usb). В противном случае вы повредите заголовок/загрузчик VeraCrypt. После обновления пакетов GRUB2, и отмены установки, загрузчик нужно инсталлировать вручную на логический диск, а не в «MBR». Если в вашем репозитории устаревшая версия GRUB2, попробуйте апдейтить его с официального сайта – не проверял (работал со свежими загрузчиками GRUB 2.02 ~BetaX).
монтируем раздел GRUB2
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).
C3. Инсталляция GRUB2 в расширенный раздел [sda6]
У вас должен быть смонтирован раздел [п.C.2]
опции
* --force -установка загрузчика, минуя все предупреждения, которые практически всегда существуют и блокируют установку (обязательный флаг).
* --root-directory -установка каталога <boot/grub> в корень sda6.
* /dev/sda6 -ваш sdaХ раздел (не пропустите <пробел> между /mnt /dev/sda6).
grub-install --force --root-directory=/mnt /dev/sda6опции
* --force -установка загрузчика, минуя все предупреждения, которые практически всегда существуют и блокируют установку (обязательный флаг).
* --root-directory -установка каталога <boot/grub> в корень sda6.
* /dev/sda6 -ваш sdaХ раздел (не пропустите <пробел> между /mnt /dev/sda6).
C4. Создание файла конфигурации [grub.cfg]
Забудьте о команде «update-grub2», и используйте полноценную команду генерации файла конфигурации
после завершения генерации/обновления файла grub.cfg, в терминале вывода должны быть строчки(а) с найденными ОС на диске («grub-mkconfig» возможно найдет и подхватит ОС с live usb, если у вас мультизагрузочная флэшка с Windows 10 и кучей живых дистрибутивов — это нормально). Если в терминале «пусто», файл «grub.cfg» не сгенерирован, то это тот самый случай, когда в системе GRUBые баги (и скорее всего загрузчик из тестовой ветки репозитория), переустановите GRUB2 из надежных источников.
Установка «простая конфигурация» и настройка GRUB2 завершена.
grub-mkconfig -o /mnt/boot/grub/grub.cfgпосле завершения генерации/обновления файла grub.cfg, в терминале вывода должны быть строчки(а) с найденными ОС на диске («grub-mkconfig» возможно найдет и подхватит ОС с live usb, если у вас мультизагрузочная флэшка с Windows 10 и кучей живых дистрибутивов — это нормально). Если в терминале «пусто», файл «grub.cfg» не сгенерирован, то это тот самый случай, когда в системе GRUBые баги (и скорее всего загрузчик из тестовой ветки репозитория), переустановите GRUB2 из надежных источников.
Установка «простая конфигурация» и настройка GRUB2 завершена.
C5. Proof-test зашифрованной ОС GNU/Linux
Корректное завершаем криптомиссию. Аккуратно покидаем зашифрованную GNU/Linux (выход из среды chroot).
После перезагрузки ПК должен загрузиться загрузчик 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).
А в случае лишних строк в меню GRUB2 (из подхвата ОС-м с live usb) избавиться от них
Краткий итог по системному шифрованию GNU/Linux:
«Простая конфигурация 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» системное шифрование блочного раздела закончено.
С6. Расширенная настройка GRUB2. Защита загрузчика цифровой подписью + защита аутентификацией
GNU/Linux зашифрован полностью, но загрузчик шифровать нельзя – такое условие продиктовано BIOS. По этой причине цепочная зашифрованная загрузка GRUB2 невозможна, но возможна/доступна простая цепочная загрузка, с точки зрения защиты – не нужно [см. П. F].
Для «уязвимого» GRUB2 разработчики реализовали алгоритм защиты загрузчика «подписью/аутентификацией».
Для «уязвимого» GRUB2 разработчики реализовали алгоритм защиты загрузчика «подписью/аутентификацией».
- При защите загрузчика «своей цифровой подписью» внешняя модификация файлов, либо попытка загрузить в данном загрузчике дополнительные модули – приведет процесс загрузки к блокировке.
- При защите загрузчика аутентификацией для выбора загрузки какого-либо дистрибутива, либо ввод дополнительных команд в CLI, потребуется ввести логин и пароль суперпользователя-GRUB2.
С6.1. Защита загрузчика аутентификацией
Проверьте, что вы работаете в терминале в зашифрованной ОС
создайте пароль суперпользователя для авторизации в GRUB2
Получите хэш пароля. Что-то похоже на это
монтируем раздел GRUB
редактируем конфиг
проверьте поиск по файлу, что в «grub.cfg» отсутствуют где-либо флаги (" --unrestricted" "--user",
добавьте в самом конце (перед строкой ### END /etc/grub.d/41_custom ###)
«set superusers=»root"
password_pbkdf2 root хэш".
Должно быть примерно так
Если вы часто пользуетесь командой «grub-mkconfig -o /mnt/boot/grub/grub.cfg» и не хотите вносить каждый раз изменения в grub.cfg, занесите вышеописанные строки (логин/пароль) в пользовательский скрипт GRUB-а в самый низ
При генерации конфига «grub-mkconfig -o /mnt/boot/grub/grub.cfg», строки, отвечающие за аутентификацию, будут добавляться автоматически в grub.cfg.
На этом шаге настройка аутентификации GRUB2 завершена.
ls /<Tab-Tab> #обнаружить файл-маркерсоздайте пароль суперпользователя для авторизации в 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!
Сгенерировать персональный шифровальный ключ
Экспортировать свой ключ
Смонтируйте логический диск в ОС если он еще не смонтирован
очистите раздел GRUB2
Инсталлируйте GRUB2 в sda6, положив ваш персональный ключ в основной образ GRUB «core.img»
опции
* --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.cfg» строку «trust /boot/grub/perskey» (принудительно использовать pgp-ключ.) Так как мы инсталлировали GRUB2 с набором модулей, в том числе и модулем подписи «signature_test.mod», то это избавляет от добавления в конфиг команд типо «set check_signatures=enforce».
Выглядеть должно примерно так (концевые строки в файле grub.cfg)
Путь к "/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-скрипт для подписи «множества файлов».
Чтобы удалить все подписи загрузчика (если что-то пошло не так)
Что бы не подписывать загрузчик после обновления системы, замораживаем все пакеты обновления, имеющие отношение к GRUB2.
На этом шаге <защита загрузчика цифровой подписью> расширенная настройка GRUB2 завершена.
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. Proof-test загрузчика GRUB2, защищенного цифровой подписью и аутентификацией
GRUB2. При выборе какого-либо дистрибутива GNU/Linux или вход в CLI (командную строку) потребуется авторизация суперпользователя. После ввода верного логина/пароля потребуется пароль от initrd
Скрин, успешная аутентификация GRUB2-суперпользователя.
Если подделать какой-либо из файлов GRUB2/внести изменения в grub.cfg, или удалить файл/подпись, подгрузить вредоносный модуль.mod, то появится соответствующее предупреждение. Загрузка GRUB2 приостановится.
Скрин, попытка вмешаться в GRUB2 «из вне».
При «нормальной» загрузке «без вторжения», системный статус кода выхода «0». Поэтому неизвестно работает ли защита или нет (то есть «с защитой загрузчика подписью или без неё» при нормальной загрузке статус один и тот же «0» — это плохо).
Как проверить защиту цифровой подписью?
Неудобный способ проверки: подделать/удалить используемый GRUB2 модуль, например, удалить подпись luks.mod.sig и получить ошибку.
Правильный способ: зайти в CLI загрузчика и набрать команду
В ответ должны получить отпечаток «perskey», если статус «0», значит защита подписью не работает, перепроверяйте п.C6.2.
На этом шаге расширенная настройка «Защита GRUB2 цифровой подписью и аутентификацией» окончена.
Скрин, успешная аутентификация 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, при загрузке ОС происходит проверка неизменности раздела загрузчика с последующим логированием в безопасной среде (зашифрованной). В случае компрометации загрузчика, либо его раздела, в дополнение к логу вторжения запускается такая
Четыре раза в день происходит аналогичная проверка, которая не нагружает ресурсы системы.
С помощью команды "-$ проверка_GRUB" происходит мгновенная проверка в любой момент времени без логирования, но с выводом информации в CLI.
С помощью команды "-$ sudo подпись_GRUB" происходит мгновенное переподписание загрузчика GRUB2/раздела и его обновленное логирование (необходимо после обновления ОС/boot), и жизнь продолжается дальше.
Реализация метода хэширования загрузчика и его раздела
0) Подпишем загрузчик/раздел GRUB, предварительно смонтировав его в /media/username
1) Создаем скрипт без расширения в корне зашифрованной ОС ~/podpis, применяем к нему нужные права 744 секьюрити и защита от «дурака».
Запускаем скрипт от su, произойдет проверка хэширования раздела GRUB и его загрузчика, save лог.
Создадим или скопируем, например, «вредоносный файл» [virus.mod] в раздел GRUB2 и запустим временную проверку/тестирования:
2) Кладём гифку сюда > ~/warning.gif, задаем права 744.
3) Настраиваем fstab на автомонтирование раздела GRUB при загрузке
4) Проводим ротацию лога
5) Добавляем задание в cron
6) Создаем постоянные алиасы
После обновления ОС
На этом шаге защита хэшированием раздела GRUB завершена.
Защита загрузчика 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.txt1) Создаем скрипт без расширения в корне зашифрованной ОС ~/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
#как видим появилось «Files moved: 1 и Audit failed» означает, что проверка не прошла.
Из-за особенностей тестируемого раздела вместо «New files found» > «Files moved»
Ср янв 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#как видим появилось «Files moved: 1 и Audit failed» означает, что проверка не прошла.
Из-за особенностей тестируемого раздела вместо «New files found» > «Files moved»
2) Кладём гифку сюда > ~/warning.gif, задаем права 744.
3) Настраиваем fstab на автомонтирование раздела GRUB при загрузке
-$ sudo nano /etc/fstabLABEL=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 -ereboot '/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 работает честно и для GNU/Linux и для Windows7.
На GNU/Linux в Bleachbit 2.0-2 надежно работают функции безвозвратного удаления файлов и каталогов, но не очистка свободного пространства. Для сравнения: на Windows в ПО CCleaner функция «ОСП для ntfs» работает исправно, и Бог действительно не сможет прочитать удаленные данные.
И так, чтобы основательно удалить «компрометирующие» старые нешифрованные данные, необходим прямой доступ Bleachbit к этим данным, далее, воспользоваться функцией «удаление файлов/каталогов безвозвратно».
Для удаления «удаленных файлов штатными средствами ОС» в Windows используйте CCleaner/BB с функцией «ОСП». В GNU/Linux над этой проблемой (удаление удаленных файлов) вам необходимо получить практику самостоятельно (удаление данных+самостоятельная попытка их восстановления и не стоит полагаться на версию ПО (если не закладка, то баг)), только в таком случае вы сможете понять механизм этой проблемы и избавиться от удаленных данных окончательно.
Bleachbit v3.0 не проверял, возможно, проблему уже поправили.
Bleachbit v2.0 работает честно и для GNU/Linux и для Windows7.
На этом шаге «зачистка диска» завершена.
[E] Универсальное резервное копирование зашифрованных ОС
У каждого пользователя свой метод резервного копирования данных, но зашифрованные данные «Системных ОС» требуют чуть иной подход к задаче. Унифицированное ПО, как например «Clonezilla» и подобный софт не могут работать напрямую с зашифрованными данными.
Постановка задачи резервного копирования зашифрованных блочных устройств:
- универсальность — одинаковый алгоритм/ПО резервного копирования для Windows/Linux;
- возможность работать в консоли с любой live usb GNU/Linux без необходимости дополнительного скачивания ПО (но все же рекомендую GUI);
- безопасность резервных копий — хранимые «образы» должны быть зашифрованы/запаролены;
- размер зашифрованных данных должен соответствовать размеру реальных копируемых данных;
- удобное извлечение нужных файлов из резервной копии (отсутствие требования расшифровать сперва весь раздел).
Например, резервная копия/восстановление через утилиту «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 том
Алгоритм создания резервной копии:
Создание зашифрованного контейнера 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)
Теперь по команде «veramountpictures» появится запрос на ввод парольной фразы, и в ОС-у подмонтируется, зашифрованный системный том Windows.
Сопоставить/смонтировать системный том VeraCrypt в cryptsetup команда
Сопоставить/смонтировать раздел/контейнер VeraCrypt в cryptsetup команда
Вместо alias-а добавим (скрипт в автозагрузку) системный том с ОС Windows и логический криптованный диск ntfs в автозагрузку GNU/Linux
Создаём скрипт и сохраняем его в ~/VeraOpen.sh
Раздаем «верные» права:
Создаем два одинаковых файла (одинаковое имя!) в /etc/rc.local и ~/etc/init.d/rc.local
Наполняем файлы
Раздаем «верные» права:
Всё, теперь при загрузке GNU/Linux нам ненадо вводить пароли на монтирование зашифрованных дисков ntfs, диски монтируются автоматом.
Заметка кратко о том, что описано выше в п.E1 по шагам (но теперь для 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, или шифрование обернется против Вас самих.
На данном шаге резервное копирование зашифрованных ОС закончено.
- создание зашифрованного контейнера (том/файл) VeraCrypt для ОС;
- перенос/синхронизация ОС с помощью ПО Rsync в криптоконтейнер VeraCrypt;
- при необходимости загрузка тома 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
Сопоставить/смонтировать системный том 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 по шагам (но теперь для 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, или шифрование обернется против Вас самих.
На данном шаге резервное копирование зашифрованных ОС закончено.
[F] Атака на загрузчик GRUB2
Подробности
Если вы защитили свой загрузчик цифровой подписью и/или аутентификацией (см п.C6.), то от физического доступа это никак не защитит. Зашифрованные данные будут по-прежнему недоступны, но обход защиты (сброс защиты цифровой подписи) GRUB2 позволяет киберзлодею внедрить свой код в загрузчик, не вызывая подозрений (если только пользователь вручную не отслеживает состояние загрузчика, или не придумает свой прочный произвольный-скрипт-код для grub.cfg).
Алгоритм атаки. Злоумышленник
* Загружает ПК с live usb. Любое изменение (нарушителем) файлов приведет к оповещению реального хозяина ПК о вторжении в загрузчик. Но простая переустановка GRUB2 с сохранением grub.cfg (и последующей возможностью его редактирования) позволит злоумышленнику редактировать любые файлы (при таком раскладе, при загрузке GRUB2, оповещение реальному пользователю не последует. Статус тот же <0>)
* Монтирует незашифрованный раздел, сохраняет у себя "/mnt/boot/grub/grub.cfg".
* Переустанавливает загрузчик (выбрасывая «perskey» из образа core.img)
* Возвращает «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»
И для хозяина ПК по-прежнему будет действовать проверка подлинности суперпользователя GRUB2.
Цепочная загрузка (загрузчик загружает другой загрузчик), как писал выше, не имеет смысла (она предназначена для другой цели). Из-за BIOS нельзя загружать зашифрованный загрузчик (при цепной загрузке происходит перезапуск GRUB2 > зашифрованный GRUB2, ошибка!). Однако если все-таки воспользоваться идеей от цепочной загрузки, то можно быть уверенным, что загружается именно зашифрованный (не модернизированный) «grub.cfg» с зашифрованного раздела. И это тоже ложное чувство безопасности, потому что, всё, что указано в зашифрованном «grub.cfg» (подгрузка модулей ) складывается с модулями, которые подгружаются из незашифрованного GRUB2.
Если вы хотите это проверить, то выделите/зашифруйте еще один раздел sdaY, скопируйте на него GRUB2 (операция grub-install на зашифрованный раздел невозможна) и в «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
Как было отмечено выше, это не поможет от загрузки вредоносных модулей, если такие модули окажутся на вашем ПК. Например, кейлоггер, который сможет сохранять нажатия клавиш в файл и смешиваться с другими файлами в "~/i386", пока его не скачает атакующий с физическим доступом к ПК.
Самый простой способ проверить, что защита цифровой подписи активно работает (не сброшена), и никто не вторгся в загрузчик, в CLI набираем команду
в ответ получаем слепок нашего «perskey», или ничего не получаем, если нас атаковали (также необходимо проверить «set check_signatures=enforce»).
Существенный минус такого шага, набивать команды вручную. Если добавить эту команду в «grub.cfg» и защитить цифровой подписью конфиг, то предварительный вывод слепка ключа на экран слишком короткий по таймингу, и можно не успеть разглядеть вывод, получив загрузку GRUB2.
Предъявлять претензии особо не к кому: разработчик в своей документации п.18.2 официально заявляет
GRUB2 — слишком перегружен функциями, которые могут дать чувство ложной безопасности, а его развитие уже опередило по функциональности ОС MS-DOS, а ведь это всего лишь загрузчик. Забавно, что GRUB2 — «завтра» может стать ОС, а загружаемые GNU/Linux виртуальными машинами для него.
Небольшой ролик, о том, как я сбросил защиту цифровой подписью GRUB2, и заявил о своем вторжении реальному пользователю (напугал, а вместо того, что показано на ролике – можно написать не безобидный произвольный код/.mod).
Алгоритм атаки. Злоумышленник
* Загружает ПК с 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).
Выводы:
1) Блочное системное шифрование для Windows — реализовать проще, а защита одним паролем удобнее, чем защита несколькими паролями при блочном системном шифровании GNU/Linux, справедливости ради: последнее автоматизировано.
2) Статью написал, как релевантное, подробное простое руководство к полнодисковому шифрованию VeraCrypt/LUKS on one home the machine, которое, на сегодняшний день лучшее в рунете (IMHO). В руководстве > 60k знаков поэтому в нём не рассматривались некоторые интересные главы: о криптографах, которые исчезают/держатся в тени; о том, что в разных книжках GNU/Linux мало/не пишут о криптографии; о ст.51 конституции РФ; о лицензировании/запрете шифрования в РФ, о том для чего нужно шифровать «корень/boot». Руководство получилось и без того немалое, но подробное (описывающая даже простые шаги), в свою очередь, это сэкономит вам кучу времени, когда вы займетесь «настоящим шифрованием».
3) Полнодисковое шифрование проводил на Windows 7 64; GNU/Linux Parrot 4x; GNU/Debian 9.0/9.5.
4) Реализовал успешную атаку на свой загрузчик GRUB2.
5) Tutorial создан, чтобы помочь всем
6) Переработал и обновил своё руководство, которое актуально в 2020 году.
[G] Полезная документация
- Руководство пользователя TrueCrypt (февраль 2012 RU)
- Документация VeraCrypt
- /usr/share/doc/cryptsetup(-run) [локальный ресурс] (официальная подробная документация по настройке шифрования GNU/Linux с помощью cryptsetup)
- Официальный FAQ cryptsetup (краткая документация по настройке шифрования GNU/Linux с помощью cryptsetup)
- Шифрование устройства LUKS (archlinux-документация)
- Подробное описание синтаксиса cryptsetup (страница руководства arch)
- Подробное описание crypttab (страница руководства arch)
- Официальная документация GRUB2.
Метки: полное шифрование диска, шифрование раздела, полнодисковое шифрование Linux, полное системное шифрование LUKS1.
Пасхалка
Комментарии (47)
AlexanderS
02.01.2020 18:23Переработал и обновил своё руководство, которое актуально в 2020 году
Актуальная версия VeraCrypt сейчас 1.24 Hotfix-1.
ne555 Автор
02.01.2020 18:31+1Спасибо, поправил
Сейча уже 1.24-Update3.AlexanderS
02.01.2020 19:42Я часть названия папки не оттуда скопировал)
Только под винду доступен Update2. А Update3 — это некритичные изменения для Linux.
yurybx
02.01.2020 18:36А как насчёт штатного для Windows BitLocker-а? Как оцените его взломостойкость?
ne555 Автор
02.01.2020 19:06Честно говоря никогда BitLocker не трогал, а VeraCrypt открыта на hackerone.
Вот на стареньком CPU bench
john --format=BitLocker --test Will run 2 OpenMP threads Benchmarking: BitLocker, BitLocker [SHA-256 AES 32/64]... (2xOMP) DONE Speed for cost 1 (iteration count) of 1048576 Raw: 1.9 c/s real, 1.1 c/s virtual
Очевидно, что хэш тоже из разряда медленных
Но результаты пусть вас не сбивают с толку, хоть эти атаки brut-a на такие медленные хэши и не актуальны, все кому интерсно копают по всем другим возможным направлениям.
Например, когда включен ПК с LUKS, 100% можно дернуть пароль в зашифрованном виде из памяти и (не расшифровать) сменить ключ/пароль (до reboot-a) на раздел (но не мастер ключ). Поможет восстановление заголовка LUKS.
В руководстве несколько раз указывал на необходимость, в первую очередь, делать бэкапы заголовков шифрованных дисков.
Daysleeper
02.01.2020 21:59Когда только появились первые tpm модули, была возможность вытащить оперативку из компа во время звгрузки, опустить их в жидкий азот и считать ключи шифрования. Во второй версии tpm, ключи шифрования грузятся в рандомное время. Так что BitLocker достаточно надёжен.
Dima_Sharihin
03.01.2020 12:49Это тот, который отправляет мастер-ключи от девайса на сервера майкрософта на случай "а вдруг потеряется?" (suuuuure)
YuriM1983
02.01.2020 19:15Поговаривают, что VeraCrypt сильно тормозит на мелких файлах.
PS: когда-то использовал DiskCryptor. Во время переустановки Win7 та снесла зашифрованный раздел, форматнула его и разместила там свои временные файлы. Причём без каких-либо предупреждений. С тех пор не использую полнодисковое шифрование, кроме BitLocker.
dartraiden
02.01.2020 20:02Она ещё сильно тормозит, когда используется для шифрования разделов на NVME-накопителях. IOPS-ы проседают чудовишно. Связано это с тем, что заточена она под работу с файловыми контейнерами.
Bitlocker на производительности, конечно, тоже сказывается, но разница с VeraCrypt колоссальная.
Что касается VeraCrypt то она уже умеет использовать механизм ReflectDrivers, позволяющий сообщить ОС (Windows 10 1607 и выше), что некоторые разделы зашифрованы и драйвер для работы с ними нужно искать там-то. Благодаря этому не требуется расшифровывать системный раздел перед мажорным обновлением операционной системы.
simplix
03.01.2020 11:04Значит у вас была сборка с файлом ответов, оригинальная программа установки никогда не делает переразметку без прямого указания.
ntfs1984
02.01.2020 21:13Зачем это нужно ?
Против мамкиных хацкеров будет достаточно грамотного распределения прав.
Тов. майор расшифрует это все несложным устройством для расшифровки.
Если у тов. майора развертывание environment'а для каждой такой расшифровки, будет занимать слишком много времени — уязвимость пофиксят на уровне
ядразакона: ст. 100500 УК РФ. Шифрование содержимого носителя карается штрафом в миллион рублей, или лишением свободы сроком до двух лет.
Действенно было бы ...Скрывать содержимое на низком уровне, чтобы информации вообще не было видно никакой. Типа доп. блина в HDD, или доп. микросхемы в флешке, активирующихся по наличию определенного триггера. Но это из ряда фантастики.
Alexfed1109
02.01.2020 22:38Можно поподробнее про несложные устройства для расшифровки?
Am0ralist
02.01.2020 22:51+1Продаются во многих магазинах для любителей электрики и электроники, особенно для починки их в домашних условиях.
AcckiyGerman
02.01.2020 23:29+1Паяльник 250 Вт с прямым жалом
AlexanderS
03.01.2020 00:00+3Зачем это нужно ?
Если вы теряете или у вас крадут шифрованную флешку/жесткий диск, то можно особо не переживать насчёт информации на ней — нашедший просто отформатирует её и всё.
Шифрование — это не обязательно значит что вы прям какой-то типа параноик-дурак или нехороший человек коварно замышляющий что-то плохое относительно властей или общества. Это как личная гигиена. Хочешь быть здоровым и чтобы не было проблем — соблюдай несложные правила.
Daysleeper
02.01.2020 22:08+1Windows 10 pro + BitLocker + hyper-v для виртуалок с линуксами может решить поставленные задачи гораздо быстрее, проще и удобнее.
Darkhon
02.01.2020 22:31+3Статья исключительно полезная, но хотелось бы также увидеть вариант всего этого для GPT. Именно потому, что мы в 2020 году.
kunix
02.01.2020 23:30Вся эта красота не имеет смысла, если у вас реально быстрый SSD и нет поддержки AES-NI :)
ne555 Автор
02.01.2020 23:47Ни AES-ом едины (не оспаривается, преимущества AES в производительности очевидные, для тех, кто любит заниматься «всякими» такими вещами, которых только закон Амдала притормозит, а для кого-то шифрование минус часть ресурсов будет незаметно вовсе).
Более того, в статье на скринах видно, что у меня Twofish (так как камень старый и нет поддержки AES. +HDD).
Про производительность в статье тоже писал, если кратко, то ощущения, что что-то не так нет, только при резервном копировани (расшифровать/скопировать/зашифровать)+дефрагментация.
В общем, тема актуальна для некоторых людей, ищущих подобные мануалы.
ps/ И мне будет жалко потерять ноут с такой конфигурацией в 2020 году.
Alexfed1109
03.01.2020 06:34Все же интересно насколько падает производительность при полнодисковом шифрование? То есть можно ли шифровать просто на всякий случай и не ощущать последствий в виде тормозов
psycho-coder
03.01.2020 12:59Вопрос мучает давно (признаюсь, не искал ответа, но раз такой случай): Что будет если работающую систему дернут по питанию? ФС останется зашифрованной/расшифрованной? Что получится в итоге?
Dima_Sharihin
03.01.2020 13:17ФС останется поврежденной (как и незашфрованная), но насколько — сложный вопрос.
В томах VeraCrypt/LUKS ключи шифрования хранятся в отдельном разделе и вычитываются при подключении тома. Насколько я понимаю, шифрование производится in-place, то есть незашифрованных данных на накопителе нет в принципе, они существуют только в оперативной памяти компьютера, то есть на операции чтения/записи просто ставится еще одна перехватывающая цепочка. Windows/Linux совершенно фиолетово, сколько этапов прошли данные от команды блочному драйверу накопителя до физической записи на носитель, системы шифрования просто становятся между этими этапами.psycho-coder
03.01.2020 16:06Ага, значит, если упрут комп (дернув из розетки) не стоит боятся, что данные попадут куда не надо. Спасибо!
Dima_Sharihin
03.01.2020 16:14Если у них в руках баночка с жидким азотом — то стоит и побояться, нынешняя динамическая оперативка на редкость живучая
cryptoz
03.01.2020 15:11Было бы неплохо, если бы в VeraCrypt был опциональный пароль на уничтожение данных (достаточно той области диска, где сгенерированные ключи, а не весь диск). И задавался бы этот пароль также в мастере шифровании системного раздела.
В таком случае можно будет разыграть такую сцену:
— Говори пароль?
— Не скажу!
— Говори, а то пожалеешь!
— Не скажу, хоть убей!
— Ну я тебя предупреждал [достаёт паяльник, включает в розетку]
— Ой не, не надо, я так не хочу, вот пароль: rdMDuf6PnYE5tjxw
Майор вводит пароль, ждёт загрузки ОС, но вместо этого видит сообщение
«Encrypted volume was successful destroyed»ne555 Автор
03.01.2020 15:29опциональный пароль на уничтожение данных (достаточно той области диска, где сгенерированные ключи,
Эта область — и часть загрузчика VeraCrypt, которая распологается в «MBR и далее».
Мне кажется вы заблуждаетесь, недооценивая работу «противника» (ведь он уже скопировал заголовок диска, а если нет, то потребует его от вас).
Например, я тоже придерживаюсь философии разработчика Сryptsetup, что такие пароли: на ввод до загрузки на самоуничтожение заголовка диска — потеря темпа.
Пример ваш: вас принудили выдать пароль, вы ввели пароль и уничтожили заголовок диска, но в таком случае «майор» просто потребует от вас не только пароль, но и бэкап заголовка диска (~3мб).
А если Вы не делали бэкап заголовка диска (я не менее 3х раз это в статье упомянул), то
Как ветераны IT незабываем отдельно делать бэкапы заголовков зашифрованных разделов ОС Windows/Linux, или шифрование обернется против Вас самих
ps/ не делать резервных копий заголовков — это все равно что не иметь никаких ценных данных на диске. «Сбой по питанию», нечаянная перезапись mbr, или любая другая мелкая неприятность и вы расстанетесь с данными навсегда (рунет плачет от таких случаев на каждом спец.форуме).
По этой основной причине и не нужна опция уничтожения ключей до загрузки системы (IHMO).
Fedorkov
05.01.2020 16:48«майор» просто потребует от вас не только пароль, но и бэкап заголовка диска
Хранить бекап у надёжного человека в другой юрисдикции. Если просишь его вернуть бекап, не сказав секретное слово, он отвечает, что нечаянно стёр его.ne555 Автор
05.01.2020 17:10И как это поможет вам от паяльника?
Это же тот же самый случай.
«Недоброжелатель» пытает юзера и добивается от него либо пароля/заголовка/секретного слова для человека в другой юрисдикции.
Вот если бы юзер убедил недоброжелателя в своей глупости, что пароль он не помнит, а бэкап заголовка не делал тогда это сработает.
Но не имея бэкапа заголовка диска = не иметь ценных данных на диске.Fedorkov
05.01.2020 17:26Во-первых, не всякий недоброжелатель сможет/захочет использовать паяльник. Во-вторых, если дело дошло до паяльников, то убедить собеседника в своей глупости вы сможете только после сеанса криптоанализа.
ne555 Автор
05.01.2020 17:34«Паяльник» в кавычках — это психологическое/физическое воздействие, если этого ничего нет, то и пароль не нужно уничтожать (медленный хэш не сбрутить), и заголовок хранить в другой юрисдикци не нужно и тд…
Все это перемолвлено десятки раз среди тех, кто разрабатывают подобные алгоритмы защиты и в оф.документации эти моменты/оговорки разъясняют.
Am0ralist
03.01.2020 17:33И как это поможет вам от паяльника после?
Ну и при этом вопрос на засыпку: как это поможет, если весь диск скопируют перед тем, как ввести пароль?
Darkhon
05.01.2020 15:21Разработчики Veracrypt предпочли решать эту задачу через скрытые тома с «убедительной отрицаемостью» их наличия. Похоже, что реализовывать аналог «LUKS Nuke patch» в Veracrypt они не планируют.
Diamos
05.01.2020 10:17Спасибо за статью! Достойнейший труд и помощь тем, кому нет времени/сил с этим разбираться.
Хотелось бы что-нибудь подобное для mac os. И еще интересно развитие идеи загрузки ложной системы с ложными данными (возможно без пароля) при невыполнении определенных действий на этапе загрузки. То есть, если бук будет изъят и запущен посторонними, загрузится «нужная» система. Остается вопрос маскировки имени/модели/размера диска.ne555 Автор
05.01.2020 10:23Остается вопрос маскировки имени/модели/размера диска.
Это «выгравенно» все на самом диске.Diamos
06.01.2020 19:56Что касается визуальной части, проблема не столь сложная, как может показаться. На современных m2 ssd наклейки, которые без труда можно убрать/переклеить на нужную.
SSD в форм.факторе 2.5, например Samsung, можно либо переклеить, либо собрать в другой корпус.
Разумеется, что можно сравнить гравировку банок памяти, погуглить и подсчитать размер исходя из количества банок и т.д., но сомневаюсь что интеллект рядового тов. майора достаточен для того, чтобы не повестись на изначальную уловку и начать гуглить размер банок и т.д. Иными словами, изначально предполагается, что ноутбук попал к обычным блюстителям закона, а не к весьма серьёзным структурам, специализирующимся на подобном, которые к тому же способны и на более радикальные вещи.
Поэтому, предполагаю, что проблема с идентификацией модели диска в bios/системе куда более сложная.
ne555 Автор
06.01.2020 20:12ноутбук попал к обычным блюстителям закона, а не к весьма серьёзным структурам, специализирующимся на подобном, которые к тому же способны и на более радикальные вещи.
Если ПК не загружается. по нажатию кнопки, он отправляется на экспертизу.
(со слов бывшего следователя/юриста).
maxzhurkin
Windows Linux — это дистрибутив Linux такой, или сборка Windows?