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

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

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

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

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

я хочу делать бэкапы, но с помощью zfs снепшотов и синхронизировать это все с удаленным пулом. Хочу использовать мощь ZFS

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

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

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

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

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

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

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

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

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

Я писал:

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

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

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

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

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

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

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

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

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

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

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

Вот тестовый бэкапсервер и у него все хорошо со снепшотами, полученными через 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 или отвечаем, чтобы пообщаться?

так вот эти инкрементые бекапы и шифровать открытым ключом.

Как? Я уже писал, что я не отправляю и не экспортирую снапшоты в файлы.

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

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

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

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

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

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

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

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

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

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

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

стоят 0.

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

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

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

у него нет снапшотов :) тут делается просто копия файловой системы посредство 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  -

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

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

хотя есть системы онлайн слежения за неизменностью системы

auditd? не, не слышале.

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

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

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

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

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

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

и шифровать, естественно, не диск на котором zpool, а фс на zvol.

спасибо, вроде понятно. Погоняю тесты на днях.

Прямо сейчас - либо zfs send | gpg, либо zfs over luks на целевой машине (либо zfs native encryption, но я его не пробовал).

Отличная мысль!

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

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 решил не использовать, так как не хочу зашифрованный сторедж на стороне продакшена.