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

[Noel Ullreich <n.ullreich@proxmox.com>]

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.
+
+Proxmox Backup Server does not allow for existing chunks of a backup to be re-uploaded.
+This means that a compromised Proxmox VE 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.
+
+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 
+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).
+
+To detect ransomware inside a compromised guest, it is recommended to frequently
+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: 
+
+* Using `two-factor authentification <https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pveum_tfa_auth>`_ 
+  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>`_.
+* 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.
+* 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.
+* Retaining backups for a few months. Some ransomware might only be encrypted weeks after an infection.
+* Creating :ref:`tape backups <tape_backup>` and :ref:`remote sync jobs <backup_remote>`.
+* 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>`_.
+
-- 
2.30.2