Hi all, I'm a little warried about that, due to the last big ransomware attack based on "MarioLocker", it was done a month ago and it was very dangerous in my region (south America) the target was VMWARE ESXI, searching and encrypting the whole VMs volumes.
Might Proxmox be affected by "MarioLocker" ransomware?
- Thread starter Guillermo Prado
- Start date
I assume PVE is not immune to attacks like that, but I doubt a ransomware specific to ESXi would work on Proxmox.
PBS might help detect and recover from them: https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery
EDIT: I did not know that ESXi is also based on Linux and that does change my answer: maybe it is also at risk.
PBS might help detect and recover from them: https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery
EDIT: I did not know that ESXi is also based on Linux and that does change my answer: maybe it is also at risk.
Last edited:
I would not count on that. ESXi is just Linux, even if they won their lawsuit against a linux kernel developer. You can compile programs on linux and copy them to your ESXi host and they will run. I do not know any other hypervisor which can run Linux binaries while not beeing Linux under the hood (excluding *BSD with its linuxulator).
These types of attacks are often a combination of things. At a very high level glance at the mentioned attack - it takes advantage of heap overflow in OpenSLP service that is running on port 427, then, after gaining execution ability, it uses another piece of code to encrypt matching files (ie vmdk).
This particular combination will not be possible against a vanilla PVE. There is no OpenSLP by default, nor are there any "vmdk" files...
Obviously this is "security through obscurity". Nothing stops an "enterprising" actor from adapting the code to attack PVE installation. And its trivial to change the list of targets to encrypt, ie add qcow.
But there is nothing special about PVE in that sense. If there is a vulnerability in standard Debian package that can be exploited remotely - any appliance based on Debian is exposed.
There are simple precautions that one may take to avoid the attack:
a) Dont expose PVE, or anything else really, to Internet unless you have an actual need and know what you are doing.
b) Block any non-essential ports via firewall
c) Restrict essential ports by firewall to a know "good" set
d) Use strong password and ssh keys
e) Keep your system up-to-date
If you must allow untrusted users in your environment, ie Cloud Service Provider, implement Multi-Tenancy at every possible level: Compute, Network and Storage.
Of course there are many more steps, but the above is a good start.
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
This particular combination will not be possible against a vanilla PVE. There is no OpenSLP by default, nor are there any "vmdk" files...
Obviously this is "security through obscurity". Nothing stops an "enterprising" actor from adapting the code to attack PVE installation. And its trivial to change the list of targets to encrypt, ie add qcow.
But there is nothing special about PVE in that sense. If there is a vulnerability in standard Debian package that can be exploited remotely - any appliance based on Debian is exposed.
There are simple precautions that one may take to avoid the attack:
a) Dont expose PVE, or anything else really, to Internet unless you have an actual need and know what you are doing.
b) Block any non-essential ports via firewall
c) Restrict essential ports by firewall to a know "good" set
d) Use strong password and ssh keys
e) Keep your system up-to-date
If you must allow untrusted users in your environment, ie Cloud Service Provider, implement Multi-Tenancy at every possible level: Compute, Network and Storage.
Of course there are many more steps, but the above is a good start.
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Last edited: