[openstack][cinder][backup] ransomware with cinder volume
Hello,
I would like to know if volumes which were attached to compute nodes and they will be impacted by ransomware. Could I have some sharing in this scenario? Currently, I just backup configure instance configure and create a new one with this configuration.
Thank you.
Nguyen Huu Khoi
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.
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
participants (2)
-
Jeremy Stanley
-
Nguyễn Hữu Khôi