The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Шифрование данных на существующем разделе ext4 без его переформатирования
Можно отметить два основных способа организации шифрования данных в уже
существующей файловой системе Ext4, не требующие пересоздания раздела с
переносом данных из резервной копии. Первый способ заключается в использовании
встроенных в Ext4 возможностей по шифрованию отдельных каталогов, а второй в
использовании команды "cryptsetup reencrypt" для прозрачного переноса ФС на
новый шифрованный раздел LUKS. В любом случае создание полной резервной копии
перед выполнением предложенных манипуляций обязательно.

Первый способ наиболее простой и безопасный, но он ограничен использованием
отдельных шифрованных каталогов, в которые можно перенести конфиденциальные
данные, требующие защиты. Шифрование в Ext4 поддерживается при использовании
как минимум ядра Linux 4.1 и утилит 2fsprogs 1.43.

Выставляем в суперблоке раздела  c ФС ext4 флаг поддержки шифрования (в нашем случае /dev/sda1):

    sudo tune2fs -O encrypt /dev/sda1

Создаём каталог, в котором будут храниться зашифрованные данные текущего пользователя:

    mkdir -p /secret/home/user
  
Генерируем случайную salt-последовательность для последующего шифрования и
сохраняем её в отдельный файл:

    echo 0x`head -c 16 /dev/urandom | xxd -p` > /home/user/.crypt_salt
 

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

    e4crypt add_key -S /home/user/.crypt_salt

    Enter passphrase (echo disabled):
    Added key with descriptor [f467134ca2c48c33]

Проверяем добавление ключа командой "keyctl show", которая поставляется в пакете keyutils.

  
Активируем шифрование для каталога /secret/home/user, указав выданный идентификатор ключа:

    e4crypt set_policy f467134ca2c48c33 /secret/home/user

Если после перезагрузки попытаться обратится к каталогу /secret/home/user без
добавления ключа командой "e4crypt add_key", его содержимое будет показано в
зашифрованном виде. Для расшифровки каталога при каждой загрузке необходимо
настроить повторный вызов команды add_key для привязки ключа.
   
   e4crypt add_key -S /home/user/.crypt_salt

   Enter passphrase (echo disabled):
   Added key with descriptor [f467134ca2c48c33]

Для просмотра привязанного к каталогу ключа можно использовать команду

   e4crypt get_policy /secret/home/user



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

Отмонтируем шифруемый раздел (при изменении корневого раздела нужно загрузиться
с отдельного live-дистрибутива), проверяем целостность ФС и уменьшаем размер ФС
для того, чтобы разместить заголвки LUKS на диске (в ФС должно быть достаточно
свободного места):

   e2fsck -f /dev/sda4
   resize2fs /dev/sda4 размер_меньше_текущего_на_32МБ

Шифруем содержимое имеющегося раздела без потери информации:
   
   cryptsetup reencrypt --encrypt /dev/sda4 --reduce-device-size 32M
   
Открываем раздел:

   cryptsetup open /dev/sdXY home
  
Увеличиваем размер ФС до свободной границы

   resize2fs /dev/mapper/home

Монтируем раздел:
   
    mount /dev/mapper/home /mnt/home

Смотрим UUID:

   blkid /dev/mapper/home 

Добавляем информацию о разделе в /etc/crypttab

   home UUID=UUID_устройства_LUKS none
 
Ключи: luks, cryptsetup, reencrypt, ext4 / Лицензия: CC-BY
Раздел:    Корень / Безопасность / Шифрование, PGP

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Анонимчик (?), 22:37, 11/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чем первый вариант лучше ecryptfs?
     
     
  • 2.2, hefenud (ok), 20:56, 12/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя бы тем, что ecryptfs более не разрабатывается и объявлен депрекейтед
    Уязвимости в нем не будут фиксится, разработка прекращена 5 лет назад
     
     
  • 3.3, Анонимчик (?), 22:43, 12/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за инфу, даже не знал об этом.
     
  • 3.5, Анонимчик (?), 10:56, 13/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    https://wiki.archlinux.org/title/Talk:Ext4:

    > e4crypt tool itself is also deprecated and no longer being updated (as it was really meant more as a demonstration, not as a proper user interface to filesystem encryption)

    https://wiki.archlinux.org/title/Fscrypt#Alternatives_to_consider:

    > e4crypt is missing many basic features and is no longer being actively developed

    Вам про это ничего не известно?

     
     
  • 4.6, hefenud (ok), 12:56, 13/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, я по привычке все LUKS'ом шифрую
    Когда в ext4 добавили шифрование посмотрел, подумал, что может быть полезно, но привычки менять не стал
     
  • 3.8, Анонимчик (?), 13:21, 13/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не похоже, что ecryptfs больше не разрабатывается - https://www.spinics.net/lists/ecryptfs/.
     
     
  • 4.9, hefenud (ok), 14:03, 13/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну я это помню по убунтовской рассылке, в объяснениях почему именно от него отказываются
    Просто я сам его использовал на десктопе и когда было объявлено, что разработка сворачивается и он депрекейтед пришлось отказаться для хома(как у настоящего параноика у меня вся система была под LUKS'ом, а /home еще и ecryptfs)

    Если меня ввели в заблуждение те кто сообщали об этом в рассылке и кто соответственно убрал из Ubuntu шифрование хома, то прошу прощения, так отложилось в голове

    С другой стороны раз оно выкинуто из мэйнстрим-десктопа, то ну его к черту, мало ли там будет уязвимостей которые могут использовать злоумышленники

     
  • 3.10, Анонимчик (?), 09:26, 14/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-

    > Chromium OS uses the eCryptfs stacked filesystem with per-user vault directories and keysets to separate and protect each user’s cached data.

    Даже так. Хотя последний релиз ecryptfs был еще 2016-05-02. В общем, странно все это. Не понятно, безопасно ее использовать или нет...

     
     
  • 4.11, hefenud (ok), 14:00, 14/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-
    >> Chromium OS uses the eCryptfs stacked filesystem with per-user vault directories and keysets to separate and protect each user’s cached data.
    > Даже так. Хотя последний релиз ecryptfs был еще 2016-05-02. В общем, странно
    > все это. Не понятно, безопасно ее использовать или нет...

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

     
     
  • 5.14, Анонимчик (?), 12:12, 15/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В общем, решил таки разобраться, deprecated ли ecryptfs или нет. Оказывается, что Ubuntu объявила как deprecated собственно поддержку ecryptfs "из коробки" (т.е. возможность при установке задать шифрование домашней папки с помощью ecryptfs) в пользу шифрования всего диска с помощью LUKS. Сама же ecryptfs ни разу не deprecated и активно развивается (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/fs/ecry).
     
  • 4.12, OpenEcho (?), 20:04, 14/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрите в сторону: gocryptfs

    Плюсы:
    - хорошо поддерживается
    - может делать реверс (плюс для бэкпапов в клоуд)
    - ЕМЕ, нет префикса
    - Самый быстрый
    - статический (т.е. работает везде)

    https://nuetzlich.net/gocryptfs/comparison/

     
     
  • 5.22, rinat85 (ok), 14:54, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    плюсую, пользуюсь долго на больших объемах и gocryptfs и нативным шифрованием отдельных датазетов zfs (домашние каталоги), всё прекрасно работает, смысла в LUKS особого не вижу, сенситивна обычно отдельные данные или места, где могут сохранится пароли и профили браузера, нафига шифровать например корневой раздел или вообще любой другой раздел или диск в целом вместе с куском того, что надо шифровать, шифровать и то, что не нужно было?
     
     
  • 6.26, Аноним (26), 02:23, 16/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы после загрузки не выяснить что /bin/ls на самом деле создает туннель с шеллом до чужого сервера: кто-то воспользовался вашим компом пока вас не было/загружались в зараженную винду.
     
     
  • 7.28, rinat85 (ok), 16:15, 16/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Чтобы после загрузки не выяснить что /bin/ls на самом деле создает туннель
    > с шеллом до чужого сервера: кто-то воспользовался вашим компом пока вас
    > не было/загружались в зараженную винду.

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

     
  • 2.4, Аноним (4), 04:00, 13/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А установка убунточки до сих пор вроде предлагает зашифровать /home и конечно же там ecryptfs (который типа деприкейдет?)
    Странно
     
     
  • 3.7, hefenud (ok), 12:56, 13/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > А установка убунточки до сих пор вроде предлагает зашифровать /home и конечно
    > же там ecryptfs (который типа деприкейдет?)
    > Странно

    Неа, с 18.04 не предлагает, предлагает криптовать всё уже 3 года, с использованием LUKS

     
  • 2.18, Аноним (18), 22:37, 20/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Тем, что ecryptfs - ломучий кусок добра, корраптящий данные при отказе питания или панике.
     
     
  • 3.19, Анонимчик (?), 09:55, 24/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А другие не портят данные в такой ситуации?)
     

  • 1.13, Аноним (13), 22:58, 14/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Шифрование данных на существующем разделе NTFS без его переформатирования
    1. Нажмите правой кнопкой по диску, выберите пункт Включить Bitlocker
    2. Готово
     
     
  • 2.16, пох. (?), 12:31, 16/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Он, гад, еще и глумится над убогими!

     
     
  • 3.24, noLimits (?), 00:42, 14/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    кто тут убогий так это этот ... юзер с битлокером, зашифрует себя так что потом фиг че достать
     
     
  • 4.25, пох. (?), 08:23, 14/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > кто тут убогий так это этот ... юзер с битлокером, зашифрует себя
    > так что потом фиг че достать

    кoкoкoкoкoнечно! То ли дело адепты шва6одки - всегда могут все достать, даже если пароли забыли и ключи потеряли. Поскольку on-disk шифрования у них нет, и где-нибудь валяется нешифрованный оригинал, который забыли удалить/удалили но восстановим.

     
     
  • 5.27, Аноним (26), 02:25, 16/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> кто тут убогий так это этот ... юзер с битлокером, зашифрует себя
    >> так что потом фиг че достать
    > кoкoкoкoкoнечно! То ли дело адепты шва6одки - всегда могут все достать, даже
    > если пароли забыли и ключи потеряли. Поскольку on-disk шифрования у них
    > нет, и где-нибудь валяется нешифрованный оригинал, который забыли удалить/удалили но восстановим.

    Но то что битлокер ломается (как миниум определенные версии) и у служб в нем есть закладки известно давно, а про luks такого не скажешь.

     
  • 4.29, Гость (??), 15:29, 20/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    При шифровании битлокером предлагается сохранить в надёжном месте ключ для восстановления. Если юзер проигнорировал рекомендацию или сохранил этот ключ в ненадёжном месте - его проблема, а не битлокера.
     
  • 2.17, Аноним (17), 20:49, 19/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А бэкап всего диска, ключ и пароль от ключа для надёжности отправляются в облако? А то вдруг забуду или потеряю...
     
  • 2.30, Аноним (30), 15:11, 21/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не отвлекайтесь, молодой человек, продолжайте переустанавливать шындоус
     

  • 1.15, kusb (?), 21:51, 15/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А зашифровать корень в первом варианте и чем тогда он будет хуже обычного? Или папку нужно пересоздавать. Наверное можно обойти.
     
  • 1.20, Карабьян (?), 01:01, 01/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В последнем случае ближе к концу раздел назван sdXY, хотя ранее sda4
     
  • 1.21, Карабьян (?), 06:15, 01/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хочу добавить, в e4crypt каталог шифрования можно указать сразу при создания ключа командой add_key
     
  • 1.23, Anonim (??), 15:40, 05/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть же fscrypt, зачем эти извращения с e4crypt?
     
  • 1.31, Садама (?), 13:08, 07/11/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Полнодисковое шифрование Windows Linux установленных систем. Зашифрованная мультизагрузка
    https://habr.com/ru/post/482696/

    Как минимум ознакомться с туториалом.

     
     
  • 2.33, Прыгающий Ленивец (?), 01:59, 22/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В 20м то году когда писался туториал было странно использовать  mbr разметку и legacy boot вместо uefi
     

  • 1.34, Сталинус (?), 09:09, 02/05/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А толку выстовлять в линукс галочку на зашифровать все если в итоге пароль на ликс сбрасывается на раз два. Известная проблнма на которую всем пох. Пароль сбрасывается легче чем на винде. И еще линь любит все безбожно журналировать как бы ты неусерался шифрованием всегда найдется файлик с блокнотом которое аждое нажатие кнопки журналирует. Т.е пишит логи.
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру