Configurando um servidor em casa para fins de backup é uma má idéia?


11

Hoje fui queimado por um provedor de hospedagem, eles tinham um problema no datacenter e alegavam fazer backups, mas o backup estava corrompido, por isso perdi um site em que havia feito backup em dois servidores diferentes hospedados por eles. Ambos os servidores foram afetados, então os dados foram embora. Infelizmente, esse site ONE era um site que eu não tinha feito backup localmente.

Então, estou pensando em comprar um servidor pequeno e barato e alguns discos rígidos para fazer backups periódicos via FTP.

A questão é: existe alguma ameaça à segurança dos meus computadores conectados na mesma rede / roteador que o servidor que terá acesso ao FTP?

É uma idéia razoável ter um servidor em casa recebendo backups de todos os sites dos meus clientes periodicamente? Nesse ponto, sinto que tenho que fazer tudo sozinho devido a inúmeras histórias de soluções de terceiros que não cumprem o que afirmam.


13
Não importa onde eles estejam armazenados ou quem os faça, a menos que você teste backups e restaurações, eles não são realmente backups.
user9517

Deixe seu servidor doméstico acessar o servidor em nuvem e faça os backups.
Cornelinux 7/01

1
Eu removi algumas referências estranhas da pergunta que achava que poderia encerrá-la, quando acho que há uma boa e principal questão de boas práticas aqui. Se alguém discordar, sinta-se à vontade para reverter as edições e / ou o VTC. E, de passagem, acho que o comentário de Iain acima sobre o teste de backups é o melhor conselho de melhores práticas que você recebeu sobre o assunto.
21717 MadHatter

Respostas:


12

É 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

  1. 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.
  2. 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

  1. 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.
  2. Use uma conta SSH limitada que tenha apenas acesso scp ao diretório de backup e apenas acesso suficiente para enviar o backup.
  3. Use uma chave privada para autenticação
  4. 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!
  5. 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)
  6. 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.
  7. 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
  8. Restrinja o acesso ao firewall para que a porta encaminhada fique visível apenas para o servidor em nuvem remoto
  9. 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.
  10. 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.


Ótima lista de precauções, obrigado. Foi como o que eu esperava ouvir. Irá avançar com isso.
Darius

Seja bem-vindo. Se eu pensar em outra coisa, editarei a resposta e comento aqui para que você saiba. Eu sou um testador profissional de penetração, então não demore muito para perceber se esqueci alguma coisa!
precisa saber é
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.