Konfigurowanie serwera w domu do tworzenia kopii zapasowych to zły pomysł?

Dzisiaj zostałem spalony przez dostawcę hostingu, mieli problem z centrum danych i twierdzili, że wykonują kopie zapasowe, ale ich kopia zapasowa została uszkodzona, więc straciłem witrynę, którą utworzyłem na dwóch różnych serwerach przez nich hostowanych. Oba serwery zostały dotknięte, więc dane zniknęły. Ta JEDNA witryna była niestety witryną, której nie utworzyłem kopii zapasowej lokalnie.

Zastanawiam się więc nad kupnem małego, taniego serwera i niektórych dysków twardych do okresowych kopii zapasowych przez FTP.

Pytanie brzmi: czy istnieje jakieś zagrożenie bezpieczeństwa dla moich komputerów podłączonych do tej samej sieci / routera co serwer, który będzie miał dostęp do FTP?

Czy to w ogóle rozsądny pomysł, aby serwer w domu okresowo tworzył kopie zapasowe wszystkich stron moich klientów? W tym momencie czuję, że muszę zrobić wszystko sam, ponieważ liczne historie o rozwiązaniach innych firm nie spełniają tego, co twierdzą.

Czy to w ogóle rozsądny pomysł, aby serwer w domu okresowo tworzył kopie zapasowe wszystkich stron moich klientów?

Tak, pod warunkiem przestrzegania pewnych środków ostrożności

Czy istnieje zagrożenie bezpieczeństwa dla moich komputerów podłączonych do tej samej sieci / routera, co serwer, który będzie miał dostęp do FTP?

Tak, jeśli nie zastosujesz się do pewnych środków ostrożności

1. Co się stanie, jeśli mój serwer w chmurze zostanie przejęty? Prawdopodobnie mój domowy komputer zapasowy również zostanie zagrożony, ponieważ serwer w chmurze może się z nim połączyć.
2. Co się stanie, jeśli mój domowy komputer zapasowy zostanie naruszony? Do czego ma dostęp?

Zasadniczo chcesz więc zmniejszyć ryzyko naruszenia bezpieczeństwa dowolnego systemu, a jednocześnie ograniczyć dostęp, jaki miałby atakujący w przypadku, gdyby udało mu się narazić jedno lub oba.

Środki ostrożności

1. Nie używaj FTP, ponieważ poświadczenia mogą być przesyłane niezaszyfrowane, uruchom serwer SSH na Linux-ie i łącz / przesyłaj pliki za pomocą scp. Alternatywa - znajdź serwer typu SFTP lub SCP działający w systemie Linux, Mac lub Windows.
2. Użyj ograniczonego konta SSH, które ma tylko dostęp scp do katalogu kopii zapasowej i tylko wystarczający dostęp do wysłania kopii zapasowej.
3. Użyj klucza prywatnego do uwierzytelnienia
4. W przypadku powyższych kroków, jeśli włamujesz się do zdalnego serwera w chmurze, a klucz prywatny zostanie skradziony, osoba atakująca uzyska dostęp tylko do kopii zapasowej serwera, do którego już ma dostęp!
5. Uruchom zaporę, która ma funkcje translacji NAT / portów i DMZ (może nawet być routerem Wi-Fi twojego dostawcy usług internetowych, jeśli ma aktualne oprogramowanie układowe bez znanych słabych punktów - sprawdź to dwukrotnie - niektóre starsze routery ISP są pełne błędów)
6. Umieść domowy komputer zapasowy w strefie DMZ. W ten sposób nie jest łatwo uzyskać dostęp do żadnego z innych komputerów, a zatem znacznie zmniejsza zagrożenie, jeśli zostanie przejęte. Możesz przekierować port 22 z wewnętrznej sieci domowej do DMZ i zalogować się z wyższymi uprawnieniami do celów administracyjnych / scp.
7. Użyj przekierowania NAT / portu, aby przekazać losowo wysoki port TCP (np. 55134) z publicznego adresu IP do usługi SSH - dzięki temu usługa będzie trudniejsza do odebrania
8. Ogranicz dostęp do zapory, aby przekierowany port był widoczny tylko dla zdalnego serwera w chmurze
9. Nie umieszczaj żadnych poufnych danych, kluczy prywatnych SSH, haseł itp. Na komputerze zapasowym. W ten sposób, jeśli zostanie to naruszone, jeszcze bardziej ograniczysz dostęp do tego, do czego atakujący ma dostęp.
10. Aktualizuj wszystkie systemy / usługi - szczególnie na serwerze w chmurze i komputerze zapasowym. Luki są zawsze wykrywane i często mogą być łatwo wykorzystane przez atakujących, na przykład w celu przekształcenia podstawowego dostępu w dostęp do poziomu root. (np. https://dirtycow.ninja/ )

Ta lista jest idealnym scenariuszem i powinna pomóc ci pomyśleć o ryzyku. Jeśli router ISP nie ma funkcji DMZ i nie chcesz inwestować w konfigurację alternatywnej zapory sieciowej, możesz być zadowolony z kompromisu (ja osobiście nie byłbym z tego zadowolony) - w takim przypadku ja zapewniłby, że zapory oparte na hoście są aktywne na wszystkich komputerach w sieci wewnętrznej, a silne hasła, wymagają uwierzytelnienia dla wszystkich udziałów / usług itp.

Alternatywą, zgodnie z sugestią innego użytkownika (tutaj jest nieco więcej szczegółów), byłoby wykonanie skryptu na serwerze w chmurze w celu utworzenia kopii zapasowych i udostępnienia ich, a także wykonanie skryptu na komputerze zapasowym, aby połączyć się za pośrednictwem SFTP lub SCP (SSH) w celu pobrania kopii zapasowych .

Może to działać dobrze, ale zablokuj port SSH / SFTP, aby dostęp do niego mógł uzyskać tylko komputer zapasowy, użyj konta z ograniczonym dostępem i pomyśl o niektórych tych samych środkach ostrożności. Np. Co zrobić, jeśli komputer zapasowy jest zagrożony? Wtedy twój serwer w chmurze jest również zagrożony itp.