Как убрать шифрование диска linux

Как убрать шифрование LUKS?

Я попытался удалить шифрование LUKS в моем домашнем каталоге с помощью следующей команды:

Но это дает мне ошибку, говоря:

Устройство / dev / mapper / luks-3fd5-235-26-2625-2456f-4353fgdgd не является допустимым устройством LUKS.

Озадаченный, я попробовал следующее:

Кажется, зашифрованное устройство активно, но недействительно. Что здесь может быть не так?

• Резервный
• Переформатировать
• Восстановить

cryptsetup luksRemoveKey удалит только ключ шифрования, если у вас их больше одного. Шифрование все еще будет там.

Раздел Fedora Installation_Guide C.5.3 объясняет, как luksRemoveKey работает.

То, что «невозможно» удалить шифрование при сохранении содержимого, является лишь обоснованным предположением. Я основываю это на двух вещах:

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

Во-первых, при удалении ключевой фразы из раздела LUKS необходимо указать раздел диска, на котором он находится, например:

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

Но luksRemoveKey удаляет только одну из парольных фраз (и никогда не последнюю). Если вы хотите постоянно дешифровать, вы должны использовать cryptsetup-reencrypt:

Источник

Могу ли я отключить полное шифрование диска?

Я недавно установил Ubuntu 12.10, и для загрузки требуется пароль (я установил его с зашифрованной файловой системой).

Нужно ли переустанавливать, чтобы перейти на стандартную незашифрованную файловую систему?

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

Нет простого метода или инструмента, чтобы отменить это. С некоторыми знаниями о том, как работают системы Linux, это можно сделать. Вам придется переместить всю файловую систему (или все файлы) в другой раздел (с достаточным количеством свободного места) или внешний жесткий диск. Затем удалите зашифрованный контейнер и заново создайте файловую систему без шифрования. Наконец, убедитесь, что новая файловая система правильно распознается загрузчиком и mount -a перед перезагрузкой.

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

PS: Скорее всего, вы можете изменить кодовую фразу шифрования, возможно, на пустую строку. Тогда для расшифровки требуется только нажать Enter. Может быть, вы можете пойти дальше и подавить (теперь бесполезно) приглашение пароля. Однако это не отключает шифрование. Данные все равно будут зашифрованы, хотя шифрование будет бесполезным, так как ключ может быть тривиально угадан.

Источник

Linux Unified Key Setup: как защитить флэшки и внешние диски от взлома

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

Чаще всего, пользователи рассуждают достаточно просто: накопители в безопасности, пока их никто не украл. Некоторые идут в размышлениях дальше: если для входа в систему нужно знать пароль — злоумышленнику будет сложно получить доступ к данным на украденном диске. Успокаиваясь на этой мысли, они забывают задать себе важный вопрос: к чему именно мешает получить доступ их пароль на самом деле?

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

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

Если время сильно ограничено, злодеи действительно могут украсть накопитель и взять работу на дом. Особенно легко это им удаётся, если он внешний и подключён через USB. В этой статье речь пойдёт о простом инструменте, позволяющем защитить от несанкционированного доступа данные на внешних накопителях. Даже если они уже попали в руки к злоумышленникам. Речь пойдёт о шифровании дисков в операционных системах семейства Linux.

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

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

Шифрование на этапе инсталляции

Проще всего выполнить полное шифрование диска, выбрав соответствующую опцию в процессе установки операционной системы. Большинство современных Linux-дистрибутивов позволяют это сделать. Здесь не буду расписывать в деталях, так как статья посвящена шифрованию внешних накопителей (далее я подробно буду рассматривать именно его).

Изображение: Seth Kenlon, CC BY-SA 4.0

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

Шифрование внешних накопителей

Внешние накопители созданы для того, чтобы их подключали к разным устройствам, быстро обмениваясь информацией, таскали с собой по работе и иногда… теряли. Я находил случайно оставленные диски в USB-портах компьютеров в вестибюле отелей, в принтерах бизнес-центров, диски, потерянные в учебных аудиториях и ​​даже в прачечной. Вряд ли их владельцы хотели бы, чтобы кто-то нашёл эти накопители и добрался до рабочих документов или личных архивов.

LUKS вместе с утилитой Cryptsetup позволяет шифровать внешние накопители почти так же просто, как и при инсталляции ОС.

Как это сделать с помощью LUKS

ВАЖНО: внешний накопитель должен быть либо пустым, либо содержать ненужные вам данные. Так что, если оба этих условия не выполнены, нулевым шагом должен стать бэкап.

1. Подключите и найдите свой внешний диск

Я для примера взял небольшую флэшку. Представим, что путь к ней выглядит как /dev/sdX. Утилита lsblk покажет мне вот такую информацию о блочных устройствах:

Всё правильно, моя флэшка обнаружена. Да, это именно она. Я точно знаю, что её размер 1.8Gb. В списке всего один диск (disk) с таким размером (ему соответствует один раздел part).
Я уделяю такое внимание этой, казалось бы, мелочи, так как дисков может быть много. И в случае ошибки на следующем шаге вы сотрёте с другого диска данные, которые вам всё ещё нужны.

2. Очистите диск

На этом шаге я обнуляю таблицу разделов диска:

Это, конечно, необязательно, но я люблю это состояние чистого листа.

3. Отформатируйте диск под LUKS

Используем для этого утилиту Cryptsetup. Её подкоманда luksFormat запускает первый этап создания зашифрованного раздела LUKS (позже мы создадим там файловую систему).
После этого появится предупреждение об удалении всех данных (которые могли всё ещё оставаться на диске). Кроме того, вас попросят придумать и ввести парольную фразу для диска.

4. Откройте LUKS-том

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

Я придумал фразу (а точнее, просто пароль в одно слово) «vaultdrive». У вас будет какой-то свой вариант. Чтобы посмотреть список открытых томов, нужно вывести содержимое каталога /dev/mapper:

Чтобы закрыть LUKS-том vaultdrive нужно написать:

После этого он исчезнет из каталога /dev/mapper.

5. Создайте файловую систему

Создайте файловую систему, чтобы иметь возможность хранить свои данные на диске. Я выбрал XFS, но это далеко не единственный вариант: можно использовать, например, ext4 или JFS. И многие другие.

Финал: монтирование LUKS-тома

Можно делать это через терминал. Например, мы хотим использовать для нашей цели директорию /mnt/hd

А рабочий стол KDE, например, позволяет указать диск для монтирования в специальном разделе с настройками. Но и там я тоже должен вводить пароль или парольную фразу, прежде чем произойдёт монтирование.

Изображение: Seth Kenlon, CC BY-SA 4.0

А какие инструменты для шифрования внешних дисков на Linux используете вы? Какие инструменты используете для аналогичных задач на macOS и Windows?

Недорогие VDS для любых задач. Используем новейшее железо, лучший дата-центр в Москве уровня надёжности TIER IV, бесплатно предоставляем защиту от DDoS-атак на любом тарифном плане, который можно создать самостоятельно в течение минуты.
Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Источник

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

Источник