A coisa mais simples provavelmente seria ir para o outro lado com os backups, ie. puxar do servidor de backup. É assim que eu executo meus backups com o rdiff-backup.
Considere este cenário: Eu tenho o servidor linux, que é automaticamente copiado diariamente para algum local remoto via rsync ou algo assim. Tudo está bem até que algum malvado tenha acesso ao servidor, encontre meu script de backup automatizado e exclua todo o servidor de backup de formulário também.
Estou tentando encontrar algum utilitário de backup remoto que permita apenas adicionar backups remotamente, mas não removê-los. Eu não sei como fazer qualquer coisa que use ssh somente para gravação, e eu tentei encontrar algo que não usa ssh, mas encontrei apenas Backup de caixas .
Eu agora é possível, mas quero saber se existe alguma maneira canônica de conseguir isso.
Eu tenho muitas respostas, graças a todos!
Se você estiver fazendo um backup ingênuo (cópia única, sobrescrevendo todos os dados), não há como conseguir o que deseja - um invasor sempre pode "fazer backup" de uma pilha de arquivos vazios (ou um conjunto de arquivos vazio) resultará em todos os seus dados indo bye-bye. Portanto, estou assumindo aqui que você está fazendo backups de arquivamento adequados e está monitorando seus backups o suficiente para que qualquer tentativa de erradicar o backup enviando um conjunto de backup vazio seja detectada antes que qualquer dano permanente seja feito.
Se o seu rsync-over- (presumivelmente) -SSH usa um comando forçado para executar rsync no destino, então você está tão protegido quanto possível da exclusão. Como você só deseja executar um comando rsync específico, pode codificar todos os argumentos e, em seguida, a única coisa que pode fazer é gravar novos dados. O arquivamento é bastante simples fazendo backup de uma nova árvore a cada vez e associando arquivos inalterados ao backup anterior usando hardlinks, o que economiza espaço e tempo de transferência.
O outro caminho a seguir é usar backups pull, em que o servidor de backup inicia e gerencia a operação rsync - isso significa que a máquina cliente nem mesmo tem a capacidade de executar um comando rsync restrito, o que significa o invasor não tem poder para excluir arquivos.
Isso tudo pressupõe que seu servidor de backup é seguro. Se o invasor puder ter acesso a ele por outros meios, você é desossado, independentemente do que fizer.
Este é um dos recursos que eu mais gosto no serviço de backup Tarsnap . Permite-me criar subchaves com capacidades de leitura, escrita e / ou eliminação.
Nos meus servidores, geralmente mantenho subchaves com recursos de leitura e gravação. Às vezes, quando preciso / quero remover arquivos de backup antigos, faço isso usando as chaves mestras do meu computador desktop local.
Observe que o Tarsnap é, por si só, um serviço de armazenamento. Você não pode usar o software Tarsnap para criar backups em seus servidores de armazenamento.
ftp: por exemplo, o vsftp tem uma opção para desabilitar exclusões, então você só pode fazer o upload. Depois, do outro lado, você cria um script que exclui backups com mais de x dias. Eu uso essa opção, nos backups do servidor principal são backups simples usando tar + gz, eles são enviados para um servidor nas via sftp e, em seguida, o servidor nas exclui backups com mais de 7 dias.
rsync: o servidor rsync tem uma opção para desabilitar as exclusões, o que também pode funcionar para você, mas você precisa usar o protocolo / servidor rsync. recusar opções = excluir
Mas você teria que excluir manualmente os arquivos "delete" de vez em quando.
Tente usar uma camada do sistema de arquivos somente para gravação que irá mascarar o seu destino real.
Eu encontrei um exemplo aqui, usando o FUSE .
Você também pode usar um sistema de arquivos criptografado que qualquer um pode gravar, mas precisa que seu certificado de chave seja alterado (parece ser a opção mais segura, embora provavelmente precise de mais planejamento durante a implementação). Se você seguir este caminho, consulte o WOCFS (Sistema de Arquivos somente Criptografado) e TrueCrypt
Assim, enquanto a primeira solução irá "mascarar" o seu sistema de arquivos, que é realmente armazenado em outro lugar dentro da máquina e pode ser alterado para os usuários do sistema com permissões, na segunda solução ele só pode ser alterado com as chaves apropriadas. / p>
Então, aprendi que existem duas estratégias básicas:
Cite o rdiff-backup manpage relacionado à segunda estratégia:
Although ssh itself may be secure, using rdiff-backup in the default way presents some security risks. For instance if the server is run as root, then an attacker who compromised the client could then use rdiff- backup to overwrite arbitrary server files by "backing up" over them. Such a setup can be made more secure by using the sshd configuration option command="rdiff-backup --server" possibly along with the --restrict* options to rdiff-backup. For more information, see the web page, the wiki, and the entries for the --restrict* options on this man page.
--restrict-update-only path
ike --restrict, but only allow writes as part of an incremental
backup. Requests for other types of writes (for instance,
deleting path) will be rejected.
É claro que seus backups devem ser incrementais, e você deve ter algum sistema de monitoramento em vigor, para evitar situações em que os backups de hackers excluam dados para eventualmente "deslocar" dados reais de seu sistema de backup incremental.