backups criptografados para Linux e FreeBSD legíveis para ambos


8

Eu tenho um computador Linux e um FreeBSD, ambos criptografados (LUKS e geli respectivamente). Gostaria de saber como fazer backups que também seriam criptografados e legíveis para ambos (para que, se um dos computadores falhar, eu possa recuperar rapidamente os dados usando o outro).

Infelizmente, parece que bot LUKS e geli são módulos de kernel para seus respectivos sistemas que nunca foram portados para o respectivo outro. A julgar pelas várias ameaças nos sistemas de arquivos compatíveis com BSD / Linux, parece que é difícil o suficiente fazer backups não criptografados que seriam legíveis para ambos (ext2 aparentemente é a única opção para um sistema de arquivos que permitiria isso).

Então, meus pensamentos foram configurar um FreeBSD virtual no KVM do Linux, capaz de ler e gravar um disco externo criptografado em geli e transferir os dados para um volume ext2 virtual não criptografado dentro do sistema de arquivos criptografado LUKS do Linux (e de outra maneira por aí). Isso, no entanto, parece terrivelmente complicado e realmente não parece o caminho certo para fazê-lo.

Existem maneiras melhores / mais fáceis / mais preferíveis? Ou a maneira explicada acima atualmente é a melhor opção possível?

Obrigado; Agradeço qualquer opinião sobre o assunto.


2
A única coisa que vejo nesta lista en.wikipedia.org/wiki/… suportada em ambos é o eCryptFS en.wikipedia.org/wiki/ECryptfs, embora não seja a criptografia em nível de bloco. É uma camada do sistema de arquivos.
Zoredache

11
Antes, eu instalava outra caixa com meu sistema operacional favorito para servir e armazenar os backups.
#

Muito obrigado a vocês dois por seus pensamentos. Eu espero que algum tempo no futuro LUKS porta alguém vai para FreeBSD ou geli para Linux (I infelizmente não têm tanto o necessário habilidades de programação / experiência e o tempo para adquiri-los.)
0range

Respostas:


3

Vamos estabelecer algumas suposições. Comente se esses não estiverem corretos.

  1. você executa máquinas com diferentes sistemas operacionais e plataformas potencialmente diferentes.
  2. você o descreve para o caso com 2 máquinas e Linux e FreeBSD
  3. suas máquinas usam sistemas de arquivos criptografados
  4. você deseja criar backups dos seus dados e também deseja que esses backups sejam criptografados
  5. você deseja acessar dados nesses backups criptografados de qualquer uma das plataformas que contribuem para o arquivamento

(comentário adicionado para fazer uma distinção entre formas de criptografia)

Você mencionou que gostaria de poder acessar os dados de outros sistemas, a partir da máquina sobrevivente. Uma maneira poderia ser armazenar backups não criptografados, na máquina local, no sistema de arquivos criptografado. Outra poderia ser armazenar backups criptografados, na máquina local, em um sistema de arquivos não criptografado. Sugiro armazenar backups criptografados, em sistemas de arquivos não criptografados.

No entanto, como um aparte - sempre há uma preocupação com os backups criptografados: - você realmente precisa ter cuidado com a chave - a corrupção parcial geralmente mata todo o backup

minha sugestão: use

para criar backups para um ou vários contêineres que ambas as máquinas podem acessar.

Para manter tudo dentro da sua LAN, você pode:

  1. crie um sistema de arquivos "backup" nos dois hosts para armazenar os "pacotes" de backup criptografados. Ele não precisa ser um sistema de arquivos criptografado, pois os "pacotes" de backup (brackup os chama de "pedaços") armazenados nele serão criptografados
  2. exporte esses sistemas de arquivos, por exemplo, com NFS e monte-o nos outros hosts, respectivamente
  3. ao criar backups, despeje-os no sistema de arquivos local e espelhe-os no diretório montado no NFS no outro host. Isso tem o bom efeito colateral de ter duas instâncias dos seus arquivos de backup.

agora você terá os seguintes sistemas de arquivos em seus servidores:

no tux, sua máquina Linux:

/dev/foo            /           # encrypted filesystem
/dev/bar            /tuxdump    # unencrypted filesystem, local backup
beastie:/daemondump /daemondump # NFS backup destination

no beastie, sua máquina FreeBSD:

/dev/flurb          /           # encrypted filesystem
/dev/baz            /daemondump # unencrypted filesystem, local backup
tux:/tuxdump        /tuxdump    # NFS backup destination

dependendo da quantidade de dados que você precisa fazer backup, você também pode pensar em um contêiner externo, como qualquer provedor de nuvem faria. Atualmente, estou brincando com a configuração dos meus contêineres S3 para que as coisas antigas envelhecam no Glacier, o que parece muito promissor e valioso.


não exatamente. não preciso que ele seja bloco por bloco e não seja pela rede (embora as ferramentas que você sugere parecem muito interessantes). o problema é bastante (como havia sido entendido corretamente por Zoredache e Ярослав Рахматуллин) que, se algum dos sistemas quebrar por algum motivo, eu preciso de alguma maneira de acessar os backups. portanto, os backups devem ser armazenados em um sistema de arquivos criptografado (em outro disco) acessível aos dois sistemas. isso representa um problema, pois os sistemas de criptografia nativos e os sistemas de arquivos nativos do linux e do freebsd são incompatíveis. desculpe por não responder mais cedo.
precisa saber é o seguinte

ah, e devo mencionar que alguns desses tarballs são criptografados manualmente para mim como meu destinatário PGP. As configurações mais inteligentes mais tarde têm dois arquivos, um arquivo criptografado com uma chave simétrica e a chave criptografada com PGP, ambos em outro tarball, para que os arquivos não se percam na transferência. Nada disso é tão bem automatizado quanto os scripts mencionados, mas funcionou.
amigos estão dizendo

Nunca ouvi falar em duplicidade, mas parece exatamente o que estou procurando! Você sabe quantos anos tem isso? É estável? Não consigo encontrar datas de quando o projeto foi iniciado.
cnst 27/01

A duplicidade [ duplicity.nongnu.org] existe desde 2002, estou em uso desde ca. 2004.
Florenz Kley

@ 0range - limpou um pouco a distinção "criptografia". O que estou propondo não é bloco por bloco, é baseado em arquivo. Sugira a utilização de sistemas de arquivos não criptografados, porque eles podem ser lidos pelos dois sistemas. Armazene backups criptografados neles, eles também podem ser lidos nas duas plataformas pelas respectivas ferramentas nativas. Isso deve marcar os requisitos, criptografia e legibilidade nas duas plataformas.
Florenz Kley

2

Duplicidade - ótima ferramenta para esta tarefa, usa GPG para criptografia. Estou usando há algum tempo e eu realmente recomendo.

Como alternativas, você pode tentar:

  • obnam - é um projeto novo, mas possui alguns recursos interessantes (é um pouco lento se for usado através do ssh / scp)
  • arroto - criptografia com senha

veja meu comentário à resposta de Florenz Kley acima. (e graças para sugerindo essas ferramentas)
0range

Desculpe, eu só poderia adicionar comentários aqui. Essas ferramentas não são bloco a bloco, mas o FS (você pode fazer backup do FS e restaurá-lo mesmo no Windows). GPG é um padrão para criptografia - ele também funciona em ambos. Esses programas não são apenas de rede, você pode fazer backup de diretório em diretório. Portanto, com a duplicidade, você pode fazer backup de ambas as máquinas e restaurar o backup criptografado em todos os lugares onde houver duplicidade e chave GPG.
Spinus

2

O TrueCrypt deve funcionar no Linux e no FreeBSD. Embora eu use regularmente o TrueCrypt apenas no Windows e não tenha experimentado o FreeBSD Truecrypt. YMMV.


1

Você pode fazer backup dos arquivos de suas máquinas usando rsynco disco rígido comum nas outras máquinas. Como você usa criptografia local de qualquer maneira, ele é criptografado com a criptografia e a transmissão dos sistemas locais, sendo protegido pelo TLS. As atualizações são rápidas e você segue os mecanismos comprovados de criptografia e backup.

Se você apenas precisar fazer backup de arquivos em algum sistema não confiável, o GPG simples funcionou bem para mim. Automatizei alguma criptografia e transferência de FTP com python, que funciona bem há dois anos.

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.