Die Version 0.18 des Backup-Systems Restic wurde ver\u00f6ffentlicht. Es erm\u00f6glicht die Speicherung von Backups in verschl\u00fcsselter Form in einem versionierten Repository mit Deduplizierungsunterst\u00fctzung. Das System ist urspr\u00fcnglich so konzipiert, dass Backups in unsicheren Umgebungen gespeichert werden, und der Zugriff auf ein Backup durch Dritte sollte das System nicht gef\u00e4hrden. Bei der Erstellung eines Backups k\u00f6nnen flexible Regeln f\u00fcr das Ein- und Ausschlie\u00dfen von Dateien und Verzeichnissen definiert werden (das Regelwerk \u00e4hnelt rsync oder gitignore). Die Anwendung unterst\u00fctzt Linux-, macOS-, Windows- und BSD-Systeme. Der Code des Projekts ist in Go geschrieben und wird unter der BSD-Lizenz ver\u00f6ffentlicht. <\/p>\n
Backups k\u00f6nnen auf einem lokalen Dateisystem, auf externen Server<\/a> mit SFTP\/SSH- oder HTTP REST-Zugriff auf Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage und Google Cloud Storage sowie in jedem Speicher, f\u00fcr den rclone-Backends verf\u00fcgbar sind. Zudem kann der vom Projekt entwickelte Rest-Server verwendet werden, der eine h\u00f6here Leistung im Vergleich zu anderen Backends bietet und im Modus nur zur Erg\u00e4nzung betrieben werden kann, sodass L\u00f6schungen oder \u00c4nderungen von Backups im Falle einer Kompromittierung des Ursprungsservers und des Zugriffs auf die Verschl\u00fcsselungsschl\u00fcssel nicht m\u00f6glich sind. <\/p>\n Das System unterst\u00fctzt Snapshots, die den Zustand der Verzeichnisstruktur zu verschiedenen Zeitpunkten widerspiegeln (Snapshots werden automatisch f\u00fcr jede Sicherung erstellt). Es ist m\u00f6glich, Snapshots zwischen verschiedenen Repositories zu kopieren. Um den Datenverkehr zu reduzieren, werden beim Erstellen von Sicherungen nur die ge\u00e4nderten Daten kopiert. Ein Snapshot mit einem Backup kann als virtuelles Laufwerk bereitgestellt werden (die Bereitstellung erfolgt \u00fcber FUSE). Au\u00dferdem stehen Befehle zur Analyse von \u00c4nderungen und f\u00fcr die selektive Wiederherstellung von Dateien zur Verf\u00fcgung. <\/p>\n Das Backup-Speicher in Restic arbeitet nicht mit vollst\u00e4ndigen Dateien, sondern mit variablen Gr\u00f6\u00dfenbl\u00f6cken, die mithilfe der Rabin-Signatur ausgew\u00e4hlt werden. Die Informationen werden in Bezug auf den Inhalt und nicht auf die Dateinamen gespeichert (datenbezogene Namen und Objekte werden auf der Metadatenebene des Blocks definiert). Um Speicherplatz zu sparen und unn\u00f6tige Datenkopien zu vermeiden, wird eine Deduplizierung durchgef\u00fchrt. <\/p>\n Auf externen Servern werden Informationen verschl\u00fcsselt gespeichert \u2014 f\u00fcr Pr\u00fcfziffern und Deduplication kommen SHA-256-Hashes zum Einsatz, f\u00fcr die Verschl\u00fcsselung \u2014 der Algorithmus AES-256-CTR, und zur Gew\u00e4hrleistung der Integrit\u00e4t \u2014 Authentifizierungscodes basierend auf Poly1305-AES. Es besteht die M\u00f6glichkeit, das Backup anhand der Pr\u00fcfziffern und Authentifizierungscodes zu verifizieren, um zu best\u00e4tigen, dass die Integrit\u00e4t der Dateien nicht beeintr\u00e4chtigt wurde. <\/p>\n In der neuen Version wurde die M\u00f6glichkeit beseitigt, einen Angriff (PDF) durchzuf\u00fchren, um das Vorhandensein bestimmter Dateien im verschl\u00fcsselten Speicher der Backups zu \u00fcberpr\u00fcfen. Solch ein Angriff erm\u00f6glicht es, festzustellen, ob sich eine bestimmte Datei im verschl\u00fcsselten Backup befindet, indem man entweder auf den Backup-Speicher zugreift oder den Netzwerkverkehr der Backups analysiert. Beispielsweise kann ein Serveradministrator, der die Backups speichert, ein Internetanbieter oder eine Sicherheitsbeh\u00f6rde, die Zugang zu Server<\/a> oder dem Datenverkehr hat, einen solchen Angriff durchf\u00fchren. Ziel eines solchen Angriffs k\u00f6nnte die Untersuchung eines Datenlecks sein, bei dem die Sicherheitsbeh\u00f6rden den Bestand an relevanten Dokumenten im Backup-Speicher bewerten k\u00f6nnen. <\/p>\n Um die Schwachstelle auszunutzen, muss der Angreifer es schaffen, seine eigenen Daten in das Backup des Opfers einzuf\u00fcgen oder wissen, dass eine ihm bekannte Datei im Backup vorhanden ist. Wenn ein im Backup enthaltenes File bekannt ist (z. B. ein typischer System- oder Multimediainhalt), kann der Angreifer durch den Zugriff auf den verschl\u00fcsselten Speicher feststellen, ob sich darin andere f\u00fcr ihn interessante Dateien befinden. <\/p>\n Die Methode basiert darauf, dass man anhand 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 die Daten auf Basis der CDC-Technik (Content-Defined Chunking) in Bl\u00f6cke unterteilen, wie BorgBackup, Tarsnap, Bupstash und Duplicacy. In Tarsnap wurde das Problem mit dem Update 1.0.41 behoben, in BorgBackup wird an einer Korrektur gearbeitet, die in den Borg 2-Zweig aufgenommen werden soll. In Bupstash gab es zuletzt vor 2 Jahren eine \u00c4nderung, und in Duplicacy vor 4 Monaten. <\/p>\n Es wird zus\u00e4tzlich angemerkt, dass in Systemen, die Deduplication verwenden, bei der M\u00f6glichkeit, eigene Dateien zum Backup hinzuzuf\u00fcgen, einfacher verfahren werden kann, um das Vorhandensein von interessierenden Dateien indirekt zu bestimmen. Nach dem Hinzuf\u00fcgen der \u00fcberpr\u00fcften Datei kann die \u00c4nderung der Speicherkapazit\u00e4t bewertet werden \u2014 wenn die Datei bereits im Speicher vorhanden ist, wird das erneute Hinzuf\u00fcgen aufgrund der Deduplication nicht zu einem nennenswerten Anstieg der Gr\u00f6\u00dfe f\u00fchren. <\/p>\n Neben der Behebung von Sicherheitsanf\u00e4lligkeiten in Restic 0.18 wurden auch mehrere Neuerungen angek\u00fcndigt: <\/p>\n\n