Вопрос по шифрованию

EsTaF

Contributor
Joined
Sep 20, 2013
Messages
163
Всем добрым людям привет. То же, добрый.
Возник вопрос по шифрованию носителей, посредством geli сабжа, а именно - при каких условиях сохраняется конфиденциальность данных? Может я чего не до конца понимаю, но не давече, как позавчера, словил очень забавный случай со всем этим хозяйством.
Хронология.
В конце 18го решил перейти на шифрованный вариант хранения инфы. Мои действия:
1. Объединил два диска в массив raid1, посредством zfs и добавил в пул. При добавлении указал визарду в веб морде FreeNAS 11.2-u1, что хочу все это дело зашифровать. Система после шифрования предложила сохранить ключ восстановления, что и было сделано.
2. Ключ был сохранен на внешний носитель с veracrypt контейнером и фс ntfs. Сохранение производилось через веб морду все той же системы FreeNAS. Носитель был пристегнут к другому компьютеру, с которого и заходил на FreeNAS. Ключ сохраняем с именем geli01.key.
Смотрю я на все это дело и понимаю, что без пароля оно как-то уж очень специфично безопасно, аля все держится не на супералгоритмах шифрования geli, а на границе защиты входа юзера в систему. Это далеко не geli. Эта же защита работает на всех BSD ОС и имеет собственную стойкость. С какими ограничениями такая стойкость - глобально, все ок. Локально - злоумышленник, имея физический доступ к устройству, попросту "подчрутит" окружение под себя, сменит пароль и ... профит. Ему даже не понадобится пробираться к запущенному устройству по сети, по смб, или еще как.
3. Я, логично полагая, что тут поможет пароль на такой пул, задал пароль и еще раз сохранил ключ восстановления, как в пункте 2.
Теперь, что бы поиметь доступ к данным, нужно будет ввести пароль при загрузке устройства, подумал я. Ок. Так как бы все и происходило.
4. Сохраняем конфиг db. FreeNAS web ui>System>general>save config. Сохраняю конфиг 11.2-u1.db.

Прошло некоторое время и вышло обновление 11.2-u2. Обновляемся до 11.2-u2. Имеем проблем с джейлами. Не суть. Откатываемся назад - 11.2-u1 fresh install. Восстанавливаемся с конфига.

5. Пробуем подмонтировать шифрованный пул и имеем проблему.
"[middleware.notifier:20261] Importing tank [xxxxxxxx....] failed with: cannot import "xxxxxxxx....": no such pool available."
Не вникая сильно в нюансы, удаляем из системы пул.
6. Визард удаления предлагает сохранить ключ восстановления. Сохраняем его под именем 000.key.
7. Пробуем снова добавить пул. Указываем диски пула в визарде. Указываем ключ geli01.key. Пишем пароль, которым обычно открывали пул. Имеем проблему присоединения.
Code:
Error: Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/middlewared/job.py", line 332, in run
    await self.future
  File "/usr/local/lib/python3.6/site-packages/middlewared/job.py", line 363, in __run_body
    rv = await self.middleware.run_in_thread(self.method, *([self] + args))
  File "/usr/local/lib/python3.6/site-packages/middlewared/main.py", line 1041, in run_in_thread
    return await self.loop.run_in_executor(executor, functools.partial(method, *args, **kwargs))
  File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.6/site-packages/middlewared/schema.py", line 668, in nf
    return f(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/middlewared/plugins/disk.py", line 258, in decrypt
    raise CallError(f'The following devices failed to attach: {", ".join(failed)}')
middlewared.service_exception.CallError: [EFAULT] The following devices failed to attach: gptid/f4aaa779-272f-11e9-8f12-002590d29258, gptid/4409ec70-1c1b-11e9-a174-002590d29258

Перегружаем ось и пробуем снова. Безрезультатно. И тут мне идиоту приходит на ум не вводить пароль. Откуда эта мысль и почему, не важно) Просто подумал так попробовать. И вуаля - пул монтируется. данные видны.
Чего я не пробовал делать, так это подкладывать второй ключ - 000.key. Если и с ним произошла такая же песня, то это аут. Будет достаточно иметь физический доступ к устройствам. Ни паролей при себе, ни ключей иметь не понадобится.

Собственно, вопрос. Чего я не учел, что у меня так просто получилось открыть пул?
 

mav@

iXsystems
iXsystems
Joined
Sep 29, 2011
Messages
1,428
Тут речь все-же о NAS -- устройстве постоянно обеспечивающем доступ к данным по сети, тоесть данные должны быть постоянно расшифрованы и доступны, тоесть шифрование никак не рассчитано защищать от злоумышленника физически добравшегося до работающего сервера. Есть две причины использовать шифрование: 1) защита от утечки данных при замене отказавшего диска, и тогда пароли вообще не нужны, нужно лишь загрузочный диск уничтожить при списании серсера или просто выкинуть его в другой мусорник, и 2) защита от кражи всего сервера, тогда конечно нужны пароли, но появляется геморой с их вводом каждый раз при загрузке. Я не готов сказать почему ключи восстановления пишутся без паролей и правда ли так, не моя область, но вообще говоря ключи восстановления должны храниться отдельно от системы, где-то в железном сейфе. Пароль на самом деле используется для шифрования ключа, а не непосредственно данных, потому его можно при желании менять и (зная старый конечно) снять совсем.
 

EsTaF

Contributor
Joined
Sep 20, 2013
Messages
163
ключи восстановления должны храниться отдельно от системы, где-то в железном сейфе. .
Ну, так ап чем и речь. А данный случай вводит в ступор - при удалении пула система предлагает, сохранить ключ. То бишь, ну забетонировал я ключ в сейфе и? Злоумышленнику не понадобится лезть в сейф - система сама ему предложит снова ключ. Этим же ключом он и откроет пул.
Во всей этой истории защищает лишь одно но, если оно присутствует - ключ, который мы сохраняем при открытом пуле, отличается от некоего аварийного ключа, который нам предлагает система при удалении пула из системы. Если это не так, то остается один случай, где эта вся защита будет работать, а именно - у злоумышленника не будет под рукой загрузочного носителя, который обычно работал с пулом. То бишь, да - если мы избавляемся от убитого физического диска.
Что же касаемо сети. Доступа извне, то тут смысл шифрования устройств вообще какой. Если стоит пароль на вход, то какая разница. Шифровано устройство, или нет. Оно все равно декриптовано при открытии. Вся защита переносится на стойкость smb/nfs/etc.
Смысл же был обезопасить данные от воришек и при этом не городить отдельные файловые контейнеры.
 

mav@

iXsystems
iXsystems
Joined
Sep 29, 2011
Messages
1,428
Как я сказал, если ключ защищен паролем, то он им шифрован и без пароля расшифровать его невозможно, равно как и экспортировать его без пароля. Но если же пароль уже введен при загрузке/импорте пула, то расшифрованный master ключ уже в памяти сервера и с ним можно делсть все что угодно, например, добавить к пулу второй user ключ без пароля и сохранить его как ключ восстановления, что собственно и делается в той ситуации. Если интересны технические детали шифрования -- почитайте `man geli`.
 

EsTaF

Contributor
Joined
Sep 20, 2013
Messages
163
Более просто:
Бэкапим ключ при закрытом контейнере - понадобится пароль.
Бэкапим ключ при открытом конт.. - пароль вводить при открытии не нужно.
Так?
 

mav@

iXsystems
iXsystems
Joined
Sep 29, 2011
Messages
1,428
Бакапный ключ во FreeNAS всегда создается без пароля. Но вот создать его при закрытом контейнере без пароля невозможно.
 

EsTaF

Contributor
Joined
Sep 20, 2013
Messages
163
1. Только сейчас закрыл контейнер.
2. Попробовал отключить пул. До продолжения отсветилась такая большая большая красная кнопка по теме экспорта ключа.
3. Сделал экспорт.
как понял, без пароля этим ключом не воспользоваться.
Ясно. Ну, тогда вопросы снимаются.
Спасибо болшущее за разъяснение.
 

EsTaF

Contributor
Joined
Sep 20, 2013
Messages
163
Снова по-новой
теперь и без пароля.
Code:
File "/usr/local/lib/python3.6/site-packages/middlewared/job.py", line 332, in run
    await self.future
  File "/usr/local/lib/python3.6/site-packages/middlewared/job.py", line 365, in __run_body
    rv = await self.middleware.run_in_thread(self.method, *([self] + args))
  File "/usr/local/lib/python3.6/site-packages/middlewared/main.py", line 1005, in run_in_thread
    return await self.loop.run_in_executor(executor, functools.partial(method, *args, **kwargs))
  File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.6/site-packages/middlewared/schema.py", line 668, in nf
    return f(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/middlewared/plugins/disk.py", line 253, in decrypt
    raise CallError(f'The following devices failed to attach: {", ".join(failed)}')
middlewared.service_exception.CallError: [EFAULT] The following devices failed to attach: gptid/f4aaa779-272f-11e9-8f12-002590d29258, gptid/4409ec70-1c1b-11e9-a174-002590d29258



Про "Перегружаем ось и пробуем снова. Безрезультатно. И тут мне идиоту приходит на ум не вводить пароль. Откуда эта мысль и почему, не важно) Просто подумал так попробовать. И вуаля - пул монтируется. данные видны."
не ввожу пароль - та же ругань.

Как быть, люди?
 
Last edited:

EsTaF

Contributor
Joined
Sep 20, 2013
Messages
163
Действия. Если вкратце - замена флешки.
Сохраняем конфиг. Ставим систему на новую флешку.
аплоадим конфиг.
Пробуем монтировать зашифрованный пул через gui - "
Error Unlocking
[object Object]"
отключаем пул (все в gui) с сохранением ключа. Пароля не просят.
монтируем. вставляем ключ. аплоадим. пароль не вводим. имеем выше оговоренную проблему.
с паролем та же песня. ругань один в один.
 
Last edited:

EsTaF

Contributor
Joined
Sep 20, 2013
Messages
163
мда..
надо было держать все в truecrypt/veracrypt контейнерах. сам виноват. соблазнился на удобства zfs и geli.
Все делал правильно. По инструкции. и так попасть.
 

EsTaF

Contributor
Joined
Sep 20, 2013
Messages
163
Проблема решена.
Снес пул и поставил обычный.
 
Top