Sicherheit Archives - ElasticSky

19. August 202315. März 2024

ESXi Config-Backup mit PowerCLI benötigt HTTP

Es gibt einen wirklich nützlichen und komfortablen PowerCLI One-Liner zur Sicherung der Hostkonfiguration. Ich verwende ihn seit Jahren und hatte diesen auch in einem alten Blogpost im Detail erklärt.

Get-Cluster -Name myCluster | Get-VMHost | Get-VMHostFirmware -BackupConfiguration -DestinationPath 'C:\myPath'

Im Rahmen meiner VMware Kurse ist dies ein Befehl, den ich meinen Studenten immer mit auf den Weg gebe. Die Sicherung der Host-Konfiguration ist geradezu Pflicht vor Änderungen am Host, Installation von Patches und Treibern, oder Host-Updates. Nur ein paar Sekunden mehr Aufwand, aber diese Konfigurations-Backups haben mir schon mehr als einmal größeren Ärger und viele Stunden Arbeit erspart.

Kürzlich war ich in einem größeren Datacenter mit der Sicherung der Host-Konfigurationen beschäftigt. Überraschenderweise funktionierte der Befehl auf einigen der vCenter-Instanzen nicht und brach mit einer Fehlermeldung ab.

Get-VMHostFirmware : 18.08.2023 12:05:49 Get-VMHostFirmware An error occurred while sending the request.
At line:1 char:28
+… et-VMHost | Get-VMHostFirmware -BackupConfiguration -DestinationPath …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-VMHostFirmware], ViError
+ FullyQualifiedErrorId : Client20_SystemManagementServiceImpl_BackupVmHostFirmware_DownloadError,VMware.VimAutomation.ViCore.Cmdlets.Commands.Host.GetVMHostFirmware

Um den Fehler zu verstehen muss man zunächst verstehen, wie das PowerCLI Kommando arbeitet. Zunächst wird über vCenter auf dem Host ein Backup der Host-Konfiguration getriggert. Diese legt der Host lokal als gezipptes TAR Archiv (.tgz) ab. Der Name lautet configBundle-HostFQDN.tgz (Beispiel: configBundle-esx01.lab.local.tgz). Das Archiv wird dann in einem zweiten Schritt vom Host geladen. Die URL hierfür lautet:

http://[HostFQDN]/downloads/[Host-UUID]/configBundle-HostFQDN.tgz

Liest man die obige Fehlermeldung, gab es ganz offensichtlich ein Problem beim Download des TGZ-Files. Mit Hilfe der Netzwerk Admins wurde schnell klar, was hier passierte. Meine Arbeitsstation, von der ich den PowerCLI Befehl absendete, versuchte erfolglos eine HTTP Verbindung zum ESXi-Host aufzubauen. Dies wurde jedoch durch eine Firewall Regel geblockt.

Ich fragte mich, warum der Transfer über unverschlüsseltes HTTP abgewickelt wird. Im Log der Firewall sieht man einen Verbindungsversuch zum ESXi-Host mit HTTP und HTTPS.

Gibt es eine Möglichkeit, den Transfer über HTTPS zu erzwingen?

Der erste Gedanke war, dass es vielleicht einen Parameter zum Kommando gibt, der das HTTPS Protokoll erzwingt. Eine Anfrage im VMTN-Forum brachte leider Ernüchterung.

Es ist etwas erstaunlich, dass VMware für diese durchaus sensitiven Daten ein unverschlüsseltes Protokoll verwendet. Umso mehr da die PowerCLI Session zum vCenter ohnehin schon über HTTPS läuft. Die plausibelste Erklärung wäre, dass schlicht ‘vergessen’ wurde bei diesem doch recht alten Befehl, den Transfer über SSL abzusichern.

Es bleibt derzeit also keine andere Wahl, als eine Firewall-Regel zu erzeugen, die den Download über HTTP erlaubt.

1. April 20211. April 2021

Tanzu K8s mit Runecast überwachen

Die Konformität eines Clusters in Bezug auf Sicherheit oder versteckte Probleme zu überprüfen gehört inzwischen zum Standard. Hierfür gibt es automatisierte Hilfsmittel wie zum Beispiel VMware Skyline oder Runecast Analyzer. Letzterer kann neben klassischen vSphere Clustern auch vSAN, NSX-T, AWS, Kubernetes und seit Version 5.0 auch Azure auf Konfomität prüfen.

Ich möchte in diesem Beitrag die Anbindung einer vSphere with Tanzu [*] Umgebung an Runcast Analyzer beschreiben. [* native Kubernetes Pods und TKG auf vSphere]

Einige Schritte sind vereinfacht, da es sich um eine Lab Infrastruktur handelt. Ich werde zu gegebenem Zeitpunkt darauf hinweisen.

Bevor wir Tanzu in Runecast registrieren können, benötigen wir ein paar Informationen.

IP Adresse oder FQDN der SupervisorControlPlane
Dienstkonto mit Zugriff auf die SupervisorControlPlane
Token des Dienstkontos

15. Februar 202127. Februar 2021

Veeam Immutable Backups auf vorhandenen Linux XFS Repositories aktivieren

Veeam backup & Replication v11 steht kurz vor der Veröffentlichung. Diese ist für Mittwoch den 24.2.2021 geplant. Partner und Service Provider hatten einige Tage Vorsprung und Zugriff auf den sogenannten RTM Build (ready to manufactoring).

Eine der (wie ich meine) spannensten neuen Funktionen in Version 11 ist die Einführung der sogenannten Immutable Backups. Ich hatte bereits in meinem Beitrag “Strategien zum Schutz von Veeam Backups durch unveränderliche Repository Server mit Linux XFS” berichtet.

Einige von Euch setzen möglicherweise schon Linux Repository Server mit dem XFS Dateisystem und Fastclone produktiv ein und möchten diese nun im die Funktion Immutable-Backups erweitern. Ich werde in diesem Beitrag erklären, wie sich dies mit wenigen Schritten bewerkstelligen lässt.

Schutz aktivieren

Um die Funktion zum Schutz der Backupdaten auf bestehenden XFS Repositories zu aktivieren, müssen wir diese im Veeam Backup Client v11 bearbeiten (Bild unten). Ab Version 11 ist im Abschnitt Repository eine neue Checkbox zu sehen (“make recent backups immutable for [x] days”). Dabei ist 7 Tage der kleinstmögliche Zeitraum für den Schutz. Sobald man die Checkbox aktiviert wird sehr wahrscheinlich eine Benachrichtigung wie unten dargestellt erscheinen. “Unable to set the immutability option: cannot find the transport service on server <your repo server>. Configure the server anyway?“. Wir bestätigen diese mit [Yes].

Wir müssen zur Aktivierung des Immutable Flags den Veeam Transport Service auf dem Ziel neu konfigurieren.

22. Januar 202128. Januar 2021

Strategien zum Schutz von Veeam Backups durch unveränderliche Repository Server mit Linux XFS

Angriffe auf IT-Infrastrukturen sind in letzter Zeit immer raffinierter geworden. Sie verschlüsseln nicht nur Live-Daten und ganze virtuelle Maschinen, sie haben auch gelernt, ganze Backups zu löschen, oder zu verschlüsseln. Dabei spielt es keine Rolle, ob Ihre Online-Backups in einem lokalen Repository, oder auf einem Cloud-Share gespeichert sind. Wenn dieser Fall eintritt und Sie kein Offline Backup wie beispielsweise Tape, oder einen sonstigen Plan B in der Hinterhand haben, werden Sie alt aussehen. Schlimmer noch: Wenn Sie in Ihrem Unternehmen für die Datensicherung verantwortlich sind, müssen Sie sich unangenehmen Fragen seitens der Geschäftsführung stellen.

Nun stellt sich die Frage, wie Sie die Backup-Daten schützen, falls ein Angreifer Zugriff auf Ihren Backup-Server erhält. Sobald er die Zugangsdaten zum Server hat, kann er alles tun, was der Backup-Administrator tun kann. Das Löschen von Backups zum Beispiel. Ein erster Schritt besteht darin, Ihre Backup-Systeme von Ihrer Domain zu trennen. Für den Fall, dass der Domain-Administrator-Account kompromittiert wird, gibt es immer noch eine (kleine) Barriere zwischen Angreifern und Ihren Backup-Systemen. Aber trotzdem werden Sie nie wissen, ob Angreifer Kenntnis von einem Zero-Day-Exploit haben, um Ihren Backup-Server zu übernehmen. Ein besserer Ansatz wäre es, Backups für eine definierte Zeitspanne gegen das Löschen zu schützen. Eine ähnliche Option gibt es bei AWS S3-Buckets, die üblicherweise als Offsite-Sicherungskopien verwendet werden. Das Zurückholen von Offsite-Backups nimmt eine beträchtliche Zeitspanne in Anspruch. Im Falle eines Kryptoangriffs ist die Zeit entscheidend und die Uhr tickt. Wäre es nicht großartig, unveränderliche Backups auf Ihren primären Repositories vor Ort zu haben? Gute Nachrichten. Es gibt Licht am Ende des Tunnels (und ich verspreche, es ist nicht der entgegenkommende Zug).

Unveränderliche (Immutable) Backups

Bevor wir ins Detail gehen, müssen wir klären, was unveränderliche Backups bedeuten. Die Idee ist, dass man einmal schreibt und dann die Dateien (Backups) für eine selbst definierte Zeitspanne geschützt sind. Selbst der Backup-Administrator kann sie nicht löschen, bevor die definierte Zeitspanne verstrichen ist.

Veeam Backup & Replication v11 wird eine native Funktion des Linux XFS-Dateisystems nutzen. XFS kann ein erweitertes Dateiattribut [i] setzen, das die Datei vor Umbenennung, Änderung, Löschung oder Hard-Linking schützt. Der Clou dabei ist, dass Backups mit einem nicht privilegierten Konto übertragen und geschrieben werden und das Immutable-Attribut von einem Dienst auf dem Repository-Server gesetzt und entfernt wird, der erhöhte Rechte hat und auf den von außen nicht zugegriffen werden kann.

Alles, was Sie benötigen, ist ein mit XFS formatiertes Linux-Repository und Veeam Backup & Replication v11, das demnächst erscheinen wird. (Update: Geplantes Erscheinungsdatum ist der 24.02.2021)