DELL/EMC hat mit seinem neuen Datensicherungsprodukt „PowerProtect Data Manager“ (PPDM) ein unschlagbares Sicherungsprogramm für VMware Image Sicherungen im Portfolio. Dieses auf Transparent Snapshots basierende Sicherungsverfahren benötigt keine virtuellen Maschinen als Backup-Proxies mehr, sondern lagert die Sicherungsarbeit auf die physikalischen ESXi Maschinen aus. Die Sicherungen der virtuellen Maschinen werden so schneller, benötigen weniger System-Ressourcen und die sonst nötige Pflege der Proxy-Server entfällt auch noch.

Leider fehlt dem Produkt PPDM jedoch die Möglichkeit die PPDM-Sicherungen auf Bänder zu duplizieren. Genau diese Tape-Auslagerung wird aber durch die immer häufiger vorkommenden Ransomeware Attacken und/oder gesetzlichen Vorgaben von einigen Kunden gewünscht.

Im vorliegenden Projekt hat der Kunde parallel zur neuen PPDM Umgebung eine bestehende NetWorker-Backup-Umgebung mit StorageNodes und einer Tape-Library. Der Wunsch war die PPDM-Sicherungen einmal pro Monat mit Hilfe von NetWorker auf Band zu sichern und diese Sicherungen dort für 1 Jahr aufzuheben. Hierbei sollten für alle mit PPDM gesicherten virtuellen Maschinen, die erste Sicherung des jeweiligen Monats auf Band dupliziert werden.

Sowohl NetWorker, als auch PPDM sichern bei dem Kunden auf das DELL/EMC Backup-Storage-System DataDomain. Was lag also näher, als die von PPDM erzeugten DataDomain Sicherungen mit Hilfe von NetWorker-StorageNodes von dem DataDomain System zu lesen und auf Tape zu sichern.

Bei der PPDM Sicherung werden die Sicherungen der virtuellen Maschinen auf dem DataDomain-Filesystem als jeweils eigenes Verzeichnis mit allen VMware spezifischen Dateien abgelegt. Sichert man ein solches Verzeichnis, hat man demzufolge einen kompletten Stand der virtuellen Maschine, der im Recover-Fall vom Band in einen VMware-Datastore eingespielt werden kann.

Die Idee war geboren; was fehlte, war „lediglich“ noch die Umsetzung einiger Voraussetzungen und die Erstellung von Python Modulen und Skripten.

Basierend auf den REST-API Schnittstellen des PPDM-Servers und des NetWorker-Servers wurden 3 Programme erstellt, die die PPDM Sicherungen analysieren, die PPDM Sicherung auf Band befördern und eine NetWorker-Band-Sicherung für Recovery Zwecke auf einer DataDomain wiederherstellen.

• ppdm_find_backup.py

  • Python-Skript, das:

    • für alle VMware Sicherungen des PPDM-Servers in einem definierten MTREE, die zugehörigen Sicherungen eines definierbaren Tages sammelt und die gewonnenen Informationen für die zukünftigen Sicherungen in einer Python-Pickle Datei ablegt.

    • alle gefundenen virtuellen Maschinen als SaveSet Namen in definierten NetWorker Clients hinterlegt. Die Clients sind in dem Falle die NetWorker StorageNodes.

Dieses Skript läuft einmal monatlich vor den NetWorker Sicherungen und wird mit Hilfe eines definierten Cron-Jobs auf dem NetWorker-Server gestartet.

• nsr_ppdm2tape.py <vm-name>

  • Python-Skript, das als NetWorker Backup-Command für die Sicherung einer übergebenen virtuellen Maschine sorgt. Das Vorgehen ist wie folgt:

    • Eventuelles mounten des DataDomain Filesystems.

    • Auslesen der backup Information aus der oben definierten Pickle-Datei.

    • Starten einer NetWorker Band-Sicherung einer virtuellen Maschine.

    • Eventuelles unmounten des DataDomain Mtrees.

• ppdm_recover.py <vm-name>

  • Python-Skript, das eine NetWorker Sicherung auf einen definierten DataDomain Mtree wiederherstellt. Der gesicherte Stand der Maschine wird in einem eigenen Unterverzeichnis im Recover-Mtree abgelegt. Folgende Schritte werden hierbei durchgeführt:

    • Interaktive Auswahl des gewünschten Sicherungsstandes

    • Mount des DataDomain Recover-Mtrees

    • Wiederherstellung der virtuellen Maschine mit Hilfe des NetWorker „recover“ Kommandos.

    • Unmount des DD-Mtrees

Das hier beschriebene Konzept ist natürlich nur eine grobe Beschreibung der Funktionalität. Es fehlen die Konfigurationsschritte und Voraussetzungen auf der DataDomain und im NetWorker. Außerdem fehlt die Installationsbeschreibung der Python-Skripte auf den beteiligten Maschinen. Natürlich fehlt auch das weitere Vorgehen beim Verlauf eines Recover von Tape in eine laufende virtuelle Maschine. Aber all das würde über das Ziel dieses Blogs hinausgehen. Ich wollte Ihnen nur eine Idee für das in der Einleitung beschriebene Problem aufzeigen. Sollten Sie an diesem Projekt näher interessiert sein, so melden Sie sich bitte per E-Mail an den Autor.

Erste erfolgreiche Migration eines Windows basierten NetWorker-Servers auf ein Linux System mit Hilfe der in NetWorker V19.9 neu eingeführten Migrations-Kommandos.

Durch das verstärkte Auftreten von Male-Ware Angriffen wird der Wunsch und auch der Druck immer größer, bestehende Windows-NetWorker-Server auf ein Linux-System zu migrieren.

Wer schon einmal einen verschlüsselten NetWorker-Server wieder ans rennen bringen musste (so wie ich für einen unserer Kunden ;-/) weiß, es ist keine gute Idee ein Backup System auf dem OS laufen zu haben, das am allermeisten unter den Verschlüsselungs-Angriffen zu leiden hat. Wenn man dann noch berücksichtigt, dass die Datensicherung eines der ersten Angriffsziele der Erpresser ist, (wenn der angegriffene seine Daten nicht wiederherstellen kann, ist er natürlich eher bereit das Erpressergeld zu zahlen), sollte jedem klar sein, dass auch die Plattform der Backup-Software so sicher wie möglich sein muss. Und da ist man mit einem Linux-System wesentlich sicherer unterwegs! Mir ist zumindest bisher kein durch einen Verschlüsselungstrojaner verschlüsseltes Linux-System bekannt geworden!

Bis zur NetWorker-Version 19.9 war die Migration von Windows zu Linux für einen NetWorker-Server ein Albtraum. Aber mit den neu eingeführten Kommandos nsrimportmmdb und nsrimportclient, sowie einer DataDomain als Backup-Storage lässt sich eine NetWorker-Server Migration ohne Einschränkungen durchführen. Klar, es sind einige Vor- und Nach-bereitungen nötig, aber mit einer guten Planung kann die Downtime des NetWorker-Servers während der eigentlichen Migration auf wenige Stunden begrenzt werden.

Die Vorbereitungen umfassen hierbei folgende Arbeiten:

• die Anpassung der Client „servers“ Dateien
• den Aufbau des neuen Linux-NetWorker-Servers
• die Übernahme der benötigten NetWorker-Ressourcen (natürlich Script gesteuert)
• das Erstellen einer schreibbaren Kopie des Sicherungs-Mtrees auf der DataDomain (hierfür wird kein zusätzlicher Platz auf dem Storage-System benötigt!)
• eine erfolgreiche Test-Migration (inclusive Test-Wiederherstellungen am neuen Server)
• Migration der NetWorker Lizenz auf das neue System

Die eigentliche Übernahme besteht dann nur noch aus:

• dem still legen des Windows-NetWorker-Servers
• der erneuten Kopie des DataDomain Mtrees
• der Migration existierender vProxy Systeme
• der Migration evtl. vorhandener StorageNodes und deren Laufwerke
• Aktivieren des neuen Servers

Die Nachbearbeitungen sind:

• Übernahme der letzten Indices
• Anpassung der Notifications
• Löschen des „alten“ Windows Mtrees auf der DataDomain
• ...

Wichtig zu erwähnen ist, dass die Migration immer auf einem doppeltem Boden aufgesetzt ist. Zu jeder Zeit kann diese unterbrochen werden, wenn eine bisher ungeahnte Problematik auftritt oder zum Beispiel ein Passwort für die Wiederherstellung der Lockbox nicht zu bekommen ist. Wichtig ist daher genügend Zeit für Recover und evtl. auch Backup-Tests vor der eigentlichen Migration einzuplanen.

Sollten auch Sie Ihren NetWorker-Server noch auf einem Windows-System betreiben und möchten diesen auf ein Linux-System migrieren lassen, dann melden Sie sich doch unverbindlich beim Autor dieses Blogs.

Eine gute Datensicherung war noch nie so wichtig wie heute.

Es vergeht gefühlt kein Tag an dem nicht eine neue Malware oder Ransomware Attacke in den Nachrichten oder Zeitungen (z.B. heute 31.01.2023 ein ganzseitiger Artikel in der SZ) erscheint, in dem ein neuer Angriff thematisiert wird. Ein absoluter Schutz gegen diese Plage scheint nicht möglich. Umso wichtiger ist eine gute und sichere Datensicherung, damit man im Fall der Fälle die  verschlüsselten Daten schnell wieder herstellen kann. ABER: nach aktuellem Stand der Dinge ist das erste Angriffsziel der Hacker eben die Datensicherung. Denn wenn diese erst mal ausgeschaltet werden kann, ist der Angegriffene machtlos und muss wohl oder übel bezahlen.

Aus diesem Grunde sollte die Sicherheit der eigenen Datensicherungsumgebung eines der wichtigsten Themen in Ihrer  IT sein. Aber natürlich muss der Backup-Administrator zunächst mal wissen, wie man die Datensicherung vor unbefugtem Zugriff und vor allem vor vorzeitigem Löschen oder Verändern schützen kann.

Diese Herausforderung ist mittlerweile eines der wichtigsten Themen in meinem „NetWorker Advanced“. Hier ein kurzer Abriss der im NetWorker und der DataDomain eingebauten Schutzmechanismen.

Kommunikation zwischen Backup-Server und Backup-Client

Verwendung von generischen NetWorker Eigenschaften:

• Servers Datei
• Client Zertifikate
• Verschlüsselung der Datenkommunikation
  • Das ist auch ohne DataDomain möglich

• Einsatz des NetWorker Tunnel Moduls
  • nsr-tunnel : sichere Kommunikation vom NetWorker Server zu Clients in einer DMZ

Verwendung von Sicherheitsfeature der DataDomain Systeme

Boost Protokoll (Bandwidth Optimized Open Storage Protokoll)

Beim Boost Protokoll handelt es sich um ein properitäres Format, das von Viren nicht erkannt wird. Die folgenden Eigenschaften machen dieses Protokoll noch sicherer:

 

• Einsatz eines PEM-Zertifikats für das Boost-Protokoll
• Verschlüsselung des Datenstroms zwischen Client und der DD
  • Medium : AES128-SHA1
  • High : AES256-SHA1

 

Sicherheits-Konfigurationen im NetWorker

• Rollen basierte Definition der NetWorker Adminstratoren
  • Sichere Benutzer Definitionen
    • user,host, …, instname

• Bestmöglicher Einsatz von Tape als Sicherungsmedium
  • WORM
    • Verschlüsselung
      • per NetWorker ASM Funktion
      • Als Tape Funktion

• Einrichten von bestmöglichen Auditierungseinstellungen
  • Security-Audit Logs
  • Data-Audit-Logs

Sicherheits-Konfigurationen auf den DataDomain-Systemen

Verwendung einer DataDomain als sichere Datenablage:

• Einsatz der DataDomain RetentionLock Funktionalität (zeitlich beschränkte WORM Funktionalität)
• Es existieren zwei Modi:
  • Governance Mod:
    • auf MTREE Ebene aktivierbar
    • Schutz der gesicherten Daten auf der Protokoll Ebene
      • CIFS
      • NFS
      • Boost
    • Rentention-Zeiten können vom DD-Admin geändert werden.
      Allerdings nur auf Datei Ebene
  • Das Ergebnis
    • Die Backup-Daten sind vor Ablauf der Retention-Lock Zeit von der Backup-Applikation und dem Backup-Admin nicht mehr veränderbar
  • Compliance Mode:
    • Besonderheiten:
      • Kann nur für das ganze System gesetzt werden
      • benötigt einen Security Officer
      • …
    • Das Ergebnis:
      • keine auf der DD befindliche Datei kann mehr verändert werden
        Auch nicht vom DELL-Support

Einsatz weiterer Sicherheitsmechanismen der DataDomain Systeme

• Verschlüsselung der Daten auf der DataDomain
  • Unter Verwendung eines Key-Managers
• Duplizierung der Daten auf eine zweite DataDomain, mittels
  • ClonedControlReplication (CCR)
  • MTREE Replication

Einsatz weiterer DataDomain Features zum Erhöhen der Sicherheit

• Login Features
  • Unterstützung von LDAPS und AD mit SSL/TLS
  • Verwendung von DataDomain Benutzer Rollen
    • Boost User ohne Rechte auf der DD
    • Benutzer („user“)-Rolle zum monitoren der Systeme
  • Separieren der Admin und Security Benutzer
  • Einsatz einer zwei Faktor Autorisierung
    • beim Login wird ein zusätzliches Token verlangt
      • RSA-SecureID

Einsatz der DELL CyberSecurity Plattform

• Einrichten eines Air-Gap zum Schutz vor Insider Hacks
• Analyse der Daten im Secure Bereich
• Verwendung von CyberSense
  • Analyse der gesicherten Daten mit Mitteln der Software-Forensik
  • Sicher stellen eines Viren-freien Datenbestandes

Alle diese Konfigurationsmöglichkeiten zur Verbesserung der Datensicherheit werden in meinem NetWorker Workshop beleuchtet und wenn möglich auch praktisch vorgeführt.
Sollten ich Ihr Interesse an diesen Themen geweckt haben, würde ich mich freuen, Sie im Hause qSkills in Nürnberg begrüßen zu dürfen.
Es steht Ihnen aber auch die Möglichkeit zur Verfügung, mich für einen NetWorker und DataDomain Health Check in Ihrem Hause zu buchen.

Seit langem mal wieder ein NetWorker Blog mit der Besprechung eines neuen „tollen“ Features „MTREE Replication“.

Die letzten neuen NetWorker Versionen waren ja eher arm an neuen Funktionen, anders die Version 19.7, diese enthält gleich mehrere brauchbare Funktionserweiterungen und ein absolutes Highlight! Die „DataDomain MTREE Replication Unterstützung“. Diese Funktion ist bisher zwar nur auf Kommando-Ebene konfigurierbar, dies tut der Funktionalität aber keinen Abbruch und wurde diese kleine Hürde einmal geschafft, so erhält man eine ganz neue und mächtige Art der Disaster- und Test-Funktionalität für NetWorker-Server.

Eine kurze Beschreibung der Funktionalität:
Bisher war es nicht sinnvoll die DataDomain MTREE-Replication in Zusammenhang mit einem NetWorker-Server einzusetzen, da der Server mit der Kopie eines Volumes nicht direkt etwas anfangen kann (Duplikate für die Volume-ID und den Volume-Namen schließen sich in einem Server aus). Die neue MTREE-Replication geht daher einen ganz anderen Weg. Die mittels MTREE-Replication erzeugte Kopie wird nicht an dem Source-NetWorker-Server, sondern an einem zweiten NetWorker-Server (nennen wir ihn im folgenden mal DR-Server) integriert. Hierbei wird aber nicht nur das DD-Volume an dem DR-Server eingepflegt, sondern die neue Import-Funktion übernimmt auch alle Ressourcen und Indices von dem Source-Server. Nach dem Durchlauf eines Export, Replication und Import Zyklus hat man im DR-Server alle im SRC-Server durchgeführten Sicherungen für Tests oder für eine DR-Umgebung zur Verfügung!
Nach dem ersten Durchlauf des kompletten Zyklus enthalten die folgenden Workflow-Durchläufe nur das Delta der neu erzeugten Sicherungen, die völlig automatisiert in den DR-Server eingearbeitet werden.
 
Die ganze Funktionalität hat natürlich einige Voraussetzungen:

1. DataDomain-OS V7.7 oder höher
2. NetWorker VERSION 19.7
3. Den identischen DD-Boost-Benutzer auf beiden DD-Systemen (Name und UID)
4. Einige Ressourcen in beiden NetWorker Servern
   
   • Policy / Workflow / Replication Action
   • „NSR DD Device Replication“
5. Administrative Rechte des SRC-Servers im DR-Server
6. Gegenseitige Client-Ressource der beiden NetWorker-Server
7. Freien Speicherplatz im „/nsr“ Bereich, sowohl auf dem SRC- als auch auf dem DR-Server

Sind diese Hürden allerdings genommen, so erhält man folgende potentielle neue Möglichkeiten:

• Einen Standby-NetWorker-Server der immer nur „n“-Stunden hinter dem aktiven NetWorker hinterher läuft.

• Eine potentielle Test-Umgebung auf der man intensive NetWorker-Recover Tests durchführen kann, ohne den produktiven Server zu beeinträchtigen.

Einschränkungen:
Die Funktionalität ist nur von LINUX zu LINUX oder Windows zu Windows einsetzbar.

Leider kann ich in diesem Blog nicht auf alle nötigen Konfigurationsschritte eingehen, aber die Funktionalität ist ab sofort Bestandteil der beiden NetWorker-Workshops „NetWorker Update 19.x“ und „NetWorker Advanced“.