Archive for April, 2012

Mein Tor-Exit beschert mir ja viel Mail. Meist kommt die vom gleichen Trottel namens Osama Hussain Esq. Diese … “Person” behauptet im Namen von Irdeto (fka BayTSP.COM Inc.), dass ich bösartig Torrenting betreibe. Seinen Irrtum habe ich ihm nun schon ein paar hundert mal mitgeteilt, offenbar ist er zu Blöd das zu verstehen. Idioten gibts halt überall. Auch sonst gibt es diverse Organisationen die ähnlich unbelehrbar immer wieder Schrott schicken, was mir primär einfach nur Arbeit macht. Dies meisten dieser Spacken sind irgendwelche selbsternannten Spam- oder Botnetz-Jäger.

Aus Juristischer Sicht hab ich nicht viel zu befürchten, mir macht eher Sorgen, dass Hetzner irgendwann nicht mehr Mitspielen möchte und meinen Server abstellt. Dies ist bisher zum Glück nicht geschehen, das möchte dieser Firma hier mal hoch anrechnen (da gibt es ganz andere, die Tor-ML ist voll davon).

Gestern wurde ich positiv überrascht. Eine (offenbar) deutsche Organisation schrieb mich an (via hetzner-abuse-system), das mein Server spamme, das scheine ein gehackter Server zu sein. “Nicht schon wieder so einer” dachte ich mir und hab meine Standartantwort geschickt. Darin sage ich, dass dies ein Tor-Exit sei, dass ich nicht viel tun könne, das ich aber die IPs blockieren würde wenn gewünscht. Also die IPs ihrer Server, so dass man meinen Exit-Node nicht mehr missbrauchen kann. Erwartet hab ich da erst mal nix. Ich hatte die Hoffnung schon komplett aufgegeben, dass es Intelligenz in diesem Bereich des Internets noch geben könne.

Aber  BlockList.de hat geantwortet. Noch am Sonntag Abend! Darin teilen sie mir mit, dass die Server-IP nun auf der Liste der Tor-server sei, und sie keine weiteren Abuse-messages mehr verschicken. Wow, so sieht eine professionelle Antwort aus. Davon können sich die ganzen Idioten da draussen mal eine Scheibe abschneiden. Offenbar gibt es doch noch Leute die ihre Aufgabe ernst nehmen.

Meine Meinung über die Digital Natives ist soeben wieder gewachsen 🙂 Vielen Dank an das Team von BlockList.de

Flattr this!

Comments Comments Off on Oh, es gibt doch noch Profis im Netz

While installing gentoo on my laptop, I had to switch over and use initramfs as I want full disk encryption.
Dracut provides a module which can load gpg encrypted keys and open a LUKS encrypted disk. This is nice, but it requires manual setup.
As I always forget about such things, I went on and implemented a small but easy to use auto-detection for LUKS encrypted volumes.
The script checks /boot/.luks for key-files named <VOLUME UUID>[.gpg] for each LUKS Device found in fstab. if found, it adds a entry to /etc/cmdline.
The patch is simple and consistent with how dracut deals with UUIDS (which is rather odd, they use udev to get the UUID instead using blkid. No idea why).

Patch for the crypt-module in /usr/lib/dracut/modules/90crypt (if using gpg-encrypted files, you need add crypt-gpg to the modules list in /etc/dracut.conf or you won’t be able to open your key on boot!)

--- module-setup.sh.orig	2012-02-24 15:38:08.000000000 +0100
+++ module-setup.sh	2012-03-29 00:24:49.997233979 +0200
@@ -22,6 +22,23 @@
         [[ ${ID_FS_UUID} ]] || return 1
         if ! [[ $kernel_only ]]; then
             echo " rd.luks.uuid=luks-${ID_FS_UUID} " >> "${initdir}/etc/cmdline.d/90crypt.conf"
+	    # look for keyfiles in $luks_key_dir (default:/boot/.luks).
+	    # Keys must be named ${ID_FS_UUID} or {ID_FS_UUID}.gpg
+	    # you need add the crypt-gpg modules to the list of additional modules to have gpg keys work.
+	    local keydir=${luks_key_dir-/boot/.luks}
+	    local keyfile=${keydir}/${ID_FS_UUID}
+	    # check for keyfile. if none try add .gpg
+	    [[ -f ${keyfile} ]] || keyfile=${keyfile}.gpg
+	    [[ -f ${keyfile} ]] || return 1
+            ID_KEY_UUID=$(udevadm info --query=property --name=$(readlink -f "/dev/block/$(find_block_device "/boot")") \
+                | while read line; do
+                    [[ ${line#ID_FS_UUID} = $line ]] && continue
+                    eval "$line"
+                    echo $ID_FS_UUID
+                    break
+                    done)
+	    [[ ${ID_KEY_UUID} ]] || return 1
+            echo " rd.luks.key=${keyfile}:UUID=${ID_KEY_UUID}:UUID=${ID_FS_UUID} " >> "${initdir}/etc/cmdline.d/90crypt.conf"
         fi
         return 0
     }
@@ -29,7 +46,7 @@this
     [[ $hostonly ]] || [[ $mount_needs ]] && {
         for_each_host_dev_fs check_crypt || return 1
     }
-
+    ddebug < ${initdir}/etc/cmdline.d/90crypt.conf
     return 0
 }

The path to the key-directory can be configured in /etc/dracut.conf

# location of keys.
# keys must be named {FSUUID} or {FSUUID}.gpg where FSUUID is the luks-device (not the key device!)
# for example "5b1049c3-ae7c-4b4c-99e7-240ba4a76f94" or "5b1049c3-ae7c-4b4c-99e7-240ba4a76f94.gpg".
#luks_key_dir="/boot/.luks"

dracut-crypt-gpg-extension.patch

anyone knows how to disable that stupid file extension filter in wordpress? simply rename .patch to .patch.txt is enough. This is just stupid in a single user setup as mine.

To answer a question in the comments, if one is paranoid and does not trust the boot partition (which has to be world readable), there are 2 ways to solve this:

  1. Use external boot volumes. Just put everything on a USB-Stick or a SD-Card. Just keep this with you all the time (or hide it in a secure location)
  2. use SATA full decryption (requires BIOS support). This allows to encrypt the disk fully without any LUKS and alike. The BIOS/Disk is responsible for doing all the stuff. This is transparent to linux, it does not even know the disk is encrypted. However, this requires HArdware support, and you have to Trust your Harddisk Vendor to implement the encryption correct (and not insert any backdoors).

Flattr this!

Comments 1 Comment »