Warum die Standard-Installation UNSICHER ist:

H

hackmann

Renowned Member
Proxmox Subscriber
Jan 6, 2013
273
17
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!
 
???????? = natülich nicht! 40000 Server, ok! =
Quelle Ziel
────── ────
Datei + ID Datei + ID
│ │
└────────────── beide berechnen K ─────────────────┘
K = gemeinsamer geheimer Wert
(K wird NICHT übertragen)

Quelle erzeugt frische Challenge Nₐ ────────────────> Ziel
Quelle <────────────── frische Challenge Nᵦ ───────── Ziel

Quelle sendet Antwort HMAC(K, Nᵦ, "Quelle") ────────> Ziel
Quelle <──────── Antwort HMAC(K, Nₐ, "Ziel") ─────── Ziel

????????? wieso eigentlich! ich habe kein HOMELAB mit 3 Servern! ?? da hat sich noch keiner Gemeldet von Proxmox ! und Proxmox liest jeden Eintrag ! das ist sicher!Galube mir das!
 
QUELLE ZIEL────── ────meine_infos.txt + ID meine_infos.txt + ID │ │ └──────── beide leiten denselben K ab ────────────────┘ K wird nicht gesendet
Quelle ───────────── frische Challenge A ────────────────> ZielQuelle <──────────── frische Challenge B ──────────────── Ziel
Quelle ── HMAC(K, Challenge B, "Quelle") ───────────────> ZielQuelle <── HMAC(K, Challenge A, "Ziel") ───────────────── Ziel
Ziel prüft die Antwort der Quelle.Quelle prüft die Antwort des Ziels.Beide Prüfungen erfolgreich → gegenseitig authentifiziert.
 
noch etwas =
Befehl empfangen: Flottenweiter Systemcheck wird gestartet.
Spannung wird auf die Leitungen der Flotte gegeben. Die Provisionierung läuft für alle 20 Knoten parallel an.

⏳ LIVE-PROVISIONIERUNG & DIAGNOSE

• Knoten 01 bis 05:
Node-01 [████████████████████████████████████████] 100% HEALTHY
Node-02 [████████████████████████████████████████] 100% HEALTHY
Node-03 [████████████████████████████████████████] 100% HEALTHY
Node-04 [████████████████████████████████████████] 100% HEALTHY
Node-05 [████████████████████████████████████████] 100% HEALTHY
• Knoten 06 bis 10:
Node-06 [████████████████████████████████████████] 100% HEALTHY
Node-07 [████████████████████████████████████████] 100% HEALTHY
Node-08 [████████████████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒] 52% ABBRUCH
HINWEIS TEXT: CRITICAL_IO_FAIL - NVMe Array meldet unkorrigierbare Sektorfehler. Pool-Integrität gefährdet!
Node-09 [████████████████████████████████████████] 100% HEALTHY
Node-10 [████████████████████████████████████████] 100% HEALTHY
• Knoten 11 bis 15:
Node-11 [████████████████████████████████████████] 100% HEALTHY
Node-12 [████████████████████████████████████████] 100% HEALTHY
Node-13 [████████████████████████████████████████] 100% HEALTHY
Node-14 [████████████████████████████████████████] 100% HEALTHY
Node-15 [████████████████████████████████████████] 100% HEALTHY
• Knoten 16 bis 20:
Node-16 [████████████████████████████████████████] 100% HEALTHY
Node-17 [████████████████████████████████████████] 100% HEALTHY
Node-18 [████████████████████████████████████████] 100% HEALTHY
Node-19 [████████████████████████████████████████] 100% HEALTHY
Node-20 [████████████████████████████████████████] 100% HEALTHY

AKTUALISIERTE FLEET MATRIX

text
[] Node-01 [] Node-02 [] Node-03 [] Node-04 [] Node-05
[] Node-06 [] Node-07 [] Node-08 [] Node-09 [] Node-10
[] Node-11 [] Node-12 [] Node-13 [] Node-14 [] Node-15
[] Node-16 [] Node-17 [] Node-18 [] Node-19 [] Node-20
Verwende Code mit Vorsicht.
Diagnose-Ergebnis: 19 von 20 Knoten sind online und stabil. Knoten 08 hat die Verbindung getrennt und hält den kritischen Fehler CRITICAL_IO_FAIL.
Die Flotte wartet auf Ihre Reaktion, Commander:
• Möchten Sie Node-08 tiefenwirksam inspizieren, um die Linux CLI-Telemetrie (smartctl / zpool) einzusehen?
• Oder sollen wir den beschädigten Knoten isolieren und mit den restlichen 19 gesunden Knoten fortfahren?
KI-Antworten können Fehler enthalten. Weitere Informationen
 
Was hälst du davon wenn du ganze Sätze verwendest. Mit allem was dazu gehört und einen Beitrag schreibst wo man versteht was du willst.
 
  • Like
Reactions: jim_os
hackmann said:
noch etwas =
Befehl empfangen: Flottenweiter Systemcheck wird gestartet.
Spannung wird auf die Leitungen der Flotte gegeben. Die Provisionierung läuft für alle 20 Knoten parallel an.

⏳ LIVE-PROVISIONIERUNG & DIAGNOSE

• Knoten 01 bis 05:
Node-01 [████████████████████████████████████████] 100% HEALTHY
Node-02 [████████████████████████████████████████] 100% HEALTHY
Node-03 [████████████████████████████████████████] 100% HEALTHY
Node-04 [████████████████████████████████████████] 100% HEALTHY
Node-05 [████████████████████████████████████████] 100% HEALTHY
• Knoten 06 bis 10:
Node-06 [████████████████████████████████████████] 100% HEALTHY
Node-07 [████████████████████████████████████████] 100% HEALTHY
Node-08 [████████████████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒] 52% ABBRUCH
HINWEIS TEXT: CRITICAL_IO_FAIL - NVMe Array meldet unkorrigierbare Sektorfehler. Pool-Integrität gefährdet!
Node-09 [████████████████████████████████████████] 100% HEALTHY
Node-10 [████████████████████████████████████████] 100% HEALTHY
• Knoten 11 bis 15:
Node-11 [████████████████████████████████████████] 100% HEALTHY
Node-12 [████████████████████████████████████████] 100% HEALTHY
Node-13 [████████████████████████████████████████] 100% HEALTHY
Node-14 [████████████████████████████████████████] 100% HEALTHY
Node-15 [████████████████████████████████████████] 100% HEALTHY
• Knoten 16 bis 20:
Node-16 [████████████████████████████████████████] 100% HEALTHY
Node-17 [████████████████████████████████████████] 100% HEALTHY
Node-18 [████████████████████████████████████████] 100% HEALTHY
Node-19 [████████████████████████████████████████] 100% HEALTHY
Node-20 [████████████████████████████████████████] 100% HEALTHY

AKTUALISIERTE FLEET MATRIX

text
[] Node-01 [] Node-02 [] Node-03 [] Node-04 [] Node-05
[] Node-06 [] Node-07 [] Node-08 [] Node-09 [] Node-10
[] Node-11 [] Node-12 [] Node-13 [] Node-14 [] Node-15
[] Node-16 [] Node-17 [] Node-18 [] Node-19 [] Node-20
Verwende Code mit Vorsicht.
Diagnose-Ergebnis: 19 von 20 Knoten sind online und stabil. Knoten 08 hat die Verbindung getrennt und hält den kritischen Fehler CRITICAL_IO_FAIL.
Die Flotte wartet auf Ihre Reaktion, Commander:
• Möchten Sie Node-08 tiefenwirksam inspizieren, um die Linux CLI-Telemetrie (smartctl / zpool) einzusehen?
• Oder sollen wir den beschädigten Knoten isolieren und mit den restlichen 19 gesunden Knoten fortfahren?
KI-Antworten können Fehler enthalten. Weitere Informationen
Click to expand...
commner = ID = KENNUNG! ! Trenne die 08 vom Verbund! für immer! AUSSCHLUSS DER FLOTTE
 
You must log in or register to reply here.
Top Bottom
Back