Mounten eines vmdk Laufwerks im Linux Host – I – vmware-mount

Manchmal muss man sich auf einem Linux-Virtualisierungs-Host direkt - d.h. ohne Umweg über virtualisierte Gastsysteme - mit dem Inhalt von "vmdk"-Dateien auseinandersetzen. Ich stelle in diesem und nachfolgenden Beiträgen ein paar einfache Möglichkeiten vor, die ich selbst immer mal zum Mounten von Filesystemen, die sich innerhalb von vmdk-Dateien befinden, in den Verzeichnisbaum meiner Linux-Workstations benutze. Als Beispiele müssen dabei NTFS-Testpartitionen einer vmdk-Disk herhalten, die einer virtuellen Maschine mit Win7 zugeordnet wurden.

Szenarien für den direkten Zugriff unter Linux?

"vmdk"-Dateien dienen unter Linux primär dazu, VMware-Gastsysteme - aber z.B. auch Virtualbox- und qemu-Gastsysteme - mit einem virtuellen "Festplatten"-Unterbau auszustatten. Ich spreche nachfolgend daher auch von "vmdk-Disks". Ein allgemeiner Begriff, der das Prinzip von virtuellen Disks in Form von Dateien umschreibt, ist der eines Disk-Images.

Eine vmdk-Disk kann wie eine echte Platte auch Filesysteme (wie Ext4, NTFS oder BrtFS) aufnehmen. Unter KVM korrespondieren zu "vmdk" etwa "qcow2"-Dateien. Die Nutzung von Linux-Dateien als Container für Filesysteme bringt beim Virtualisieren einige Vorteile mit sich: u.a. kann man die virtuellen Platten relativ problemlos zwischen Hosts hin- und her bewegen. Natürlich lässt sich auch die Durchführung von Backups für "vmdk"-Dateien besonders einfach mit Linux-Bordmitteln durchführen.

Nun könnte man sagen, dass man auf die über "vmdk" bereitgestellten Filesysteme ja immer über die virtuelle VMware-Gast-Maschine selbst zugreifen kann. Das stimmt so nicht uneingeschränkt: Bisweilen muss man etwa die Pflege des/der auf der vmdk-Datei installierten Filesystems/e über Tools des Hosts betreiben. In anderen Fällen ist eine Bereinigung von eingefangenen Viren auf einem NTFS-Filesystem nötig, ohne dass das betroffene Gast-System gebootet werden soll. Ein anderes wichtiges Szenario ist die forensische Analyse von Inhalten der virtuellen Maschine - z.B. eines kompromittierten Windows-Gastsystems - durch Linux-Tools. Für letzteres reicht oftmals der lesende Zugriff. Weitere Anwendungsfälle sind logischerweise auch Pen-Tests (oder Hacker-Angriffe), bei denen der "Angreifer" von einem (teil-)eroberten Virtualisierungshost aus die Extraktion von Daten aus dort vorhandenen vmdk-Dateien virtueller Maschinen anstrebt.

Toolunterstützung unter Linux?

Die Spezifikation zu "vmdk" ist seit einiger Zeit offen; man erwartet daher, dass der Zugriff auf Inhalte von vmdk-Dateien (bzw. -"Laufwerken") unter Linux gut unterstützt wird. Unterstützung bedeutet für mich dabei primär die Erfüllung zweier Anforderungen:

  • Der Inhalt von "vmdk"-Disks sollte sich für den berechtigten User nach ein paar Schritten so darstellen, als gebe es dort (ggf. mehrere) Partitionen mit je einem unter Linux handhabbaren Filesystem (wie etwa NTFS von MS).
  • Unter diesen Filesystemen muss man dann eines auswählen und - wie von echten Festplatten gewohnt - mounten können.

Für den Anwender ist der Einsatz entsprechender Tools unter Linux unterschiedlich komfortabel: Einige Tools führen alle notwendigen Schritte inkl. des Mountens für den User bequem in einem Rutsch durch; besonders nachvollziehbar ist das Vorgehen hinter den Kulissen des/der jeweiligen Kommandos dann aber nicht. Dies gilt im Besonderen für die Behandlung sog. vmdk-Container.

FUSE, Loop Devices - Komplexität durch Snapshots, "sparse vmdk-Container" mit mehreren "Extension Files" und mit mehreren internen Partitionen/Filesystemen

Es gibt vier Hindernisse, die Entwicklern von vmdk-Tools überwinden müssen:

  • Sparse-vmdk: Spezielle Schwierigkeiten bei der Analyse der in vmdk-Disks verborgenen Filesysteme bereitet u.a. die Tatsache, dass eine einzelne vmdk-"Disk" oftmals in Form eines Containers daherkommt, der sich über mehrere vmdk-Dateien (jedes davon z.B. mit einer Größe von 4GB) erstreckt.
    Man spricht hier von "growable split and sparse file vmdk"; die "virtuelle" Platte wächst auf dem Host durch immer neu angelegte 2GB oder 4GB große Extents erst im Lauf der Zeit auf die Gesamtgröße an. Auch jedes einzelne neue Extension File selbst wächst dabei bedarfsgerecht an.
    Es gibt dann eine "führende", beschreibende vmdk-Datei - etwa mydisk.vmdk - und etliche weitere Extension-Dateien mit der Endung "-sNNN" - also z.B. "mydisk-sNNN.vmdk"; "NNN" steht dabei für eine dreistellige Nummer. Die führende Datei nennt man auch Deskriptor-Datei (s. hierzu den nächsten kommenden Artikel).
  • Mehrere Partitionen auf einer Disk: In beiden Fällen (sparse und flat) kommt hinzu, dass eine vmdk-Disk mehrere Partitionen beinhalten kann.
  • Loop-Devices und Offsets: Hat man die Partitionen in einer vmdk-Disk erstmal erkannt, muss man entsprechende Linux-"Devices" für den Zugriff als Blockdevice definieren. Dabei muss man sich natürlich auch um den sog. "Offset" einer spezifischen Partition relativ zum Anfang der beherbergenden Disk-Datei(en) kümmern.
  • Snapshots: Weiter verkompliziert wird die Handhabung für den Nutzer noch dadurch, dass man unter VMware Snapshots einer virtuellen Maschine anlegen kann. Solche Snapshots äußern sich in weiteren Zusätzen der vmdk-Dateien; z.B. mydisk-000001-s001.vmdk. Man muss also unter der Menge vorhandene vmdk-Disk-Dateien geeignete Snapshot-Dateien auswählen (z.B. mydisk-000001.vmdk). Dabei können die führende Snapshot-Datei und die ehemals führende Datei (die auch der Snapshot mitnutzt) u.U. in verschiedenen Verzeichnissen liegen (s.u.). Noch weitere Namens-Zusätze unterscheiden übrigens ggf. Clones virtueller Maschinen.

Ergänzende Hinweise (im nächsten Artikel liefere ich dazu auch Links):

Zu einer "growable split and sparse Disk" (Container) gibt es auch die Variante, dass zwar über mehrere Files hinweg gesplittet wird, aber der gesamte Plattenplatz von vornherein allokiert wird. Die erste Extent-Datei nennt man auch "Base-File" des vmdk-Disk-Images.
Das Gegenteil zu einer Sparse Disk, die über viele Extension Files verteilt ist, ist das sog. "monolithic file vmdk"; dabei wird von Anfang an nur genau eine vmdk-Datei für die angestrebte virtuellen Platte angelegt. Das bringt neben strukturellen Unterschieden u.a. geringfügige Performance-Vorteile. Aber auch hier gibt es wieder zwei Möglichkeiten: Die Datei kann von vornherein den gesamten Platz der virtuellen Disk allokieren, oder sie kann langsam wachsen. In letzterem Fall spricht man auch von einer "Monolithic Sparse Disk".

Bei aktuellen Linux-Werkzeugen zu vmdk führt der Weg zur Lösung der oben genannten Probleme intern regelmäßig über die Nutzung von FUSE und Loop-Devices. Letztere werden manchmal auch Loopback-Devices genannt; sie sind aber nicht mit dem gleichnamigen Netzwerk-Device "lo" zu verwechseln. Siehe zu Loop-Devices etwa
Wikipedia-Artikel zu Loop-Devices;
OSDevv.org zu Loopback-Device;
http://www.tldp.org/HOWTO/archived/Loopback-Root-FS/Loopback-Root-FS-2.html.

In "vmdk"-Containern mit einer Vielzahl von sparse vmdk-Dateien, aber auch in wachsenden monolithischen vmdk-Dateien ist die Adressierung von Sektoren und Daten-Blöcke unterschiedlicher Partitionen verständlicherweise kompliziert. Auf solche vmdk-Disk-Images kann man unter Linux deshalb weder fdisk noch kpartx direkt loslassen. Leider. Aber kleine Umwege mit linux-eigenen Zusatztools führen auch dann zum Ziel - selbst wenn man nicht das nachfolgend besprochene Tool von VMware einsetzen will.

Zugriff mit dem VMware-Tool "vmware-mount"

Hat man die VMware-Workstation für Linux lizenziert, finden sich nach der Installation unter "/usr/bin/" eine Reihe von Kommando-Tools vor, die mit "vmware-" beginnen.

mytux:~ # vmware
vmware                            vmware-installer                  vmware-ping
vmware-authd                      vmware-license-check.sh           vmware-tray
vmware-authdlauncher              vmware-license-enter.sh           vmware-usbarbitrator
vmware-collect-host-support-info  vmware-modconfig                  vmware-vdiskmanager
vmware-fuseUI                     vmware-mount                      vmware-vim-cmd
vmware-gksu                       vmware-netcfg                     vmware-vprobe
vmware-hostd   

Die meisten dieser Kommandos haben eine Option "help", die Informationen liefert. "man"-Seiten gibt es leider nicht.

Für uns relevant ist im aktuellen Kontext "vmware-mount". Dieses nützliche CLI-Werkzeug ist auch Teil des VMware VDDK (s. folgenden Link vddk/; das VDDK wird unabhängig von der VMware WS angeboten und enthält auch Tools für den Remote-Zugriff auf Virtual Disks eines VMware ESX-Servers).

"vmware-mount help" zeigt die nötigsten Infos und Optionen zum Kommando an:

mytux:~ # vmware-mount help
VMware DiskMount Utility version 6.5.0, build-7528167

Usage: vmware-mount diskPath [partition num] mountPoint
       vmware-mount [option] [opt args]

There are two modes for mounting disks.  If no option is
specified, we mount individual partitions from virtual disks
independently.  The filesystem on the partition will be
accessible at the mount point specified.

The -f option mounts a flat representation of a disk on a
user-specified mount point.  The user must explicitly unmount
the disk when finished.  A disk may not be in both modes at once.

Options: -p <diskID>      list all partitions on a disk
         -l <diskID>      list all mounted partitions on a disk
         -L               list all mounted disks
         -d <mountPoint>  cleanly unmount this partition
                          (closes disk if it is the last partition)
         -f <diskPath> <mountPoint> mount a flat representation of the disk
                          at "mountPoint/flat."
         -k <diskID>      unmount all partitions and close disk
         -K <diskID>      force unmount all partitions and close disk
         -x               unmount all partitions and close all disks
         -X               force unmount all partitions and close all disks
         -r               mount the disk or partition read-only
         -o               comma-separated list of options to be passed
                          to the 'mount' when mounting a partition

 
Wissen muss man demnach noch, was eine sog. "" ist; diese Info erhält man z.B. aus einem von unter VMware bereitgestellten PDF (VMwareDiskMount.pdf :

"In the following list of options, is an identifier of the form username@hostname:/path/to/disk for remote disks, or just the /path/to/disk for local disks."

Man kann diskIDs für vmdk-Files auf ESX-Servern einsetzen. Das interessiert uns hier nicht weiter.
Auf lokalen Linux-Systemen entspricht eine diskID gerade einem Pfad (Path) zu einer führenden vmdk-Datei.

Identifikation von Partitionen mit vmware-mount

Probieren wir "vmware-mount" einfach mal lokal aus; auf meinem Testsystem liegt etwa unter "/vmw/Win7" eine Windows 7-Installation für VMware Workstation, die u.a. eine kleine vmdk-Disk namens "Win7_x64_ssd_ex.vmdk" mit einer NTFS-Partition für Testzwecke beherbergt. Um es einfach zu machen, besteht dieses Disk-Image nur aus genau einem vmdk-File (monolithic sparse disk). Es sind keine Extension Files vorgesehen; der Speicherplatz ist aber nicht vorallokiert. "vmware-mount" hat damit erwartungsgemäß keine Probleme:

mytux:/vmw # vmware-mount -p /vmw/Win7/Win7_x64_ssd_ex.vmdk/ 
Nr      Start       Size Type Id Sytem                   
-- ---------- ---------- ---- -- ------------------------
 1       2048   12576768 BIOS  7 HPFS/NTFS

Es wird korrekterweise genau eine Partition mit NTFS erkannt (6GB; 512Byte Sektorgröße). Wären mehrere File-Systeme enthalten, würden die entsprechend aufgelistet werden (s.u.).

fdisk erkennt weder die Partitionen einer über genau ein File repräsentierten monolithischen vmdk-Disk noch die eines echten vmdk-Containers

"fdisk -l" erkennt im Gegensatz zu vmware-mount nur die Blockstruktur des Files als Ganzes, nicht aber dessen interne Filesystem-Struktur:

mytux:~ # fdisk -l /vmw/Win7/Win7_x64_ssd_ex.vmdk 
Disk /vmw/Win7/Win7_x64_ssd_ex.vmdk: 34.9 MiB, 36569088 bytes, 71424 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Das gilt, obwohl für meine spezielle Test-Disk nur genau ein (wachsendes) vmdk-File vorliegt:

mytux:~ # la /vmw/Win7/ | grep ex
-rw-rw-rw-  1 myself  users   36569088 Mar 23 18:03 Win7_x64_ssd_ex.vmdk

Nun umfasst meine virtuelle Maschine aber auch noch eine weitere Test-Disk, deren Container tatsächlich zwei unterschiedliche Files beinhaltet:

mytux:/vmw/Win7 # la | grep ssdx
-rw-------  1 myself  users 2344157184 Mar 27 19:38 Win7_x64_ssdx-s001.vmdk
-rw-------  1 myself  users     131072 Mar 27 19:37 Win7_x64_ssdx-s002.vmdk
-rw-------  1 myself  users        511 Mar 27 19:34 Win7_x64_ssdx.vmdk

Leider liefert fdisk auch für diesen Fall kein besseres Ergebnis:

mytux:/vmw/Win7 # fdisk -l Win7_x64_ssdx.vmdk 
fdisk: cannot open Win7_x64_ssdx.vmdk: Inappropriate ioctl for device
mytux:/vmw/Win7 # fdisk -l Win7_x64_ssdx-s001.vmdk 
Disk Win7_x64_ssdx-s001.vmdk: 2.2 GiB, 2344157184 bytes, 4578432 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Dagegen ermittelt vmware-mount auch für diesen komplexen vmdk-Container die richtige Filesystem-Information:

mytux:/vmw/Win7 # vmware-mount -p Win7_x64_ssdx.vmdk 
Nr      Start       Size Type Id Sytem                   
-- ---------- ---------- ---- -- ------------------------
 1       2048    5310464 BIOS  7 HPFS/NTFS
 2    5312512    3072000 BIOS  7 HPFS/NTFS

Aus diesem Grund vermutet man, dass vmware-mount intern zunächst einmal das hoch-spezifische vmdk-(Container)-Format in ein für Linux handhabbares "flat-file"-Format aufdröselt. Zur linux-konformen Handhabung der vmdk-Spezifikation wird dabei intern auf zeitgemäße FUSE-Mechanismen zurückgegriffen. Sagt zumindest eine Recherche zu unterschiedlichen FUSE-Formaten im Internet ...

Mounten

Die allgemeine Form des "vmware-mount"-Kommandos ist:

myself@mytux:~> su -c 'vmware-mount /vmw/Win7/Win7_x64_ssd_ex.vmdk /mnt/vmdk/'

Zur Durchführung des Mounts braucht man root-Rechte. Im obigen Fall muss man also das root-Passwort kennen. Alternativ wechselt man gleich in eine root-Shell.

Wir sehen dann in meinem Testfall etwa folgende Inhalte:

myself@mytux:~> la /mnt/vmdk/        
insgesamt 9
drwxrwxrwx 1 root root 4096 22. Mär 10:57 .
drwxr-xr-x 5 root root 4096 20. Mär 18:36 ..
drwxrwxrwx 1 root root    0 22. Mär 10:34 $RECYCLE.BIN
drwxrwxrwx 1 root root    0 21. Mär 08:41 System Volume Information
-rwxrwxrwx 1 root root   11 22. Mär 10:57 ufo1.txt
drwxrwxrwx 1 root root    0 22. Mär 10:36 ufodir
-rwxrwxrwx 1 root root    6 20. Mär 18:35 ufo.txt

Beispiele mit mehreren Partitionen innerhalb einer vmdk-Disk und mit mehreren vmdk-Files eines echten vmdk-Containers diskutiere ich weiter unten. Dabei läuft alles aber weitgehend analog zum eben erläuterten Beispiel ab.

Zwischenschritte von vmware-mount

vmware-mount nimmt uns freundlicherweise gleich mehrere Aktionen ab:

  • Involvieren von "FUSE"-basierten Methoden zur Bereitstellung der "vmdk"-Disk als zusammenhängendes "flat"-File. Dieses (scheinbar) zusammenhängende File wird in einem temporären Verzeichnis unter "/run/vmware/fuse" bereitgestellt
    /run/vmware/fuse/ID-Nummer/flat
    Das Verzeichnis erhält eine ID-Nr, die die Disk identifiziert. Die ID wird als Hash generiert.
  • Anlegen eines Loop-Devices (hier: /dev/loop0) mit richtiger Offset-Positionierung (hier: 1048576).
  • Mounten des Loop-Devices (hier /dev/loop0) auf dem Ziel-Mount-Punkt (hier: /mnt/vmdk); das geschieht wiederum mit Hilfe des Fuse-Plugins für ntfs-ng3

Mehr Information?

Ein paar weiterführende Informationen findet man für unser Testbeispiel durch folgende Kommandos:

mytux:~ # mount
....
/dev/fuse on /run/vmware/fuse/13958668715283886016 type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
/dev/loop0 on /mnt/vmdk type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
...
mytux:~ # losetup -l
NAME       SIZELIMIT  OFFSET AUTOCLEAR RO BACK-FILE                                  DIO
/dev/loop0         0 1048576         0  0 /run/vmware/fuse/13958668715283886016/flat   0
....
mytux:~ # cat /run/vmware/fuse/13958668715283886016.info 
.encoding = "UTF-8"
backingPath = "/vmw_win7/Win7_x64_ssd_ex.vmdk"
diskName = "/vmw_win7/Win7_x64_ssd_ex.vmdk"
mountPath = "/run/vmware/fuse/13958668715283886016"
refCount = "1"
privateFlatFile = "TRUE"
isRemote = "FALSE"
openFlags = "0"
readOnly = "FALSE"
mountPath0 = "/mnt/vmdk"
loopPath0 = "/dev/loop0"

 
Auf die Bestimmung des Offsets kommen wir weiter unten zurück.

Sicheres Unmounten

Hat man mittes vmware-mount einen schreibenden Zugriff realisiert, so ist schon allein wegen des umfangreichen Cachings auf einem Linux-Host ein sicheres Unmounten erforderlich: Dabei erfolgt vorab eine Synchronisation (Sync) von geänderten Daten vom Cache in das/die Container-File/s hinein. Das Unmounten erfordert die Angabe der Option "-d":

mytux:~ # vmware-mount -d /mnt/vmdk/ 

Anzugeben ist dabei lediglich der Mount-Point. Manchmal dauert der Unmount-Prozess wg. der Syncs zur Festplatte einen Tick.

Mounten als Flat File?

Die Option "-f" (s. oben) deutet an, dass "vmware-mount" dem Linux-User auch die Möglichkeit gibt, einen vmdk-Container einfach nur in ein zusammenhängendes "flat"-File umzuwandeln, das man dann selbst einer weiteren Behandlung zuführen kann:

mytux:~ # vmware-mount "-f" /vmw/Win7/Win7_x64_ssd_ex.vmdk /mnt
mytux:~ # la /mnt
total 6291456
-rw-rw-rw- 1 myself users 6442450944 Mar 23 18:03 flat
mytux:~ # fdisk -l /mnt/flat
Disk /mnt/flat: 6 GiB, 6442450944 bytes, 12582912 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x77138461

Device     Boot Start      End  Sectors Size Id Type
/mnt/flat1       2048 12578815 12576768   6G  7 HPFS/NTFS/exFAT

Wie man die in einem solchen "Flat"-File enthaltenen Filesysteme konkret über Loop-Devices nutzen kann, besprechen wir im übernächsten Artikel, in dem wir ein natives Linux-Tool für den Zugriff auf einen vmdk-Disk-Container benutzen werden.

Vorsicht mit Modifikationen und Rechten bei NTFS-Partitionen einer vmdk-Disk

Da wir gerade bei Rechten waren, ist eine Warnung bzgl. NTFS-Systemen in vmdk-Containern angebracht:

Die User und Rechte im virtualisierten Gastsystem (hier Win7) sind im Linux-Host nicht ohne weiteres bekannt. Bei der Anwendung von ntfs-3g müssen daher Standard-"Umsetzungen" von Linux-UIDs/GIDs auf Windows SIDs verwendet werden sowie Standard-ACL-Abbildungen erfolgen. Im Fall von "vmware-mount" bedeuten die intern gewählten Standard-Umsetzungen:

Warnung 1: Nach dem oben besprochenen Einsatz von vmware-mount erhält jeder Linux-User auf dem Linux-System Lese- und Schreibrechte - sowohl am Flat-File wie auch bzgl. des gemounteten Filesystems.

Das ist leider unabhängig von den (ursprünglichen) Linux-Rechten des Mount-Punktes (hier: /mnt/vmdk). Man probiere das selbst aus und lasse sich die Rechte vor und nach dem Mounten anzeigen. Das hat denn ggf. auch Konsequenzen im virtualisierten Windows-System:

Warnung 2: Evtl. manuell nach dem vmware-mount angelegte Dateien/Ordner auf dem NTFS-System gehören später unter dem virtualisierten Windows zwar den dortigen Administratoren - aber auch dort hat jeder Windows-User trotzdem Vollzugriff.

Diese Rechte-Situation zu ändern ist meines Wissens mit VMware-Tools alleine nicht möglich. Siehe zu einer feingranulareren, Nutzer-unterstüzten Abbildung aber:
Windows Partitionen einbinden mit NTFS-3G.

Read-Only-Mount

Im Zweifel ist es besser, auf Nummer sicher zu gehen und die Filesystem der virtuellen Disk-Images nur read-only zu mounten. Also (als root):

mytux:~ # vmware-mount -r /vmw/Win7/Win7_x64_ssd_ex.vmdk /mnt/vmdk/

Obwohl die Rechte danach immer noch identisch zum vorherigen rw-Mount angezeigt werden, sind faktisch keine Schreibzugriffe mehr möglich. das verhindert aber immer noch nicht den Diebstahl von Daten durch unbefugte Nutzer. In einem kommenden Artikel komme ich beim Zugriff auf "flat"-Files über Loop-Devices auf dieses Thema zurück.

2-te Partition einer Snapshot-vmdk-Disk mounten

Abschließend habe ich zu unserer Test-Disk mal drei Snapshots angelegt und sie zudem danach in zwei NTFS-Partitionen unterteilt. Dann ergibt sich folgendes komplexere Bild:

Die ursprüngliche vmdk-Disk lag unter "/vmw/Win7/", die virtuelle Maschine mit ihrer Haupdisk aber unter "/vmw/Win7Prod/". Die Snapshots der ursprünglichen Disk
/vmw/Win7/Win7_x64_ssd_ex.vmdk
wurden automatisch aber unter "/vmw/Win7Prod/" abgelegt - der letzte als
/vmw/Win7Prod/Win7_x64_ssd_ex-000003.vmdk.

Der Unterschied mach sich sich schon beim Betrachten der Partitionen bemerkbar:

mytux:/vmw/Win7Prod # vmware-mount -p ../Win7/Win7_x64_ssd_ex.vmdk 
Nr      Start       Size Type Id Sytem                   
-- ---------- ---------- ---- -- ------------------------
 1       2048   12576768 BIOS  7 HPFS/NTFS

mytux:/vmw/Win7Prod # vmware-mount -p Win7_x64_ssd_ex-000003.vmdk 
Nr      Start       Size Type Id Sytem                   
-- ---------- ---------- ---- -- ------------------------
 1       2048    6295552 BIOS  7 HPFS/NTFS
 2    6297600    6279168 BIOS  7 HPFS/NTFS

Mounten der zweiten Partition im dritten Snapshot zeigt:

mytux:/vmw/Win7Prod # la | grep _ex
-rw------- 1 myself  users   42860544 Mar 27 11:19 Win7_x64_ssd_ex-000001.vmdk
-rw------- 1 myself  users    1572864 Mar 27 11:51 Win7_x64_ssd_ex-000002.vmdk
-rw------- 1 myself  users    1572864 Mar 27 11:56 Win7_x64_ssd_ex-000003.vmdk

mytux:/vmw/Win7Prod # vmware-mount  Win7_x64_ssd_ex-000003.vmdk 2 /mnt/vmdk

mytux:/vmw/Win7Prod # la /mnt/vmdk
total 8
drwxrwxrwx  1 root root 4096 Mar 27 11:15 .
drwxr-xr-x 38 root root 4096 Mar 20 11:14 ..
drwxrwxrwx  1 root root    0 Mar 27 11:08 System Volume Information
drwxrwxrwx  1 root root    0 Mar 27 11:50 tull
mytux:/vmw/Win7Prod7 # la /run/vmware/fuse
total 8
drwxr-xr-x 3 root   root    80 Mar 27 12:08 .
drwxr-xr-x 5 root   root   180 Mar 27 11:56 ..
dr-xr-xr-x 2 myself users 4096 Mar 27 12:08 11844985246325345490
-rw-r--r-- 1 root   root   344 Mar 27 12:08 11844985246325345490.info
mytux:/vmw/Win7Prod # losetup
NAME       SIZELIMIT     OFFSET AUTOCLEAR RO BACK-FILE                                  DIO
/dev/loop0         0 3224371200         0  0 /run/vmware/fuse/11844985246325345490/flat   0

 
Der Offset errechnet sich hier übrigens aus einem Standard vmdk-Offset von 2048 * 512 Byte plus der Größe der ersten Partition

2048 * 512 + 6295552 * 512 = 6297600 * 512 = 3224371200

Ganz analog läuft unser Beispiel mit dem echten Container "Win7_x64_ssdx.vmdk", der zwei Extension-Files und zwei Filesysteme beinhaltet:

mytux:/vmw/Win7 # vmware-mount -p Win7_x64_ssdx.vmdk 
Nr      Start       Size Type Id Sytem                   
-- ---------- ---------- ---- -- ------------------------
 1       2048    5310464 BIOS  7 HPFS/NTFS
 2    5312512    3072000 BIOS  7 HPFS/NTFS
mytux:/vmw/Win7 # vmware-mount  Win7_x64_ssdx.vmdk /mnt2
mytux:/vmw/Win77 # la /mnt2
total 8
drwxrwxrwx  1 root root    0 Mar 27 19:35 $RECYCLE.BIN
drwxrwxrwx  1 root root 4096 Mar 27 19:35 .
drwxr-xr-x 38 root root 4096 Mar 20 11:14 ..
drwxrwxrwx  1 root root    0 Mar 27 19:34 System Volume Information
mytux:/vmw/Win7 # vmware-mount -d /mnt2
umount: /var/run/vmware/fuse/15887816320560912647.links/19: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)
mytux:/vmw/Win7 # vmware-mount -d /mnt2
Failed to unmount partition '/mnt2': Nothing mounted at the given mountpoint
mytux:/vmw/Win7 # vmware-mount  Win7_x64_ssdx.vmdk 2 /mnt2
mytux:/vmw/Win7 # la /mnt2
total 196124
drwxrwxrwx  1 root root      4096 Mar 27 19:38 .
drwxr-xr-x 38 root root      4096 Mar 20 11:14 ..
drwxrwxrwx  1 root root         0 Mar 27 19:37 System Volume Information
-rwxrwxrwx  2 root root 200822784 Nov  4  2013 mysql-installer-community-5.6.14.0.msi
mytux:/vmw/Win7 # vmware-mount -d /mnt2

Hier sieht man übrigens, dass man bei einer manchmal auftauchende Fehlermeldung "target is busy" im Unmount-Process, die u.a. auch durch Desktop-Suchmaschinen bedingt sein kann, nicht gleich in Panik verfallen muss.

Man beachte beim zweiten Mount-Versuch die 2 in "vmware-mount Win7_x64_ssdx.vmdk 2 /mnt2"; diese 2 spezifiziert das zweite Filesystem. Auch in diesem Fall wird natürlich ein "Flat-File" angelegt:

mytux:/vmw/Win7 # vmware-mount  Win7_x64_ssdx.vmdk 2 /mnt2
mytux:/vmw/Win7 # la /run/vmware/fuse 
total 8
drwxr-xr-x 3 root root    80 Mar 27 20:50 .
drwxr-xr-x 5 root root   180 Mar 27 19:38 ..
dr-xr-xr-x 2 rmo  users 4096 Mar 27 20:50 15887816320560912647
-rw-r--r-- 1 root root   299 Mar 27 20:50 15887816320560912647.info
mytux:/vmw/Win7 # la /run/vmware/fuse/15887816320560912647 
total 4194304
-rw------- 1 myself  users 4294967296 Mar 27 19:34 flat
mytux:/vmw/Win7 # 

Fazit

vmware-mount bietet eine einfache Möglichkeit, Partitionen, die in vmdk-Containern enthalten sind, unter Linux zu mounten. Container kann man aber auch einfach nur als ein Flat-File mounten und die Behandlung der enthaltenen Partitionen über Loop-Devices selbst übernehmen. Die automatisch vergebenen Rechte (voller Lese- und Schreibzugriff durch jedermann) erfordern aber Vorsicht.

Im nächsten Beitrag

Mounten eines vmdk-Laufwerks im Linux Host – II – Einschub, Spezifikation, Begriffe

liefere ich zunächst einige Hinweise zur vmdk-Spezifikation nach und versuche dann, durch Rückgriff auf ein Tool aus dem qemu-Bereich, das erforderliche Flat-File zu einem vmdk-Container ohne vmware-mount bereitzustellen.

Links

https://www.novell.com/communities/coolsolutions/retrieve-modify-take-backup-files-inside-vmdk-offline-mode/

systemd bug: systemd-tmpfiles-setup.service fails with unknown user „systemd-network“

I had a strange error after updating "systemd" on one of my Opensuse server systems from version 228.41.1 to version 228.44.1. This update seems harmless, but it is not. With it substantial changes appear in the file /usr/lib/tmpfiles.d/systemd.conf. Especially the lines:

d /run/systemd/netif 0755 systemd-network systemd-network -
d /run/systemd/netif/links 0755 systemd-network systemd-network -
d /run/systemd/netif/leases 0755 systemd-network systemd-network -
</p>

In my case this lead to trouble - service "systemd-tmpfiles-setup.service" started to fail :

# systemctl status -l systemd-tmpfiles-setup
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
   Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static)
   Active: failed (Result: exit-code) .....
...
...
Mar 12 11:33:32 myserv systemd-tmpfiles[509]: [/usr/lib/tmpfiles.d/systemd.conf:19] Unknown user 'systemd-network'.

I checked whether user "systemd-network" existed with YaST. Yes, it was there - with all its default details.
However the command

getent passwd systemd-network

did not give me anything!

It took me a bit to find out what had happened. On this server I had once experimented with NIS, NISplus. The "/etc/passwd"-file still contained a line

+::::::

The "/etc/group"-file had a corresponding "+:::". However, no active NIS server is any longer defined. Should not matter as long as the file have a correct format, i.e. as long as the NIS-lines are placed at the bottom of the files ...

But:
At some point in time (?) systemd had created the user "systemd-network" and a corresponding group. Unfortunately, both entries were dumbly added at the end of the files "/etc/passwd" and "/etc/group" - i.e. after the already existing NIS-lines.

systemd-timesync:x:478:478:systemd Time Synchronization:/:/sbin/nologin
+::::::
systemd-network:x:475:475:systemd Network Management:/:/sbin/nologin

Not funny! Because, this in turn became the cause for the empty "getent"-answer!

However, it seems that systemd now uses "getent" to check the existence of some special systemd-users like "systemd-network" as a requirement for starting certain services. Which then leads to errors ...

Summary
"systemd" seems to add new user- and group-entries at the bottom of the files "/etc/passwd" and "/etc/group" - without checking for NIS lines. Or it at least did at some point in the past. This may prevent the start of some initial services for which the existence of user or group entries are checked.

So, if you run across a similar problem check your "passwd" and "group" files for wrong entries at the end of the file! Move the NIS lines to the very bottom of the files. Afterward "getent" will work again for all user entries - and your failed services hopefully will start again.

Note: If you still get errors for "unknown systemd-users" you have to check whether entries for all the required users really exist in "/etc/passwd".

P.S.: The stupid thing on Opensuse is that YaST shows you the required users with passwd-entries below a NIS line as existing, whereas "getent" does not.

Bundeshack: Outlook kann nicht das einzige Problem sein – I

Mittwoch früh erhielt ich eine Nachricht von einer guten Bekannten; der Mailinhalt bezog sich auf den SZ-Artikel
http://www.sueddeutsche.de/digital/exklusiv-so-schleusten-die-hacker-daten-aus-dem-auswaertigen-amt-1.3894534
zum Hacker-Angriff auf das IVBB. Offenbar wird dieser Angriff jetzt als "Bundeshack" bezeichnet - und beschäftigt wohl einige Sicherheitsexperten in der Republik. Meine Bekannte schrieb mir, ich hätte mit meinen regelmäßig kritischen Anmerkungen zur Sicherheit heutiger IT-Infrastrukturen und im Besonderen zu MS-Produkten - wie Outlook - wohl mal wieder Recht gehabt. Das stimmt in diesem Fall aber nicht so ganz, denn tatsächlich sind mit der Sicherheit des IVBB Fachleute befasst, die die Gefahrenlage und auch die eingesetzten SW-Produkte in und auswendig kennen. Und leider verführt der SZ-Artikel dazu, das Versagen primär bei Outlook zu sehen. Das ist aber zu kurz gedacht; die im IVBB aufgetretenen Probleme müssen - wenn man mal glaubt, was die Presse kolportiert - aus meiner Sicht noch tieferliegende Ursachen haben. Was mich als IT-affinen Bürger dann eher beunruhigt ...

Neutraler und sachlicher im Ton als der SZ-Beitrag ist der kommentierende Artikel bei Heise (s. https://www.heise.de/security/meldung/Bundeshack-Daten-sollen-ueber-Outlook-ausgeleitet-worden-sein-3987759.html?xing_share=news). Dort wird zu Recht festgestellt, dass die Informationen der SZ mehr Fragen aufwerfen, als sie beantworten.

Ich fasse nachfolgend und in einem weiteren Artikel ein paar eigene Gedanken zum Thema "Bundeshack" zusammen. Ich hoffe, das hilft, eben jene Fragen besser zu erkennen, die sich nach dem SZ-Artikel aufdrängen. Meine Argumente sind dabei weitgehend unabhängig von der Frage "MS oder nicht" - und deshalb hoffentlich auch für Linux-Freunde interessant. Kommentare könnt ihr gerne per Mail an mich schicken.

Verschlüsselte Kommunikationsverbindungen ins Internet - und ihre zwei Seiten

Zunächst wollen wir die Grund-Information des SZ-Artikels - nämlich, dass die Hacker Mails (ggf. über Manipulationen von Outlook) zur Kommunikation mit einer Schad-Software und zum Transfer von geheimen Informationen nach außen genutzt haben - genauer einordnen. Als Voraussetzung ist dazu, für den einen oder anderen vielleicht überraschenderweise, ein Blick auf Datenverschlüsselung erforderlich.

Ich gehe mal davon aus, dass der Leser mit mir einig ist, dass ein essentielles Problem von Angriffen auf Behördennetze ein nachfolgender unkontrollierter Abfluss von Daten an Unbefugte ist. (Das ist natürlich nur ein Bedrohungsaspekt von Hacker-Angriffen; andere blende ich hier aber mal aus). Der illegale Zugriff auf Daten betrifft u.a. geheime Informationen der Exekutive sowie der Legislative, die z.Z. auch im Behördennetz hängt, aber ggf. auch Daten der Judikative. In keinem Fall kann man wollen, dass Hackern ein unbefugter Zugriff auf geheimzuhaltende Daten von Behörden (wie etwa dem Auswärtigen Amt) gelingt und diese nach außen transferiert werden. Wie erfolgt denn eigentlich ein unbemerkter Daten-Transfer von einem gehackten Gerät (PC, Notebook, Smartphone, ...) und aus einem Firmen/Behörden-Netzwerk nach außen an irgendwelche Empfänger im Internet? Wieso ist das überhaupt möglich?

Antwort: U.a. wegen zu großen Freiräumen für elektronische Kommunikation am Arbeitsplatz und ausgerechnet auch noch durch ein wichtiges IT-Sicherheits-Element - nämlich Verschlüsselung. Wie das?

Als ich vor Jahren mal an einem Projekt in einer öffentlichen Institution arbeitete, hatte ich eine erbitterte "Diskussion" mit einer hoch positionierten - und politisch gut verdrahteten - Führungskraft zum Thema HTTPS. Es gab im Zuge der Auseinandersetzung sogar eine schriftliche Beschwerde: Ich könne doch wohl nicht am Vormittag HTTPS-Verbindungen fordern und am Nachmittag HTTPS in einem anderen Kontext als problematisch darstellen. Tja, ... kann ich doch ... Es ging dabei nämlich um zwei ganz verschiedene Dinge: Am Vormittag wurde HTTPS als (halbwegs) sicheres Verbindungsprotokoll diskutiert, das es Kunden/Bürgern ermöglichen sollte, über das Internet auf einen künftig zu betreibenden Web-Service der Institution zuzugreifen. Am Nachmittag aber waren verschlüsselte Web-Verbindungen von den Arbeitsplatz-PCs der Behörden-Angestellten aus zu Web-Mail-Diensten privater Anbieter im Internet das Thema. Letzteres war erlaubt ...

Mancher sicherheitsbewusster Leser wird schon jetzt den Kopf schütteln ... Ich hatte damals (am Nachmittag) diese "Policy" als ideale Möglichkeit für korrupte, unzufriedene oder schlicht böswillige Mitarbeiter charakterisiert, unkontrollierbar und auch im Nachhinein nur äußerst schwer nachweisbar interne, geheimzuhaltende Daten nach außen abfließen zu lassen.

Meine Kritik stieß damals leider auf völliges Unverständnis. Man müsse seinen Mitarbeitern/innen doch wohl vertrauen können ... Nun ja, ich sehe das von Haus aus anders. Zudem sind bei Sicherheitsthemen nicht nur die Mitarbeitermotivation sondern auch Gefahrenpotentiale zu berücksichtigen, die durch das unbedarfte Handeln von Mitarbeitern im Kontakt mit dem Internet ungewollt auftreten können (s.u.). Unabhängig davon: Der Versuch, einem Politiker den Unterschied

  • zwischen den Gefahrenpotentialen ausgehender verschlüsselter Verbindungen vom Arbeitsplatz-PC eines Angestellten (oder dortiger Programme) ins Internet einerseits
  • und den Gefahren bei der Behandlung von Daten eingehender verschlüsselter Verbindungen zu vom Betreiber kontrollierten Webservern in einer gesicherten Zone andererseits

zu vermitteln, erwies sich im Nachgang jedenfalls als unerwartet, ja geradezu verblüffend schwierig...

Den Lesern dieses Linux-Blogs ist dagegen natürlich klar, dass Verschlüsselung ab einem Endgerät (PC, Notebook, ...) und aus einem Verwaltungsnetz heraus zu externen Servern ein echtes Problem darstellt. Grund: Niemand kann dann mehr kontrollieren, was über eine solche Verbindung an ggf. unbefugte Empfänger im Internet übertragen wird. Zumindest nicht ohne Zusatzmaßnahmen. Man erkennt bei etwas Nachdenken unschwer, dass Sicherheit durch Verschlüsselung immer eine Frage der Autorität über die verschlüsselten Daten ist und zum zweischneidigen Schwert werden kann:

Als Privatperson sollte ich unzweifelhaft der Herr meiner Daten sein - und z.B. auf einer Verschlüsselung in der Kommunikation mit Behörden bestehen. Als Behörde habe ich stellvertretend die Autorität über die mir vom Bürger anvertrauten Daten erlangt - und muss durch Sicherheitsmaßnahmen u.a. Folgendes garantieren:

  • Behörden müssen kontrollieren können, dass zu schützende Daten nur Befugte erreichen und von Unbefugten nicht eingesehen werden können.
  • Behörden müssen dafür sorgen, dass zu schützende Daten im Transfer zu Befugten verschlüsselt werden, wenn dabei öffentliche Netze passiert werden.

Hierbei gibt es aber Risiken (u.a. durch böswillige Mitarbeiter), denen durch Maßnahmen zu begegnen ist. Die Autorität über Datenflüsse nach außen und über evtl. zu schützende Inhalte kann ich aus Gründen der Risikoeindämmung in der IT nicht an einzelne Mitarbeiter oder Programme am Arbeitsplatz-PCs abtreten. Erforderlich ist vielmehr eine unabhängige, unbestechliche Kontrolle darüber, welche elektronischen Daten über welche Kanäle nach außen wandern. Das ist zumindest meine Erwartung an Behörden in demokratisch verfassten Staaten. Unkontrollierter Abfluss von geheim zu haltenden Daten von Arbeitsplatz-PCs aus geht gar nicht. Und eine durchgehende Verschlüsselung durch Mitarbeiter vom Arbeitsplatz zu Empfängern im Internet erweist sich hier gerade als Problem, da die Verschlüsselung i.d.R. irreversibel ist und auch im Nachhinein keine Inhalts- und Berechtigungskontrolle zu dem Transfervorgang mehr möglich ist.

Das gilt u.a. für Mail-Verschlüsselung in Mail-Anwendungen am Arbeitsplatz genauso wie für HTTPS-Verbindungen zu irgendwelchen Web-Servern. Betroffen sind potentiell aber auch andere Netzwerk-Protokolle. Die nach außen übermittelten verschlüsselten Inhalte sind in allen Fällen auch im Nachhinein nur schwer zu - wenn überhaupt - zu ermitteln. Ggf. durch die Koinzidenz von Zeitstempeln bei Datei-Zugriffen und darauf anschließendem Mailversand. Zeitstempel liefern aber nur Indizien. Ein rechtskräftiger Beweis lässt sich daraus nur schwerlich ableiten, wenn man die Verschlüsselung nicht knacken kann. Gut verschlüsselter Inhalt an illegitime Empfänger ist halt immer noch gut verschlüsselt.

Wenn man dann noch die Aufnahme verschlüsselter Verbindungen zu vom Arbeitsplatz zu beliebigen Zieladressen im Internet zulässt, wird das Problem immens:

Nicht nur ein böswilliger Mitarbeiter kann über einen verschlüsselten Kanal von einem Endgerät aus geheime Daten nach außen schleusen. Über verschlüsselte Verbindungen kann man sich ggf. auch Malware unkontrolliert einhandeln, bevor ein lokaler Virenscanner die eliminieren kann. Und - noch schlimmer: Prinzipiell kann natürlich auch jede Malware (Schad-Software), die man sich irgendwie und irgendwann mal durch Unachtsamkeit eingefangen hat, einen verschlüsselten Verbindungskanal nach außen nutzen, um Informationen an externe Empfänger zu senden.

Vertrauen in Mitarbeiter ist eine Sache; unerkannte Malware, die mit der Nutzerkennung des Anwenders ausgehende Verbindungen zu Systemen im Internet aufnimmt, ein andere.

Nun wird der eine oder andere Leser sagen: Aber wir haben ja Firewalls!? Tja, schon - aber der transferierte Inhalt wurde ja schon im Browser am Arbeitsplatz mit einem zwischen Browser und Zielserver ausgehandelten Schlüssel verschlüsselt. Die Firewall kann die Legitimität der Verbindung damit in keinem Fall mehr am Inhalt festmachen. Höchstens und vielleicht noch am Adressaten. Aber auch ein legitimer Adressat kann illegitime Inhalte über verschlüsselte Verbindungen erhalten.

Nächste Frage: Warum sind verschlüsselte Verbindungen in der öffentlichen Verwaltung dann überhaupt sinnvoll und erlaubt? Hatte ich weiter oben nicht gerade selbst verlangt, dass Kommunikation über das Internet verschlüsselt werden muss? Liegt hier nicht ein Widerspruch vor?

Gute Frage! Betrachten wir zunächst mal eine Privatperson: Die braucht Verschlüsselung, um über das Internet sicher mit anderen Diensteanbietern (in der "Cloud") kommunizieren zu können. Man denke dann z.B. an die Notwendigkeit der Verschlüsselung von Daten im Online-Banking, aber - und ebenso wichtig - an die Notwendigkeit, die Identität eines Webservers feststellen zu können, um nicht auf vorgegaukelte Webseiten hereinzufallen, die dem Original täuschend ähnlich sehen. Auf privaten PCs/Notebooks/Smartphones wird eine dortige "Personal Firewall" deshalb also kaum HTTPS-Verbindungen nach außen blocken. Im Gegenteil sind Privatpersonen eher dazu zu ermuntern, HTTPS wann und wo immer möglich zu nutzen.

Das gilt für Privatpersonen. Im Grunde aber doch auch für Behörden?

Wir dürfen bei der Beurteilung den oben diskutierten Punkt nicht übersehen: Die Tatsache, dass verschlüsselte Verbindungen von Nutzer-Geräten nach außen zu Web- und Dienste-Servern der "Cloud" in unserer internet-dominierten Welt so (überleben-) wichtig sind, dass sie zumindest auf normalen PCS, Smartphones, etc. nicht ohne weiteres geblockt werden können, ist aber eben auch ein erheblicher Schwachpunkt moderner web-orientierter IT und macht einmal eingefangene Schad-Software so erfolgreich und gefährlich:

Der Mensch wird einerseits als Schwachstelle für das Einschleusen von Malware genutzt; die Malware nutzt danach verschlüsselte Verbindungen vom Gerät des Anwenders zu Computern im Internet, welche direkt oder wiederum über Schad-Software durch den Angreifer kontrolliert werden. Was dabei alles vom eigenen PC, aus dem umgebenden Firmen- oder Behördennetz nach außen übertragen wird, können wir dann leider nicht mehr kontrollieren.

Darin besteht die problematische, "dunkle" Seite von Verschlüsselung in bestimmten Arbeitsumgebungen. Kann man diese negative Seite und andererseits die positive Seite von Verschlüsselung bei Behörden überhaupt in Einklang bringen?

Verschlüsselung und Closed Source

Mal (nicht) ganz nebenbei: Unter dem Gesichtspunkt "unkontrollierter Datenabfluss" stellt "Closed Source-Software", die regelmäßig verschlüsselte Verbindungen zu Herstellern und deren Servern aufnimmt, von Haus aus ein großes Problem dar. Auch da haben wir überhaupt keine Chance zu prüfen, was da von unseren Systemen nach außen abfließt. Für mich ist das ein entscheidender Grund dafür, warum der Einsatz von Closed Source Software und Betriebssystemen im öffentlichen Verwaltungsbereich grundsätzlich ein Fehlgriff ist.

Die Umkehrung der Bedrohungsverhältnisse

Nicht nur ein böswilliger Mitarbeiter, sondern auch jede Art von Schad-Software wird typischerweise versuchen, vom "beherbergenden" System aus verschlüsselte Kommunikationskanäle von innen nach außen (!) zu Systemen im Internet aufzubauen, die unter Kontrolle des Angreifers liegen. Der nachfolgende Kommunikationsfluss erfolgt in beide Richtungen; er kann dabei sowohl Kommandos zur Steuerung der Schad-SW (und nach einer Rechteeskalation ggf. des gesamten umgebenden Systems) beinhalten oder aber den Transfer von Informationen zum Angreifer in ganz unterschiedlicher Form.

Früher betrachtete man die Absicherung von Netzen als Aufgabe, zu deren Lösung man einen "Schutzwall" um das eigene Netz aufbaut, der von außen kommende Angriffs- und Eindring-Versuche blockt. Das war schon immer ein unzureichendes Bild. Der Angriff auf IT-Strukturen erfolgt nicht nur von außen nach innen; mit "Social Engineering" und dem Ausnutzen mentaler Schwachpunkte von Menschen gelingt die Platzierung von Malware im Zeitalter von "Bring your own device" auch in Firmen immer irgendwann. Der wirkliche Angriff läuft danach aber sozusagen eher ungeblockt von innen nach außen. Modetrends wie "Bring your own Device (BYOD)" und das Nutzen von Cloud-Diensten lassen zudem die Grenzen zwischen Firmen- und Behörden-Netzen und dem Internet immer weiter verschwimmen. Wenn System-Administratoren meinen, sie müssten in der heutigen Zeit vor allem den Datenverkehr von außen nach innen kontrollieren, irren sie gewaltig. Die Überwachung des Verbindungsaufbaus von innen nach außen und die Überwachung zugehöriger Datenströme ist in bestimmten Netzen noch wichtiger. Übrigens: UDP-basierte Multimedia-Anwendungen, die mit Internet-Diensten kommunizieren, stellen dabei ein besonderes Problem-Umfeld dar und haben in sicheren IT-Umgebungen meiner Meinung nach nichts verloren. Das betrifft im besonderen Skype und dessen Ableger für Firmen.

Leider ignorieren das viele Firmen ... Auch manche Behörden erheben eine Policy zur Erlaubnis verschlüsselter Verbindungen vom Arbeitsplatz-PC ins Internet geradezu zum mitarbeiterfreundlichen Prinzip .. und verlieren dabei jegliche Kontrolle über den Datenabfluss.

Verschlüsselte Verbindungen - ein Dilemma?

Unsere bisherige Diskussion hat bislang ein Dilemma beschrieben:
In einem Behördennetz mit Geheimhaltungsbedarfen sind verschlüsselte Verbindungen/Mails zwischen User-Endgeräten und Servern im Internet ein großes Problem. Andererseits erscheint Verschlüsselung im Datenaustausch über das Internet geradezu als Pflicht ... (Tatsächlich werden ausgehende verschlüsselte Verbindungen ins Internet in vielen Netzen - u.a. denen von Behörden - erforderlich und werden von sog. Perimeter-Firewalls oft auch zugelassen.)

Das Dilemma gipfelt in der Frage: Sollte man Verwaltungsangestellten die Aufnahme verschlüsselter Verbindungen von Netzen, in denen geheimzuhaltenden Informationen gelagert sind, nach außen überhaupt erlauben? Eigentlich kann die Antwort nach dem bisher Ausgeführten nur "Nein" lauten.

Was ist also tun? Der entscheidende Punkt besteht darin, die Irreversibilität von Verschlüsselung ab dem Arbeitsplatz zu vermeiden.

Im Fall hoher Sicherheitsbedürfnisse wird man daher im Regelfall Verschlüsselung nicht direkt von den Endgeräten der Anwender aus zulassen. Das Ziel typischer Lösungsansätzen ist es vielmehr, die Kommunikation über aktive Server des eigenen Netzes zu leiten, bevor ein irreversibler Verschlüsselungsprozess einsetzt. Zentrale Sicherheits-Appliances auf Servern, die im eigenen Netz platziert sind und die die Kommunikation nach außen herstellen, müssen dabei die Kontrolle über die über die ausgehende Verbindung sowie die ausgetauschten Daten und Inhalte behalten.

Entsprechende Lösungsansätze bestehen im Fall von E-Mail darin, Mailverschlüsselung erst ab einem und über einen zentralen Mailserver zuzulassen und automatisiert sowie in Abhängigkeit von den Empfängeradressen durchzuführen. Die Verbindung zwischen Enduser-PC und Mailserver verbleibt dabei unverschlüsselt - oder wird mit eigenen Schlüsseln geregelt, die an den zentralen Servern eine Entschlüsselung der Inhalte erlauben. Die eigenen Server behalten dabei die Kontrolle über die transferierten Inhalte in beide Richtungen. Nicht besonders datenschutzfreundlich bzgl. der Mitarbeiter? Die Frage ist eher, ob private verschlüsselte Mails in Verwaltungsnetzen, in denen hohe Sicherheitsbedarfe gegeben sind, überhaupt etwas zu suchen haben.

Im Fall von HTTP / HTTPS bestehen Lösungswege darin, ausgehende HTTPS-Verbindungen und andere verschlüsselte Verbindungen von User-Geräten entweder zu verbieten oder aber zwischengeschaltete Web-Proxy-Server einzusetzen, die die Verschlüsselung/Entschlüsselung sozusagen als legitimierte "Man-in-the-Middle"-Instanz übernehmen. Proxys müssen dabei die Zertifikate der Zielserver prüfen, den Inhalt der ausgetauschten Datenströme analysieren, protokollieren, etc.. Der User kann dabei evtl. sogar in Richtung Proxy verschlüsseln, aber eben mit Schlüsseln, die mit dem Proxy ausgehandelt werden und nicht mit Schlüsseln für Zielserver im Internet. Der Proxy kann daher Inhalte des Datenstrom entschlüsseln und behält so die Kontrolle über die ausgetauschten Inhalte. Letztere verschlüsselt er dann automatisch neu im Rahmen einer separat aufzubauenden Verbindung mit dem Zielserver im Internet. (Ein verschmerzbarer Nachteil ist, dass der Anwender selbst die Gültigkeit von Zertifikaten der Empfangsstelle nicht direkt kontrollieren kann.)

IVBB und verschlüsselte Verbindungen

Gem. SZ und Heise-Artikel sind verschlüsselte Verbindungen von Anwendern aus dem IVBB nach außen verboten. Gut so! Genau richtig! Das entspricht meinen Erläuterungen von oben. Worin besteht dann das beim Bundeshack laut SZ aufgetretene Problem?

Mail als Kommunikationskanal zu Schad-SW ?

Nun kennen professionelle Angreifer/Hacker/Geheimdienste vermutlich die Verschlüsselungspolitik im IVBB genau. Sie werden sich also intensiv Gedanken darüber gemacht haben, wie sie "Kommunikationskanäle" von einer einmal auf einem angegriffenen IVBB-Gerät implantierten Schad-SW nach außen aufbauen können. Das "unauffällige" und "elegante" Vorgehen, wie die SZ einen Sicherheitsfachmann zitiert, besteht nun wohl darin, ein Mail-Programm als Kommunikationskanal zu nutzen.

Das ist allerdings viel naheliegender als die Presse das darstellt. E-Mail-Kommunikation wird in Organisationsnetzen womöglich noch weniger unterbunden und von den Zieladressen her eingegrenzt als HTTPS- und HTTP-Verbindungen. Behörden müssen ja auch mit anderen Institutionen des öffentlichen Lebens und ggf. sogar Bürgern kommunizieren. Das ist Teil ihrer Aufgabe.

Ein- und ausgehende dienstliche Mails von und zu Mitarbeitern in Behörden werden aber (hoffentlich) auf die dabei transferierten Inhalte geprüft - u.a. durch Virenscanner - und in besonders sicherheitslastigen Umgebungen (hoffentlich) auch durch intelligentes Scannen der textuellen Inhalte: Eingehende Texte u.a. wegen Spam, ausgehende Texte in Kombination mit der Empfängeradresse u.a. wegen illegitimer Inhalte. Voraussetzung ist wiederum, dass eine evtl. Verschlüsselung der Mails erst ab einem eigenen Ausgangsserver (SMTP-Server) erfolgt.

Was aber, wenn ein Angreifer in den Inhalten einlaufender Mails (durch einfache Sprach- oder Buch-Codes) gar keine Malware oder Spam-Inhalte, sondern gestückelt und über den Text verteilt Kommandos an eine SW unterbringt? Und umgekehrt eine Schad-Software oder ein böswilliger Mitarbeiter ausgehende Geheiminformationen illegalerweise in scheinbar harmlosen Texten oder Bildern einer Mail verbirgt - und die geheimzuhaltenden Informationen nur stückweise über mehrere Mails an unbefugte Empfänger überträgt? So, dass das mengenmäßig nicht auffällt? Dann haben Virenscanner ein Problem. Und wird dann zusätzlich nicht auf "seltsame" Empfangs- und Zieladressen reagiert, so gibt es ein absehbares Sicherheitsloch.

Es braucht dann theoretisch nur noch zwei Zutaten für ein Sicherheits-Desaster:

  1. Die bereits vorhandene, implantierte Schad-SW muss eingehende Mails und/oder deren Anhänge auslesen können.
  2. Die Schad-SW muss eigene Mails kodieren und über zentrale Server zu Zieladressen, die der Angreifer kontrolliert, verschicken können - ohne dass das auffällt.

Wie konnte der Datenabfluss über Mails nach außen eigentlich gelingen?

Der SZ-Artikel hebt vor allem auf die Methodik ab, dass von den Angreifern E-Mails zur Steuerung einer ansonsten autonom lebenden Schad-SW, die in diesem Fall offnbar keine aktiven Verbindungen nach außen aufnahm, genutzt wurde. Ja, das ist in der Tat bemerkenswert - und sollte zu einer anderen Einstellung gegenüber dem Aufbau von Arbeitsplätzen in sicherheitsrelevanten Bereichen führen. Darauf komme ich im zweiten Artikel zurück.

Aber viel naheliegender und kritisch zu betrachten ist doch folgender Punkt:
Der Schaden ist vor allem dadurch entstanden, dass Informationen nach außen geschleust werden konnten. Wir hatten aber festgestellt, dass man in sicherheitsrelevanten Netzen die Kontrolle über alle auslaufende Datenströme und deren Inhalte behalten muss. Deswegen wurde ja im IVBB gerade - zumindest gemäß der SZ - der Aufbau verschlüsselter Verbindungen nach außen unterbunden. Nun würde man annehmen, dass das dann auch für den E-Mail-Kanal gilt. Sprich:

  1. Alle Mails gehen ausschließlich über einen eigenen zentralen Mail-Versand-Server (SMTP-Server). Der direkte Versand von Mails mittels eines Mail-Clients vom Arbeitsplatz aus über andere (externe) SMTP-Server wird durch Firewalls strikt unterbunden.
  2. Der eigene Versandserver kann die Identität des Senders nicht nur anhand der IP-Adressen des Arbeitsplatz-PCs sondern auch über elektronische Signaturen an den Mailinhalten feststellen. Die intern verwendeten Signaturschlüssel sind natürlich durch Passwörter geschützt ...
  3. Der eigene Mailserver kann den Mailinhalt und den Inhalt von Anhängen analysieren, bevor vor dem Versand nach außen eine ggf. erforderliche Verschlüsselung in Richtung Adressat erfolgt. Bereits am Arbeitsplatz-PC verschlüsselte Inhalte werden vor dem Versand erkannt und nicht akzeptiert.
  4. Alle Klartext-Inhalte ausgehender Mails (und deren Anhänge) werden zumindest auf Schlüsselbegriffe und versteckte Botschaften hin analysiert. Die Möglichkeit von kodierten Botschaften in Multimediadateien (Steganographie) wird in Betracht gezogen und geprüft (statistische Analyse oder Vergleiche mit Originalen aus definierten offiziellen Datei-Depots. Unbekannte Multimediadateien werden eliminiert.)
  5. Der zentrale Versandserver prüft die Mail-Adresse des Adressaten auf Auffälligkeiten - und stoppt die Mail gegebenenfalls. In diesem Zusammenhang sind von Mitarbeitern ggf. explizite Deklarationen und Freigaben von Ziel-Adressaten in zentralen Listen/Datenbanken einzufordern.

Nun drängt sich - unabhängig von Problemen mit Outlook - der Verdacht auf, dass an einem dieser Punkte etwas schief gegangen sein muss. Oder, dass meine - hoffentlich einsichtige Haupt-Annahme - nicht stimmt und zentrale Mail-Versand-Server und dortige Prüfungen durch die Schad-Software umgangen werden konnten. Was beides peinlich wäre, da alle genannten Punkte grundsätzlicher Natur sind. Entsprechende Schwachpunkte hätten dann ja auch bereits Menschen - z.B. korrupte Angestellte - ausnutzen können. Zu allen oben genannten Punkten fallen einem natürlich noch weitere Unterpunkte und Fragen ein.

Zum ersten Punkt ist zu sagen, dass eine Perimeter-Firewall einen Mailversand über IVBB-externe SMTP-Server natürlich unterbinden muss. Davon ist hoffentlich auszugehen?

Bei Punkt 2 kommt die Frage ins Spiel, wie die Schad-SW überhaupt die ausgehenden Mails konstruiert hat - mit oder ohne Nutzung bzw. steuernde Manipulation von Outlook? Wenn letzteres: Wieso war/ist das überhaupt möglich und zugelassen? Und wieso wird überhaupt ein so anfälliger und durch Dritt-Software unter Windows manipulierbarer Mailclient wie Outlook in einem Netz mit hohen Sicherheitsbedarfen eingesetzt?

Falls die Schad-Software ihre Mails aber autonom verfasst hat: Wieso und wie konnte sie interne Signatur-Schlüssel erfassen? Oder werden im IVBB gar keine internen Signaturen zur Authentizitätsfeststellung der Verfasser vor dem Versand verwendet?

Punkt 4 ist fundamental, aber in der Praxis ggf. problematisch. Aber daran hängt doch irgendwie alles! Das Thema muss sich doch jemand bereits gründlich durchdacht haben - zumindest beim BSI. Ein gestückelter Datenabfluss über versteckte Nachrichten in Texten und Multimedia-Dateien ist doch ein Grund-Risiko, das sich zur Behandlung durch technische Maßnahmen geradezu aufdrängt. Erst recht, wenn man schon richtigerweise ein Verbot verschlüsselter Verbindungen nach außen gegenüber Mitarbeitern durchsetzt, um ausgetauschte Inhalte kontrollieren zu können.

Punkt 5 ist ebenfalls fundamental. Mailversand zu x-beliebigen ungeprüften Empfangsadressen in der Welt erscheint irgendwie als ein "No Go". Dass es in diesem Kontext nicht reicht zu prüfen, ob es zu einer Mailadresse auch schon mal einen Eingang gab, liegt auf der Hand. Die Gültigkeit einer Adressaten-Adresse muss sich an viel mehr Kriterien festmachen.

An dieser Stelle schließt sich eine weitere interessante Unterfrage an: War die Zieladresse vielleicht gar eine bekannte? Wenn ja, dann würde das bedeuten, dass auch die dortigen Systeme unter Kontrolle von Angreifern liegen und der Hack insgesamt viel größere Ausmaße hat als bislang gedacht.

Zusammenfassend müssen sich die Betreiber des IVBB folgende Fragen gefallen lassen :

  • Wie konnten Mails mit kritischen Inhalten überhaupt an den Angreifer versandt werden? Welche Lücken wurden da ausgenutzt? Sind diese Lücken ggf. von allgemeinem öffentlichen Interesse, weil sie mit Schwachpunkten der SW Outlook und/oder bestimmter Mailserver zu tun haben?
  • Wieso und wie haben andere befreundete Geheimdienste das mitbekommen? Waren die in der Lage die Mails abzufangen und die Kritikalität der Inhalte zu erkennen? Wieso? Und wieso die IVBB-Betreiber nicht?
  • Im Kontext von E-Geovernment in Deutschland tauchen regelmäßig die Themen "verschlüsselnde OSCI-Infrastruktur" (s. Wikipeadia zu Online-Services-Computer-Interface), "Virtuelle Poststelle des Bundes", "Governikus-Server" (https://www.governikus.de/anwendung-des-it-planungsrates/faqs-zur-anwendung-governikus/ und Governikus-Portfolioueberblick-Juni2017-Einzelseiten.pdf) u.a. in der Funktion als sichere Mail-Gateways ins Internet auf. Wie passen die offenbar vorhandenen Lücken und Defizite eigentlich damit zusammen?

Bzgl. des letzten Punkts ist auch interessant, dass 2017 Sicherheitslücken im OSCI-Transport-Protokoll festgestellt wurden.

Es sollte nun hinreichend klar geworden sein, dass es beim Bundeshack nicht allein um Schwächen von Outlook geht.

Nachtrag 23.03.2018:
Zwei Nachrichten passen gut zum Kern der obigen Ausführungen:
http://www.sueddeutsche.de/digital/attacke-auf-auswaertiges-amt-die-geschichte-eines-cyber-angriffs-1.3917502
Tja, irgendwie peinlich, dass ein ausländischer Nachrichtendienst verdächtige Mails aus dem eigenen Netz entdeckt. Dass einer eigenen Überwachung gesetzliche Hindernisse im Wege stehen könnten, dürfte wohl bei Scans nach selbst versandten Mails, eigenen IP-Adressen und zugehörigen Mustern kein Argument sein.

Bzgl. des Bezugs zu proprietärer Software ist folgender Artikel interessant:
https://www.heise.de/ix/meldung/Bund-will-Windows-10-ueber-Bundesclient-sicher-nutzen-koennen-3907088.html
Ich finde es beunruhigend, wenn man Desktop-Systeme von Spezialkräften aus Sicherheitsgründen so hinbiegen lassen muss, dass sie für die Verwaltung geeignete sind und eine Überwachung von Datenströmen zwischen Clients und Servern (s.o.) überhaupt erlauben.

Im nächsten Beitrag befasse ich mich ein wenig mit der Frage, ob ein Standard-Arbeitsplatz, bei dem Mail, Dateibearbeitung, Internet-Browsing durch Programme einer Desktop-Umgebung abgewickelt werden, überhaupt noch zeitgemäß und höchsten Sicherheitsanforderungen in Behörden angemessen ist.