LINUX.ORG.RU
ФорумAdmin

Организация правильного шифрованного backup-сервера

 , ,


1

3

Долго был читателем, решил стать писателем!

Есть желание организовать backup-сервер с обратно-инкрементальными архивами нескольких компов, работающих как на Linux так и на windows. Имею опыт администрирования локалхоста по выходным. Чтобы было не скучно, хочется сделать сервер, который будет устойчив к его изъятию / физическому взлому, возможно, вместе с отдельными компами, которые он резервирует.

Напрашивается шифрование, но возникает вопрос, как правильно монтировать шифрованные разделы / контейнеры на время резервирования. Не определился я и с протоколом / программным продуктом, который будет для этой задачи оптимальным.

Алгоритм вроде простой: сервер монтирует раздел и получает по сети данные от клиентов. Но в нем много вариантов:

1) Чтобы смонтировать шифрованный раздел нужен ключ, к которому у сервера должен быть доступ. Раз у сервера он есть, значит он может быть получен после его взлома и использован. Как хранить ключ, чтобы он был цел и при этом пригоден к использованию в скриптах? Можно ли считать ключ, который отсутствует на диске сервера, но загружен в его оперативную память, неизвлекаемым без трудоемких методов?

2) Через какой протокол и в какую сторону передавать данные? Если их толкает клиент, то ему нужен доступ на чтение, чтобы сравнивать файлы. Ладно, оставляем ему открытой вчерашнюю резервную копию, как защитить предыдущие копии, не дублируя вчерашнюю на шифрованном разделе? Жесткие ссылки же в шифрованный раздел тянуться не могут.

3) Решить это можно, если сервер сам будет тянуть данные, но тогда возникает проблема с открытыми файлами, особенно в windows. Пока единственная идея, которая приходит на ум, - монтировать на клиенте теневую копию по расписанию непосредственно перед резервированием и предоставлять к ней доступ серверу через smb. Linux'овые демоны, типа rsyncd, как я понял, под windows запускать довольно проблематично.

Такой вот сумбур получился. Проблема вряд ли новая, и наверняка есть готовые программные решения, но мне пока найти их не удалось. Вроде Duplicati выглядит не плохо, но возможность с клиента вернуть любой архив без ввода пароля все портит, да и защита паролей там весьма условная.

Подскажите, пожалуйста, куда двигаться.



Последнее исправление: noroots (всего исправлений: 1)

Как хранить ключ, чтобы он был цел и при этом пригоден к использованию в скриптах?

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

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

Нет.

Через какой протокол и в какую сторону передавать данные?

IP, TCP, SSH, VPN. Любой удобный протокол заверни в любой безопасный туннель и получишь и удобство и безопасность.

Если их толкает клиент, то ему нужен доступ на чтение, чтобы сравнивать файлы.

Нафига? Он сам не знает что наинкременталил? А если и не знает, то не проще ли уже серверу этим всем заниматься?

оставляем ему открытой вчерашнюю резервную копию, как защитить предыдущие копии

Да хоть шифруй разными ключами, хоть сертификаты выдавай с ограничением гарантийного срока.

особенно в windows

Выбрось бяку!

наверняка есть готовые программные решения

Чтобы эффективно и безопасно использовать абстракцию — нужно очень хорошо разбираться в том, над чем абстрагируешься.
Так что изучай матчасть и делай всё руками; когда сделаешь хотя бы пару раз — переходи к готовым решениям.
Иначе проблем потом будет больше от непонимания процесса.

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

Goury ★★★★★
()
Последнее исправление: Goury (всего исправлений: 1)
Ответ на: комментарий от Goury

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

Я понимаю, что они есть, но что и как можно использовать в скриптах, которые должны исполняться день за днем без участия администратора? Единственное, что приходит на ум, - подтягивание ключей с безопасного сервера по туннелю через интернет, но его и со взломанного сервера также можно будет подтянуть, если разобрать скрипты. Да и интернета стабильного нет, пока ни одна ssh сессия через него двух суток не пережила.

Нафига? Он сам не знает что наинкременталил? А если и не знает, то не проще ли уже серверу этим всем заниматься?

Rsync, вроде, не знает, можно, конечно, прикрутить через списки файлов, но на windows будет заморочено. Duplicati теоретически должна знать, но из коробки все равно читает архив. Буду разбираться. Если тянуть с сервера, нужно разобраться со своевременным созданием теневой копии, пока нет понимания, как сервер будет компу на windows такую команду давать.

Да хоть шифруй разными ключами, хоть сертификаты выдавай с ограничением гарантийного срока.

С жесткими ссылками это не проходит, так что нужен вариант с хранением предыдущих архивов в виде непривязанных фалов. Вроде, подходящий способ, для варианта с зашифрованной последней копией, но вариант сам не очень, только как запасной.

noroots
() автор топика
Ответ на: комментарий от noroots

Единственное, что приходит на ум

Учи матчасть — приходить будет больше и по делу.

Да и интернета стабильного нет

Его и не бывает за пределами локалки, в которой ты админ.

С жесткими ссылками это не проходит

Ключи проверять надо на этапе листинга и обращения к файлу.
Но лучше не параноить до неадекватного состояния и отдавать по одному ключу хотя бы весь инкремент до ближайшего полного архива.

как сервер будет компу на windows такую команду давать

Выбрось все вантузы или забудь о безопасности как о несбыточной мечте.

Goury ★★★★★
()

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

Нет, можно использовать encfs и бэкапить только зашифрованую версию.

Через какой протокол и в какую сторону передавать данные?

rsync, естественно. Смотреть в сторону rsnapshot и http://www.mikerubel.org/computers/rsync_snapshots/

anonymous
()
Ответ на: комментарий от anonymous

Нет, можно использовать encfs и бэкапить только зашифрованую версию.

Если бы клиентами были только компы с Linux, был бы логичный вариант. На windows нужно прикручивать fuse и много думать, как все это скрипотвать.

bacula или bareos с шифрованием.

Побаиваюсь я их пока, представляются overkill'ом для резервного копирования 5-7 компов. Думаю попробовать BURP. По документации умеет шифрованное резервирование с клиента без прав на восстановление.

noroots
() автор топика

Подскажите, пожалуйста, куда двигаться

Я бы двинулся в сторону системного подхода к обеспечению безопасности, который очень быстро навел бы меня на мысль о том, что если/когда сервер изымут, изъявшие тоже очень быстро выйдут на меня и все расшифруют и восстановят на любую дату даже без терморектального криптоаназа.

Поэтому ответ на вашу задумку заключается не в технических деталях шифрования, а в том чтобы сервер попросту не нашли. «Схорониться мне надо..» - в этом направлении следует двигаться ;)

rubic
()

В идеале надо шифровать так: все открыто, закрыта только небольшая порция данных в пределах 1-5k

anonymous
()
Ответ на: комментарий от rubic

Там нет таких данных, за которые будет смысл выходить на меня, но и хранить все в отрытую, когда можно сделать шифрование с небольшими накладными расходами, мне кажется неправильным. Сервер спрятать - хорошая идея, думаю, когда закончу отладку, я так и сделаю, но одно другому не мешает.

noroots
() автор топика
Ответ на: комментарий от afanasiy

С шифрованием без шифрования

bacula или bareos с шифрованием.

Bacula и Bareos хранят в открытом виде имена файлов, которые тоже могут представлять интерес. Я хранил резервные копии в открытом виде на LUKS'овском устройстве.

Camel ★★★★★
()
Ответ на: комментарий от noroots

Рыбку съесть

Я понимаю, что они есть, но что и как можно использовать в скриптах, которые должны исполняться день за днем без участия администратора?

Тут либо дудочка, либо кувшинчик. Если ключи доступны сценарию оболочки, то они доступны и «злоумышленнику» в погонах или без.

Тут уже правильно сказали, что безопасность требует комплексного подхода. Надо заботится не только о длине ключа, но и чтобы до терморектального анализа дело не дошло.

Camel ★★★★★
()
Ответ на: Рыбку съесть от Camel

Надо заботится не только о длине ключа, но и чтобы до терморектального анализа дело не дошло.

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

anonymous
()
Ответ на: комментарий от anonymous

WAT?

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

Это как? А если админ не знает пароль, то кто его вообще знает? Как не зная пароль смонтировать шифрованую директорию? Можно ли не зная пароль смонтировать шифрованую директорию чтобы записать в неё ещё несколько файлов?

Camel ★★★★★
()

Ну сколько можно твердить, что бэкап и шифрование это в принципе не совместимые вещи.

хочется сделать сервер, который будет устойчив к его изъятию / физическому взлому

Огорчу, но такого не бывает.

Такой вот сумбур получился.

Это не сумбур - это каша.

Подскажите, пожалуйста, куда двигаться.

Для начала, понять, нужна резервная копия (и средства ее восстановления) или шифрование.

robot12 ★★★★★
()

В догонку, все Ваше шифрование вскроется за 5 минут сотрудниками органов, без глубоких познаний в ИТ.

robot12 ★★★★★
()
Ответ на: комментарий от robot12

Ну сколько можно твердить

Ну сколько можно твердить, что бэкап и шифрование это в принципе не совместимые вещи.

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

Для начала, понять, нужна резервная копия (и средства ее восстановления) или шифрование.

Нужна и копия и шифрование. Когда я занимался такими вещами, то у меня LUKS'овский контейнер шифровался с двумя ключами, один знал я, второй — директор. Кроме того была инструкция. Даже если бы меня съел динозавр, то директор всё равно мог бы расшифровать бэкапы (если бы не понял инструкцию, то нанял бы специального мальчика). Если бы я беспокоился, что директор зная пароль может изменить бэкапы, положить туда Центральные Процессоры, а потом свалить всё на меня, то пароль от бэкапов был бы в запечатанном конверте в сейфе. Если директор может предъявить запечатанный конверт, значит он не вмешивался в бэкапы.

Camel ★★★★★
()
Последнее исправление: Camel (всего исправлений: 1)
Ответ на: WAT? от Camel

А если админ не знает пароль, то кто его вообще знает?

Тот, кому положен доступ. Админ помогает настроить, чтобы осталось только пароль ввести.

Как не зная пароль смонтировать шифрованую директорию?

Никак, нужно бэкапить криптоконтейнер.

anonymous
()
Ответ на: Ну сколько можно твердить от Camel

правильное резервное копирование и шифрование это вещи в принципе неразделимые

Зачем бэкапить в расшифрованом виде?

LUKS

Теперь понятно зачем. encfs избавляет от этого геморроя.

anonymous
()
Ответ на: WAT? от Camel

Это как? А если админ не знает пароль, то кто его вообще знает? Как не зная пароль смонтировать шифрованую директорию? Можно ли не зная пароль смонтировать шифрованую директорию чтобы записать в неё ещё несколько файлов?

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

------------- В плане терморектала, интересно, есть ли какая-то замена сдувшемуся truecrypt с его «plausible deniability»?

rubic
()
Ответ на: Ну сколько можно твердить от Camel

Окай ! Но в твоей схеме два изъяна - конверт в сейфе и директор :)

То есть все твое шифрование - пыф в воздух.

а потом свалить всё на меня

А это как раз вариант развития событий. Как следствие, срок мотать тебе а не директору.

robot12 ★★★★★
()
Ответ на: комментарий от anonymous

Давай я тебе пару вводных дам :)

Есть данные, хранить их нужно 50 лет.

Вопрос чем ты их собираешься шифровать, и через 30 лет доставать ?

ПО - устраеет, процессор устареет ...

Да же IBM не рекомендует, шифровать ленты своим встроенным в привод шифровальщиком, в случае хранения лент более 10 лет.

robot12 ★★★★★
()
Ответ на: комментарий от robot12

Директор в конверте в сейфе

Окай ! Но в твоей схеме два изъяна - конверт в сейфе и директор

Пащму? Если конверт вскрыт, то это уже не я (точнее возможно не только я).

А это как раз вариант развития событий. Как следствие, срок мотать тебе а не директору.

В нашей стране это в любом случае так, что с шифрованием, что без.

Да же IBM не рекомендует, шифровать ленты своим встроенным в привод шифровальщиком, в случае хранения лент более 10 лет.

Не путайте резервную копию и архив.

Camel ★★★★★
()
Ответ на: комментарий от anonymous

Так не бывает

Тот, кому положен доступ. Админ помогает настроить, чтобы осталось только пароль ввести.

осталось только пароль ввести

пароль ввести

This!

Это только в стране пони пароль будет вводить директор, а в реальности его будет вводить админ, потому что только он понимает что всё это значит.

Если вы допускаете конфигурацию «админ всё настроил, осталось только кому-то другому пароль ввести. Мы называем это пароль вводить не надо», то LUKS тоже не требует ввода пароля. Админ всё настроил, при подключении шифрованного тома у «кого-то» будет запрашиваться пароль.

Camel ★★★★★
()
Ответ на: Директор в конверте в сейфе от Camel

Пащму?

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

Не путайте резервную копию и архив.

А есть ли разница ? Копию ПО все равно нужно хранить, для доступа к данным :) А кратковременные резервные копии, типа снапшутов дневных вообще шифровать бессмысленно :) Вероятность утери данных при шифровании возрастает, ведь если потерять ключ..... то резервная копия теряет всякий смысл.

robot12 ★★★★★
()
Ответ на: комментарий от rubic

Deniable LUKS

В плане терморектала, интересно, есть ли какая-то замена сдувшемуся truecrypt с его «plausible deniability»?

Раскритикуйте алгоритм. Почему бы заголовочную часть LUSK'ового шифрованого раздела не XOR'ить с md5 от пароля? Заголовочная часть после этого будет похожа на случайные данные, весь остальной раздел и так похож на случайные данные. А если захотим смонтировать, что XOR'нем ещё раз. Для того кто не знает что на разделе LUSK он будет похож на случайные данные.

Camel ★★★★★
()
Ответ на: комментарий от robot12

Объясните

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

Не объяснение. А если злоумышленник из фирмы конкурента хочет вставить закладку в наши резервные копии? Директор сам себе враг чтобы вскрывать конверт и портить бэкапы? И почему конверт слабое звено? Как можно «взломать» конверт? На конверте подпись админа, печать и сургуч, всё это запаяно в стеклянную ампулу.

Camel ★★★★★
()
Ответ на: комментарий от robot12

Есть разница

А есть ли разница?

Есть.

Копию ПО все равно нужно хранить, для доступа к данным.

А копию которую начальник хранит у себя на даче будете в открытом виде перевозить?

Camel ★★★★★
()
Ответ на: Объясните от Camel

А если злоумышленник из фирмы конкурента хочет вставить закладку в наши резервные копии?

Хммм что действительно ?

Директор сам себе враг чтобы вскрывать конверт и портить бэкапы?

У директора есть родня, наверняка, жена и дети. Взяв их в заложники, этого директора вынудят не такое сделать :)

robot12 ★★★★★
()
Ответ на: Есть разница от Camel

А копию которую начальник хранит у себя на даче

Это выстрел в голову, прям.

Не серьезно это.

robot12 ★★★★★
()
Ответ на: Ну сколько можно твердить от Camel

Почему-то все темы, где упоминается шифрование, раньше или позже сводятся к «терморекталу»...

Когда я занимался такими вещами, то у меня LUKS'овский контейнер шифровался

Можно поподробнее? Контейнер каждый раз монтировался вручную с вводом пароля?

noroots
() автор топика
Ответ на: Так не бывает от Camel

Если вы допускаете конфигурацию «админ всё настроил, осталось только кому-то другому пароль ввести. Мы называем это пароль вводить не надо», то LUKS тоже не требует ввода пароля.

Угу, и каждый раз бэкапить всё вместо изменённых файлов.

anonymous
()
Ответ на: комментарий от robot12

Ну сколько можно твердить, что бэкап и шифрование это в принципе не совместимые вещи.

Совместимые, но очень аккуратно. Если нужен disaster recovery с минимальным временем восстановления - то да, шифрование только мешает. Если на первый план выходит обеспечение конфиденциальности - то шифрование не помешает, хотя его лучше заменить другими средствами.

>> хочется сделать сервер, который будет устойчив к его изъятию / физическому взлому

Огорчу, но такого не бывает.

Бывает. Называется «элемент неизвлекаемости». Правда, имеет два недостатка: трудно найти в свободной продаже, и замахаешься с обслуживанием.

CaveRat ★★
()
Ответ на: комментарий от noroots

Вручную

Можно поподробнее? Контейнер каждый раз монтировался вручную с вводом пароля?

Да, каждый раз при монтировании контейнера я вводил пароль. Я уже писал выше, что тут либо дудочка, либо кувшинчик. Либо автоматизация, либо шифрование. Учитывая, что полная автоматизация правильных резервных копий невозможна (холиварщики, вперёд!), я выбрал шифрование. Раз в неделю я подключал контейнер, на него лилась полная резервная копия и дневные инкременатальные, потом отключал и отдавал начальнику, который увозил НЖМД домой в сейф, а мне привозил другой.

На самом деле начальнику я отдавал бэкапы с прошлой недели.

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

Важно иметь хотя бы одну копию не подключенную вообще ни к чему, чтобы её никто не мог испортить, ни хэккер, ни взбесившийся админ, ни небо, ни даже Аллах.

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

Camel ★★★★★
()
Ответ на: комментарий от anonymous

Бред

Угу, и каждый раз бэкапить всё вместо изменённых файлов.

Вот это сюрприз. Придётся стереть мою память, потому что я каждую ночь делал инкрементальные бэкапы.

Camel ★★★★★
()
Ответ на: Бред от Camel

Вот это сюрприз. Придётся стереть мою память, потому что я каждую ночь делал инкрементальные бэкапы.

Или что-то типа rdiff-backup с соответствующими тормозами, или монтировать.

anonymous
()
Ответ на: Вручную от Camel

Наверное, начну с реализации чего-то подобного. Копии в пределах недели оставлю открытыми, это облегчит аварийное восстановление. Обратные инкрементальные части буду еженедельно шифровать в контейнер или encfs вручную или скриптом, запускаемым извне. Опционально вывод в offsite шифрованной части архива через ssh туннель, во избежание лишних вопросов. Вроде сумбур проясняется.

noroots
() автор топика

Linux'овые демоны, типа rsyncd, как я понял, под windows запускать довольно проблематично.

ничего сложного, всё работает.

ktk ★★★★
()
Ответ на: комментарий от noroots

Bacula+LUKS

Посмотрите на Bareos и Bacula. Куча недостатков, но лучше пока ничего не сделали (из свободного).

Сразу предупреждаю, тамошнее шифрование оставляет имена файлов открытым текстом, поэтому рекомендую создавать нешифрованые копии на LUKS'овое устройство.

Camel ★★★★★
()
Ответ на: комментарий от noroots

Копии в пределах недели оставлю открытыми, это облегчит аварийное восстановление.

И зачем тогда шифровать остальное?

anonymous
()

Есть асимметричное шифрование. Для шифрования используется один ключ, для расшифровки - другой. Есть кто-то получит ключ для шифрования, расшифровать данные это ему не поможет.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

Компания маленькая и не занимается интеллектуальной собственностью. Предполагаю, что единственный интерес в резервируемых компах может представлять отчетность и первичная информация для ее формирования. Шифровать актуальные данные большого смысла нет - за соседней дверью клиент на котором они же с еще меньшими проблемами с доступом, ибо windows. А вот ретроспектива всей «первички» и того, как она переходит в отчетность, мне представляется требующей защиты.

noroots
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.