Version 0.18 av backup-systemet Restic har lanserats, vilket möjliggör lagring av säkerhetskopior i krypterad form i en versionshanterad uppsättning med stöd för deduplicering. Systemet är ursprungligen utformat för att säkerhetskopior ska lagras i osäkra miljöer, så att om en säkerhetskopia hamnar i fel händer ska det inte kompromettera systemet. Vid skapande av säkerhetskopior är det möjligt att definiera flexibla regler för att inkludera och exkludera filer och kataloger (regelformatet liknar rsync eller gitignore). Arbetet stöds i Linux, macOS, Windows och BSD-system. Projektets kod är skriven i Go och distribueras under BSD-licens.
Säkerhetskopior kan lagras i lokal filsystem, extern servern med åtkomst via SFTP/SSH eller HTTP REST, i moln som Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage och Google Cloud Storage, samt i alla lagringslösningar som har backend-lösningar för rclone. För lagring kan även en utvecklad server av projektet användas, som erbjuder högre prestanda jämfört med andra backend-lösningar och kan fungera i enbart append-läge, vilket förhindrar att säkerhetskopiorna kan raderas eller ändras i händelse av en kompromiss av den ursprungliga servern och tillgång till krypteringsnycklar.
Systemet stöder snapshots som reflekterar tillståndet av kataloghierarkin vid olika tidpunkter (snapshots skapas automatiskt för varje säkerhetskopia). Det är möjligt att kopiera snapshots mellan olika uppsättningar. För att spara bandbredd kopieras endast ändrade data under skapandet av säkerhetskopior. En snapshot med säkerhetskopian kan monteras som en virtuell partition (montering sker via FUSE). Kommandon för att analysera förändringar och selektiv extrahering av filer tillhandahålls också.
Backup-lagringen i Restic arbetar inte med hela filer utan med block av varierande storlek som väljs med hjälp av Rabins signatur. Informationen lagras kopplad till innehållet snarare än filnamnen (de namn och objekt som är relaterade till datan definieras på metadata-blocknivå). För att spara utrymme i lagringen och förhindra onödig datakopiering utförs deduplicering.
På externa servrar lagras information krypterad – SHA-256-hashar används för kontrollsummor och deduplicering, AES-256-CTR-algoritmen används för kryptering, och autentiseringarna baserade på Poly1305-AES garanterar integritet. Det finns en möjlighet att verifiera säkerhetskopian med hjälp av kontrollsummor och autentisering för att bekräfta att filernas integritet inte har blivit komprometterad.
I den nya versionen har möjligheten att utföra en attack (PDF) för att avgöra om vissa filer finns i det krypterade backupsystemet avlägsnats. Attacken gör det möjligt att avgöra om en specifik fil finns i det krypterade backupet genom att få tillgång till backupsystemet eller genom att analysera nätverkstrafik relaterad till säkerhetskopior. Till exempel kan attacken genomföras av serveradministratören dit säkerhetskopior sparas, en internetleverantör eller säkerhetstjänster som fått tillgång till servern eller trafiken. Målet med attacken kan vara att utreda en informationsläcka, där säkerhetstjänster kan bedöma förekomsten av intressanta dokument i backupsystemet.
För att utnyttja sårbarheten måste angriparen få sina data tillagda i offrets säkerhetskopia eller veta att en viss fil han känner till finns i säkerhetskopian. Om säkerhetskopian innehåller en fil som angriparen känner till (till exempel något standard system- eller multimediainnehåll), kan angriparen efter att ha fått tillgång till det krypterade lagret avgöra om det finns andra filer av intresse.
Metoden bygger på att, med hänsyn till innehållskomprimeringens särdrag, kan parametrarna för blocken som används vid uppdelning av innehållet avgöras. För att avgöra sådana parametrar räcker det med att identifiera tre krypterade block som innehåller data kända för angriparen.
Sårbarheten är inte specifik för Restic och påverkar andra säkerhetskopieringssystem som använder blockdelning med hjälp av CDC-tekniken (Content-Defined Chunking), såsom BorgBackup, Tarsnap, Bupstash och Duplicacy. Problemet i Tarsnap åtgärdades i uppdateringen 1.0.41, en lösning för BorgBackup är under arbete och avser att inkluderas i borg 2-grenen. Det senaste ändringen i Bupstash var för 2 år sedan, medan Duplicacy senast ändrades för 4 månader sedan.
Det noteras också att i system som använder deduplicering, om det finns möjlighet att lägga till egna filer i säkerhetskopian, kan man agera enklare och indirekt bestämma om intressanta filer finns. Efter att en fil lagts till kan man bedöma förändringen i lagringsutrymmet - om filen redan finns i lagringen, kommer dess återläggning på grund av deduplicering inte att leda till en avsevärd ökning av storleken.
Förutom att åtgärda sårbarheten i Restic 0.18 föreslås även flera nya funktioner:
- Experimentellt stöd har lagts till för "kalla" säkerhetskopieringslagringssystem (data blir tillgänglig för extraktion inom några minuter eller timmar efter begäran), som stödjer S3-protokollet, såsom Amazon S3 Glacier.
- Stödet för utdata i JSON-format har lagts till i kommandona check och tag.
- I sammansättningen av bilder för GitHub Container Registry beaktas rekommendationer från SLSA (Supply-chain Levels for Software Artifacts).
- Det har lagts till ett val av sorteringsmetod för utdata i kommandot ls. I kommandot find används som standard sortering efter datum (från nyast till äldst).
- Det finns möjlighet att utesluta filer som är mindre än en angiven storlek från ompackningsoperationen.
- En inställning för att aktivera/deaktivera återställning av filers utökade attribut har lagts till.
- Stöd har lagts till för OS DragonFlyBSD.
- Stöd har lagts till för utökade filattribut på system med NetBSD 10+.
- I grenen restic 0.19.0 planeras borttagning av stöd för föråldrade funktioner som aktiverats genom inställningarna deprecate-legacy-index, deprecate-s3-legacy-layout, explicit-s3-anonymous-auth och safe-forget-keep-tags.
- Stödet för äldre versioner av Windows och macOS har upphört, och det krävs nu minst Windows 10, Windows Server 2016 eller macOS 11. Stödet för TLS-versioner före 1.2 har upphört.
Källa: opennet.ru
