Cloud-Encryption: Unterschied zwischen den Versionen

Aus Neobikers Wiki
Zur Navigation springen Zur Suche springen
 
(64 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== [[Cloud-Encryption|Verschlüsselung, Datensicherung, Cloud und mehr]] ==
== [[Cloud-Encryption|Verschlüsselung, Datensicherung, Cloud und mehr (Alt)]] ==
'''(En)CryptFS''' verschlüsselt Daten auf dem Fileserver. Diese werden '''verschlüsselt in beliebigen Cloud-Storage (webdav) gesichert (rsync)''', und können von beliebigen Geräten - sogar einem Live Linux auf einem USB-Stick - im Notfall gelesen werden.


Ich habe ein '''Knoppix mit verschlüsselter Datenpartition auf einem USB-Stick''' an meinem Schlüsselbund und kann damit von jedem (fremden) PC vom USB-Stick booten, eine VPN-Verbindung nach Hause aufbauen oder ein verschlüsseltes Backup-Verzeichnis aus dem Cloud-Storage mounten und auf dieses entschlüsselt zugreifen. Meine Notfall Datensicherung liegt also verschlüsselt in einem Cloud-Storage (falls meine Hütte mal abbrennt oder absäuft, oder Stromschlag alle 5 Harddisks zuhause zerstört, wo die Daten redundant liegen).


== Verschlüsselung ==
'''Hinweis''': Dieser Artikel ist veraltet. EncFS wurde durch '''GoCryptFS''' ersetzt. Lesen Sie den [[Backup in die Cloud|Artikel mit GoCryptFS]].
Nachdem meine 2TB Harddisk einen Defekt hatte, und ich 2 Wochen gebraucht habe, die Daten runter zu kratzen und anschliessend zu löschen (dd dauert bei einer defekten 2TB Disk ziemlich lange), habe ich mich entschlossen meine kritischen Daten zu verschlüsseln. Von 3 neuen Festplatten war prompt eine sofort wieder defekt, freilich erst, nachdem ich diese mit 2TB in einem RAID eingebunden und gesynced hatte. Garantie heisst: zurück zu AMAZONE ... also sollten keine Daten mehr drauf liegen - bin extrem genervt.


'''Problem''': Der (XEN-) Server muss '''vollautomatisch starten''', der '''Schlüssel darf nicht auf den Platten''' liegen!


'''Lösung''': Ich speicher den Schlüssel auf einen USB-Stick, und kopiere diesen beim booten des XEN-Host in den RAM(tmpfs)! Die virtuellen Server lesen den Schlüssel bedarfsweise per ssh vom XEN Hostsystem.
'''(En)CryptFS''' verschlüsselt Daten auf Fileebene. Diese können '''verschlüsselt''' in beliebigen Cloud-Storage (Anbindung z.B. per webdav) gesichert (z.B. mittels rsync) werden, und von beliebigen Geräten - sogar einem Live Linux auf einem USB-Stick - im Notfall gelesen werden.


== Datensicherung ==
Ich habe ein ''Knoppix'' mit '''verschlüsselter Datenpartition''' auf einem USB-Stick an meinem Schlüsselbund. Damit kann ich von jedem (fremden) PC vom USB-Stick booten, eine VPN-Verbindung nach Hause aufbauen oder ein verschlüsseltes Backup-Verzeichnis aus einem Cloud-Storage mounten und darauf entschlüsselt zugreifen. Meine Katastrophen-Datensicherung liegt somit verschlüsselt in einem Cloud-Storage - falls meine Hütte mal abbrennt oder absäuft, oder ein Blitzschlag sämtliche Harddisks zerstört, welche die Daten redundant speichern.
Jetzt wo die Daten verschlüsselt sind, können diese an beliebige Orte gesichert werden. Ich benutze zur Sicherung weiterhin rsync, jeweils den letzten Snapshot sichere jede Nacht in verschiedene Cloud-Speicher (T-Online, 1blu, ...).


== Cloud Storage ==
== Verschlüsselung mit EncFS ==
Den Cloud Storage binde ich mit '''webdav''' auf meinem Fileserver ein (T-Online), oder kann sogar direkt '''per ssh rsync''' verwenden (1blu). Webdav kann man von inzwischen überall direkt mounten (Windows und Linux Clients), sehr praktisch. Ich hab alles notwendige auf einem Knoppix-USB Stick installiert, von dem ich booten kann.
Nachdem meine 2TB Harddisk einen Defekt hatte, und ich zwei Wochen gebraucht habe, die Daten runter zu kratzen und anschliessend zu löschen (''dd'' dauert bei einer defekten 2TB Disk ziemlich lange), habe ich mich entschlossen meine persönlichen Daten zu verschlüsseln. Von drei neuen Festplatten war prompt eine sofort wieder defekt, freilich erst, nachdem ich diese mit 2TB in einem RAID eingebunden und gesynced hatte. Garantie heisst: Disk muss zurück zum Händler ... also sollten keine Daten mehr drauf liegen - ich bin extrem genervt.
 
 
'''Das Problem''': Der (XEN-) Server muss '''vollautomatisch starten''', der '''Schlüssel darf nicht auf den Platten''' liegen!
 
 
'''Die Lösung''': Ich speicher den Schlüssel auf einem USB-Stick, und kopiere diesen '''verschlüsselt''' über das Netzwerk '''in den RAM''' (tmpfs)!
 
Der Fileserver (''srv'') liest den Schlüssel ''/etc/EncFS.PWD'' per ''ssh'' vom XEN-Hostsystem (''m450''). Im Bootscript ''rc.local'' wird der Schlüssel vorher vom USB-Stick in den RAM ''"importiert"''.
 
 
'''XEN-Host'''
 
Der Schlüssel ''/etc/EncFS.PWD'' wird im RAM (tmpfs) unter ''/var/run'' gespeichert und liegt somit nicht auf der Disk!
<pre>root@m450# ls -l /etc/EncFS.PWD
lrwxrwxrwx 1 root root 18 Sep  9 17:38 /etc/EncFS.PWD -> /var/run/EncFS.PWD
 
root@m450:~# df /var/run
Dateisystem    1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
tmpfs              35780    908    34872    3% /run
 
root@m450:~# cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
 
ssh vm01 'cat /root/USB-Stick/EncFS.PWD' > /etc/EncFS.PWD # read EncFS.PWD with ssh
</pre>
 
 
'''Fileserver'''
 
Der '''Fileserver''' ''srv'' benötigt den Schlüssel ''/etc/EncFS.PWD'' zum entschlüsseln des Filesystems. Zum mounten wird ein '''Helper-Skript''' ''/usr/local/sbin/encfs.sh'' verwendet, welches in ''/etc/fstab'' eingetragen ist:
 
<pre>root@srv:~# cat /usr/local/sbin/encfs.sh
#!/bin/sh
encfs --public --extpass="ssh m450 cat /etc/EncFS.PWD" $* # get EncFS.PWD via ssh
 
 
root@srv:~# cat /etc/fstab | grep encfs
/usr/local/sbin/encfs.sh#/srv/crypt  /srv/daten  fuse noauto,kernel_cache,nofail 0 0
/usr/local/sbin/encfs.sh#/backup/snapshot/latest/srv/crypt  /backup/snapshot-latest  fuse noauto,nofail,ro  0 0
</pre>
 
 
'''Daten'''
 
Die Daten liegen verschlüsselt im Verzeichnis ''/srv/crypt'', und werden entschlüsselt unter ''/srv/daten'' vom Fileserver zur Verfügung gestellt (CIFS, NFS). Anwender können auf die letzte Datensicherung im einfachen ''Self-Service'' über ''/backup/snapshot-latest'' zugreifen (Read-Only).
 
 
'''EncFS (Encrypted Filesystem)'''
 
Erstelle ein verschlüsseltes Verzeichnis ''/srv/crypt'', welches unter ''/srv/daten'' entschlüsselt vorliegt:
<pre>root@srv# encfs /src/crypt /srv/daten
Directory "/srv/crypt" does not exist, create (y,n)?y
Directory "/srv/daten" does not exist, create (y,n)?y
Creating new encrypted volume.
Please choose from one of the following options:
  enter "x" for expert configuration mode,
  enter "p" for pre-configured paranoia mode,
  anything else, or an empty line will select standard mode.
?>
 
Standard configuration selected.
Using cipher Blowfish, key size 160, block size 512
New Password: <password entered here>
Verify: <password entered here>
</pre>
Das Passwort speichere ich auf einem USB-Stick und importiere es später als ''/etc/EncFS.PWD'' auf dem XEN-Host (siehe oben).
 
Neben dem Passwort wird eine Konfigurationsdatei ''.encfs6.xml'' benötigt, welche durch ''encfs'' automatisch im verschlüsselten Verzeichnis ''/srv/crypt'' erstellt wird. In die Cloud synchronisiere ich diese Konfigurationsdatei aus Sicherheitsgründen nicht, selbst wenn diese nur in Kombination mit dem Passwort/Schlüssel ''EncFS.PWD'' verwendbar ist. Ich kopiere stattdessen einfach eine modifizierte nicht funktionsfähige Konfigurationsdatei ''.encfs6.xml'' in die Cloud, welche ich auf meinen eigenen Rechnern mittels <pre>root@client# mount -bind .encfs6.xml .encfs6.xml.working</pre> mit der korrekten Version ''überschreibe'', bevor ich diesen Cloud-Storage wieder auf meinen Rechnern entschlüssele.
 
=== Datensicherung ===
Verschlüsselte Daten können an beliebigen Orte gesichert werden. Ich benutze zur Sicherung ''rsync'', der letzte Snapshot wird jede Nacht in verschiedene Cloud-Speicher (T-Online, 1blu, ...) synchronisert.
 
Meine ''rsync-snapshot'' Datensicherung legt Snapshots im Verzeichnis '''/backup/snapshot''' an, welche vom Fileserver bei Bedarf (readonly!) gemounted werden können.
 
Das verschlüsselte Verzeichnis '''/backup/snapshot/latest/srv/crypt''' wird jede Nacht per ''rsync'' in Cloud-Storage gesichert.
 
=== Cloud Storage ===
Cloud-Storage binde ich per ''webdav'' auf meinem Rechner ein. Teilweise kann sogar direkt ''rsync über ssh '' zur Synchronisation verwendet werden. ''Webdav''-Storage kann man inzwischen meist direkt verwenden (Windows und Linux Clients), sehr praktisch.
 
'''Webdav'''
 
Cloud-Storage wird unter Linux mittels ''webdav'' eingebunden, die Konfiguration liegt unter ''/etc/davfs2'':
<pre>root@srv:/etc/davfs2# l
insgesamt 12
drwxr-xr-x 3 root root 4096 Sep 12 21:41 certs
-rw-r--r-- 1 root root 2319 Dez  7 19:12 davfs2.conf
-rw------- 1 root root 2720 Sep 12 22:33 secrets
 
 
root@srv:/etc/davfs2# cat davfs2.conf
# davfs2 configuration file 2009-04-12
# version 9
# ------------------------------------
 
# Copyright (C) 2006, 2007, 2008, 2009 Werner Baumann
 
# Copying and distribution of this file, with or without modification, are
# permitted in any medium without royalty provided the copyright notice
# and this notice are preserved.
 
 
# Please read the davfs2.conf (5) man page for a description of the
# configuration options and syntax rules.
 
if_match_bug 1
use_locks 0
cache_size 20480 # MiByte
table_size 4096
delay_upload 1
gui_optimize 1
 
dir_refresh  60  # seconds
file_refresh 10  # second
cache_dir /var/cache/davfs2 # system wide cache
 
...
</pre>
Beispielkonfiguration mit einem relativ grossem Cache(!).
 
 
Die '''Webdav Zugangsdaten''' stehen in ''/etc/davfs2/secrets''
<pre>root@srv:/etc/davfs2# cat secrets
# davfs2 secrets file  2009-10-18
# version 4
# -------------------------------
 
# Copyright (C) 2006, 2007, 2008, 2009 Werner Baumann
 
# Copying and distribution of this file, with or without modification, are
# permitted in any medium without royalty provided the copyright notice
# and this notice are preserved.
 
 
# # This file must be readable and writeable by the owner only (mode 0600).
 
...
 
/backup/cloud/t-online/neobiker  <account@t-online.de>  <mycloudpassword>
...
</pre>
Die Cloud-Storages liegen unter ''/backup/cloud/<Provider>/<account>'' auf meinem Server.
 
Die korrespondierenden ''/etc/fstab'' Einträge sehen dann so aus:
<pre>root@srv:/etc/davfs2# cat /etc/fstab | grep -i t-online
# T-Online Mediencenter
https://webdav.mediencenter.t-online.de/ /backup/cloud/t-online/neobiker davfs _netdev,rw,noauto,uid=neobiker,gid=neobiker,file_mode=777,dir_mode=777 0 0
</pre>
 
 
Man mounted den Cloud-Storage jetzt einfach mittels
<pre>root@srv# mount /backup/cloud/t-online/neobiker
</pre>
und kann diesen anschliessend wie ein normales Verzeichnis lesend und schreibend nutzen (abgesehen von der Performance der Internetverbiundung).
 
 
Zusätzlich zu den "normalen Cloud-Verzeichnissen" habe ich ein Verzeichnis ''mybackup'' angelegt, in welches ich meine verschlüsselten Backupdateien synchronisiere. Dieses Verzeichnis ''mybackup'' ist also nicht lesbar, es enthält nur verschlüsselte Dateien und Verzeichnisse.
 
Das wird durch ''encfs'' einfach wieder entschlüsselt in einem anderen Verzeichnis gemounted:
<pre>root@srv:/etc/davfs2# cat /etc/fstab | grep -i t-online
/usr/local/sbin/encfs.sh#/backup/cloud/t-online/neobiker/mybackup /backup/cloud/t-online/neobiker-decrypt fuse noauto,nofail,ro 0 0
</pre>
 
Voilà, die verschlüsselten Cloud-Storage (Backup-)dateien können unter ''/backup/cloud/t-online/neobiker-decrypt'' wieder lesbar auf einem Client gemounted werden.

Aktuelle Version vom 5. Dezember 2020, 20:50 Uhr

Verschlüsselung, Datensicherung, Cloud und mehr (Alt)

Hinweis: Dieser Artikel ist veraltet. EncFS wurde durch GoCryptFS ersetzt. Lesen Sie den Artikel mit GoCryptFS.


(En)CryptFS verschlüsselt Daten auf Fileebene. Diese können verschlüsselt in beliebigen Cloud-Storage (Anbindung z.B. per webdav) gesichert (z.B. mittels rsync) werden, und von beliebigen Geräten - sogar einem Live Linux auf einem USB-Stick - im Notfall gelesen werden.

Ich habe ein Knoppix mit verschlüsselter Datenpartition auf einem USB-Stick an meinem Schlüsselbund. Damit kann ich von jedem (fremden) PC vom USB-Stick booten, eine VPN-Verbindung nach Hause aufbauen oder ein verschlüsseltes Backup-Verzeichnis aus einem Cloud-Storage mounten und darauf entschlüsselt zugreifen. Meine Katastrophen-Datensicherung liegt somit verschlüsselt in einem Cloud-Storage - falls meine Hütte mal abbrennt oder absäuft, oder ein Blitzschlag sämtliche Harddisks zerstört, welche die Daten redundant speichern.

Verschlüsselung mit EncFS

Nachdem meine 2TB Harddisk einen Defekt hatte, und ich zwei Wochen gebraucht habe, die Daten runter zu kratzen und anschliessend zu löschen (dd dauert bei einer defekten 2TB Disk ziemlich lange), habe ich mich entschlossen meine persönlichen Daten zu verschlüsseln. Von drei neuen Festplatten war prompt eine sofort wieder defekt, freilich erst, nachdem ich diese mit 2TB in einem RAID eingebunden und gesynced hatte. Garantie heisst: Disk muss zurück zum Händler ... also sollten keine Daten mehr drauf liegen - ich bin extrem genervt.


Das Problem: Der (XEN-) Server muss vollautomatisch starten, der Schlüssel darf nicht auf den Platten liegen!


Die Lösung: Ich speicher den Schlüssel auf einem USB-Stick, und kopiere diesen verschlüsselt über das Netzwerk in den RAM (tmpfs)!

Der Fileserver (srv) liest den Schlüssel /etc/EncFS.PWD per ssh vom XEN-Hostsystem (m450). Im Bootscript rc.local wird der Schlüssel vorher vom USB-Stick in den RAM "importiert".


XEN-Host

Der Schlüssel /etc/EncFS.PWD wird im RAM (tmpfs) unter /var/run gespeichert und liegt somit nicht auf der Disk!

root@m450# ls -l /etc/EncFS.PWD
lrwxrwxrwx 1 root root 18 Sep  9 17:38 /etc/EncFS.PWD -> /var/run/EncFS.PWD

root@m450:~# df /var/run
Dateisystem    1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
tmpfs              35780     908     34872    3% /run

root@m450:~# cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

ssh vm01 'cat /root/USB-Stick/EncFS.PWD' > /etc/EncFS.PWD # read EncFS.PWD with ssh


Fileserver

Der Fileserver srv benötigt den Schlüssel /etc/EncFS.PWD zum entschlüsseln des Filesystems. Zum mounten wird ein Helper-Skript /usr/local/sbin/encfs.sh verwendet, welches in /etc/fstab eingetragen ist:

root@srv:~# cat /usr/local/sbin/encfs.sh
#!/bin/sh
encfs --public --extpass="ssh m450 cat /etc/EncFS.PWD" $* # get EncFS.PWD via ssh


root@srv:~# cat /etc/fstab | grep encfs
/usr/local/sbin/encfs.sh#/srv/crypt  /srv/daten  fuse noauto,kernel_cache,nofail 0 0
/usr/local/sbin/encfs.sh#/backup/snapshot/latest/srv/crypt  /backup/snapshot-latest  fuse noauto,nofail,ro  0 0


Daten

Die Daten liegen verschlüsselt im Verzeichnis /srv/crypt, und werden entschlüsselt unter /srv/daten vom Fileserver zur Verfügung gestellt (CIFS, NFS). Anwender können auf die letzte Datensicherung im einfachen Self-Service über /backup/snapshot-latest zugreifen (Read-Only).


EncFS (Encrypted Filesystem)

Erstelle ein verschlüsseltes Verzeichnis /srv/crypt, welches unter /srv/daten entschlüsselt vorliegt:

root@srv# encfs /src/crypt /srv/daten
Directory "/srv/crypt" does not exist, create (y,n)?y
Directory "/srv/daten" does not exist, create (y,n)?y
Creating new encrypted volume.
Please choose from one of the following options:
  enter "x" for expert configuration mode,
  enter "p" for pre-configured paranoia mode,
  anything else, or an empty line will select standard mode.
?>

Standard configuration selected.
Using cipher Blowfish, key size 160, block size 512
New Password: <password entered here>
Verify: <password entered here>

Das Passwort speichere ich auf einem USB-Stick und importiere es später als /etc/EncFS.PWD auf dem XEN-Host (siehe oben).

Neben dem Passwort wird eine Konfigurationsdatei .encfs6.xml benötigt, welche durch encfs automatisch im verschlüsselten Verzeichnis /srv/crypt erstellt wird. In die Cloud synchronisiere ich diese Konfigurationsdatei aus Sicherheitsgründen nicht, selbst wenn diese nur in Kombination mit dem Passwort/Schlüssel EncFS.PWD verwendbar ist. Ich kopiere stattdessen einfach eine modifizierte nicht funktionsfähige Konfigurationsdatei .encfs6.xml in die Cloud, welche ich auf meinen eigenen Rechnern mittels

root@client# mount -bind .encfs6.xml .encfs6.xml.working

mit der korrekten Version überschreibe, bevor ich diesen Cloud-Storage wieder auf meinen Rechnern entschlüssele.

Datensicherung

Verschlüsselte Daten können an beliebigen Orte gesichert werden. Ich benutze zur Sicherung rsync, der letzte Snapshot wird jede Nacht in verschiedene Cloud-Speicher (T-Online, 1blu, ...) synchronisert.

Meine rsync-snapshot Datensicherung legt Snapshots im Verzeichnis /backup/snapshot an, welche vom Fileserver bei Bedarf (readonly!) gemounted werden können.

Das verschlüsselte Verzeichnis /backup/snapshot/latest/srv/crypt wird jede Nacht per rsync in Cloud-Storage gesichert.

Cloud Storage

Cloud-Storage binde ich per webdav auf meinem Rechner ein. Teilweise kann sogar direkt rsync über ssh zur Synchronisation verwendet werden. Webdav-Storage kann man inzwischen meist direkt verwenden (Windows und Linux Clients), sehr praktisch.

Webdav

Cloud-Storage wird unter Linux mittels webdav eingebunden, die Konfiguration liegt unter /etc/davfs2:

root@srv:/etc/davfs2# l
insgesamt 12
drwxr-xr-x 3 root root 4096 Sep 12 21:41 certs
-rw-r--r-- 1 root root 2319 Dez  7 19:12 davfs2.conf
-rw------- 1 root root 2720 Sep 12 22:33 secrets


root@srv:/etc/davfs2# cat davfs2.conf
# davfs2 configuration file 2009-04-12
# version 9
# ------------------------------------

# Copyright (C) 2006, 2007, 2008, 2009 Werner Baumann

# Copying and distribution of this file, with or without modification, are
# permitted in any medium without royalty provided the copyright notice
# and this notice are preserved.


# Please read the davfs2.conf (5) man page for a description of the
# configuration options and syntax rules.

if_match_bug 1
use_locks 0
cache_size 20480 # MiByte
table_size 4096
delay_upload 1
gui_optimize 1

dir_refresh  60  # seconds
file_refresh 10  # second
cache_dir /var/cache/davfs2 # system wide cache

...

Beispielkonfiguration mit einem relativ grossem Cache(!).


Die Webdav Zugangsdaten stehen in /etc/davfs2/secrets

root@srv:/etc/davfs2# cat secrets
# davfs2 secrets file  2009-10-18
# version 4
# -------------------------------

# Copyright (C) 2006, 2007, 2008, 2009 Werner Baumann

# Copying and distribution of this file, with or without modification, are
# permitted in any medium without royalty provided the copyright notice
# and this notice are preserved.


# # This file must be readable and writeable by the owner only (mode 0600).

...

/backup/cloud/t-online/neobiker   <account@t-online.de>   <mycloudpassword> 
...

Die Cloud-Storages liegen unter /backup/cloud/<Provider>/<account> auf meinem Server.

Die korrespondierenden /etc/fstab Einträge sehen dann so aus:

root@srv:/etc/davfs2# cat /etc/fstab | grep -i t-online
# T-Online Mediencenter
https://webdav.mediencenter.t-online.de/ /backup/cloud/t-online/neobiker davfs _netdev,rw,noauto,uid=neobiker,gid=neobiker,file_mode=777,dir_mode=777 0 0


Man mounted den Cloud-Storage jetzt einfach mittels

root@srv# mount /backup/cloud/t-online/neobiker

und kann diesen anschliessend wie ein normales Verzeichnis lesend und schreibend nutzen (abgesehen von der Performance der Internetverbiundung).


Zusätzlich zu den "normalen Cloud-Verzeichnissen" habe ich ein Verzeichnis mybackup angelegt, in welches ich meine verschlüsselten Backupdateien synchronisiere. Dieses Verzeichnis mybackup ist also nicht lesbar, es enthält nur verschlüsselte Dateien und Verzeichnisse.

Das wird durch encfs einfach wieder entschlüsselt in einem anderen Verzeichnis gemounted:

root@srv:/etc/davfs2# cat /etc/fstab | grep -i t-online
/usr/local/sbin/encfs.sh#/backup/cloud/t-online/neobiker/mybackup /backup/cloud/t-online/neobiker-decrypt fuse noauto,nofail,ro 0 0

Voilà, die verschlüsselten Cloud-Storage (Backup-)dateien können unter /backup/cloud/t-online/neobiker-decrypt wieder lesbar auf einem Client gemounted werden.