\u00c8 stata rilasciata la versione 0.18 del sistema di backup Restic, che consente di memorizzare i backup in forma crittografata in un repository versionato con supporto per deduplicazione. Il sistema \u00e8 progettato per garantire che i backup siano archiviati in ambienti non fidati, evitando che la compromissione di un backup possa compromettere il sistema stesso. Durante la creazione del backup \u00e8 possibile definire regole flessibili per includere ed escludere file e cartelle (il formato delle regole \u00e8 simile a rsync o gitignore). \u00c8 supportato l'uso su Linux, macOS, Windows e sistemi BSD. Il codice del progetto \u00e8 scritto in Go e distribuito con licenza BSD. <\/p>\n
Le copie di backup possono essere memorizzate nel file system locale, su dispositivi esterni server<\/a> con accesso tramite SFTP\/SSH o HTTP REST, su cloud come Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage e Google Cloud Storage, cos\u00ec come in qualsiasi archiviazione per la quale sono disponibili backend rclone. Per l'archiviazione pu\u00f2 essere utilizzato anche un progetto in sviluppo chiamato rest server, che offre prestazioni superiori rispetto ad altri backend e pu\u00f2 operare in modalit\u00e0 solo supplementare, impedendo la cancellazione o la modifica dei backup in caso di compromissione del server originale e accesso alle chiavi di crittografia. <\/p>\n Il sistema supporta snapshot che riflettono lo stato della gerarchia delle cartelle in momenti diversi (gli snapshot vengono creati automaticamente per ogni backup). \u00c8 possibile copiare gli snapshot tra diversi repository. Per risparmiare traffico, durante la creazione dei backup vengono copiati solo i dati modificati. Uno snapshot con un backup pu\u00f2 essere montato come una partizione virtuale (il montaggio avviene tramite FUSE). Sono anche disponibili comandi per analizzare le modifiche e per estrarre selettivamente i file. <\/p>\n Lo storage dei backup in Restic manipola non file interi, ma blocchi di dimensione variabile, scelti utilizzando la firma di Rabin. Le informazioni sono archiviate in base ai contenuti e non ai nomi dei file (i nomi e gli oggetti associati ai dati sono definiti a livello di metadati del blocco). Per risparmiare spazio di archiviazione e per evitare duplicazioni non necessarie dei dati, viene effettuata la deduplicazione. <\/p>\n Nei server esterni, le informazioni sono salvate in forma crittografata \u2014 per le somme di controllo e la deduplica sono utilizzati hash SHA-256, per la crittografia \u2014 l'algoritmo AES-256-CTR, e per garantire l'integrit\u00e0 \u2014 codici di autenticazione basati su Poly1305-AES. \u00c8 prevista la possibilit\u00e0 di verificare il backup tramite somme di controllo e codici di autenticazione per confermare che l'integrit\u00e0 dei file non sia stata compromessa. <\/p>\n Nella nuova versione \u00e8 stata eliminata la possibilit\u00e0 di effettuare un attacco (PDF) per determinare la presenza di determinati file nello storage crittografato dei backup. L'attacco consente di verificare se un file specifico si trova nel backup crittografato, accedendo allo storage dei backup o analizzando il traffico di rete dei backup. Ad esempio, l'attacco potrebbe essere portato a termine da un amministratore del server sul quale vengono salvati i backup, da un provider Internet o da agenzie governative che hanno ottenuto accesso a server<\/a> o al traffico. L'obiettivo di tale attacco potrebbe essere l'indagine su una fuga di informazioni, in cui le agenzie governative sarebbero in grado di valutare la presenza di documenti di loro interesse nello storage dei backup. <\/p>\n Per sfruttare la vulnerabilit\u00e0, l'attaccante deve riuscire ad aggiungere i propri dati nel backup della vittima o sapere che un file a lui noto \u00e8 presente nel backup. Se nel backup \u00e8 presente un file di cui l'attaccante \u00e8 a conoscenza (ad esempio, un contenuto sistemico o multimediale standard), accedendo allo storage crittografato, l'attaccante pu\u00f2 determinare se ci sono altri file a lui interessati al suo interno. <\/p>\n Il metodo si basa sul fatto che, in base alle caratteristiche di compressione del contenuto, \u00e8 possibile determinare i parametri dei blocchi utilizzati nella suddivisione del contenuto. Per determinare tali parametri \u00e8 sufficiente identificare 3 blocchi crittografati contenenti dati noti all'attaccante. <\/p>\n La vulnerabilit\u00e0 non \u00e8 specifica per Restic e interessa altri sistemi di backup che utilizzano la segmentazione dei dati in blocchi attraverso la tecnica CDC (Content-Defined Chunking), come BorgBackup, Tarsnap, Bupstash e Duplicacy. In Tarsnap, il problema \u00e8 stato risolto con l'aggiornamento 1.0.41, mentre in BorgBackup si sta lavorando a una correzione che dovrebbe essere inclusa nella branch borg 2. In Bupstash, l'ultimo cambiamento risale a 2 anni fa, mentre in Duplicacy \u00e8 avvenuto 4 mesi fa. <\/p>\n Inoltre, si osserva che nei sistemi che utilizzano la deduplica, se \u00e8 possibile aggiungere i propri file al backup, si pu\u00f2 procedere in modo pi\u00f9 semplice e determinare la presenza dei file di interesse in modo indiretto. Dopo aver aggiunto il file da controllare, \u00e8 possibile valutare la variazione delle dimensioni dello storage \u2014 se il file \u00e8 gi\u00e0 presente nello storage, il suo reinserimento a causa della deduplica non comporter\u00e0 un aumento significativo delle dimensioni. <\/p>\n Oltre alla correzione delle vulnerabilit\u00e0, Restic 0.18 introduce anche diverse novit\u00e0: <\/p>\n\n