È 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 è progettato per funzionare in ambienti non fidati, affinché il reperimento di una copia di backup da parte di terzi non comprometta il sistema. Durante la creazione di una copia di backup, è possibile definire regole flessibili per includere ed escludere file e directory (il formato delle regole è simile a rsync o gitignore). È supportato il funzionamento su Linux, macOS, Windows e sistemi BSD. Il codice del progetto è scritto in Go e distribuito con licenza BSD.
I backup possono essere archiviati nel file system locale, su dispositivi esterni server con accesso SFTP/SSH o HTTP REST, nei cloud Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage e Google Cloud Storage, nonché in qualsiasi archiviazione per la quale sono disponibili backend rclone. Per lo storage può essere utilizzato anche il server REST sviluppato dal progetto, che offre prestazioni più elevate rispetto ad altri backend e può operare in modalità solo per integrazione, non consentendo di eliminare o modificare i backup in caso di compromissione del server originale e accesso alle chiavi di crittografia.
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). È 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ò essere montato come una partizione virtuale (il montaggio è effettuato tramite FUSE). Sono inoltre disponibili comandi per analizzare le modifiche e per estrarre file in modo selettivo.
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.
Su server esterni, le informazioni vengono salvate in forma crittografata: per i checksum e la deduplicazione si utilizzano hash SHA-256, per la crittografia si adotta l'algoritmo AES-256-CTR e per garantire l'integrità si utilizzano codici di autenticazione basati su Poly1305-AES. È prevista la possibilità di verificare il backup tramite i checksum e i codici di autenticazione per confermare che l'integrità dei file non sia stata compromessa.
Nella nuova versione è stata rimossa la possibilità 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 è 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ò 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 o al traffico. L'obiettivo di tale attacco può 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.
Per sfruttare la vulnerabilità, 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 è presente un file di cui l'attaccante è a conoscenza (ad esempio, un tipo comune di contenuto sistemico o multimediale), accedendo all'archivio crittografato, l'attaccante può stabilire se all'interno ci sono altri file di interesse.
Il metodo si basa sul fatto che, in base alle specifiche del contenuto compresso, è possibile determinare i parametri dei blocchi utilizzati per frammentare il contenuto. Per identificare tali parametri è sufficiente individuare 3 blocchi criptati contenenti dati noti all'attaccante.
La vulnerabilità non è specifica per Restic e colpisce altri sistemi di backup che utilizzano la suddivisione dei dati in blocchi tramite la tecnica CDC (Content-Defined Chunking), come BorgBackup, Tarsnap, Bupstash e Duplicacy. In Tarsnap, il problema è stato risolto nell'aggiornamento 1.0.41; in BorgBackup è in corso la lavorazione di una correzione, che dovrebbe essere inclusa nel ramo borg 2. In Bupstash, l'ultimo aggiornamento risale a 2 anni fa, mentre in Duplicacy è avvenuto 4 mesi fa.
Inoltre, si osserva che nei sistemi che utilizzano la deduplicazione, se si ha la possibilità di aggiungere i propri file al backup, si può seguire una procedura più semplice e determinare la presenza dei file di interesse in modo indiretto. Dopo aver aggiunto il file in esame, si può valutare il cambiamento delle dimensioni dello storage: se il file è già presente nello storage, il suo riaggiunta a causa della deduplicazione non porterà a un aumento significativo delle dimensioni.
Oltre alla correzione della vulnerabilità in Restic 0.18, sono state proposte diverse novità:
- Aggiunta la supporto sperimentale per i "cold storage" delle copie di backup (i dati diventano disponibili per il recupero dopo minuti o ore dalla richiesta), che supportano il protocollo S3, come Amazon S3 Glacier.
- Nei comandi check e tag è stata aggiunta l'opzione di output in formato JSON.
- Nella creazione delle immagini per GitHub Container Registry sono state considerate le raccomandazioni SLSA (Supply-chain Levels for Software Artifacts).
- Nel comando ls è stata aggiunta la scelta del metodo di ordinamento dell'output. Nel comando find l'ordinamento predefinito è per data (dal più recente al più vecchio).
- È stata fornita la possibilità di escludere dalla ripackaging file di dimensioni inferiori a quelle specificate.
- Aggiunta un'impostazione per attivare/disattivare il ripristino degli attributi estesi dei file.
- Aggiunta la supporto per il sistema operativo DragonFlyBSD.
- Aggiunta la supporto per gli attributi estesi dei file sui sistemi con NetBSD 10+.
- Nella branch restic 0.19.0 è previsto il ritiro del supporto per funzionalità obsolete attivate tramite le impostazioni deprecate-legacy-index, deprecate-s3-legacy-layout, explicit-s3-anonymous-auth e safe-forget-keep-tags.
- Il supporto per le versioni obsolete di Windows e macOS è stato interrotto; ora è richiesto almeno Windows 10, Windows Server 2016 o macOS 11. Il supporto per le versioni TLS inferiori a 1.2 è stato interrotto.
Fonte: opennet.ru
