© photocase.com

Dual-Boot- oder virtualisierte Linux-Windows-Systeme liefern Admins einigen Anlass, auf ein NTFS-Volume zugreifen zu wollen. Ein anderer Grund kann viel prekärer sein: Der Datenträger eines per Angriff oder Virus kompromittierten Windows-Systems ist mit forensischen Methoden zu untersuchen.

Daten mit einem Windows-Rechner austauschen heißt für ein Linux-System oft, von NTFS-Partitionen lesen zu müssen und darauf zu schreiben. Zwar ist NTFS ein Anhängsel des mit den bekannten Nachteilen behafteten Windows, aber auch ein modernes Dateisystem und damit reichlich komplex. Für die gestellte Aufgabe braucht der Admin darum ein gerüttelt Maß an Wissen, um die Möglichkeiten zu nutzen, mit Linux auf NTFS-Dateisysteme zuzugreifen.

Ein anderes Szenario ist die forensische Analyse, und hierfür ist Linux exzellent geeignet. Bezeichnenderweise ist die beste zurzeit erhältliche – natürlich inoffizielle NTFS-Dokumentation – in der Linux-Community entstanden, nämlich im Rahmen des Linux-NTFS-Projekts [1]. Dieser Artikel beschreibt die Utilities des Ntfsprogs-Pakets aus dem erwähnten Linux-NTFS-Projekt, zudem die Analyse per Sleuthkit von Brian Carrier [2], der auch ein hervorragendes Buch zur Dateisystem-Forensik geschrieben hat [3], sowie die Unterstützung, die der Linux-Kernel selbst bereithält.

Vieles ist vertraut

Das von Microsoft entwickelte New Technology File System (NTFS) ist das Standard-Dateisystem für Windows NT, Windows XP und Windows Server 2003. Primär entwickelt Microsoft NTFS als natives Dateisystem für alle Windows-Varianten weiter. Die seit Windows XP aktuelle Version von NTFS ist 3.1, auf sie bezieht sich dieser Artikel. Das Überleben des konzeptionell veralteten FAT-Dateisystems sichern nur noch mobile Geräte und Speicherkarten. Aber auch für den Datenaustausch spielt es eine gewisse Rolle.

NTFS ist viel komplexer als FAT und besitzt eine umfangreiche Sammlung an Features. An mancher Stelle spiegelt sich in den NTFS-Konzepten die Windows-Semantik wider, die denkbar anders ist als die Posix-Semantik der Unix-Welt. Das einfache Mounten eines NTFS-Dateisystem macht nicht annähernd alle Merkmale des Dateisystems zugänglich und ist zudem mit einer Vieldeutigkeit belegt, die dessen Nutzbarkeit für ein Unix-System ein wenig erschwert.

Andererseits weist NTFS durchaus Gemeinsamkeiten mit modernen Linux-Dateisystemen auf: Es ist ein Journaled Filesystem, es versteht jede Metadaten-Operationen also als Transaktion. Sehr wichtige Dateisystem-Metainformationen wie der Superblock (von Microsoft als Bootsektor bezeichnet) oder die im Folgenden besprochene Master File Table sind redundant gespeichert, um ein gewisses Maß an Wiederherstellbarkeit zu bieten. Im Gegensatz zu den FAT-Varianten verfügt NTFS über Besitzer und Zugriffskontrolllisten (ACL), die semantisch besser zum Windows-Sicherheitsmodell passen als zur Unix-Welt.

Cluster nach Windows-Art

Wenn im Windows-Jargon von einem Cluster die Rede ist, dann ist ein logischer Block gemeint, also die elementare Allokierungseinheit, deren Größe je nach zugrunde liegendem Volume zwischen 512 Byte und 64 KByte schwankt. Per se legt Windows allerdings Dateisysteme mit maximal 4 KByte Blockgröße an. Als reinrassiges 64-Bit-Dateisystem spezifiziert NTFS maximale Datei- und Dateisystemgrößen jenseits aller momentanen Notwendigkeiten.

Da aber selbst neue Implementierungen nur die untersten 32 Bits zur Adressierung verwenden, beträgt das Limit für das Dateisystem knapp 256 Terabyte, die maximale Dateigröße rund 16 Terabyte. Ein NTFS-Volume vermag 232-1 Dateien aufzunehmen [4]. NTFS beherrscht wie die Unix-Dateisysteme der neueren Generation (XFS, JFS und Reiser4) eine Extent-basierte Adressierung von Dateien. Ein Extent ist hier eine Menge aufeinander folgender logischer Blöcke, im Windows-Jargon Cluster Run genannt.

Die Mutter aller Tabellen

Das Herz der NTFS-Dateisystemstruktur ist die Master File Table (MFT). Sie ist eine geordnete Liste von Einträgen für sämtliche im Dateisystem enthaltenen Dateien und mit der Inode Allocation Map eines Unix-Dateisystems vergleichbar, speichert allerdings weitaus mehr Informationen. Jeder Datei-Eintrag (in Microsoft-Speak File Record) besitzt bei einem mit Windows angelegten NTFS-Dateisystem die feste Größe von 1 KByte, unabhängig von der Clustergröße. Theoretisch könnte diese Größe auch eine andere sein, der Wert ist im Bootsektor gespeichert.

Das Unix-Äquivalent zum File Record sind Inodes, nur dass der Inode nicht den Dateinamen trägt, was Hardlinks dort durch einfache Indirektion mehrerer Verzeichniseinträge auf denselben Inode möglich macht. Bei NTFS sind Hard- und Softlinks nur mit etwas komplizierteren Methoden möglich.

NTFS führt ironischerweise das aus der Unix-Welt stammende Konzept “Alles ist eine Datei” konsequenter zu Ende als viele Unix-Dateisysteme selbst. So listet die MFT sämtliche das Dateisystem selbst bestimmenden Metadatenstrukturen als Dateien an fester Position. Deren Namen beginnen mit einer Ausnahme stets mit einem Dollarzeichen. Sogar die MFT selbst besitzt einen eigenen, selbstbezüglichen Eintrag, nämlich Eintrag Nummer 0 mit dem Namen ». Tabelle 1 listet die wichtigsten MFT-Metadaten der MFT auf.

Beim Mounten eines NTFS-Dateisystems – unter Windows wie unter Linux – muss der NTFS-Treiber wissen, wo sich der Startcluster der MFT in dem Volume befindet. Diese Information holt er sich ab dem ersten Sektor (Nummer 0 in Computer-üblicher Nummerierung), dem 8 KByte großen Superblock oder Bootsektor des Volume. Für den existiert wiederum ein MFT-Eintrag » (siehe Tabelle 1). Neben den Dateisystem-Metadateninformationen, die allesamt in Sektor 0 liegen, enthält der Bootsektor auch Bootcode, der ein Windows-System zum Hochfahren ermächtigt.

Den Inhalt des Superblocks kann beispielsweise das Sleuthkit-Kommando »fsstat« auslesen, zu besichtigen in Listing 1. Interessant ist in Zeile 12 der Verweis auf die Datei », die ab Cluster Nummer 4193965 beginnt. Dahinter verbirgt sich eine Sicherheitskopie der ersten vier Einträge der Master File Table, » selbst ist Eintrag Nummer 1 in der MFT (siehe Tabelle 1). Zeile 15 listet die Anzahl der Datei-Einträge.

01 FILE SYSTEM INFORMATION
02 --------------------------------------
03 File System Type: NTFS
04 Volume Serial Number: 0EF0A0D6F0A0C4F5
05 OEM Name: NTFS
06 Volume Name: System
07 Version: Windows XP
08 
09 METADATA INFORMATION
10 --------------------------------------
11 First Cluster of MFT: 786432
12 First Cluster of MFT Mirror: 4193965
13 Size of MFT Entries: 1024 bytes
14 Size of Index Records: 4096 bytes
15 Range: 0 - 131591
16 Root Directory: 5
17 
18 CONTENT INFORMATION
19 --------------------------------------
20 Sector Size: 512
21 Cluster Size: 4096
22 Total Cluster Range: 0 - 12209390
23 Total Sector Range: 0 - 97675127

Viele Attribute

Zwar ist alles eine Datei, aber eine Datei ist bei NTFS etwas ganz anderes als bei Unix-Dateisystemen. Im Kern ist eine NTFS-Datei eine Aneinanderreihung von Attributen. Neben dem wichtigsten, dem Datei-Inhalt (genauer dem Wert des »-Attributs des unbenannten Stream), gibt es weitere Attribute, zum Beispiel Dateiname, Besitzer, Zugriffszeiten und andere. Tabelle 2 gibt einen Überblick über die Standard-Attribute eines MFT-Eintrags mit ihren Default-Typen. NTFS bietet im Übrigen sogar die Möglichkeit, die Attributtypen zu ändern. Abbildung 1 zeigt die Struktur eines einfachen MFT-Eintrags.

Abbildung 1: Struktur eines einfachen MFT-Eintrags. Eine NTFS-Datei ist eine Aneinanderreihung von Attributen.

Wenn die Daten eines Attributs vollständig in den MFT-Eintrag hineinpassen, nennt man das Attribut resident. Andernfalls verbleibt lediglich der Attributheader im MFT-Eintrag selbst, samt Referenz auf den Speicherort der Attributdaten im Dateisystem, also der so genannten Extent-Tabelle oder Run List. Dann heißt das Attribut non-resident. Einige Attribute, etwa » oder das weiter unten behandelte Attribut », müssen stets resident sein. Die »-Attribute einer Datei hingegen sind häufig nicht resident, da die mittlere Dateigröße auf den meisten Systemen größer als 1 KByte ausfällt.

Auch Unix-Dateisysteme wie XFS oder Reiser packen den Inhalt kleiner Dateien in den Inode selbst und handeln somit resident. Insbesondere Reiser begründet damit seine gute Performance im Falle sehr vieler kleiner Dateien. XFS speichert zudem die erweiterten Attribute für ACLs oder SE-Linux-Security-Labels in den Inode, wenn das möglich ist.

In dem seltenen Fall, dass selbst bei konsequenter Verwendung nicht residenter Attribute der MFT-Eintrag nicht mehr ausreicht, um alle Attributheader aufzunehmen, allokiert Windows einen zweiten MFT-Eintrag, auf den der Haupteintrag (der Base Entry) verweist.

NTFS-Attribute besitzen, je nach Typ, zusätzlich noch einen Namen und heißen dann benannte Attribute (Named Attributes). Bekanntestes Gegenbeispiel ist das namenlose »-Attribut, wenn es das einzige einer Datei ist. Alle weiteren »-Attribute jedoch, die dann jene unter NTFS so einzigartigen Alternate Data Streams (ADS) realisieren, müssen einen Namen haben. Das Attribut », das die Schlüsselinformationen für das Encrypted File System (EFS) beinhaltet, heißt ebenfalls ».

Standardinformation und Datei-Eigenschaften

Zu den wichtigsten Attributen gehört » (siehe Tabelle 3). Es speichert neben Besitz- und Security-Informationen die vier unter Windows üblichen Zeitstempel: den Zeitpunkt der Erzeugung (Creation Time), den der letzten Änderung (File Altered Time), die letzte Änderung der Metadaten (MFT Altered Time) und den des letzten Zugriffs (File Accessed Time). Für den ersten Zeitstempel kennt Posix keine Entsprechung, für die anderen sind die Modification Time (Mtime), die Change Time (Ctime) und die Access Time (Atime) die Unix-Äquivalente.

Daneben speichert » die Datei-Flags, die der Windows-Explorer verwirrenderweise als Datei-Attribute ausweist. Tabelle 4 listet alle Flags auf. Da sie in den Attributheadern ebenfalls existieren, kann NTFS die Flags Sparse, Compressed und Encrypted für jedes Attribut sogar einzeln setzen. Die korrespondierenden Flags in » weisen dann lediglich darauf hin, dass es in diesem MFT-Eintrag überhaupt Attribute mit diesen Flags gibt.

Im Prinzip gestattet es das NTFS-Layout demnach, auch die Datei-Metainformationen wie Dateinamen oder Zeitstempel zu verschlüsseln. Windows macht hiervon jedoch keinen Gebrauch. Diese Flags sind nur für die »-Attribute, also den eigentlichen Datei-Inhalt, von Bedeutung.

Was ist ein Name?

Das fragt sich Julia in Shakespeares Drama. Bei NTFS entpuppen sich Bedeutung und Benutzung des facettenreichen Attributs » als wahre Wissenschaft. Es bildet darüber hinaus ein Paradebeispiel dafür, wie NTFS einige Metainformationen mehrfach speichert – eine Redundanz, die zwar einen gewissen Performance-Schwung bringt, aber Inkonsistenzen im Dateisystem durchaus begünstigt. Hier bietet es sich an zu klären, wie ein Verzeichnis in NTFS überhaupt funktioniert.

Ein spezielles Flag sowohl im Header des MFT-Eintrags als auch in dem Attribut » kennzeichnen es als Verzeichnis. Im Wesentlichen ist auch bei NTFS ein Verzeichnis eine Tabelle von Dateiname-Inode-Nummer-Paaren. (Die Inode-Nummer ist wie beschrieben die MFT-Referenznummer, zumindest in semantischer Sicht.) Diese Tabelle umfasst aber, wie auch in modernen Unix-Dateisystemen, nicht einfach nur eine ungeordnete Liste, sondern ist auf der Speicherschicht als Baum organisiert.

Für Spezialisten der Informatik-Baumkunde: Die de facto offizielle technische Dokumentation von Microsoft [5] spricht zwar von B+-Bäumen als spezieller Struktur. Anhand der Beschreibung wird jedoch klar, dass dies nicht der Fall ist – es handelt sich um einfache B-Bäume, in denen nicht nur die Blattknoten die eigentlichen Daten halten, sondern auch die internen.

NTFS realisiert die Baumstruktur über die beiden Meta-Attribute » und », die andere Attribute aufnehmen und in einer Baumstruktur kapseln. Das Dateisystem macht von den zwei Meta-Attributen regen Gebrauch und verwendet sie nicht nur, um Verzeichnisinhalte zu indizieren, sondern auch für Security-Informationen, für Listen aller unten beschriebenen Reparsepoints und anderes. Das Schema in Abbildung 2 zeigt, wie ein Verzeichnis implementiert ist.

Abbildung 2: NTFS-Implementierung eines Verzeichnisses. Ein spezielles Flag sowohl im Header des MFT-Eintrags als auch im Attribut »$FILE_NAME« kennzeichnen es als Verzeichnis.

Drei Namensräume

Für alles Weitere ist die exakte Baumstruktur aber wenig wichtig; relevant ist die Tatsache, dass in einem solchen Verzeichnis ein und dieselbe Datei im Allgemeinen mehrere Verweise besitzt – den Hardlinks unter Unix nicht unähnlich -, nämlich für jeden Windows-Namensraum einen. Abbildung 3 zeigt die mengentheoretischen Zusammenhänge der drei möglichen Namensräume in einer Art Venn-Diagramm.

Abbildung 3: Die drei unter Windows darstellbaren Namensräume.

Als Beispiel betrachtet Listing 2 das Root-Verzeichnis einer typischen Windows-Installation mit dem »ntfsls«-Kommando aus dem Paket Ntfsprogs. Die verwendeten Optionen »-lis« fördern neben der Inode-Nummer, der Größe und der Creation Time der Dateien auch den Dateinamen des Win32-Namensraums zutage. Die Option »x« in Listing 3 zeigt statt der Win32- die DOS-Namen an.

01 4       2560 May 20 18:50 $AttrDef
02    8          0 May 20 18:50 $BadClus
03    6    1526176 May 20 18:50 $Bitmap
04    7       8192 May 20 18:50 $Boot
05   11          0 May 20 18:50 $Extend
06    2   67108864 May 20 18:50 $LogFile
07    0  134750208 May 20 18:50 $MFT
08    1       4096 May 20 18:50 $MFTMirr
09    9          0 May 20 18:50 $Secure
10   10     131072 May 20 18:50 $UpCase
11    3          0 May 20 18:50 $Volume
12 6957          0 May 20 18:23 AUTOEXEC.BAT
13 3253        211 May 20 18:54 boot.ini
14 3212       4952 May 20 18:54 bootfont.bin
15 5731          0 May 20 18:23 CONFIG.SYS
16 3259          0 May 20 17:55 Dokumente und Einstellungen
17  151 1073311744 May 29 20:04 hiberfil.sys

01 [...]
02 5731          0 May 20 18:23 CONFIG.SYS
03 3259          0 May 20 17:55 DOKUME~1
04  151 1073311744 May 29 20:04 hiberfil.sys

Die von der Posix-Kompatibilität geforderten Hardlinks und die drei Namensräume von Windows sind für NTFS das Gleiche: In beiden Fällen enthalten die MFT-Einträge mehrere Attribute » und für jedes von ihnen existiert irgendwo im Dateisystem auch ein Index-Knoten in der Baumstruktur eines Verzeichnisses. Das liefert ein weiteres Beispiel für die Mehrfachspeicherung der gleichen Information an unterschiedlichen Stellen.

Der Unterschied: Die »-Attribute, die zu den einzelnen Namensräumen gehören, verweisen mit ihrer Datenstruktur stets auf dieselbe MFT-Referenzadresse des Elternverzeichnisses. Dies belegt auch Listing 4, das als Beispiel das Verzeichnis »Dokumente und Einstellungen« aus den Listings 2 und 3 untersucht. Bei echten Hardlinks muss dies nicht der Fall sein, wie der Vergleich mit Listing 5 zeigt.

01 Number of hard links:       2
02 Dumping attribute $FILE_NAME (0x30)
03    File Name:             'DOKUME~1'
04    File Name Length:      8
05    Namespace:             DOS
06    Attribute instance:    3
07    Allocated File Size:   0
08    Real File Size:        0
09    Parent directory:      5
10    File attributes:       DIRECTORY
11    File Creation Time:    Thu May 20 17:55:51 2004
12    File Altered Time:     Thu May 20 17:55:51 2004
13    MFT Changed Time:      Thu May 20 17:55:51 2004
14    Last Accessed Time:    Thu May 20 17:55:51 2004
15 Dumping attribute $FILE_NAME (0x30)
16    File Name:             'Dokumente und Einstellungen'
17    File Name Length:      27
18    Namespace:             Win32
19    Attribute instance:    2
20    Allocated File Size:   0
21    Real File Size:        0
22    Parent directory:      5
23    File attributes:       DIRECTORY
24    File Creation Time:    Thu May 20 17:55:51 2004
25    File Altered Time:     Thu May 20 17:55:51 2004
26    MFT Changed Time:      Thu May 20 17:55:51 2004
27    Last Accessed Time:    Thu May 20 17:55:51 2004

01 Number of hard links:       2
02 Dumping attribute $FILE_NAME (0x30)
03    File Name:             'this_is_a_hard_link'
04    File Name Length:      19
05    Namespace:             POSIX
06    Attribute instance:    4
07    Allocated File Size:   4096
08    Real File Size:        4981
09    Parent directory:      1731
10    File attributes:       ARCHIVE COMPRESSED
11    File Creation Time:    Wed Jun  7 17:55:11 2006
12    File Altered Time:     Wed Jul 20 21:07:00 2005
13    MFT Changed Time:      Fri Aug 26 09:18:47 2005
14    Last Accessed Time:    Wed Jun  7 17:55:11 2006
15 Dumping attribute $FILE_NAME (0x30)
16    File Name:             'Readme.txt'
17    File Name Length:      10
18    Namespace:             Win32 & DOS
19    Attribute instance:    2
20    Allocated File Size:   0
21    Real File Size:        0
22    Parent directory:      1914
23    File attributes:       ARCHIVE
24    File Creation Time:    Wed Jun  7 17:55:11 2006
25    File Altered Time:     Wed Jun  7 17:55:11 2006
26    MFT Changed Time:      Wed Jun  7 17:55:11 2006
27    Last Accessed Time:    Wed Jun  7 17:55:11 2006

Das Sleuthkit-Kommandos »fls« listet sogar gelöschte Verzeichniseinträge. Was in Listing 6 zu sehen ist, sind die Reste der ständigen Umorganisation der Baumstrukturen des Root-Verzeichnisses. Für die aufgeführten Verzeichniseinträge hat der NTFS-Treiber offenbar mehrmals einen Index-Knoten erzeugt und einen anderen dafür gelöscht. Anhand dieser Informationen kann ein Forensiker Löschvorgänge zurückverfolgen.

01 d/d * 86315-144-1(realloc):  gs
02 r/r * 3216-128-3(realloc):   NTDETECT.COM
03 r/r * 3211-128-3(realloc):   ntldr
04 d/d * 9625-144-7(realloc):   NVIDIA Display Driver
05 r/r * 27-128-1(realloc):     pagefile.sys
06 d/d * 85512-144-5:           pc-bib
07 d/d * 87392-144-1(realloc):  ppwork
08 d/d * 41620-144-1(realloc):  Program Files
09 d/d * 3662-144-7(realloc):   Programme
10 d/d * 10928-144-5(realloc):  RECYCLER
11 d/d * 9373-144-6(realloc):   System Volume Information
12 d/d * 28-144-7(realloc):     WINDOWS
13 d/d * 28-144-7(realloc):     WINDOWS
14 d/- * 0:                     WINDOWS

Verkettungen

NTFS kennt neben Hard- auch Softlinks. Damit sind nicht die unter Windows üblichen Verknüpfungen (LNK-Dateien, die im Englischen ebenfalls Links heißen) gemeint. Dies sind gewöhnliche Dateien, die Windows auf Applikationsebene als eine Art symbolische Links interpretiert. Echte Softlinks auf Verzeichnisse dagegen heißen bei Windows Junctions. Die NTFS-Struktur hinter Softlinks sind die so genannten Reparsepoints.

Hat eine Datei das entsprechende Flag in den Attributen » und » gesetzt, liefert als weiteres Attribut » Informationen über das Ziel des Links. Da Reparsepoints nicht nur den Mechanismus für Junctions darstellen, sondern als universelles Instrument auch für die Implementierung von Mountpoints, für das Distributed Filesystem (DFS), für Hierarchical Storage Management (HSM) und Weiteres dienen, geben im Attribut » insgesamt 4 Bytes Aufschluss über deren Verwendung.

Listing 7 zeigt das Beispiel einer Junction als Auszug und Listing 8 die Informationen zu einem symbolischen Link auf eine echte Datei. Offensichtlich ist es den Ntfsprogs leider unmöglich, den Unterschied zwischen beiden zu erkennen. Es fehlt die Auswertung des »-Attributs. Doch sowohl das »ntfscat«-Kommando der Ntfsprogs als auch das »icat«-Tool aus dem Sleuthkit helfen weiter, wenn auch der Admin hierzu einen Hex-Editor wie in Listing 9 und 10 bemühen muss. Den gleichen Output erhält er mit:

icat -f ntfs /dev/hdg2 985-192 | hexdump -C

Das Ziel des Links, fett markiert, ist ab Byte-Offset 16 des Attributs ersichtlich. Im Listing 9 handelt es sich also um den Softlink auf die Datei »E:NVIDIAWin2KXP77.77setup.skin«, im Listing 10 um eine Junction auf das Verzeichnis »E:Anwendungsdaten«.

01 Dumping Inode #985
02 Dumping attribute $STANDARD_INFORMATION (0x10)
03    File attributes:       REPARSE_POINT COMPRESSED
04 Dumping attribute $FILE_NAME (0x30)
05    File Name:             'this_is_a_soft_link'
06    File attributes:       COMPRESSED DIRECTORY
07 Dumping attribute $REPARSE_POINT/$SYMBOLIC_LINK (0xC0)

01 Dumping Inode #982
02 Dumping attribute $STANDARD_INFORMATION (0x10)
03    File attributes:       REPARSE_POINT
04 Dumping attribute $FILE_NAME (0x30)
05    File Name:             'this_is_a_junction'
06    File attributes:       DIRECTORY
07 Dumping attribute $REPARSE_POINT/$SYMBOLIC_LINK (0xC0)

00000000  03 00 00 a0 58 00 00 00  00 00 4c 00 4e 00 00 00  |....X.....L.N...|
00000010  5c 00 3f 00 3f 00 5c 00  45 00 3a 00 5c 00 4e 00  |.?.?..E.:..N.|
00000020  56 00 49 00 44 00 49 00  41 00 5c 00 57 00 69 00  |V.I.D.I.A..W.i.|
00000030  6e 00 32 00 4b 00 58 00  50 00 5c 00 37 00 37 00  |n.2.K.X.P..7.7.|
00000040  2e 00 37 00 37 00 5c 00  73 00 65 00 74 00 75 00  |..7.7..s.e.t.u.|
00000050  70 00 2e 00 73 00 6b 00  69 00 6e 00 00 00 00 00  |p...s.k.i.n.....|

00000000  03 00 00 a0 38 00 00 00  00 00 2c 00 2e 00 00 00  |....8.....,.....|
00000010  5c 00 3f 00 3f 00 5c 00  45 00 3a 00 5c 00 41 00  |.?.?..E.:..A.|
00000020  6e 00 77 00 65 00 6e 00  64 00 75 00 6e 00 67 00  |n.w.e.n.d.u.n.g.|
00000030  73 00 64 00 61 00 74 00  65 00 6e 00 00 00 00 00  |s.d.a.t.e.n.....|

Ein NTFS-Dateisystem protokolliert im Metafile » alle im Dateisystem vorhandenen Reparsepoints. Das Metafile führt mit Hilfe der beschriebenen Meta-Attribute » und » einen Index über alle MFT-Referenznummern von vorhandenen Reparsepoints. Zusätzlich gibt es in einem anderen »-Attribut der Metadatei ».« eine Liste aller über Mountpoints eingehängten Volumes. Die Liste heißt schlicht ».

Dieses »-Attribut entsteht nur beim Mounten eines Volume und wird beim Abhängen wieder gelöscht. Bei einer Post-mortem-Analyse oder dem Mounten eines NTFS-Dateisystems unter Linux ist dieser spezielle Alternate Data Stream also nicht vorhanden.

Lesen und schreiben

Der Inhalt einer NTFS-Datei ist mitunter gar nicht eindeutig zu bestimmen. Wie angesprochen kann eine Datei mehrere »-Attribute besitzen, die die so genannten Alternate Data Streams realisieren. Die Streams verwendet Windows für die Datei-Zusatzinformationen zu Autor, Kategorie, Thema sowie andere, die es im Explorer-Fenster in der erweiterten Anzeige zeigt. Unter Linux kommt man auf die in Listing 11 demonstrierte Weise an diese Information.

01 Dumping Inode #374
02 [...]
03 Dumping attribute $FILE_NAME (0x30)
04    File Name:             'TESTDA~1.TVP'
05    File Name Length:      12
06    Namespace:             DOS
07 [...]
08 Dumping attribute $FILE_NAME (0x30)
09    File Name:             'Testdatei mit erweiterter Info.tvp'
10    File Name Length:      34
11    Namespace:             Win32
12 [...]
13 Dumping attribute $DATA (0x80) related info
14    Stream name:           unnamed
15    Attribute instance:    4
16    Flags:                 0x0000
17    Is resident?           No
18    Data size:             32846
19    Allocated size:        36864
20    Initialized size:      32846
21    Not Compressed
22 Dumping attribute $DATA (0x80) related info
23    Stream name:           'DocumentSummaryInformation'
24    Attribute instance:    5
25    Flags:                 0x0000
26    Is resident?           No
27    Data size:             128
28    Allocated size:        4096
29    Initialized size:      128
30    Not Compressed
31 Dumping attribute $DATA (0x80) related info
32    Stream name:           'SummaryInformation'
33    Attribute instance:    6
34    Flags:                 0x0000
35    Is resident?           No
36    Data size:             292
37    Allocated size:        4096
38    Initialized size:      292
39    Not Compressed
40 Dumping attribute $DATA (0x80) related info
41    Stream name:           '{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}'
42    Attribute instance:    7
43    Flags:                 0x0000
44    Is resident?           Yes
45    Data size:             0
46    Residence Flags:       0x00
47 End of inode reached

Offensichtlich benutzt NTFS dazu immerhin drei weitere benannte »-Attribute. Das Sleuthkit-Kommando »icat« zeigt die einzelnen Streams an (siehe Listings 12 und 13). Als Argument verwendet es »MFT-Referenznummer-Attributtyp-Attributinstanz«. Wer die Attributinstanz weglässt, erhält als Ausgabe den unbenannten Stream.

[...]
00000060  13 00 00 00 07 04 00 00  1e 00 00 00 0e 00 00 00  |................|
00000070  53 74 72 65 6e 67 20 67  65 68 65 69 6d 00 00 00  |Streng geheim...|

[...]
00000090  4f 6c 69 20 54 65 6e 6e  65 72 74 20 6f 64 65 72  |Oli Tennert oder|
000000a0  20 61 75 63 68 20 6e 69  63 68 74 00 1e 00 00 00  | auch nicht.....|
000000b0  1b 00 00 00 41 63 68 20  69 63 68 20 77 65 69 df  |....Ach ich wei.|
000000c0  20 61 75 63 68 20 6e 69  63 68 74 2e 2e 2e 00 00  | auch nicht.....|
000000d0  1e 00 00 00 0c 00 00 00  64 69 65 73 2c 20 6a 65  |........dies, je|
000000e0  6e 65 73 00 1e 00 00 00  18 00 00 00 6b 65 69 6e  |nes.........kein|
000000f0  20 62 65 73 6f 6e 64 65  72 65 72 20 42 65 74 72  | besonderer Betr|
00000100  65 66 66 00 1e 00 00 00  16 00 00 00 54 65 73 74  |eff.........Test|
00000110  64 61 74 65 69 20 6d 69  74 20 53 74 72 65 61 6d  |datei mit Stream|
00000120  73 00 00 00                                       |s...|

Das Kommando »ntfscp« kann in Dateien auf NTFS-Volumes schreiben, sofern sie existieren. Das Beispiel

ntfscp /dev/hdg2 /tmp/some_data Kopie von NVIDIA Display Driver/Readme.txt

überschreibt die vorhandene Datei »Readme.txt«. Ein Alternate Data Stream lässt sich mit Angabe des Stream-Namens folgendermaßen überschreiben:

ntfscp -N SummaryInformation /dev/hdg2 /tmp/some_data Kopie von NVIDIA Display Driver/Testdatei mit erweiterter Info.tvp

Was der Kernel kann – und was nicht

Das bisher Gesagte legt nahe, dass es keine einfache Abbildungsvorschrift von NTFS-Dateien oder gar -Dateisystemen in die Unix-Welt mit ihrer Posix-Semantik geben kann. Entsprechend vieldeutig gestalten sich die Möglichkeiten, unter Linux ein NTFS-Dateisystem zu mounten. Interessant ist vor allem, wie der Linux-Kernel beim Einhängen des Dateisystems mit Hard- und Softlinks, Zugriffsrechten, Zeitstempeln sowie mit Alternate Data Streams (ADS) umgeht. Folgendes Mount-Kommando liefert sogleich die Antwort auf einige der Fragen:

mount -t ntfs /dev/hdg2 /mnt

Das Listing eines der Unterverzeichnisse beweist, dass der NTFS-Treiber Hardlinks problemlos unterstützt:

# ls -il /mnt/NVIDIA/Win2KXP/77.77/
[...]
2069 -rw-------  2 root root    4981 2005-07-20 21:07 Readme.txt
2069 -rw-------  2 root root    4981 2005-07-20 21:07 this_is_a_hard_link

Es handelt sich hier um dieselbe Datei wie im obigen Beispiel. Mit Softlinks hat der Kernel aber seine Probleme. Die früheren Beispiele interpretiert er fälschlicherweise als leere Verzeichnisse, und zwar in beiden Fällen:

# ls -ail
[...]
380 drwx------   1 root root  4096 2006-06-10 20:59 Anwendungsdaten
982 drwx------   1 root root 0 2006-08-05 16:37 this_is_a_junction
# ls -ail this_is_a_junction/
[...]
982 drwx------  1 root root    02006-08-05 16:37 .
  5 drwx------  1 root root 4096 2006-08-05 16:37 ..

Eigentlich ist »this_is_a_junction« ein Softlink auf »Anwendungsdaten«, also eine Junction. Ebenso hier:

# ls -ali /mnt/NVIDIA/Win2KXP/77.77/
2076 -rw-------  2 root root   68593 2005-07-20 21:07 setup.skin
 985 drwx------  1 root root       02006-08-05 16:38 this_is_a_soft_link
# ls -ali /mnt/NVIDIA/Win2KXP/77.77/this_is_a_soft_link/
[...]
 985 drwx------  1 root     02006-08-05 16:38 .
1914 drwx------  1 root 36864 2006-08-05 16:38 ..

Jetzt erkennt der Kernel nicht einmal, dass das Ziel des Softlinks eine echte Datei ist. Mit symbolischen Links kann der NTFS-Treiber unter Linux also nichts anfangen.

Benutzer und Gruppen abbilden

Eine große Herausforderung bei der Handhabung eines NTFS-Dateisystems unter Linux ist auch das Sicherheitskonzept von Windows – nicht zuletzt wegen der persistenten Speicherung im NTFS-Dateisystem. Die numerischen IDs, die in einer Windows-Umgebung Benutzer und Gruppen identifizieren, sind unter Unix nämlich nicht ohne weiteres interpretierbar. Entsprechend ignorieren sowohl der Kernel als auch alle dem Autor bekannten User-Kommandos die in den Sicherheitsattributen einer NTFS-Datei vorhandenen Besitzer- und Zugriffsrechte-Informationen.

Das Mount-Kommando von eben ordnet alle Dateien einfach dem User »root« zu. Mit den Mount-Optionen »uid=« und »gid=« lassen sich die User ändern. Darüber hinaus gibt es die Optionen »dmask« und »fmask«, die die Zugriffsrechte für Verzeichnisse beziehungsweise Dateien regeln. Ihre Syntax entspricht der Unix-üblichen von »umask«.

Zeichen der Zeit und die Schlüssel-Misere

Bei den Zeitstempeln zeigen die »ls«-Standardoptionen »-t«, »-c« und »-u« wie bei nativen Linux-Dateisystemen die Modification Time (File Altered Time), die Change Time (MFT Changed Time) und die Access Time (Last Accessed Time) an. Für die Anzeige der Windows-spezifischen File Creation Time gibt es leider keine geeignete Option.

Neben der fehlenden Unterstützung für die Sicherheitsattribute von NTFS-Dateien gibt es im Linux-Kernel gegenwärtig keinen Support für die thematisch verwandten Quotas sowie für per Encrypted File System verschlüsselte Dateien. Letzteres ist ohne Zugriff auf die auch auf lokalen Windows-Maschinen rudimentär vorhandene PKI-Infrastruktur und die privaten Schlüssel der Anwender schon technisch unmöglich. Wie ein Linux-Benutzer mit Hilfe des Kommandos »ntfsdecrypt« trotzdem auf EFS-Dateien zugreifen kann, zeigt der Kasten “EFS-Dateien lesen”.

# ntfsls -lis -d /dev/hdg2
1070      0 Jun  7 17:53 Crypted_von_Admin
[...]
# ntfsls -lis -d /dev/hdg2 -p Crypted_von_Admin
1071  69632 Jun  7 17:53 beispiel.txt
[...]
# ntfsinfo -d /dev/hdg2 -i 1071
File attributes:     ARCHIVE ENCRYPTED

01 00000050  0d 0a 4e 56 49 44 49 41  20 44 69 73 70 6c 61 79  |..NVIDIA Display|
02 00000060  20 44 72 69 76 65 72 20  66 6f 72 20 57 69 6e 64  | Driver for Wind|
03 00000070  6f 77 73 20 32 30 30 30  2f 58 50 20 20 20 20 20  |ows 2000/XP     |
04 00000080  20 20 20 20 20 20 20 20  20 76 65 72 73 69 6f 6e  |         version|
05 00000090  20 37 37 2e 37 37 2c 20  30 37 2f 32 30 2f 32 30  | 77.77, 07/20/20|
06 000000a0  30 35 0d 0a 3d 3d 3d 3d  3d 3d 3d 3d 3d 3d 3d 3d  |05..============|

Das Lesen von komprimierten Dateien oder Sparsefiles ist kein Problem mehr, das Schreiben in eine solche hingegen schon. Überhaupt kann der NTFS-Treiber des Linux-Kernels keine neuen Dateien oder Verzeichnisse erzeugen, das Schreiben funktioniert nur in bestehende Dateien hinein. Offenbar ist die Unterstützung von ADS zurzeit noch nicht fertig implementiert.

Praxis: Partitionen klonen und sichern

Ein immens praktisches Tool aus dem Ntfsprogs-Paket ist Ntfsclone. Es sichert eine NTFS-Partition vollständig und ohne Verlust an Information in einer Imagedatei. So fertigt

# ntfsclone /dev/hdg1 -o /backup/winxp.img

ein Image an, das sich darüber hinaus auch noch per Loopback-Device mounten lässt, beispielsweise zum Zwecke eines Restore:

# mount -t ntfs -o loop /backup/winxp.img

Der große Vorteil dieser Art Imaging ist, dass es nur die allokierten Blöcke sichert. Es entspricht also dem Dump eines Unix-Dateisystems. Von der detaillierten Semantik eines NTFS-Dateisystems muss Ntfsclone ohnehin nichts wissen. Lücken von nicht allokierten Blöcken sichert es nicht mit, die entstehende Imagedatei ist ein Sparsefile.

Zum Sichern eines NTFS-Volume über das Netz empfiehlt es sich, ein spezielles Imageformat zu benutzen:

ilka2000:~ # ntfsclone --save-image --output - /dev/hdg1 | ssh backuphost '( cat > winxp.img )'

Das entstandene Image ist kein Sparsefile mehr, vielmehr kodiert Ntfsclone die nicht allokierten Blöcke auf spezielle Art. Dafür lässt sich die entstehende Datei problemlos mit Gzip oder Bzip 2 komprimieren, verschlüsseln oder übers Netzwerk streamen. Das Zurückspielen des Abbilds auf die ursprüngliche Partition erfolgt dann über das Kommando:

Backuphost:~ # cat winxp.img | ssh ilka2000'(ntfsclone --restore-image --overwrite/dev/hdg1 - )'

Ntfsresize vergrößert oder verkleinert ein NTFS-Dateisystem. Wie bei anderen Dateisystemen auch muss der Admin beim Vergrößern zuerst das betreffende Volume vergrößern, beim Verkleinern andersherum. Nach einem erfolgreichen Resizing setzt das Tool das Dirty-Flag des Dateisystems, was beim nächsten Windows-Start ein Konsistenzcheck via Chkdsk mit blauem Hintergrund erzwingt.

Fazit und Rundblick

Dieser Artikel stellte die Manipulations- und Zugriffsmöglichkeiten auf NTFS-Dateisysteme mit Hilfe des Linux-Kernels und der Userspace-Tools aus dem Ntfsprogs- und dem Forensik-Paket Sleuthkit vor. Wie zu lesen war, ist eine konflikt- und ambivalenzfreie Integration aufgrund der völlig anderen Windows-Semantik in die Linux-Welt nicht ohne weiteres möglich. Auf der anderen Seite kann ein Admin mit Linux-Mitteln sehr viele Informationen aus einem NTFS-Dateisystem extrahieren, teilweise sogar mehr als mit Windows selbst. Wer sich für weitere Details interessiert, findet sie in ausführlicher Darstellung in dem Buch von Brian Carrier [3].

Es sei nicht verschwiegen, dass es alternative Projekte zur NTFS-Unterstützung gibt. Zum einen das Captive-Projekt von Jan Kratochvil [7], das den Original-Windows-NTFS-Treiber »ntfs.sys« unter Linux per Wine betreibt, um vollen Schreib-Lese-Zugriff auf NTFS-Dateisysteme zu erhalten. Zum Einhängen im Userspace dient das mittlerweile im Vanilla-Kernel vorhandene Fuse-Modul. (Nebenbei: Auch die Ntfsprogs-Utilities unterstützen das Einhängen eines Dateisystems über Fuse per »ntfsmount«.) Zum anderen gibt es das lizenzkostenpflichtige und proprietäre Kernelmodul NTFS for Linux von Paragon [8], das relativ performant und stabil arbeitet [9], aber auch mit verschlüsselten Dateien nichts anzufangen weiß.

Ganz neu ist das Projekt Ntfs-3g von Szabolcs Szakacsits [10], das ebenfalls auf Fuse aufsetzt und umfassenden Schreib-Lese-Zugriff verspricht. Es versteht sich als Weiterentwicklung des »ntfsmount«-Kommandos und wartet nach eigenen Angaben mit einer besseren Performance auf als der Vorgänger. Ein schwer wiegender Nachteil ist die fehlende Portierung auf 64-Bit-Systeme. Auch für eine umfassende Bewertung ist Ntfs-3g noch zu neu und unausgereift – die FAQ-Sektion der Readme-Datei offeriert sehr viele offene Punkte. (jk)