Warum die Standard-Installation UNSICHER ist:

H

hackmann

Renowned Member
Proxmox Subscriber
Jan 6, 2013
261
16
83
Ich hatte gestern einen Bericht gelesen!

Warum die Standard-Installation UNSICHER ist:
  1. Sture ID-Logik ohne Validierung: Das Standard-Backup (vzdump) vertraut blind dem Dateinamen auf dem NAS. Ändert jemand außen die ID im Namen, überschreibt Proxmox beim Restore stur produktive Daten, weil es im Standard-Modus keine automatische GUID-Prüfung gegen ein zentrales Register durchführt.
  2. Der blinde Fleck bei Containern (LXC): VMs haben wenigstens noch eine interne Hardware-UUID im smbios. Container (LXC) haben das nicht. Ändert man bei einem Container-Backup den Dateinamen von ID 101 auf ID 202, merkt Proxmox beim Einspielen überhaupt nichts und überschreibt das Ziel-System.
  3. Mangelnde Mandantenfähigkeit im Standard: Wenn 30 eigenständige Hosts auf dasselbe NFS/SMB-Share sichern, sieht jeder Host die Backups aller anderen Hosts, sofern sie im selben Verzeichnis liegen. Ein einziger kompromittierter Host kann das Backup-Verzeichnis aller anderen Nodes manipulieren oder einsehen
ist das wirlick so liebe grüsse
 
Klingt dramatischer als es ist. Punkt 1 und 2 sind der gleiche Punkt, das stimmt nicht. Die VMID im Dateinamen ist beim Restore nur ein Vorschlag, die Ziel-ID legst du selbst fest (GUI oder qmrestore <archiv> <vmid> bzw. pct restore <vmid> <archiv>). Einen bestehenden Gast überschreibt der Restore nur, wenn du das in der GUI bestätigst bzw. auf der CLI --force mitgibst. Die smbios-UUID wird beim VM-Restore auch nicht gegen irgendwas geprüft. Zwischen VM und LXC gibts da keinen Unterschied.

Wichtiger ist was anderes: Wer Schreibzugriff aufs Backup-Storage hat, muss nicht erst Dateinamen umbenennen. Der kann gleich den Inhalt manipulieren oder alles löschen. Das liegt aber nicht an Proxmox, sondern daran, wie man das Backup-Ziel absichert.

Punkt 3 stimmt. Wenn 30 Hosts auf dasselbe Share schreiben dürfen, sieht jeder die Backups der anderen. Ein simples NFS/SMB-Share ist halt nicht mandantenfähig. Dafür gibts PBS: Namespaces oder eigene Datastores pro Host, eigene User/Tokens mit ACLs, clientseitige Verschlüsselung (dann fällt eine Manipulation beim Verify/Restore auf) und für die Offsite-Kopie ein Pull-Sync, damit ein kompromittierter Host die Kopie nicht anfassen kann. Wenns beim NAS bleiben soll, dann zumindest ein eigenes Export/Share pro Host.

Hast du nen Link zu dem Bericht?
 
  • Like
Reactions: ThoSo, UdoB, Johannes S and 2 others
hackmann said:
Mangelnde Mandantenfähigkeit im Standard: Wenn 30 eigenständige Hosts auf dasselbe NFS/SMB-Share sichern, sieht jeder Host die Backups aller anderen Hosts, sofern sie im selben Verzeichnis liegen. Ein einziger kompromittierter Host kann das Backup-Verzeichnis aller anderen Nodes manipulieren oder einsehen
Click to expand...
Naja das lässt sich ja beheben, in dem man halt nicht einen einzigen NFS/SMB Share für alle Hosts benutzt. ;-)
 
Last edited:
  • Like
Reactions: ThoSo and Johannes S
Bu66as said:
Klingt dramatischer als es ist. Punkt 1 und 2 sind der gleiche Punkt, das stimmt nicht. Die VMID im Dateinamen ist beim Restore nur ein Vorschlag, die Ziel-ID legst du selbst fest (GUI oder qmrestore <archiv> <vmid> bzw. pct restore <vmid> <archiv>). Einen bestehenden Gast überschreibt der Restore nur, wenn du das in der GUI bestätigst bzw. auf der CLI --force mitgibst. Die smbios-UUID wird beim VM-Restore auch nicht gegen irgendwas geprüft. Zwischen VM und LXC gibts da keinen Unterschied.

Wichtiger ist was anderes: Wer Schreibzugriff aufs Backup-Storage hat, muss nicht erst Dateinamen umbenennen. Der kann gleich den Inhalt manipulieren oder alles löschen. Das liegt aber nicht an Proxmox, sondern daran, wie man das Backup-Ziel absichert.

Punkt 3 stimmt. Wenn 30 Hosts auf dasselbe Share schreiben dürfen, sieht jeder die Backups der anderen. Ein simples NFS/SMB-Share ist halt nicht mandantenfähig. Dafür gibts PBS: Namespaces oder eigene Datastores pro Host, eigene User/Tokens mit ACLs, clientseitige Verschlüsselung (dann fällt eine Manipulation beim Verify/Restore auf) und für die Offsite-Kopie ein Pull-Sync, damit ein kompromittierter Host die Kopie nicht anfassen kann. Wenns beim NAS bleiben soll, dann zumindest ein eigenes Export/Share pro Host.

Hast du nen Link zu dem Bericht?
Click to expand...
nein, aber ich musste feststellen, dass da ganze nach hinten los gehen kann! wenn man sich das ganze etwas von oben betrachtet! Da VZDUMP sit eine NAJA, es geht so Sache! dann noch der PBS Server dazu,also! Ich hatte schon das Vergnügen einen Restore zu machen, das war eine herausforderung! wenn du mal eine posix umgeung hast, dann wird es richtig nett! Alles im allem nett gemacht. Aber ich habe das ganze andere Ansrüche wie offene Port, PRECHECK vor dem BACKUP, stimmt die Zugehörikeit= ABFRAGE KETTE !=== =??? das ist alles offen! und viels mehr! ich denke nicht nach bei 30 Servern! ich denke ab 40000 Servern! das ist der Unterschied!
 
You must log in or register to reply here.
Top Bottom
Back