id: Гость   вход   регистрация
текущее время 07:07 03/12/2021
Автор темы: Гость, тема открыта 28/05/2009 18:39 Печать
Категории: софт, инфобезопасность, защита дисков, свободный софт
https://www.pgpru.com/Форум/UnixLike/УдобныйПросмотрФотоПоСети
создать
просмотр
ссылки

Удобный просмотр фото по сети


Хочется просматривать приватные фото по сети.
Фото размещены в локальной сети на Linux-сервере.
Просматривать фото нужно на десктопах, подключенных к этой сети.
На десктопах тоже установлены Linux и среда KDE.


Причем, чтобы максимально удобно и просто.
Например, на десктопе это выглядит так:
– клик на рабочем столе по ярлыку сервера
– выбор на на сервере папки с криптоконтейнером
– клик по файлу криптоконтейнера
– ввод пароля для его открытия
– клик по фото-файлу
– автоматическая загрузка соответствующего приложения десктопа для просмотра фото-файла


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


На виндовсе с использованием PGP-диска это решается элементарно.


Как бы это же реализовать в линуксе в среде KDE?


Или, может, найдутся лучшие идеи...


 
Комментарии
— SATtva (28/05/2009 19:19)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4116
man cryptsetup?
— Гость (28/05/2009 19:35)   <#>
Наверное, рано мне еще по манам лазить, реальность общей концепции в деталях хочется обсудить
— SATtva (28/05/2009 19:46)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4116
Так может стоит для начала решить, чего именно хочется добиться? Каковы угрозы и риски? Если цель только в том, чтобы сложить картинки в криптоконтейнер и открывать его через сеть с последующим просмотром файлов, то в помощь Вам SSH X11 Forwarding, cryptsetup, bash и любой просмотрщик типа gqview.
— Гость (28/05/2009 19:54)   <#>
Да, конечно. И тут я повторю то, что недостаточно акцентировал.
Итак, угроза одна – со стороны Интернета. Нужно максимально обезопасить утечку фото в него, а также внешнее вторжение с целью их похищения. Последнее реализовано файрволом, но хотелось бы закрепить этот эффект еще и путем криптозащиты данных. Все-таки криптоконтейнер не постоянно открыт, а только по сеансам, следовательно, риски доступа дополнительно уменьшаются.

Для тех же юзеров, кто внутри локальной сети – позволен доступ ко всем фото на сервере, т.е. они доверенные лица.
— Гость (28/05/2009 20:01)   <#>
Прочел следующее:

Подумайте, действительно ли Вам нужны разделы dm-crypt. В
ряде случаев вполне можно обойтись шифрованием файлов (архивов)
с использованием GnuPG или подобных систем. Возможно, Вам стоит
взглянуть на EncFS. Решение на базе dm-crypt достаточно ресурсоёмкие
с точки зрения процессорного времени и плохо подходят для слабых машин.

У меня сервер как раз слабая машинка. Но даже дело не в этом – как говорил ранее, предпочтительнее криптоконтейнер в виде файла, а не целого диска ввиду большей гибкости при работе с файлом.
— SATtva (28/05/2009 20:08)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4116
В линуксе нет разницы между файлом и дисковым разделом: и то, и другое можно монтировать как блочное устройство (только файл нужно вначале представить как блочное устройство с помощью losetup). Хотя в данном случае EncFS действительно может быть более предпочтительно.
— Гость (28/05/2009 20:27)   <#>
и любой просмотрщик типа gqview

Для trueъ-аскетов есть feh :)
— unknown (29/05/2009 09:07)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Возможно, Вам стоит взглянуть на EncFS.

Вот-вот. На сервере будут лежать фото в зашифрованном виде, на локальной машине вы их будете монтировать как расшифрованные. Какой гибкости не хватает? Это даже гибче, чем создавать файл-контейнер – все файлы лежат по-отдельности и шифруются на лету прозрачно поверх обычной FS. Хотите сделать архив – забэкапьте таром директорию.

Только в отличие от криптоконтейнера сильнее стоит проблема — анализ траффика и зашифрованного содержимого посторонним — виден приблизительный размер, количество, даты файлов.

Да и проверьте стабильность работы encFS, в отличие от dm-crypt.

В линуксе нет разницы между файлом и дисковым разделом: и то, и другое можно монтировать как блочное устройство (только файл нужно вначале представить как блочное устройство с помощью losetup).

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

Всё что касается криптоконтейнеров, касается любых программ и операционных систем. Может добавить это в FAQ? Вот только в какой раздел, чтобы относился ко всему дисковому шифрованию, а не к конкретной ОС или программе?
— Гость (29/05/2009 18:41)   <#>
Поясню, почему мне не очень подходит идея криптоконтейнера в виде раздела целиком.
Как уже отмечал, этому решению не хватает гибкости. Например, на сервере есть винчестер объемом 1 Тб. Допустим, разбиваю его пополам – 500 Гб уйдет на обычные данные, еще 500 Гб на шифрованный раздел.
Через полгодика окажется, что промахнулся – фотографий оказалось больше, чем ожидалось, и надо отвести под криптораздел больше места. Переразбивка раздела занятие проблематичное и небезопасное, хотя и есть решения, позволяющие это делать на лету, но все же.... в-общем, не нравится.
Файловый же контейнер гораздо удобнее – перекинул его на другое место, удалил на прежнем, и завел новый большего размера, и затем скопировал в него данные со старого.
Сколько раз так делал в винде – очень удобно. Хотелось бы и здесь также реализовать, без крипторазделов.
— SATtva (29/05/2009 19:55)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4116
Всё что касается криптоконтейнеров, касается любых программ и операционных систем. Может добавить это в FAQ? Вот только в какой раздел, чтобы относился ко всему дисковому шифрованию, а не к конкретной ОС или программе?

В понедельник переименую раздел FAQ, чтобы отвязать от одного только PGPdisk. Пока можно прямо туда написать.
— Гость (30/05/2009 04:35)   <#>
Через полгодика окажется, что промахнулся – фотографий оказалось больше, чем ожидалось, и надо отвести под криптораздел больше места.

И в чём проблема? Создаёте ещё один, второй, криптораздел и монтируете его в один из каталогов первого криптораздела (ещё про логические симлинки ln -s почитайте, man ln) – будет выглядеть как будто объём первого вырос. Если вам уж слишком нужно, чтобы и физически системой несколько разделов воспринимались как один – есть стандартная штука, называемся concatenated disk driver (CCD). А вообще, про управление большими объёмами данных можно почитать здесь.
— unknown (30/05/2009 21:46)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
dmcrypt в Linux специально интегрировался с системой томов LVM, что позволяет изменять разделы данных с файловой системой или зашифрованные разделы.

Использование гибкой системы томов позволяет избежать традиционного разбиения диска на разделы вообще типа: /dev/sda1 – это у нас /boot, /dev/sda2 – это /, /dev/sda3 – это /home.

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

Ненавязчиво предлагаю оставить "удобные" виндовые привычки с устаревшей системой "контейнер – это файл поверх ФС" и попробовать даже не разделы шифровать, а перейти на использование LVM.
— Гость (30/05/2009 22:08)   <#>
Использование гибкой системы томов позволяет избежать традиционного разбиения диска на разделы вообще

Например, в BSD рекомендуется разбивать на разделы не потому что "иначе нельзя", а чтобы в случае сбоя файловой системы, таковая поросла лишь на проблемном разделе, а не на всём диске (в конце концов, на разных разделах могут стоять вообще разные ФС, смонтированные с разными параметрами безопасности). Если ФС вдруг слетает в Linux, проблема затронет весь диск, на котором использовался LVM?
— unknown (30/05/2009 22:33)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Spinore (или кто-там :), почитайте где-нибудь про различие между физическими и логическими томами и группами томов. Примитивно – логический том – для системы как раздел, пожалуйста, создавайте на нём любые системы и задавайте параметры монтирования, разносите на несколько дисков, размещайте поверх RAID или без него, изменяйте его размеры в зашифрованном или открытом виде вместе с содержимым, делайте снэпшоты и копии содержимого, не останавливая работы сервера.

LVM разщработан и подарен сообществу IBM'ом. Проблемы у LVM были, но сейчас он относительно стабилен. Если побъётся заголовок физического тома, тогда могут полететь все логические тома, но это малореально.

Может полететь отдельно логический том, в котором смонтировано /что_то также как и обычный раздел, другие логические тома, где смонтировано /что_то_другое будут работать. Есть проблемы с восстановлением информации после глобальных повреждений, но при использовании шифрования это не актуально само по себе.
— Гость (30/05/2009 22:47)   <#>
Spinore (или кто-там :)

:-D Ясно, спасибо. Я итак понимаю, что это некий уровень абстракции к реальным разделам и интерфейсам, но вот в контексте устойчивости к сбоям ничего не слышал про. CCD тоже не изучал и не настраивал.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3