Approfondimento sul Mount di Ubuntu

Inserito da denis frati il Dom, 04/20/2008 - 05:44

da www.denisfrati.it

Dopo aver scritto l’articolo sulla gestione delle partizioni con file system EXT3 da parte di Ubuntu ho pensato di approfondire il discorso anche verso le altre tipologie di file system, giusto per fugare eventuali dubbi.
Ho quindi preso un piccolo hard disk nel quale ho creato:
-NTFS (sdb1)
-FAT (sdb5)
-EXT2 (sdb6)
-EXT3 (sdb7)
-REISERFS (sdb8)

Ho quindi avviato il portatile con Helix v.1.9, collegato il box esterno contenente il disco via usb e calcolato gli hash md5 delle varie partizioni.
Quindi le ho montate in sola lettura, le ho smontate e ho ricalcolato gli hash md5.
Come c’era da aspettarsi erano tutti coincidenti a quelli calcolati prima del mount.

Ho scollegato il disco esterno ed ho avviato Ubuntu v.7.10, ho
disabilitato il mount automatico dei supporti rimovibili ed ho
collegato il disco esterno.
Dopo aver verificato che nessuna delle partizioni del disco esterno,riconosciuto come sdb, fosse stata montata, ho ricalcolato gli hash md5 verificando che erano identici a quelli calcolati su Helix.

Per ogni partizione ho svolto una prova molto semplice:
1- creazione punto di mount;
2- mount in read-only della partizione;
3- verifica della modalità di mount;
4- navigazione del file system;
5- umount della partizione;
6- verifica dell’avvenuta operazione;
7- calcolo dell’hash md5.

Come c’era da aspettarsi tutti gli hash coincidevano con quelli calcolati prima del mount.

Dopo aver scollegato il disco esterno ho abilita, attraverso “Preferenze>>Unità e supporti rimovibili”, il mount in automatico dei device rimovibili, senza tuttavia abilitare lo sfoglio dei supporti.
 

Dopo aver ricollegato il disco al portatile ho verificato come le partizioni fossero state montate:

/dev/sdb1 on /media/NTFS type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=1024)
/dev/sdb5 on /media/FAT32 type vfat (rw,nosuid,nodev,shortname=mixed,uid=1000,utf8,umask=077,usefree)
/dev/sdb6 on /media/EXT2 type ext2 (rw,nosuid,nodev)
/dev/sdb7 on /media/EXT3 type ext3 (rw,nosuid,nodev)
/dev/sdb8 on /media/disk-1 type reiserfs (rw,nosuid,nodev)

Tutte le partizioni erano state montate in scrittura.
Smontati tutti i device ho ricalcolato gli hash, verificando che le partizioni EXT* e la REISER avevano subito modifiche

nemo@nexus:~$ md5sum /dev/sdb1 /dev/sdb5 /dev/sdb6 /dev/sdb7 /dev/sdb8 /dev/sdb9
b1c728c4fed957ed14022821088c14ac /dev/sdb1
aaa04ae6f17c2186fff4a8c095ed3525 /dev/sdb5
fbb2584f88e17c5bf3b3e7f9d70690db /dev/sdb6 <<<<
d6af93bd9f305d66ce07b6851fcd0fb7 /dev/sdb7 <<<<
97f2b87a729427b91b383481660b082d /dev/sdb8 <<<<
5c695f0acb8d297d81c23cf5dc1e3d08 /dev/sdb9

Ricordando quanto visto nell’articolo sulla gestione delle partizioni con file system EXT3 da parte di Ubuntu sappiamo che nel superblock di EXT* i bytes ci forniscono i seguenti valori:

Byte range
44-47 Last mount time
48-51 Last write time
52-53 Current mount count
54-55 Maximum mount count
56-57 Signature (0xef53)
64-67 Last consistency check time

che ci consente di comprendere quali sono state le modifiche ai superblock, come evidenziati nelle immagini successive, dove superiormente vediamo il superblock prima del mount in rw, inferiormente dopo il mount):
 

in entrambi i casi notiamo che è stato modificato il time stamp dell’ultimo mount, dell’ultima scrittura ed il numero di mount.
Per quanto riguarda la partizione REISER (la cui struttura troviamo trattata qui) possiamo notare anche in essa alcune modifiche prima e dopo il mount (verificate dopo 3 mount differenti).
 

dove abbiamo questa struttura:

Byte range
00-04 Last flush ID
05-07 Unflushed offset
08-11 Mount ID

Come si può notare dopo il mount in scrittura, sebbene non si sia in alcun modo esplorato il file system, sono state apportate delle modifiche al “journal header” nei campi sopra citati. In particolare si nota immediatamente come Il Mount ID si incrementi di uno ad ogni montaggio.

Le partizioni FAT, NTFS ed HFS, come si noterà riguardando gli hash non hanno subito alcuna modifica.

La prova successiva si distingueva da quella appena svolta in quanto abbiamo impostato il sistema affinché avvenisse lo sfoglio delle partizioni al momento del mount.
Dopo aver smontato i device e verificato gli hash non vi sono state sorprese per quanto riguardava le partizioni EXT* e ReiserFS, che avevano riportato nuovamente le modifiche sopra descritte, come minimo.
L’hash della partizione FAT risultava essere cambiato in quanto lo sfoglio del file system aveva comportato la modifica dei tempi di accesso alla directory, quindi i bytes relativi ai MAC time sono stati modificati.
Questo non è avvenuto nella partizione NTFS. Il perchè è facilmente rilevabile dall’analisi delle modalità di mount

/dev/sdb1 on /media/NTFS type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=1024)
/dev/sdb5 on /media/FAT32 type vfat (rw,nosuid,nodev,shortname=mixed,uid=1000,utf8,umask=077,usefree)
/dev/sdb6 on /media/EXT2 type ext2 (rw,nosuid,nodev)
/dev/sdb7 on /media/EXT3 type ext3 (rw,nosuid,nodev)
/dev/sdb8 on /media/disk-1 type reiserfs (rw,nosuid,nodev)

si nota infatti che la partizione NTFS è l’unica che viene montata di default con l’opzione noatime che consente appunto di mantenere invariati i MAC time.

Sfortunatamente la mia competenza di amministratore linux va ancora molto migliorata ed io sono riuscito a comprendere in quale file di configurazione le modalità per il mount automatico andassero impostate.
Nell’ipotesi di lavorare su una forensics workstation dotata di sistema operativo Linux, potrebbe infatti essere utile modificare tali impostazioni di default, ottimizzandole in modo da limitare i danni nel caso non si sia controllato le opzioni per il mount automatico (verificando che sia disabilitato) prima di attaccare il disco sospetto.
Questo articolo, come già il precedente, non è un invito a operare senza l’utilizzo di write-blocker hardware, ma pone anzi l’accento sulle problematiche e modifiche alle quali si andrà incontro nel caso, decidendo di non dotarsi di tali dispositivi, si sia operato con superficialità, senza verificare preventivamente le modalità di mount, o un errore di sistema sia intervenuto rendendole inutili.