id: Гость   вход   регистрация
текущее время 18:54 29/03/2024
Автор темы: Гость, тема открыта 25/02/2014 02:12 Печать
Категории: софт, инфобезопасность, защита дисков, свободный софт
http://www.pgpru.com/Форум/UnixLike/ВведениеНовыхДисковВРаботуИLUKS
создать
просмотр
ссылки

Введение новых дисков в работу и 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
?


б.) Какова рекомендуемая минимальная длина пароля?


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


г.) Покритикуйте вышеуказанные действия или добавьте что-то еще в эту последовательность.


Спасибо.



 
На страницу: 1, 2 След.
Комментарии
— SATtva (25/02/2014 09:45)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Для абсолютно нового диска имеет ли смысл заполнение случайными числами, как это указано здесь ... ?

Обязательно. В противном случае можно будет элементарно определить объём зашифрованных данных и их расположение на диске.
— unknown (25/02/2014 10:22)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

а). Заполнять рэндомом даже чистый диск практически обязательно. Чтобы нельзя было видеть, сколько там осталось пустого места; вычислять, есть ли там известные файлы некоторого очень большого размера (например после полупустых блоков появился кусок на пару гигов, похожий на известный противнику архив с документами или видео) и т.д.
б). Обсуждение этой темы привело к вопросу кандидату в FAQ с последующем обсуждением самого этого вопроса на грани флуда. Формально, исходным параметром является не длина пароля, а более абстрактная величина — его энтропия. А длина зависит от энтропии по тому, каким способом придумывался/генерился пароль. В обсуждении ещё приведены и указаны по ссылкам разные техники. Но всё упирается в то, что у разных пользователей разные предпочтения. Кто-то может запомнить абсолютно рэндомный набор символов. А кто-то на это совсем неспособен и ему проще набивать равностойкие по энтропии, но гораздо более длинные парольные фразы, к которым можно придумать какой-то скрытый смысл.
в). Ключевые файлы, которые используются отдельно от заголовков контейнера в большинстве случаев не нужны. Если не нужно только использовать некую внешнюю флэшку как дополнительный ключ или делать сложную иерархию доступа между разными шифрованными раздела (вида «при открытии одного контейнера получаем ключ к другому»).
г). Можно не форматить под ext4, а сначала отформатить внутри шифрованного тома как физический том, а в нём сделать логические тома. Но если не знаете, что такое LVM, то скорее всего он и не нужен. И даже если знаете, возможно, тоже ничего добавлять смысла нет.
— cyber_beard (25/02/2014 11:42)   <#>
Спасибо за подсказки! Ещё вопрос по пункту а.)
Какой конкретно способ заполнения рэндомом предпочесть.
1. Способ затирания через зануление криптотома
https://www.pgpru.com/faq/zaschitadiska#h42-15
2. выполнить с самого начала, еще до разметки диска.
3. Еще какие-то способы.
3-ий пункт связан с одной стороны с тем, что запонение случайными числами обязательно, с другой стороны с тем, что речь идет о 2Tb hdd, и
такой процесс будет высокой нагрузкой и для hdd, и для системы в целом.
— unknown (25/02/2014 12:28)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Это может на пару суток растянется.

Два способа из FAQ — примерно часов на 8.


Так и зануление криптотома с переформатом заголовка даст случайные числа в итоге. Способ с HAVEGE — самый быстрый, простой и приемлемо надёжный для данной задачи.
— cyber_beard (01/03/2014 17:43)   <#>
Для абсолютно нового диска имеет ли смысл заполнение случайными числами, как это указано здесь ... ?


Обязательно. В противном случае можно будет элементарно определить объём зашифрованных данных и их расположение на диске.


Вот к этой фразе постоянно мысленно возвращаюсь.
Вопрос больше теоретический. Допустим, в ходе соответствующего анализа был определен объем данных и их расположение.
Имеется в виду общий объем данных?
Что это дает?
В таком случае, какие будут следующие шаги по анализу этих данных?
— unknown (01/03/2014 19:41)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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

Что это дает?
В таком случае, какие будут следующие шаги по анализу этих данных?

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

Считается, что при расположении данных не на локальном винчестере, а, например на удалённом сервере (в облаке), который подконтролен противнику, использовать нынешние режимы дискового шифрования вообще нельзя. Ни в прямом онлайн-режиме, ни в режиме бэкапов. Или надо каждый бэкап перешифровывать заново с нуля, но тогда дисковое шифрование не нужно — можно пошифровать данные через архив или образ диска, пропущенный через gnupg в режиме симметричного шифрования.

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

Попадание противнику диска с шифроконтейнером, который не был заполнен целиком, схоже со случаем единичного наблюдения шифрования. Возможно, при этом утечка данных будет и незначительной. Возможно, никто из теоретиков этот вопрос подробно и не исследовал. Важен факт, что утечка есть, но её достаточно легко в данном случае предотвратить.
— cyber_beard (01/03/2014 20:09)   <#>
Спасибо, теперь уже яснее.
Вернусь к предыдущей проблеме:
раздел на диске был отформатирован с помощью luksFormat и смонтирован в /dev/mapper/experimental
Далее применяется следующая команда:

На что получаем ответ:


В чем здесь ошибка?

Зато работает следующая команда:
— cyber_beard (01/03/2014 20:19)   <#>
Еще вопрос по вышеуказанному мануалу Способ затирания через зануление криптотома, возникший в ходе сравнения с другими подобными мануалами в англоязычном интернете.
Получается, что мы сначала форматируем раздел в LUKS и монтируем его в /dev/mapper/some_name. А потом к уже смонтированному /dev/mapper/some_name применяем такую же процедуру, т.е. еще раз форматируем его с помощью luksFormat и еще раз монтируем в /dev/mapper/some_name1. Правильно понимаю? Спасибо.
— unknown (01/03/2014 21:59)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
sudo pv -s 2T sudo >

Это явная опечатка. Как можно перенаправлять что-то из sudo? sudo должно стоять перед командой. Или сделайте sudo -i, чтобы войти в рутовую консоль и наберите все команды с правами рута.

Получается, что мы сначала форматируем раздел в LUKS и монтируем его в /dev/mapper/some_name. А потом к уже смонтированному /dev/mapper/some_name применяем такую же процедуру, т.е. еще раз форматируем его с помощью luksFormat и еще раз монтируем в /dev/mapper/some_name1. Правильно понимаю? Спасибо.

Монтирование обозначает обычно несколько другое: связывание устройства, на котором есть файловая система, с каталогом. Здесь же можно сказать, что не монтируем, а открываем "open" или поднимаем том.

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

В том примере операции производятся над логическим томом, возможно это вас и запутало. Потому что в таком случае в /dev/mapper есть и просто исходный логический том и открытый том одновременно.

Если же вы шифруете всё устройство, то желательно создать на нём через fdisk раздел /dev/sd[x]1 и пометить как Linux LVM. Есть варианты с разметкой через pvcreate – vgcreate – lvcreate. Зависит от того, что вам нужно, например при автомонтировании через /etc/crypttab или стартовые скрипты и что для вас допустимо может торчать наружу, а что нет.
— cyber_beard (01/03/2014 22:11)   <#>
ОК, спс. По поводу haveged все понятно.

Монтирование обозначает обычно несколько другое: связывание устройства, на котором есть файловая система, с каталогом. Здесь же можно сказать, что не монтируем, а открываем "open" или поднимаем том.

Тогда в мануале неточность. Первые 2 команды должны быть такими:
cryptsetup luksFormat /dev/sdx1
cryptsetup luksOpen /dev/sdx1 Group_T
dd if=/dev/zero bs=1M | pv -s [размер раздела в терабайтах]T > /dev/mapper/Group_T
— unknown (01/03/2014 22:38, исправлен 01/03/2014 22:42)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Был выбран пример на основе логического тома, о чём не было явно указано. Подразумевлось, что пользователь, знакомый с LVM, сам разберётся и подставит нужное устройство.


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


Кстати, вывод haveged не нужно направлять в открытый с помощью cryptsetup том: это ускоренный аналог {u}random, так что его можно направить на исходное устройство или на сырой том, который ещё не был отформатирован при помощи cryptsetup.

— cyber_beard (01/03/2014 22:57)   <#>
так что его можно направить на исходное устройство или на сырой том, который ещё не был отформатирован при помощи cryptsetup.

Полезная информация! Уже было протестировано и так и так ) Скорость от этого не поменялась, что писал в /dev/mapper/example, что в /deb/sdx. Одно и то же.

Был выбран пример на основе логического тома, о чём не было явно указано. Подразумевлось, что пользователь, знакомый с LVM, сам разберётся и подставит нужное устройство.

Ок, но еще раз хочу у Вас уточнить: нули можно направить и в dev/mapper/example, это корректно?
Например вот так:
— unknown (01/03/2014 23:56)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Нули нужно направлять исключительно на открытый том, который возникает после открытия через cryptsetup/LUKS от другого исходного тома или устройства. Чтобы когда этот том закроют, нули на исходном устройстве оказались зашифрованными данными.

Параметр bs в команде dd обычно не имеет смысла брать больше 1M, скорость выше этого предела не растёт, хотя на каких-то современных носителях может и можно что-то выжать при незначительном увеличении.
— Гость (02/03/2014 04:33)   <#>

Делать одну файловую систему на все 2 TB — это очень плохо по множеству соображений, таких как:
  1. Ошибка в файловой системе — и сразу будет проблема со всем диском.
  2. Если захочется открыть доступ только к некоторому набору данных, придётся открывать доступ ко всем имеющимся, поскольку иного не будет предусмотрено.
  3. Будет невозможно сделать гибкое управление данными (разбить диск на подразделы, разные файловые системы, назначить разные пароли к разным виртуальным разделам и т.д.), т.к. для этого нужно LVM. Если LVM есть на нижнем уровне, то вы можете им и по сути не пользоваться, используя всё пространство LVM под один раздел, но главное — что он есть, т.е. при надобности можно будет ужать файловую систему, переразбить диск иначе, создать новые подразделы и т.д., причём всё это будет делаться без переноса всех данных на третий носитель. Если же на нижнем уровне (внутри первого LUKS) LVM'а нет, то без полного временного переноса данных куда-то и полной переразбивки диска не обойдётся. С учётом того, что 2 TB — слишком большой объём данных, вероятность того, что вам рано или поздно захочется большей гибкости в управлении этими данными, стремится к единице. В общем, не повторяйте чужих ошибок. Лучше потратить лишние день-два, чтобы разобратья с LVM (делов-то — тройку лишних команд ввести: pvcreate, vgcreate и lvcreate), чем потом годами негодовать по поводу «сложившегося порядка вещей на диске». Ну, и не стоит забывать про вечное «нет ничего более постоянного, чем временное».


Если это внешний диск, работающий по USB 2.0, то на 5 суток:

2*1024*1024*1024*1024/(5*1024*1024)/3600/24 ≈ 4.85,

т.к. urandom, судя по моему опыту, больше 5MB/sec почему-то не даёт. И, вообще, есть ограничения на скорость USB, её не предололеть. Скорей всего, именно она будет самым узким местом при заполнении диска.


Нет, нет здесь никакой вложенности процедур. Заполнять нулями надо /dev/mapper/some_name, а потом этот LUKS-раздел уничтожить переформатированием, после чего создать новый на этом же месте (а не внутри предыдущего!), грубо говоря.
— cyber_beard (02/03/2014 13:59)   <#>
Если LVM есть на нижнем уровне, то вы можете им и по сути не пользоваться, используя всё пространство LVM под один раздел, но главное — что он есть, т.е. при надобности можно будет ужать файловую систему, переразбить диск иначе, создать новые подразделы и т.д., причём всё это будет делаться без переноса всех данных на третий носитель.

Тогда последовательность будет такой?
1.) форматируем

2.) Открываем LUKS:

Появляется диск /dev/mapper/lvm/
3.) Создаем на нем физический раздел

4.) Создаем группу томов

5.) Создаем логические разделы внутри, исходя из объема 2Gb(например, 2 раздела по 500Gb + 1 раздел всё остальное, т.е. около 1Gb):

6.) Далее каждый форматируем:

7.) И монтируем как обычно, т.е.


Правильно?

Благодарю за совет по поводу LVM, но не совсем понятно:
судя по этому
назначить разные пароли к разным виртуальным разделам

Вы говорите про LUKS on LVM.
А судя по этому
Если же на нижнем уровне (внутри первого LUKS)

Вы пишите об LVM on LUKS.
Если исходить из моих потребностей, то допускаю возможность поделить диск на несколько разделов с разными паролями. Но в таком случае было бы лучше делать LUKS on LVM, т.е. создавать LVM сначала, а потом уже форматировать каждый раздел под LUKS. Это даст возможность в случае необходимости изменить конфигурацию не сносить с диска вообще всё.
С другой стороны, в случае с LVM on LUKS нравится то, что можно скрыть вообще всю структуру разделов диска, когда LUKS закрыт.
Подитожу вопросы:
1.) О каком типе использования LUKS и LVM Вы пишите, когда пишите о преимуществах LVM? Сначала LVM, а потом LUKS?
2.) При каком подходе LVM все же больше преимуществ с точки зрения добавления новых носителей?
3.) Правильна ли моя последовательность команд, указанных выше?
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3