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