4 ms·

As somebody who has switched to Linux-only (desktop+servers) years ago, seeing how ransomeware gets "ported" to Linux makes me overthinking my backup system. H

by ktpsns 6y ago

As somebody who has switched to Linux-only (desktop+servers) years ago, seeing how ransomeware gets "ported" to Linux makes me overthinking my backup system. Has anybody experience with immutable backups? This is so important, because many ransomeware codes attacks backups first. I think offline backups on write-once media are the safest. A DVD-RW is the only thing I can think of, but this is quite elaborate and doesn't seem contemprary in 2020. Do I miss something?

shock 6y ago
M-Disc
worewood 6y ago
Tape.
dxld 6y ago
I've been thinking about this problem for a while now. Personally I use restic[1] and B2 with a dedicated API key that can't delete anything. [1]: Patched slightly to make it work, https://github.com/restic/restic/pull/2398 https://github.com/restic/restic/pull/2398 (hope this will get merged eventually) How one goes about not accumulating backups forever is a problem with this setup. My basic plan is manually switching to another bucket and verifying the newly backed-up data before deleting the old bucket. You can also enable a time-based deprecation of hidden files on B2 then you don't have to actively do anything, but in theory if the malware bides its time it could still delete/overwrite everything without you noticing. If you want to self-host the restic/rest-server also has a --append-only flag that would have a similar effect, but if you use that you'll have to make sure the malware can't hop onto your backup machine via ssh.
viraptor 6y ago
You can do lots of other things, it just depends on what's important / what do you want to achieve. In almost any online storage you can implement backups as close to immutable by having two amounts. One for upload, another one for long term storage with the second one only ever written to via an isolated, non interactive, simple process (think AWS lambda). Or use you access policies which allow file creation and nothing else. Or many other ways.
20after4 6y ago
Just use plain hard drives with spinning disks.* Make backup, then disconnect, then use a fresh drive next time, keeping at least 1 extra drive offline on a shelf or in a safe deposit box if you're extra paranoid. Keeping the drive off-site also helps to insure against fire, natural disasters or theft. Rotate drives regularly to keep the off-site backup fresh and to spread the (minimal) wear across several drives. When used in this manner and stored correctly, a set of say 3 to 5 hard drives can be expected to last a _very_ long time. * This is important, because solid state drives are not suited to long term offline storage, they can lose data surprisingly quickly if you leave them sitting on a shelf.
gcc42 6y ago
I thought about this exact problem a month ago when I got paranoid (I'm on Windows) , and my solution involved setting up a separate cheap Linux node in my home and attaching my backup drive to it. The server is locally SSHable, but only authenticates via password that I have to type in during each backup. Key authentication is disabled. I use borg backup so I don't even have to give shell access to this particular account (there are hardened borg configs available online). If you're more paranoid about security, you can enable 2FA over SSH, or make sure the backup server itself creates a periodic offline backup of the backup repository, without the SSH account having permissions to that of course. Honestly though as long as you're not doing something stupid like mounting NFS to your vulnerable device to make backups, you should be mostly fine.

by ktpsns 6y ago

shock 6y ago

M-Disc

worewood 6y ago

Tape.

dxld 6y ago

I've been thinking about this problem for a while now. Personally I use restic[1] and B2 with a dedicated API key that can't delete anything. [1]: Patched slightly to make it work, https://github.com/restic/restic/pull/2398 https://github.com/restic/restic/pull/2398 (hope this will get merged eventually) How one goes about not accumulating backups forever is a problem with this setup. My basic plan is manually switching to another bucket and verifying the newly backed-up data before deleting the old bucket. You can also enable a time-based deprecation of hidden files on B2 then you don't have to actively do anything, but in theory if the malware bides its time it could still delete/overwrite everything without you noticing. If you want to self-host the restic/rest-server also has a --append-only flag that would have a similar effect, but if you use that you'll have to make sure the malware can't hop onto your backup machine via ssh.

viraptor 6y ago

You can do lots of other things, it just depends on what's important / what do you want to achieve. In almost any online storage you can implement backups as close to immutable by having two amounts. One for upload, another one for long term storage with the second one only ever written to via an isolated, non interactive, simple process (think AWS lambda). Or use you access policies which allow file creation and nothing else. Or many other ways.

20after4 6y ago

Just use plain hard drives with spinning disks.* Make backup, then disconnect, then use a fresh drive next time, keeping at least 1 extra drive offline on a shelf or in a safe deposit box if you're extra paranoid. Keeping the drive off-site also helps to insure against fire, natural disasters or theft. Rotate drives regularly to keep the off-site backup fresh and to spread the (minimal) wear across several drives. When used in this manner and stored correctly, a set of say 3 to 5 hard drives can be expected to last a _very_ long time. * This is important, because solid state drives are not suited to long term offline storage, they can lose data surprisingly quickly if you leave them sitting on a shelf.

gcc42 6y ago

I thought about this exact problem a month ago when I got paranoid (I'm on Windows) , and my solution involved setting up a separate cheap Linux node in my home and attaching my backup drive to it. The server is locally SSHable, but only authenticates via password that I have to type in during each backup. Key authentication is disabled. I use borg backup so I don't even have to give shell access to this particular account (there are hardened borg configs available online). If you're more paranoid about security, you can enable 2FA over SSH, or make sure the backup server itself creates a periodic offline backup of the backup repository, without the SSH account having permissions to that of course. Honestly though as long as you're not doing something stupid like mounting NFS to your vulnerable device to make backups, you should be mostly fine.