Entries tagged as verschlüsselung

Related tags

Passworte in /etc/shadow

Monday, August 19. 2013

 Ich bekam doch einen Schreck, als ich auf einem Rechner, der seit sarge oder so immer debian-stable hatte, bei einer Kontrolle darauf stiess, dass die Passworte in /etc/shadow nur mit md5 gehasht wurden. 
Der Sache nachgehend fand ich einen Thread in den Debian-User Foren, der dank eines hartnäckig nachfragenden Users eine recht erhellende Diskussion zum Thema hat. 

Bei einem Eintrag in shadows der Form:

webdb8_usr:$1$Ksmg|oP`$9S1FToADihC6K4o2cifd50:15672:0:99999:7:::
steht $1 für den Hash-algorithmus md5, zwischen den beiden nächsten $ stehen 8 Zeichen salt und dem folgt dann das Hash.
$5 wäre SHA-256 und $6 SHA-512
 
Die relevante config dazu fand sich in /etc/pam.d/common-password
Hier fand ich:
password   required   pam_unix.so nullok obscure min=4 max=16 md5
ich habe es ersetzt bzw ergaenzt durch
password   required   pam_unix.so nullok obscure min=8  sha512 rounds=65519 
 
nun ist die entsprechende Zeile in der Shadow auch deutlich länger....
 
Das abschliessende rounds=65519 sorgt dafür, dass das Passwort nicht einfach einmal gehasht wird, sondern das Ergebnis ein weiteres Mal, und dann wieder und wieder - 65519 mal hintereinander. Das hat hauptsaechlich den Nutzen, eine Weile zu dauern, immer noch zu kurz, um bei einer aktuellen Passworteingabe aufzufallen, aber lang genug, um brute force Passwortknackern lästig zu fallen.
Geschrieben von daniel
Comments (0) Trackbacks (0)

arch linux von verschlüsselter SSD

Sunday, August 11. 2013

Das Thema ist an sich gut dokumentiert, hier ein paar Links:

https://wiki.archlinux.org/index.php/Encrypted_LVM

https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS

https://wiki.archlinux.de/title/Festplatte_verschl%C3%BCsseln

http://www.marcstraube.de/linux/2012/08/installation-von-archlinux-mit-verschlusseltem-lvm-und-systemd/

 
Medium mit Rauschen initialisieren:
# frandom ist ein wenig schneller /dev/random und dcfldd ist ein erweitertes dd und gibt dem Ungeduldigen eine Fortschrittsanzeige
dcfldd if=/dev/frandom of=/dev/sdb   
 
# für Neugierige und Kontroll-freaks ist
# lde ein DiskEditor, mit dem man sich anschliessend ansehen kann, was nun auf der disk steht
 
lde /dev/sdb   
 
# SSD partitinieren, da wir syslinux einsetzen werden, brauchen wir nur zwei Partitionen für boot und den verschluesselten Rest 
# gdisk ist gpt fdisk, GPT ist bei mehr als 2 TB angesagt
 
gdisk /dev/sdb  
 
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          100351   48.0 MiB    8300  Linux filesystem
   2          100352       250069646   119.2 GiB   8E00  Linux LVM
 
# jetzt luks auf die grosse Partition, vorher einen langen, gut merkbaren Pass-Satz ausdenken
cryptsetup -y  -h sha512 --align-payload=8192 luksFormat /dev/sdb2
cryptsetup luksOpen --allow-discards /dev/sdb2 clvm 
 
# und jetzt die logischen Partitionen der LVM anlegen
pvcreate  --dataalignment 4M /dev/mapper/clvm
vgcreate ssd /dev/mapper/clvm
lvcreate -L 20G ssd -n rootvol
lvcreate -L 80G ssd -n homevol
lvcreate -l 100%FREE ssd -n varvol
 
# boot formatieren, 
mkfs.ext2 /dev/sdb1 -L boot
 
# die übrigen volumes bekommen ext4
mkfs.ext4  -E discard /dev/mapper/ssd-rootvol -L root
mkfs.ext4  -E discard /dev/mapper/ssd-homevol -L home
mkfs.ext4  -E discard /dev/mapper/ssd-varvol -L var
 
# standardmaessig werden immer 5% für root reserviert, auf home brauchen wir das nicht
tune2fs -m 0 /dev/mapper/ssd-homevol
 
# so jetzt kann man sie schon mounten und mit der Installation beginnen
mkdir /mnt/sdb2
mount /dev/ssd/rootvol /mnt/sdb2
mkdir /mnt/sdb2/home
 
mkdir /mnt/sdb2/var
mkdir /mnt/sdb2/boot
mount /dev/sdb1 /mnt/sdb2/boot
mount /dev/ssd/homevol /mnt/sdb2/home
 
mount /dev/ssd/varvol /mnt/sdb2/var
 
# damit die naechsten Schritte aus einem installierten Arch-System (statt archiso) gehen, 
# müssen die arch-install-scripts installiert sein
 
pacstrap /mnt/sdb2 base base-devel syslinux
 
syslinux-install_update -i -a -m -c /mnt/sdb2
 
# das legt uU in /boot/syslinux/ diverse symlinks an, was natuerlich nicht funktioniert,
# wenn die Bootpartition alleine und das Ziel der Links noch verschluesselt ist.
# Also kontrollieren und ggf statt der symlinks die echten dateien einkopieren.
 
# Die erzeugte /boot/syslinux/syslinux.cfg wird man auch kontrollieren und editieren wollen.
# wenn man statt der device -Pfade UUIDs einsetzen will, sieht ein funktionierender Eintrag etwa so aus:
 
LABEL arch
        MENU LABEL Arch Linux
        LINUX ../vmlinuz-linux
        APPEND root=/dev/mapper/ssd-rootvol cryptdevice=UUID=c30af807-1234-1234-1234-5ae7f6803b4d:ssd:allow-discards rw lang=de locale=de_DE.UTF-8
        INITRD ../initramfs-linux.img
 
# fstab erzeugen
#  (-U nutzt die UUID, anschliessend ist Handarbeit angesagt, wg swap etc.
# nuetzlich kommt blkid mit einer Liste aller partitionen und deren Bezeichnungen)
genfstab -U -p /mnt/sdb2 >> /mnt/sdb2/etc/fstab  
 

Anschliessend kann man in das neue System booten und normal installieren...

Und? Ist die SSD wirklich so rasend schnell, bzw. bringt sie überhaupt auf einem älteren Board mit legacy SATA etwas? Und wird die Performance nicht von der Ver-/Entschlüsselung komplett wieder aufgefressen?

Die Stoppuhr sagt: fast doppelt so schnell. Von der alten Platte ist die Kiste in 32sec. beim LoginScreen des KDM und braucht danach noch einmal 18 sec., bis der Desktop sichtbar wird. Von der neuen Platte sind es 16 sec und danach 14.

 

Geschrieben von daniel
Comments (0) Trackbacks (0)

dm-crypt und luks für eine Container-Datei

Wednesday, October 5. 2011

In einem vorigen Eintrag hatte ich die Verschlüsselung kompletter Partitionen und deren Einbindung mit dm-crypt und luks beschrieben, hier als Ergänzung, wie das mit Container-Dateien geht.

# ggf vorbereiten
modprobe loop
losetup -a

#  erstelle 2G container mit zufallsfuellung
dd if=/dev/urandom of=testfs.bin bs=1M count=2048

# die (leere) Imagedatei auf das naechste freie Loop-Gerät legen, wird angezeigt
losetup -f --show  testfs.bin

# und zunächst als Partition formatieren
cryptsetup luksFormat /dev/loop0

# dabei wird die Eingabe einer Passphrase verlangt, die gut verschluesselt notieren...

# jetzt kann die Datei-Partition geöffnet werden
cryptsetup luksOpen /dev/loop0 testfs

# mit einem Dateisystem formatiert
mkfs -t ext4 /dev/mapper/testfs

# und schliesslich gemounted werden
mount /dev/mapper/testfs /mnt/testfs

Damit ist ein Dateisystem in einem verschlüsselten Container angelegt und kann benutzt werden. Hier noch mal die Aufrufe im Einsatz, Einbinden und Lösen:

Einbinden:
losetup -f --show testfs.bin
cryptsetup luksOpen /dev/loop0 testfs
mount /dev/mapper/testfs /mnt/testfs

Lösen:
umount /mnt/testfs
cryptsetup luksClose /dev/mapper/testfs
losetup -d /dev/loop0

Geschrieben von daniel
Comments (0) Trackbacks (0)

Festplattenverschlüsselung mit dm-crypt und luks

Friday, February 18. 2011

Am Beispiel einer externen Festplatte, die sich nach dem Anstöpseln als /dev/sdc meldet:

fdisk -l
gibt unter anderem:

Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x08040000

Disk /dev/sdc doesn't contain a valid partition table

Die Partition mit ziemlichem Zufall initialisieren und dabei gleichzeitig die Zuverlässigkeit der Platte prüfen:

badblocks -c 10240 -s -w -t random -v /dev/sdc
(dauert ewig.)

Formatieren und mit dem Namen silva einbinden:
luksformat -t ext3 /dev/sdc
cryptsetup luksOpen /dev/sdc silva

Optional die fsck-Frequenz etwas ausdünnen: 
tune2fs -c 1000 /dev/mapper/silva
tune2fs -i 365 /dev/mapper/silva

und ins Dateisystem holen:
mount /dev/mapper/silva /mnt/silva

und zurück:
umount /mnt/silva , falls dass mit device busy hakt, ggf fuser -m /mnt/silva
cryptsetup luksClose /dev/mapper/silva


Mehr Infos

dm-crypt vs. truecrypt:
- beide können einen Container in einer Datei, einer Partition oder einem ganzen device einrichten, beide sind opensource und bier-frei, beide sind schwer genug zu knacken dass es aussichtsreicher ist, das Versteck für den Schlüssel zu finden.
- dm-crypt ist gefühlt paarmal schneller. Bei einem Container mit Passwörtern und Tagebüchern etc. macht das keinen nennenswerten Unterschied, aber bei einer TB-Platte mit der Musiksammlung dann schon.
- dafür hat truecrypt deutlich die Nase vorn, wenn man den Container mal von win*, mal von linux her öffnen möchte
- mit dem Konzept der plausible deniability und hidden volumes hat truecrypt ein Alleinstellungsmerkmal, das unter Umständen den Abstand zwischen Kopf und Kragen regulieren helfen kann.

Vom Einsatz-Szenario her würde ich das Projekte-Device, auf dem unter anderem auch Vorhaben, die unter NDA stehen, gewiss auf dm-crypt legen, dito die Sammlung von vmware und vmbox - Maschinen oder Videos fraglicherer Herkunft.
Die MindMaps, Tagebücher, Liebesbriefe und org/finanzamt wären da eher auf einem trauecrypt-Volumen gut aufgehoben und die Sammlung von Belegen all' der schoflen  Begebenheiten, die irgendwann mal reif für ein Upload nach wikileaks sein wird, käme wohl am besten zu truecrypt in ein hidden volume.

Geschrieben von daniel
Comments (0) Trackbacks (0)
(Page 1 of 1, totaling 4 entries)