devqp
Специалист
Рассмотрим сценарий: к системе добавлен физический диск для хранения конфиденциальных данных с использованием LUKS-шифрования. После настройки происходит внезапное отключение питания без выполнения cryptsetup luksClose. Возникает вопрос: возможен ли доступ к данным без пароля?
Этапы настройки диска:
1. Определение имени диска:
2. Форматирование LUKS-контейнера:
3. Открытие контейнера:
4. Заполнение нулями:
5. Создание файловой системы:
6. Монтирование:
Ключевые риски при незакрытом контейнере:
- Физический доступ к диску: данные остаются зашифрованными, ключи не хранятся на носителе.
- Дамп оперативной памяти: при извлечении DIMM-модулей возможно извлечение мастер-ключа из RAM.
- Runtime-атаки: при работающей системе без аутентификации пользователя уязвимость зависит от уровня доступа злоумышленника и настроек SELinux/AppArmor.
Основная угроза — извлечение ключей из оперативной памяти при физическом доступе к серверу до полного отключения питания.
Этапы настройки диска:
1. Определение имени диска:
Код:
lsblk2. Форматирование LUKS-контейнера:
Код:
cryptsetup luksFormat --type luks2 /dev/sdb3. Открытие контейнера:
Код:
cryptsetup luksOpen /dev/sdb safe_data4. Заполнение нулями:
Код:
dd if=/dev/zero of=/dev/mapper/safe_data status=progress5. Создание файловой системы:
Код:
mkfs.ext4 /dev/mapper/safe_data6. Монтирование:
Код:
mount /dev/mapper/safe_data /home/safe_dataКлючевые риски при незакрытом контейнере:
- Физический доступ к диску: данные остаются зашифрованными, ключи не хранятся на носителе.
- Дамп оперативной памяти: при извлечении DIMM-модулей возможно извлечение мастер-ключа из RAM.
- Runtime-атаки: при работающей системе без аутентификации пользователя уязвимость зависит от уровня доступа злоумышленника и настроек SELinux/AppArmor.
Основная угроза — извлечение ключей из оперативной памяти при физическом доступе к серверу до полного отключения питания.
