Безопасное резервное копирование вне сайта, даже в случае хакерского root-доступа

24

Я ищу способ реализовать более безопасный способ резервного копирования за пределы площадки, который также защитит мои данные от ситуации, когда злонамеренный хакер получил root-доступ к моему серверу. Даже если вероятность этого меньше, чем другие виды рисков, если SSH и защита паролем правильно настроены, а система поддерживается в актуальном состоянии, количество повреждений, которые можно навсегда нанести, действительно велико, и поэтому я Я хотел бы найти решение, чтобы ограничить это.

Я уже пробовал два способа резервного копирования за пределы сайта:

  • простое монтируемое в корневой каталог webdav-монтирование (и сконфигурированное в fstab), куда копируются резервные данные. Проблема : на самом деле не резервное копирование вне сайта, потому что подключение - и, более того, доступ - к удаленному расположению постоянно остается открытым как папка в файловой системе. Это достаточная защита от многих видов атак, если монтируемое устройство имеет ограниченные права доступа (доступ только для чтения с правами root), но не защищает от злоумышленника с root-доступом.

  • Резервное копирование Borg через SSH с ключом аутентификации. Проблема : подключение к этому внешнему серверу можно выполнить с помощью ключа, который хранится на хосте, если злонамеренный пользователь имеет root-доступ к хосту.

В качестве решения я думаю об этих возможных путях, но я не знаю, как и с чем:

  • Резервные копии могут быть только записаны или добавлены к месту назначения, но не могут быть удалены.
  • Использование программного обеспечения для резервного копирования, которое обрабатывает внешние резервные копии и не поддерживает массовое удаление внешних резервных копий с первого хоста.

Решения, которые не очень интересны в моей ситуации:

  • Дополнительное задание резервного копирования на внешнем хосте, которое переносит их в местоположение, недоступное первому хосту (из-за технических ограничений).

Может ли кто-нибудь дать совет о том, как создать правильное резервное копирование для моего случая?

EarthMind
источник
7
Сначала вы делаете локальную резервную копию внутри сервера. Затем с другого сервера вы загружаете резервную копию себе (без монтирования каталогов).
TheDESTROS
2
30 или 40 лет назад существовали FTP-серверы с анонимным «входящим» каталогом. Вы можете загружать файлы, но не перезаписывать или перечислять их. Работал просто путем установки разрешений каталога соответственно. Итак ... локальный рут или нет, без разницы.
Дэймон
@TheDESTROS Отвечайте в ответах, а не в комментариях.
wizzwizz4
Я не думаю, что анонимный FTP должен использоваться больше.
Лукас Рэймидж

Ответы:

54

Все ваши предложения в настоящее время имеют одну общую черту: источник резервного копирования выполняет резервное копирование и имеет доступ к месту назначения резервной копии. Независимо от того, монтируете ли вы расположение или используете такие инструменты, как SSH или rsync, исходная система каким-то образом имеет доступ к резервной копии. Следовательно, компрометация на сервере может также поставить под угрозу ваши резервные копии.

Что, если решение для резервного копирования имеет доступ к серверу? Система резервного копирования может выполнять свою работу с доступом только для чтения, поэтому любой компромисс в системе резервного копирования, вероятно, не скомпрометирует сервер. Кроме того, система резервного копирования может быть выделена только для этой цели, что делает содержимое резервной копии единственным вектором атаки. Это было бы очень маловероятно и потребовало бы действительно сложной атаки.

Чтобы избежать перезаписи резервных копий с подделанным или поврежденным содержимым, делайте инкрементные резервные копии, которые позволяют восстановить любое предыдущее состояние в течение определенного периода восстановления.

Эса Йокинен
источник
Какой-нибудь совет, где искать руководство, чтобы настроить решение только для чтения?
EarthMind
5
Вот как я выполняю резервное копирование через ssh: сервер резервного копирования перейдет по ssh на сервер для резервного копирования.
Майкл Хэмптон
4
rsync через ssh также является хорошим вариантом и позволяет создавать инкрементные резервные копии. прямой scp лучше подходит для полного резервного копирования
GoFundMonica - codidact.org
10
+1 - «тянуть» вместо «толкать»
Кригги
1
Так же работают решения для резервного копирования, такие как BackupPC или IBM Tivoli Storage Manager (также известный как Spectrum Protect) .
Дубу
9

Неизменное хранение

Один хороший вариант - сделать хранилище резервных копий неизменным или, по крайней мере, обеспечить надежное управление версиями, которое обеспечивает эффективную неизменность. Чтобы было ясно: неизменный означает, что не может быть изменен или постоянный.

Есть несколько служб, которые могут сделать это для вас. AWS S3, BackBlaze B2 и я подозреваю, что Azure и Google предлагают аналогичную услугу. Возможно, вы могли бы настроить сервер для этого, но я не уверен, как.

Если у вас есть неизменяемый / контролируемый версией репозиторий, вы можете восстановить резервную копию в любой момент, поэтому, если ваш хост будет скомпрометирован, вы все равно сможете восстановить его в любой момент времени.

* AWS S3 **

Я наиболее знаком с AWS S3. S3 обеспечивает версионное, зашифрованное хранилище с высоким уровнем надежности.

S3 поддерживает управление версиями, что дает вам эффективную неизменность. Вы можете использовать правила жизненного цикла для удаления старых версий файлов после периода времени, который вы можете настроить. Вы также можете заархивировать версии в холодное хранилище (архив ледника), стоимость которого составляет около 1 долл. США / ТБ / месяц.

Вы можете использовать интеллектуальный класс многоуровневого хранения для сокращения затрат. Я предпочитаю использовать правило жизненного цикла, чтобы переместить все статические данные в нечастый класс доступа, который имеет длительную и умеренную (горячую) производительность, но не обладает масштабируемостью или производительностью стандарта S3.

S3 использует пользователей и политики IAM (управление доступом к личности, т.е. управление пользователями). Это дает вам очень детальный контроль над тем, что ваша программа резервного копирования может делать с вашим хранилищем. Вы можете дать пользователю разрешения на загрузку, но запретить обновление и удаление. Вы также можете требовать многофакторной аутентификации для удаления файлов или даже обеспечить блокировку объекта, чтобы файлы не могли быть удалены.

Предлагаемое программное обеспечение

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

Борг это еще один вариант. Раньше я использовал Borg, но обнаружил, что при моих средних размерах резервных копий в сотни МБ он каждый день эффективно загружал все мои данные из EC2 в S3. Для меня это не постепенно, поэтому я перестал его использовать. Я нашел документацию по этому вопросу, но у меня нет ссылки.

Существуют десятки программ, которые можно загружать в облачное хранилище.

Защищенное хранилище

С помощью некоторого программного обеспечения для резервного копирования вы можете попытаться дать пользователю IAM разрешение на запись новых файлов, но не обновлять существующие. Это легко сделать с помощью AWS IAM, но согласно приведенному ниже комментарию Restic не будет работать с этими разрешениями. Вы также можете иметь многофакторную аутентификацию, необходимую для удаления файлов из S3.

У вас может быть другой пользователь IAM, запускаемый, скажем, с вашего ПК, который периодически чистит архив, отбрасывая версии в соответствии с установленной вами политикой.

Тим
источник
1
Смотрите также S3 Object Lock . Он может быть настроен так, что никто, даже пользователь root, не может удалить или перезаписать объект в течение определенного периода.
user71659
Я подозреваю, что для резервных копий блокировка объекта может быть слишком сложной, так как иногда вам захочется удалить файлы. Это может истечь, так что вы можете удалить файлы позже.
Тим
1
Restic любит создавать и удалять файлы в каталоге «locks» для управления монопольным доступом, поэтому, если вы убираете разрешение на удаление файлов в бэкэнде, он ломается. Одно из предложенных здесь решений - использовать два сегмента (один блок чтения / записи для блокировок и один блок только для добавления для всего остального). Затем он использует локальный экземпляр tinyproxy для отправки содержимого через один из двух экземпляров Rclone в зависимости от пути запроса, и каждый Rclone отправляет команды в соответствующий сегмент.
Скотт Дадли
8

Borg Backup поддерживает удаленные репозитории только для приложений . Любой компромисс резервного копирования сервера может привести только к созданию новых резервных копий, а не к перезаписи только старых.

Иаков
источник
2
Одна вещь, которая мне не нравится в Borg, - если ваша инкрементная резервная копия меньше заданного размера, она просто загружает все копии. Я перешел на Restic, потому что это было неэффективно с пропускной способностью. Я не знаю, что такое порог, но достаточно, чтобы он был слегка раздражающим.
Тим
Итак, кто удаляет старые резервные копии в такой системе? Я пробовал только добавлять и никогда не удалять файлы на жесткие диски один раз, оказывается, они быстро исчерпали память.
Мачта
7

Решения, которые не очень интересны в моей ситуации:

Дополнительное задание резервного копирования на внешнем хосте, которое передает их в место, недоступное первому хосту.

Основная проблема заключается в том, что если вы можете получить удаленный доступ к резервным копиям, то и хакер может .

(Из-за технических ограничений)

Технические ограничения сделаны для преодоления.

Может ли кто-нибудь дать совет о том, как создать правильное резервное копирование для моего случая?

Ленточные накопители уже почти 70 лет обеспечивают надежную внешнюю защиту от всевозможных бедствий, включая хакеров.

RonJohn
источник
1
Я не понимаю, почему этот ответ не выше. Лучший способ предотвратить онлайн-атаку - отключить ее. Лента простая и проверенная.
Грег
@Greg Это не решение для каждого, как в моем случае из-за ограничений службы, которую я использую, которая разрешает только соединения webdav, Borg, SMB и NFS. Кроме того, это очень дорогое (по сравнению с приличными альтернативами) решение, которое не всегда интересно. Я не вижу, как я копирую свой VPS за 10 € / м с помощью дорогостоящего решения для автономного резервного копирования. Если данные исчезнут, для меня это не конец света. Здесь приятно видеть рекомендации разных ценовых диапазонов, но это решение наименее интересно для моего варианта использования.
EarthMind
Это. Резервное копирование на физический носитель и ротация физического носителя через безопасное удаленное расположение, в идеале с другим профилем риска стихийных бедствий.
Арп
@asp два моих сисадмина (я - администратор баз данных) держали ленты в своих багажниках ... Один из них опоздал на работу в WTC 9/11 (эти системы были на разных DC), поэтому 9 / 12 или 9/13 (я забыл, какой) он поехал на резервный DC со своими недельными лентами.
РонДжон
3

Вы можете использовать службы хранения, такие как AWS S3 (или, возможно, Google или эквивалент Azure), где вы можете предоставить полномочия PUT вашей корневой учетной записи для вашего сегмента, но не УДАЛИТЬ разрешения. Таким образом, вы можете использовать push-модель, и злоумышленник не сможет удалить резервную копию.

Существуют и другие меры безопасности, которые вы можете предпринять с AWS, например, требовать, чтобы MFA выполнял DELETE на корзине, но разрешать PUT и GET без MFA. Таким образом, вы можете как резервировать свои данные, так и извлекать их для восстановления своих услуг, не используя ваше устройство MFA, что может быть полезно в каком-то экстремальном (и, возможно, слишком неясном, чтобы даже упоминать) случае, когда доступ к устройству MFA может скомпрометировать его.

Кроме того, комментарий, выходящий за рамки, может показаться интересным / полезным, есть несколько способов настроить S3 и аналогичные службы для автоматического переключения при сбое в случае, если основной источник данных отключен.

Blueriver
источник
1
Я бы порекомендовал создать выделенный «push» клиент с доступом для записи в IAM. Кроме того, включите управление версиями, чтобы более ранние версии все еще были доступны. В качестве экономии средств «удалите» старые версии на Glacier.
Кригги
3

Резервное копирование Borg через SSH с ключом аутентификации. Проблема: подключение к этому внешнему серверу можно выполнить с помощью ключа, который хранится на хосте, если злонамеренный пользователь имеет root-доступ к хосту.

Вы можете использовать команду option в ваших авторизованных ключах. Вы исправляете команду, разрешенную в удаленном режиме.

Как добавить команды в SSH авторизованных ключей

Даже если злоумышленник восстановит учетную запись root, он не сможет сделать ничего, кроме определенной команды.

Snorky
источник
1

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

Джон
источник