[Статья] Использование nuke в Backbox закриптованых LUKSом

Статья написана специально для runion.

В данной статье мы рассмотрим как применить nuke на дистрибутиве Backbox основаной на Ubuntu.

С точки зрения физической безопасности и конфиденциальности, патч nuke для LUKS cryptsetup - я считаю одним из лучших решений. Nuke позволяет сделать наш зашифрованный диск недоступным.

Патч изначально был разработан специально для Kali Linux. В кратце его можно описать как паранойный пароль, который может «убить» зашифрованный диск.

Хоть в данной статье мы будем выполнять все действия на Backbox его также можно использовать для любого другого дистрибутива. Ключевое это убедиться что все зависимости установлены. Помимо этого, наша система должна иметь настроенное полное шифрование диска. А иначе смысл пользоваться паранойным паролем?

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

1. Установка зависимостей

sudo apt-get install libgcrypt11-dev libdevmapper-dev libpopt-dev uuid-dev libtool automake autopoint debhelper xsltproc docbook-xsl dpkg-dev

2. Качаем сорцы cryptsetup:

sudo apt-get source cryptsetup

После завершения операции должен существовать каталог cryptsetup-1.6.1.

3. Качаем nuke:

git clone https://github.com/offensive-security/cryptsetup-nuke-keys. У нас появляется каталог cryptsetup-nuke-keys

4. Применяем патч находясь в скачаной папке cryptsetup 

sudo patch -p1 <../cryptsetup-nuke-keys/cryptsetup_1.6.1+nuke_keys.diff

5. Собираем пакеты:

sudo dpkg-buildpackage -b -uc

После завершения сборки, должны быть установлены два пакета cryptsetup * .deb и два пакета libcryptsetup * .deb

6. Затем установим собраные пакеты:

dpkg -i ../libcryptsetup*.deb

dpkg -i ../cryptsetup*.deb

7. Добавим ключ nuke в систему, набрав

cryptsetup luksAddNuke /dev/sdaX

Заменим «X» на номер зашифрованного раздела в нашей системе. Увидим сообщение: «Введите любую существующую парольную фразу». Вводим наш действующий пароль. После этого вам будет предложено ввести и подтвердить фразу nuke.

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

Красивая фича, давно ее не хватало LUKS'у "из коробки". С другой стороны, практическая полезность у нее низкая, т.к. в случае возникновения любого практического интереса к данным, лучшие практики рекомендуют сначала снять полный цифровой образ их носителя, а уже потом - пытаться разными методами узнать пароль. Каждый (!) побывавший в моих руках материал по компьютерной криминалистике особенно акцентирует момент, что данные на оригинальном носителе всегда могут быть изменены или уничтожены. Поэтому решение получилось как и многое в "стоковой" Kali Linux - обращает на себя внимание, но в жизни в чистом виде без доработок малоприменимо.

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

Да, есть такое, в том то и проблема информации вообще. Ее тяжело защитить от копирования или даже невозможно. Звукозаписывающие студии борятся с копированием музыки, кто снимает фильмы не могут найти универсальное решение от копирования их фильмов.

Но с паранойным паролем лучше, чем без него. А лучше не попадаться, и быть всегда чистым или быть готовым все уничтожить. А еще лучше ничего плохого не мутить и идти работать на завод.

Спасибо, действительно все расписано.

А разве эта задача хоть в теории имеет решение?
Всё, что можно увидеть глазами — можно увидеть не только ими.

То есть, если я правильно понимаю, ничего специфического для отдельного дистрибутива нет - и таким образом это должно прекрасно сработать с любым дистрибутивом на базе свежей ubuntu lts и проапгрэйдить таким образом без проблем можно уже установленную с помощью cryptsetup систему - просто после сборки и обновления пакетов добавляется новый функционал, так?

Верховцев, все верно, но рекомендую сначала, протестировать ваш дистр на виртуальной машине.

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

Зафигачить в автозагрузку скрипт, который при вводе некой заданной фразы тупо обнуляет заголовок тома?..

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

Ненадежно это все, демоны на баше. Пишешь обертку, чтоб при open фраза писалась в переменную, сверяешь ее с заранее заданным хешем например, и если че затираешь заголовок. Остальные параметры пускаешь как есть напрямую, сам скрипт называешь cryptsetup, кладешь в /usr/bin, оригинал называешь как хочешь и уже его вызываешь в скрипте.

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

Полез в документацию по LUKS - обнаружил возможность использования ключевых файлов. Не очень понял про 2048 bit - файл обязан быть 2048 размером или будут использованы первые 2048 бит? Насколько помню доку по трукрипту - ключевой файл может быть любой, но для шифрования используются сколько-то там первых бит. Тут аналогично?

В целом наиболее правильно, если ключ физически находится где-то далеко. Но, если я правильно понимаю, crypttab обрабатывается раньше fstab (по крайней мере в моей системе разделы fstab берутся уже из /dev/mapper, а значит ранее они там должны появиться из crypttab) - и зашифровать корневой раздел с использованием монтируемого по сети ключа не получится, так как раздел должен монтироваться раньше, чем есть возможность подцепить что-то внешнее по nfs или sshfs?

cryptsetup --help
Default compiled-in key and passphrase parameters:
	Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)

Тык.