Чи навіть розумна ідея мати сервер вдома, який періодично створює резервні копії всіх веб-сайтів моїх клієнтів?
Так, за умови дотримання деяких запобіжних заходів
Чи є загроза безпеці моїх комп'ютерів, підключених у тій же мережі / маршрутизаторі, що і сервер, на якому буде доступ FTP?
Так, якщо ви не дотримуєтесь деяких запобіжних заходів
- Що робити, якщо мій хмарний сервер буде порушений? Тоді, швидше за все, мій домашній резервний ПК також буде порушений, оскільки хмарний сервер може підключитися до нього.
- Що робити, якщо мій домашній резервний ПК порушений? До чого він має доступ?
Таким чином, ви в основному хочете знизити ризик компромісу будь-якої системи, в той же час обмеживши, який доступ матиме зловмисник у випадку, якщо їм вдасться скомпрометувати або обидва, і обидва.
Запобіжні заходи
- Не використовуйте FTP, оскільки облікові дані можна передавати незашифрованими, запустити SSH-сервер у вікні Linux та підключити / передати файли за допомогою
scp. Альтернативно - знайдіть сервер типу SFTP або SCP, який працює на Linux, Mac або Windows.
- Використовуйте обмежений обліковий запис SSH, який має лише доступ scp до каталогу резервного копіювання, і достатньо доступу для надсилання резервної копії.
- Використовуйте приватний ключ для аутентифікації
- З вищезазначеними кроками, якщо ваш віддалений хмарний сервер зламаний, а приватний ключ вкрадений, зловмисник отримає доступ лише до резервної копії сервера, до якого вони вже мають доступ!
- Запустіть брандмауер з функцією перенаправлення NAT / порту та DMZ (навіть може бути маршрутизатором вашого Інтернет-провайдера, якщо він має сучасну вбудовану програму без відомих уразливостей - двічі перевірте це - деякі старі маршрутизатори провайдера пронизані помилками)
- Помістіть домашній резервний комп'ютер у DMZ. Таким чином, він не може легко отримати доступ до будь-якого іншого комп’ютера, а отже, різко зменшує загрозу, якщо вона порушена. Ви можете переслати порт 22 зі своєї внутрішньої домашньої мережі в DMZ і ввійти з більш високими привілеями для адміністрування / scp цілей.
- Використовуйте перенаправлення NAT / порту для пересилання випадкового високого порту TCP (наприклад, 55134) з вашого загальнодоступного IP до вашої служби SSH - це зробить послугу менш легкою для підбору
- Обмежте доступ до брандмауера, щоб пересланий порт бачив лише ваш віддалений хмарний сервер
- Не розміщуйте на своєму резервному комп'ютері жодних конфіденційних даних, приватних ключів SSH, паролів тощо. Таким чином, якщо це поставлено під загрозу, ви ще більше зменшите те, до чого має доступ нападник.
- Оновлюйте всі системи / послуги, особливо на хмарному сервері та резервному ПК. Уразливості завжди виявляються і часто можуть бути легко використані зловмисниками, наприклад, щоб перетворити базовий доступ у доступ до кореневого рівня. (наприклад, https://dirtycow.ninja/ )
Цей список є ідеальним сценарієм і повинен допомогти вам подумати про ризики. Якщо ваш маршрутизатор провайдерів не має функції DMZ, і ви не хочете інвестувати кошти в створення альтернативної брандмауеру, то, можливо, ви будете задоволені компромісом (я особисто не був би задоволений цим) - у такому випадку я гарантував би, що брандмауери на основі хоста є активними на всіх ваших комп'ютерах із внутрішньою мережею та надійні паролі, потребують автентифікації для всіх спільних ресурсів / служб тощо.
Альтернативою, запропонованої іншим користувачем (тут трохи детальніше), було б скриптування хмарного сервера для створення резервних копій та надання їх доступним, а також сценарій вашого резервного ПК для підключення через SFTP або SCP (SSH) для витягування резервних копій. .
Це може бути добре, але заблокуйте порт SSH / SFTP, щоб тільки ваш резервний ПК міг отримати доступ до нього, використовувати обліковий запис з обмеженим доступом та продумати деякі ті ж заходи безпеки. Наприклад, що робити, якщо ваш резервний ПК порушено? Тоді ваш хмарний сервер також порушений і т.д.