Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: Could we create an immutable incremental backup system to protect against ransomware?

  1. #11
    Join Date
    Mar 2010
    Location
    Squidbilly-Land
    Beans
    Hidden!
    Distro
    Ubuntu

    Re: Could we create an immutable incremental backup system to protect against ransomw

    The other solution is to have a backup server that "pulls" the backups. Then the client wouldn't be able to access any of the backup storage. rdiff-backup supports "pulling". If you want more security, setup an alternate userid that is equivalent to root just for backup needs. Then lock that account down so it can only run the commands necessary for the backups. This is how github works from the CLI with ssh-keys. Each userid can only run 1 program on the connection - "git". No shells. Nothing else. Just git. For backups, probably want to run
    1. pre-backup script,
    2. backup script and
    3. post-backup script.

    Use the authorized_keys file with restrictions on the client allowed to connect using specific keys, each to run a specific command. Look for command= in the sshd manpage.
    The old tcp-wrappers files work for limiting by IP and/or userid, but limiting the commands can only happen in the ssh configs.

    I hope you aren't doing versioned backups of media files. That will make backups balloon. Also restricting what gets backed up to just the stuff that is necessary to put everything back pre-backup, can save 4-10G, easy. I don't backup the OS, for example. I just get the settings, lists of installed packages, and the data. For programs that are installed outside APT, I place those under /usr/local/ which does get backed up like all the HOME directories do.

    But the key is to "pull" the backups, never "push" them. Just be certain that your backup server isn't nice to undesired network locations.

  2. #12
    Join Date
    Oct 2004
    Location
    Albuquerque New Mexico, U
    Beans
    1,182
    Distro
    Ubuntu Development Release

    Re: Could we create an immutable incremental backup system to protect against ransomw

    Quote Originally Posted by Paddy Landau View Post
    With immutable incremental backups, of course, I'd have to accept having larger drives with corresponding increase in costs.
    Your immutable backup store doesn't have to be literally immutable. It just needs to be protected against any unauthorized alterations or deletions in the backup store.

    Some smart person could probably work out a scheme using access groups and ACLs that would do that, but still permit periodic pruning of the backup store to control disk consumption. Something like files in this directory are read-only except to the application rdiff-backup running on machine [some unique identifier] under user who is a member of [special backup group].

    Macrium Reflect for Windows does something similar, except I think it uses an application daemon to monitor accesses to the backup store and blocks write attempts and certain other file operations from all but from the application itself. Don't know how effective it is. The automatic pruning routine is very effective and efficient and I haven't had the need to interfere with what Reflect thinks best.
    Last edited by rbmorse; June 5th, 2021 at 10:36 PM.
    regards

  3. #13
    Join Date
    Mar 2010
    Location
    Squidbilly-Land
    Beans
    Hidden!
    Distro
    Ubuntu

    Re: Could we create an immutable incremental backup system to protect against ransomw

    If a higher level directory is locked down, say
    root:root 0700,
    then only root will be able to have access below there, regardless of the permissions, owners, ACLs in any subdirectories.

    There are lots of ways to ensure backups aren't tampered. Use Encrypted storage and parity files. Tools like duplicity have a checksum for each file, which would almost prove that the backup hadn't been tampered with. There are cryptographic signature tools, like openssl which can be used as a pipe-filter for encrypting any data that goes through the filter. gpg can work the same, if stronger methods are necessary.

    Or use a file as a block device, mounted with a loop, and lay down a file system inside it, then place the backups into that file system. When complete, umount the loop device, create a sha256sum for for the block-file or a gpg signature of it. Keep that signature with the block file.

    Almost everything on Unix-like OSes are files, so we can treat them however we actually like, as needed. That goes for whole disks, disk partitions or regular files - we can treat each like the other, when it is convenient.

  4. #14
    Join Date
    May 2008
    Location
    United Kingdom
    Beans
    4,783
    Distro
    Lubuntu 18.04 Bionic Beaver

    Re: Could we create an immutable incremental backup system to protect against ransomw

    Thank you for all of your replies. It looks as though creating this sort of backup requires good technical knowledge, and maybe a remote server that I personally look after!
    Quote Originally Posted by scorp123 View Post
    Follow the link I provided.
    Thanks, that worked.
    Quote Originally Posted by TheFu View Post
    The other solution is to have a backup server that "pulls" the backups. … the key is to "pull" the backups, never "push" them.
    That's a clever idea that I hadn't thought of. I'll have to learn a lot more about this method before trying to implement it.
    Quote Originally Posted by TheFu View Post
    I hope you aren't doing versioned backups of media files.
    Indeed, no I don't!
    Quote Originally Posted by TheFu View Post
    I don't backup the OS, for example. …
    No, I back up only the data including settings.
    Quote Originally Posted by TheFu View Post
    If a higher level directory is locked down, … only root will be able to have access below there…
    Now, that's a great idea! I'll see if I can implement this, because it would possibly be the simplest solution.

    Thank you again, everyone!
    Always make regular backups of your data (and test them).
    Visit Full Circle Magazine for beginners and seasoned Linux enthusiasts.

  5. #15
    Join Date
    Mar 2010
    Location
    Squidbilly-Land
    Beans
    Hidden!
    Distro
    Ubuntu

    Re: Could we create an immutable incremental backup system to protect against ransomw

    Quote Originally Posted by Paddy Landau View Post
    Now, that's a great idea! I'll see if I can implement this, because it would possibly be the simplest solution.
    We have to assume the client machines are completely cracked. Never trust the client. It does dangerous things. It has internet access. This is why only "pull"ed backups can fight malware/cryptoware.

    And it should be clear that using any networked storage that is accessible by clients, besides read-only mounts, won't work. If the client can mount storage read-write, then the malware can change all those backup files.

    There are lots of subtle choices with backups that improve the security and convenience.

    BTW, rdiff-backup works with "pull"ed backups just fine. The SOURCE directories are just on the other system with the TARGET directories local to the backup server.
    Code:
    $ sudo   rdiff-backup 
            --exclude-special-files \
            --include /usr/local --include /etc --include /home  --include /root \
            --exclude '**'   backup5492@{remote-machine}::/ \ 
            /Backups/{remote-machine}
    where:
    • Backups are run from a backup server via root's crontab (the sudo above not needed), just for initial work,
    • connect to a random account, say backup5492, on the remote system and
    • "pull"ed specific included directories, excluding everything else (wouldn't hurt to clean up junk in HOME directories nightly and to exclude .Trash and cache directories in HOMEs.
    • Random account is a root-equiv with ssh-keys from the backup server installed just for that system, only allowed to run 3 commands: pre-backup, backup, post-backup scripts and only from the backup server.
    • The account keys are in the ~/.ssh/config of the root account on the backup server - might as well make the backup5492 username the default for the aliased connections to the system so we don't need to know or add to the script anything but the correct ssh-alias for the host. manpage for ssh_config has all the possible settings in ~/.ssh/config, but in general, we'll need something like this:
      Code:
      host spam-backup
        user backup5492 
        hostname 172.22.22.81
        port 22
        IdentityFile ~/.ssh/id_ed25519-backup
      Tie the host alias to the different key file for the pre/post and backup allowed commands. On the other side, the backup5492 authorized_keys file will need 3 entries with command= limits. Ref authorized_keys manpage for more details.

    Subtle things.

  6. #16
    Join Date
    Mar 2016
    Beans
    7

    Re: Could we create an immutable incremental backup system to protect against ransomw

    chmod 000 should work.

    But ransomeware should not be an issue, if it is, then there is something else not correct. I have noticed system.d has bugs in it that Redhat fixed for themselves but didn't share that with the other distros. Be aware of this as I removed system.d from my commercial hosting servers because of this critical bug.

Page 2 of 2 FirstFirst 12

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •