ExaGrid Time-Lock – Keine Angst vor Ransomware

Einleitung

Ransomware stellt aktuell eine der herausragenden Bedrohungen für IT Infrastrukturen dar. Berichte über erfolgreiche Angriffe häufen sich, die Einschläge kommen näher. Über 30% aller Unternehmen, Institute, Universitäten oder Behörden in Deutschland hatten bereits mit derartigen Attacken zu tun. Zum Teil wurde ein Lösegeld bezahlt, um wieder an die eigenen Daten zu gelangen.

Selbst bei Zahlung ist der Erfolg niemals sicher. Schließlich verhandelt man mit Verbrechern. Die Behörden raten daher von der Zahlung ab.

Die wesentliche Schutzmaßnahme gegen die Folgen einer solchen Attacke ist ein aktuelles und konsistentes Backup.

Ransomware vs. Backup

Leider wissen auch die Angreifer um die Wichtigkeit der Backups. Die aktuell kursierenden Schädlinge, wie z.B. Emotet oder Ryuk, enthalten Code der aktiv nach Datensicherungen im Netz fahndet. Mit vorher erlangten Zugangsdaten für Active Directory Konten oder durch Attacken auf z.B. RDP Lücken oder die brandaktuelle Zerologon Lücke wird versucht die Systeme zu übernehmen, welche die Datensicherung im Unternehmen betreiben bzw. die Backupdaten halten.

Oftmals folgen der automatischen Attacke sogar Hacker aus Fleisch und Blut, die sich aktiv im Netz umsehen und versuchen alle Backups zu zerstören. Ein vielfach leiches Unterfangen, da Backups heute vorzugsweise auf Festplattensystemen permanent mit der Infrastruktur verbunden sind.

Der Grund liegt auf der Hand: Sind alle Backups gelöscht oder ebenfalls verschlüsselt, steigt die Compliance des “Kunden” zur Zahlung eines Lösegeldes massiv.

Viele Ansätze wurden daher schon erdacht, die Backupdaten sicher im Netz abzulegen. Eine sehr einfache und sichere Variante ist ein Air-Gap – also eine echte Trennung der Backupmedien vom System. Beispielsweise können LTO Tapes physisch aus der Library entnommen werden.

Ohne eine solche aufwändige manuelle Entnahme – die zudem täglich erfolgen müsste – bleiben die Daten latent verwundbar. Ganz egal, ob sie auf Plattensystemen, Dedup-Appliances, Tapes in einer Library oder sogar in einem S3 Cloud Repository liegen.

S3 Cloud Anbieter haben daher schon vor einiger Zeit eine API Erweiterung mit dem Namen “Object Lock” vorgeschlagen. Hiermit können zumindest die Backups im Cloud Layer eine gewisse Zeit immun gegen Änderungen gemacht werden.

Einige dieser Lösungen werden inzwischen nativ von Veeam unterstützt. Amazon AWS gehört z.B. dazu. Microsoft Azure fehlt z.B. aktuell noch. Außerdem ist S3 Speicher nicht für jeden Anwendungsfall geeignet. Ein Primärbackup mit Veeam auf S3 ist z.B. nicht direkt möglich. Der S3 Layer ist ausschließlich als Erweiterung eines Scale-Out-Backup Repositories verfügbar.

„ExaGrid Time-Lock – Keine Angst vor Ransomware“ weiterlesen

Veeam Storage Plugin für DataCore – Deepdive

SANsymphony trifft Veeam Backup and Replication – Ende gut, alles gut!

(der folgende Artikel wurde automatisch aus dem englischen Original übersetzt)

Fragen, Ergänzungen oder Anmerkungen zu diesem Artikel: melter[at]idicos.de

Seit Dezember 2019 ist das Plugin für den populären DataCore SANsymphony SDS veröffentlicht. Realisiert wurde es auf die einzig richtige Art und Weise: Mit voller Unterstützung und Validierung durch Veeam.

In dieser Artikelserie werden wir verschiedene Aspekte des Plugins behandeln:

„Veeam Storage Plugin für DataCore – Deepdive“ weiterlesen

Netzwerk am CITRIX NetScaler VPX instabil durch VMWARE Patch für ESX 5.1 und 5.5

NetScaler VPX ist die virtuelle VPN, Firewall und Applikationsfilterlösung von Citrix. Wir verwenden diese in etlichen Projekten insbesondere für den Zugang auf XenDesktop, die VDI Lösung von CITRIX, aus dem Internet. Sie steht als Appliance für die gängigen Hypervisoren zur Verfügung und basiert auf einem gehärteten FreeBSD.

Die virtuelle Appliance steht mit begrenztem Leistungsumfang und nach Registrierung bei Citrix frei für jeweils ein Jahr zur Verfügung und reicht bequem für mindestens fünf gleichzeitige externe Zugriffe auf die XenDesktop Umgebung.


Kürzlich gab es in einer Implementierung, die schon >1 Jahr fehlerfrei funktionierte, folgendes Verhalten: Der Zugriff auf XenDesktop von extern funktionierte zunächst, war dann aber plötzlich weg. Meistens nach stärkerer Grafik- und damit Netzlast im ICA Protokoll. Die VM war in Folge der Störung auch nicht mehr im Netzwerk pingbar.

Nach einem Reboot der NetScaler VM war zunächst wieder alles in Ordnung – erneute Last führt aber reproduzierbar wieder zum Absturz.

Nähere Analyse ergab, dass auch der Zugriff auf die Management WebGUI bereits den Abbruch der Netzverbindung auslösen konnte.

Um die VM eingehend zu untersuchen wurde sie exportiert und in einen ESX Testcluster portiert.

Erstaunlicherweise war im Testcluster alles ok. Die VM war auch bei Netzlast stets funktional und erreichbar.

Wieder zurück im Produktivcluster gleiches Verhalten wie vorher.

In der WebGUI war, wenn das Netz einmal so lange durchhielt, eine Fehlermeldung im SysLog zu sehen:

stall

Offenbar kommt für gesendete Pakete keine rechtzeitige Rückmeldung (ACK) und NetScaler startet daher das Interface neu. Infolgedessen gehen alle Verbindungen über dieses Interface verloren.

Die Suche nach dem Problem im Netz ergab zunächst keine Hinweise.

Schließlich fanden wir den zielführenden Hinweis in der KB bei VMWARE und auch CITRIX. Laut VMWARE liegt das Problem bei CITRIX.

Sobald man den Hypervisor unter ESX 5.5 auf Update 2 (build 2143827) oder ESX 5.1 auf EP 5 (build 1900470) gehoben hat.

Citrix umschreibt das Problem so:

NetScaler VPX network connectivity issue on VMware ESXi 5.1.0 2191751 and VMware ESXi 5.5 Build 2143827 is caused by tx_ring_length mismatch, which causes TX stalls.

Das Problem wurde am 05.11.2014 von CITRIX veröffentlicht. Es gibt noch keinen Patch für die NetScaler Appliance. Dieser ist aber angekündigt.

Im Testcluster war das VMWARE Update noch nicht installiert – daher lief hier noch alles stabil wie vorher.


Bis zum erscheinen eines Patches für die NetScaler VPX wird ein Workaround vorgeschlagen, der bei uns nachhaltigen Erfolg brachte:

Hierzu muss unter dem FreeBSD des NetScaler eine Datei /flash/boot/loader.conf.local erzeugt werden.

In diese muss der Parameter hw.em.txd=512 eingefügt werden.

Wie geht das am schlankesten?

  • Anmelden in der NetScaler VM Konsole als nsroot
  • Wechseln auf die Shell mit shell
  • Eingabe von echo hw.em.txd=512 > /flash/boot/loader.conf.local
  • Hierdurch wird hw.em.txd=512 in diese Datei geschrieben, die üblicherweise noch nicht vorhanden ist.
  • Prüfen ob der Eintrag vorhanden ist kann man mit less /flash/boot/loader.conf.local
  • Danach noch reboot eingeben um die Appliance neu zu starten.
  • Problem gelöst. Das NetScaler Netzwerk ist auch unter Last wieder stabil.

hw.em.txd


Links:

NetScaler VPX Loses Network Connectivity on VMware ESXi 5.1.0 2191751 and VMware ESXi 5.5 Build 2143827

After applying patches to an ESXi 5.1/5.5 host, Citrix NetScaler virtual machine with e1000 vNIC loses network connectivity (2092809)