Настроить домашний сервер для резервного копирования - плохая идея?

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

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

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

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

Разумно ли даже иметь дома сервер, периодически получающий резервные копии всех сайтов моих клиентов?

Да, при условии соблюдения некоторых мер предосторожности

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

Да, если вы не будете соблюдать некоторые меры предосторожности

1. Что если мой облачный сервер будет взломан? Тогда, скорее всего, мой домашний резервный ПК также будет взломан, потому что к нему может подключиться облачный сервер.
2. Что, если мой домашний резервный ПК будет взломан? К чему он имеет доступ?

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

Меры предосторожности

1. Не используйте FTP, так как учетные данные могут передаваться в незашифрованном виде, запускать SSH-сервер в Linux и подключаться / передавать файлы с помощью scp. Альтернатива - найти сервер типа SFTP или SCP, работающий в Linux, Mac или Windows.
2. Используйте ограниченную учетную запись SSH, у которой есть только scp-доступ к каталогу резервных копий и только достаточный доступ для отправки резервной копии.
3. Использовать закрытый ключ для аутентификации
4. С помощью описанных выше шагов, если ваш удаленный облачный сервер был взломан и секретный ключ украден, то злоумышленник получит доступ только к резервной копии сервера, к которому у него уже есть доступ!
5. Запустите брандмауэр, который имеет функции NAT / переадресации портов и функции DMZ (может даже быть маршрутизатором WiFi вашего интернет-провайдера, если на нем установлена ​​последняя версия микропрограммы без известных уязвимостей - проверьте дважды - некоторые старые маршрутизаторы ISP полны ошибок)
6. Поместите свой домашний резервный компьютер в DMZ. Таким образом, он не может легко получить доступ к любому из ваших других компьютеров, и, следовательно, значительно снижает угрозу, если он скомпрометирован. Вы можете перенаправить порт 22 из своей внутренней домашней сети в DMZ и войти в систему с более высокими привилегиями для целей администрирования / scp.
7. Используйте переадресацию NAT / порта для переадресации случайного порта с высоким TCP (например, 55134) с вашего общедоступного IP-адреса на службу SSH - это сделает услугу менее легко подобранной
8. Ограничьте доступ к брандмауэру, чтобы перенаправленный порт был виден только вашему удаленному облачному серверу.
9. Не размещайте конфиденциальные данные, закрытые ключи SSH, пароли и т. Д. На своем резервном компьютере. Таким образом, если это скомпрометировано, вы дополнительно уменьшите доступ к злоумышленнику.
10. Поддерживайте все системы / службы в актуальном состоянии - особенно на облачном сервере и резервном компьютере. Уязвимости всегда обнаруживаются и часто могут быть легко использованы злоумышленниками, например, чтобы превратить базовый доступ в доступ корневого уровня. (например, https://dirtycow.ninja/ )

Этот список является идеальным сценарием и должен помочь вам подумать о рисках. Если ваш маршрутизатор ISP не имеет функции DMZ и вы не хотите вкладывать средства в настройку альтернативного брандмауэра, то вы, возможно, будете довольны компромиссом (лично я не был бы доволен этим) - в этом случае я будет гарантировать, что брандмауэры на основе хоста активны на всех ваших компьютерах внутренней сети и имеют надежные пароли, требуют аутентификации для всех общих ресурсов / служб и т. д.

Альтернатива, предложенная другим пользователем (здесь чуть более подробно), состоит в том, чтобы создать сценарий для своего облачного сервера для создания резервных копий и сделать их доступными, а также сценарий резервного копирования на ПК для подключения через SFTP или SCP (SSH) для извлечения резервных копий. ,

Это может хорошо работать, но заблокируйте порт SSH / SFTP, чтобы только ваш резервный ПК мог получить к нему доступ, использовать учетную запись с ограниченным доступом и подумать о некоторых из тех же мер предосторожности. Например, что если ваш резервный компьютер скомпрометирован? Тогда ваш облачный сервер также будет взломан и т. Д.