Comments 15
А есть возможность сделать так, чтобы пароль от раздела считывался, к примеру, скачиваясь с какого то хоста? К примеру, не корневую ос криптить (она везде у всех одинаковая, а раздел с данными?)
0
В данном случае этого сделать не получится, поскольку на момент запроса пароля, у нас загружено только ядро и система не знает ничего про сеть. Вернее про устройства она знает, но конфиги ещё не прочитаны, поскольку зашифрованы.
И вот какой момент, ОС у всех одинаковая, но вот конфигурация системы. Здесь все совсем не так, именно по этому и предлагается шифровать вообще всё.
Если мы будем шифровать только наши важные данные и считывать пароль откуда-то снаружи, то тут сразу видится парочка проблем:
Хотя мне видится жизнеспособной такая схема:
Тогда если мы обращаемся к хосту который нам отдаёт пароль и «предъявляем» корректный IP и какой-либо хеш, который генерируем на лету по какому-то секретному алгоритму, то получаем правильный пароль и получаем правильный контейнер. А если IP не тот, или локальный IP не тот, или еще какая неприятность (унесли наш сервер или просто диск в края далёкие), то отдаём второй пароль и показываем как-бы наши «суперсекретные» данные но все же не совсем их. И подозрений не вызываем.
И вот какой момент, ОС у всех одинаковая, но вот конфигурация системы. Здесь все совсем не так, именно по этому и предлагается шифровать вообще всё.
Если мы будем шифровать только наши важные данные и считывать пароль откуда-то снаружи, то тут сразу видится парочка проблем:
- в этой схеме нет препятствий злоумышленнику. Несмотря на то, что у нас есть зашифрованный контейнер, подключается он в систему скриптом, который откуда-то автоматически берёт пароль и открывает криптоконтейнер. Отсюда вопрос: Где защита? Ведь всё происходит совсем совсем само и мне и не надо знать никаких паролей.
- отсутствует соединение с парольным хостом, у нас нет наших данных.
Хотя мне видится жизнеспособной такая схема:
- используем любой криптоконтейнер для наших данных, главное чтобы он поддерживал двойные пароли (как TrueCrypt) для реального контейнера и «вроде зашифровано, но ничего важного там нет» контейнера.
- на площадке установки локальных серверов у нас белый статический IP.
Тогда если мы обращаемся к хосту который нам отдаёт пароль и «предъявляем» корректный IP и какой-либо хеш, который генерируем на лету по какому-то секретному алгоритму, то получаем правильный пароль и получаем правильный контейнер. А если IP не тот, или локальный IP не тот, или еще какая неприятность (унесли наш сервер или просто диск в края далёкие), то отдаём второй пароль и показываем как-бы наши «суперсекретные» данные но все же не совсем их. И подозрений не вызываем.
0
Паранойя 2012 года — недостаточная осмотрительность 2013.
+9
UFO just landed and posted this here
Нет, Вы совершенно правы.
Для swap раздела лучше использовать onetime параметр, который на каждый запуск системы будет генерировать новый случайный пароль шифрования. В идеале ещё необходимо так же вынести на отдельный раздел файловую систему для временных файлов и её тоже шифровать точно таким же образом как swap раздел.
Для swap раздела лучше использовать onetime параметр, который на каждый запуск системы будет генерировать новый случайный пароль шифрования. В идеале ещё необходимо так же вынести на отдельный раздел файловую систему для временных файлов и её тоже шифровать точно таким же образом как swap раздел.
0
Из минусов только то, что в случае краха coredump на такой swap раздел писать бессмысленно.
0
Шифрование средствами файловой системы (например ZFS)К сожалению, ZFS во FreeBSD не умеет шифрование, только через гелю. Оракл, как поглотил Сан, перестал отдавать наработки по ZFS «конкурентам». :-( Кто-то пилит свою собственную реализацию шифрования, но я не вижу в этом большого смысла, т.к. нет никакой совместимости с reference реализацией.
Ну и к вопросу о том, что же, собственно, стоит шифровать: зачем шифровать все от корня (и в некотором смысле решать проблему курицы и яйца)? Почему бы не шифровать только своп и, скажем, /home? (Я на ноуте так и делаю.)
0
А шифрование от корня я использую по простой причине, вот живой пример:
Есть у меня один сервер, который используется частично как 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 площадке. Человеческий фактор мощная штука.
А при шифровании всего и вся, начиная от корня, мы этих опасностей избегаем. Они, конечно же, маловероятны, но как известно всё может быть.
0
А есть вариант с использованием TPM или смарт-карты?
0
Обычно у каждого разработчика есть локальная копия репозитория с исходными кодами. Как вы организовали работу с кодом без копирования на локальную машину? Как работает репозиторий? Удобно ли это разработчикам?
0
Например так, если машины разработчиков под 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, все работает не менее замечательно с поправкой на используемые технологии авторизации и схем монтирования сетевых ресурсов.
0
Так же хочу заметить, что если уж шифровать данные, то стоит делать это надёжно, явно указывая алгоритм, размер ключа и 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
там ещё много всяких интересностей: +1
Sign up to leave a comment.
Установка FreeBSD 9.1 с шифрованием корневого раздела