É uma idéia razoável ter um servidor em casa recebendo backups de todos os sites dos meus clientes periodicamente?
Sim, desde que você siga algumas precauções
Existe alguma ameaça à segurança dos meus computadores conectados na mesma rede / roteador que o servidor que terá acesso ao FTP?
Sim, se você não seguir algumas precauções
- E se meu servidor em nuvem for comprometido? É provável que meu PC de backup em casa também esteja comprometido porque o servidor em nuvem pode se conectar a ele.
- E se meu PC de backup em casa estiver comprometido? A que ele tem acesso?
Portanto, você basicamente deseja reduzir o risco de comprometimento de qualquer sistema, além de limitar o acesso que um invasor teria no caso de conseguirem comprometer um ou ambos.
Precauções
- Não use FTP, pois as credenciais podem ser transmitidas sem criptografia, execute um servidor SSH em uma caixa Linux e conecte / transfira arquivos usando
scp
. Alternativa - encontre um servidor do tipo SFTP ou SCP que seja executado no Linux, Mac ou Windows.
- Use uma conta SSH limitada que tenha apenas acesso scp ao diretório de backup e apenas acesso suficiente para enviar o backup.
- Use uma chave privada para autenticação
- Com as etapas acima, se o seu servidor de nuvem remota for invadido e a chave privada for roubada, um invasor terá acesso apenas a um backup de um servidor ao qual ele já tem acesso!
- Execute um firewall com encaminhamento NAT / porta e recursos DMZ (pode até ser o roteador WiFi do seu ISP, se ele tiver um firmware atualizado sem vulnerabilidades conhecidas - verifique isso novamente - alguns roteadores ISP mais antigos estão cheios de bugs)
- Coloque seu computador de backup em casa em uma DMZ. Dessa forma, ele não obtém facilmente acesso a nenhum dos seus outros computadores e, portanto, reduz drasticamente a ameaça se for comprometida. Você pode encaminhar a porta 22 da sua rede doméstica interna para a DMZ e fazer logon com privilégios mais altos para fins de administração / scp.
- Use o encaminhamento NAT / porta para encaminhar uma porta TCP alta aleatória (por exemplo, 55134) do seu IP público para o serviço SSH - isso tornará o serviço menos fácil de pegar
- Restrinja o acesso ao firewall para que a porta encaminhada fique visível apenas para o servidor em nuvem remoto
- Não coloque dados confidenciais, chaves privadas SSH, senhas, etc. etc. no seu computador de backup. Dessa forma, se estiver comprometido, você reduzirá ainda mais o acesso de um invasor.
- Mantenha todos os sistemas / serviços atualizados - especialmente no servidor em nuvem e no PC de backup. As vulnerabilidades estão sempre sendo descobertas e geralmente podem ser facilmente exploradas pelos invasores, por exemplo, para transformar o acesso básico em acesso no nível raiz. (por exemplo, https://dirtycow.ninja/ )
Essa lista é o cenário ideal e deve ajudá-lo a pensar nos riscos. Se o seu roteador ISP não tiver um recurso DMZ e você não quiser investir na configuração de um firewall alternativo, poderá ficar feliz com um compromisso (eu pessoalmente não ficaria feliz com ele) - nesse caso, eu garantiria que os firewalls baseados em host estejam ativos em todos os seus PCs de rede internos, e senhas fortes, exijam autenticação para todos os compartilhamentos / serviços etc.
Uma alternativa, conforme sugerido por outro usuário (aqui está um pouco mais detalhadamente), seria o script do seu servidor em nuvem para produzir os backups e disponibilizá-los, e o seu PC de backup para se conectar via SFTP ou SCP (SSH) para obter os backups .
Isso pode funcionar bem, mas bloqueie a porta SSH / SFTP para que apenas o seu PC de backup possa acessá-la, use uma conta de acesso limitado e pense nas mesmas precauções. Por exemplo, e se o seu PC de backup estiver comprometido? Então, seu servidor na nuvem também está comprometido, etc.