Butschek.de

Mit dm-crypt / LUKS lassen sich unter Linux Festplatten oder Partitionen verschlüsseln. Die Details sind auf Wikipedia zu finden, dieser Artikel soll zeigen, wie einfach es einsetzbar ist.

Wir gehen von einer normalen Debian Lenny installation aus. Ich habe sda in 3 Partitionen unterteilt: Swap (2 GB), Root-FS (10 GB) und /home (Rest). Die dritte Partition werde ich verschlüsseln.

Zuerst installieren wir die Software und laden das nötige Kernel-Modul. Dies ist beim Einrichten einmalig manuell nötig, beim späteren Öffnen des Containers wird das Modul automatisch geladen:

apt-get install cryptsetup
modprobe dm_crypt

Nun starten wir die Einrichtung:

cryptsetup luksFormat /dev/sda3

Mit luksOpen öffnen wir den verschlüsselten Bereich. Dadurch entsteht ein neues Gerät namens /dev/mapper/{name} welches das “geöffnete” /dev/sda3 repräsentiert, jedoch in nichtverschlüsselter Form. Wir benutzen also künftig /dev/mapper/{name}, wobei alles, was wir dorthin speichern transparant verschlüsselt und nach /dev/sda3 geschrieben wird.

cryptsetup luksOpen /dev/sda3 private

Wir haben der Partition also nun den Gerätenamen ‘privat’ gegeben, daher finden wir unsere lesbare “Partition” nun unter /dev/mapper/private. Nun formatieren wir die Partition:

mkfs.xfs -L sda3-priv /dev/mapper/private

Fertig, schon kann die Partition gemountet und genutzt werden:

mount /dev/mapper/private /home

Was ich an dieser Stelle gerne empfehle ist das vollständige Überschreiben der Festplatte. Beim luksFormat wird der Bereich nämlich nicht überschrieben, es wird nur der leere Index angelegt. Die zuvor unverschlüsselt gespeicherten Daten sind also noch rekonstruierbar.

Das “Ausnullen” (Ãœberschreiben mit lauter 0×00 Bytes) vermeide ich hier, da ein Angreifer sonst verschlüsselte und unverschlüsselte Daten großer Teile der Platte kennen könnte und somit gezielt nach dem Schlüssel suchen könnte. Daher benutze ich hier /dev/urandom:

dd if=/dev/urandom of=/home/fillup.dat bs=1M
rm /home/fillup.dat

Eine interessante Sache übrigens: Das Füllen mit Zufallsdaten könnte theoretisch auch vor dem luksFormat direkt auf /dev/sda3 erfolgen, man könnte sogar annehmen, dass dies schneller geht, weil die Zufalldaten dann nicht verschlüsselt geschrieben werden müßten. Da die Verschlüsselung jedoch die Entropie der Zufallszahlen ganz vewaltig in die Höhe treibt, geht das Erzeugen von Zufallszahlen beim Überschreiben des gecrypteten Bereiches in der Tat schneller als beim Überschreiben der Platte sda3.

Meine Messwerte:

So, um die Partition nach dem Entmounten wieder zu “schließen”, also das Mapper Device wieder zu entfernen, damit nicht mehr auf die Daten zugegriffen werden kann, wird das Kommando luksClose genutzt:

umount /dev/mapper/private
cryptsetup luksClose private

Durch einen Reboot ist das Laufwerk übrigens auch geschlossen, wenn also jemand mit lokalen Zugang zum PC kein Passwort hat, wird er künftig keine Daten aus /home mehr auf dem Rechner finden, denn selbst ein Reboot mit init=/bin/bash ist nun wirkungslos.

Fertig ist das streng geheime Home-Verzeichnis – was übrigend auch mit jedem anderen Verzeichnis klappt – zumindest solange es kein System-Verzeichnis ist, welches zum Booten schon benötigt wird.

TIPP: Ein Blick ins Manual von cryptsetup ist übrigens sehr zu empfehlen. Hier wied auch verraten, wie man mit den luks*Key Kommandos mehrere Passwörter anlegen (z.B. für mehrere Leute, jeder hat SEIN Passwort) oder wie man mit Key-Files (z.B. auf dem USB-Stick) arbeiten kann. Auch Scripting ist dank isLuks und luksUUID problemlos möglich…

IT, LST dd, dm-crypt, Linux, luks, Shell, Sicherheit, urandom

Ein normales Image einer Partition kann mit losetup zum Loop-Device gemacht werden und so über /dev/loopX als Gerät angesprochen und z.B. gemountet werden. Schwieriger wird es jedoch, wenn das Loop-Device eine komplette Platte inklusive Partitionen enthält.

Ein einfaches Beispiel: Ein mit “dd if=/dev/sda of=/imagefile” erstelltes Image kann zwar mit losetup zu /dev/loop0 gemacht werden, jedoch ist ein direktes Ansprechen der Partitionen, die ehemals auf /dev/sda existierten, nicht möglich. Dazu müßte es ja ein /dev/loop0_1, /dev/loop0_2 oder /dev/loop0_3 geben.

Gut, möglich ist es schon, denn losetup kann mit –offset auch nur Teile der Image-Datei als Loop-Device nutzen, nur müßte man so auf’s Byte genau die Partitionen finden, wobei ein Irrtum möglicherweise die Daten vernichten würde.

Diese Aufgabe löst kpartx. Der Einsatz ist ganz einfach: Installieren und loslegen.

apt-get install kpartx
kpartx -av /imagefile
oder
kpartx -av /dev/loop0

Schon stehen unter /dev/mapper je Partition ein Loop-Device zur Verfügung, also zum Beispiel:

• /dev/mapper/loop0p1 (ehemals /dev/sda1)
• /dev/mapper/loop0p2 (ehemals /dev/sda2)
• /dev/mapper/loop0p3 (ehemals /dev/sda3)

Der Parameter -a steht für add, das v dagegen für verbose, so dass ich gleich sehe, was er mir angelegt hat. Mit dem Parameter -l zeigt man die Mappings an, mit -d löscht man sie wieder.

Typischer Anwendungszweck:

Mit losetup kam ich noch gut klar. Als ich jedoch das erste mal ein Image erstellt habe und darin eine virtuelles Debian von einer virtuellen CD (.ISO-Datei) installierte, hat mir dieses in der Image-Datei mehrere Partitionen angelegt. Hier war kpartx meine Rettung, denn so konnte ich noch auf die Daten im Image-File zugreifen.

IT, LST kpartx, Linux, losetup, Shell

Der Hersteller Sunbelt Software bietet mit VIPRE Rescue Program eine kostenlose Notfall-Lösung für vireninfizierte PCs an.

Die Notfall-Lösung beherrscht keine Online-Updates oder sonstige Features einer Desktop-Suite. Die 140 MB große Datei wird heruntergeladen und doppelgeklickt. Nach dem Entpacken startet der Scanner und untersucht den kompletten PC. Dabei geht er wirklich sehr gründlich vor, geprüft wird Boot-Bereich, laufende Prozess, Festplatte (inkl. des Bereichs für die Systemwiederherstellung) sowie die Registry.

Testlauf:

Beim Scannen gab das Programm unsinnigerweise seitenweise Dateinamen von geprüfen Dateien aus, dabei sah ich in roter Farbe auch meine Mainboard-Treiber vorbeilaufen. Diese werden aufgrund einer Download-Routine von vielen Scannern fälschlicherweise als Virus eingestuft. Warum man nicht einfach nur die wichtigen Informationen ausgibt, die man dann vielleicht auch lesen könnte, wurde mir nicht klar. Immerhin zeigt dieser False-Positive, dass Vipre aktuelle Pattern einsetzt – lobenswert!

Nach etwa etwa einer halben Stunde war mein Rechner dann komplett gescannt, die Abschlußmeldung auf der Konsole ist nur leider wenig aussagekräftig:

Scan completed.
Scan time: 00:31:08
Rootkits: **** scanned, 0 found
Processes: ** scanned, 0 found
Modules: **** scanned, 0 found
Folders: **** scanned, 0 found
Files: **** scanned, 7 found
Registry: **** scanned, 0 found
Total: **** scanned, 7 found
7 threat traces were detected.
Starting clean.
Quarantine {5b456ca4-42f2-8456-629d-f96b1854c0cf} completed.
Quarantine {b657c909-0d8b-29ca-fe3d-377447d960d6} completed.

Clean completed.
Clean time: 00:00:01
2 threats were cleaned.

Im Quarantäne-Verzeichnis fand ich 7 Dateien benannt in Hexadezimal-Ziffern und ohne Dateiendung (scheinbar die o.g. 7 Files) sowie 2 XML-Dateien benannt nach der Ausgabe oben “Quarantine {…} completed”.

Die 7 Dateien waren wirklich meine Mainboard-Treiber, die 2 XML-Dateien protokollierten Originalname, Quarantäne-Name, Prüfsumme und den Grund der Sicherstellung. Ob ich diese Dateien überhaupt in Quarantäne schieben will, wurde ich nicht gefragt.

Fazit:

Als Versuch der letzten Rettung bei einem halbtoten Windows-System ist der Scanner wirklich gut zu gebrauchen. Er entsorgt zumindest alles virenverdächtige und erlaubt daher das sichere Übernehmen der restlichen Daten.

Für ein noch genutztes System ist der Scanner absolut nicht zu gebrauchen, da er ohne Rücksicht auf Verluste und ohne Rückfrage Dateien umbenennt und in Quarantäne nimmt, die man ohne gute Kenntnisse in XML kaum wieder zurückbekommt. In meinem Fall waren es Mainboard-Treiber (bzw. dessen Installer) und hätte ich nicht genauer hingeschaut, wäre mir das wohl nie aufgefallen, dass hier plötzlich 7 Dateien fehlen. Doch bei der nächsten Neuinstallation hätte ich wohl geflucht und die Welt nicht mehr verstanden.

Sorry, Sunbelt Software, setzen 6!

Plus-Punkte:

• Einfache Bedienung
• Keine Installation nötig
• Läuft auch in der Rettungskonsole (DOS)

Minus-Punkte:

• Ausgabe unübersichtlich
• Absolut keine Rückfrage
• Protokoll nur in XML-Datei (keine für Nicht-Programmierer lesbare Text-Fassung)

Schade, denn die negativen Punkte ließen sich von den Entwicklern wohl in 30 Minuten beheben. Zumindest für den Notfall, wenn Windows gar nicht mehr startet, ist die Software wirklich gut zu gebrauchen:

VIPRE Rescue Program Download:
http://live.sunbeltsoftware.com/

IT, Webtipps Sicherheit, virenscanner, virus, Windows

Mit einem Loop-Device kann man unter Linux nette Dinge machen: Man kann Dateien wie ein Gerät, z.B. eine Festplatte oder eine Partition (also ein Block Device) behandeln.

Normalerweise besteht eine Festplatte aus mehreren Partitionen. Diese werden uns dank udev im /dev Verzeichnis angezeigt und lassen sich mit Ihrem Namen /dev/sda1, /dev/sda2, … ansprechen.

Was aber, wenn nur ein Dump einer Partition in Form einer Datei vorliegt? Zum Beispiel wenn jemand eine komplette Kopie mit “dd if=/dev/sda3 of=/file” erstellt hat. Hier hilft losetup.

Um eine Datei als sog. Loop-Device zu benutzen, muss es – sofern nicht schon vorhanden – erstmal erstellt werden:

dd if=/dev/zero of=/home/test bs=1M count=1k

Damit erstellen wir eine Datei mit eine Größe von 1 GB (1000 Blöcke [1k] zu je 1MB). Diese wird nun eingebunden.

losetup -f /home/test

Mit ‘losetup  -a’ läßt sich jetzt herausfinden, welchen Gerätenamen unser Gerät nun erhalten hat, üblicherweise wird dies beim ersten Versuch /dev/loop0 sein. Man hätte übrigens mit ‘losetup -f’ auch vorher schon nachsehen können, welches der nächste freie Gerätename ist – für Scripte ist dieser Weg wohl einfacher.

So, nun können wir /dev/loop0 benutzen wie eine normale Partition, z.B. so:

mkfs.ext3 /dev/loop0
mount /dev/loop0 /mnt
df -h /mnt

Nach dem entmounten läßt sich das Loop Device auch wieder entfernen:

umount /dev/loop0
losetup -d /dev/loop0

Damit ist unsere Datei auch wieder nur eine Datei.

Mit dem Parameter -e läßt sich übrigens auch ein verschlüsseltes Loop-Device erzeugen (z.B. losetup -e des -f file, siehe Manpage, doch nutze ich hier lieber LUKS, das in Kürze in einem Artikel erklärt wird.

IT, LST Linux, losetup, Shell

Heute stand ich vor 2 Problemen: Erstmal mußte ich ein PDF-Dokument aus einer Applikation erstellen, die das selbst nicht konnte. Nachdem ich dort eine Software fand, wollte mein Adobe Reader mal wieder nicht richtig laufen, blieb stattdessen lieber als hängender Prozess stehen.

Nachdem ich vor kurzem auch noch bei Heise gelesen hatte, dass sogar Virenspezialisten wie F-Secure vom Einsatz des Adobe Reader abraten, weil das Produkt einfach zu unsicher ist, habe ich mich also nach freier Alternativ-Software umgesehen.

Folgende Programme habe ich gefunden, die sehr einfach sind, ihren Zweck aber voll erfüllen und nicht mit Popups oder ähnlichem nerven:

Zum Betrachten von PDF-Dateien:

Foxit Reader
http://www.foxitsoftware.com/pdf/reader/

Zeigt PDF-Dateien an und bietet auch eine Browserintegration. Bei der Installation sollte man höllisch gut aufpassen, die Software will ständig irgendwelche Zusatztools oder Browserleisten installieren oder Standard-Suchmaschine und Startseite ändern. Doch hat man das erstmal überstanden, läuft das Programm sehr stabil und ohne nervige Werbung.

Zur Erstellung von PDF-Dateien:

CC PDF Converter
http://www.cogniview.com/cc-pdf-converter.php

Erstellt einen Druckertreiber, der Dateien als PDF-Dateien speichert. Auf Wunsch kann auch gleich noch ein Creative Commons Lizenzhinweis eingebunden werden.

IT, Webtipps Adobe, Foxit, PDF, Reader, Windows