From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 0A05AB744 for ; Thu, 24 Nov 2022 11:24:24 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E08C12C97D for ; Thu, 24 Nov 2022 11:23:53 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 24 Nov 2022 11:23:52 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 5AB1144458; Thu, 24 Nov 2022 11:23:52 +0100 (CET) Message-ID: <155c8909-50b4-b93f-e9a7-77c11867d2d1@proxmox.com> Date: Thu, 24 Nov 2022 11:23:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:108.0) Gecko/20100101 Thunderbird/108.0 Content-Language: en-GB To: Proxmox Backup Server development discussion , Noel Ullreich Cc: Noel Ullreich References: <20221123174810.2703466-1-n.ullreich@proxmox.com> <20221123174810.2703466-6-n.ullreich@proxmox.com> From: Thomas Lamprecht In-Reply-To: <20221123174810.2703466-6-n.ullreich@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.429 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_ASCII_DIVIDERS 0.8 Spam that uses ascii formatting tricks KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com, cisa.gov, wikipedia.org] Subject: Re: [pbs-devel] [PATCH proxmox-backup 5/5] docs: added section on ransomware X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2022 10:24:24 -0000 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 `_ warning: squelched 2 whitespace errors warning: 7 lines add whitespace errors. ``` Am 23/11/2022 um 18:48 schrieb Noel Ullreich: > From: Noel Ullreich > > 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 > --- > 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 --tuning 'sync-level=filesystem,chunk-order=none' > + > +.. _ransomware_protection: > + > +Ransomware Protection > +--------------------- > + > +Prevention by Proxmox Backup Server > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +`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 ` 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 `_ s/authentification/authentication/ > + for user management in the Proxmox Virtual Environment. > +* Using `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 `_. Why RSA, are ecdsa, ... insecure? > +* Keeping the firmware and software up-to-date to patch exploits and vulnerabilities > + (such as `spectre `_ or > + `meltdown `_). > +* 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 `_: 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 ` and :ref:`remote sync jobs `. 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 `_. > + overly long line