Комментарии 15
А есть возможность сделать так, чтобы пароль от раздела считывался, к примеру, скачиваясь с какого то хоста? К примеру, не корневую ос криптить (она везде у всех одинаковая, а раздел с данными?)
В данном случае этого сделать не получится, поскольку на момент запроса пароля, у нас загружено только ядро и система не знает ничего про сеть. Вернее про устройства она знает, но конфиги ещё не прочитаны, поскольку зашифрованы.
И вот какой момент, ОС у всех одинаковая, но вот конфигурация системы. Здесь все совсем не так, именно по этому и предлагается шифровать вообще всё.
Если мы будем шифровать только наши важные данные и считывать пароль откуда-то снаружи, то тут сразу видится парочка проблем:
Хотя мне видится жизнеспособной такая схема:
Тогда если мы обращаемся к хосту который нам отдаёт пароль и «предъявляем» корректный IP и какой-либо хеш, который генерируем на лету по какому-то секретному алгоритму, то получаем правильный пароль и получаем правильный контейнер. А если IP не тот, или локальный IP не тот, или еще какая неприятность (унесли наш сервер или просто диск в края далёкие), то отдаём второй пароль и показываем как-бы наши «суперсекретные» данные но все же не совсем их. И подозрений не вызываем.
И вот какой момент, ОС у всех одинаковая, но вот конфигурация системы. Здесь все совсем не так, именно по этому и предлагается шифровать вообще всё.
Если мы будем шифровать только наши важные данные и считывать пароль откуда-то снаружи, то тут сразу видится парочка проблем:
- в этой схеме нет препятствий злоумышленнику. Несмотря на то, что у нас есть зашифрованный контейнер, подключается он в систему скриптом, который откуда-то автоматически берёт пароль и открывает криптоконтейнер. Отсюда вопрос: Где защита? Ведь всё происходит совсем совсем само и мне и не надо знать никаких паролей.
- отсутствует соединение с парольным хостом, у нас нет наших данных.
Хотя мне видится жизнеспособной такая схема:
- используем любой криптоконтейнер для наших данных, главное чтобы он поддерживал двойные пароли (как TrueCrypt) для реального контейнера и «вроде зашифровано, но ничего важного там нет» контейнера.
- на площадке установки локальных серверов у нас белый статический IP.
Тогда если мы обращаемся к хосту который нам отдаёт пароль и «предъявляем» корректный IP и какой-либо хеш, который генерируем на лету по какому-то секретному алгоритму, то получаем правильный пароль и получаем правильный контейнер. А если IP не тот, или локальный IP не тот, или еще какая неприятность (унесли наш сервер или просто диск в края далёкие), то отдаём второй пароль и показываем как-бы наши «суперсекретные» данные но все же не совсем их. И подозрений не вызываем.
Паранойя 2012 года — недостаточная осмотрительность 2013.
НЛО прилетело и опубликовало эту надпись здесь
Нет, Вы совершенно правы.
Для swap раздела лучше использовать onetime параметр, который на каждый запуск системы будет генерировать новый случайный пароль шифрования. В идеале ещё необходимо так же вынести на отдельный раздел файловую систему для временных файлов и её тоже шифровать точно таким же образом как swap раздел.
Для swap раздела лучше использовать onetime параметр, который на каждый запуск системы будет генерировать новый случайный пароль шифрования. В идеале ещё необходимо так же вынести на отдельный раздел файловую систему для временных файлов и её тоже шифровать точно таким же образом как swap раздел.
Из минусов только то, что в случае краха coredump на такой swap раздел писать бессмысленно.
Шифрование средствами файловой системы (например ZFS)К сожалению, ZFS во FreeBSD не умеет шифрование, только через гелю. Оракл, как поглотил Сан, перестал отдавать наработки по ZFS «конкурентам». :-( Кто-то пилит свою собственную реализацию шифрования, но я не вижу в этом большого смысла, т.к. нет никакой совместимости с reference реализацией.
Ну и к вопросу о том, что же, собственно, стоит шифровать: зачем шифровать все от корня (и в некотором смысле решать проблему курицы и яйца)? Почему бы не шифровать только своп и, скажем, /home? (Я на ноуте так и делаю.)
А шифрование от корня я использую по простой причине, вот живой пример:
Есть у меня один сервер, который используется частично как CI сервер и как песочница для разработки. Если я зашифрую только своп (куда в общем то ничего не попадает, поскольку памяти хватает) и папку где лежат исходники, то теоретически всё будет хорошо. Но. Так же есть базы данных MySql и Postgres. Хорошо, не забыли зашифровать и их папки. Появляется, например, capistrano для экспериментов по развертыванию проекта на боевую. По умолчанию считаем, что все её ресурсы у нас опять же на зашифрованном разделе. Пока всё отлично. И тут наступает аврал и дедлайн. И что-то разворачивается на сервер, и что-то добавляется на сервер, и что-то переконфигурируется.
Какова вероятность что-то забыть в открытой области файловой системы? Какова вероятность отдать информацию об используемых технологиях и програмных продуктах на боевых серверах? Ведь в песочницах зачастую используется тот же набор софта. Мы же тестируем.
И вот внезапно злоумышленник знает, что, например в работе мы используем apache + nginx. или nginx + php-fpm. или apache + mod_perl. Или выясняется что у нас имеется что-то типа Supervisor для запуска чего-либо что всегда должно быть живым. И вот тут виден установленный node.js. Просто так отдаём знания о дополнительных векторах атаки на продакшн сервера. Или какой-то скрипт у нас в кроне, и положили мы его куда нибудь вне шифрованного раздела, и рядом положили ssh ключ к stage площадке. Человеческий фактор мощная штука.
А при шифровании всего и вся, начиная от корня, мы этих опасностей избегаем. Они, конечно же, маловероятны, но как известно всё может быть.
Есть у меня один сервер, который используется частично как CI сервер и как песочница для разработки. Если я зашифрую только своп (куда в общем то ничего не попадает, поскольку памяти хватает) и папку где лежат исходники, то теоретически всё будет хорошо. Но. Так же есть базы данных MySql и Postgres. Хорошо, не забыли зашифровать и их папки. Появляется, например, capistrano для экспериментов по развертыванию проекта на боевую. По умолчанию считаем, что все её ресурсы у нас опять же на зашифрованном разделе. Пока всё отлично. И тут наступает аврал и дедлайн. И что-то разворачивается на сервер, и что-то добавляется на сервер, и что-то переконфигурируется.
Какова вероятность что-то забыть в открытой области файловой системы? Какова вероятность отдать информацию об используемых технологиях и програмных продуктах на боевых серверах? Ведь в песочницах зачастую используется тот же набор софта. Мы же тестируем.
И вот внезапно злоумышленник знает, что, например в работе мы используем apache + nginx. или nginx + php-fpm. или apache + mod_perl. Или выясняется что у нас имеется что-то типа Supervisor для запуска чего-либо что всегда должно быть живым. И вот тут виден установленный node.js. Просто так отдаём знания о дополнительных векторах атаки на продакшн сервера. Или какой-то скрипт у нас в кроне, и положили мы его куда нибудь вне шифрованного раздела, и рядом положили ssh ключ к stage площадке. Человеческий фактор мощная штука.
А при шифровании всего и вся, начиная от корня, мы этих опасностей избегаем. Они, конечно же, маловероятны, но как известно всё может быть.
А есть вариант с использованием TPM или смарт-карты?
Обычно у каждого разработчика есть локальная копия репозитория с исходными кодами. Как вы организовали работу с кодом без копирования на локальную машину? Как работает репозиторий? Удобно ли это разработчикам?
Например так, если машины разработчиков под Windows:
1. Есть домен AD
2. на *nix сервере самба втянутая в домен и созданы каталоги каждого разработчика
3. на машинах разработчиков монтируется сетевая шара (одна и та же у всех), например \\devel.domain.local\resource1
4. самба в зависимости от того из под чьей учётной записи монтируется этот ресурс, отдаёт соответствующий каталог из пункта 2
5. создаём в локальном DNS хост dev.domain.local указывающий на наш *nix сервер
6. в конфигах nginx пишем что при запросе dev.domain.local устанавливаем root хоста в /usr/local/devel/*/oursystem. Вместо звёздочки nginx подставляет логин человека который запросил этот локальный сайт.
Итого:
На каждой рабочей машине получаем сетевой диск X:, в который смонтирован соответствующий каталог с dev сервера. И все разработчики работают с ним, разворачивают туда рабочие копии репозитория и т.д. Неудобство только одно — существенно более медленная работа с этим смонтированным диском, особенно по сравнению с SSD. Но это не мешает жить совершенно, как показала практика. Сеть, естественно гигабитная.
И любой разработчик обращается к одному и тому же локальному доменному имени и видит свою копию продукта.
Естественно нужны некоторые соглашения по именованию каталогов проектов и доменов для такой схемы, но всё замечательно работает.
В случае, если машины разработчиков тоже под *nix, все работает не менее замечательно с поправкой на используемые технологии авторизации и схем монтирования сетевых ресурсов.
1. Есть домен AD
2. на *nix сервере самба втянутая в домен и созданы каталоги каждого разработчика
/usr/local/devel/ivanov
/usr/local/devel/petrov
/usr/local/devel/sidorov
3. на машинах разработчиков монтируется сетевая шара (одна и та же у всех), например \\devel.domain.local\resource1
4. самба в зависимости от того из под чьей учётной записи монтируется этот ресурс, отдаёт соответствующий каталог из пункта 2
5. создаём в локальном DNS хост dev.domain.local указывающий на наш *nix сервер
6. в конфигах nginx пишем что при запросе dev.domain.local устанавливаем root хоста в /usr/local/devel/*/oursystem. Вместо звёздочки nginx подставляет логин человека который запросил этот локальный сайт.
Итого:
На каждой рабочей машине получаем сетевой диск X:, в который смонтирован соответствующий каталог с dev сервера. И все разработчики работают с ним, разворачивают туда рабочие копии репозитория и т.д. Неудобство только одно — существенно более медленная работа с этим смонтированным диском, особенно по сравнению с SSD. Но это не мешает жить совершенно, как показала практика. Сеть, естественно гигабитная.
И любой разработчик обращается к одному и тому же локальному доменному имени и видит свою копию продукта.
Естественно нужны некоторые соглашения по именованию каталогов проектов и доменов для такой схемы, но всё замечательно работает.
В случае, если машины разработчиков тоже под *nix, все работает не менее замечательно с поправкой на используемые технологии авторизации и схем монтирования сетевых ресурсов.
Так же хочу заметить, что если уж шифровать данные, то стоит делать это надёжно, явно указывая алгоритм, размер ключа и mode-of-operation, например, AES256-XTS:
Бенчмарки тут: forums.freebsd.org/showthread.php?t=31425 (в случае AES-CBC ядрёный
Для особо параноиков которые хотят ещё, чтобы их данными нельзя было манипулировать можно включить аутентификацию данных с помощью, например, HMAC/SHA256:
Ну и в завершение крайне рекомендую почитать
% geli init -l 256 -e AES-XTSБенчмарки тут: forums.freebsd.org/showthread.php?t=31425 (в случае AES-CBC ядрёный
aesni.ko помогает удваивая скорость шифрования)Для особо параноиков которые хотят ещё, чтобы их данными нельзя было манипулировать можно включить аутентификацию данных с помощью, например, HMAC/SHA256:
-a HMAC/SHA256, что добавит уверенности в читаемых данных, но сократит кол-во места на диске и слегка замедлит его.Ну и в завершение крайне рекомендую почитать
man geli там ещё много всяких интересностей: Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Установка FreeBSD 9.1 с шифрованием корневого раздела