Die Ver\u00f6ffentlichung des Backup-Systems Restic 0.18 wurde vorgestellt, das es erm\u00f6glicht, Backups in verschl\u00fcsselter Form in einem versionierten Repository mit Deduplizierung zu speichern. Das System ist urspr\u00fcnglich darauf ausgelegt, dass Backups in nicht vertrauensw\u00fcrdigen Umgebungen gespeichert werden, und der Zugang zu einem Backup durch Dritte sollte das System nicht gef\u00e4hrden. Beim Erstellen eines Backups k\u00f6nnen flexible Regeln zum Ein- und Ausschlie\u00dfen von Dateien und Verzeichnissen definiert werden (das Regelwerk \u00e4hnelt rsync oder gitignore). Der Betrieb wird in Linux, macOS, Windows und BSD-Systemen unterst\u00fctzt. Der Projektcode ist in der Programmiersprache Go geschrieben und wird unter der BSD-Lizenz verteilt. <\/p>\n
Backups k\u00f6nnen im lokalen Dateisystem, auf externen Server<\/a> mit Zugriff \u00fcber SFTP\/SSH oder HTTP REST, in Cloud-Diensten wie Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage und Google Cloud Storage, sowie in allen Speichersystemen, f\u00fcr die rclone-Backends verf\u00fcgbar sind. Zum Speichern kann auch der vom Projekt entwickelte Rest-Server verwendet werden, der eine h\u00f6here Leistung als andere Backends bietet und im Nur-Zusatzmodus betrieben werden kann, was das L\u00f6schen oder \u00c4ndern von Backups bei Kompromittierung des urspr\u00fcnglichen Servers und Zugang zu den Verschl\u00fcsselungsschl\u00fcsseln verhindert. <\/p>\n Das System unterst\u00fctzt Snapshots, die den Zustand der Verzeichnisstruktur zu verschiedenen Zeitpunkten darstellen (Snapshots werden automatisiert f\u00fcr jedes Backup erstellt). Snapshots k\u00f6nnen zwischen verschiedenen Repositories kopiert werden. Um den Datenverkehr zu reduzieren, werden beim Erstellen von Backups nur die ge\u00e4nderten Daten kopiert. Ein Snapshot mit einem Backup kann als virtuelles Laufwerk eingebunden werden (das Mounten erfolgt \u00fcber FUSE). Au\u00dferdem stehen Befehle zur Analyse von \u00c4nderungen und zur selektiven Wiederherstellung von Dateien zur Verf\u00fcgung. <\/p>\n Das Backup-Speichersystem in Restic arbeitet nicht mit ganzen Dateien, sondern mit variablen Gr\u00f6\u00dfenbl\u00f6cken, die mithilfe des Rabin-Signaturverfahrens ausgew\u00e4hlt werden. Die Informationen werden in Bezug auf den Inhalt und nicht auf die Dateinamen gespeichert (die mit den Daten verbundenen Namen und Objekte werden auf der Ebene der Blockmetadaten definiert). Zur Platzersparnis im Speicher und zur Vermeidung \u00fcberfl\u00fcssiger Datenkopien wird Deduplizierung durchgef\u00fchrt. <\/p>\n Auf externen Servern werden Informationen verschl\u00fcsselt gespeichert \u2013 zur Erstellung von Pr\u00fcfziffern und Deduplication werden SHA-256-Hashes verwendet, f\u00fcr die Verschl\u00fcsselung der AES-256-CTR-Algorithmus und zur Gew\u00e4hrleistung der Integrit\u00e4t Authentifizierungscodes auf Basis von Poly1305-AES. Es besteht die M\u00f6glichkeit, das Backup anhand von Pr\u00fcfziffern und Authentifizierungscodes zu \u00fcberpr\u00fcfen, um zu best\u00e4tigen, dass die Integrit\u00e4t der Dateien nicht beeintr\u00e4chtigt ist. <\/p>\n In der neuen Version wurde die M\u00f6glichkeit eines Angriffs (PDF) zur Feststellung der Existenz bestimmter Dateien im verschl\u00fcsselten Speicher von Sicherungskopien beseitigt. Der Angriff erm\u00f6glicht es zu erkennen, ob sich eine bestimmte Datei im verschl\u00fcsselten Backup befindet, indem auf den Speicher von Sicherungskopien zugegriffen wird oder durch die Analyse des Netzwerkverkehrs mit den Sicherungskopien. Beispielsweise kann ein Serveradministrator, auf dem die Backups gespeichert werden, ein Internetanbieter oder Geheimdienste, die Zugriff erhalten haben, einen Angriff durchf\u00fchren. zu einem Server<\/a> Das Ziel des Angriffs kann eine Untersuchung von Datenlecks sein, bei der Geheimdienste die M\u00f6glichkeit haben, das Vorhandensein von relevanten Dokumenten im Speicher der Sicherungskopien zu bewerten. <\/p>\n Um die Schwachstelle auszunutzen, muss der Angreifer es schaffen, seine Daten in die Sicherungskopie des Opfers einzuf\u00fcgen oder wissen, dass sich eine ihm bekannte Datei in der Sicherungskopie befindet. Wenn eine Datei in der Sicherungskopie vorhanden ist, die dem Angreifer bekannt ist (zum Beispiel eine Art von systemgeneriertem oder multimedialem Inhalt), kann der Angreifer durch den Zugriff auf den verschl\u00fcsselten Speicher feststellen, ob es darin andere f\u00fcr ihn interessante Dateien gibt. <\/p>\n Die Methode basiert darauf, dass man aufgrund der Besonderheiten der Inhaltskompression die Parameter der Bl\u00f6cke bestimmen kann, die beim Zerlegen des Inhalts verwendet werden. Um solche Parameter zu bestimmen, reicht es aus, 3 verschl\u00fcsselte Bl\u00f6cke zu identifizieren, die Daten enthalten, die dem Angreifer bekannt sind. <\/p>\n Die Schwachstelle ist nicht spezifisch f\u00fcr Restic und betrifft auch andere Backup-Systeme, die Daten mithilfe der CDC-Technik (Content-Defined Chunking) in Bl\u00f6cke aufteilen, wie BorgBackup, Tarsnap, Bupstash und Duplicacy. In Tarsnap wurde das Problem in der Version 1.0.41 behoben, bei BorgBackup wird an einem Fix gearbeitet, der in den Borg 2 Branch aufgenommen werden soll. Bei Bupstash gab es die letzte \u00c4nderung vor 2 Jahren, und bei Duplicacy vor 4 Monaten. <\/p>\n Es wird zus\u00e4tzlich darauf hingewiesen, dass in Systemen, die Deduplication verwenden, falls die M\u00f6glichkeit besteht, eigene Dateien in das Backup hinzuzuf\u00fcgen, eine einfachere Vorgehensweise besteht, um das Vorhandensein interessierender Dateien indirekt zu bestimmen. Nach dem Hinzuf\u00fcgen der \u00fcberpr\u00fcften Datei kann die \u00c4nderung der Speichergr\u00f6\u00dfe bewertet werden \u2013 wenn die Datei bereits im Speicher vorhanden ist, wird ihre erneute Hinzuf\u00fcgung aufgrund der Deduplication nicht zu einem signifikanten Gr\u00f6\u00dfenwachstum f\u00fchren. <\/p>\n Neben der Beseitigung von Schwachstellen in Restic 0.18 wurden auch einige Neuerungen vorgeschlagen: <\/p>\n\n