Маскировка ввода пароля в cryptsetup
Форумчане, скажите, можно ли сделать в Crytpsetup затирание вывода консоли при вводе пароля на загрузку?
Как в TrueCrypt – фейковая ошибка, например "Invalid BOOT.INI file Booting from C:windows", таким образом ввести в заблуждение по поводу установленной системы и не реагировать на ввод неправильных паролей.
Спасибо
комментариев: 9796 документов: 488 редакций: 5664
Здесь был гипероффтоп. Пусть он будет там.
комментариев: 9796 документов: 488 редакций: 5664
Вы хотите бессигнатурно шифровать, делать множество нетривиальных вложений томов и т.д. В Debian был баг-репорт, что при даже не самом навороченном вложении шфированных томов некая матрёшечная конструкция некорректно отмонтировалась при poweroff и накапливались ошибки. Тогда что-то пофиксили. Если вы городите что-то очень своё, то есть шанс поиметь проблемы с потерей доступа к данным после очередного выключения, обновления и т.д. Не говоря уже об общей оценке затрат сложности персонального поддержания на некоторые самопальные неискоробочные решения.
Даже при стандартном полнодисковом шифровании он не мог корректно всё отмонтировать и удалить ключи из памяти, а при таком — тем более, поэтому, по-хорошему, всё критическое надо перед выключением отмонтировать самостоятельно (а также удалять ключи из памяти). В идеале — зачищать оперативную память перед выключением, как это можно сделать при желании из настроек Tails.
К счастью, журналирование в ФС есть, это сильно спасает дело, но и бэкапы никто не отменял, естественно.
Угрозы со временем только растут, атаки становятся только сильнее, поэтому, чтобы сохранять паритет с противником и быть хотя бы на один шаг впереди, нужно развиваться и совершенствовать защиту.
комментариев: 1079 документов: 58 редакций: 59
Ну, к примеру сделать openssl rand -base64 16384, записать его на флешку и при включении компьютера система будет требовать его и ввод пароля?
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 1079 документов: 58 редакций: 59
Обычно всё же нет. Во-первых, /boot, как правило, на том же диске, который и шифруется, а не на внешнем носителе, а, во-вторых, cryptsetup обычно работает без каких-либо ключевых файлов. Конечно, всё это можно наворотить при желании самому.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
См. /usr/share/doc/cryptsetup/examples.
Просто штатное полнодисковое шифрование — оно не для параноиков, посторонний внешний носитель для загрузки ещё таскать — неудобно, поэтому вот так. ☺
Только хотел сказать, что --key-file — это не произвольный файл, а файл для пассфразы, поэтому для двухфакторной аутентификации, видимо, понадобятся костыли (в отличие от того же cgd, где это по умолчанию делается всегда и штатно). Собственно, да, в examples приведён пример костыля. ☺ Кстати, тут это уже обсуждалось.
Патчи к пунктам про общую (неупрощённую) схему бессигнатурки
Плохой вариант. Обманка, в которой ничего не шифруется, позволяет проследить каждый шаг пользователя, выполненный в обманке: когда систему грузили, что делали, откуда что скачивали и т.д. и т.п. Следов будет полный воз, и по ним точно можно сказать, что система фиктивная. Кроме того, какие бы нейтральные вещи под ней ни делались, это всё равно будет утечкой информации.
Вместо этого в качестве обманки можно взять какой-нибудь Live-USB и записать его на диск подобно этой инструкции. Брать Tails — значит, подчёркивать осведомлённость в некоторых технологиях, но можно взять какой-нибудь нейтральный Live-образ. В принципе, его можно создать даже самому под свои нужды. Ничего такого туда устанавливать не надо, но в довесок можно (по аналогии всё с той же инструкцией) сделать для обманки отрицаемый скрытый раздел, из которого после запуска системы можно каждый раз доустанавливать нужный софт (Tor, macchanger или ещё что-то специфичное) и подключать какие-то нейтральные данные. Если отрицаемый скрытый раздел не подключается, будет обычная нормальная рабочая Live-система с ограниченными возможностями. К ней можно даже сделать обманный нешифрованный раздел с нейтральными данными, но он, в принципе, будет вреден: будет видна частота изменения данных, когда последний раз монтировали систему и т.д.
Live-система ничего не пишет на диск во время работы (это можно уточнить, сверив хэши образов до и после её работы) и обладает легендой: вместо того, чтобы обновлять систему для устранения уязвимостей, достаточно использовать Live-образ, где все изменения сбрасываются перезагрузкой. На самом деле, всё не совсем так (полностью скомпрометированная Live-система с правами рута позволит поменять данные на диске), но это уже тонкости. Во всяком случае, такой метод безопасности есть и часто используется разными людьми в разных случаях.
openssl не нужен, как уже выше, кажется, отмечалось. Достаточно бессигнатурного cryptsetup'а с адресацией нужных блоков, а внутри него сделанной ФС с данными. Это делается проще, из коробки, и в целом оно более безопасно/надёжно.
Как ясно из этого треда и вышеприведённых обсуждений, «live» тут не нужен. Скрытая система — полноценная система, установленная куда-то там внутрь матрёшки из LVM'ов и cryptsetup'ов. Системе всё равно, куда она установлена, лишь бы был правильный загрузочник и /etc/fstab.
Ввиду вышесказанного патча к п. 2, посторонние LiveCD/LiveUSB не нужны — вместо них можно воспользоваться обманкой, раз она тоже будет Live-системой. Основное требование к обманке — то, что по ней не должно быть возможным сказать, сколько раз её грузили, как долго в ней работали, какие сайты открывали и т.д.
Как уже было выше сказано, ничего из этого не нужно. Достаточно просто штатно грузануться с карточки/флэшки или что там используется, в командной строке initramfs'а подключить нужные LVM и cryptsetup'ы, а потом набрать exit — загрузка пройдёт.
У флэш и прочих карточек есть интерфейсы низкоуровневого доступа, которые принудительно записывают нули во все ячейки [1], [2]. Это делается намного быстрее, чем полное заполнение флэш-носителя какими-то данными через стандартные интерфейсы взаимодействия с ним. В общем, можно как-то комбинировать эти методы.
Посторонная Live-систеима не нужна, как выше уже было отмечено (разве что для подстраховки).
На загрузочнике скрытой ОС стоит просто /boot, а в нём есть и гипервизор со всеми вытекающими. Live-система тут уже ни при чём.
P.S. Если в матрёшке какие-то LUKS-разделы нужны только для возможности быстрого удаления, на них можно ставить пустые или простые пароли.
комментариев: 511 документов: 2 редакций: 70
Раз загрузочный носитель всё равно затирается:
можно на него помещать как скрипты для автоматического монтирования дисков, так и LUKS-заголовки к ним:
Т.е. аутентичный режим plain mode нужен только при шифровании образа загрузчика. Этот образ нужно будет при каждой загрузке расшифровывать вручную из-под того или иного LiveUSB и записывать на флэшку/карточку.
комментариев: 511 документов: 2 редакций: 70
Но:
Т.е., похоже, всё было не так. С lilo загрузчик установился сразу, всё работало, но система не пережила upgrade. С grub2 загрузчик штатно нормально не поставился, понадобились ручные фиксы, но зато после этого система стала нормально штатно апгрейдиться/апдейтиться.
Можно было бы тщательней поковырять вариант с lilo, но непонятно, насколько он считается штатным и поддерживаемым в Debian. К примеру, правильно ли он фиксится/апдейтится (как grub2) при установке гипервизора Xen и dom0-ядер Linux?
комментариев: 64 документов: 0 редакций: 4