Введение новых дисков в работу и LUKS
Есть абсолютно НОВЫЙ hdd, который нужно ввести в работу в linux x64. Необходимо надежно защитить данные на этом hdd.
Для этого предполагается приготовить его с помощью dm-crypt/LUKS.
Планируется выполнить следующие действия:
1. Создать один раздел на диске с помощью
.
2. Отформатировать LUKS.
как указано здесь
https://www.pgpru.com/faq/zaschitadiska#h42-18
3. Открыть его
4. Отформатировать с помощью и смонтировать.
Всё.
Теперь что хотелось бы узнать:
а.) Для абсолютно нового диска имеет ли смысл заполнение случайными числами, как это указано здесь
https://www.pgpru.com/faq/zaschitadiska#h42-15
?
б.) Какова рекомендуемая минимальная длина пароля?
в.) Так ли уж нужны ключевые файлы? Для чего они в случае довольно мощного подхода, предлагаемого линукс?
г.) Покритикуйте вышеуказанные действия или добавьте что-то еще в эту последовательность.
Спасибо.
комментариев: 11558 документов: 1036 редакций: 4118
Обязательно. В противном случае можно будет элементарно определить объём зашифрованных данных и их расположение на диске.
комментариев: 9796 документов: 488 редакций: 5664
б). Обсуждение этой темы привело к вопросу кандидату в FAQ с последующем обсуждением самого этого вопроса на грани флуда. Формально, исходным параметром является не длина пароля, а более абстрактная величина — его энтропия. А длина зависит от энтропии по тому, каким способом придумывался/генерился пароль. В обсуждении ещё приведены и указаны по ссылкам разные техники. Но всё упирается в то, что у разных пользователей разные предпочтения. Кто-то может запомнить абсолютно рэндомный набор символов. А кто-то на это совсем неспособен и ему проще набивать равностойкие по энтропии, но гораздо более длинные парольные фразы, к которым можно придумать какой-то скрытый смысл.
в). Ключевые файлы, которые используются отдельно от заголовков контейнера в большинстве случаев не нужны. Если не нужно только использовать некую внешнюю флэшку как дополнительный ключ или делать сложную иерархию доступа между разными шифрованными раздела (вида «при открытии одного контейнера получаем ключ к другому»).
г). Можно не форматить под ext4, а сначала отформатить внутри шифрованного тома как физический том, а в нём сделать логические тома. Но если не знаете, что такое LVM, то скорее всего он и не нужен. И даже если знаете, возможно, тоже ничего добавлять смысла нет.
Какой конкретно способ заполнения рэндомом предпочесть.
1. Способ затирания через зануление криптотома
https://www.pgpru.com/faq/zaschitadiska#h42-15
2. выполнить с самого начала, еще до разметки диска.
3. Еще какие-то способы.
3-ий пункт связан с одной стороны с тем, что запонение случайными числами обязательно, с другой стороны с тем, что речь идет о 2Tb hdd, и
такой процесс будет высокой нагрузкой и для hdd, и для системы в целом.
комментариев: 9796 документов: 488 редакций: 5664
Это может на пару суток растянется.
Два способа из FAQ — примерно часов на 8.
Так и зануление криптотома с переформатом заголовка даст случайные числа в итоге. Способ с HAVEGE — самый быстрый, простой и приемлемо надёжный для данной задачи.
Вот к этой фразе постоянно мысленно возвращаюсь.
Вопрос больше теоретический. Допустим, в ходе соответствующего анализа был определен объем данных и их расположение.
Имеется в виду общий объем данных?
Что это дает?
В таком случае, какие будут следующие шаги по анализу этих данных?
комментариев: 9796 документов: 488 редакций: 5664
Чисто теоретически, противник должен видеть после шифрования данные, неотличимые от рэндома, без какой-либо структуры и различителей. За исключением служебных заголовков и предопределённого форматирования шифртекста, если таковое используется (в случае дискового шифрования в текущих режимах форматирования нет).
у меня пока нет возможности квалифицированно ответить на этот вопрос. Могу дать отвлечённый, косвенный ответ.
Считается, что при расположении данных не на локальном винчестере, а, например на удалённом сервере (в облаке), который подконтролен противнику, использовать нынешние режимы дискового шифрования вообще нельзя. Ни в прямом онлайн-режиме, ни в режиме бэкапов. Или надо каждый бэкап перешифровывать заново с нуля, но тогда дисковое шифрование не нужно — можно пошифровать данные через архив или образ диска, пропущенный через gnupg в режиме симметричного шифрования.
Считается, что с каждым актом наблюдения за изменением данных при дисковом шифровании происходит утечка сведений об открытом тексте. Поэтому, для серверного и облачного шифрования разрабатывают специальные режимы updatable encryption, чтобы сохранять возможность шифровать прозрачно без перешифровки всех данных. Публикуются соответствующие работы с кучей специфической терминологии, сведениями о нетривиальных различителях и пр.
Попадание противнику диска с шифроконтейнером, который не был заполнен целиком, схоже со случаем единичного наблюдения шифрования. Возможно, при этом утечка данных будет и незначительной. Возможно, никто из теоретиков этот вопрос подробно и не исследовал. Важен факт, что утечка есть, но её достаточно легко в данном случае предотвратить.
Вернусь к предыдущей проблеме:
раздел на диске был отформатирован с помощью luksFormat и смонтирован в /dev/mapper/experimental
Далее применяется следующая команда:
На что получаем ответ:
В чем здесь ошибка?
Зато работает следующая команда:
Получается, что мы сначала форматируем раздел в LUKS и монтируем его в /dev/mapper/some_name. А потом к уже смонтированному /dev/mapper/some_name применяем такую же процедуру, т.е. еще раз форматируем его с помощью luksFormat и еще раз монтируем в /dev/mapper/some_name1. Правильно понимаю? Спасибо.
комментариев: 9796 документов: 488 редакций: 5664
Это явная опечатка. Как можно перенаправлять что-то из sudo? sudo должно стоять перед командой. Или сделайте sudo -i, чтобы войти в рутовую консоль и наберите все команды с правами рута.
Монтирование обозначает обычно несколько другое: связывание устройства, на котором есть файловая система, с каталогом. Здесь же можно сказать, что не монтируем, а открываем "open" или поднимаем том.
Идея в том, чтобы после открытия тома его занулили внутри, а снаружи появился шифртекст нулей. А затем закрыли и перетёрли заголовок с первоначальным ключом заново с помощью повторного формата.
В том примере операции производятся над логическим томом, возможно это вас и запутало. Потому что в таком случае в /dev/mapper есть и просто исходный логический том и открытый том одновременно.
Если же вы шифруете всё устройство, то желательно создать на нём через fdisk раздел /dev/sd[x]1 и пометить как Linux LVM. Есть варианты с разметкой через pvcreate – vgcreate – lvcreate. Зависит от того, что вам нужно, например при автомонтировании через /etc/crypttab или стартовые скрипты и что для вас допустимо может торчать наружу, а что нет.
Тогда в мануале неточность. Первые 2 команды должны быть такими:
cryptsetup luksFormat /dev/sdx1
cryptsetup luksOpen /dev/sdx1 Group_T
dd if=/dev/zero bs=1M | pv -s [размер раздела в терабайтах]T > /dev/mapper/Group_T
комментариев: 9796 документов: 488 редакций: 5664
Был выбран пример на основе логического тома, о чём не было явно указано. Подразумевлось, что пользователь, знакомый с LVM, сам разберётся и подставит нужное устройство.
Есть возможность подумать и сделать акцент именно начиная с шифрования физического устройства. Возможно, инструкция будет дополнена, спасибо за замечания.
Кстати, вывод haveged не нужно направлять в открытый с помощью cryptsetup том: это ускоренный аналог {u}random, так что его можно направить на исходное устройство или на сырой том, который ещё не был отформатирован при помощи cryptsetup.
Полезная информация! Уже было протестировано и так и так ) Скорость от этого не поменялась, что писал в /dev/mapper/example, что в /deb/sdx. Одно и то же.
Ок, но еще раз хочу у Вас уточнить: нули можно направить и в dev/mapper/example, это корректно?
Например вот так:
комментариев: 9796 документов: 488 редакций: 5664
Параметр bs в команде dd обычно не имеет смысла брать больше 1M, скорость выше этого предела не растёт, хотя на каких-то современных носителях может и можно что-то выжать при незначительном увеличении.
Делать одну файловую систему на все 2 TB — это очень плохо по множеству соображений, таких как:
Если это внешний диск, работающий по USB 2.0, то на 5 суток:
т.к. urandom, судя по моему опыту, больше 5MB/sec почему-то не даёт. И, вообще, есть ограничения на скорость USB, её не предололеть. Скорей всего, именно она будет самым узким местом при заполнении диска.
Нет, нет здесь никакой вложенности процедур. Заполнять нулями надо /dev/mapper/some_name, а потом этот LUKS-раздел уничтожить переформатированием, после чего создать новый на этом же месте (а не внутри предыдущего!), грубо говоря.
Тогда последовательность будет такой?
1.) форматируем
2.) Открываем LUKS:
Появляется диск /dev/mapper/lvm/
3.) Создаем на нем физический раздел
4.) Создаем группу томов
5.) Создаем логические разделы внутри, исходя из объема 2Gb(например, 2 раздела по 500Gb + 1 раздел всё остальное, т.е. около 1Gb):
6.) Далее каждый форматируем:
7.) И монтируем как обычно, т.е.
Правильно?
Благодарю за совет по поводу LVM, но не совсем понятно:
судя по этому
Вы говорите про LUKS on LVM.
А судя по этому
Вы пишите об LVM on LUKS.
Если исходить из моих потребностей, то допускаю возможность поделить диск на несколько разделов с разными паролями. Но в таком случае было бы лучше делать LUKS on LVM, т.е. создавать LVM сначала, а потом уже форматировать каждый раздел под LUKS. Это даст возможность в случае необходимости изменить конфигурацию не сносить с диска вообще всё.
С другой стороны, в случае с LVM on LUKS нравится то, что можно скрыть вообще всю структуру разделов диска, когда LUKS закрыт.
Подитожу вопросы:
1.) О каком типе использования LUKS и LVM Вы пишите, когда пишите о преимуществах LVM? Сначала LVM, а потом LUKS?
2.) При каком подходе LVM все же больше преимуществ с точки зрения добавления новых носителей?
3.) Правильна ли моя последовательность команд, указанных выше?