Seite wählen

NETWAYS Blog

Verschlüsselten File-Container mittels cryptsetup und LUKS erstellen

von | Jul 25, 2018 | , , ,


Datenschutz wird im Jahr 2018 so groß geschrieben wie nie zuvor. Verschiedene Anforderungen an die Absicherung der Daten zwingen Admins, sich elegante und sichere Setups einfallen zu lassen. Ich nehme das zum Anlass, eine neue Serie zur Dateiverschlüsselung zu eröffnen, bei der es um die verschiedensten Möglichkeiten geht, die gespeicherten Daten gegen den Zugriff Unbefugter abzusichern.
Oftmals ist eine Verschlüsselung der Daten aufgrund bestehender Infrastrukturen oder mangels Rechten (z. B. bei extern angemieteten Storages) nicht so einfach möglich. Früher war hier ECryptFS im Linux-Umfeld und TrueCrypt bei Windows State of the Art. Heute haben sich die Anforderungen geändert und ECryptFS ist wegen einer zu restriktiven Beschränkungen der Dateinamen nicht mehr alltagstauglich. Daher stelle ich hier eine moderne Alternative mit cryptsetup in Ergänzung mit LUKS vor.

Vorbereitung

Installation von cryptsetup (Beispiel Debian-Derivate)

sudo apt-get install cryptsetup

Laden des Kernel-Moduls (nur bei initialer Einrichtung)

sudo modprobe dm-crypt

File-Container erstellen

Zunächst wird mittels dd ein File-Container mit 1GB Größe erstellt, der Wert kann natürlich je nach Anforderung angepasst werden

dd if=/dev/zero of=/storage/my_container bs=1M count=1024

File-Container mittels cryptsetup initialisieren

 cryptsetup -y luksFormat /storage/my_container

Nun die gewünschte Passphrase eingeben. Aber Achtung, ohne ein gut gewähltes Passwort nutzt die stärkste Verschlüsselung nichts!
Verschlüsselten Container öffnen und Dateisystem erstellen

cryptsetup luksOpen /storage/my_container my_mount

hier wird das Kennwort abgefragt, dies sollte man sich natürlich zuvor gut merken. Der Container ist nun unter /dev/mapper/my_mount eingebunden.  Anschließend wird ein ext4-Dateisystem in dem Container erzeugt.

mkfs.ext4 -j /dev/mapper/my_mount

File-Container am Wunschort mounten

Ordner zum mounten erstellen

mkdir /my_data
mount /dev/mapper/my_mount /my_data

Fertig – alle Daten die nun in /my_data erzeugt werden, landen am Ende verschlüsselt im Container, wie in meinem Beispiel unter /storage/my_container

Mount aushängen und File-Container schließen

Damit die Daten während der Nichtnutzung auch wirklich sicher sind, empfehle ich, den Container wieder abzuschließen.

umount /my_data
cryptsetup luksClose my_mount

Protip

Ich habe auf diese Art der Verschlüsselung bei meiner Nextcloud zurückgegriffen, da mir die Bordmittel von Nextcloud nicht gefallen, oder zu langsam sind. Im nächsten Artikel werde ich auch erklären, wie man den Container entsprechend vergrößern kann. Alle mit my_ verwendeten Variablen, können natürlich auf die jeweiligen Bedürfnisse angepasst werden.

Haben wollen?

Wir bieten natürlich bei uns im Managed-Hosting individuelle Lösungen an. Falls unsere (potentiellen) Kunden ein solches Setup wünschen, so sind wir natürlich für jeden Spaß zu haben.

Disclaimer

LUKS verwaltet die Verschlüsselungsdaten im Header. Ohne den Header (oder im Falle einer Beschädigung), ist ein Zugriff auf die Daten nicht mehr möglich. Es gibt verschiedene Tools, wie beispielsweise zuluCrypt, mit denen die Schlüssel und Header verwaltet und gesichert werden können, doch dazu in einem späteren Artikel mehr. Die Anleitung wurde nach bestem Wissen und Gewissen erstellt, testet bitte jedoch selbst ausreichend, bevor diese Lösung in die Produktion geht, damit das ihr die Funktionsweise versteht und Datenverlust vermeidet.

How to configure a Windows machine to allow file sharing with a DNS Alias

von | Dez 16, 2014 |

Last week we moved our cifs share from a Netapp filer to a Ceph disk mounted on a virtual windows server handling the share. After that, we configured the share and changed the DNS Alias to the new IP on the Windows server. Now every Windows and Mac client is able to mount the new share with the new dns alias – except the Linux clients, which got some errors like:

mount error(5): Input/output error
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

On Windows machines file sharing can work via the computer name, with or without full qualification, or by the IP Address. By default however, file sharing will not work with DNS aliases (in our case just the Linux clients). To enable filesharing to work with DNS aliases, you must make registry changes and reboot the machine.
The solution for this is setting „DisableStrictNameChecking“ to allow other machines to use filesharing via the DNS Alias. This change will allow other machines on the network to connect to the machine using any arbitrary hostname:
Add the value „DisableStrictNameChecking“ of type DWORD and set it to 1:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

On Windows Server 2008 R2:
Add the value „DnsOnWire“ of type DWORD and set it to 1

HKLM\SYSTEM\CurrentControlSet\Control\Print

This change will not allow a machine to connect to itself via a hostname. For that you need „BackConnectionHostNames“ to allow a server machine to use filesharing with itself via the DNS Alias.
Add a new Multi-String Value „BackConnectionHostNames“

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

In the Value data box, type the CNAME or the DNS alias, that is used for the local shares on the computer, and then click OK.
Note: Type each host name on a separate line.

Martin Schuster
Martin Schuster
Senior Systems Engineer
Martin gehört zu den Urgesteinen bei NETWAYS. Wenn keiner mehr weiss, warum irgendwas so ist, wie es ist, dann wird Martin gefragt. Er hat es dann eigentlich immer mal schon vor Jahren gesehen und kann Abhilfe schaffen :). Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren oder zieht einfach um und fängt von vorne an.
Lies mehr von Martin und triff unser Team

Apple Time Machine mit Netzwerk Share verwenden

von | Jun 24, 2009 |

Normalerweise kann die in Mac OS X integrierte Backup Software Time Machine nur auf lokal angeschlossene Festplatten oder auf die teure Hardwarelösung Time Capsule sichern. Es gibt jedoch einen Trick, mit dem man auch gemountete Shares eines Servers verwenden kann und dabei ist es ganz egal, ob es sich um Samba (SMB), NFS oder AFS Shares handelt.
Die folgende Anleitung bescheibt, wie es am besten gelingt:

  1. Zuerst muss man auf dem Mac einen versteckten Konfigurationsparameter setzen, damit Netzlaufwerke überhaupt in Time Machine angezeigt werden. Dazu ruft man das Terminal auf und gibt in das Fenster den folgenden Befehl in einer Zeile ein (am besten per Copy und Paste einfügen):
    [code language=“shell“]defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1[/code]
  2. Zum Speichern der Backup Dateien benutzt OS X ein sogenanntes Sparse Bundel, das auf einer lokalen USB Festplatte automatisch angelegt wird. Leider funktioniert das nicht auf dem Netzwerkshare und so muß man das Sparse Bundle manuell erzeugen. Dazu startet man das Festplattendienstprogramm und klickt anschließend auf den Button „Neues Image erstellen“:
    festplattendienstprogramm
  3. Im anschließenden Dialog gibt man zuerst einen Dateinamen, beispielsweise „timemachine“ und gibt als Speicherort den Schreibtisch an. Wir müssen die Datei später sowieso auf den Server verschieben. Als nächstes sollte man die letzte Option „Image-Format“ ändern (letzter Auswahlpunkt). Dieses Dropdown steht normalerweise auf „Beschreibbares Image“ und muß unbedingt auf „Mitwachsendes Bundle-Image“ geändert werden. Danach kann man noch eine maximale Größe für die Imagedatei angeben. Dieser Wert steht normalerweise auf 100MB, was natürlich viel zu wenig ist. Ich habe hier 300GB als Maximalwert angegeben. Gibt man nichts an, kann die Datei theoretisch so groß werden, wie Speicherplatz auf dem Server zur Verfügung steht. Am Anfang ist das Image ca. 150MB groß und wächst automatisch, bis das eingestellte Limit erreicht ist, danach fängt Time Machine an ältere Backups zu löschen. Optional kann man noch den Volumenamen setzen, so dass man das gemountete Image später leicht identifizieren kann. Hier ein Beispiel, wie ich meine Daten angegeben habe:
    createimage
  4. Nach dem Klick auf „Erstellen“ generiert OS X die Datei, welche dann auf dem Schreibtisch liegt.
  5. Danach mounted man das Servershare, auf dem man seine Time Machine Backups speichern will und verschiebt die gerade erstellte Datei auf dieses Share.
  6. Dann kann man Time Machine zum ersten Mal starten. Man ruft also Time Machine in den Systemeinstellungen auf, gibt das gemountete Share als Backup Volumen an und konfiguriert seine Optionen. Insbesondere sollte man Verzeichnisse, die man nicht mehr extra sichern muss, aus dem Backup ausschließen. Bei mir sind das die Verzeichnisse Downloads, ein temporäres Verzeichnis, Filme und die Datenbankdatei von Entourage, weil meine E-Mails ja sowieso nochmal auf dem Server liegen.
  7. Anschließen kann man das erste Backup starten, allerdings sollte man dabei noch das gemountete Share im Finder geöffnet haben, denn Time Machine versucht nun eine eigene Sparsebundel Datei zu erstellen. Sobald die Datei im Finder erscheint, kopiert man sich den Namen per Copy und Paste in die Zwischenablage. Danach kann man das Backup gleich wieder abbrechen, denn es wird sowieso fehlschlagen, da die Bundle Datei nicht erfolgreich angelegt werden kann.
  8. Nun muss man nur noch die selbst erstellte Bundel Datei in den gerade per Copy und Paste gesicherten Namen umbenennen und das „tmp“ aus dem Namen entfernen. Aus „jhein MacBook_002500ac9213.tmp.sparsebundle“ wird also „jhein MacBook_002500ac9213.sparsebundle“. Alternativ kann man den Namen auch manuell vergeben, denn er besteht aus „Rechnername_MacAdresse.sparsebundle“
  9. Danach kann man Time Machine nochmal manuell starten und dieses mal sollte es fehlerfrei durchlaufen.

Der erste Durchlauf hat bei mir mit fast 120 GB zu sichernden Daten ein bisschen gedauert. Seit diesem ersten Start laufen alle nachfolgenden Backups aber schon seit mehreren Tagen schnell und vor allem fehlerfrei durch. Um das ganze zu testen habe ich einige Files wieder zurückgesichert, ohne dass Probleme aufgetreten sind.

Julian Hein
Julian Hein
Executive Chairman
Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.
Lies mehr von Julian und triff unser Team

Trainings

Web Services

Events