I have been following the introduction of immutable snapshots in QuTS hero 6.0 with great interest and recently read a Japanese article testing this feature in detail (Yukihito Hara, LinkedIn Japan), which shows that immutable snapshots cannot be deleted even via SSH or with root privileges.
Based on this, I assume that immutable snapshots are intended to protect data not only from accidental deletion, but also from malicious or illegitimate actions performed via a compromised administrator account (e.g. in a ransomware scenario).
However, this raises an important conceptual question:
Is it still possible for an administrator to delete the entire storage pool that contains immutable snapshots?
If yes, wouldn’t this effectively undermine the immutability concept, since deleting the pool would remove all volumes and snapshots regardless of their protection policy?
To be clear:
I fully understand that physical destruction of hardware or removing disks cannot be prevented if someone has physical access. That is not what I am asking about.
My question is strictly about logical protection within the OS:
Immutable snapshots are protected against deletion, even by root.
But is there (or will there be) any safeguard on storage-pool level that prevents accidental or malicious pool deletion while immutable snapshots are still within their retention period?
Or stated differently:
Is the current design intentionally limited to snapshot/volume-level protection?
Or are there plans to extend immutability guarantees to prevent pool-level destructive actions as well?
I would appreciate clarification on the intended threat model and design goals here.
Thank you very much for your time and for this important new feature.
Welcome to the community. I am not running hero 6 yet but here is my take on this.
There is no “protection” for destroying or changing storage pools. WORM immutability is set at the shared folder level or in the case of hero 6 at the snapshot level as well. In a WORM setup, not every folder is set up to be immutable. You would not want it that way. You then could never delete or change anything on the NAS.
Additionally, immutability can be limited in time. So you can have a folder where files stay locked for say 5 days after they are written to. After that, the lock goes away. Other settings allow everything to stay locked permanently.
I don’t see that you would ever want immutability at the storage pool level. That would prevent you from being able to add space to the storage pool, etc.
WORM helps guard files against ransomware attacks. The files can’t be altered. Most of the time the bad guys who say get into your NAS want to infect your files so they can then extort you for money. They aren’t going to take the time to wipe your pools and destroy that. If they did, then they have wiped out all the files and they have nothing with which to hold you at ransom! So it’s counter to their mindset. Plus this stuff is desired to spread rapidly - get in to the system, spread your poison and get out. Pool wiping is going to take a lot more effort and work.
So this is my take on it and should not be construed as anything “official.”
Thank you very much for your valuable feedback! Regarding the issues you’ve raised, we will forward them to our internal team for further evaluation and analysis.
Maybe just to clear things up: I am just a bit confused regarding the internal logic of the immutable snapshot concept. As far as I can tell, if you define a small unit of the system as “must be immutable - even vis-a-vis compromised admin action - to provide maximum non-physical protection” this must replicate throughout the whole hierarchy (i.e. the storage pool level) or else the immutability is undermined. To me, this would mean that the implementation should enforce a check on the critical storage pool actions in the sense of “delete only allowed if currently no immutable files stored”.
Regarding the question of relevant attack vectors: I am with you, that most attacks would not want to delete the files due to the logic of the extortion it wants to achieve. But consider the fact that a sophisticated attacker with access could simply copy the files to his infrastructure before the delete and use the same “pay or no more files” logic to extort.
I understand what you are saying. But I would not want an immutable system where I could never re-do my storage pool. I mean, that means that once you set things up, it’s baked and there’s no way it could ever change. That means you couldn’t expand the pool, delete the pool because you want to move the data to a new larger pool, etc. There’s a lot of headaches with what you propose. It’s bad enough with immutable files. I accidentally copied some files into an immutable folder when I wanted to put them into a sub-folder. Well, now I have two copies of the files, one set of which is sitting in a place where I didn’t want them. What if you accidentally did that with a pool?
I highly doubt any bad actor is going to want to take the time to copy a large set of files to their infrastructure given the time it would take to transfer. And even if they did, it’s kind of useless especially if the NAS has an appropriate backup strategy.