Como desencorajar um hacker com acesso root de excluir backups remotos?

Question

Atualmente estou pesquisando a melhor solução de backup para o meu servidor do CentOS, e estou pensando em ir com o Tarsnap ou o Amazon S3.

Estou tentando descobrir como desencorajar um hacker a excluir o conteúdo do meu servidor e meus backups remotos, no pior caso em que ele obtém acesso root ao meu servidor e, portanto, tem acesso às credenciais de autenticação de backup remoto. (Compreendo perfeitamente a importância de ter uma senha strong e / ou de impingir apenas a autenticação SSH com base em chave, bem como outras práticas gerais de segurança. Mas, às vezes, acontece uma vulnerabilidade do Linux ou uma vulnerabilidade no nível VPS do meu host, ou algo mais, mais ou menos fora do meu controle.)

Eu sei que tanto o Tarsnap quanto o Amazon S3 têm permissões de usuário somente para gravação, mas o problema é que eu também preciso de poda / rotação automatizada de backup. Seria possível configurar qualquer um desses serviços (ou possivelmente algum outro serviço) para impedir a exclusão de gerações de backups mais recentes do que, digamos, dois dias? Isso me daria um buffer de dois dias para perceber que eu fui hackeado e impedir que o hacker excluísse minhas mais novas gerações de dados.

Ou alguma outra ideia? Muito obrigado!

    

Answer 1

em um nível fundamental, seu problema é exacerbado em parte ao enviar seus backups do host, em vez de tirá-los dele.

Você pode corrigir esse problema e, além disso, fisicamente (ou logicamente, se necessário) desconectar os volumes de backup no host de backup central.

Eu tenho máquinas que enviam backups para o S3, mas esses buckets do S3 usam controle de versão para que um invasor que faça um backup incorreto não seja um problema (e as chaves de api usadas não têm direitos para excluir objetos, apenas adicioná-las) . Eu podar backups antigos com boto como controle de versão e ciclo de vida do balde ao mesmo tempo não é permitido).

Nenhum incentivo vai funcionar, essas pessoas não se importam com seus dados.

    

Answer 2

Bem, acabei indo com o Duplicity, pois ele tem sua própria interface do Amazon S3. Eu criei um usuário do Amazon S3 via IAM com permissões limitadas apenas para objetos GETting e PUTting. Estou usando a opção --full-if-older-than Duplicity para criar um novo backup completo a cada sete dias. Então eu tenho uma política de ciclo de vida S3 automática no local que move objetos com mais de 10 dias para o Glacier. Em seguida, uma regra secundária exclui objetos que são mais antigos que 102 dias do Glacier (adicionei um pouco de slop extra apenas para ter certeza de que não receberei as taxas de exclusão antecipada do Glacier antes de 90 dias). Então, isso me dará mais de 80 dias de backups no Glacier (uma vez que o backup completo mais antigo for excluído, seus incrementos filhos continuarão existindo por mais alguns dias, mas não serão mais válidos) e outros 10 dias dos backups mais recentes no S3 . Com as atualizações diferenciais e a compactação, meus backups diários são muito pequenos, por isso deve ser extremamente econômico.

Obrigado a todos pela ajuda e sugestões.