Veeam Endpoint Backup und Cryptolocker

Warum man unbedingt Zugriffsrechte auf Backup Targets einschränken sollte

Veeam hat einen guten Artikel zur Cryptolocker Problematik veröffentlicht. Es geht im Kern darum, was passiert wenn nicht nur der PC, sondern auch die Backup Dateien verschlüsselt werden.
Es ist daher sehr wichtig, das Backup-Ziel mit einem alternativen Login anzusprechen und dem PC Nutzerkonto darauf keine Schreibrechte zu erteilen. In der Praxis wird hier aus Nachlässigkeit gerne das Konto des Benutzers verwendet. Das kann sich als gravierender Fehler heraus stellen.

Veeam Backup Problem nach Update auf ESXi 6.0 U1

Nach dem Update auf ESXi 6.0 Update 1 kommt es zu Problemen bei Veeam Backup Jobs.

SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

In der Veeam Konsole erscheint die Meldung

Failed to create NFC download stream

Ursache ist die Abschaltung von SSLv3 in ESXi 6.0 U1. Der VMware KB Artikel 2121021 erklärt, wie man SSLv3 wieder aktivieren kann. Nach der Reaktivierung funktionieren die Veeam Backup Jobs wieder.

Nicht nur Veeam

Betroffen sind eine Reihe Anwendungen – auch vmware eigene. Offensichtlich kann die VMware NFC API nicht mit TLS umgehen. Ein Fallback auf SSLv3 ist seit dem Update jedoch nicht mehr möglich.

Auch wenn SSLv3 als veraltet und unsicher gilt, so kann man das Risiko in kontrollierter LAN Umgebung abwägen und dieses vorübergehend wieder aktivieren, bis VMware und/oder Veeam einen Patch bereitstellt.

 

SSL Fehler – schwacher Diffie Hellman Public Key

Zur Administration virtueller Appliances und Hardware im LAN verwende ich gerne Chrome als Browser. Das funktionierte bis vor kurzem einwandfrei. So war ich auch nicht schlecht überrascht, als mir beim gewohnten Aufruf einer WebGUI diese Meldung auf dem Schirm erschien:

WeakDHKey01
Wie bitte!? Ich hatte an der Appliance nichts verändert. Also probierte ich es mit Firefox. Aber auch damit gab es die rote Karte. Keine Möglichkeit die Warnung zu Bestätigen und “auf volles Risiko” fortzufahren (danke für den Hinweis, aber alles ist gut).

WeakDHKey02
Hintergrund dieses Phänomens ist die Tatsache, dass sowohl Google, als auch Mozilla ihren aktuellen Browsern den Kontakt mit https zu Webseiten mit schwachen SSL Schlüsseln komplett untersagt haben. Das ist nett gemeint und zu meinem Schutz im bösen Internet, aber es sperrt mich auf einen Schlag von der Administration zahlreicher Geräte und Appliances aus. Zumindest eine Experten-Option für nicht DAUs wäre nett gewesen.
Zumindest Firefox bietet hier etwas Spielraum über die Konfiguration. Bei Chrome gibt es nur Dirty Tricks, die aber im Alltag nicht praktikabel sind.

Firefox

Die erweiterten Einstellungen von Firefox erreicht man durch Eingabe von “about:config” (ohne Anführungszeichen) in der Adresszeile. Dort gibt es erweiterte Einstellungen. Wählt man diese erstmalig aus, erscheint eine Warnung zum Verlust der Gewährleistung (welche Gewährleistung?). Es müssen die beiden unten dargestellten Optionen auf “false” gesetzt werden. Dann erlaubt Firefox wieder den Kontakt mit der Webseite, trotz schwachem Private Key.

 

WeakDHKey03

Chrome

Den Workaround für Chrome poste ich nur der Vollständigkeit wegen. Er ist in meinen Augen nicht praxistauglich. Dazu muss Chrome über CLI oder eine angepasste Verknüpfung gestartet werden.

C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Eine Lanze für den IE

Mit dem IE ins Web gehen ist ja etwas für Chuck Norris und Danger-seeker, aber gelegentlich ist reduzierte Sicherheit auch von Vorteil. 😉

Zumindest machte IE 10 keine Schwierigkeiten beim Kontakt mit der schwach gesicherten Webseite.

Links

  • Test der Browser Einstellungen – DCSec