using btrfs subvolume as a write once read many medium

using btrfs subvolume as a write once read many medium

[spaarder]

Hello,

With all the ransomware attacks I am looking for a "write once read
many" (WORM) solution, so that if an attacker manages to get root
access on my backup server, it would be impossible for him to
delete/encrypt my backups.

Using btrbk I already have readonly daily snapshots on my backupserver.
Is there any way to password protect the changing of the properties of
these subvolumes, so an attacker could not just simply set the RO
property to false? Any support for a feature request?

Big thanks for this MAGNIFICENT filesystem!!

Re: using btrfs subvolume as a write once read many medium

[David Sterba]

On Wed, Jul 29, 2020 at 09:02:14AM +0200, spaarder wrote:
> Hello,
> 
> With all the ransomware attacks I am looking for a "write once read
> many" (WORM) solution, so that if an attacker manages to get root
> access on my backup server, it would be impossible for him to
> delete/encrypt my backups.
> 
> Using btrbk I already have readonly daily snapshots on my backupserver.
> Is there any way to password protect the changing of the properties of
> these subvolumes, so an attacker could not just simply set the RO
> property to false? Any support for a feature request?

I could dust off my old idea of so called 'sealed' subvolumes, that
would do something similar to that: it could start as a read-write
subvolume or read-only snapshot, switched back and forth rw/ro any
number of times but once it's set as 'sealed', no switching allowed
anymore. It could be snapshotted again or deleted.

For your usecase, the deletion would be still be a problem though and
protecting against root actions would need some countermeasures outside
of filesystem reach.

Re: using btrfs subvolume as a write once read many medium

[Roman Mamedov]

On Wed, 29 Jul 2020 09:02:14 +0200
spaarder <spaarder@hotmail.nl> wrote:

> Hello,
> 
> With all the ransomware attacks I am looking for a "write once read
> many" (WORM) solution, so that if an attacker manages to get root
> access on my backup server, it would be impossible for him to
> delete/encrypt my backups.

If the attacker gets root on the said server, they could just do
"dd if=/dev/zero of=/your/btrfs", and no amount of password-protected,
read-only or sealed subvolumes will save you.

If you want to be more secure against that, include offline (powered off)
media into your backup scheme, which is powered-on to synchronize e.g. only
for short periods of time and under close supervision.

Or, if practical for your budgets and data volumes, even not just hard disks,
but also tape or optical writable-once media (e.g Blu-ray).

There are also some creative ways you can makeshift a write-only remote server
using "the cloud", such as emailing encrypted backups to your own E-Mail
account at say Gmail, with passwords or even 2-factor authentication to that
account kept securely and separately from everything else. (Suitable for
smaller amounts of data, though).

> Using btrbk I already have readonly daily snapshots on my backupserver.
> Is there any way to password protect the changing of the properties of
> these subvolumes, so an attacker could not just simply set the RO
> property to false? Any support for a feature request?

-- 
With respect,
Roman

Re: using btrfs subvolume as a write once read many medium

[Zdenek Kaspar]

On Wed, 29 Jul 2020 12:29:47 +0200
David Sterba <dsterba@suse.cz> wrote:

> On Wed, Jul 29, 2020 at 09:02:14AM +0200, spaarder wrote:
> > Hello,
> > 
> > With all the ransomware attacks I am looking for a "write once read
> > many" (WORM) solution, so that if an attacker manages to get root
> > access on my backup server, it would be impossible for him to
> > delete/encrypt my backups.
> > 
> > Using btrbk I already have readonly daily snapshots on my
> > backupserver. Is there any way to password protect the changing of
> > the properties of these subvolumes, so an attacker could not just
> > simply set the RO property to false? Any support for a feature
> > request?
> 
> I could dust off my old idea of so called 'sealed' subvolumes, that
> would do something similar to that: it could start as a read-write
> subvolume or read-only snapshot, switched back and forth rw/ro any
> number of times but once it's set as 'sealed', no switching allowed
> anymore. It could be snapshotted again or deleted.
> 
> For your usecase, the deletion would be still be a problem though and
> protecting against root actions would need some countermeasures
> outside of filesystem reach.
> 

Maybe make them single-sealed aka removable only in "single"
user mode? Together with LUKS protected rootfs it could be sufficient.

HTH, Z.

Re: using btrfs subvolume as a write once read many medium

[Alberto Bursi]

On 29/07/20 09:02, spaarder wrote:
> Hello,
>
> With all the ransomware attacks I am looking for a "write once read
> many" (WORM) solution, so that if an attacker manages to get root
> access on my backup server, it would be impossible for him to
> delete/encrypt my backups.

The only way protect them from an user with root privilege is to move 
the backups off that server alltogether, as root can simply erase or 
encrypt the raw block device, and the filesystem really cannot do much 
about that even if it could be set as permanently readonly.

So, keep a NAS as a dedicated backup server (i.e. that's the only job, 
to limit the ways someone can get into it).

Then you should limit what an external request can do in the backup 
server application/script/whatever settings, so that it will accept a 
new backup or an incremental backup from a client, but it will not 
accept a request to delete a backup.

And obviously have more than one backup, possibly off-site.

-Alberto

Re: using btrfs subvolume as a write once read many medium

[Graham Cobb]

On 29/07/2020 13:03, Roman Mamedov wrote:
> On Wed, 29 Jul 2020 09:02:14 +0200
> spaarder <spaarder@hotmail.nl> wrote:
> 
>> Hello,
>>
>> With all the ransomware attacks I am looking for a "write once read
>> many" (WORM) solution, so that if an attacker manages to get root
>> access on my backup server, it would be impossible for him to
>> delete/encrypt my backups.
> 
> If the attacker gets root on the said server, they could just do
> "dd if=/dev/zero of=/your/btrfs", and no amount of password-protected,
> read-only or sealed subvolumes will save you.
> 
> If you want to be more secure against that, include offline (powered off)
> media into your backup scheme, which is powered-on to synchronize e.g. only
> for short periods of time and under close supervision.

Roman makes excellent points. What I do is a combination of different
types of backups. Basically:

- There are local backup disks on most systems. These have a few local
snapshot-based backups primarily for easy restoration of accidentally
deleted files. These could be easily trashed by any rogue software. In
some cases they also keep some local backups which are only accessible
to root - but they could also be trashed by software which can get local
root access.

- My main backups are created on a separate backup server. That has ssh
key-based access into the user systems (but not the other way around)
and uses btrbk to create backups (with snapshots going back several
years). It doesn't run user applications so compromising it would
require a remote root access hole in the standard debian packages it
uses. Which is unlikely but not impossible.

- My "offsite" backups (mainly to protect against a fire at home, but
useful for ransomware as well) archive backups to cloud services. Again
with archives going back years.

- I also occasionally copy some encrypted backups onto disks I
physically remove and store at friends houses. Fortunately I have never
needed one of these.

It is actually a bit more complicated than that but the bottom line is
that a person, willing to spend time discovering all my backups and
exploiting (currently unknown) remote access bugs could destroy all my
backups except the disks stored at other houses. However, as I am not
worrying about state-level attackers, I am confident that ransomware
software would not be able to do it.

Re: using btrfs subvolume as a write once read many medium

[Robert Krig]

On 29.07.20 09:02, spaarder wrote:
> Hello,
>
> With all the ransomware attacks I am looking for a "write once read
> many" (WORM) solution, so that if an attacker manages to get root
> access on my backup server, it would be impossible for him to
> delete/encrypt my backups.
>
> Using btrbk I already have readonly daily snapshots on my backupserver.
> Is there any way to password protect the changing of the properties of
> these subvolumes, so an attacker could not just simply set the RO
> property to false? Any support for a feature request?
>
> Big thanks for this MAGNIFICENT filesystem!!
>
>

If an attacker gets root access to your server, then there is not much 
you can do to prevent them from deleting backups. Your best protection 
against something like that is backing up to multiple destinations.

Re: using btrfs subvolume as a write once read many medium

[Chris Murphy]

On Wed, Jul 29, 2020 at 1:02 AM spaarder <spaarder@hotmail.nl> wrote:
>
> Hello,
>
> With all the ransomware attacks I am looking for a "write once read
> many" (WORM) solution, so that if an attacker manages to get root
> access on my backup server, it would be impossible for him to
> delete/encrypt my backups.

Ultimately you have to prevent an attacker from getting root access.
Once they have root access they can do anything you can do with root
access, including merely zeroing out less than 15MiB of critical Btrfs
metadata and render it completely unrecoverable. That this could still
happen indicates a need for independent backups. That is, more than
one set, and one or more sets aren't even connected to this system, or
at the least, aren't persistently connected to this system.



-- 
Chris Murphy