NEWS / BLOG auf DICKE-AERSCHE.DE

UK-Flag Click here to access my english BLOG US-Flag

Anzeige:
blog.dicke-aersche.de in 2D-QR-Barcode T-Shirt Shop von Dicke-Aersche.de blog.dicke-aersche.de in 2D-QR-Barcode



search 2013 adfgs

Klaut die Cloud!

2011-03-15, 02:06 CET

Also theoretisch müßte man jetzt was über Japan, Tsunamis, Atom-SuperGAUs usw. schreiben. Das machen aber schon genug andere und ehrlich gesagt, mir reichen diese Bilder so langsam. Es ist grauenhaft, ja. Aber Japaner sind auch deshalb so ruhig, weil die immer mal wieder in ihrer Geschichte voll auf die Fresse kriegen, die können damit besser umgehen als jeder andere von uns. Insofern: ich glaube an deren Wiederauferstehungskraft: Erneuerung! (Bitte ohne Karussell…)

Deshalb werde ich jetzt niemanden enttäuschen und weiterhin technisches Gesülze von mir geben. Heute mein Thema: Die Cloud!
(Nein, es soll nicht heißen “Stirb Wolke!”…)

Zuerstmal zum Begriff: Cloud ist Marketing-Geschwafel. Da kann man alles mögliche an Technik ranpappen. In den meisten Fällen ist ein virtualisierter Dienst gemeint. So könnte man den Server, den ich mir mit Ralf teile und auf dem wir unsere 2 VMs laufen lassen, als private Cloud bezeichnen. Ich bleibe trotzdem beim Wort Virtualisierung, alleine, weil es exakter ist.

Überlegen wir doch mal, welche Vorteile es bei einer Cloud, ach Verdammt, Virtualisierung gibt. Man hat seine Daten dezentral irgendwo liegen. Brennt die Hütte ab, ist noch alles im Netz. Man kann Daten mit anderen austauschen. Man kann Dienste (Webserver, Bilder, Videos usw.) anbieten, ohne selbst Hardware betreiben zu müssen. Die meisten dieser Ideen kann man im Netz mieten, z.B. bei Amazon. Dort kann man eine VM mieten, die nach CPU-Zeit abgerechnet wird. Und nach anderen Ressourcen, die man verbraucht. Man kann auch zu Webhosting-Providern gehen, VServer mieten oder richtige Root-Server mieten. Dann wird das Ganze meistens mit einer Monatspauschale abgerechnet und man bekommt bestimmte (virtuelle oder echte) Hardware dafür.

Bei all dem gibt es natürlich Nachteile: wenn ich meine ganzen Daten dort ablege, dann kann ich die mit Paßworten schützen. Wenn ich das nicht mache, ist Polen offen wie bei Facebook, man macht sich quasi selbst zum gläsernen Bürger. Ich verweise da mal auf die Hirntoten, die behaupten, Privacy ist sowas von Eighties. Und die machen mit bei den Piraten? Der Vorschlag, seine Daten offenzulegen, ist ungefähr so, als würde man sagen: Ist nicht schlimm, bei rot über die Straße zu gehen, am besten Du bleibst in der Mitte stehen und wartest noch auf den Bus! Oder gleich die Autobahn überqueren. No Privacy, no safety! Ganz simpel. Deswegen bin ich auch stutzig, wenn mir Dienste z.B. virtuelle Datenträger anbieten. Bei solchen Diensten packt man Daten nur auf einen Fileservice, der irgendwo im Netz rumschwirrt. Bestes Beispiel ist Dropbox, aber auch Google oder Microsoft bieten so etwas an. Und dann fragt man sich schon: will ich wirklich, daß die alles, was ich mache, mitlesen können? Natürlich nicht! Firmen kann man in dem Fall gar nicht vertrauen, sie sind daran interessiert, die Daten zu verwerten, aus ihnen Kapital zu schlagen. Denen ist gleichgültig, wer dahintersteckt und ob derjenige dann Probleme haben könnte.

Mittlerweile ist beim Cloud-Gedanken der Industrie aufgefallen, daß nicht alle so hirntot sind wie der Standard-Gesichtsbuch-Nutzer, der gerne die Bilder des letzten Partygelages rausballert, auch wenn das dann bedeutet, außer Müllmann nie wieder einen Job zu kriegen. Gerade zahlende Kundschaft will Privacy. Also bietet man nun ein Feigenblatt an: die virtuellen Welten können Verschlüsselung! Jaja! Also, so direkt auf der Hardware. Natürlich glaube ich auch nicht, daß die Abhörmechanismen an ihre eigene Hardware klemmen, um dort die Keys mitzulauschen. Aufwand/Verhältnismäßigkeitsrechnungen (und damit auch Kosten) müßte man hier gegenrechnen und natürlich auch der Image-Supergau, wenn Schnüffelei der Keys rauskommt und heutzutage leakt ja irgendwie immer alles, wo viele Leute mitschrauben. Doch selbst wenn die Wahrscheinlichkeit gering ist, so würde eine solche Datensicherheitsmaßnahme schon wieder einmal Vertrauen in den Anbieter voraussetzen. Übrigens hat man im Internet zwecks der Umgehung des Vertrauensproblems gerade solche Dienste wie HTTPS oder SSH entworfen, so daß man auch technisch hinkommt, ohne einander zu beargwöhnen.

Was heißt das nun in der Praxis? Heißt das, man soll es lassen, Daten zu Netzanbietern zu schaufeln? Nein! Es gibt viele Möglichkeiten. Die einfachste, die eigentlich immer geht: die Daten auf dem eigenen Rechner verschlüsseln (z.B. mit Crypt-XOR, Hahaha!) und erst dann übertragen. Das ist sehr, sehr mühselig. Aber machbar. Schöner wäre natürlich, man würde ein Filesystem mounten können, auf dem man direkt verschlüsseln könnte. Linux-Systeme bieten mittels des Tools cryptsetup eine Verschlüsselung namens LUKS an. Der Haken: man kann damit nur Devices anpatschen. Die einfachste Lösung ist: Network Block Device, oder kurz NBD. Das gibt es mit einer Server und einer Client-Ausführung. Kurze Anleitung:

Server, 1 GB Datei als Disk-File:

dd if=/dev/zero of=/tmp/file bs=1024k count=1000

Nun startet man darauf den nbd-server:

nbd-server 6789 /tmp/file

Auf TCP-Port 6789 wird nun ein RAW-Device durchgetunnelt, welches auf /tmp/file (zur Zeit nur mit Nullen gefüllt) zeigt. Dieses Kommando läßt sich auch absichern, man könnte es auch auf localhost starten und dann via ssh einen lokalen Tunnel drauf zeigen lassen. Also keine Panik, theoretisch ist kein offener Port außer ssh nötig!

Auf der anderen Seite nimmt man nun der Client das RAW-Device entgegen:

nbd-client remote-server 6789

Unter /dev/nbd0 hat man nun ein Device, welches 1 GB groß ist (kann man sich z.B. mit fdisk /dev/nbd0 ansehen). Und nun kommt der Clou (ohne d!): Hier kann ich mittels cryptsetup verschlüsseln!

cryptsetup luksFormat /dev/nbd0

und danach

cryptsetup luksOpen /dev/nbd0 file

Jetzt kann man diese Datei als Filesystem bearbeiten und ins System einhängen:

mkfs.ext4 /dev/mapper/file
mount /dev/mapper/file /mnt

Und siehe da: man hat einen 1 GB großen Speicherplatz, der völlig verschlüsselt wird, BEVOR die Daten auf die Reise gehen! Dann darf auch auf der anderen Seite gerne mitgeschnüffelt werden, das dürfte ziemlich aussichtslos sein, was Brauchbares herauszubekommen, die Arbeit macht mein lokaler Prozessor komplett @Home.

Diese Möglichkeit mit dem NBD-Device hat man aber nur, wenn man im komfortablen Besitz einer virtuellen Maschine ist, auf der Linux läuft. Oder einer echten. Diese Möglichkeit ist dahin, wenn man sich z.B. für eine Online-Platte entscheidet, wie sie z.B. Strato und andere Firmen sie anbieten. Hier kann man die Online-Disk nur mit speziellen Dienstmechanismen in sein eigenes System hängen. Ich habe viel getüftelt und kann klar sagen: mit WebDAV habe ich es nicht hinbekommen! Also fällt jeder Anbieter, der nur WebDAV unterstützt, hinten runter. Aber eine Anbindung mittels Samba oder SSHFS ist tatsächlich machbar! Strato bietet übrigens heftig viele Protokolle an, Hut ab!

Das läuft dann so ab: ich mounte mir mittels SSHFS oder Samba/CIFS das fremde Device. Nun habe ich ja wieder die Möglichkeit, auf diesem Filesystem eine große Datei zu erstellen (siehe oben, der dd-Befehl). Diese Datei kann ich nun leider nicht direkt mit cryptsetup bearbeiten. Das Kommando losetup dagegen hilft. Nehmen wir an, das angehängte Verzeichnis /mnt beinhaltet den Samba-Mount mit der Datei file darauf, dann würde es so weitergehen:

losetup /dev/loop0 /mnt/file
cryptsetup luksFormat /dev/loop0
cryptsetup luksOpen /dev/loop0 file
mkfs.ext4 /dev/mapper/file
mount /dev/mapper/file /mnt2

Und schon hätte man wieder ein verschlüsseltes File-System in einer Datei, wobei die Keys den lokalen Rechner nicht verlassen! Vorsicht: man sollte sich öfter des Kommandos sync bedienen, gerade bei Samba-Shares wird viel zwischengecached und erst später geschrieben (merkt man beim unmounten: dauert!). Da droht Datenverlust beim Absturz des Rechners. Ich empfehle also eher das Kommando cp als mv…

BTW, ich bin in diesem Beispiel von EXT4 als Filesystem ausgegangen. Gerade Online-Festplatten sind natürlich ein knappes und teures Gut und so gibt es noch die Möglichkeit mittels des Filesystems ZFS (ubuntu: apt-get install zfs-fuse) deutlich Bytes zu sparen. Obiger FS-Befehl würde dann so aussehen:

zpool create FILE /dev/loop0

Und schon könnte man reinschreiben. Nun noch optimieren, Komprimierung und Deduplizierung anschalten:

zfs set compression=lzjb FILE
zfs set dedup=verify FILE

Und schon spart man bei gleichen Dateien massiv Platz, aber auch schon durch die Komprimierung. Gleiche Dateien werden z.B. bei Backups oft nicht bemerkt, ZFS bemerkt sie und ist erstaunlich stabil dabei. Alles hat einen Haken: Die Verschlüsselung zerrt am Prozessor, die einzelnen Ebenen der Verschachtelung (NBD, /dev/mapper) ebenso. Und ZFS läuft als FUSE-FS im User-Modus, hat also sowieso schon 1/3 Speed-Verlust. Schaltet man obige Optimierungen an, wird’s eher noch heftiger, ich schätze mal 50% Performance-Verlust. Aber auf der anderen Seite: große Daten kann man doch einfach über Nacht rausschieben, da hat man mehr als genug Zeit. Insofern ist Zeit eigentlich gar kein Faktor. Falls jemand noch mehr Möglichkeiten kennt, wo man losetup/cryptsetup ranknüppern kann: nur her damit!

Ich wäre auch sehr erfreut, wenn es eine diesbezügliche WebDAV-Lösung gäbe, das würde den Kreis der Anbieter explosionsartig erweitern, denn WebDAV bieten mittlerweile alle an.

2 Kommentare zum Artikel “Klaut die Cloud!”

  1. erwin janot

    schlitzohr!!! ha,ha,ha -klasse-

  2. UWP

    Aha, diesmal war es also verständlicher! :)

Kommentar schreiben


6 × vier =

Kategorien

Archiv

Dezember 2017
M D M D F S S
« Jun    
 123
45678910
11121314151617
18192021222324
25262728293031
-->


Blog-Seiten aufgerufen seit 9. Januar 2006:
digit digit digit digit digit digit digit digit
  Impressum