Recuperare Dati da Volume Tier QNAP con Metadati LVM Thin Danneggiati

Introduzione: QNAP Tier e Thin Provisioning

I QNAP implementano di Default una gestione "virtuosa" dei volumi logici. Se collegassimo un Hard Drive estratto da un NAS QNAP ad una qualsiasi distribuzione Linux Noteremmo, che ci è preclusa la possibilità di visionare i dati ed importare correttamente il volume.

La particolarità dei Volumi creati dai QTS è l'implenentazione dei Tier e di una organizzazione dei blocchi basata su Thin Provisioning, una tipologia di scrittura in cui i blocchi sono coalescenti ed la mappatura relativa al volume finale gestita da un Volume Dedicato.

Il Volume Metadata configurato su QNAP

Nella maggior parte dei NAS QNAP, i metadati LVM, che definiscono l'organizzazione dei volumi logici, la distribuzione dei blocchi e gli snapshots, sono localizzati in un volume specifico essenziale per la lettura ed il ripristino dei file.

Essendo tale volume oggetto di intenso IO, è possibile che i settori sui quali insiste possano degradarsi precocemente o incontrare errori di incoerenza e risultare essere illeggibile o corrotto.

Se abbiamo configurato il QNAP con un volume Metadati è possibile che una semplice corruzione di un settore possa provocare la perdita definitiva di tutti i volumi logici ed i dati presenti sul NAS, in quanto non esistono copie o procedure di ridondanza per i Volumi Medatata.

Corruzione CRC di un Volume Installato su RAID 6

Nei Raid 6 è molto comune rilevare che la parità di tipo Q presente dei blocchi Reed Solomon non sia consolidata o contenga degli errori.

Se avvenisse un minimo errore di consolidazione del Raid 6 e dovessimo accedere ad un raid degradato in seguito al fallimento di unità disco è molto probabile che i CRC presenti nel volume contenente i metadati Thin non siano validi.

Nei casi in cui si presenti una corruzione della partizione con i metadati tutti i Volumi presenti sul QNAP non sarebbero disponibili e l'unico intervento possibile è rappresentato da una procedura di recovery eseguita in offline.

In questo log prodotto dall'utility thin_check è possibile notare un errore checksum che ha letteralmente bloccato il qnap.

examining superblock
examining superblock backups
  128 valid superblock backups, last backup_id=1710339 blocknr=8388604
examining devices tree
examining mapping tree
  thin device 1 is missing mappings [6028431, 6028796]
    bad checksum in btree node (block 8261)
  thin device 1 has unexpected number of mapped blocks
    expected 6847262 != actual 6846927
examining tiering tree
examining tiering space maps

E' certo paradossale che un checksum error possa provocare la perdita di un volume intero, ma la flessibilità dei volumi LVM ha un prezzo ed è proprio la sicurezza dei dati.

In questo caso il log è stato prodotto da un tecnico QNAP collegato in remoto che ha "azzardato" operazioni sul QNAP Danneggiato danneggiando definitivamente la partizione Metadati.

Abbiamo bisogno di Volumi LVM Espandibili o Coalescenti ?

Le features che stiamo utilizzando sul nostro qnap sono veramente importanti ? E' davvero utile una scrittura coalescente sul Volume Logico ? Siamo Consapevoli dei rischi dell'utilizzo di volumi Thin ?

Casi Concreti: Rebuild Forzato di Raid 5 e corruzione dei Volumi Thin

Casi Concreti: Attacco Hacker e danneggiamento dei Volumi Thin

Concetti Preliminari: Come risolvere un caso di corruzione Metadati su QNAP

La regola numero uno da seguire è mantenere inalterato lo scenario dati originale.

Per poter garantire la massima sicurezza nella procedura di recovery è INDISPENSABILE produrre una copia forense/clone di ogni singola unità presente nell'array ed eseguire un backup del volume thin.

E' possibile utilizzzare qualsiasi tool, visuale o da shell, che garantisca la creazione di una immagine disco non compressa che sia identica al sorgente.

Preparazione del Volume di destinazione Target per la ricostruzione del Volume

Una volta terminato il processo di imaging dei dischi clone, è necessario mettere a disposizione un volume logico o fisico di dimensioni pari o superiori al volume che si intende recuperare.

Il volume target verrà utilizzato per il trasferimento dei blocchi coalescenti presenti sul tier ai blocchi relativi sul volume di destinazione.

Il risultato sarà un volume EXT4 di tipo tradizionale dove eseguiremo il data recovery o auspicabilmente un mount diretto.

Installazione dei dischi clone ed importazione dei Volumi LVM.

I dischi clone possono essere installati su una qualsiasi distribuzione Linux con supporto LVM2. Durante le procedure di importazione è comune che il Kernel non sia in grado di rilevare correttamente i Tiers, ma certamente sarà in grado di identificare i volumi principali e il volume Thin Metadata.

Se non fossimo in grado di ottenere l'accesso ai volumi logici possiamo utilizzare strumenti professionali per il trattamento di LVM2 come ufs-explorer o reclaim me.

E' tuttavia semplice una volta che abbiamo la detection completa dell'array in RAID visionare i backup di configurazione LVM ed estrarre gli offset manualmente.

Il nostro obiettivo è identificare due data range fondamentali dell'array:

• Tier Principale
• Volume Metadata

Estrazione e dump del Volume Metadata

Una volta localizzato il volume contenente i dati di Thin Provisioning è necessario produrre un dump fisico.Normalmente in un NAS QNAP la dimensione del volume Thin è pari a 64 GB.

Per il dump è possibile utilizzare gnu ddrescue che è molto flessibile e rapida.

Esempio di utilizzo:

ddrescue -s size ( dimensione della partizione metadati - di solito 64gb ) -i thinoffset ( in bytes o in settori ) -o 0 ( offset = 0 ) /dev/md126 ( il volume RAID contenente i dati ) thinmetadatadump.img

Download e compilazione dei Tools Thin Provisioning 

I Thin Tools presenti sulle distribuzioni non sono utilizzabili in un contesto QNAP in quanto non supportano i CRC QNAP e non supportano i Tiers.

E' dunque necessario scaricare una release di QTS ed estrarre dal sorgente i thin-tools specifici per QNAP.

Dump dei Metadati utilizzando thin_dump

Usage: thin_dump [options] {device|file}
Options:
  {-h|--help}
  {-f|--format} {xml|human_readable|compact}
  {-r|--repair} [level]
  {-d|--device} <dev_id>
  {-s|--single-mapping-tree} <block#>
  {-b|--brief}
  {-t|--tiering}
  {-c|--clone}
  {-m|--metadata-snap} [block#]
  {--data-space-map}
  {--metadata-space-map}
  {-o <xml file>}
  {-V|--version}
  {--non-exclusive}
  {--bs} <metadata block size>

esempio di utilizzo:

/usr/sbin/thin_dump -f xml thinmetadatadump.img -o dump.xml

Thin Dump ed analisi dei metadati XML

<superblock uuid="" time="2169" transaction="2170" flags="3221225473" version="4" metadata_block_size="16" data_block_size="1024" nr_data_blocks="14936400" tier_block_size="8192" nr_tiers="3" tier0_data_blocks="0" tier1_data_blocks="0" tier2_data_blocks="1867450">
  <device dev_id="1" mapped_blocks="6847262" transaction="1" creation_time="1" snap_time="2169" clone_time="1" scaned_index="18446744073709551615" snap_origin="18446744073709551615">
    <single_mapping origin_block="0" data_block="3473530" time="2169" fastzero="0"/>
    <range_mapping origin_begin="1" data_begin="3478019" length="2" time="2169" fastzero="0"/>
    <single_mapping origin_block="3" data_block="3478027" time="2169" fastzero="0"/>

Esempio di Thin Dump in formato XML

E' semplice comprendere che nel nodo XML "<device>" viene definito la sequenza specifica per un volume con le seguenti informazioni:

1. dev_id
2. mapped_blocks

I records di questo XML sono classificabili in due tipologie:

1. single_mapping
2. range_mapping

La stessa definizione è self-explicative e va interpretata secondo la seguente logica:

Origin Block è la posizione di destinazione sul volume Finale,Data Block è il blocco definito sul tier gestito in modalità Thin ed ovviamente lenght è la dimensione di blocchi allocati per la sequenza.

1. origin_block
2. data_block
3. length

Ricostruzione del volume Finale e recupero dei dati

I tools Thin non hanno la capacità di riprodurre il volume definitivo, e sarete voi a dover realizzare un piccolo script per analizzare i metadati xml ed eseguire il dump sul target disk.

E' anche possibile utilizzare una modalità ibrida utilizzando un file locale di dump ed un array ricostruito via software o eseguire un dump completo del volume tier per poi utilizzare una base offset a 0.

Conclusioni e Valutazioni Finali

Quando si sceglie QNAP per la gestione del proprio patrimonio digitale, è bene conoscere che la moltitudine di features disponibili per la gestione dei volumi ha un prezzo.

Una infrastruttura tanto complessa e così dipendente dai metadati presenta numerosi rischi e riduce le opzioni di disaster recovery di fronte a crash totale dell'array o ad un attacco Hacker.

Se un attaccante in seguito ad una escalation di privilegi colpisse la zona metadati, il recovery risulterebbe difficoltoso anche per il miglior esperto ed una semplice corruzione di settori logici potrebbe risultare irrisolvibile anche a tecnici dotati di eccellente preparazione.