É uma ideia 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 de segurança aos 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? Então é provável que meu PC de backup baseado em casa também seja comprometido porque o servidor de nuvem pode se conectar a ele.
- E se o meu PC de backup baseado em casa estiver comprometido? A que tem acesso?
Então, você basicamente quer reduzir o risco de comprometimento de um dos sistemas, ao mesmo tempo em que limita o acesso que um atacante teria no caso de comprometer um / ambos.
Precauções
- Não use o FTP, pois as credenciais podem ser transmitidas sem criptografia, executar um servidor SSH em uma caixa Linux e conectar / transferir 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 remoto estiver invadido e a chave privada for roubada, o invasor terá acesso somente a um backup de um servidor ao qual ele já tenha acesso!
- Execute um firewall que tenha recursos NAT / port forwarding e DMZ (pode até ser o roteador WiFi do seu ISP se ele tiver um firmware atualizado sem vulnerabilidades conhecidas - verifique isso - alguns roteadores ISP mais antigos estão cheios de bugs)
- Coloque seu computador de backup baseado em casa em uma DMZ. Desta forma, não obtém facilmente acesso a nenhum dos seus outros computadores e, portanto, reduz drasticamente a ameaça caso esteja comprometida. Você pode encaminhar a porta 22 de 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 de NAT / porta para encaminhar uma porta TCP alta aleatória (por exemplo, 55134) do seu IP público para seu serviço SSH. Isso tornará o serviço menos fácil de ser acessado
- Restringir o acesso no firewall para que a porta encaminhada seja visível apenas para o seu servidor de nuvem remoto
- Não coloque dados confidenciais, chaves privadas SSH, senhas etc. etc. em seu computador de backup. Dessa forma, se estiver comprometido, você reduz ainda mais o que o invasor tem acesso.
- 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 podem ser facilmente exploradas por invasores, por exemplo, para transformar o acesso básico em acesso ao nível de raiz. (por exemplo, link )
Esta lista é o cenário ideal e deve ajudá-lo a pensar nos riscos. Se o seu roteador ISPs não tem um recurso DMZ e você não quer investir na criação de um firewall alternativo, então você pode ser feliz com um compromisso (eu pessoalmente não ficaria feliz com isso) - nesse caso eu garantiria que firewalls baseados em host estivessem ativos em todos os PCs da sua rede interna e senhas strongs, exigindo autenticação para todos os compartilhamentos / serviços, etc.
Uma alternativa, como sugerido por outro usuário (aqui é um pouco mais detalhado), seria roteirizar seu servidor de nuvem para produzir os backups e disponibilizá-los, e roteirizar seu PC de backup para se conectar via SFTP ou SCP (SSH). Puxe os backups.
Isso pode funcionar bem, mas bloqueie a porta SSH / SFTP para que somente o seu PC de backup possa acessá-lo, use uma conta de acesso limitado e pense em algumas das mesmas precauções. Por exemplo. E se o seu PC de backup estiver comprometido? Então seu servidor de nuvem também está comprometido, etc.