Udviklingen af backup-systemet Restic 0.18 er blevet præsenteret. Det muliggør opbevaring af sikkerhedskopier i krypteret format i et versioneret repository med understøttelse af deduplication. Systemet er oprindeligt designet til, at backup-kopier gemmes i nevenyttige miljøer, hvor det ikke skal kompromittere systemet, selvom en sikkerhedskopi havner i de forkerte hænder. Ved oprettelse af en sikkerhedskopi er det muligt at definere fleksible regler for inkludering og ekskludering af filer og mapper (regelformatet ligner rsync eller gitignore). Der er understøttelse af Linux, macOS, Windows og BSD-systemer. Projektets kode er skrevet i Go-sproget og distribueres under BSD-licensen.
Sikkerhedskopier kan opbevares på den lokale filsystem, på ekstern serveren med adgang via SFTP/SSH eller HTTP REST, i skyerne Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage og Google Cloud Storage, samt i enhver lager, hvor der findes backends til rclone. Også backup serveren, der er udviklet af projektet, kan bruges til opbevaring, som giver højere ydeevne i forhold til andre backends og kan arbejde i kun-tilføjelsesmodus, hvilket forhindrer sletning eller ændring af sikkerhedskopier i tilfælde af kompromittering af den oprindelige server og adgang til krypteringsnøglerne.
Systemet understøtter snapshots, der afspejler tilstanden af kataloghierarkiet på forskellige tidspunkter (snapshots oprettes automatisk for hver sikkerhedskopi). Det er muligt at kopiere snapshots mellem forskellige repository. For at spare båndbredde kopieres kun de ændrede data under oprettelse af sikkerhedskopier. En snapshot med backup kan monteres som et virtuelt partition (monteringen udføres ved hjælp af FUSE). Derudover tilbydes kommandoer til at analysere ændringer og selektivt udtrække filer.
Backup-lageret i Restic håndterer ikke hele filer, men blokke med variabel størrelse, der vælges ved hjælp af Rabins signatur. Oplysningerne opbevares i forhold til indhold snarere end filnavne (tilknyttede data-navne og objekter defineres på metadata-blok niveau). For at spare plads i lageret og undgå unødvendig kopiering af data udføres deduplication.
På eksterne servere gemmes oplysninger i krypteret form — SHA-256-hashes anvendes til kontrolsummer og deduplisering, AES-256-CTR-algoritmen bruges til kryptering, og integritet sikres med autentifikationskoder baseret på Poly1305-AES. Der er mulighed for at verificere backupen ved hjælp af kontrolsummer og autentifikationskoder for at bekræfte, at filernes integritet ikke er blevet kompromitteret.
I den nye version er muligheden for at udføre et angreb (PDF) for at bestemme tilstedeværelsen af bestemte filer i det krypterede backup-lager blevet fjernet. Angrebet gør det muligt at bestemme, om en specifik fil findes i den krypterede backup ved at få adgang til backup-lagringssystemet eller ved at analysere netværkstrafikken til backup-filerne. For eksempel kan et angreb udføres af serveradministratoren, hvor backups gemmes, internetudbyderen eller efterretningstjenester, der har fået adgang til server eller trafikken. Målet med angrebet kan være at undersøge et datalæk, hvor efterretningstjenester kan vurdere tilstedeværelsen af interessante dokumenter i backup-lageret.
For at udnytte sårbarheden skal angriberen sørge for, at deres data bliver tilføjet i offerets backup, eller de skal vide, at en fil, som de kender til, findes i backupen. Hvis backupen indeholder en fil, som angriberen kender til (f.eks. en bestemt type system- eller multimedieindhold), kan de ved at få adgang til det krypterede lager afgøre, om der er andre interessante filer indeni.
Metoden er baseret på, at man ud fra indholdets komprimeringsegenskaber kan bestemme parametrene for de blokke, der anvendes ved opdeling af indholdet. For at bestemme sådanne parametre er det tilstrækkeligt at identificere 3 krypterede blokke, der indeholder oplysninger kendt af angriberen.
Sårbarheden er ikke specifik for Restic og påvirker andre backup-systemer, der bruger datadeling i blokke ved hjælp af teknikken CDC (Content-Defined Chunking), såsom BorgBackup, Tarsnap, Bupstash og Duplicacy. Problemet i Tarsnap blev løst i opdatering 1.0.41, mens der arbejdes på en rettelse i BorgBackup, som hensigten er at inkludere i borg 2-grenen. I Bupstash skete den seneste ændring for 2 år siden, og i Duplicacy var det for 4 måneder siden.
Det bemærkes desuden, at i systemer, der bruger deduplicering, kan man, hvis der er mulighed for at tilføje sine egne filer til backup, gøre det enklere og bestemme tilstedeværelsen af de ønskede filer indirekte. Efter tilføjelse af den kontrollerede fil kan man vurdere ændringen i lagerstørrelse — hvis filen allerede findes i lageret, vil dens gentagne tilføjelse ikke medføre en væsentlig stigning i størrelsen på grund af deduplicering.
Udover at fjerne sårbarheden i Restic 0.18 er der også foreslået flere nye funktioner:
- Tilføjet eksperimentel støtte til "kolde" backup-lagre (data bliver tilgængelige for udtræk gennem minutter eller timer efter anmodning), der understøtter S3-protokollen, såsom Amazon S3 Glacier.
- Der er tilføjet støtte til output-formatet JSON i kommandoerne check og tag.
- Når der bygges billeder til GitHub Container Registry, er der taget hensyn til SLSA (Supply-chain Levels for Software Artifacts) anbefalinger.
- Kommandoen ls har fået mulighed for at vælge metoden til sortering af output. I kommandoen find er sorteringen som standard baseret på dato (fra ny til gammel).
- Der er givet mulighed for at udelukke filer fra repackaging-operationen, hvis de er mindre end en angivet størrelse.
- Der er tilføjet en indstilling til at aktivere/deaktivere gendannelse af udvidede filattributter.
- Der er tilføjet støtte til OS DragonFlyBSD.
- Der er tilføjet støtte til udvidede filattributter på systemer med NetBSD 10+.
- I versionen restic 0.19.0 er det planlagt at fjerne støtten til forældede funktioner, der aktiveres via indstillingerne deprecate-legacy-index, deprecate-s3-legacy-layout, explicit-s3-anonymous-auth og safe-forget-keep-tags.
- Støtten til gamle versioner af Windows og macOS er ophørt, og der kræves nu mindst Windows 10, Windows Server 2016 eller macOS 11. Støtten til TLS-versioner før 1.2 er også ophørt.
Kilde: opennet.ru
