Шифрование всего диска линукс

Установка системы с шифрованием всего диска

Содержание

Описание руководства

Данная статья рассказывает, как создать надёжно зашифрованное хранилище данных на жестком диске компьютера и при этом не сломать спящий и ждущий режимы. Особенно актуально это для владельцев ноутбуков, т. к. в отличие от стационарных компьютеров шанс кражи/утери ноутбука выше и возникает обоснованное желание хранить информацию в зашифрованном виде. Однако, предлагаемая по-умолчанию опция шифрования домашней папки при помощи ecryptfs во-первых не шифрует корневой раздел системы 1) , а во-вторых ecryptfs шифрует раздел swap с применением случайно сгенерированного ключа, таким образом, перестает работать такая нужная в ноутбуках опция как спящий режим 2) 3) .

Предлагается же создать один большой зашифрованный раздел размером с весь диск компьютера 4) , поверх которого развернуть виртуальную группу LVM, в которой создать обычные (не шифрованные с точки зрения ОС) разделы /, /home и swap. При этом, пользователю придётся вводить пароль при каждом включении компьютера (даже при выходе из спящего режима), однако, за счёт смещения шифрования на более низкий уровень, ОС «не заметит» этого и все функции будут работать.

Установка

Итак, для установки нам потребуется диск альтернативной установки системы, который можно скачать тут. Ищите образ с alternate в названии.

Загрузите систему с alternate — диска, выберите язык и приступите к установке:

Выберите ручной режим разметки диска:

Если у вас новый диск или, если вы хотите очистить на нем таблицу разделов, выберите строку с названием диска:

и создайте на нем новую таблицу разделов:

После этого, создайте на диске раздел /boot, выбрав указателем свободное место на диске:

Укажите небольшой объем, от 300 МБ до 1ГБ, т.к. для /boot этого будет вполне достаточно:

В списке «использовать как» укажите /boot, не забудьте сделать раздел загрузочным:

Далее, не размечая оставшееся место, переходим в пункт «Настроить шифрование для томов»:

Соглашаемся записать изменения:

Выбираем «Create encrypted volumes»:

Далее выбираем (при помощи кнопки Space ) свободное место на диске и жмём «Продолжить»:

Если у вас нет паранойи, можете просто нажать «Настройка раздела закончена», если есть — установите параметр «Стереть данные» в «Да»:

Снова соглашаемся на запись изменений на диск:

Далее выбираем «Finish»:

Далее установщик попросит вас ввести парольную фразу, которой он «закроет» диск:

После этого подтвердите пароль:

Если вы используете слишком простой пароль 5) , установщик попросит подтверждения:

После создания шифрованного тома, нужно настроить LVM:

Снова соглашаемся на запись изменений:

Создаем группу томов:

И указываем в качестве устройств для группы только что созданный шифрованный диск:

После этого создаем логические тома:

Пример для swap:

Аналогично создаем диски для root и home, выделяя им желаемый объем. Если у вас большой диск — можете оставить некоторый его объем свободным, позднее вы сможете добавить его к любому логическому тому 6) .

После этого выбирайте «Закончить»:

Теперь нужно назначить файловые системы и точки монтирования для созданных дисков:

Выбирайте разделы, находящиеся в блоках, начинающихся на LVM, они названы, согласно именам, данным им вами при создании логических томов, например, в данном случае, это LV home, LV swap и LV root. Стоит заметить, что раздел root 7) не нужно делать загрузочным, т.к. роль загрузочного у нас выполняет отдельный раздел /boot.

По окончании, выбирайте «Закончить разметку и записать изменения на диск»:

И снова соглашаемся с записью изменений на диск (заодно можно ещё раз проверить все ли вы правильно разметили):

Далее продолжайте установку системы как обычно. Когда установщик спросит вас, зашифровать ли домашний каталог — откажитесь, ведь ваш диск уже зашифрован.

После завершения установки и перезагрузки система предложит вам ввести пароль для разблокировки шифрованного диска. Введите пароль и нажмите Enter .

Изменение пароля

Работа с live-cd

Загрузитесь с live-cd 8) , выберите «Попробовать Ubuntu» и дождитесь полной загрузки системы. После этого, настройте подключение к интернету. Затем откройте терминал и выполните:

После успешной установки, переходите к этапу «Смена пароля».

Смена пароля

Описание

При установке диск шифруется при помощи связки LUKS и dm-crypt. LUKS использует в качестве идентификаторов доступа key slots, которые в данном случае выступают в виде пароля, однако могут быть и ключом. Всего доступно 8 слотов. По умолчанию (при создании шифрованного диска) используется слот 0.

Если вам нужно использовать компьютер совместно с другим человеком — вы можете создать для него отдельный пароль разблокировки диска.

Для операций со слотами — сначала нужно определиться с диском, на котором установлено шифрование. Выполните в терминале команду

Вывод будет примерно следующим:

Она даст вам список разделов на диске. Нужно найти тот раздел, на котором присутствует зашифрованный раздел. В данном случае это sda5.

Теперь можно просмотреть состояние слотов на этом разделе:

Видим, что слот 0 содержит пароль, а слоты 1-7 имеют статус DISABLED.

Устанавливаем новый ключ

Ввиду того, что необходим как минимум один активный слот, сменить пароль в обычном понимании на таком диске невозможно. Однако, можно создать пароль в другом слоте, а потом удалить первый слот. Чтобы создать новый ключ, выполните:

Если теперь посмотреть слоты, то станет видно, что статус ENABLED стоит теперь уже у двух слотов:

Теперь можно удалить старый пароль, находящийся в слоте 0:

И видим, что слот 0 стал DISABLED.

Заключение

Вот и все. Информация на диске надёжно защищена. Однако, не стоит забывать, что существует большое количество различных угроз, и ваши данные все еще могут быть доступны злоумышленнику, в то время, пока компьютер включён, все диски «открыты». И конечно же, в случае кражи, шифрование спасет ваши данные от злоумышленника, но не вернет их вам, так что не забывайте делать резервные копии.

Ссылки

Статья написана по мотивам вот этой вот статьи.

Источник

Взлом и защита шифрования дисков LUKS

Шифрование дисков предназначено для защиты данных в компьютере от несанкционированного физического доступа. Бытует распространённое заблуждение, что дисковое шифрование с этой задачей действительно справляется, а сценарии, в которых это не так, представляются уж слишком экзотическими и нереалистичными. В этой статье показано, что извлечение мастер-ключа шифрованного тома LUKS легко осуществимо на практике, и предложен (давно не новый) метод защиты.

Суть проблемы

Отдельно стоит остановиться на предназначении дискового шифрования. Действительно, когда физический доступ невозможен и данными владеет запущенная система, проблем никаких нет. Могут быть проблемы с безопасностью самой системы, но тут шифрование дисков никак не поможет. Дисковое шифрование должно оберегать данные, когда у любопытствующей стороны есть возможность получить доступ к дискам минуя систему, например физически подключив диски к своей системе или загрузив свою ОС на инспектируемом компьютере. Сценарий физического доступа — единственный сценарий, при котором дисковое шифрование имеет какой-то смысл.

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

Такая атака требует лишь одного акта доступа к компьютеру: данные с диска можно скопировать совместно с подменой цепи загрузки, а потом расшифровать их, дождавшись появления ключа. В сравнении с незашифрованными дисками неудобство состоит только в том, что нужно озаботиться тем, как ключ будет передан, и дождаться запуска.

Далее перейдём к демонстрации такой техники на практике. Может оказаться так, что для её реализации атакующему потребуется меньше усилий, чем владелец системы затратил на настройку какого-то своего экзотического метода разблокировки дисков (например, удалённо).

Практическая демонстрация

Демо я проведу на примере виртуальной машины с Debian 9, на которой шифрование дисков было включено при установке системы.

Установка Debian 9 с шифрованием создаёт загрузочный раздел и раздел с шифрованным LVM. Снимок экрана установленной системы с запросом пароля расшифровки для наглядности:

Всё готово, можно приступать. Выключаем машину, копируем диск. В моем случае это выглядит так:

Монтируем диск машины, извлекаем инитрамдрайв:

Готово, можно редактировать инитрамдрайв. Зная, что машина имеет постоянное сетевое подключение, я хочу организовать зашифрованную отправку мастер-ключа после открытия дисков. Для этого мне потребуется:

1. Утилита для шифрованной отправки по сети. Добавляю её в /sbin
2. Шелл-скрипт для извлечения ключа и отправки. Отправляется в /scripts/local-top и добавляется в список /scripts/local-top/ORDER после cryptoroot .
3. Недостающий родной скрипт обработки событий udhcpc, чтобы запустить автонастройку сети прямо в рамдрайве, пользуясь встроенными средствами. Его законное место в /etc/udhcpc/default.script

Исполняемый файл secsend собран статически, чтобы устранить зависимости от каких-либо библиотек. При обычных условиях сборка даёт на выходе файл размером 2,7 МБ, что довольно ощутимо по сравнению с размером рамдрайва — 62 мегабайта в распакованном виде и 20 в сжатом. Однако, при сборке всех библиотек и исполняемого файла с минималистичной musl libc размер выходного файла получается

250 КБ и 120 КБ после сжатия UPX. Сам secsend просто читает стандартный вход, шифрует его cryptobox-ом из libsodium с использованием заданного публичного ключа Curve25519 и отправляет данные на заданный адрес по TCP. Его использование непринципиально для основной цели демонстрации, он скорее показывает что атакующий по сути ничем не ограничен: можно запускать код, который делает что хочет атакующий и как он этого хочет.

После добавления этих трёх файлов и редактирования ещё одного можно запаковывать всё обратно и возвращать изменённый файл на место:

Потребуется некоторый сервер для приёма зашифрованного мастер-ключа, например такой (Python 3.5.3+). Запустив его с указанием секретной части ключевой пары, дожидаемся, пока условная жертва включит свой компьютер:

При включении виртуальной машины с зашифрованным диском всё внешне выглядит как обычно, ничего не изменилось:

А вот на стороне слушателя подключений появился секретный мастер-ключ:

С этого момента сама виртуальная машина с данными и её пользователь со знанием пароля шифрования уже не представляют интереса для злоумышленника. Особо отмечу, что смена парольной фразы не меняет мастер-ключ, которым зашифрован весь том. Даже если между снятием копии и отправкой ключа как-то затесалась смена парольной фразы — это не помеха. Воспользуемся мастер-ключом для открытия тома. Для этого преобразуем его 16ричную запись в логе в бинарный файл:

Монтируем диски со снятой копии:

Меры защиты

Как можно заключить — корень проблемы в запуске недоверенного кода. Вот небольшой обзор методик, которые стоит рассмотреть в контексте этого вопроса.

Шифрование загрузочного раздела

Некоторые дистрибутивы предлагают и такую возможность при установке (например OpenSuSE). В таком случае загрузочный раздел расшифровывается загрузчиком, а затем с него загружаются ядро и инитрамдрайв. Такой подход не имеет особого смысла по следующим причинам:

• Самый главный вопрос с подменой кода всё равно остаётся открытым. Только теперь подменять нужно будет загрузчик.
• Для загрузочного раздела важнее не конфиденциальность данных, а целостность данных. Обычное шифрование LUKS не предоставляет такой гарантии. Некоторая выгода здесь заключается только в том, что на таком зашифрованном разделе трудно сформировать осмысленную подмену.
• И шифрование LUKS2 с проверкой целостности (dm-integrity) тоже не защищает от вмешательств, потому что оно не даёт гарантий против атак, связанных с повторным воспроизведением секторов. Например, имея дамп такого раздела и конфиг загрузчика на нём, всё равно можно взять и откатить ядро на состояние, скопированное ранее. Это не даёт преимуществ конкретно в вопросе извлечения ключа (разве что если старое ядро было уязвимо и это можно каким-то образом использовать), это скорее довод в пользу бесполезности шифрования загрузочного раздела.

 

Использование TPM для хранения ключа шифрования и валидации безопасной среды загрузки

Однако в линуксе поддержка TPM пока находится в зачаточном состоянии. Загрузчик TrustedGRUB2 (приспособленный для работы с TPM загрузчик) не поддерживает UEFI и от этого пропадает весь смысл затеи. Кроме того наличие рабочего TPM 2.0 только сейчас начинает появляться в железе, зачастую вместе с обновлениями BIOS. Большинство материнских плат не имеют дискретного TPM-модуля, вместо этого TPM программно реализован внутри Intel ME . По всем этим причинам я пока не рассматриваю такую конфигурацию как рабочую и пригодную для широкого использования.

Использование UEFI Secure Boot для полного покрытия загрузочной цепи электронной подписью

Существуют дистрибутивы (Fedora, OpenSuSE) и одиночные решения, которые позволяют использовать Secure Boot в Linux. Однако, коробочные решения зачастую не обеспечивают целостность кода в цепи загрузки. Они предназначены преимущественно для того, чтобы Linux просто запускался при включенном Secure Boot. Обычно просто используется EFI shim, подписанный сертификатом Microsoft, который дальше запускает всё что угодно. Соответственно, при использовании внешнего сертифицирования покрыть подписью инитрамдрайв, который генерируется прямо в установленной системе, просто невозможно.

1. Укрощаем UEFI SecureBoot — первая статья на хабре на эту тему, очень подробная.
2. Используем Secure Boot в Linux на всю катушку — здесь особенно хорошо написано, почему Secure Boot с установленными сертификатами Microsoft эквивалентен его отсутствию.

Требуемый результат получается во второй статье. Подпись инитрамдрайва достигается слиянием рамдрайва и ядра в одно EFI-приложение, без использования загрузчика, и UEFI напрямую проверяет подпись сразу оптом. Оба руководства требуют массу ручной работы на каждой защищаемой системе.

Доступное решение

Мне встретился подход к полноценному внедрению Secure Boot, совместимый с общепринятой схемой загрузки и не требующий серьёзного вмешательства в систему: отдельный загрузчик, отдельный рамдрайв, отдельное ядро. UEFI проверяет подпись только загрузчика GRUB2, загрузчик имеет вшитый конфиг с ключом для проверки подписи и паролем администратора, и дальше проверяет ядро и рамдрайв. Подписанный загрузчик устанавливается параллельно со старым и при необходимости сохраняется возможность запуститься обычным образом, выключив Secure Boot. Разумеется, эта возможность должна быть закрыта паролем администратора в меню настроек UEFI.

Я решил автоматизировать процесс внедрения Secure Boot с собственным PKI и сделать его простым и независимым от дистрибутива насколько возможно. В результате получился вот такой набор из рецепта Makefile и утилит: https://github.com/Snawoot/linux-secureboot-kit. Для debian, ubuntu, fedora и centos весь процесс требует всего несколько команд.

Конкретно на примере Debian 9 установка выглядит примерно следующим образом (предполагая, что UEFI уже в Setup Mode):

Здесь все команды введены от имени суперпользователя. В итоге остаётся только убедиться, что Secure Boot включён в меню BIOS и защитить настройки BIOS паролем администратора.

А вот как выглядит попытка подмены рамдрайва на такой инсталляции:

Подмена загрузчика (внешний вид зависит от платформы):

Одного лишь дискового шифрования недостаточно для обеспечения конфиденциальности данных. Подпись всей цепи загрузки с использованием UEFI Secure Boot и GPG позволяет достичь хорошего уровня защиты от подмены исполняемого кода при условии, что эксплуатант компьютера способен распознать сброс или подмену системной платы, или даже всего компьютера. В противном случае крайне трудно предложить адекватные способы защиты, если пользователь готов ввести пароль/передать ключ в любую машину, которая случайно оказалась на столе или в серверной.

ОБНОВЛЕНИЕ (2020-09-24 20:24:24+00:00): NSA опубликовало технический отчёт со схожими рекомендациями по усилению безопасности загрузочной цепи: ссылка, зеркало.

Источник