Шифрование диска на сервере

без квм (или аналога) - никак. у тебя сеть без доступа к etc не поднимется.

Как вариант, использовать аппаратный ключ. Правда, и тогда нужен физический доступ к компу. Так что всё равно без вариантов.

gorilych, gserg: ясно, что исходную задачу не решить без доступа к машине или kvm

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

GELI на FreeBSD позволяет хранить файл с секретным ключом на отдельном носителе и не использовать пароль.

Ты это к чему сказал? LUKS тоже это позволяет, как любая другая вменяемая система этого типа.

К этому:

2) Как загрузить сервер до ввода пароля.

Не совсем уверен, что это то что нужно. http://habrahabr.ru/blogs/infosecurity/91948/
Там же, на хабре можно найти еще парочку статей про шифрование в Linux.

отдельный носитель на удаленнном сервере это как?

Вот же http://www.howtoforge.com/unlock-a-luks-encrypted-root-partition-via-ssh-on-u... (=

отдельный носитель на удаленнном сервере это как?

Любой раздел на диске. Да, тот же раздел с нешифрованной ФС /boot подойдёт, ведь он раньше всех опознаётся, не так ли?

Можно что бы загружался по дефолту минимальный дистр с ssh, как вариант, /boot с толстым initrd (в стиле Slackware) — с шеллом и прочим, туда можно и минимальный ssh впихнуть.
Там вручную вводятся команды монтирования зашифрованных разделов, далее смена корня и загрузка как обычно.
Или отдельный совсем дистр и chroot в шифрованный.
Но злоумишленник с физическим доступом может подменить initrd чтоб слал пароль ему. Не вижу способа избежать.

А смысл в шифровании, если любой может получить доступ без пароля?

Но злоумишленник с физическим доступом может подменить initrd чтоб слал пароль ему. Не вижу способа избежать.

Проверять контрольную сумму initrd скриптом при загрузке. Злоумышленник о его существовании не может знать. В случае тревоги принять меры (сменить ключ luks, сделать cat /dev/zero > /dev/sda и т.д.).

Почему не решить?
Впрочем, задача поставлена неверно. Правильная бы бы была на уровень выше. Она должна указать, защита от каких атак нужна, а от каких нет. Может шифрование бесполезно

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

Почему не может?

Потому что скрипт на зашифрованном разделе, и как он работает известно лишь его создателю.

А смысл в шифровании, если любой может получить доступ без пароля?

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

Завязывай с этими веществами. Шифрование нужно именно для предотвращения физического доступа. А исполнить man-in-the-middle можно только протащив необходимый исполняемый код на защищённую машину и обеспечив возможность его запуска. При правильно организованной системе безопасности это возможно только через сеть.

Шифрование не может и не должно предотвращать физический доступ.

Интересно, для чего же тогда оно вообще нужно?

> Потому что скрипт на зашифрованном разделе, и как он работает известно лишь его создателю.
От снятия дампа винчестера и подмены initrd оно не защитит.

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

> Шифрование бесполезно, если есть физический доступ злоумышленника
В таком случае шифрование разделов винчестера вообще бесполезно.
Но на самом деле это неверно, шифрование уменьшает риск компрометации информации в случае различных сценариев физического доступа. Скажем, кража ноутбука без возврата.
Или с возвратом, но тогда уже рекомендуется снять дамп с винта и расшифровывать на другой машине, убрав ноутбук, который вернули, подальше, на случай если в него встроили жучок.

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

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

В случае же если ключ хранится на том же сервере, то достаточно изъять сервер, что бы всё расшифровать позже... ну или снять дампы всех носителей. Тут шифрование не имеет смысла. Разве что остановить технически-неграмотного юзера

>А если у злоумышленника есть возможность получить физический доступ так что бы это не стало известно, он всегда может снять дамп винта и подменить initrd на свой, который по сети отсылает ему введенный пароль.
Можно сделать «одноразовые» пароли с зашифрованным куском исполняего кода, передаваемого скрипту в зашифрованном разделе. Скрипт проверяет, например, дату, закодированную в пароле, после чего расшифровывает пароль и выполняет его кусок.

Выдыхаю.

Шифрование предназначено для защиты от неавторизованного доступа к защищаемому объекту, а не к его окружению и не к его носителям.

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

Не вырывайте из контекста предложения, что я сказал.

Изначально я предположил, что сервер физически недоступен злоумышленникам, поэтому предложил хранить ключ на одном из разделов, доступных системе.

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

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

Таким образом, ответ на ваши вопросы кроется в наличии определённого протокола авторизации. Давайте мыслить конструктивно, каким образом это можно обеспечить. Для начала нужно посмотреть в сторону TPM, так как эта штука позволяет привязать шифрование и ключи к конкретному аппаратному окружению, а шифрованные данные будут бесполезны на другом аппаратном обеспечении (например, вынут винчестер и перенесён на другой компьютер). В случае кражи всей системы (всего компьютера), опять же, невозможно её защитить от компрометации без наличия внешнего секретного ключа.

>а шифрованные данные будут бесполезны на другом аппаратном обеспечении

Не при данном сценарии. TPM — это смар-карта по сути дела. Только с некотороыми несущественными выкрутасами.

В случае LUKS на TPM ты сможешь хранить только ключ, которым будет шифроваться MasterKey. А поменять MasterKey бысто и безопасно крайне проблематично. Это, кстати, фундаментальная слабость систем шифрования дисков и не только LUKS.

> Изначально я предположил, что сервер физически недоступен злоумышленникам,
Зачем тогда там вообще что-то шифровать?

хранить ключ на одном из разделов, доступных системе.

Зачем? Какая разница тогда, открытый раздел или зашифрованный, если и ключ и шифротекст в одном месте?

Зачем тогда там вообще что-то шифровать?

Вопрос из серии: зачем нужны виртуальные машины, если и так всё нормально.

Зачем? Какая разница тогда, открытый раздел или зашифрованный, если и ключ и шифротекст в одном месте?

Места-то как раз разные.

> зачем нужны виртуальные машины, если и так всё нормально.
Что бы запускать другую операционную систему без перезагрузки основной, очевидно же

Места-то как раз разные.

Один и тот же жесткий диск, разные разделы — это разные места?

Как идея :

1. Генерим несимметричную пару ключей (на закрытом будем шифровать ядро и initrd, на открытом соотв. раскрывать)

2. Делаем обычные ключи для шифрования разделов

3. С головой и руками лезем в gPXE и наглухо зашиваем туда открытый ключ и дешифратор.

4. там же в gPXE в загрузочном скрипте указывает грузить всё с адреса например server007.dyndns.com .

5. полученный на 3,4 gPXE ставим на целевой сервер

6. готовим ядро и шифруем его на закрытом ключе

7. готовим initrd (складываем туды ключи шифрования разделов) и также шифруем на закрытом ключе.

8. пишим скрипты для web-server`а чтобы образы выдавал, по расписанию, только в некоторые адреса и проч. Направляем адрес server007 на веб-сервер

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

http://xkcd.ru/538/