A fost lansată versiunea sistemului de backup Restic 0.18, care permite stocarea backup-urilor în format criptat într-un depozit versionat cu suport pentru deduplicare. Sistemul este proiectat în mod special pentru a salva backup-uri în medii nesigure, astfel încât accesul neautorizat la un backup să nu compromită sistemul. La crearea unui backup, este posibil să definiți reguli flexibile pentru includerea și excluderea fișierelor și directoarelor (formatul regulilor seamănă cu rsync sau gitignore). Este compatibil cu Linux, macOS, Windows și sistemele BSD. Codul proiectului este scris în limbajul Go și este distribuit sub licența BSD.
Backup-urile pot fi stocate pe FS local, pe extern server cu acces prin SFTP/SSH sau HTTP REST, în cloud-uri Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage și Google Cloud Storage, precum și în orice depozite pentru care există backend-uri rclone. Poate fi folosit, de asemenea, serverul de rest dezvoltat de proiect, care asigură o performanță mai bună comparativ cu alte backend-uri și care poate funcționa în mod de completare, interzicând ștergerea sau modificarea backup-urilor în cazul compromiterii serverului de bază și accesului la cheile de criptare.
Sistemul suportă instantanee care reflectă starea ierarhiei directoarelor în momente diferite (instantanele sunt create automat pentru fiecare backup). Este posibilă copierea instantaneelor între diferite depozite. Pentru economisirea traficului, în procesul de creare a backup-urilor sunt copiate doar datele modificate. O instantanee cu un backup poate fi montată sub formă de partiție virtuală (montarea se face cu ajutorul FUSE). De asemenea, sunt furnizate comenzi pentru analiza modificărilor și extragerea selectivă a fișierelor.
Depozitul de backup-uri din Restic manipulează nu fișiere întregi, ci blocuri de dimensiuni variabile, selectate folosind semnătura Rabin. Informația este stocată corelată cu conținutul, nu cu numele fișierelor (numele și obiectele legate de date sunt definite la nivel de metadate ale blocului). Pentru economisirea spațiului de stocare și eliminarea copiei inutile a datelor, se realizează deduplicare.
In serverele externe, informațiile sunt stocate în formă criptată – pentru sumele de control și deduplicare se folosesc hash-uri SHA-256, pentru criptare – algoritmul AES-256-CTR, iar pentru garantarea integrității – coduri de autentificare bazate pe Poly1305-AES. Există posibilitatea verificării backup-ului prin sumele de control și codurile de autentificare pentru a confirma că integritatea fișierelor nu a fost încălcată.
În noua versiune, a fost eliminată posibilitatea de a efectua un atac (PDF) prin determinarea prezenței unor fișiere specifice în stocarea criptată a backup-urilor. Atacul permite identificarea dacă un anumit fișier se află în backup-ul criptat, obținând acces la stocarea backup-urilor sau prin analiza traficului de rețea cu backup-urile. De exemplu, atacul poate fi realizat de un administrator al serverului pe care sunt stocate backup-urile, de un furnizor de internet sau de agenții de securitate care au obținut acces la server sau la trafic. Scopul atacului poate fi investigarea unei scurgeri de informații, în care agențiile de securitate pot evalua prezența documentelor de interes în stocarea backup-urilor.
Pentru a exploata vulnerabilitatea, atacatorul trebuie să reușească să adauge datele sale în backup-ul victimei sau să știe că un fișier cunoscut se află în backup. Dacă în backup există un fișier de care atacatorul este conștient (de exemplu, un anumit tip de conținut sistem sau multimedia), obținând acces la stocarea criptată, atacatorul poate determina dacă există și alte fișiere de interes în interior.
Metoda se bazează pe faptul că, având în vedere particularitățile compresiei conținutului, se pot determina parametrii blocurilor utilizate la fragmentarea conținutului. Pentru a determina astfel de parametri, este suficient să se identifice 3 blocuri criptate care conțin date cunoscute atacatorului.
Vulnerabilitatea nu este specifică pentru Restic și afectează alte sisteme de backup care folosesc separarea datelor în blocuri prin tehnica CDC (Content-Defined Chunking), cum ar fi BorgBackup, Tarsnap, Bupstash și Duplicacy. În Tarsnap, problema a fost rezolvată în actualizarea 1.0.41, la BorgBackup se lucrează la o soluție ce urmează să fie inclusă în ramura borg 2. La Bupstash, ultima modificare a fost acum 2 ani, iar la Duplicacy – 4 luni în urmă.
Se remarcă suplimentar că, în sistemele care utilizează deduplicarea, dacă există posibilitatea de a adăuga fișiere proprii la backup, se poate proceda mai simplu și se poate determina prezența fișierelor de interes pe un cale indirectă. După adăugarea fișierului verificat, se poate evaluar schimbarea dimensiunii stocării — dacă fișierul există deja în stocare, re-adăugarea sa, din cauza deduplicării, nu va duce la o creștere semnificativă a dimensiunii.
În plus față de eliminarea vulnerabilității din Restic 0.18, au fost propuse și câteva noutăți:
- A fost adăugat suport experimental pentru „stocările reci” de backup (datele devin disponibile pentru extragere după câteva minute sau ore de la solicitare), care suportă protocolul S3, precum Amazon S3 Glacier.
- Comenzile check și tag au fost adăugate cu suport pentru ieșirea în format JSON.
- La construirea imaginilor pentru GitHub Container Registry au fost avute în vedere recomandările SLSA (Supply-chain Levels for Software Artifacts).
- Comenzii ls i s-a adăugat opțiunea de a alege metoda de sortare a ieșirii. În comanda find, sortarea implicită este realizată după dată (de la cele recente la cele vechi).
- A fost oferită posibilitatea de a exclude din operația de reambalare fișierele cu dimensiunea mai mică decât cea specificată.
- A fost adăugată o setare pentru activarea/desactivarea restabilirii atributelor extinse ale fișierelor.
- A fost adăugat suport pentru sistemul de operare DragonFlyBSD.
- A fost adăugat suport pentru atributele extinse ale fișierelor pe sistemele cu NetBSD 10+.
- În ramura restic 0.19.0 se preconizează eliminarea suportului pentru funcționalitățile învechite, activate prin setările deprecate-legacy-index, deprecate-s3-legacy-layout, explicit-s3-anonymous-auth și safe-forget-keep-tags.
- Suportul pentru versiunile vechi de Windows și macOS a fost suspendat, pentru funcționare acum este necesară cel puțin Windows 10, Windows Server 2016 sau macOS 11. Suportul pentru versiunile TLS anterioare versiunii 1.2 a fost suspendat.
Sursa: opennet.ro
