Have to agree with Fabian and Max.
I'd like to share what we usually see on the Support side when we get cases after customers have been hit by a Ransomware attack; ransomware attackers have pretty "good" playbooks for getting in, encrypting the production data, and getting out fast, and from what we've seen, the focus usually goes like the below.
Complete disclosure, of course Veeam Support are _not_ security researchers, so take this with a grain of salt, but this is just what we've seen:
1. The attackers usually have already gotten privileged credentials to the entire environment before reaching the backup environment
2. The attackers seems to segregate data into two categories:
- Production Data to encrypt
- Backup data to destroy
The Production data is what ends up with the goofy extensions; I assume this is to give you incentive to pay the attackers for something, and they're pretty good it seems at figuring out where your important data is, since databases, file shares, etc, are usually pretty easy to spot once an attacker is on the system (presumably)
All other data is instead intended to be made unusable (see point 3) so your only option is paying the ransom.
3. Attackers know the file extensions and formats of the most popular backup applications, and also typically just look for "big" files (bigger than a few gig); any file that meets one or both of these conditions typically are treated in then following way:
- encrypt/destroy the first 10-20 MB of data
- encrypt/destroy random portions of the file
- delete the data entirely
- Some combination of the above three points
4. Any removable/remote storages (read: Public Clouds, S3, etc) are attempted to be accessed and messed with as well, depending on the access the attacker has. This is why it's important to heavily lock down access to secondary backup locations and use things like Veeam's Hardened repository to set immutability, or tape-out or use S3 storage. Rotated/air-gapped drives are also pretty fine, but they don't scale very well for larger environments.
Most of the success stories we have from Support with regards to ransomware attacks include either tape, S3, Cloud Connect, or rotated drives. While the data is sometimes a bit older, it's often better than nothing. While we have some potential options for recovery even if such data is damaged, it's never a guarantee and needs to be accommodated for; the more redundant copies you have, the more chances you have to recover from it, assuming the secondary copies are protected appropriately.
My personal take is that Tape has some of the best success rates we've seen; the restores do take some time because of the nature of the medium, but it's still pretty fast. I've also seen quite a few rather impressive restores of a few hundred TB from Capacity Tier; this was mostly "slow" due to download speeds, but such environments were back up and running in full after a few weeks, with the most critical servers being brought up typically within a few hours.
In my opinion, it's best to assume your on-disk backups _will be corrupted_ somehow; they're great for your non-emergency restores for usual outages/data loss you might experience in a modern workplace (server just goes down for some reason, user accidentally deletes some files, admin accidentally types a > instead of a . during an rm -rf, etc), but for proper protection, you must have a locked down and immutable off-site backup, or have proper air-gapped backups or backups on a locked down and immutable device. NAS Devices are great for cheap primary storage, but they lack the protection and security to act as "good" secondary backup locations; iscsi targets are easy to punk (even accidentally!), network shares are not easy to properly secure, and so on.
So this isn't just to dump on your idea Daniel, but more just to be aware that it's not really how the attackers usually work when it comes to backup data. For your production data, file restrictions aren't a bad idea though, and likely can help
