Hello.

I get it. We have tools to detect malware but currently I cannot find an effective solution for volumes. Ceph has RBD export but we are using SAN and Cinder backup is not good in case of having too much and large volume size.

Nguyen Huu Khoi


On Sat, Apr 6, 2024 at 10:13 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2024-04-06 21:28:51 +0700 (+0700), Nguyễn Hữu Khôi wrote:
> I would like to know if volumes which were attached to compute
> nodes and they will be impacted by ransomware.

It really depends on the details of how that "ransomware" works.
You're better off approaching this from a lower-level view of what
specific actions you're trying to protect against. Malicious
software you accidentally run (or get tricked into running) on the
server? A compromise of login credentials? An attacker getting
access to your cloud API account/token? An administrative compromise
of the underlying cloud infrastructure? The measures one might take
to defend against these different scenarios vary and come at
increasing cost (either in terms of resources or convenience).

> Could I have some sharing in this scenario? Currently, I just
> backup configure instance configure and create a new one with this
> configuration.

If you have a backup (server and/or volume, but sometimes they might
be the same thing for example using boot-from-volume) in the cloud
from before your server was compromised, then yes you can just
restore that by booting a new server from that image and/or creating
a new volume from that snapshot. Of course, it should go without
saying that if you don't know how the attacker got access then it's
entirely likely it will just happen again to your restored
replacement too, so thorough forensic review by a security
professional is a good idea.

And that's just addressing the case of a compromised server
instance. If the attacker has compromised your cloud account or the
underlying cloud services, then you'd better have remote backups,
since they could just delete your server images/volume snapshots
there.
--
Jeremy Stanley