Используем EncFS для "прозрачного" шифрования данных в облаках + реверс

Автор oermolaev, 21 декабря 2014, 10:50:08

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

oermolaev

Преамбула:

Имеется несколько аккаунтов mail.ru на которых по терабайту свободного места в облаках (в своё время «нажадничал» по акции). Известно что уровень доверия к mail.ru в линукс-сообществах очень низкий, что также сказалось и на моём отношении к нему. Но не пропадать же «добру»? Описанными ниже способами, настроил «прозрачное» и «на лету» шифрование домашней коллекции фото-видео материалов (которая на сегодняшний день составляет уже 155 ГБ) и синхронизацию с упомянутым облаком. По-скольку имена файлов и папок достаточно абстрактные, то они намеренно не шифруются и остаются в оригинальном виде, тем самым, возможно, мы избежим излишней пересинхронизации при использовании на разных компьютерах, и не привлечем нежелательного внимания спецслужб :) .
[свернуть]

Описываемый способ несколько отличается от способа Leo своей «прозрачностью» и некоторыми другими аспектами, поэтому, надеюсь, не будет считаться дублем. Для «прозрачной» разблокировки шифрованных данных будет использоваться пароль пользователя операционной системы. Это нужно учитывать при смене пароля, а также для обеспечения возможной синхронизации с другими своими компьютерами. Для решения задачи используем программу EncFS (Шифрованная виртуальная файловая система) и пакет libpam-encfs (модуль для автоматического монтирования файловых систем EncFS использующий механизм модуля PAM).
Стандартно - EncFS сохраняет данные зашифрованными, а отображает их расшифрованными. С опцией --reverse — наоборот, но об этом позже.

Установка

sudo apt-get install encfs libpam-encfs

Создание необходимых каталогов

Создадим в каталоге пользователя директорию ~/<cloud>/.private, в которой будут храниться данные в зашифрованном виде, и точку монтирования шифрованной файловой системы ~/private:

mkdir -p ~/<cloud>/.private ~/private

где <cloud> - ваше название каталога который настроен для синхронизации облака. Названия каталогов могут быть, разумеется, своими.

Создаем шифрованную файловую систему EncFS

Предварительно добавляем пользователя в группу fuse:

sudo usermod -a -G fuse $USER
и перелогинимся.

Создаем шифрованную файловую систему EncFS для уже созданных нами каталогов:

encfs ~/<cloud>/.private ~/private

в процессе создания выбираем режим эксперта: «x» - для того что бы иметь возможность выбрать алгоритм шифрования имен «Null» - если мы хотим что бы файлы в облаке имели привычные не шифрованные имена.

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

Настройка автоматического монтирования EncFS при входе пользователя в систему (логине)

1. Редактируем файл «/etc/security/pam_encfs.conf»:

sudo nano /etc/security/pam_encfs.conf

для того что бы отключить автоматическое размонтирование при простое, комментируем строку:

# encfs_default --idle=1

и раскомментируем строку:

* .private private -v allow_other

отредактируем её таким образом что бы указать созданные нами ранее каталоги:

* <cloud>/.private private -v allow_other

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

Если синхронизируемые папки находятся вне домашнего каталога, то нужно вместо «*» прописать имя (логин) пользователя:

example_user /mnt/<cloud>/.private /home/example_user/private -v allow_other

2. Редактируем файл «/etc/fuse.conf»:

sudo nano /etc/fuse.conf

где раскомментируем строку позволяющую опции монтирования не-root пользователям:

user_allow_other

Использование

Теперь, всякий раз при запуске системы, данные из ~/<cloud>/.private будут монтироваться в ~/private в расшифрованном виде. Пользователь должен работать с файлами расположенными именно в каталоге ~/private. Каталог c шифрованными данными сознательно сделан скрытым (в названии впереди добавлена точка) что бы случайно не ввести туда данные.

Настройка синхронизации с другими компьютерами

При настройке синхронизации с другим компьютером сначала настраиваем синхронизацию с облаком, синхронизируем все файлы и только затем настраиваем EncFS. По скольку, файл «.encfs6.xml» уже будет на месте, программа EncFS, при правильном указании каталогов, должна спросить у вас только пароль.

Замечания
1. Если включен автологин в систему в файле «/etc/lightdm/lightdm.conf», то монтирование шифрованного каталога в «~/private» автоматически осуществляться не будет.
2. Будьте готовы к тому, что при неправильных действиях вновь созданный пустой каталог может привести к опустошению содержимого соответствующего каталога в облаке и на всех связанных с ним компьютерах.
3. В процессе настройки и эксплуатации может потребоваться отмонтировать шифрованную систему. Выполняется командой:

fusermount -u ~/private

4. Судить о том примонтирована шифрованная файловая система, или нет можно таким образом:

cat /etc/mtab | grep encf

Теперь о реверсе

Хранение локальных файлов в шифрованном виде может быть нецелесообразным, например, если домашний каталог и так шифруется, или, как у меня, зашифрован весь корень, или же вы вообще не собираетесь шифровать данные локально. Для такого случая есть интересная опция --reverse. Что бы её использовать меняем местами как в настройках, так и в голове понятия  SOURCE и  TARGET. Теперь источником будут обычные нешифрованные данные, а в точке монтирования  TARGET PATH будут шифрованные данные.

Таким образом меняется команда создания шифрованной файловой системы:

encfs --reverse ~/private ~/<code>/.private

И строка в файле «/etc/security/pam_encfs.conf» меняется соответственно:

* private <cloud>/.private -v allow_other.

Надо отметить, что вы должны во всех случаях беречь копию файла .encfsX, которая содержит информацию EncFS.

Сведения о безопасности encfs
ЦитироватьСогласно аудиту безопасности, выполненному Taylor Hornby (Defuse Security), текущая реализация Encfs уязвима или потенциально уязвима нескольким типам атак. Например, атакующий с правами чтения/записи шифрованных данных может понизить стойкость шифрования последующих данных без уведомления законного пользователя, или может использовать временной анализ для получения информации.

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