Рубрика «luks»

Полнодисковое шифрование Windows Linux установленных систем. Зашифрованная мультизагрузка - 1

Обновленное свое же руководство по полнодисковому шифрованию в рунете V0.2.

Ковбойская стратегия:

[A] блочное системное шифрование Windows 7 установленной системы;
[B] блочное системное шифрование GNU/Linux (Debian) установленной системы (включая /boot);
[C] настройка GRUB2, защита загрузчика цифровой подписью/аутентификацией/хэшированием;
[D] зачистка — уничтожение нешифрованных данных;
[E] универсальное резервное копирование зашифрованных ОС;
[F] атака <на п.[C6]> цель — загрузчик GRUB2;
[G] полезная документация.

╭───Схема #комнаты 40# <BIOS/MBR/1HDD без lvm>:
├──╼ Windows 7 установленная — шифрование полное системное, не скрытое;
├──╼ GNU/Linux установленная (Debian и производные дистрибутивы) — шифрование полное системное не скрытое(/, включая /boot; swap);
├──╼ независимые загрузчики: загрузчик VeraCrypt установлен в MBR, загрузчик GRUB2 установлен в расширенный раздел;
├──╼ установка/переустановка ОС не требуется;
└──╼ используемое криптографическое ПО: VeraCrypt; Cryptsetup; GnuPG; Seahorse; Hashdeep; GRUB2 – свободное/бесплатное.Читать полностью »

Зачем вообще люди шифруют диски своих персональных компьютеров, а иногда — и серверов? Понятное дело, чтобы никто не украл с диска фотографии их любимых домашних котиков! Вот только незадача: зашифрованный диск требует при каждой загрузке ввести с клавиатуры ключевую фразу, а она длинная и скучная. Убрать бы ее, чтобы хотя бы иногда не приходилось ее набирать. Да так, чтобы смысл от шифрования не потерялся.

Котейка для привлечения внимания

Котейка

Ну, совсем убрать ее не получится. Можно вместо нее сделать ключевой файл на флешке, и он тоже будет работать. А без флешки (и без второго компьютера в сети) можно? Если повезло с BIOS, почти можно! Под катом будет руководство, как настроить шифрование диска через LUKS вот с такими свойствами:

  1. Ключевая фраза или ключевой файл нигде не хранится в открытом виде (или в виде, эквивалентном открытому) при выключенном компьютере.
  2. При первом включении компьютера требуется ввести ключевую фразу.
  3. При последующих перезагрузках (до выключения) ключевую фразу вводить не требуется.

Инструкции проверены на CentOS 7.6, Ubuntu 19.04 и openSUSE Leap 15.1 в виртуальных машинах и на реальном железе (десктоп, ноутбук и два сервера). Они должны работать и на других дистрибутивах, в которых есть работоспособная версия Dracut.

И да, по-хорошему, это должно было бы попасть в хаб "ненормальное системное администрирование", но такого хаба нет.

Читать полностью »

Взлом и защита шифрования дисков LUKS - 1

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

Всем доброго дня, ночи! Этот пост будет полезен тем, кто используется шифрование данных LUKS и хочет производить decryptдешифровку дисков под Linux (Debian, Ubuntu) на стадии расшифровки root раздела. И такой информации в интернете я найти не смог.

Совсем недавно с увеличением количества дисков в полках, столкнулся с проблемой расшифровки дисков с использованием более чем известного метода через /etc/crypttab. Лично я выделяю несколько проблем использования этого метода, а именно то, что файл читается только после загрузки (mount) root-раздела, что негативно сказывается на импорте ZFS, в частности если они были собраны из разделов на *_crypt устройстве, или же mdadm рейды, собранные так же из разделов. Мы же все знаем, что можно использовать parted на LUKS контейнерах? И также проблема раннего старта других служб, когда массивов еще нет, а использовать уже что-то надо (я работаю с кластеризованным Proxmox VE 5.x и ZFS over iSCSI).

Немного о ZFSoverISCSI

iSCSI работает у меня через LIO, и собственно когда стартует iscsi-таргет и не видит ZVOL устройств, он их просто-напросто удаляет из конфигурации, что не дает возможности загружаться гостевым системам. Отсюда либо восстановление бэкапа json файла, либо ручное добавление устройств с идентификаторами каждой VM, что просто ужас, когда таких машин десятки и в конфигурации каждой более 1 диска.

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

Список статей и литературы про NAS - 1

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

В этой статье собраны ссылки на большую часть материалов, которые я использовал. По мере накопления и обработки материалов, тут может появиться что-то новое.

Читать полностью »

В данном посте вы прочитаете немного о моих странных изыскания во время вынужденного отпуска по болезни. Речь пойдёт сразу о нескольких вещах, которые не являются «best practice», но так же тоже можно! Итак, здесь будет туториал о том, как установить Archlinux(мой любимый дистр) так, чтобы:

  • без отдельного /boot (просто в /root)
  • / на lvm
  • lvm внутри luks-контейнера
  • с UEFI
  • в виртуальной машине.
  • с secure boot(«сложна», в виртуалке вряд ли получится)

Примечательно, что зашифровано будет всё, кроме EFI system partition с единственным файлом grubx64.efi — EFI-приложением для запуска grub.

Если заинтересовались, — добро пожаловать под кат!
Читать полностью »

Цикл статей: построение NAS, либо домашнего мини-сервера - 1

Как видно из новостей, облака и крупные компании — это удобно и надёжно, но далеко не всегда:

Так что, кормить облачные сервисы хорошо, но в некоторых случаях "своя рубашка ближе к телу".

Изначально, одной из моих целей являлось исследование построения собственной системы, в частности NAS с возможностью работы "домашним сервером".

Постепенно возникла идея, что в свете недавних событий, информация такого плана интересна, и неплохо бы аккумулировать её в одном месте, структурировать и дополнить.
В итоге, должно сформироваться что-то вроде общедоступных best practices для энтузиастов, начиная от выбора и сборки железа и заканчивая программным обеспечением.

Данная статья является оглавлением к статьям по построению NAS.

Читать полностью »

image

Предисловие

В связи с необходимостью работать в другом городе, пришлось приобрести ноутбук.
Постепенно, назрела проблема синхронизации его и стационарной машины.
Несмотря на то, что все мои проекты ведутся в гите, не весь код полностью мой, и не хочется его выкладывать на гитхаб.

Для решения этой проблемы, я начал строить свой NAS, который даст мне, ко всему прочему, дополнительные возможности.

Изучив, какие сейчас имеются ОС для решения данной задачи, я пришёл к выводу, что изо всего многообразия, наиболее развиты, широко используемы и, следовательно, проработаны, FreeNAS на основе FreeBSD и OpenMediaVault на основе Debian, созданный одним из разработчиков FreeNAS.

FreeNAS стабилен, удобен, гибок и вообще хорош, но попытавшись его поставить, вместо FreeBSD bsdinstall, я увидел совершенно урезанный инсталлятор, в котором я могу только выбрать диски и ввести пароль root: даже разметить диски нельзя.
GELI мне понравился больше cryptsetup на Linux, как и BSD-шный parted.
Попытавшись сделать root на шифрованном разделе, я понял, что эта задача нетривиальна, несмотря на то, что они уже используют root на ZFS.
Затем, пообщавшись, с сообществом FreeNAS, которые стали доказывать, что FreeNAS — не ОС, а приложение, я решил установить OMV.

К тому же, Debian — моя основная ОС и с Linux дела обещали быть проще...

Выяснилось, что не совсем. Задача создания такой конфигурации, как у меня, совсем не тривиальна. Потому, я решил написать данную статью.

Читать полностью »

Статья для подписчиков LWN

Стратегии офлайнового хранения ключей PGP - 1Хотя население в целом практически не использует OpenPGP, но это критический элемент безопасности, особенно для дистрибутивов Linux. Например, центральный репозиторий Debian проверяет каждый пакет с помощью OpenPGP-ключей мейнтейнера, а затем подписывает его своим ключом. Если у пакетов, которые включаются в ветку, тоже есть такие подписи, то создаётся полноценная цепочка доверия от изначального разработчика до пользователей. Кроме того, пулл-реквесты в ядро Linux тоже верифицируются цифровыми подписями. Поэтому ставки высоки: если скомпрометирован ключ для подписи релиза или хотя бы ключ единственного мейнтейнера, следствием может стать разрушительная атака на много машин.

Это привело сообщество Debian к лучшему пониманию хороших практик работы с криптографическими подписями (которые обычно создаются в программе GNU Privacy Guard, также известной как GnuPG или GPG). Например, слабые (менее 2048 бит) и уязвимые ключи PGPv3 в 2015 году удалили из связок ключей, а среди разработчиков Debian широко распространена практика взаимной подписи ключей при личной встрече. Но даже у разработчиков Debian, кажется, отсутствуют общепринятые правила хранения критического секретного материала, как видно по дискуссии в списке рассылки debian-project. Эта дискуссия сводится к единственному простому требованию: где взять «руководство по хранению электронных ключей для чайников»? Электронные аппаратные ключи или карты-ключи, как мы их здесь называем — это маленькие устройства, позволяющие хранить ключи в офлайне и представляющие собой один из вариантов защиты секретного материала, то есть ключа. В этой статье я постараюсь поделиться своим опытом в данной области и разъяснить проблему, как хранить эти драгоценные секретные ключи, которые в случае компрометации подвергают опасности миллионы компьютеров по всему миру.
Читать полностью »

Часть 3: Yubikey 4 и LUKS

Двухфакторная аутентификация при монтировании зашифрованного раздела LUKS с помощью Yubikey 4 - 1

Введение

В статье рассматривается реализация двухфакторной аутентификации с помощью ключа Yubikey 4 для монтирования зашифрованного раздела LUKS.

Процесс реализации двухфакторной аутентификации с помощью ключа Yubikey 4 для монтирования зашифрованного раздела LUKS можно разбить на три части:

1. Подготовка LUKS раздела.
2. Подготовка к использованию ключа Yubikey 4 в операционной системе.
3. Непосредственно использование ключа Yubikey 4 для двухфакторной аутентификации.

Начальные условия:

  • Linux Mint 18 Sarah 64-bit
  • Yubikey 4

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js