Pull to refresh

Comments 48

В статье сказано: архивируется 7zip-ом с паролем. Так что, они не смогут прочитать бэкапы.
Только фантазии за желаемое выдавать не нужно, у 7-zip — AES используется, а для хэширования пароля используется PBKDF2 с sha256 и несколькими сотнями тысяч раундов. Так что TrueCrypt намного проще ломануть.
Особенно если пароль плайнтекстом в скрипте, ага.
Для того, чтобы архивы открыли надо моему хостеру скооперироваться с дропбоксом, что для меня маловероятно.
А зачем хостеру кооперироваться? Дропбоксовые данные у Вас в том же скрипте.
И как это поможет дропбоксовцам или тем кто его ломанет? Откуда они достанут этот скрипт с паролем? С таким же успехом можно про терморектальный криптоанализ вспомнить, но это никакого отношения к 7zip не имеет.
Так эта тема вообще не про 7zip. А про доверие к сервисам. Если уж параноить и не доверять гугломылу и прочим, то надо быть параноиком до конца, и пользовать свои облака. Тем более, что средств для этого придостаточно. Вы так не считаете?
Ну вам отписали, что дропбоксу отправляется только пароленный 7-zip. А Вы сказали, типа его могут открыть при желании, вот только непонятно как им это сделать.
Что касается своего облака, а своё облако, что сломать не могут?
Вы чуть-чуть недопонимаете. Своё облако вы контролируете сами, зная его структуру, определяете политики доступа, следите, кто получает на него доступ. Сможете ли вы опредилить, не синхронизирует ли ваши файлы из дропбокса кто-нибудь еще? Сможете ли вы со 100% увереностью сказать, сколько копий ваших бекапов хранит дропбокс. Ведь получи они пароль от архива, смогут посмотреть всю историю.
Если своё облако находится не у Вас дома, то вы его контролируете не намного больше, чем Dropbox. А можете к примеру еще пропустить обновление софта и получить дырку. Или вы предлагаете еще админа нанять для своего облака?
Ведь получи они пароль от архива

Как они получат? Телепатически?
Как они получат? Телепатически?

через дырку после пропущенного обновления софта.
Подождите, у нас тут ветка о том, что дропбокс, как вы утверждаете, может получить мои данные, которые я кладу в архив.
Пароль на архив он где найдёт?
Т.е. вы на 100% уверены, что в API который в с дропбокса скачали бэкдора нет? (и быть не может)
Ну, пусть будет и бэкдор, я то ему даю уже зашифрованный файл.
Как-то вы упорно гнёте свою линию, не разобравшись в вопросе…
Вы просто слишком прямолинейны и зацикливаетесь на взломе пароля, но есть ведь обходные пути. Что если бекдор читает файлы на диске (хотя я посмотрел, там вроде только питонские скрипты), но так, чисто теоритически.
А вы этот API видели вообще, или так фантазии на тему? У него как бы открытый исходный код, и никаких бэкдоров там нет, он тупо выполняет HTTP-запросы к API Dropbox, там никакой магии нет.
Читайте комменты до конца. Написал уже.
Как вам уже ответили, алгоритм у 7zip'а хороший, а пароли у меня буквенно-цифровые, в разном регистре и более 15-ти знаков.
Вы же знаете разницу между алгоритмом и реализацией алгоритма. (Хочу сразу оговориться, всё расматривается в теоритическом аспекте)
Естественно, где-то паддинг могут занулить, где-то ГСПЧ инициализировать троечкой, но я надеюсь, что там такого нет :)
Ходят страшилки что клиент читает\хеширует файлы на машине и шлёт куда надо.
Это вы о каком таком клиенте? Если вы думаете, что он есть на моём сервере, то вы неправы. Используется только API, которому скармливается уже готовый, зашифрованный файл.
Не я про ваш сервер не думаю так.
Тоже самое бы про облако.mail.ru с шифрованием — так и не придумал куда их 1 Тб использовать.
У меня самого тот же террабайт места, пока только заливаю файлы с шифрованием через BoxCryptor, ведь в cloud.mail.ru пока не разродились API.
Есть 400 гигабайт Яндекс.Диска за закрытие Яндекс.Видео и баг, который убивал винду.
Вот всё думаю сделать бекапы туда. Тем более, что там WebDav и его можно подмонтировать просто разделом в систему.
Для инкрементных бекапов подходит 7z-архив (http://a32.me/2010/08/7zip-differential-backup-linux-windows/). Удалённые папки/файлы не останутся.
Спасибо за наводку! Может быть так действительно было бы лучше.
инкрементный и дифференциальный — это весьма разные вещи
Главное иметь отдельный dropbox аккаунт только для бэкапов, иначе в случае взлома любого из ваших серверов, запороленные бэкапы не представляют ценность, а другая информация из соседних папок может оказаться ценнее пароля на zip архив )
То есть, вы считаете, что заполучив мой скрипт бэкапа с паролем, используемым для архивирования, злоумышленник получит доступ к аккаунту дропбокса?

Если так, то вы не очень внимательно читали статью.
1. Для бэкапа создается виртуальное «приложение» (как, например, приложения в VK), которое имеет доступ только к своей папке.
2. Пароль для архивирования не такой же, как пароль к дропбоксу.
Да, действительно упустил из виду момент «Yes — My app only needs access to files it creates». Попробовал ваше решение, добавил "# -*- coding: utf-8 -*-" в скипт и установил Setuptools. Но т.к. у меня python ни для чего больше не используется, решил пока остановиться на скрипте dropbox_uploader.
Может и лучше, но у них нет простого, подходящего под небольшой скриптинг, API. И появились они позже.
У меня для бэкапов есть отдельный аккаунт dropbox, и я поставил в крон простой bash-скрипт, который c помощью rdiff-backup ежедневно скидывает инкрементальные бэкапы определенных папок из /var/www в папку дропбокса. Еще туда сбрасываются дампы баз данных MySQL для указанных сайтов. Если кому-то интересно, подробнее можно ознакомиться здесь
А у меня бэкапы не лежат на самом сервере. Ведь для использования клиента дропбокса необходимо чтобы все файлы лежали в папке.
Тут же уже была отличная статья. Пароли это зло, они утекают. А правильный выход это pgp и на сервере только публичный ключ для которого будут шифроваться данные.
Я себе так настроил.

gpg --trust-model=always --yes -e -r 0xId_pgp_key -o crypted.sql.gz.pgp source.sql.gz
Я для резервного копирования приспособил Яндекс.Диск и утилиту ydcmd. А для экономии места в облаке сжимаю данные zpaq в инкрементальные архивы — для моих данных сжатие получается существенно лучше чем у 7z.

Присматривался к bitcasa за ее дешевизну (объемы достаточно большие и цена играет роль), но невозможность удалять файлы помноженная на странный способ адресации объектов в хранилище свела на нет все кажущиеся преимущества.
Т.е. сначала с zpaq делаем архив папок и потом кладем в я.диск?
Да. Что-то в стиле:

$ zpaq a '/home/backup/user.???.zpaq' /home/user -threads 4 -method 5 -quiet -key 123456

Такая команда будет создавать зашифрованные инкрементальные архивы вида user.001.zpaq, user.002.zpaq и т.д. При этом первый архив может быть достаточно большой (полный), остальные содержат только измененные части. Если между вызовами файлы не изменились, то дополнительного архива просто не создается.

Такая схема позволяет уменьшить трафик (т.к. нужно загружать только дельты), ну и сам zpaq сжимает достаточно неплохо (особенно, скажем, дампы баз).

Единственное неудобство для меня было в том, что в Debian версия zpaq достаточно старая и приходилось на каждом сервере собирать руками. В конечном итоге это надоело и сделал для себя пакет zpaq-upstream.
Дело в том, что этот «посредник» в моём случае выступает еще и дополнительным хранилищем. Это скорее плюс, чем минус. Тем более, файлы открыть он не может.
Не вижу в вашем случае зачем нужно делать инкрементальные бэкапы. Dropbox идеально сам справляется с этой задачей. Сохраняете каждый день свой полный бэкап под одним и тем же именем, а Dropbox позаботится о версионности. Сейчас посмотрел у себя — у файл бэкапа доступно последние 30 версий, при этом файл занимает всего 1.5Гб.

Так как приложение ограничено только своей директорией, то можно не боятся, что в случае компрометации вашего приложения уйдет что-то еще кроме бэкапов.

У нас в Plesk'e мы решили проблему хранения бэкапов на внешних источниках тем, что шифруем пароли и подписываем сам бэкап. И да, у нас есть расширение для хранения бэкапов в Dropbox'e:
devblog.plesk.com/2013/10/dropbox-backup-extension/
devblog.plesk.com/2014/07/dropbox-backup-2-0/

Если интересно, могу подготовить обзор на русском языке.
Я просто не хочу каждые сутки перекачивать 1,5гб с сервера на дропбокс и по те же 1,5гб на каждый из подключенных компов. Еще раз поясню — клиент дропбокса не используется, некому считать хэши кусков и т.п. За то полный бэкап у меня сейчас большой, а каждые сутки архивируется примерно по 30мб, если не заливать в бложики видеофайлы.
Если файлы шифруются, то они будут каждый раз разные (так как любая более-менее нормальная софтина для шифрования каждый раз использует как минимум разные векторы инициализации, а скорее всего еще и случайные ключи). Так что каждый день качать 1,5 гига на dropbox сомнительное удовольствие.

Маленькое уточнение для нубов. Первый скрипт нужно назвать как-нибудь оригинально, например mydropbox.py


Я же наступил на грабли — dropbox.py


Traceback (most recent call last):
  File "./dropbox.py", line 6, in <module>
    import dropbox
  File "/home/dropbox.py", line 13, in <module>
    flow = dropbox.client.DropboxOAuth2FlowNoRedirect(app_key, app_secret)
AttributeError: 'module' object has no attribute 'client'
Sign up to leave a comment.

Articles