Если у вас есть Synology и уровень вашей параноидальности >0, то наверняка вы используете зашифрованные папки. Основанная на encfs эта технология работает стабильно и не доставляет никаких неудобств. Кроме того случая, когда этих папок становиться 2-3, да еще каждая со своим паролем! Ведь по результатам исследований британских ученых, уровень параноидальности отдельного индивидума со временем только растет)
Соответственно, вводить 2-3 разных пароля после каждой, хотя и довольно редкой, перезагрузки устройства, начинает напрягать.
Поэтому мы устроим нечто вроде мастер пароля.
Первым делом создадим новую шифрованную папку, назовем ее master.
В нее положим скрипт autorun.sh (ниже подразумевается, что вы имеете доступ к Synology через SSH):
cat /volume1/master/autorun.sh
synoshare –enc_mount folder1 PASSWORD1
synoshare –enc_mount folder2 PASSWORD2
synoshare –enc_mount folder3 PASSWORD3
synoshare –enc_ummount master
, где folderx – папка и PASSWORDx пароль от нее.
Как видите, мы просто одну за другой монтируем зашифрованные папки, а затем размонтируем саму папку master. Таким образом, никто не может добраться до паролей, в открытом виде прописанных в скрипте.
Если папки уже замонтированы — ничего страшного не произойдет, поэтому никаких дополнительных проверок мы не делаем.
Несмотря на то, что мы не планируем долго держать папку master в подмонтированном (открытом) сотоянии, к cкрипту autorun.sh надо максимально ограничить доступ:
chown root autorun.sh
chmod 700 autorun.sh
теперь дело за малым: нам необходим механизм, который будет следить за появлением файла autorun.sh в папке master и выполнять его. Напишем простой сервис:
Примечание: Путь к сервису указан для DSM 6.x. Для DSM 5.x путь к сервисам: /usr/syno/etc/rc.d/ Имейте ввиду, после обновления системы пользвательские сервисы могут быть удалены.
cat /usr/local/etc/rc.d/S90_automount.sh
autorun=/volume1/master/autorun.sh
sleep=10
if [ "$1" == "start" ]; then
$0 service &
echo "Automount service started. Looking for $autorun"
exit
fi
if [ ! "$1" == "service" ]; then
echo "Usage: $0 start"
echo " Wait for $autorun and run it"
exit 1
fi
while [ 1 ]; do
sleep $sleep
if [ -f $autorun ]; then
echo "Found $autorun, running..."
$autorun &
sleep 120
fi
done
На этом все! Как вы видите, мы просто в цикле проверяем наличие файла и если он найден — выполняем его. Можно было оптимизировать выполнение и вместо цикла со sleep использовать команду inotifywait, но судя по всему этот пакет не входит в состав DSM.
У сервиса весьма ограниченный функционал, всего один параметр start и нет пераметров stop и status, но они и не нужны.
Теперь смело запускаем сервис: /usr/local/etc/rc.d/S90_automount.sр start
и проверяем, что при монтировании папки master в течении 10-20 секунд будут примонтированы папки, перечисленные в файле autorun.sh, а сама папка master автоматически отмонтируется.
Из минусов — рано или поздно вы забудете все свои пароли на папки, кроме одного. И если вдруг потеряете папку master – пиши пропало! По возможности избегайте этого!
Из плюсов — теперь вы можете на папки назначить сколь угодно длинные пароли — вводить вручную вам их больше не придется!
Удачного администрирования!
Комментарии (12)
novoxudonoser
06.06.2016 17:39Если вы пишите статью для linux пользователей, пожалуйста используйте соответствующую терминологию вроде каталога или директории. Если по проще то «папка» в отличие от девушки лёгкого поведения у вас один.
dgrees
06.06.2016 19:34Я правильно понимаю, что шифрование папок спасает от похищения информации только в случае физической кражи устройства?
Настроил пользователей, гостя не включал. Доступ к зашифрованной папке есть у авторизованных пользователей, ограничений нет вроде как.
И опция авто-монтирования при старте нивелирует пользу от шифрования или нет?
Hissing_Bridge
07.06.2016 02:11Нет, не правильно. Зашифрованный каталог (обратите внимание на комментарий novoxudonoser, папками называть каталоги в unix системах неправильно) после монтирования доступен в системе только тому пользователю который его смонтировал. Можно конечно добавить опцию --public, тогда каталог, в который смонтирована зашифрованная директория будет доступен всем. Но стандартное поведение такое, что доступ имеет только тот кто смонтировал.
Вообще пофайловое шифрование каталога очень удобно. К примеру у меня зашифрованный каталог лежит у меня в dropbox и owncloud. Он содержит какие-то конфигурационные файлы, настройки окружения, к примеру .bash_aliases, какие-то не сильно конфиденциальные документы, стандартные конфиги для серверов, а также база keepassx2. Это обеспечивает меня надежной защитой (к примеру шифруется база паролей самим keepassx2 + шифруется сам файл базы данных) в случае увода моего аккаунта dropbox (прецеденты уже были не раз у dropbox). Все что увидит злоумышленник, кто увел мой аккаунт, что-то вроде этого:
Dropbox +-- English +-- eRGmip9MJZ-EkseQF22WwL6q +-- H28UQXmRVkqsPDtfpXEKSk,n +-- ji4VUba3hqNFraLQcSAPXu,N +-- k3sYa-5PLOL0eTlJ-NVZtuX7 +-- owu8IRTTMWnEkt1RzOcyofZS +-- Share +-- V38bcwkLW2r5luyUwEpnNvWg +-- woRkZVRNbdMqkLDsmpiTbiNM
И это несомненно лучше чем хранить какие-то важные приватные данные в голом виде на чужих серверах.Antonto
07.06.2016 10:49после монтирования доступен в системе только тому пользователю который его смонтировал.
Не знаю, с какими ключами запускается монтирование в DSM, но приведу пример:
— администратор монтирует каталог
— администратор зайти в него не может из-за ограничения прав
— два различных рядовых пользователя (с установленными правами на полный доступ в каталог) могут туда зайти и имеют там полный доступ на чтение/записьHissing_Bridge
07.06.2016 11:00Опыта с DSM не имел, но encfs у меня монтируется именно так как написано выше.
[16:55] ~ [user@nix] ? ls -1 ~/.sandbox/ configs keepassx docs pic notes webmoney [16:55] ~ [user@nix] ? su - Пароль: [root@nix ~]# ls -al ~user/.sandbox ls: невозможно получить доступ к '/home/user/.sandbox': Отказано в доступе ls -al ~user/ | grep sand ls: невозможно получить доступ к '/home/user/.sandbox': Отказано в доступе d????????? ? ? ? ? ? .sandbox [17:57] ~ [user@nix] ? mount | grep sand encfs on /home/user/.sandbox type fuse.encfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
dgrees
07.06.2016 11:43А как тогда самому пользоваться этим каталогом через dropbox на удалённой машине? «вручную» расшифровывать?
И да, на DSM авторизованные пользователи с правами на чтение и запись могут читать и писать в шифрованном каталоге.
Antonto
06.06.2016 19:40Все верно! Спасет только при физическом доступе к устройству.
А опция штатного автомонтирования зашифрованных папок совсем странная, на мой взгляд. Кстати, опцию монтирования можно сделать чуть хитрее — например при втыкании флешки с ключевым файлом + завязать мастер пароль на MAC адрес роутера…
Hissing_Bridge
Лично я пробовал разные варианты автомонтирования шифрованного раздела и каталога. Самым защищенным и прозрачным для меня оказался следующий способ.
Автомонтирование шифрованного LUKS раздела (DMCrypt + автомонтирование шифрованного encfs каталога по средствам модуля PAM (pam-encfs). Для особых параноиков можно разместить на шифрованном разделе, в шифрованном каталоге скрипт с монтированием второй шифрованной директории, с запросом пароля или без (в самом скрипте прописать) решать вам. Лично у меня стоит вызов в автозапуске DM:
urxvt -e encfs /path/to/encrypt_dir/ /path/to/decrypt_dir/
Прописал в ~/.Xdefault размер терминала и приятные глазу цвета.
Таким образом я логинюсь в систему, ввожу лишь один пароль. Монтируется шифрованный volume и шифрованная директория, срабатывает скрипт автозапуска с запросом пароля на второй каталог. Много и подробно все это описано в Arch wiki.
Минус есть. Длина пользовательского пароля.
При логине в систему приходится вводить достаточно длинный пароль, потому как шифрованные разделы негоже создавать с коротким и слабым паролем.
Так же потребуется время чтобы настроить sudoers файл, на NOPASSWD для многих частых команд (ALL как то выставлять не прилично :\), хотя никто не мешает использовать su или использовать какой-нибудь gnome-keyring.
В остальном не вижу каких-то неудобств при использовании подобного способа. Более того, это решение кроссплатформенное. Да и 100% защиты нет и вряд ли когда-нибудь будет. Поэтому стоит несколько раз подумать, а стоит ли вообще что-нибудь сверхсекретное, оправдываемое всеми этими извращениями хранить где-нибудь у себя под 7 паролями. Защиты против метода горячего утюга, паяльника и кочерги еще не придумали ;)