Data Protector und das VMware VDDK

In den aktuellen Patch und Versionsständen nutzt die VMware Integration von Data Protector das VDDK 5.0.

VDDK (Virtual Disk Development Kit) ist dafür zuständig VMFS Volumes von z.B. Backupprogrammen gelesen und geschrieben werden können. Konfiguriert man im DP eine SAN based Sicherung von VMware, werden die DataStore LUNs für die Sicherung read only an den DP gehängt. Bei einem Restore einer VM nutzt DP den optimalen Weg, also ein SAN based Restore. VDDK 5.0 enthält einen dokumentierten Fehler, welcher beim Schreiben auf read only DataStores abbricht:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2010428

Im Data Protector äußert sich der Fehler so, dass ein Restore zuerst normal läuft, aber nie beendet wird. Als Workaround sollte man in der omnirc den default Restore auf NBD setzen OB2_VEAGENT_RESTORE_TRANSPORT_METHOD=NBD

HP hat die Unterstützung für VDDK 5.1 mit einem Update des DP noch in diesem Jahr angekündigt.

http://www.vmware.com/support/developer/vddk/VDDK-510-ReleaseNotes.html#resolvedissues

Wer bewacht die Bewacher?

Viele Artikel der letzten Wochen, die sich mit der Spionage durch Geheimdienste beschäftigt haben, enthielten hinweise darauf, dass Geheimdienste in der Lage seien unterschiedliche Verschlüsselungen zu knacken, darunter auch SSL.

In den Fachmedien hingegen hieß es, dass die mathematischen Verfahren welche z.B. bei aktuellen SSL Implementierungen zum Einsatz kommen, weiterhin sicher sind und noch nicht geknackt wurden.

Grundsätzlich besteht für Geheimdienste oder andere Organisation die Möglichkeit Verschlüsselungen zu knacken. Mit hoher Wahrscheinlichkeit trifft dies jedoch nur auf Verschlüsselungen zu, deren mathematische Funktionen als nicht mehr sicher bzw. gebrochen gelten oder deren Implementierung falsch umgesetzt wurde.

„Wer bewacht die Bewacher?“ weiterlesen

TrendMicro InterScan Web Security via NetScaler LB / CS

Auf der Suche nach einer skalierbaren Viruswall für eingehenden Webtraffic haben wir eine spannende Kombination aus NetScaler Content Switching, Loadbalancing und der Trendmicro InterScan Web Security Appliance (IWSVA) zusammengestellt und damit gute Erfahrungen gesammelt.

In unserem konkreten Beispiel benötigte der Kunde eine Lösung um File Uploads in eine geschützte Umgebung zu realisieren und abzusichern. Für diese Anforderung kam die IWSVA gerade richtig, virtuell supported für vSphere und HyperV ist man schnell in der Lage mit einem PoC alle Anforderungen abzuklopfen und kann im Anschluss schnell horizontal erweitern und in Betrieb gehen. Darüber hinaus ist man virtuell einfach besser aufgestellt wenn der Kunde Systeme für verschiedene Staging Umgebungen benötigt.

Im aktuellen Beispiel lassen wir der Einfachkeit halber den gesamten eingehenden Traffic über die IWSVA laufen. In einer späteren Ausbaustufe sollte man sich aber Gedanken machen über die Trennung von GET und POST Requests, um die IWSVA nicht unnötig zu belasten.

Die User Sessions terminieren auf dem Content Switch der bestehenden NetScaler VPX. Hier können wir Policy-gesteuert den Ursprung der Session analysieren (http Header, Source IP) und die Session bei Bedarf an die Loadbalancing vServer für die IWSVA Anbindung leiten. Die IWSVA läuft als Reverse Proxy und scannt die Session auf die verschiedenen Sicherheitsbedrohungen. Im Anschluss werden die Sessions wieder an den Content Switch geleitet um hier weitere Prüfungen vornehmen zu können. In dieser vereinfachten Darstellung werden die Sessions an die Loadbalancing Prozesse für den Webservice geleitet.

Anhand der folgenden Grafik lässt sich die Architektur für diese Lösung gut erkennen.

Auf den ersten Blick schnell implementiert, dennoch sollte man sich die Zeit nehmen beim Design der Content Switching Policies und der Loadbalancing Details.

Domain Controller mit gespaltener Persönlichkeit

Das ist wohl schon einigen Admins passiert, die ein FreeNAS installiert und in ihre Domäne aufgenommen haben: Im Dialog zum Domänenbeitritt wird ein „Hostname“ abgefragt – hier ist der Hostname für das FreeNAS gefragt, also der Name des Maschinenkontos im AD. Wer hier den Namen eines seiner DCs einträgt, überschreibt damit dessen Maschinenkonto.

Was ist die Folge? Es kann leicht unterschiedliche Varianten geben, je nachdem bei welchem DC der Vorgang ausgeführt wird und wie die Replikation läuft. Das Ergebnis dürfte fast immer sein, dass der betroffene Domain Controller plötzlich nicht mehr mit seinem eigenen AD sprechen kann. Seine Dienste, allen voran der Anmeldedienst, haben damit ernsthafte Probleme – und alles und jeder, der sich bei ihm authentifizieren möchte, ebenfalls. Da er als gleichberechtigter DC im DNS gefunden wird, ist binnen kürzester Zeit die gesamte Domäne betroffen und zu einem großen Teil handlungsunfähig. Das System sollte daher umgehend vom Netz getrennt (heruntergefahren) werden.

Ist die Zeit bis zum Erkennen der Situation kurz genug, kann man vielleicht noch einen anderen DC finden, der die Änderungen noch nicht repliziert hat. Dort muss umgehend die Inbound Replication unterbunden werden, um diesen Stand auch zu erhalten. Dann kann das betroffene Objekt authoritativ geschaltet und ausgehend repliziert werden. Ist aber die Änderung bereits durch alle Replikationsverbindungen gelaufen (was selbst bei weitverzweigten ADs innerhalb weniger Minuten bis Stunden der Fall sein dürfte), greift das Standardverfahren für einen Authoritative Restore gemäß Microsoft.

Der grobe Ablauf ist: Starten des betroffenen DCs im Verzeichnisdienstwiederherstellungsmodus (VWM), Wiederherstellen des AD Objektes aus der letzten Datensicherung – falls kein Object Restore verfügbar ist, Wiederherstellen z.B. des Objektes „Systemstate“ (Symantec Backup Exec mit Server 2003 R2). Am Ende NICHT neustarten. Aufruf von ntdsutil auf dem betroffenen DC im VWM:

ntdsutil:
> authoritative restore
> restore object „Distinguished Name des überschriebenen Maschinenkontos“
> quit
> quit

Damit ist nur genau das betroffenen Objekt als authoritativ markiert und wird nach dem jetzt durchzuführenden Reboot bei der wieder anlaufenden Replikation nicht durch die neuere Version der anderen DCs überschrieben, sondern umgekehrt. Die üblichen Anlaufschwierigkeiten bei der Replikation sind im Eventlog zu erwarten, nach wenigen Minuten sollten aber Positivmeldungen folgen, dass die Heraufstufung zum Domain Controller durchgeführt werden konnte.

HP DataProtector 6.2 ante portas

In der nächsten Woche soll es voraussichtlich soweit sein: HP DataProtector 6.2 wird veröffentlicht.

Das neue Release bringt Features, die für die aktuelle Version 6.11 entweder gar nicht oder nur mit Patches und Klimmzügen realisierbar sind. Immerhin existieren schon seit einigen Monaten Patches, die die Verwendung der neuen vStorage API von vSphere ermöglichen; damit verbessern sich nicht nur die Sicherungsmöglichkeiten von VMware Infrastrukturen noch weiter, sondern es wird auch kostengünstiger. Seit letztem Sommer werden keine Online Lizenzen mehr für den VCB Proxy (jetzt: „Backup Server“) und den vSphere Center Server benötigt, sondern nur noch eine je ESX(i) Host.

In 6.2 integriert und supported ist dann auch das Disaster Recovery von Systemen mit Windows Server 2008 R2 mittels EADR (Enhanced Automated Disaster Recovery) und das ganze sogar auch auf abweichender Hardware. Eine Beschreibung der Technik und des Vorgehens sowie eine Skript-unterstützte Lösung für das Disaster Recovery eines Cell Managers selbst (unter 2008 R2) hat Daniel Braun in seinem DataProtector Blog veröffentlich.

Datensicherung ist kein Notfallplan

In den meisten größeren Unternehmen ist man sich des Unterschieds zwischen Datensicherung und Disaster Recovery bewusst, doch im Mittelstand fehlt diese Einsicht oft.

Die Datensicherung ist dazu da, Daten zu sichern und im Bedarfsfall wiederherstellen zu können. Daten, nicht ganze Systeme, sondern Nutzdaten. Also Dateien, Datenbanken etc., die versehentlich oder aus welchen Gründen auch immer gelöscht, überschrieben oder beschädigt wurden.

Ein Notfallkonzept betrachtet Großschadensfälle vom Hardware-Ausfall (System-Platten statt oder zusätzlich zu den Nutzdaten-Platten, zentrale Komponenten, die zum Ausführen von Betriebssystem und/oder Anwendungen/Diensten erforderlich sind, …) bis zur Nicht-Verfügbarkeit von Infrastruktur-Elementen wie Stromversorgung, Netzwerk, Anbindung reichen.

Das Notfallkonzept ist sehr individuell und vielfältig, denn es muss nicht nur verschiedene Szenarien betrachten, sondern auch unterschiedlichen Anforderungen an die Verfügbarkeit gerecht werden. So ergeben sich für die Auslegung einer zentralen Infrastruktur Verfügbarkeitsklassen, die Systemen/Diensten zugeordnet werden, und darauf basierend unterschiedliche Auslegungen der Infrastrukturelemente, die diese Systeme bereitstellen, sowie verschiedene Maßnahmenkataloge für den je nach Szenario notwendigen Wiederanlauf.

Abhängig von den umgesetzten Redundanz-Niveaus (Rahmen-Infrastruktur wie Strom, Kühlung etc., Netzwerk passiv und aktiv, Storage, Virtualisierung, Verfügbarkeitscluster) gibt es nur noch bestimmte Szenarien, die überhaupt dazu führen, dass eine Unterbrechung (Disaster) eintritt und ein Disaster Recovery erforderlich wird. Fällt beispielsweise ein ganzer Standort aus, aber sämtliche Daten und Systeme sind dank Speicher- und Server-Virtualisierung auch in einem weiteren Standort vorhanden und ausführbar, so liegt aus Infrastruktur-Sicht kein Disaster vor (Definitionssache, aber zumindest kann, entsprechende Kapazitäten vorausgesetzt, alles weiter ausgeführt und bereitgestellt werden). Dieses Niveau lässt sich etwa mit einem Storage Cluster aus HP MSA P4000 (ehemals „Lefthand“) und entsprechend aufgebauter Virtualisierungsinfrastruktur (Citrix, VMware, Microsoft) erreichen.

Man reduziert so die Wahrscheinlichkeit, aber irgendwie kann es doch immer noch passieren, dass mal ein System komplett wiederhergestellt werden muss. Sei es aufgrund von Kompromittierung durch einen Angreifer (neu installieren oder auf einen definitiv sauberen Stand zurück gehen) oder durch beschädigte Daten im Systembereich. Dafür muss es entsprechende Mechanismen geben, die etwa auf Imaging-Verfahren oder einer Software-Verteilung inkl. Betriebssystem-Installation basieren könnten. Die Möglichkeiten klassischer Backup Software sind hier meist eingeschränkt, erlauben bei entsprechend sauberer Umsetzung aber zumindest die Wiederherstellung auf absolut identischer Hardware. Oft ist das aber gar nicht mehr das Problem, da die „Hardware“ sowieso eine Virtuelle Maschine ist. Aber es reicht nicht aus, einfach „alles“ mit der Datensicherung zu sichern.

Datensicherung ist kein Notfallplan. Wer eine Datensicherung einkauft und umsetzt, hat davon kein Notfallkonzept für Komplettausfälle von Systemen.