\u00c8 stato presentato il rilascio del sistema di backup Restic 0.18, che consente di archiviare le copie di backup in forma crittografata in un repository versionato con supporto per la deduplicazione. Il sistema \u00e8 progettato per funzionare in ambienti non fidati, affinch\u00e9 il reperimento di una copia di backup da parte di terzi non comprometta il sistema. Durante la creazione di una copia di backup, \u00e8 possibile definire regole flessibili per includere ed escludere file e directory (il formato delle regole \u00e8 simile a rsync o gitignore). \u00c8 supportato il funzionamento su Linux, macOS, Windows e sistemi BSD. Il codice del progetto \u00e8 scritto in Go e distribuito con licenza BSD. <\/p>\n
I backup possono essere archiviati nel file system locale, su dispositivi esterni server<\/a> con accesso SFTP\/SSH o HTTP REST, nei cloud Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage e Google Cloud Storage, nonch\u00e9 in qualsiasi archiviazione per la quale sono disponibili backend rclone. Per lo storage pu\u00f2 essere utilizzato anche il server REST sviluppato dal progetto, che offre prestazioni pi\u00f9 elevate rispetto ad altri backend e pu\u00f2 operare in modalit\u00e0 solo per integrazione, non consentendo di eliminare o modificare i backup in caso di compromissione del server originale e accesso alle chiavi di crittografia. <\/p>\n Il sistema supporta gli snapshot, che riflettono lo stato della gerarchia delle directory in diversi momenti nel tempo (gli snapshot sono creati automaticamente per ogni backup). \u00c8 possibile copiare gli snapshot tra diversi repository. Per risparmiare larghezza di banda, durante la creazione dei backup vengono copiati solo i dati modificati. Uno snapshot con il backup pu\u00f2 essere montato come una partizione virtuale (il montaggio \u00e8 effettuato tramite FUSE). Sono inoltre disponibili comandi per analizzare le modifiche e per estrarre file in modo selettivo. <\/p>\n Lo storage dei backup in Restic opera non su file interi, ma su blocchi di dimensioni variabili selezionati tramite la firma di Rabin. Le informazioni sono memorizzate in base al contenuto e non ai nomi dei file (i nomi e gli oggetti associati ai dati sono determinati a livello di metadati del blocco). Per risparmiare spazio nello storage e ridurre le copie superflue dei dati, viene eseguita la deduplicazione. <\/p>\n Sugli server esterni, le informazioni vengono salvate in forma crittografata \u2014 per i checksum e la deduplicazione vengono 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 checksum e codici di autenticazione per confermare che l'integrit\u00e0 dei file non sia stata compromessa. <\/p>\n Nella nuova versione \u00e8 stata rimossa la possibilit\u00e0 di effettuare un attacco (PDF) per determinare la presenza di file specifici nell'archivio riservato delle copie di sicurezza crittografate. L'attacco consente di stabilire se un file specifico \u00e8 presente nel backup crittografato accedendo all'archivio delle copie di sicurezza o attraverso l'analisi del traffico di rete riguardante i backup. Ad esempio, l'attacco pu\u00f2 essere effettuato dall'amministratore del server dove vengono memorizzati i backup, dal fornitore di servizi Internet o dai servizi segreti che hanno accesso a server<\/a> o al traffico. L'obiettivo di tale attacco pu\u00f2 essere l'investigazione di una fuga di informazioni, in cui i servizi segreti possono valutare la presenza di documenti di interesse nell'archivio delle copie di sicurezza. <\/p>\n Per sfruttare la vulnerabilit\u00e0, l'attaccante deve riuscire ad aggiungere i propri dati al backup della vittima o sapere che un file di suo interesse si trova nel backup. Se nel backup \u00e8 presente un file di cui l'attaccante \u00e8 a conoscenza (ad esempio, un tipo comune di contenuto sistemico o multimediale), accedendo all'archivio crittografato, l'attaccante pu\u00f2 stabilire se all'interno ci sono altri file di interesse. <\/p>\n Il metodo si basa sul fatto che, in base alle specifiche del contenuto compresso, \u00e8 possibile determinare i parametri dei blocchi utilizzati per frammentare il contenuto. Per identificare tali parametri \u00e8 sufficiente individuare 3 blocchi criptati contenenti dati noti all'attaccante. <\/p>\n La vulnerabilit\u00e0 non \u00e8 specifica per Restic e colpisce altri sistemi di backup che utilizzano la suddivisione dei dati in blocchi mediante la tecnica CDC (Content-Defined Chunking), come BorgBackup, Tarsnap, Bupstash e Duplicacy. In Tarsnap, il problema \u00e8 stato risolto nell'aggiornamento 1.0.41, mentre in BorgBackup \u00e8 in fase di lavoro una correzione che si prevede di includere nel ramo borg 2. In Bupstash, l'ultimo cambiamento risale a 2 anni fa, mentre in Duplicacy \u00e8 avvenuto 4 mesi fa. <\/p>\n Si segnala inoltre che nei sistemi che utilizzano la deduplicazione, qualora sia possibile aggiungere file propri al backup, \u00e8 possibile procedere in modo pi\u00f9 semplice e determinare la presenza dei file di interesse in modo indiretto. Dopo l'aggiunta del file da controllare, si pu\u00f2 valutare la variazione della dimensione del deposito \u2014 se il file \u00e8 gi\u00e0 presente nel deposito, l'aggiunta ripetuta a causa della deduplicazione non comporter\u00e0 un aumento sostanziale della dimensione. <\/p>\n Oltre alla correzione della vulnerabilit\u00e0 in Restic 0.18, sono state proposte diverse novit\u00e0: <\/p>\n\n