Entries tagged as verschlüsselung
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
/etc/pam.d/common-password
Hier fand ich:
password required pam_unix.so nullok obscure min=4 max=16 md5
password required pam_unix.so nullok obscure min=8 sha512 rounds=65519
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
dcfldd if=/dev/frandom of=/dev/sdb
gdisk /dev/sdb
cryptsetup -y -h sha512 --align-payload=8192 luksFormat /dev/sdb2
cryptsetup luksOpen --allow-discards /dev/sdb2 clvm
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
mkfs.ext2 /dev/sdb1 -L boot
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
tune2fs -m 0 /dev/mapper/ssd-homevol
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
pacstrap /mnt/sdb2 base base-devel syslinux
syslinux-install_update -i -a -m -c /mnt/sdb2
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
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.
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
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
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.