backup crittografati per Linux e FreeBSD leggibili per entrambi

8

Ho un computer Linux e un FreeBSD, entrambi crittografati (LUKS e geli rispettivamente). Mi chiedo come fare backup che sarebbero anche crittografati e sarebbero leggibili da entrambi (in modo che se uno dei computer fallisse potessi recuperare rapidamente i dati usando l'altro).

Sfortunatamente sembra che i bot LUKS e geli siano moduli del kernel per i rispettivi sistemi che non sono mai stati portati sul rispettivo altro. A giudicare dalle numerose minacce sui filesystem compatibili con BSD / Linux sembra che sia abbastanza difficile fare backup non crittografati che siano leggibili da entrambi (apparentemente ext2 è l'unica opzione per un filesystem che lo consentirebbe).

Quindi il mio pensiero era di configurare un FreeBSD virtuale nel KVM di Linux che sarebbe in grado di leggere e scrivere un disco esterno crittografato con geli e trasferire i dati su un volume ext2 virtuale non crittografato all'interno del filesystem crittografato LUKS di Linux (e viceversa) in giro). Questo, tuttavia, sembra terribilmente complicato e non sembra davvero il modo giusto per farlo.

Esistono modi migliori / più facili / più preferibili? O il modo sopra spiegato attualmente è l'opzione migliore possibile?

Grazie; Apprezzo qualsiasi pensiero in merito.

— 0range
fonte

2

L'unica cosa che vedo in questo elenco en.wikipedia.org/wiki/… supportata su entrambi è eCryptFS en.wikipedia.org/wiki/ECryptfs, tuttavia non è crittografia a livello di blocco. È un livello di filesystem.

— Zoredache,

1

Vorrei prima impostare un'altra scatola con il mio sistema operativo preferito per servire e archiviare i backup.

— Ярослав Рахматуллин,

Grazie mille a entrambi per i vostri pensieri. Spero che in futuro qualcuno porti il LUKS su FreeBSD o geli su Linux (purtroppo mi mancano sia le competenze / esperienze di programmazione necessarie sia il tempo per acquisirle.)

— 0range

3

Stabiliamo un paio di ipotesi. Commenta se quelli non sono corretti.

si eseguono macchine con sistemi operativi diversi e piattaforme potenzialmente diverse.
lo descrivi per il caso con 2 macchine e Linux e FreeBSD
le tue macchine usano filesystem crittografati
vuoi creare copie di backup dei tuoi dati e vuoi che anche quei backup vengano crittografati
si desidera poter accedere ai dati in quei backup crittografati da una qualsiasi delle piattaforme che contribuiscono all'archivio

(commento aggiunto per distinguere le forme di crittografia)

Dici che vorresti poter accedere ai dati degli altri sistemi, dalla macchina sopravvissuta. Un modo potrebbe essere quello di archiviare backup non crittografati, sul computer locale, sul suo file system crittografato. Un altro potrebbe essere quello di archiviare backup crittografati, sul computer locale, su un filesystem non crittografato. Suggerisco di archiviare backup crittografati, su filesystem non crittografati.

Tuttavia, a parte - c'è sempre una preoccupazione per i backup crittografati: - devi davvero stare attento con la chiave - la corruzione parziale di solito uccide l'intero backup

il mio consiglio: usare

Brackup , o
Duplicità

per creare backup su uno o più contenitori a cui entrambe le macchine possono accedere.

Per mantenere tutto all'interno della LAN, è possibile:

creare un filesystem "backup" su entrambi gli host, per memorizzare i "pacchetti" di backup crittografati. Non è necessario che sia un file system crittografato, poiché i "pacchetti" di backup (brackup li chiama "blocchi") memorizzati su di esso verranno crittografati
esportare questi filesystem, ad esempio con NFS, e montarlo rispettivamente su altri host
quando si creano i backup, scaricarli nel filesystem locale e copiarli nella directory montata su NFS sull'altro host. Questo ha il piacevole effetto collaterale di avere due istanze dei tuoi file di backup.

ora avrai i seguenti filesystem sui tuoi server:

su tux, la tua macchina Linux:

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

sulla bestia, la tua macchina FreeBSD:

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

a seconda della quantità di dati di cui hai bisogno per il backup, potresti anche pensare a un contenitore fuori sede, farebbe qualsiasi provider cloud. Attualmente sto giocando con la configurazione dei miei contenitori S3 in modo che le cose vecchie vengano invecchiate a Glacier, che sembra molto promettente, dal punto di vista dei prezzi.

— Florenz Kley
fonte

non esattamente. non ho bisogno che sia blocco per blocco e non ho bisogno che sia in rete (anche se gli strumenti che suggerisci sembrano molto interessanti). il problema è piuttosto (come era stato correttamente compreso da Zoredache e Ярослав Рахматуллин) che se uno dei sistemi si guasta per qualche motivo, ho bisogno di un modo per accedere ai backup. quindi i backup dovrebbero essere archiviati su un filesystem crittografato (su un altro disco) accessibile ad entrambi i sistemi. questo pone un problema in quanto sia i sistemi di crittografia nativi che i filesystem nativi di Linux e FreeBSD sono incompatibili. scusa per non aver risposto prima.

— 0

oh, e dovrei menzionare che alcuni di quei tarball sono crittografati manualmente per me come mio destinatario PGP. Le configurazioni più intelligenti in seguito hanno due file, un archivio crittografato con una chiave simmetrica e la chiave crittografata con PGP, entrambi in un altro tarball, quindi i file non vanno persi durante il trasferimento. Niente di tutto ciò è ben automatizzato come gli script citati, ma ha fatto il lavoro.

— Florenz Kley,

Non ho mai sentito parlare di doppiezza, ma sembra esattamente quello che sto cercando! Sai quanti anni ha? È stabile? Non riesco a trovare alcuna data di inizio del progetto.

— CNST

Duplicity [ duplicity.nongnu.org] esiste dal 2002, lo uso da ca. 2004.

— Florenz Kley,

@ 0range - ha eliminato un po 'la distinzione "crittografia". Quello che sto proponendo non è blocco per blocco, è basato su file. Suggerire di usare filesystem non crittografati, perché possono essere letti da entrambi i sistemi. Memorizzare su di essi backup crittografati, anch'essi possono essere letti su entrambe le piattaforme dai rispettivi strumenti nativi. Ciò dovrebbe spuntare la casella su entrambi i requisiti, la crittografia e la leggibilità, su entrambe le piattaforme.

— Florenz Kley,

2

Duplicità - ottimo strumento per questa attività, utilizza GPG per la crittografia. Lo sto usando da tempo e lo consiglio vivamente.

In alternativa puoi provare:

obnam - è un nuovo progetto, ma ha alcune caratteristiche interessanti (è un po 'lento se si usa tramite ssh / scp)
burp - crittografia con password

— spinus
fonte

vedere il mio commento alla risposta di Florenz Kley sopra. (e grazie per aver suggerito quegli strumenti)

— 0range

Spiacente, ho potuto solo aggiungere un commento qui. Questi strumenti non sono blocco per blocco, ma FS (è possibile eseguire il backup di FS e ripristinarlo anche su Windows). GPG è uno standard per la crittografia - funziona anche su entrambi. Questi programmi non sono solo di rete, è possibile eseguire il backup di dir in dir. Quindi, con la duplicità è possibile eseguire il backup di entrambe le macchine e ripristinare il backup crittografato ovunque in cui si disponga di duplicità e chiave GPG.

— Spinus,

2

TrueCrypt dovrebbe funzionare sia su Linux che su FreeBSD. Anche se uso regolarmente TrueCrypt solo su Windows e non ho provato personalmente FreeBSD Truecrypt. YMMV.

— Mikhail Kupchik
fonte

1

È possibile eseguire il backup dei file dei computer utilizzando il normale rsyncdisco rigido di altri computer. Poiché si utilizza comunque la crittografia locale, viene crittografata con la crittografia dei sistemi locali e la trasmissione è protetta da TLS. Gli aggiornamenti sono rapidi e ti attacchi con meccanismi di crittografia e backup ben collaudati.

Se devi solo fare il backup dei file su un sistema non attendibile, il semplice GPG ha funzionato bene per me. Ho automatizzato la crittografia e il trasferimento FTP con Python, che funziona bene già da due anni.

— Michael
fonte