LINUX.ORG.RU

Зашифровать девайс «на месте» в одну команду

 ,


2

3

Здравствуй, лор. Подскажи пожалуйста инструмент, с которым можно без временных файлов зашифровать уже заполненное данными блочное устройство на ±1Тб? Типа такого:

# здесь /dev/sdb незашифрован
encrypt -p qwerty123 /dev/sdb
# здесь /dev/sdb зашифрован
decrypt -p qwerty123 /dev/sdb
# здесь /dev/sdb расшифрован

Ответ на: комментарий от anonymous

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

Northsoft ★★
() автор топика

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

anonymous
()
Ответ на: комментарий от Northsoft

на википедии пишут что умеет

PGP (англ. Pretty Good Privacy) — компьютерная программа, также библиотека функций, позволяющая выполнять операции шифрования и цифровой подписи сообщений, файлов и другой информации, представленной в электронном виде, в том числе прозрачное шифрование данных на запоминающих устройствах, например, на жёстком диске. 
anonymous
()
Ответ на: комментарий от anonymous

Естественно, нужно обеспечить бесперебойное питание, про бэкапы и говорить не стоит

Была бы возможность создать бэкап — я сделал бы openssl enc =)

прозрачное шифрование данных

Ну PGP я пользовал лет 15 назад, и всё-таки это инструмент для почты и созданных с нуля томов, а не для уже заполненных блочных устройств независимо от их содержимого.

Northsoft ★★
() автор топика
Последнее исправление: Northsoft (всего исправлений: 2)
Ответ на: комментарий от Northsoft

Была бы возможность создать бэкап — я сделал бы openssl enc =)

Тогда считай, что я тебе не говорил о шифровании через пайп. Минимальное невезение — и о данных можно забыть насовсем.

anonymous
()
Ответ на: комментарий от anonymous

Я конечно отбитый, но даже я понимаю, что делать openssl enc -e -in /dev/sdb -out /dev/sdb — это сомнительная идея. :D

Northsoft ★★
() автор топика
Ответ на: комментарий от anonymous

Спасибо, анон, но с таким же успехом я могу сделать и openssl enc, интересно посмотреть на нечто более приспособленное к блочным девайсам.

Northsoft ★★
() автор топика

cryptsetup reencrypt --new --reduce-device-size / cryptsetup-reencrypt --decrypt

Есть одна попытка. Если что-то пойдёт не так, данным конец.

anonymous
()
Ответ на: комментарий от Northsoft

Спасибо, анон, но с таким же успехом я могу сделать и

Тогда тебе нужно кодирование «байт в байт», а это ни что иное, как побайтовый xor с ключом-словом.

Попробуй скрестить https://github.com/abderraouf-adjal/fxor с dd.

anonymous
()

decrypt -p qwerty123 /dev/sdb
# здесь /dev/sdb расшифрован

Вот такое умеет cryptsetup LUKS

# здесь /dev/sdb незашифрован
encrypt -p qwerty123 /dev/sdb

Вижу только один относительно надёжный вариант — через plain dm-crypt:

1. Сокращаем существующую файловую систему, освобождая свободное место.
2. В освободившемся месте создаём cryptsetup plainOpen ---offset*количество 512-байтных блоков с начала устройства* -c aes-xts-plain64 -h sha512 -s 512 /dev/sdb temp1
3. Создаём ext2 файловую систему на /dev/mapper/temp1
4. Перемещаем туда часть файлов(сколько получится), закрываем temp1 после размонтирования cryptsetup close temp1, запоминаем его размер.
5. Повторяем предыдущие шаги, только добавляя соответствующую опцию --size (см. man cryptsetup).

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

1. Берём следующий за основным контейнер, открываем его, переносим сколько получится данных с него на основной.
2. Соответствующим образом изменяем размер файловых систем внутри контейнеров.
3. Открываем получившиеся контейнеры, соответствующим образом изменив параметр --size и расширив файловую систему основного контейнера за счёт освободившегося места.

И вот так до победного конца.

Это всё очень долго и изнурительно, а при неправильном подходе — ещё и опасно.

Точно нельзя просто сделать зашифрованный бекап и перенести потом файлы на правильный LUKS?

SM5T001
()
Последнее исправление: SM5T001 (всего исправлений: 2)
Ответ на: комментарий от Northsoft

Не рекомендую использовать openssl enc без чёткого понимания ограничений.

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

Для такого использования более годятся gpg и gpgtar.

SM5T001
()
Ответ на: комментарий от SM5T001

В общем — я понял, что готового решения для этого нету. Одолжил винт и сделал всё через LUKS (да, я слабак). На будущее, наверное, придётся заняться этим вопросом. Спасибо, лор.

Northsoft ★★
() автор топика
Ответ на: комментарий от token_polyak

Для этого придумали Secure Erase. На SSD быстро, на HDD может и много часов пыхтеть.

Radjah ★★★★★
()
Ответ на: комментарий от Northsoft

Я изучил вопрос получше и проверил несколько способов, оказалось решение есть, правда не через LUKS, а через plain dm-crypt, но сработает и с LUKS, только заголовок будет отдельно(ИМХО чем так делать лучше сразу использовать прямой dm-crypt).

Вот последовательность действий:

1. Открываем диск этой командой: sudo cryptsetup plainOpen /dev/sdxx inplace --verify-passphrase, где xx — буква диска и номер раздела(без номера для целого диска). Желательно добавить дополнительные параметры, такие как -c aes-xts-plain64 -h sha512 -s 512. На предупреждение ответить YES
2. Выполнить команду cat /dev/sdxx | sudo dd of=/dev/mapper/inplace. Вместо cat можно использовать pv, что позволит видеть прогресс.

Собственно всё, можно монтировать /dev/mapper/inplace и крутить штурвал.

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

ВНИМАНИЕ: я проверял работоспособность только на отдельном разделе. Я не знаю что будет если попытаться так зашифровать целый диск с несколькими разделами, но обещаю проверить в скором времени.

Да, и ещё: естественно корень запущенной системы так зашифровать нельзя. Для этого нужно использовать pivot_root или делать это через initramfs/LiveUSB.

SM5T001
()
Ответ на: комментарий от SM5T001

На случай, если кому нужно будет наоборот дешифровать:

1. Открываем зашифрованный диск точно так, как написано выше.
2. Делаем sudo cat /dev/mapper/inplace 1<> /dev/sdxx

Всё.

Кстати, похожим образом можно менять пароль/шифр/прочие опции криптоконтейнера без дешифрования, а также добавлять новые слои шифрования, чтобы, например, использовать несколько шифров в связке, как у VeraCrypt. Только не используйте одинаковые ключи для разных слоёв!

Как именно это всё реализовать расписывать я не буду — вышеописанного хватит чтобы догадаться и подправить под свои нужды.

SM5T001
()
Последнее исправление: SM5T001 (всего исправлений: 1)
Ответ на: комментарий от ValdikSS

Как это должно сработать?

user@lVZdhDhM ~ $ sudo cryptsetup reencrypt --new --reduce-device-size /dev/sdf
--new: неизвестный параметр

user@lVZdhDhM ~ $ sudo cryptsetup-reencrypt --decrypt /dev/sdf
Устройство /dev/sdf не является корректным устройством LUKS.
SM5T001
()
Ответ на: комментарий от SM5T001

Пожалуйста, почитайте справку. Команда, которая вам нужна — cryptsetup reencrypt, с флагом --encrypt, в частности. Также обязательно прочитайте о том, как пользоваться --reduce-device-size, её нельзя запускать на неподготовленной (неуменьшенной) ФС.

ValdikSS ★★★★★
()
Последнее исправление: ValdikSS (всего исправлений: 2)
Ответ на: комментарий от SM5T001

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

Сказано — сделано. Всё работает отлично, как и ожидалось. mbr и gpt в целости и сохранности. Теперь по пунктам:

1. Делаем всё то же, что и с обычным разделом.
2. На данном этапе у нас есть открытое устройство, но у device mapper нет встроенной поддержки раделов. Если сделать fdisk -l /dev/mapper/inplace, в выводе могут отображаться разделы(аля /dev/mapper/inplace-partition1), но смонтировать их напрямую нельзя — нет нужной ноды.
3. Чтобы можно было работать с разделами, при такой конфигурации придётся использовать losetup поверх /dev/mapper/inplace. Вот команда для инициализации петлевого устройства: losetup -f /dev/mapper/inplace.
4. Всё, готово! Теперь с устройством можно работать штатными средствами, вся информация будет прозрачно шифроваться и дешифроваться. Разделы, соответственно — /dev/loopXp1, /dev/loopXp2 и т.д. Важный момент — система может не определять автоматически разделы, тут поможет команда partprobe /dev/loopX, где Х — номер петлевого устройства. Эту же команду необходимо исполнять при каждом изменении структуры разделов и/или их размеров. Ошибки определения можно смело игнорировать и исполнять partprobe по необходимости.
5. Когда нужно размонтировать диск, следует сначала выполнить команду losetup -d /dev/loopX, затем cryptsetup close inplace.

Всё вышесказанное касается и файлов-образов дисков.

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

Конечно, напрямую через GRUB загрузить систему с такого диска не выйдет — тут нужен отдельный boot/efi.

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

Я обещаю в скором времени попробовать зашифровать таким образом полностью системный диск. Если всё отлично заработает, значит можно выносить LVM на свалку и использовать исключительно по назначению, а не как затычку для device mapper.

Таким образом, отвечая на изначальный вопрос ТС, «одна команда» выглядит примерно так:

# здесь /dev/sdb незашифрован
cryptsetup plainOpen -c aes-xts-plain64 -h sha512 -s 512 /dev/sdb inplace && dd if=/dev/sdb of=/dev/mapper/inplace bs=1M status=progress && cryptsetup close inplace
# здесь /dev/sdb зашифрован
cryptsetup plainOpen -c aes-xts-plain64 -h sha512 -s 512 /dev/sdb cryptodisk && losetup -f /dev/mapper/cryptodisk
# здесь /dev/sdb прозрачно расшифрован и готов к работе
losetup -d /dev/loopX && cryptsetup close cryptodisk
# здесь /dev/sdb закрыт, данные нечитаемы.
cryptsetup plainOpen -c aes-xts-plain64 -h sha512 -s 512 /dev/sdb cryptodisk && dd if=/dev/mapper/cryptodisk of=/dev/sdb bs=1M status=progress && cryptsetup close cryptodisk
# здесь /dev/sdb окончательно расшифрован

SM5T001
()
Ответ на: комментарий от ValdikSS

Спасибо, конечно, за совет, но едва ли я смогу им воспользоваться — я сам уже давно(задолго до создания темы) прочитал большую часть документации по cryptsetup и dmsetup, а вопрос задал Northsoft. Всё нужное уже давно зашифровано, сейчас вот только ради эксперимента и помощи Northsoft и всем читающим зашифрую рабочую систему целиком через plain dm-crypt.

Не хочу показаться грубым, но приведённые выше команды НЕ РАБОТАЮТ в том виде, в котором их представили. Более того — они в принципе __НЕ СРАБОТАЮТ__ при попытке зашифровать целый диск с таблицей разделов. Просто потому, что таблицу разделов сохранить не получится. Её в теории *можно* переместить дальше от начала устройства, изменить размеры разделов, файловых систем и т.д., но трудоёмкость такого шаманства высока(как и риски), а предназначение столь туманно, что эффективного способа осуществить подобное с помощью инструментов, входящих в базовый комплект GNU/Linux, не существует. Только ручная работа и огромнейший шанс ошибиться. И да, тут требуется НУЛЕВОЙ допуск. MBR/GPT должно идти сразу после будущего заголовка.

Напомню, Northsoft спрашивал именно про шифрование отдельного диска целиком:

# здесь /dev/sdb незашифрован
encrypt -p qwerty123 /dev/sdb
# здесь /dev/sdb зашифрован
decrypt -p qwerty123 /dev/sdb
# здесь /dev/sdb расшифрован

Конечно, ВОЗМОЖНО у ТС диск без разделов в принципе, с голой файловой системой на весь диск(например, диск форматирован командой mkfs.ext4 /dev/sdb), и тогда способ, который я опишу дальше, сработает.

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

Следовательно, вышеприведённые команды cryptsetup reencrypt(слава воле случая, они неработоспособны) не потенциально, а гарантированно ведут к ПОТЕРЕ ДАННЫХ.

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

В связи со всем вышесказанным и тем, что у cryptsetup и cryptsetup-reencrypt крайне скудные маны по данному вопросу, Ваш призыв делать усиленное RTFM по меньшей мере выглядит некорректно, а на деле же воспринимается как форменное издевательство.

Надеюсь, теперь всё более или менее прояснилось, и более к этому вопросу возвращаться не придётся.

__________________________________________

Итак, как же корректно зашифровать раздел «на месте» с использованием cryptsetup-reencrypt или cryptsetup reencrypt(это разные команды, с разными опциями)? Пройдём по порядку:

1. На нужном разделе(пусть это будет /dev/sdb1) необходимо уменьшить файловую систему без уменьшения самого раздела. Если целевая файловая система — ext2/ext3/ext4, следует использовать команду resize2fs. Для этого необходимо определить размер файловой системы и вычесть из него примерно 10-20М. Например, если целевая файловая система имеет размер 2000М, конечная команда примет такой вид: resize2fs /dev/sdb1 1980M, можно использовать и универсальную команду, не вычисляя размер файловой системы: resize2fs -M /dev/sdb1, следует, однако, учитывать, что эта команда уменьшит файловую систему до минимально допустимого размера, т.е. это размер имеющихся на ней файлов + зарезервированное пространство. Перед выполнением одной из этих команд может потребоваться выполнить e2fsck -f /dev/sdb1

2. Далее необходимо выполнить одну из следующих команд: cryptsetup reencrypt --encrypt /dev/sdb1 --reduce-device-size 16384S или cryptsetup-reencrypt /dev/sdb1 --new --reduce-device-size 16384S. Авторы официальной документации рекомендуют использовать вторую команду.

3. После необходимо открыть новый контейнер cryptsetup luksOpen /dev/sdb1 cryptodisk, затем проверить файловую систему на предмет ошибок: e2fsck -f /dev/mapper/cryptodisk. Если ошибок нет или они были исправлены, далее можно заново отдать файловой системе всё свободное место: resize2fs /dev/mapper/cryptodisk. Эта команда автоматически расширит файловую систему до конца контейнера.

4. Теперь зашифрованный раздел готов к работе. Смонтируйте его и проверьте сохранность файлов. Дальнейшая работа с разделом ничем не отличается от работы с корректно созданным с нуля разделом LUKS.

Преимущества перед использованием прошлого метода plain dm-crypt:

1. Наличие LUKS и всех его особенностей. Примечание: предыдущий метод также поддерживает LUKS, но только с отделённым заголовком
2. Возможность возобновить шифрование после прерывания.
3. Удобное отображение статуса в процессе шифрования.

Недостатки:

1. Наличие LUKS и всех его недостатков.
2. Невозможно зашифровать целиком диск с таблицей разделов.
3. Повышенная трудоёмкость, необходимо дополнительно изменять размер файловой системы, что невозможно в некоторых случаях и для некоторых файловых систем. Риск отказа файловой системы.
4. Первоначально шифрование производится медленнее. Это связано с особенностями, позволяющими возобновить прерванный процесс шифрования.

SM5T001
()
Ответ на: комментарий от SM5T001

Было

16384S

Стало: 16384K

Таки да, самоисправление. Я имел в виду именно стандартный размер заголовка LUKS2, который на данный момент 16М. 16384S это половина от стандартного размера, использование такого размера приведёт к сокращению количества слотов ключей, что обычно не критично, но тем не менее.

SM5T001
()
Последнее исправление: SM5T001 (всего исправлений: 1)
5 августа 2021 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.