Restic 0.18, et backup-system, der giver dig mulighed for at gemme krypterede backups i et versionsbaseret repository med deduplikeringsunderstøttelse, er blevet udgivet. Systemet er designet fra bunden til, at backups kan gemmes i upålidelige miljøer, så systemet ikke kan kompromitteres, hvis en backup falder i de forkerte hænder. Når du opretter en backup, kan du definere fleksible regler for at inkludere og ekskludere filer og mapper (regelformatet ligner rsync eller gitignore). Understøttelse af Linux, macOS, Windows og BSD-systemer. Projektets kode er skrevet i Go og distribueret under BSD-licensen.
Sikkerhedskopier kan gemmes i et lokalt filsystem, på en ekstern server Tilgængelig via SFTP/SSH eller HTTP REST, i Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage og Google Cloud Storage, samt alle lagringstjenester, der understøttes af rclone backends. Projektets egen REST-server kan også bruges til lagring. Den tilbyder højere ydeevne end andre backends og kan fungere i append-only-tilstand, hvilket forhindrer sletning eller ændring af sikkerhedskopier, hvis kildeserveren og adgangen til krypteringsnøgler kompromitteres.
Systemet understøtter snapshots, der afspejler kataloghierarkiets tilstand på forskellige tidspunkter (snapshots oprettes automatisk for hver sikkerhedskopi). Det er muligt at kopiere snapshots mellem forskellige repositories. For at spare trafik kopieres kun ændrede data under backup-processen. Et snapshot med en sikkerhedskopi kan monteres som en virtuel partition (montering udføres med FUSE). Kommandoer til at analysere ændringer og selektivt udpakke filer er også tilvejebragt.
Restics backup-lager manipulerer ikke hele filer, men derimod flydende blokke valgt ved hjælp af Rabins signatur. Information gemmes i forhold til indhold, ikke filnavne (datarelaterede navne og objekter er defineret på blokmetadataniveau). For at spare lagerplads og undgå unødvendig kopiering af data udføres deduplikering.
På eksterne servere lagres information i krypteret form - SHA-256 hashes bruges til kontrolsummer og deduplikering, AES-256-CTR algoritmen bruges til kryptering, og autentificeringskoder baseret på Poly1305-AES bruges til at garantere integritet. Det er muligt at verificere sikkerhedskopien ved hjælp af kontrolsummer og autentificeringskoder for at bekræfte, at filernes integritet ikke er blevet kompromitteret.
Den nye version eliminerer muligheden for et angreb (PDF) for at bestemme tilstedeværelsen af specifikke filer i et krypteret backuplager. Angrebet giver mulighed for at bestemme, om en specifik fil er i en krypteret backup, ved at få adgang til backuplageret eller ved at analysere netværkstrafik med backups. For eksempel kan angrebet udføres af administratoren af den server, hvor backupsene er gemt, en internetudbyder eller efterretningstjenester med adgang til backuplageret. server eller trafik. Formålet med angrebet kunne være at undersøge en datalækage, hvilket giver efterretningstjenester mulighed for at vurdere tilstedeværelsen af dokumenter af interesse i backup-lageret.
For at udnytte sårbarheden skal en angriber enten have deres data tilføjet til ofrets backup eller vide, at en fil, som vedkommende kender, er i sikkerhedskopien. Hvis sikkerhedskopien indeholder en fil, som angriberen kender til (f.eks. noget typisk system- eller multimedieindhold), kan angriberen efter at have fået adgang til det krypterede lager afgøre, om der er andre filer af interesse inde.
Metoden er baseret på det faktum, at det ud fra funktionerne ved indholdskomprimering er muligt at bestemme parametrene for de blokke, der bruges ved opdeling af indholdet. For at bestemme sådanne parametre er det tilstrækkeligt at bestemme 3 krypterede blokke, der indeholder data kendt af angriberen.
Sårbarheden er ikke specifik for Restic og påvirker andre sikkerhedskopieringssystemer, der bruger indholdsdefineret chunking (CDC) til at opdele data i blokke, såsom BorgBackup, Tarsnap, Bupstash og Duplicacy. Tarsnap løste problemet i 1.0.41, BorgBackup arbejder på en rettelse, som de planlægger at inkludere i borg 2-grenen. Bupstash blev sidst ændret for 2 år siden, og Duplicacy blev sidst ændret for 4 måneder siden.
Det bemærkes også, at i systemer, der bruger deduplikering, hvis der er mulighed for at tilføje dine filer til en sikkerhedskopi, kan du gøre det mere enkelt og bestemme tilstedeværelsen af filerne af interesse på en indirekte måde. Efter tilføjelse af filen, der skal kontrolleres, kan du evaluere ændringen i lagerstørrelsen - hvis filen allerede er på lageret, vil tilføjelse af den igen ikke føre til den nødvendige stigning i størrelse på grund af deduplikering.
Ud over at rette op på sårbarheden tilbyder Restic 0.18 også flere nye funktioner:
- Tilføjet eksperimentel understøttelse af kold backup-lagring (data bliver tilgængelige for hentning minutter eller timer efter anmodningen), der understøtter S3-protokollen, såsom Amazon S3 Glacier.
- Check- og tag-kommandoerne understøtter nu output i JSON-format.
- Ved opbygning af billeder til GitHub Container Registry blev anbefalingerne fra SLSA (Supply-chain Levels for Software Artifacts) taget i betragtning.
- Kommandoen ls har nu et valg af outputsorteringsmetode. Find-kommandoen sorterer som standard efter dato (nyeste til ældste).
- Giver mulighed for at udelukke filer mindre end en specificeret størrelse fra ompakningsoperationen.
- Tilføjet en indstilling for at aktivere/deaktivere gendannelse af udvidede filattributter.
- Tilføjet understøttelse af DragonFlyBSD OS.
- Tilføjet understøttelse af udvidede filattributter på systemer med NetBSD 10+.
- Den restic 0.19.0-gren er planlagt til at fjerne understøttelse af ældre funktioner aktiveret via indstillingerne deprecate-legacy-index, deprecate-s3-legacy-layout, explicit-s3-anonymous-auth og safe-forget-keep-tags.
- Understøttelse af ældre versioner er ophørt. Windows и macOS, for at arbejde nu skal du bruge mindst Windows 10, Windows Server 2016 eller macOS 11. Understøttelse af TLS-versioner før 1.2 er udgået.
Kilde: opennet.ru
