Re: [pbs-devel] [PATCH proxmox-backup 5/5] docs: added section on ransomware

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

in general there are various trailing whitespace

```
Applying: docs: added section on ransomware
.git/rebase-apply/patch:23: trailing whitespace.
encrypts files until a ransom is paid. Proxmox Backup Server includes features to 
.git/rebase-apply/patch:30: trailing whitespace.
Backup Server. By limiting a sync user's or an access token's right to only write 
.git/rebase-apply/patch:35: trailing whitespace.
it can no longer be backed up by a Proxmox Backup Server instance. This is because the 
.git/rebase-apply/patch:49: trailing whitespace.
by Proxmox Backup Server. These recommendations include, but are not limited to: 
.git/rebase-apply/patch:51: trailing whitespace.
* Using `two-factor authentification <https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pveum_tfa_auth>`_ 
warning: squelched 2 whitespace errors
warning: 7 lines add whitespace errors.
```



Am 23/11/2022 um 18:48 schrieb Noel Ullreich:
> From: Noel Ullreich <nullreich@eloa.proxmox.com>
> > Added a section on ransomware that lists the features
> offered by pbs to protect from ransomware as well as
> best practices outside of pbs
> 
> Signed-off-by: Noel Ullreich <n.ullreich@proxmox.com>
> ---
>  docs/storage.rst | 58 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 58 insertions(+)
> 
> diff --git a/docs/storage.rst b/docs/storage.rst
> index c4e44c72..60991cb9 100644
> --- a/docs/storage.rst
> +++ b/docs/storage.rst
> @@ -374,3 +374,61 @@ with a comma, like this:
>  .. code-block:: console
>  
>    # proxmox-backup-manager datastore update <storename> --tuning 'sync-level=filesystem,chunk-order=none'
> +
> +.. _ransomware_protection:
> +
> +Ransomware Protection
> +---------------------
> +
> +Prevention by Proxmox Backup Server
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +`Ransomware <https://en.wikipedia.org/wiki/Ransomware>`_ is a type of malware that
> +encrypts files until a ransom is paid. Proxmox Backup Server includes features to 
> +prevent ransomware attacks.

We cannot prevent ransomware attacks in general on a setup/datacenter/..., but PBS can
be used to insure against such attacks by making it possible, and relatively easy to
recover by restoring a backup.

> +
> +Proxmox Backup Server does not allow for existing chunks of a backup to be re-uploaded.

It does not re-writes data for existing blocks, making them immutable. As just because
our (uncompromised) client does not uploads chunks again as optimization you can do so
just fine, and it's not forbidden on an api level, but, and that's the important thing,
we don't re-write the data if it already exisits but only touch (update) the access time.

IMO that difference is important, as somebody testing this would be surprised after
reading this, if they can re-upload chunks (seemingly!) just fine as the API tells
OK.

> +This means that a compromised Proxmox VE cannot corrupt existing backups.
s/Proxmox VE/Proxmox VE host/ or maybe even include clients more generally, something
like (not closely typo checked):

This means that a compromised Proxmox VE host, or any other compromised system using
the client to backup data, cannot corrupt existing backups.

> +
> +Furthermore, comprehensive :ref:`user management <user_mgmt>` is offered in Proxmox
> +Backup Server. By limiting a sync user's or an access token's right to only write 
> +backups, not delete them, compromised Proxmox VEs cannot delete existing backups. Backup
> +pruning should be done by the Proxmox Backup Server itself.

"In that case, backup pruning should be handled on the Proxmox Backup Server using
prune jobs."

> +
> +Should a guest running in a Proxmox VE instance become compromised and encrypted,
> +it can no longer be backed up by a Proxmox Backup Server instance. This is because the 

huh? a encrypted guest can be backed up just fine? Otherwise users couldn't use
desired encryption for privacy/integrity, e.g. things like LUKS in the guest.

> +SHA-256 checksum can no longer be read. This should alert you that your backups are
> +corrupted and might indicate a compromised Proxmox VE (although it should be noted that
> +verify jobs can also fail for other reasons, such as bit rot).

Do you mean restore test here? this section seems off

> +
> +To detect ransomware inside a compromised guest, it is recommended to frequently

maybe hint that its restore _test_ing (not that people think they need to restore over
existing guests ^^)
s/frequently restore and boot backups fully/frequently test restoring and booting backups/

> +restore and boot backups fully. In the case of many backed-up guests, it is
> +recommended to automate this restore testing or, if this is not possible, to restore
> +random samples from the backups.
> +
> +Other Prevention Methods and Best Practices
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +It is recommended to take additional security measures, apart form the ones offered
> +by Proxmox Backup Server. These recommendations include, but are not limited to: 

wouldn't half of this section fit better into PVE? So that PBS docs only links at that
and gives tipps here about how to make PBS more resistant (use API tokens, setup remote
sync, ...) - can be done later too though, for now I'd just keep fail2ban and TFA tipss
for PVE out, we're talking about PBS-as-insurance-for-after-the-fact here.

> +
> +* Using `two-factor authentification <https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pveum_tfa_auth>`_ 

s/authentification/authentication/

> +  for user management in the Proxmox Virtual Environment.
> +* Using `Fail2ban <https://pve.proxmox.com/wiki/Fail2ban>`_ to secure the 
> +  Proxmox Virtual Environment web interface. Fail2ban monitors login attempts and
> +  temporarily bans IP addresses that try unsuccessfully to log in too many times.



> +* Using `RSA keys with SSH <https://wiki.debian.org/SSH>`_.

Why RSA, are ecdsa, ... insecure?

> +* Keeping the firmware and software up-to-date to patch exploits and vulnerabilities
> +  (such as `spectre <https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)>`_ or
> +  `meltdown <https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)>`_).
> +* Following safe and secure network practices, for example using logging and
> +  monitoring tools and setting up vlans.

s/vlans/VLANs/

> +* Making plenty of backups using the
> +  `3-2-1 rule <https://en.wikipedia.org/wiki/Backup#Storage>`_: creating
> +  3 backups on 2 storage media, of which 1 copy is kept offsite.

s/offsite/off-site/

> +* Retaining backups for a few months. Some ransomware might only be encrypted weeks after an infection.

maybe rather something along:

Retaining backups for a longer period, using Proxmox Backup Server's
flexible retention keep settings, as you may only notice that guest got
encrypted by an attacker after some days or even weeks, which makes the
newer backups unusable too.

> +* Creating :ref:`tape backups <tape_backup>` and :ref:`remote sync jobs <backup_remote>`.

I'd flesh that out as short e.g. "Off-Site Safe Keeping" sub-section above.

> +* Restore testing: frequently test if the backups of the guests can be correctly restored.
> +
> +For more information on how to avoid ransomware attacks and what to do in case of a ransomware infection, see `Cisa <https://www.cisa.gov/stopransomware/ransomware-guide>`_.
> +

overly long line