Анонимный и безопасный бэкап данных
После того, как при обыске у меня поизымали все компы-ноуты + все носители с бэкапами, и я с трудом восстановил меньшую часть своих данных, возникает вопрос, как грамотно обеспечить максимально анонимный и безопасный бэкап данных на удаленном носителе? (дедике или vpn)
Во-первых, что все же лучше брать для это цели – дедик или впн с большим виртуальным "диском"? Мне кажется, что все равно, но может быть какие есть соображения?
Во-вторых, как лучше организовать хранение на нем данных? Если делать криптоконтейнер, то криптоконтейнер с полутерабайтом данных заколебешься через сеть передавать на сервер. Если делать кучу мелких криптоконтейнеров – то тоже заколебешься. Если все файлы шифровать gpg – то мало того, что заколебешься это делать рекурсивно, это съест примерно столько же дискового пространства, сколько у тебя есть. Ну и сами ключи же надо как-то потом извлекать, если все локальные данные будут утрачены из-за действий властей.
В-третих, как передавать данные, чтобы противник не узнал, где ты их хранишь? Если через Tor, то опять таки очень долго передавать данные объемом полутерабайт – терабайт.
Есть какие-нибудь идеи?
Tahoe?
Дедик по умолчанию лучше защищён от атаки уборщицы, как мне кажется.
Основной ключ (пароль) должен быть в голове, остальное шифруется им.
Но как-то же они должны туда быть переданы, не через астрал же.
Ну, разве что передать с другого места или вывезти в место назначения вместе с диском.
Если хочется регулярно обновлять бэкап, есть программы*, которые это делают без передачи всех файлов. В любом случае придётся либо делать удалённую ФС с ключами на локальной машине**, либо всё нужное шифровать и высылать на удалённый сервер цельным файлом.
Почти все соображения уже высказывались тут[link1], если что. Лучше бы свой вопрос там и задавали в продолжение дискуссии.
*Не уверен, что именно это умеет rsync.
**eCryptFS, EncFS? Обсуждались они тут ранее.
Есть немного. Подойдут ли?
Я, например, важные данные не доверяю облакам. Понятно, многие не согласятся с такой позицией и будут правы в какой-то мере. Однако, мало что меня может заставить лить важные или критически важные данные на удаленные хосты в целях бэкапа. Зашифровать и залить всегда можно. Можно это сделать довольно оперативно и в приличных объемах, в том числе анонимно (через Tor). Но будут ли они там в надежности и сохранности? Как с ними потом работать? В каком виде они там должны быть? Для чего? К тому же данные могут быть разные, у каждого свое понятие критичности и оценка важности.
Вот у вас 500-1000 Гб данных. Залить их куда-то на скорости 1 мегабайт в секунду займет в сферическом вакууме около недели-двух. Tor может обеспечить такую скорость и по дефолту на быстрых нодах и при выборе цепочек индивидуально. Т.е., в реальности на это уйдет грубо говоря месяц-полтора. Допустим все уже на серваке в Конконге. Дальше что? С данными надо как-то работать, платить за нехилое пространство. Удобством, оперативностью, гибкостью, надежностью и мобильностью это назвать сложно. разве что анонимностью и только.
Это правда? Как восстанавливали? С чего, если все
вынеслиизъяли?Вы не предусмотрели вариант, когда силовые структуры вторгаются к вам в помещение. Допустить обыск, засветиться – уже ошибка. Которую можно исправить, предусмотрев ее. Но еще лучше ее избежать и учится на чужих.
Хранить 0,5-1 Тб бэкапа можно на съемном зашифрованном HDD. И все проблемы с каналами, аптаймом и пр. головной болью уходят. 2,5 дюйма, пара сотен граммов и пара тысяч рублей – вот и вся цена вопроса. Репликация данных на разные носители, хранящиеся в разных местах. Когда речь идет о действительно важных данных цена вопроса в несколько тысяч или максимум десятков тысяч рублей крайне невелика. Хотя для кого как. Студент и контрафактный софт – это одно, бизнес и комерческая тайна – другое, запрещенный контент и рядовой пользователь – третье и так далее по списку.
Полюбуйтесь на duplicity. С точки зрения передачи данных её можно считать неким балансом между шифрующей пофайлово ФС и контейнером.Но работы с бэкапом онлайн не будет.
Спасибо.
Есть одна гипотетическая ситуация, при которой эта метода не работает. Это когда после обыска вы пускаетесь в бега, с друзьями и знакомыми встречаться смертельно опасно, т.к. всюду засады, а всплыть в интернете можете только за границей, причём заранее неизвестно даже где. Бегать по лесам и откапывать тайники с дисками времени тоже не будет, т.к. надо делать ноги.
За вами уже вылетеливыехали.Вас на досмотре в аэропорту поймают. Лучше добровольно сдайтесь.
Откуда пишете-то? С брата? И как, жив курилка?
Вы инспектируйте, записывайте, хороший 3D-экшон получится, да и на попкорне озолотимся!
В школе еще каникулы не начались, а тут уже такие страсти.
Да. Всегда найдется гипотетическая ситуация, при которой та или иная метода не работает. Поэтому, ничего страшного, если метода не работает. Гораздо хуже, когда голова не работает.
Хотите, я угадаю, что вы сейчас случаете? Николая Носкова, композиция "Вот она пришла весна, как паранойя")
За вами уже вылетели выехали.Пусть позвонят, как подъедут, а то охрана, электронные пропуска, забор, да потом искать нужную дверь долго.Когда так сматываются, из страны выезжают не через аэропорт и не на общественном транспорте, потому не бесокойтесь.
Не угадали[link2].
Ну как гипотетическая... гипотетическая, но случается на свете часто. В интернете можно найти много историй. Работаешь разведчиком в тылу врага, заметил, что попал под наблюдение, пытаешься скрыться. Рядовой случай.
Подсказываю свою методу хранения бекапов и паролей к разным данным. В голове держу мастер-пароль и нижеописанный алгоритм:
домен сервера с бекапами = md5(host|backup|master_pass).com
пароль к архивам бекапов = md5(data|backup|master_pass)
рутовый пароль к серверу = md5(root|server_ip|master_pass)
Самые важные данные бекапятся автоматически, их не больше гигабайта. Остальное не фатально потерять.
Как возможно получить пароль=md5(data|backup|master_pass) при том, что зашифрованные data зависят от пароля? Или это просто имя архива?
data это не данные, это такая строчка. Вычисляется т.е. если мастер-пароль qwerty, паролем на архив будет md5(data|backup|qwerty) = 1FE1C0C2A7CCD6049155E8D549A8E570
Уметь бы его ещё считать прямо в голове!
Ещё один повод встроить чип себе в мозг? :)
Только на основе OpenHardware!
Посмотрел на неё, на rsync и на rdiff-backup. Пока остановился на последнем, но это всё равно не то, что хотелось бы, а хочется следующего:
Все эти инкрементальные бэкапы в duplicity и rdiff-backup для решения задачи подходят плохо. То, что они инткрементальные — это как раз хорошо, но вот они не являются идентичными копиями исходной директории. Duplicty вообще создаёт шифрованный tar-архив, потому не подходит сразу, а rdiff-backup делает уже настоящую копию директории, но к ней ещё есть директория с метаданными, инкрементами, статистикой и прочим. Директорию, куда сделал бэкап rdiff-backup, ни в коем случае нельзя менять, т.к. rdiff-backup — это скорее версионник для директории, который хранит список последних изменений и даже позволяет извлечь снапшот директории за какой-то промежуток времени. Грубо говоря, если хочется подключить бэкап, его надо разворачивать в новую директорию, и уже с ней работать. Если речь идёт о десятках-сотнях гигабайт данных, это, прежде всего, куча времени и бессмысленных копирований. Т.е. как бэкап-то оно работает, но бэкап «не живой». Можно ли сделать «живой» бэкап, который редактируем и подключаем на лету в любой момент? Или это несовместимо с инкрементальностью обновлений бэкапа? Казалось бы, rsync достаточно умён, чтобы синхронизировать директории даже без специальной БД о последних изменениях.
Подумалось ещё о такой аналогии: есть RAID'ы, когда идентичная информация пишется сразу на несколько носителей. Хочется получить то же самое, но чтобы информация писалось только в один из дисков «рейда», а потом можно было руками указать, содержимое какого из дисков отзеркалить на все остальные*. И отзеркалирование должно происходить не постоянно, как в рейдах, а раз в сутки/неделю — что-то типа такого.
*И, желательно, по возможности, быстрее, чем это занимает процесс полного удаления содержимого остальных дисков с последующим копированием на них всей информации.
Пример из жизни, где это нужно: на работе и дома есть почти идентичные директории. Допустим, дома я поработал, внёс какие-то изменения, что-то удалил, другие файлы добавил. Потом прихожу на работу, подключаюсь по сети к домашнему компьютеру и синхронизирую его с рабочим, после чего должен получить идентичную копию директории. Затем, поработав на работе, могу прийти домой и синхронизировать теперь уже домашний компьютер по рабочему. Как решают такие задачи? Здесь есть простота, т.к. заранее оговаривается, что в любой момент времени изменения вносятся только в одну из директорий. Наверное, нужен версионник, который содержит в себе всю БД изменений. Поработал дома — закоммитил изменения, подключился на работе — обновил свою версию из центральной БД версионника, а после изменений снова закоммитил. Если центрального сервера нет, БД с версионником должна быть либо дома, либо на работе.
Так это не бэкапы, а VCS.
Бэкап — частный случай VCS.
Я о том, что следует попробовать топикстартеру. Тот же Subversion вполне подпадает под требования.
Или всё-таки rsync.
Если не нужна версионность, то rsync — самый необременительный вариант.
Сколько существует таких алгоритмов, которые можно удержать в голове? Думаю, что по ставнению с количеством возможныых паролей очень немного, поэтому и битов сложности данная схема добавляет немного. Скорее всего в профессиональных "открывалках" такие схемы уже заложены. Дополнительная безопасность через неясность. Большой ли в этом смысл?
Про rsync говорят, что он синкает, а не бэкапит. Если в директории-1 снести файл, а потом посинкать её с директорией-2, где этот файл уже есть от предыдущих бэкапов, то rsync восстановит стёртый файл в директории-1. Т.е. чтобы что-то удалить, надо сначала удалить файл в директории-бэкапе, а только потом в основной директории, что очень неудобно. Не знаю, переопределяется ли такое поведение rsync'а.
Если я правильно понял, что вы хотите, то он может и так, и так:
Про слэши в конце пути только надо не забывать — они тоже имеют значение.
Может ещё выводить прогресс, делать сжатие потока и работать через ssh (в т.ч. без запуска демона).
Никакой безопасности через неясность, иначе бы я здесь не написал. Смысл данной схемы в том чтобы добраться до всех своих контактов, серверов и даных, не имея на руках никаких носителей информации. Нужна только голова и то что можно скачать из интернета.
В вашей схеме можно убрать md5, поскольку при брутфорсе это добавляет немного битов – брать в качестве ключа популярный хэш – довольно очевидная вещь. И даже если брать комбинации известных функций которые можно держать в голове – их относительно немного. Проще эти биты непосредственно в пароль загонять.
Сноудэн не читал ваших советов...
Сноуден выезжал из каждой из стран совершенно легально в момент выезда и знал заранее, что его выпустят.
Заблуждаетесь. У него были проблемы с выездом из Китая и СМИ даже обсуждали версию, что он выезжал по другому паспорту...
Не из Китая, а из Гонконга — это раз. Правительство Гонконга вполне официально решило его выпустить — это два. Как это было технически реализовано — дело третье, но искать подпольные от правительства пути покинуть страну ему было не надо.