Представлен выпуск системы резервного копирования Restic 0.18, позволяющей хранить резервные копии в зашифрованном виде в версионированном репозитории с поддержкой дедупликации. Система изначально рассчитана на то, что резервные копии сохраняются в окружениях не заслуживающих доверия, и попадание резервной копии в чужие руки не должно скомпрометировать систему. При создании резервной копии возможно определение гибких правил для включения и исключения файлов и каталогов (формат правил напоминает rsync или gitignore). Поддерживается работа в Linux, macOS, Windows и BSD-системах. Код проекта написан на языке Go и распространяется под лицензией BSD.
Резервные копии могут храниться в локальной ФС, на внешнем сервере с доступом по SFTP/SSH или HTTP REST, в облаках Amazon S3,
OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage и Google Cloud Storage, а также в любых хранилищах для которых имеются бэкенды rclone. Для хранения также может использоваться развиваемый проектом rest server, обеспечивающий более высокую производительность по сравнению с другими бэкендами и способный работать в режиме только для дополнения, не позволяющем удалить или изменить резервные копии в случае компрометации исходного сервера и доступа к ключам шифрования.
Система поддерживает снапшоты, отражающие состояние иерархии каталогов в разные моменты времени (снапшоты создаются автоматически для каждой резервной копии). Возможно копирование снапшотов между разными репозиториями. Для экономии трафика в процессе создания резервных копий копируются только изменившиеся данные. Снапшот с резервной копией может быть примонтирован в форме виртуального раздела (монтирование осуществляется при помощи FUSE). Также предоставляются команды для анализа изменений и выборочного извлечения файлов.
Хранилище резервных копий в Restic манипулирует не целыми файлами, а блоками плавающего размера, выбираемыми с использованием подписи Рабина. Информация хранится в привязке к содержимому, а не именам файлов (связанные с данными имена и объекты определяются на уровне метаданных блока). Для экономии места в хранилище и исключения лишнего копирования данных выполняется дедупликация.
На внешних серверах информация сохраняется в зашифрованном виде – для контрольных сумм и дедупликации используются хэши SHA-256, для шифрования – алгоритм AES-256-CTR, а для гарантирования целостности – коды аутентификации на основе Poly1305-AES. Предусмотрена возможность верификации резервной копии по контрольным суммам и кодам аутентификации для подтверждения, что целостность файлов не нарушена.
В новой версии устранена возможность совершения атаки (PDF) по определению наличия заданных файлов в зашифрованном хранилище резервных копий. Атака позволяет определить находится ли в зашифрованном бэкапе какой-то конкретный файл, получив доступ к хранилищу резервных копий или при возможности анализа сетевого трафика с резервными копиями. Например, атаку может совершить администратор сервера, на который сохраняются бэкапы, интернет-провайдер или спецслужбы получившие доступ к серверу или трафику. Целью совершения атаки может стать расследование утечки информации, в котором спецслужбы смогут оценить наличие интересующих документов в хранилище резервных копий.
Для эксплуатации уязвимости атакующий должен добиться добавления своих данных в резервную копию жертвы или знать, что известный ему файл находится в резервной копии. Если в резервной копии имеется файл, о котором знает атакующий (например, какой-то типовой системный или мультимедийный контент), то получив доступ к зашифрованному хранилищу атакующий может определить, есть ли внутри другие интересующие его файлы.
Метод основан на том, что исходя из особенностей сжатия контента, можно определить параметры блоков, используемых при дроблении содержимого. Для определения подобных параметров достаточно определить 3 зашифрованных блока, содержащих данные, известные атакующему.
Уязвимость не специфична для Restic и затрагивает другие системы резервного копирования, использующие разделение данных на блоки при помощи техники CDC (Content-Defined Chunking), такие как BorgBackup, Tarsnap, Bupstash и Duplicacy. В Tarsnap проблема устранена в обновлении 1.0.41, в BorgBackup ведётся работа над исправлением, которое намерены включить в ветку borg 2. В Bupstash последнее изменение было 2 года назад, а в Duplicacy – 4 месяца назад.
Дополнительно отмечается, что в системах, использующих дедупликацию, при наличии возможности добавлять свои файлы в резервную копию можно поступить проще и определить наличие интересующих файлов косвенным путём. После добавления проверяемого файла можно оценить изменение размера хранилища – если файл уже имеется в хранилище, то его повторное добавление из-за дедупликации не приведёт к должному увеличению размера.
Кроме устранения уязвимости в Restic 0.18 также предложено несколько новшеств:
- Добавлена экспериментальная поддержка “холодных” хранилищ резервных копий (данные становятся доступны для извлечения через минуты или часы после запроса), поддерживающих протокол S3, таких как Amazon S3 Glacier.
- В команды check и tag добавлена поддержка вывода в формате JSON.
- При сборке образов для GitHub Container Registry учтены рекомендации SLSA (Supply-chain Levels for Software Artifacts).
- В команду ls добавлен выбор метода сортировки вывода. В команде find по умолчанию задействована сортировка по дате (от новых к старым).
- Предоставлена возможности исключения из операции перепаковки файлов, размером меньше заданного.
- Добавлена настройка для включения/отключения восстановления расширенных атрибутов файлов.
- Добавлена поддержка ОС DragonFlyBSD.
- Добавлена поддержка расширенных атрибутов файлов на системах с NetBSD 10+.
- В ветке restic 0.19.0 намечено удаление поддержки устаревших возможностей, активированных через настройки deprecate-legacy-index, deprecate-s3-legacy-layout, explicit-s3-anonymous-auth и safe-forget-keep-tags.
- Прекращена поддержка старых версий Windows и macOS, для работы теперь требуется как минимум Windows 10, Windows Server 2016 или macOS 11. Прекращена поддержка версий TLS до 1.2.