Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
Вот бы кто ещё придумал как сделать туда внутрь раздел с загружаемой виндой
qemu/kvm? В принципе, можно заморочиться и сделать pci-passthrough видеокарты. А блочное и сетевое IO — через хост-систему. Общаться с ней можно будет либо по сети (с другой машины), либо через последовательный порт.
Ды что то сложно. Речь про вторую ос для поиграть, в основном. Это к тому что ей бы полноценно загружаться, а не внутри виртуальной машины.
Причём, принципиально проблем нет, я так понял — был же fde в том же truecrypt.
Просто нет кроссплатформенного решения почему то
Причём, принципиально проблем нет, я так понял — был же fde в том же truecrypt.
Просто нет кроссплатформенного решения почему то
Я с трудом себе представляю такую схему. Особенно в контексте винды, у которой свой загрузчик.
Схема то как раз представима.
— Windows может быть зашифрована до уровня «запрос пароля на уровне загрузчика» при помощи truecrypt
— Linux может быть зашифрован до уровня «запрос пароля на уровне загрузчика» десятком (наверное) способов
Если я правильно помню про truecrypt, оно там чуть ли не в роли прослойки между ос и оборудованием должно было выступать.
Просто реально неудобно что с какой то одной ос ты себе можешь fde организовать, а на две — неа
— Windows может быть зашифрована до уровня «запрос пароля на уровне загрузчика» при помощи truecrypt
— Linux может быть зашифрован до уровня «запрос пароля на уровне загрузчика» десятком (наверное) способов
Если я правильно помню про truecrypt, оно там чуть ли не в роли прослойки между ос и оборудованием должно было выступать.
Просто реально неудобно что с какой то одной ос ты себе можешь fde организовать, а на две — неа
Весь диск шифровать LUKS — это оверкилл…
Как правило, /home выносят на отдельный раздел и шифруют только его, тк всё остальное обычно не представляет особого интереса с точки зрения утечки данных.
Как правило, /home выносят на отдельный раздел и шифруют только его, тк всё остальное обычно не представляет особого интереса с точки зрения утечки данных.
Всё-таки, обычно, если учесть массовость использования коробочных решений, шифруют весь диск кроме /boot.
Что же касается излишества — зависит от того, что и где вы храните и как сильно у вас развита паранойя. Я вот даже /etc/wpa_supplicant.conf отдавать никому не хочу.
Кроме того, подобный подход позволяет вводить пароль только один раз, без ущерба для безопасности (конечно, если с данным ноутом работает только один человек) так, как если кто-то сможет обойти luks, остальные пароли его даже не затормозят.
Что же касается излишества — зависит от того, что и где вы храните и как сильно у вас развита паранойя. Я вот даже /etc/wpa_supplicant.conf отдавать никому не хочу.
Кроме того, подобный подход позволяет вводить пароль только один раз, без ущерба для безопасности (конечно, если с данным ноутом работает только один человек) так, как если кто-то сможет обойти luks, остальные пароли его даже не затормозят.
> Я вот даже /etc/wpa_supplicant.conf отдавать никому не хочу.
Если у вас паранойя, это еще не значит, что за вами никто не следит)))
Если у вас паранойя, это еще не значит, что за вами никто не следит)))
Если у вас развита паранойя, то вы должны понимать, что нет разницы между «нешифрованным /usr» и «нешифрованным /boot».
Алсо, отдельные пароли на ssh и gpg-ключи и менеджер паролей — must have.
Алсо, отдельные пароли на ssh и gpg-ключи и менеджер паролей — must have.
Вы совершенно не правы. Если вы опасаетесь не только случайного разглашения данных, но и [зло-]умышленного, то вам следует защитить не только домашнюю директорию, но и всю систему, в которую злоумышленник может попытаться установить считыватель клавиатурных нажатий или ещё какой-нибудь зловред.
Другими словами, если вы догадываетесь, что данные на вашем ноутбуке представляют интерес для, скажем так, товарищей майоров из спец.служб враждебных к вам стран, то сделайте так, чтобы им сложнее было поставить вам кейлогер.
Другими словами, если вы догадываетесь, что данные на вашем ноутбуке представляют интерес для, скажем так, товарищей майоров из спец.служб враждебных к вам стран, то сделайте так, чтобы им сложнее было поставить вам кейлогер.
спец.служб враждебных к вам стран
Мы тут говорим про установку кейлоггера при физическом доступе к устройству, так?
От удаленной установки через уязвимость описанное в статье шифрование не спасёт.
А при физическом доступе они поставят физический кейлоггер.
Бла-бла-бла, сколько раз уже обсуждалось, что все эти пароли на разделы, на вход просто сходят на нет, когда достают паяльник…
Если действительно возможна ситуация, что к тебе придут и будут тебя трясти, то тебя расколют (если ты конечно не крепкий орех). А если такая ситуация не возможна, то зачем напрягаться к таким сложностям?
Если действительно возможна ситуация, что к тебе придут и будут тебя трясти, то тебя расколют (если ты конечно не крепкий орех). А если такая ситуация не возможна, то зачем напрягаться к таким сложностям?
/var/www тоже не хотелось бы потерять) да и бдшки) или у вас всё в /home?)
На незашифрованный бук могут еще и подкинуть веществ, ой, я хотел сказать анимэ или порнографии в школьной униформе. Или по мелочи напакостят — пару фоток с «фошыстами» загрузят — так, на административку. Причем их даже распространять не надо, достаточно во время обыска (по любой другой причине) найти их на харде.
> я не использую UEFI
Имелось в виду GPT?
Имелось в виду GPT?
Имелось в виду UEFI. Для загрузки с использованием UEFI создаётся отдельный небольшой раздел.
Этот раздел необходим исключительно для GPT разметки. И я бы не рекомендовал его удалять. В сети ходят слухи (сам лично не проверял), что после удаления EFI раздела невозможно зайти в настройки BIOS/UEFI.
Этот раздел не имеет ничего общего с GPT. Монтируется он в /boot/efi.
Что касается слухов — это только слухи. Я уже проверил на своём ноуте.
Что касается слухов — это только слухи. Я уже проверил на своём ноуте.
Вроде и статью прочитал, но не могу понять, как это работает.
Сначала grub загружается из mbr, это ок.
Но дальше для расшифровки раздела ему нужно получить initrd, который лежит на этом же зашифрованном разделе.
Подскажите, пожалуйста, что я пропустил?
Сначала grub загружается из mbr, это ок.
Но дальше для расшифровки раздела ему нужно получить initrd, который лежит на этом же зашифрованном разделе.
Подскажите, пожалуйста, что я пропустил?
> Я не особо долго искал, но из того, что попалось под руку, загрузку с шифрованного диска поддерживает только Grub2.
Т.е., Grub способен самостоятельно получить доступ к зашифрованному разделу. При попытке доступа, он запрашивает пароль.
После ввода пароля, он получает доступ к необходимым ему файлам, в том числе, ядру и рамдиску.
Далее, Grub загружает ядро и передаёт ему управление. После этого, система так же должна подключить необходимые разделы. В штатном режиме, она так же попросит пароль. Для того, чтобы она не просила пароль, используется luks-ключ, который хранится в initrd.
Т.е., Grub способен самостоятельно получить доступ к зашифрованному разделу. При попытке доступа, он запрашивает пароль.
После ввода пароля, он получает доступ к необходимым ему файлам, в том числе, ядру и рамдиску.
Далее, Grub загружает ядро и передаёт ему управление. После этого, система так же должна подключить необходимые разделы. В штатном режиме, она так же попросит пароль. Для того, чтобы она не просила пароль, используется luks-ключ, который хранится в initrd.
GRUB_ENABLE_CRYPTODISK=y — правильный вариант.
Правильный, но не всегда работающий.
[user@HOST /tmp/grub-2.00] grep -rE '(GRUB_ENABLE_CRYPTODISK|GRUB_CRYPTODISK_ENABLE)' .
./util/grub-install.in: if [ x$GRUB_CRYPTODISK_ENABLE = xy ]; then
./util/grub-mkconfig.in: GRUB_ENABLE_CRYPTODISK \
./util/grub-mkconfig_lib.in: if [ x$GRUB_CRYPTODISK_ENABLE = xy ]; then
./util/grub-mkconfig_lib.in: if [ x$GRUB_CRYPTODISK_ENABLE = xy ]; then
./ChangeLog: * util/grub-mkconfig.in: Export GRUB_ENABLE_CRYPTODISK.
Похоже, что GRUB_CRYPTODISK_ENABLE — это внутренняя переменная, используемая для генерации конфигов компиляции.
По крайней мере, в грабе Арча GRUB_ENABLE_CRYPTODISK=y.
И вот ещё ссылка на всякий случай, тоже полезная:
http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
По крайней мере, в грабе Арча GRUB_ENABLE_CRYPTODISK=y.
И вот ещё ссылка на всякий случай, тоже полезная:
http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
фигня всё это и игрушки. лучше бы ктонить рассказал о готовой схеме, чтото типа — гдето в сети лежит зашифрованный файл, который монтируется на моём компе и я работаю с ним как с диском. скорость работы… срать! главное, чтоб оно записывало/читало _В РЕАЛЬНОМ_ времени, а не как яндексдиск — создал мне папку и синхронизирует её с облаком. нахера оно такое нада??? почему сразу не монтировать облако в папку????
NBD (Network Block Device) + LUKS вполне решают эту задачу.
iSCSI
Блочное устройство — пожалуйста, буквально три строчки. Можно ceph, можно iscsi/nbd для чего попало.
С файловой системой сложнее — адекватно-шаренных multitenant FS не существует до сих пор, слишком сложно.
С файловой системой сложнее — адекватно-шаренных multitenant FS не существует до сих пор, слишком сложно.
Можно попробовать EncFS. А каталог с зашифрованными файлами монтировать каким-нибудь стандартным способом.
TrueCrypt
Немалая часть дистрибутивов спрашивает «а не зашифровать ли вам диск?» сразу при установке.
Я просто оставлю это здесь: https://github.com/hummelchen/notes/blob/master/full_disk_encryption.md
Если этот вопрос стоит остро, почему бы не вынести все нужное для загрузки на флешку? Ведь могут подменить код, который запрашивает пароль, пока вы не рядом с ноутбуком.
Флешку могут забрать (не всегда спрашивая согласия), её можно потерять, она может сломаться… а если вопрос стоит на столько остро, чтобы привлечь спецалистов, которые за короткий промежуток времени внедрят в код загрузчика кейлогер, чтобы узнать пароль от люкса то… терморектальный криптоанализ (паяльник, утюг и т.д.) позволяет обойти любые пароли куда дешевле и быстрее.
Единственный способ защитить информацию — сделать затраты на её получение несоразмерными с получаемой выгодой.
Единственный способ защитить информацию — сделать затраты на её получение несоразмерными с получаемой выгодой.
нужно мнение знающих людей: что скажете о программе DiskCryptor, как способе зашифровать винт с виндовсом на борту? (хорошо/плохо/альтернативы)
Спасибо
Спасибо
Diskcryptor умеет грузиться с флешки, храня там же ключ (удобно — загрузил машину с флешки, унёс до ребута, никаких паролей). Может грузить левую ОС (пароль под принуждением).
По теме топика —
Вообще, сейчас многие, скажем, SSD (Intel/Samsung) имеют AES шифрование на уровне диска. Что мешает воспользоваться им?
По теме топика —
Вообще, сейчас многие, скажем, SSD (Intel/Samsung) имеют AES шифрование на уровне диска. Что мешает воспользоваться им?
Если ли возможность задать т. н. «пароль под принуждением», с загрузкой совершенно другой системы? Если нет, то и смысла возиться нет — вежливо попросят, сами пароль введете.
Самая, на мой взгляд, большая трудность с «загрузкой совершенно другой системы» заключается в том, что вам придётся этой «подложной» системой регулярно пользоваться, чтобы создать впечатление, что это и есть основная система. Иначе, у товарища майора к вам возникнет совершенно закономерный вопрос, отчего она у вас последний раз запускалась месяц или неделю назад, когда есть свидетельства того, что вы активно пользуетесь ПК.
То есть, придётся каждый день её запускать, сёрфить из неё и так далее.
То есть, придётся каждый день её запускать, сёрфить из неё и так далее.
Кажется, это уже совершенно иная тема. Я описал вариант защиты данных на переносной системе, которую можно «потерять» и при этом, желательно не допустить возможности того, что кто-то воспользуется этими данными.
Вопросы сокрытия хостовой или основной системы — тема абсолютно другая и подобные задачи решаются абсолютно иными средствами. Для решения подобных задач, правда, с серьёзной потерей производительности, как мне кажется, могла бы подойти VMware ESX(i?)… особенно, если её удастся скрестить с тем же LUKS-ом. Но данной темой я не занимался и потому, не могу сказать чего-либо конкретного.
Вопросы сокрытия хостовой или основной системы — тема абсолютно другая и подобные задачи решаются абсолютно иными средствами. Для решения подобных задач, правда, с серьёзной потерей производительности, как мне кажется, могла бы подойти VMware ESX(i?)… особенно, если её удастся скрестить с тем же LUKS-ом. Но данной темой я не занимался и потому, не могу сказать чего-либо конкретного.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Full Disk Encryption (FDE)