Шифрование linux после установки

Шифрование дисков в Linux

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

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

Методы шифрования данных в Linux

Шифрование на уровне файловой системы:

• 1. eCryptfs — это криптографическая файловая система Linux. Она хранит криптографические метаданные для каждого файла в отдельном файле, таким образом, что файлы можно копировать между компьютерами. Файл будет успешно расшифрован, если у вас есть ключ. Это решение широко используется для реализации зашифрованной домашней директории, например, в Ubuntu. Также ChromeOS прозрачно встраивает эти алгоритмы при использовании сетевых устройств для хранения данных (NAS).
• 2. EncFS — обеспечивает шифрованную файловую систему в пространстве пользователя. Она работает без каких-либо дополнительных привилегий и использует библиотеку fuse и модуль ядра для обеспечения интерфейса файловой системы. EncFS — это свободное программное обеспечение и она распространяется под лицензией GPL. В наши дни эта файловая система уже устарела потому что в ней было найдено несколько уязвимостей. Вместо неё популярность набирают другие утилиты.

Блочное шифрование на уровне устройства:

• Loop-AES — быстрая и прозрачная файловая система, а также пакет для шифрования раздела подкачки в Linux. Исходный код программы давно не изменялся. Она работает с ядрами 4.x, 3.x, 2.2, 2.0.
• TrueCrypt — это бесплатное решение с открытым исходным кодом для шифрования диска в операционных системах Windows 7 / Vista /XP / Mac OS X, а также в Linux.
• dm-crypt+LUKS — dm-crypt — это прозрачная подсистема для шифрования диска в ядре 2.6 и более поздних версиях. Поддерживается шифрование целых дисков, съемных носителей, разделов, томов RAID, программного обеспечения, логических томов и файлов.

В этой инструкции мы рассмотрим шифрование жесткого диска на Linux с помощью алгоритма Linux Unified Key Setup-on-disk-format (LUKS).

Как работает LUKS?

LUKS (Linux Unified Key Setup — протокол шифрования блочного устройства. Но мы забежали далеко наперед, чтобы понять как это работает, нужно скачала разобраться с другими технологиями, используемыми в этом способе.

Чтобы выполнить шифрование диска linux используется модуль ядра dm-crypt. Этот модуль позволяет создавать в каталоге /dev/mapper виртуальное блочное устройство с прозрачным для файловой системы и пользователя шифрованием. Фактически все данные лежат на зашифрованном физическом разделе. Если пользователь пытается записать данные на виртуальное устройство, они на лету шифруются и записываются на диск, при чтении с виртуального устройства, выполняется обратная операция — данные расшифровываются с физического диска и передаются в открытом виде через виртуальный диск пользователю. Обычно для шифрования используется метод AES, потому что под него оптимизированы большинство современных процессоров. Важно заметить, что вы можете шифровать не только разделы и диски, но и обычные файлы, создав в них файловую систему и подключив как loop устройство.

Алгоритм LUKS определяют какие действия и в каком порядке будут выполняться во время работы с шифрованными носителями. Для работы с LUKS и модулем dm-crypt используется утилита Cryptsetup. Ее мы и рассмотрим далее.

Утилита Cryptsetup

Утилита Cryptsetup позволят облегчить шифрование раздела Linux с помощью модуля dm-crypt. Давайте сначала ее установим.

В Debian или Ubuntu, для этого используйте такую команду:

suduo apt install cryptsetup

В дистрибутивах, основанных на Red Hat это будет выглядеть так:

sudo yum install cryptsetup-luks

Синтаксис запуска команды такой:

$ cryptsetup опции операция параметры_операции

Рассмотрим основные операции, которые можно сделать с помощью этой утилиты:

• luksFormat — создать зашифрованный раздел luks linux;
• luksOpen — подключить виртуальное устройство (нужен ключ);
• luksClose — закрыть виртуальное устройство luks linux;
• luksAddKey — добавить ключ шифрования;
• luksRemoveKey — удалить ключ шифрования;
• luksUUID — показать UUID раздела;
• luksDump — создать резервную копию заголовков LUKS.

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

Шифрование диска Linux

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

1. Создание раздела

В этом примере мы будем шифровать раздел /dev/sda6, но вместо него вы можете использовать целый жесткий диск или просто один файл, заполненный нулями. Создаем шифрованный раздел:

sudo cryptsetup -y -v luksFormat /dev/sdb1

Эта команда выполнит инициализацию раздела, установит ключ инициализации и пароль. Сначала надо подтвердить создание виртуального шифрованного диска набрав YES, затем нужно указать пароль. Указывайте такой пароль, чтобы его потом не забыть.

Выполните такую команду чтобы открыть только что созданный раздел с помощью модуля dm-crypt в /dev/mapper, для этого понадобится ввести пароль, с которым выполнялось шифрование luks linux:

sudo cryptsetup luksOpen /dev/sdb1 backup2

Теперь вы можете увидеть новое виртуальное устройство /dev/mapper/backup2 созданное с помощью команды luksFormat:

ls -l /dev/mapper/backup2

Чтобы посмотреть состояние устройства выполните:

sudo cryptsetup -v status backup2

А с помощью следующей команды вы можете сделать резервную копию заголовков LUKS на всякий случай:

cryptsetup luksDump /dev/sdb1

Ну, можно сказать, раздел готов. И что самое интересное, теперь вы можете им пользоваться так же, как и любым другим обычным разделом в каталоге /dev. Его можно форматировать с помощью стандартных утилит, записывать на него данные, изменять или проверять файловую систему и т д. Нельзя только изменить размер. То есть все полностью прозрачно, как и сказано в начале статьи.

2. Форматирование раздела

Давайте для начала отформатируем диск. Для надежности, чтобы стереть все данные, которые были в этом месте раньше, перезапишем наш шифрованный раздел linux нулями. Это уменьшит вероятность взлома шифрования, через увеличение количества случайной информации. Для этого выполните:

dd if=/dev/zero of=/dev/mapper/backup2

Работа утилиты может занять несколько часов, чтобы иметь возможность наблюдать за процессом, используйте pv:

pv -tpreb /dev/zero | dd of=/dev/mapper/backup2 bs=128M

Когда процесс завершится мы можем отформатировать устройство в любую файловую систему. Например, отформатируем в ext4:

sudo mkfs.ext4 /dev/mapper/backup2

Как видите, все команды cryptsetup применяются к физическому разделу, в то время как остальные команды для работы с дисками — к нашему виртуальному.

3. Монтирование раздела

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

sudo mount /dev/mapper/backup2 /backup2

4. Отключение раздела

Все работает, но как отключить устройство и защитить данные. Для этого выполните:

sudo umount /backup2

sudo cryptsetup luksClose backup2

5. Повторное монтирование

Чтобы снова получить возможность работать с зашифрованным разделом с помощью LUKS linux необходимо опять его открыть:

sudo cryptsetup luksOpen /dev/sdb1 backup2

Теперь можем монтировать:

sudo mount /dev/mapper/backup2 /backup2

6. Проверить файловую систему luks

Поскольку после открытия раздела с помощью luks linux, этот раздел воспринимается системой, как и все другие, вы можете просто использовать утилиту fsck:

sudo umount /backup2

sudo fsck -vy /dev/mapper/backup2

sudo mount /dev/mapper/backup2 /backu2

7. Изменить парольную фразу luks

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

sudo cryptsetup luksDump /dev/sdb1

Затем создадим новый ключ:

sudo cryptsetup luksAddKey /dev/sdb1

И удалим старый:

sudo cryptsetup luksRemoveKey /dev/sdb1

Сейчас вам придется ввести еще старый пароль.

Выводы

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

Плюсы:

• LUKS шифрует все блочное устройство, и поэтому очень хорошо подходит для защиты содержимого переносных устройств, таких как мобильные телефоны, съемные носители или жесткие диски ноутбуков.
• Вы можете использовать на серверах NAS для защиты резервных копий
• Процессоры Intel и AMD с AES-NI (Advanced Encryption Standard) имеют набор команд, которые могут ускорить процесс шифрования на основе dm-crypt в ядре Linux начиная с 2.6.32.
• Работает в том числе и с разделом подкачки, так что ваш ноутбук может использовать функцию спящего режима, или гибернации полностью безопасно.

Минусы:

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

Источник

Взлом и защита шифрования дисков 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 опубликовало технический отчёт со схожими рекомендациями по усилению безопасности загрузочной цепи: ссылка, зеркало.

Источник