LINUX.ORG.RU

zfs backup на remote шифрованый диск

 , , , ,


1

3

Привет. Задача такая: есть zpool , который я будут синхронизировать ssh send/receive на внешний сервер.

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

Ну и еще на систему можно поставить inotify и мониторить любые изменения в /. Так что если кто-то поставил систему раком и ставит руткиты, чтобы отснифить ключ маунта, который передается при send/receive , то я успеваю автоматически остановить/отменить следующую синхронизацию и примуанчивание дисков.

Есть какие-то готовые решения/мысли?

Или может я херню вообще написал и есть best practice по этому поводу?

Ну и еще на систему можно поставить inotify и мониторить любые изменения в /. Так что если кто-то поставил систему раком и ставит руткиты, чтобы отснифить ключ маунта, который передается при send/receive , то я успеваю автоматически остановить/отменить следующую синхронизацию и примуанчивание дисков.

Делать бекапы будет не легче ?

Samamy ★★ ()

может просто поток/файл, сгенерированный send, шифровать с помощью открытого ключа ?? тем же gpg
не имея закрытого ключа с бекапами ничего не сделаешь. а его держать очень сильно секурно :)
украдут открытый ключ - да х с ним. сделать ключи подлиннее и профит ??

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

может просто поток/файл, сгенерированный send, шифровать с помощью открытого ключа ??

Поток-то я зашифрую, но тут надо понимать , что именно я хочу сделать. Я НЕ кидаю в бэкапсервер какие-то архивы в виде файлов. Я делаю zfs send/recieve , те на той стороне у меня такой же zpool, но лежащий на разделе c LUKS

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

но с помощью zfs снепшотов и синхронизировать это все с удаленным пулом

Если будут снапшоты то зачем волноваться о руткитах ? Что мешает монтировать раздел только при синхронизации ?

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

=синхронизация != бекап
версионности это не дает, для примера ты не сможешь откатиться на несколько синков назад, когда файл был а теперь его нет

я отправляю на бэкапсервер инкрементные снепшоты, таким образом версионность там будет тоже. Или я не правильно понял что-то?

Делаем на хосте снепшот и посылаем его на бэкапсервер. В результате имеем историю снепшотов на хосте и копию этого всего со снепшотами на бэкапсервере.

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

Если будут снапшоты то зачем волноваться о руткитах ? Что мешает монтировать раздел только при синхронизации ?

Вообще это изначальный вопрос поста.

Я писал:

«Они должны монтироваться только на время синхронизации.»

Меня интересуют best practice, опыт, свои наработки и мысли. Может быть я тут костыль изобретаю на ровном месте.

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

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

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

у него нет снапшотов :) тут делается просто копия файловой системы посредство tarоподбного потока send/recieve на удлаенный zpool. это таки не бекап :( в копию все руткиты просто перельются при очередной синхронизации.

мож стоит все-таки подумать о реальном бекапе ?? в принципе можно даже делать бекап из копии. я так понимаю копия используется как рабочая, т.е. в ней копают а потом заливают на основной или нет ?? зачем копия ??

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

в копию все руткиты просто перельются при очередной синхронизации.

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

у него нет снапшотов :)

У меня есть снапшоты.

Вот тестовый бэкапсервер и у него все хорошо со снепшотами, полученными через send/recieve

root@ZFS-Backup-Pool# zfs list -t snap
NAME                          USED  AVAIL  REFER  MOUNTPOINT
backup/pxe@init              1.20M      -  7.25G  -
backup/pxe@AutoD-2019-03-12     0B      -  7.25G  -

У отвечающих вообще есть какой-то опыт с zfs или отвечаем, чтобы пообщаться?

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

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

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

хотя есть системы онлайн слежения за неизменностью системы, но стоят они соотвествующе.

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

Можно внимательно читать пост?

захватив систему злоумышленник захватит все ее содержимое.

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

в принципе похер на zfs (чего ты в него уперся),

Я не спрашиваю какие существуют способы бэкапов вообще. Я меня все хорошо и бэкапится в разные места и на разных уровнях.

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

Если бы ты читал внимательно пост, то прочитал бы , что через inotify.

стоят они соотвествующе.

стоят 0.

Итого у тебя нет опыта zfs, если я правильно понял. Но есть размышления о бэкапах. Сорри, но это не тема этого поста.

P.S. Тут столько уже написали не соответствующей действительности херни. Как так можно в IT области делать?

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

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

у него нет снапшотов :) тут делается просто копия файловой системы посредство tarоподбного потока send/recieve на удлаенный zpool. это таки не бекап :( в копию все руткиты просто перельются при очередной синхронизации.

Не верно.

backup server

root@ZFS-Backup-Pool:# zfs list -t snap
NAME              USED  AVAIL  REFER  MOUNTPOINT
backup/pxe@init  1.20M      -  7.25G  -

Хост

root@pxe1804-ZFS:~# zfs send -i  pxe@init pxe@AutoD-2019-03-26 | ssh 192.168.0.121 zfs recv -vF backup/pxe
receiving incremental stream of pxe@AutoD-2019-03-26 into backup/pxe@AutoD-2019-03-26
received 116M stream in 4 seconds (29.1M/sec)

backup server

root@ZFS-Backup-Pool:# zfs list -t snap
NAME                          USED  AVAIL  REFER  MOUNTPOINT
backup/pxe@init              96.1M      -  7.25G  -
backup/pxe@AutoD-2019-03-26     0B      -  7.25G  -

И вот теперь скажи, зачем ты это написал?)

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

Сделай zvol c любой шифрованной ФС и обменивайся его снапшотами.
Таким образом бэкап сервер будет хранить образ этой ФС, а ключ к ней на него не попадёт вообще никогда.

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

Сделай zvol c любой шифрованной ФС и обменивайся его снапшотами.
Таким образом бэкап сервер будет хранить образ этой ФС, а ключ к ней на него не попадёт вообще никогда.

Можно подробнее?

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

zvol - это блочное устройство нарезанное с пула.

ну это я понимаю. Но мне бы разжевать мысль сверху. Я нифига не гуру zfs и начал ее тестировать всего неделю назад.

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

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

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

Вот так пока на тесте:

zfs send -i  pxe@init pxe@AutoD-2019-03-27 | ssh 192.168.0.121  'echo XXXXXXXXXX | cryptsetup luksOpen /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi2 luks1; zpool import lpool; zfs recv -vF lpool/pxe;zpool export lpool; cryptsetup luksClose luks1'

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

constin ★★ ()