Help ... proxmox 6.4 hacked

[guidrex]

Hallo ... wie der Titel schon sagt, wurde mein Knoten angegriffen und ich habe keinen Zugriff mehr auf die proxmox-GUI.
Ich habe immer noch die Möglichkeit, mich in ssh sowohl mit dem Knoten als auch mit jedem einzelnen Container oder jeder einzelnen VM zu verbinden, und bin gerade dabei, die neue Version von proxmox 7 auf einem neuen System zu installieren.
Ist es möglich, die Container und die aktiven VMs auf dem beschädigten System zu klonen? kannst du mir irgendwie helfen

Hi ... as the title suggests I suffered an attack on my node and I no longer have access to the proxmox GUI.
I still have the possibility to connect in ssh both to the node and to every single container or vm and in this moment I am about to install the new version of proxmox 7 on a new system.
is it possible to be able to clone the containers and the active VMs on the corrupt system? can you help me in any way?

 

[Iso]

Keine Backups gemacht?
So ohne Infos zu deinem Proxmox würde ich sagen..

Unter `/etc/pve/storage.cfg` siehst deinen Storage und in welchem Verzeichnis die verfügbar sind.

Via CLI startest du ein Backup pro VM, kopierst das Archiv auf den neuen PVE und stellst die VM wieder her.
https://pve.proxmox.com/wiki/Command_line_tools#vzdump

 

[guidrex]

I think the thing is more serious than expected because all the vz / images were definitely deleted during the attack ... and the system works only because the VMs and active containers are on an active PID.
is it possible to create a backup of a vms and a container that no longer have the image on / var / lib / vz / images / {<vim>}?

Ich denke, die Sache ist ernster als erwartet, weil alle vz/images während des Angriffs definitiv gelöscht wurden ... und das System nur funktioniert, weil die VMs und aktiven Container auf einer aktiven PID sind.
Ist es möglich, ein Backup eines vms und eines Containers zu erstellen, die das Image nicht mehr auf /var/lib/vz/images/{<vim>} haben?

 

[Iso]

I think the thing is more serious than expected because all the vz / images were definitely deleted during the attack ... and the system works only because the VMs and active containers are on an active PID.
is it possible to create a backup of a vms and a container that no longer have the image on / var / lib / vz / images / {<vim>}?

Ich denke, die Sache ist ernster als erwartet, weil alle vz/images während des Angriffs definitiv gelöscht wurden ... und das System nur funktioniert, weil die VMs und aktiven Container auf einer aktiven PID sind.
Ist es möglich, ein Backup eines vms und eines Containers zu erstellen, die das Image nicht mehr auf /var/lib/vz/images/{<vim>} haben?

Nein.

 

[fiona]

Hi,
falls die Datei im Prozess noch offen ist, kann sie oft gerettet werden. Beispiel mit VM 103:

root@pve701 ~ # lsof -p $(cat /var/run/qemu-server/103.pid) | grep deleted
kvm     25647 root   14u      REG              253,3 4295884800 526714 /var/lib/vz/images/103/vm-103-disk-0.qcow2 (deleted)
root@pve701 ~ # cp /proc/25647/fd/14 /anderer/Ort/Kopie-von-vm-103-disk-0.qcow2

Dann kann die Disk z.B. an eine neue VM angehängt werden, um zu kontrollieren, ob alles in Ordnung ist.

Für Container kannst Du versuchen über /proc/<PID>/root auf das Dateisystem zuzugreifen. Die PID kann z.B. für Container 131 mit pct status 131 --verbose gefunden werden.

Wichtig ist, dass der Prozess nicht vorher beendet wird! Und es besteht natürlich das Risiko, dass der Knoten auch grundlegender kompromittiert ist, und man den VMs/CTs/Disken nicht mehr trauen sollte! EDIT: Und falls es sich um ein Cluster handelt, bezieht sich die Warnung auf das gesamte Cluster.

 

[Neobin]

Und es besteht natürlich das Risiko, dass der Knoten auch grundlegender kompromittiert ist, und man den VMs/CTs/Disken nicht mehr trauen sollte!

Genau das! Ich würde an dem System gar nichts mehr trauen und alles aus den Backups vor dem Angriff wiederherstellen.
Wenn keine brauchbaren Backups vorhanden sein sollten, können die Daten auch nicht so wichtig gewesen sein.