How do I send a ZFS snapshot to an immutable offsite target?

[PhilipMay]

Hi,

many guides suggest to do snapshots and then send + recv them over ssh to an other offsite server.

Now the problem I see is: if the source server is hacked (ransomware) the target backup server can just be
deleted.

Now my question: How can I make the target backup server (the one that recv the data) make immutable?
So data is received but can not be deleted?

Many thanks
Philip

[rincebrain]

I mean, if you're not using recv -F, it's not going to clobber your old snapshots, so at that point, the worst that can happen if the sender can only pipe things into a recv is the latest snapshot versions will have the data deleted. If you delete the old snapshots on the destination, of course, then the data is gone, but if you're not doing that, or using recv -F, then I don't believe a receive is going to delete your data permanently...

If your threat model is the sender sshing in and running commands, then that's a harder problem, but I think if you don't mind it not being able to mount the filesystem you can successfully delegate that on Linux to nonroot? (And you probably don't want it mounting on a ro backup destination anyway since then it would have to replay things in progress when the snapshot was taken, which can break incremental recv without a manual rollback...) (I also haven't had a problem where I've had to use this, so it might still not work for reasons involving interactions with the above mount caveats, but that would be my thought.)
(On FreeBSD there's no problem AFAIK, Linux just has hard special-casing of calling mount, is my understanding.)

I guess if you're using native encryption the sender could pipe in a change-key if it's doing send -w, but hopefully you're not doing that.

[IvanVolosyuk]

There are 2 parts to this question: 1. secure data transfer 2. minimum privileges on the remote end Ssh gives secure transfer, but not the only option. HTTPS with server and client certificates can probably be used as transport. Even with ssh you can for example reverse - instead of pushing the backend you can pull them from the backup server. Another option, restrict ssh target to limit what can be executed there, say change shell in /etc/passwd to be 'sudo zfs recv backup/host-foo' or a script which rate-limits recv requests with alerting and does the bookkeeping.

…

On Sun, Jan 22, 2023 at 10:40 PM Philip May ***@***.***> wrote: Hi, many guides suggest to do snapshots and then send + recv them over ssh to an other offsite server. Now the problem I see is: if the source server is hacked (ransomware) the target backup server can just be deleted. Now my question: How can I make the target backup server (the one that recv the data) make immutable? Do data is received but can not be deleted? Many thanks Philip — Reply to this email directly, view it on GitHub <#14417>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXQ6HP3AR6MWGASNCINLIDWTUMDNANCNFSM6AAAAAAUC564RI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>