Newsletter Juni 2018
Hallo,
der Sommer ist da und die Fußball-Weltmeisterschaft läuft. Da nimmt man meistens nicht viel anderes wahr - auch wenn abseits des Fußballs ebenfalls eine Menge passiert. Nun ist die Mannschaft überraschend aber verdient ausgeschieden. Daher ist jetzt wieder Zeit, sich mit Digitalisierung und Open-Source-Software zu beschäftigen. Einiges von dem, was sich da so alles tut, haben wir auch in diesem Monat wieder für Sie zusammengestellt.
Und jetzt wie immer: Viel Spaß mit den GONews!
Alfred Schröder
Geschäftsführer
Inhalt
- Open Source Studie 2018 der Schweiz
- Digital ist noch viel mehr möglich
- Tipp des Monats
Open Source Studie 2018 der Schweiz
Die Open Source Business Alliance weist in ihren News auf eine interessante Studie aus der Schweiz hin. Dort hat man festgestellt, dass OSS sich mittlerweile nicht nur an vielen Stellen durchgesetzt hat, sondern dass man das “Plateau der Produktivität” erreicht hat. Mit Blick auf die üblichen Entwicklungsphasen von Technologien (Gartner Hype Cycle) hat Open Source damit wohl nicht nur die Kinderstube und die Phasen der Begeisterung und Ernüchterung hinter sich gelassen, sondern ist nun endlich richtig auf allen Ebenen angekommen. Das heißt, dass nicht nur innovative und strategische IT-Entscheider auf OSS setzen, sondern dass nun auch die breite Masse OSS als vollwertige Alternative produktiv einsetzt.
Mehr zur Studie im Artikel der OSBA:
Digital ist noch viel mehr möglich
Die Digitalisierung ist nicht nur ein Thema für große Konzerne oder IT-Unternehmen sondern erreicht immer mehr auch die unterschiedlichsten mittelständischen Unternehmen. Die Westfalenpost in Arnsberg hat den GONICUS Geschäftsführer Alfred Schröder zu dieser Entwicklung befragt, die natürlich auch Südwestfalen mit einer Vielzahl von starken mittelständischen Unternehmen betrifft.
Gerne stehen wir für diese Unternehmen mit unseren Erfahrungen und unserem regionalen Bezug als Ansprechpartner zur Verfügung. Wir kennen zwar nicht nur aber eben auch ganz besonders unser Sauerland, woll!
Den Artikel findet man auch online hier:
Tipp des Monats
Festplatten für Verschlüsselung vorbereiten
Es ist mal wieder soweit, ein neues System soll installiert werden. Diesmal mit allem drum und dran, mit Raid, LVM und natürlich Festpattenverschlüsselung mit LUKS. In so ziemlich jedem Tutorial oder Howto liest man:
“Festplatten sollten vor dem Verschlüsseln einmal mit Zufall überschrieben werden, sonst können vorherige Inhalte der Festplatte später ausgelesen werden.”
So oder ähnlich lautet immer der Ratschlag, welcher auch richtig und wichtig ist. Stellt sich nur die Frage: Wie geht das am besten? Häufig wird die “Hammerschlag-Methode” verwendet: dd von /dev/urandom auf das Zielgerät. Andere benutzen shred, und es gibt noch viele weitere Möglichkeiten. Allerdings unterscheiden sich die Methoden zum Teil deutlich in der Geschwindigkeit, was gerade bei großen Festplatten eine nicht unerhebliche Zeitersparnis bedeutet. Schauen wir uns also mal die verschiedenen Möglichkeiten an, die uns zur Verfügung stehen:
Folgendes sei bei den Tests gegeben: /dev/sdd # Vorzubereitende Festplatte, schon vorbereitet mit Partitionstabelle und einer Partition /dev/sdd1 # Partition über die ganze Festplatte
1) Hammerschlag Methode ganz klassisch, Pseudozufallszahlen nehmen, und auf das Gerät schreiben, bis es voll ist:
#> dd if=/dev/urandom of=/dev/sdd1 bs=1M status=progress
Einfacher Befehl, dauert aber am längsten.
2) Userland-Tools wie shred Spezialisierte Tools wie shred erledigen ihre Aufgabe zuverlässig und recht schnell:
#> shred -vn 1 /dev/sdd1
Super zu benutzen, muss aber natürlich auch verfügbar und installiert sein (ist es auch in der Regel)
3) Temporäres LUKS als Cryptolayer benutzen Diese Methode erfordert etwas Erklärung. Die Idee ist, ein LUKS über die komplette Festplatte anzulegen und für die Crypto einen langen (!) und zufälligen (!!) Schlüssel zu nehmen, das frische Cryptogerät einzuhängen und dann das entschlüsselte Gerät mit Nullen aus /dev/zero zu überschreiben. Auf der Platte landen die Daten trotzdem verschlüsselt, da sich das ganze innerhalb eines LUKS-Containers abspielt. Anschließend das Gerät aushängen (bzw. “Abschließen”) und den Anfang des verschlüsselten Geräts mit etwas Zufall überschreiben, damit der Header gelöscht wird und der Inhalt der Platte aus Zufall besteht. Und das geht so:
Gerät verschlüsseln:
#> cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/sdd1
Gerät entschlüsselt einhängen:
#> cryptsetup luksOpen /dev/sdd1 test1
Entschlüsseltes Gerät mit Nullen füllen:
#> dd if=/dev/zero of=/dev/mapper/test1 bs=1M status=progress
Verschlüsseltes Gerät wieder aushängen/abschließen:
#> cryptsetup luksClose test1
Header von LUKS bzw. den Anfang der Partition mit Zufall überschreiben:
#> if=/dev/urandom of=/dev/sdd1 bs=1M count=1
Etwas umständlich, aber signifikant schneller als z.B. Methode 1.
Warum es sich also so kompliziert machen? Nun, unter bestimmten Vorraussetzungen können die Methoden 2 und 3 etwa die gleiche Geschwindigkeit erreichen, häufig wird aber die dritte Variante trotz mehr Tipparbeit die schnellste sein. Der Grund dafür ist, dass heutzutage die meisten Prozessoren dedizierte AES-Einheiten oder AES-Co-Prozessoren haben, die diesen Algorithmus in Hardware (de)kodieren können und somit signifikant höhere Geschwindigkeiten erreichen und das bei kaum vorhandener Last auf der CPU. Wir bedienen uns hier des Tricks, dass verschlüsseltes Ablegen der Daten durch eine Dateisystemebene mit LUKS passiert, welches AES in diesem Fall benutzt, statt aufwendig Zufallszahlen selber zu generieren. Wir brauchen an dieser Stelle ja noch gar keine richtige Verschlüsselung und händisch fein abgezählte Entropie, sondern wir wollen einfach erreichen, dass unsere Ausgangslage ist, dass sich auf der Festplatte nur nicht zuordenbarer Müll befindet. Auch die gerne gelebte Halbwahrheit, dass Datenträger mindestens X-mal mit Zufall und/oder Nullen überschrieben werden müssen, ist auf heutige Datenträger schlicht nicht mehr anwendbar und damit obsolet. Einmal Pseudozufall reicht hier völlig.
Ein Wort zur Größenordnung: Beim Testen hat Variante 1 bei uns auf einem 10 GB großen Testgerät ca. eine Minute gedauert, Variante 2 ca. 10 Sekunden und Variante 3 ca. <5 Sekunden. Wenn man diesen Test nachstellen will, sollte man vielleicht noch darauf achten, dass man das auf leeren Medien ausprobiert, denn auf dem eigenen Rechner wird das Ergebnis auf jeden Fall verfälscht, wenn der Rechner selbst von einer LUKS-Partition startet.